SGHRM

The main activity of the customer's company is financial analysis; the company has more than 200 employees.The initial task was to automate the hiring process. At that time, all the documentation was on third-party services: Google documents, Excel files in cloud storages.

It was not just inconvenient but led to a lack of control over HR managers: candidates left unanswered, they were lost on the way to the interview, HR managers forgot to collect important data, or they skipped the security check. This worsened the hiring process too much, and due to the number of simultaneous vacancies and candidates, it was difficult to control it manually. The second problem was data security. It was unclear who had access to data, and the customer did not like the idea of ​​storing important information on third-party servers. In other words, the hiring process was not adjusted, that led to the loss of money and time.

The customer knew what he wanted, but, as often happens, there were no ready-made specs, tasks or interfaces. Even more, there was no formalized description of the business process. This did not frighten us, and we created all the specs ourselves.

First of all, we discussed that the customer is ready to take most of the responsibility for the future CRM introduction because we decided to work remotely to make development cheaper. We collected data about business process not directly from HR-managers, but through management.

We also initially created a flexible modular architecture based on the process paradigm. Thus, we have separated the conceptual part: the system consists of candidate processes that are in different states (invited, makes a test, his documents are processed, etc.) and the rules for the transition between these states. As a result, we received a transition graph that defines a business process. At first, we wrote a generalized code, and then, based on it, we described a specific business process of the customer.

When the customer found out that we had some kind of “constructor” in the code, we immediately received a request to make it visual so that he could customize and change the process on his own. We gently rejected this idea, because, despite the seeming concept attractiveness, it is very demanding to the user of the constructor. In order to build a working system even in the most convenient constructor, one needs some knowledge of business analysis, and we didn’t want to hear objections later that the system assembled on our product somehow works wrong.

For example, site builders have been around for a long time, but there are very few good sites made on a constructor because their users are far from knowing the laws of design and usability.

Such a flexible approach has repeatedly helped us in other projects, for example, when we wrote the testing platform MetaTest. Thanks to this approach, we easily converted the system from the corporate scale of one company into a product with monetization, where employees of many companies can pass complex tests. In our own ERP-system we use in our company for sales, hiring and project management, we constantly test different versions of processes, collect statistics, and adjust processes based on data mining.

So, we made a flexible architecture, where any process is described in the form of a graph, where there are various states between which the candidates can move. The candidate can be transferred between states only by filling in all the required fields. In such a system, a person cannot be forgotten or lost. As soon as a person is at some stage longer than the prescribed period, the system begins to remind a responsible manager and his directors about this. Access to different stages is divided by roles and access to specific fields in the candidate's card can be role-restricted as well.

React.js was chosen as a frontend-technology upon customer request. In the first version, we implemented a flexible process graph, basic reports, and task management.

The customer had a look at the MVP and asked for different types of processing for various candidates. Thus, different graphs were made in the system, for example, for candidates on the position of a manager and a programmer. Also, states and roles associated with the security service and the collection of references appeared in the processes.

We managed to make these edits within a week, and since we worked by Time & Material, the customer realized that he greatly saved his budget. “Walk this way,” decided the customer and asked us to expand the system from the hiring process to the full employees’ support in the company. We added the functionality of personnel records, appeals to the legal department, performance tracking, and the structure of the company to the system.

After the completion of this stage, we also made task manager, where it is possible to send notifications not only via email but also in Telegram; we automated the sending of reports and notifications, and we made floor and room maps with personnel sitting plans, tree structure of departments.

The work on the project turned out to be another confirmation of the correctness of the flexible and conceptual approach for us; it was a useful and valuable experience of business analysis and implementation of the system to support the existing company.

SeeYou Dispatcher CRM

When the customer came to us, he was already in the middle of the development process. He took a decision to create several native applications (one for couriers and the other for managers) to support his business process. This decision was not optimal and led to the expensive development process. At this point, the customer came to us as he wanted the process to be cheaper and faster.

We offered him to make a responsive web application. We considered this option as requirements for the interface in terms of following the guidelines for corporate applications are not so strict. Also, we proposed to create one application instead of two for managers and couriers to simplify the development process.

The project didn’t seem too complicated. And what’s funny, it appeared to be so - that happens not so often.

Before we started, we figured everything about the project and created complete documentation in advance to avoid surprises during the development. We have made mockups, usage scenarios and testing protocols.

an example of a mocap is apparently very similar to the final application.

We managed to complete the work together with testing and implementation in 1.5 months, which is great for automating the live process with different roles (all this time the service worked as usual).

order creation page

order list page

After we created MVP with main functionality and discussed it with the customer, we continued to work on usability. We found that managers performed different types of search often during our customer interaction scenarios explorations. That’s why we designed the main screen in a way where various entities can be searched via one uber-input field. This universal search field was able to find all entity types that existed in this CRM — addresses, users, products.

The most frequent operation in manager’s working process was courier’s assignment on order. It occurred many times per day; that’s why we created drag-and-drop functionality so managers can drag an order to a courier directly on the map.

Then we created type hints for frequent addresses in all the input fields and a system that allowed to offer the most frequently used customers and addresses to speed up operators’ work.

SeeYou was an interesting project in terms of development planning. We managed to create extensive project description in advance, and we stuck to it all the way through. We’ve got a unique experience, taking into account the fact that we are mainly engaged in Agile development.

MetaTest

The client appeared without a clear understanding of the future product. Instead, he stated goals he wanted to achieve. The company management was sure that employees should continuously take psychological tests. There were only some example tests and a desire to get graphical reports afterward.

There was a need in access roles and levels, for example, the heads of departments should have control over testing process deadlines of their subordinates. For example, “The whole department should take the psychological type test by the end of November.”

testing process

The system seemed to need several roles with tasks and privileges. We agreed on implementing Access Control List (ACL) pattern where users have roles and roles own resources. Thus it was easy to add new resources and roles during development of the project.

When we delivered MVP, the client decided to change the project audience. Instead of being used inside one company, it had to be a cloud product for many companies. Thanks to ACL pattern, it was easy enough to rearrange access levels and to add the “Cloud administrator” role.

By that time we had an extensive understanding of the project roles and goals.

Editors created tests and reports for users and administrators. Staff officers managed employees database, sent invitations and controlled the process of test taking. Summary reports were available after all of the staff members had finished the tests.

 For notification purposes, we added a personal messaging system. Now the administration could send test invitations to single people or whole departments easily. We also sent a copy via e-mail. If that was the employee’s first invitation, we created a new account for him.

personal messaging system

About reports. They had to be extremely flexible with different types of graphs and with the support of statistical math functions. For example, one can show personal motivation question answer only for people that scored 10 points more than average or filter people that are working in a company for more than a year.

graphical report

We could solve that by writing code for each specific report type. But we decided to write a unique report creation language, so-called DSL (Domain Specific Language). We used Twig templating engine as a base. Twig is a complete language with conditions, cycles and variables, but it is safe and is working in a sandbox environment.

Then we added functions for graph plotting, tables and statistics calculation. Also, we connected the app data to the report script (user data, answers, scores, averages, dispersion).

DSL-based report template

Then we created the logo and UI design, added some extra features like quizzes on the homepage and banner rotation functionality. As a result, we got a stable and user-friendly product. All thanks to nice initial requirement gathering and agile development process.