ERP: project initiation. Alternative customer perspective

UPD: I was accused of plagiarism, so I have to change the title of the article. There are no changes in the article itself.

Disclaimer: the post does not claim objectivity. Exclusively subjective opinion on the basis of not too much experience in implementing ERP on the client side. The article describes some actions that are desirable to do before entering into a contract for the implementation of the ERP system.

What is "consulting"?

I suggest to start with the terminology.

It seems to me that when introducing ERP, business representatives understand the concept of “consulting services” in a slightly different way than representatives of the executing company. Let's try to clarify. Wikipedia definition:
')
“Consulting (consulting) - the activity of consulting managers and managers on a wide range of issues in the field of financial, commercial, legal, technological, technical, expert activities. The purpose of consulting is to help the management system (management) achieve its stated goals . ”

So, the goal of the project is the implementation of the ERP system . That is what is prescribed in the contract with the performer. As part of the implementation project, consultants will NOT perform audit and reengineering of business processes as such.

Within the framework of the ERP implementation project, consultants analyze the existing processes and the wishes of users to reflect them correctly in the new system , nothing more. Operations that are planned to be performed outside the system generally fall out of their attention.

As a rule, a comprehensive audit of processes in order to achieve certain business indicators (for example, reduction of commodity balances, reduction of delivery time to a client) is performed by consulting companies of a different profile under a separate contract and for separate money.

Indeed, with the introduction of ERP, "optimization ..., increasing ..., minimizing ..." of business indicators occurs, but this happens only if at least one of the points below is fulfilled:

• automating processes previously performed manually or not executed at all;
• the customer clearly understands what new logic / structure / content he wants to build into the processes of the new system and how much he plans to gain from this. In other words, the customer himself (or with the help of third-party companies) conducted an audit of business processes in order to optimize business performance and he has a desire to reflect the recommendations received in the implemented ERP system;
• The standard processes of the implemented system are much better arranged than the current processes of the customer. And the customer is ready to adapt to these processes;

If the process of implementation will be a simple transposition of the processes from existing systems to a new ERP without significant changes in logic - no need to wait for breakthrough improvements in business performance. Those. I suggest not to confuse consulting directly with business processes and consulting processes when implementing an ERP system. However, sometimes consultants and when implementing ERP offer beautiful non-trivial solutions for business problems, but this is still more the exception than the rule on implementation projects.

What you need to do before entering into an agreement with a consulting company

1. Formulate the goal of the project and bring it to all business representatives who will be involved in the project. That's just not necessary streamlined formulations like "improving the efficiency of the enterprise through the introduction of ERP." Let these epistolary exercises remain at the mercy of implementers, really something, and they can do such wording for the contract: not every ERP implementation project is successful, but for every project, at the very beginning, beautiful goals are declared, the achievement of which is not always possible measure at the completion of the project.
   
   It is necessary in simple words to explain both the business and the executive company why an ERP – system is needed. After all, something inspired to consider the question of its implementation? What exactly? What for? It is necessary to formulate this idea and put it on paper.
   
   At the enterprise, everyone should understand why a new system is being introduced, what improvements it should bring to the enterprise, how much change will be made to specific business units.
   
   In this case, the business will be understood for the sake of what this whole whistle with an additional burden in the form of communication with consultants, studying thick documents with incomprehensible terminology, the need to study new software, etc. This is especially true for divisions, in whose work no drastic changes are foreseen and for them the change of self-recording for the industrial system looks like barter for soap. On only one question and moaning, consultants like “Why do you introduce your system to us?”, “And will they all fire us after the introduction of your system?”, “Everything works well for us, we don’t need to introduce anything!”, Etc. . You can save a significant amount of expensive consultancy time.
   
   Initially stated goal will be useful and performer. This will help the consultants to understand the vector, in the direction of which the customer wants to develop, apply the "correct" criteria when choosing a specific solution to problems from several possible ones, simplify the establishment of productive contacts with users.
   
   
