Who is a consultant, and are they needed in IT projects?

Ekaterina Nikolaeva, city — Tashkent, co-founder of the AMEGA group of IT companies

Modern projects involve different role responsibilities for participants — everything depends on the class of software solutions being implemented, the project methodology used, the timelines, who is considered the client, and many other factors.

Who is a consultant

There is no single, stable definition of the term "consultant" in IT projects: some refer to a business analyst and/or system integrator as a consultant, others call a sales manager a consultant, and yet others refer to a technical support manager as a consultant.

In the classical understanding of the "consultant" role, it is assumed that this is a specialist who does not know the software solution, is not employed by the client, and therefore does not reliably know all their business processes. However, they possess certain expertise and best practices on how these business processes should work for the client. Thus, they act as an intermediary between the client as a business user of the future information system/application and the IT team of the executor, which must integrate this very system into the client's business.

Why the consultant is important

A consultant, possessing international and extensive expertise, can carry out business process reengineering. They can rebuild them anew, show where work is currently being done inefficiently, where processes are getting stuck, and which ones are failing entirely, posing risks to the business. Any integrator always finds it comfortable to work with a client who has clearly structured and updated their business processes, making them logical, sequential, and ready for automation.

Most software solutions have already been tested in practice in various companies and include well-established business processes. When an integrator tries to embed such a model into the client's chaotic environment, the result is digitized chaotic processes, and both teams experience stress. The client is dissatisfied because the integrator "does not want" to automate processes according to familiar rules, while the integrator suffers when their solution is adapted to outdated and inefficient approaches. In this case, a consulting team helps: first, it establishes correct business processes, and then they are digitized. Typically, such projects require minimal customization, as the processes become logical and fit into the system.

In large ERP system implementation projects, such "saviors" are often international consulting companies from BIG4. In my opinion, this is not always a mandatory condition; local consulting teams can also handle the task of structuring, reengineering, and preparing the client company's business processes for automation well.

There are successful cases in practice where experienced specialists are hired into the staff for the duration of the project or have civil law contracts signed with them. All of this depends on budgets.

The size of such a consulting team depends on the project perimeter: from 1 to 20 people. The primary factor influencing this is the perimeter of business processes. For example, for an ERP system project, the team usually works in blocks of business processes such as "sales," "warehouse accounting," "procurement," "assets," "treasury," "accounting and tax reporting," and so on. For an asset management system implementation project, processes such as supply, maintenance planning, repair planning, repair execution, interaction with contractors, personnel management, and so on, will be included.

Main tasks of a consultant

The list of tasks assigned to the consulting team also plays a role. Often, a consultant or a team of consultants performs the following tasks in a project:

1. Analysis of current business processes (As Is).

2. Designing future business processes (To Be).

3. Formalizing functional requirements for the system. Assistance in setting tasks for automating and digitizing processes.

4. Reviewing calculation algorithms, for example, for payroll, cost calculation for goods/services, separate accounting, automatic ordering of materials and raw materials, and many others.

5. Reviewing, updating, and creating accounting methodologies, for example, according to international accounting standards, budgeting, personnel management, repair management, and much more.

6. Reviewing, updating, and creating various regulations, provisions, and normative acts within the company, including even job descriptions.

7. Systematizing, structuring, cleaning, and enriching reference information with data, for example, the "Partners" directory, the "Assets/Fixed Assets" directory, the "Goods/Services/Raw Materials/Materials/Semi-finished Products" directory.

8. Unifying document templates, for example, templates for personnel orders, contracts, so that fields, fonts, formatting, style, etc., are consistent.

9. Unifying methods and formats for reporting within the organization, for example, headers, table headers, fonts, colors, etc.

10. Formulating and updating principles for end-to-end document numbering in the company, which are transferred to digitization, for example, the principle of assigning sequential numbers to lease agreements or supply contracts with clients.

11. Participating in the acceptance of customization and/or implementation results of the accounting system to confirm the correctness of business processes and algorithms in the system.

Of course, reviewing the list above, one might conclude that indeed, for a software solution, all these requirements should be analyzed/implemented by the integrator. Meanwhile, IT teams are convinced that the client should provide the aforementioned list. However, often the client's team is busy with their main work according to their job responsibilities. Moreover, this team has likely been working in the company for a long time and has already become accustomed to the existing business processes and is unable to look at them "from the outside" and understand what is "wrong." Perhaps none of them have ever thought about how it should be done correctly. And this is not because they are bad specialists, but because, immersing themselves in the environment, everyone plays by the rules within that environment, and they can only change collectively. Many, even understanding that something needs to be changed in the company, are simply not ready to take the courage and responsibility to state this. However, an external expert — a consultant — handles this role excellently. They have an external perspective, experience with best practices, and time to focus on describing, generating ideas, and documenting.

Key skills of a consultant

This work requires a serious understanding of business process logic, extensive study of best practices, the ability to build excellent communication, experience in moderating discussions, skills in working with tools that allow drawing business process maps, and the ability to work structurally and in detail with documentation. But the main requirement in this profession is high stress resistance, because the consultant is positioned between the client, who firmly believes that "everything is fine" and that they know best how to run their business, and the integrator, who is convinced that their software solution is the best of the best and was made intelligently.

The average salary of consultants ranges from $2,000 to $15,000 per month, with ages ranging from 27 to 50 years. People often enter this profession from senior management positions in large companies, or they start as interns and slowly climb the career ladder. But there is another popular entry into the profession — through IT. Often, former functional architects or lead business analysts transition into consulting because they realize that they prefer bringing order rather than just digitizing it.

Conclusion

Many IT solution business analysts already have consulting skills and often combine this role in projects. Often, in small projects, due to a tight budget and a targeted approach to the project, the client initially assumes that the software product integrator should also take on the consulting function. Therefore, my advice to project participants is to discuss this "invisible" part of the work before the project begins to avoid conflicts during the project regarding such a significant pool of work.