Do you know how difficult it is to find the right candidate at moments of strategic importance? Signium knows that getting the right candidate’s fit is challenging and requires a balance of hard assessment and application of judgment and experience.
Signium is an expert in helping clients recruit, develop and retain the best leadership teams. “We don’t just find talent – we advise senior business leaders on developing their skills, people and organizations, combining global reach with deep local knowledge to exceed client needs – whenever, wherever, whatever. During periods of significant change, we give the clients the edge when shaping their future.”
To adjust to the changing environment Signium has made a decision about technological development within the office in Poland.
They desire to improve their efficiency even more by using a modern and user-friendly web application. Its main goal is to help manage customer and candidate data. It supports sales management, tracks every customer and candidate interaction, it delivers actionable insights and facilitates team communication. It also enables access to data that the company has gathered over the years.
Our task was to build a new application as an evolution of the existing tool with a more efficient GDPR compliance module. A new web application is now helping Signium’s employees do their job more efficiently.
Old data migration from the system to the new web application proved to be the biggest challenge. It was difficult due to lack of technical documentation and solutions that are currently out of use. The first version of Signium’s system was created about 25 years ago and updated a few times after that.
The transfer of data was essential for proper functionality of the new web application. Our aim was to migrate the data and make the web application work efficiently. As it happens with such a mature product which contained inconsistencies, non-existent references or “interesting” solutions. Some of them, however, proved to be highly innovative and impressive for those times.
The first step was to separate important data. We reduced some tables by half, for example from 40 columns to 20. A significant part of the tables wasn’t useful for us, but due to the lack of documentation, we had to be in permanent contact with the client, to analyze the operation of the old software, step by step, table by table, and to assess what data we will need. Having selected the tables we are interested in, we rebuilt their contents to JSON. Then we wrote a script in Ruby, which flew over each of them and matched the data to a previously designed new database (PostgreSQL).
As mentioned before, a huge part of the data contained left references to previously deleted elements. It also often combined tables by strings, not IDs. The old tool had many open fields for self-entry. In the new application, they had to be replaced by values taken from the dictionary to avoid lack of consistency in nomenclature. It ended up mostly in plucking all possible variants of a given column and wrapping it in a big switch case.
Another challenge was to process attachments in the database. A certain type of records allowed to attach files to it – they were saved as BLOBs in one of the tables. We were forced to use an external program (OLE Express) to export files. Unfortunately, despite following the program instructions, they could not be named according to the references held by this table, we also had to sort the records and give the files a name in the form of an iterator (1,2,3, …). We wrote a simple SQL that combined table records and attachments with the parent table records in the correct order. After trying to transfer them to the new application, we noticed that they fell into the wrong places. It turned out that the old application had an error related to attachment translations. The main version correctly matched with the given record, while the translation contained an empty reference. This caused a simple error on our side because instead of the left join required here, we used the inner join. It may sound trivial, but it was not easy to orientate, because in this case we operated on the ID itself.
But the most important thing is that we have managed to overcome these challenges!
The application should allow users to filter the results of the extended database by many different categories like location, nationality, company and many, many more. So its UX and UI should be at the highest possible level. Moreover, we have cooperated mostly remotely during the project using emails and calls for communication, Jira for tasks planning and reporting.
Together with the Signium team, after the series of workshops, we determined the expectations, needs and specified the functions of the web application. Behind many filtrating options available for employees stays a complex architecture of the system. After the Signium team approved the colors and mockups of individual screens presented by our UX/UI designer, we started developing the app. We decided to use Ruby on Rails for back-end and VUE.JS for front-end development. We took some time to test the application properly, and our QA specialist was paying attention to every detail. The whole process went smoothly as we were always in touch with the client.
Our team is highly satisfied with the results of our cooperation with the client, especially as most of it was remote. The web application was created for internal use and the end-user has many of the available functions, easily accessible on just a few clicks. We used a limited number of colors while designing the interface, so that the product itself helps and doesn’t distract while working. We provided Signium with full technical specifications which allow in the future to analyze the application and develop it further. Signium has always been taking care of GDPR compliance, but the new system ensures data security and more effective tracking of consents to the processing of personal data. Now they can conduct searches at top executive and upper management levels even faster!