ERP: project initiation. Alternative view from the client
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 pretend to be objective. Exceptionally subjective opinion based on not too much experience in implementing ERP on the client side. The article describes some of the actions that it is advisable to do before concluding a contract for the implementation of an ERP system.
I suggest for a start to determine the terminology.
It seems to me that when introducing ERP, business representatives understand the concept of “consulting services” somewhat differently than representatives of the executing company. Let's try to clarify. Definition from Wikipedia:
“Consulting (consulting) is the activity of advising managers and managers on a wide range of issues in the field of financial, commercial, legal, technological, technical, and expert activity. The purpose of consulting is to help the management system (management) in achieving the stated goals . ”
So, the goal of the project is the implementation of an ERP system. This is what is prescribed in the contract with the contractor. As part of the implementation project, consultants will NOT audit and reengineer business processes as such.
As part of the ERP implementation project, consultants analyze existing processes and user wishes for their correct reflection in the new system , nothing more. Operations whose execution is planned outside the system generally fall outside their area of attention.
As a rule, a comprehensive audit of processes in order to achieve certain business indicators (for example, reducing inventory balances, reducing delivery time to a client) is carried out by consulting companies of a different profile under a separate agreement and for separate money.
Indeed, when ERP is implemented, “optimization ..., increase ..., minimization ..." of business indicators occurs, but this only happens if at least one of the points below is fulfilled:
If during the implementation process there will be a simple transfer of processes from existing systems to a new ERP without significant changes in the logic, you do not need to wait for breakthrough improvements in business indicators. Those. I propose not to confuse business process consulting directly with process consulting when implementing an ERP system. However, sometimes consultants, when implementing ERP, offer beautiful non-trivial solutions for business tasks, but this is still more an exception than the rule on implementation projects.
I hope that my article will reduce the number of questions “And what, could it have been so?” On someone else’s project.
Disclaimer: The post does not pretend to be objective. Exceptionally subjective opinion based on not too much experience in implementing ERP on the client side. The article describes some of the actions that it is advisable to do before concluding a contract for the implementation of an ERP system.
What is "consulting"?
I suggest for a start to determine the terminology.
It seems to me that when introducing ERP, business representatives understand the concept of “consulting services” somewhat differently than representatives of the executing company. Let's try to clarify. Definition from Wikipedia:
“Consulting (consulting) is the activity of advising managers and managers on a wide range of issues in the field of financial, commercial, legal, technological, technical, and expert activity. The purpose of consulting is to help the management system (management) in achieving the stated goals . ”
So, the goal of the project is the implementation of an ERP system. This is what is prescribed in the contract with the contractor. As part of the implementation project, consultants will NOT audit and reengineer business processes as such.
As part of the ERP implementation project, consultants analyze existing processes and user wishes for their correct reflection in the new system , nothing more. Operations whose execution is planned outside the system generally fall outside their area of attention.
As a rule, a comprehensive audit of processes in order to achieve certain business indicators (for example, reducing inventory balances, reducing delivery time to a client) is carried out by consulting companies of a different profile under a separate agreement and for separate money.
Indeed, when ERP is implemented, “optimization ..., increase ..., minimization ..." of business indicators occurs, but this only happens if at least one of the points below is fulfilled:
- Automated processes previously performed manually or not executed at all;
- the customer clearly understands what new logic / structure / content he wants to lay in the processes of the new system and what kind of gain he plans to get 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 indicators and he has a desire to reflect the recommendations received in the implemented ERP system;
- standard processes of the implemented system are arranged much better than the current processes of the customer. And the customer is ready to adapt to these processes;
If during the implementation process there will be a simple transfer of processes from existing systems to a new ERP without significant changes in the logic, you do not need to wait for breakthrough improvements in business indicators. Those. I propose not to confuse business process consulting directly with process consulting when implementing an ERP system. However, sometimes consultants, when implementing ERP, offer beautiful non-trivial solutions for business tasks, but this is still more an exception than the rule on implementation projects.
What you need to do before concluding an agreement with a consulting company
- To formulate the goal of the project and bring it to all business representatives who will be involved in the project. Just do not need streamlined formulations such as "improving the efficiency of the enterprise through the implementation of ERP." Let these epistolary exercises remain at the mercy of the implementers, so what, everyone knows how to make such wordings for the contract: not every ERP implementation project is successful, but beautiful goals are declared for each project at the very beginning, the achievement of which is not always possible measure at the completion of the project.
It is necessary in simple words to explain to both the business and the executing company why an ERP system is needed. After all, something inspired us to consider the issue of its implementation? What exactly? What for? It is necessary to formulate this idea and state it on paper.
At the enterprise, everyone should understand why the new system is being introduced, what improvements it should bring to the enterprise, how much the changes will affect specific business units.
In this case, the business will understand why all this whistle with an additional load in the form of communication with consultants, studying thick documents with incomprehensible terminology, the need to learn new software, etc. This is especially true for divisions in whose work no radical changes are foreseen and for them changing a self-record to an industrial system looks like a barcode for soap. On questions and moaning alone, consultants like “Why are you introducing us your system?”, “Will we all be fired after implementing your system?”, “Everything works well for us, we don’t need to implement anything!”, Etc. . You can save a significant amount of expensive consulting time.
The initially formulated goal will be useful to the performer. This will help consultants understand the vector in the direction that the customer wants to develop, apply the “right” criteria when choosing a particular solution to the problem from several possible ones, and simplify the establishment of productive contacts with users. - Make a list of the necessary functionality for the new system . As a rule, this work is carried out 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 communication with potential performers. In our realities, the situations are different, a project can be initiated at a friendly TOP party with the phrase “We need to automate production here. Take it? ” And they even clap hands, and then the line employees of the integrator company realize that the customer, under the automation of production, understood “not quite” production in ERP, but something from the list below:
- Integration of production equipment with IP. Moreover, as a control system, the customer implies the existing recorder system;
- Custom cost accounting for production;
- Automatic generation of the sequence of production orders taking into account the existing restrictions;
- Production planning for a long horizon based on a sales plan (which also needs to be automated in the new system. Is this not a matter of course?) With the ability to vary parameters and choose the most optimal production plan.
This is not clear to every IT specialist that not all of the above tasks are solved in an ERP system, but how does the director of a production company who is well versed in the production and sales of consumer goods, but far from IT know how to do this? I hope your imagination is enough to imagine how anecdotally such situations develop in reality: no one would 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 contractor;
- allows the contractor to make a more accurate calculation of the price and timing;
- reduces the time for preparation of the contract by the contractor: these requirements can become 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, the company's internal IT specialists 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 Project Scope” in the contract, should lie precisely with the owners of business processes.
It is also important that these requirements indicate what the system should do, but do not need to describe how the system should do it. To determine and describe how the processes will be implemented in the new system is completely the task of the consultants. And it’s not at all a fact that the processes in the new system will look like they are initially presented by the business. - Ask for a reference visit . It is unlikely that it will be possible to organize a reference visit to a competitor's company, but to a company from a completely different industry is quite possible. 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 production, it is unlikely that the reference to machine-building production will help you at least something (although in terms of HR - how to know), but when you visit a food processing company, you can already learn something useful, for example, in sales , shipments, in working with receivables.
An alternative to reference is a 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 any typical processes.
Even if processes that are completely unsuitable for use on the project are shown / demonstrated, but at the same time the customer will have more specific questions regarding the implementation, and he will receive comprehensive answers to these questions, this will not be a waste of time. - Evaluate the various options for implementing the system - phased and "all at once."
When comparing, it is worth paying attention to the following points:- 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 by this criterion the "big bang" and the "elephant cut into pieces" is meaningless, the result is known a priori. It makes sense to compare among themselves several options for phased implementation. Perhaps this parameter allows you to find a more optimal option than the one that seems obvious at first glance at the processes of the enterprise. To study this issue, it is advisable to involve an expert with knowledge of the architecture of the implemented system and a connoisseur of existing enterprise IT systems.
- The need to upgrade old / deploy new infrastructure. It takes time and money to organize an infrastructure that meets the needs of the project. With different implementation options - a different amount of time and money. Infrastructure is one of the most obvious tasks that accompany an implementation project. But the number of cases when she is not given the proper priority, or even simply forgotten, is surprising.
- The company's plans for natural development, for example, the commissioning of new warehouses, the purchase of new equipment, and access to new markets. It is necessary to analyze how these plans overlap plans for the implementation of the system and how these plans affect each other.
- 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 by this criterion the "big bang" and the "elephant cut into pieces" is meaningless, the result is known a priori. It makes sense to compare among themselves several options for phased implementation. Perhaps this parameter allows you to find a more optimal option than the one that seems obvious at first glance at the processes of the enterprise. To study this issue, it is advisable to involve an expert with knowledge of the architecture of the implemented system and a connoisseur of existing enterprise IT systems.
I hope that my article will reduce the number of questions “And what, could it have been so?” On someone else’s project.