2. Make a list of the necessary functionality to the new system . As a rule, this work is done during the preparation of the contract for implementation by consultants, but in my opinion, it is better for the client to start doing this independently before starting to communicate with potential performers. In our realities, situations are different, a project can be initiated at a friendly party of the TOPs with the phrase “We need to automate production here. Will you take it? ” And they will even clap their hands, and then the line employees of the integrator company realize that the customer understood “not quite” production in ERP as production automation, but something from the list below:
   
   
   • Integration of production equipment with IP. Moreover, as a control system, the customer implies an existing samopisny system;
   • Order accounting of production costs;
   • Automatic formation of a sequence of production orders, taking into account the limitations;
   • Production planning for a long horizon based on the sales plan (which also needs to be automated in the new system. Isn’t this something taken for granted?) With the ability to vary the parameters and choose the most optimal production plan.
   
   It is not clear to every IT specialist that not all of the above tasks are solved in the ERP system, but how do you know the director of a manufacturing company who is well versed in the production and sales of consumer goods, but far from IT? I hope your imagination will be enough to imagine how anecdotically such situations develop in reality: no one will take it out loud to say that the TOPs are wrong (one in the statement of the problem, the other in its assessment).
   
   Therefore, the list of requirements for system functionality:
   
   
   • promotes mutual understanding between the customer and the performer;
   • allows the contractor to make a more accurate calculation of the price and terms;
   • reduces the time of the contract preparation by the contractor: these requirements can form the basis for the section “Functional scope of the project” in the contract;
   • allows you to realize your share of responsibility for the project to the owners of business processes. In my opinion, internal IT specialists of the company can and should be involved in this work, but the responsibility for the completeness of the initial list, as well as for the completeness of the “Functional scope of the project” in the contract should rest with the owners of business processes.
   
   It is also important that these requirements state what the system should do, but it is not necessary to describe how the system should do it. Defining and describing how the processes will be implemented in the new system is the task of the consultants. And it’s not at all the fact that the processes in the new system will look like the business represents them at the initial stage.
   
   
3. Ask for a reference visit . It is hardly possible to organize a reference visit to a competitor’s company, but it’s quite possible to join a company from a completely different industry. You can analyze in advance which processes may be similar and give them special attention, cutting off work that is completely irrelevant. For example, if you have a household chemical industry, it is unlikely that a reference to the machine-building industry will help you (although in the HR part, you never know), but when you visit the food industry, you can already learn something useful, for example, in sales , shipments, in work with accounts receivable.
   
   An alternative to referencing is the demonstration of any important processes in an already configured system. An integrator company may have its own training and / or test bases on which they can demonstrate some typical processes.
   
   Even if processes are shown / demonstrated that are completely unsuitable for use on the project, but the customer will have more specific questions regarding the implementation, and he will receive exhaustive answers to these questions - it will not be a waste of time.
   
   
4. Evaluate the various options for implementing the system - phased and "all at once."
   When comparing, pay attention to the following points:
   
   
   • The scope and complexity of integration. It is absolutely clear that the phased version has a greater amount of integration due to temporary interfaces. And to compare “big bang” and “an elephant cut into pieces” by this criterion is meaningless, the result is known a priori. It makes sense to compare among themselves several options for phased implementation. Perhaps this parameter can be found more optimal option than the one that seems obvious when you first look at the processes of the enterprise. To study this issue, it is advisable to involve an expert with knowledge of the architecture of the system being implemented and knowledge of the existing IT systems of the enterprise.
     
     
   • The need to upgrade the old / deploy new infrastructure. To organize the infrastructure that meets the needs of the project requires time and money. With different implementation options - a different amount of time and money. Infrastructure is one of the most obvious tasks associated with an implementation project. But the number of cases when it is not given due priority is simply surprising, or it is simply forgotten.
     
     
   • The company's plans for natural development, for example, the commissioning of new warehouses, the purchase of new equipment, access to new markets. It is necessary to analyze how these plans overlap the plans for the implementation of the system and how these plans affect each other.

I hope that my article will reduce the number of questions "And what, and so it was possible?" On someone else's project.