Get best of the week

Modeling business processes as part of an ERP system implementation project

Before starting another project to implement an information system that covers most areas of the enterprise’s functioning, I decided to write a series of articles with my thoughts on the rationale for the fact that large industrial enterprises, especially those that have been operating for decades, have more than half of ERP projects “ they don’t take off. ” I will write these articles more for myself as a “sclerosis” for forming conversations with top managers of the enterprise and structuring those considerations that I made based on my experience.

These articles are not intended to tell the world how cool I am or how best I know how to implement such projects. If you say that this is “another article of a loser who, well, understands everything incorrectly,” this will be a value for me too, as I expect someone to share their thoughts in the comments.

There are plenty of problems in the implementation of such systems. If you correctly build a checklist of the risks of the ERP-system implementation project, then it will take more than one hundred lines and most likely will turn into a pretty good justification for why the implementation of the ERP-system can never be started in life. Nevertheless, successful projects exist, the need for the introduction of such systems is also repeatedly confirmed, which means that the introduction of such systems is not an impossible task.

For myself, I divide all the problems that impede the successful implementation of the project into three categories:

  1. Political, caused by the mismatch of the stated goals of the project with the internal expectations of project participants
  2. Functional, caused by lack of competencies of project participants
  3. Technological, caused by underestimation of required resources, time

This is rather large and conditional, but it helps me personally when ranking the risks to form an assessment of the probability of a successful implementation of the system.

I have no experience in implementing large production systems using Agile or any other methodologies other than the standard “waterfall”, which includes the following main steps:

  1. Inspection of the enterprise, description of business processes “as is”, “as will be”.
  2. Creating an information system model.
  3. Development and implementation of TK.
  4. Test operation.
  5. Pilot operation.

Therefore, the description of the tasks and risks that I want to structure in my head is connected with the waterfall methodology and may not be entirely applicable to technologies for achieving quick results.

It would probably be more expedient to start with a description of the tasks that must be completed before the project is launched, such as identifying a functional customer, gathering project teams, forming and evaluating project success criteria.

But so far I have not structured these considerations and put them in a separate box.
Therefore, to read the following article we will take it “for granted”: the need for implementation is fixed, a functional customer is found and is on fire with the project, the budget is found, the project teams are correctly assembled, resources for implementation are identified.

In the first article, I would like to fix the tasks and risks of the business process modeling project. This is far from the most critical problem that was available at the initial stage of the project, but since the stage of enterprise inspection begins with the modeling of business processes “as is” and “as it should be,” I decided to start with it.

So, I will begin.

It is difficult to imagine that one of the owners or top managers of a large industrial enterprise acquired an ERP system for the sake of fashion. One way or another, if you started talking about acquiring a system, then top management is dissatisfied with existing analysts for making decisions, existing business processes, the speed and quality of changes in them (we do not take into account the acquisition of an ERP system for money laundering or political, image purposes).

Business processes always exist in an enterprise and it doesn’t matter whether they are documented or not. Moreover, at a large industrial enterprise, it is likely that the actual business processes in a substantial part or do not completely coincide with the documented business processes. One way or another, the shipment request still gets to the warehouse, economists still calculate the production needs, and the master still generates a shift-daily task in some system, using a pencil on a punch card or verbal “mother's edra”.

Another question is that these established business processes are not optimal, redundant, and sometimes they also lack any value for both the business and the participant in the business process. As an example, this is the formation of some kind of management reporting, the appointment of which everyone has already forgotten, nobody is analyzing the content of and the need to create this reporting is argued at the level of “Maria Ivanovna always asks to do this, but why, God knows, ask her her. "

Of course, no one wants to drag these non-optimal business processes into an ERP system. In theory, at the stage of system design, top management declares goals for optimizing business processes and their regulation. And even subscribes to the thesis of "maximizing the model of the existing business processes of the enterprise under the typical functionality of the implemented system."

In practice, everything looks much more deplorable. Ordinary performers are not ready to change business processes, even the most elementary ones. Maybe this is personally my unsuccessful practice of working at prom. enterprises, maybe this is a real trend, but don’t expect that the phrase “now you don’t need to carry an expense order for approval by feet for 3 kilometers, but can be done automatically in the system in 3 seconds”, you will receive delight in response. An ordinary performer, whose job consisted of 60% of the time running with documents, immediately decides that he will be cut, he will be given jobs in which he does not think or will reduce his salary. The logic in his considerations is not always present, but the ordinary employee can provide resistance to changes quite clearly. Moreover, as at the stage of collecting requirements for the system,when he will prove the value of just running around with papers (“And MikhalKuzmich from the budget department of the head organization said that they only accept a scan of a document with all signatures from us”), and at the stage of operation of the system, when he just plainly prints orders from the old system and wear them with your feet (“but no one told me that the new system is already working”, “oh, yes, it’s faster with my feet”, “but I sent it to this system of yours, and nobody answered there”, etc.).“I sent it to this system of yours, and nobody answered there”, etc.).“I sent it to this system of yours, and nobody answered there”, etc.).

Far from always ready for changes in business processes and middle managers and even top managers. Changing business processes leads to a change in the functions of subordinate personnel and is able to identify both a shortage of qualified personnel and the release of personnel due to a reduction in labor costs for performing certain functions. This is a hidden political factor that can greatly influence decision-making on changing business processes. At the initial stage of system design, it can be perceived as insignificant and solved organizationally at the level of the process owner. But at the stage of test or pilot industrial operation with a lack of managerial potential, the implementation of a business process can even lead to sabotage of project work by middle managers.Lack of resources can be detected already during the OPE and directly affect the course of operation, and underload or qualification unavailability of personnel will be hidden by the manager under the pretext of the complexity of operating “this your system” and lead to requirements for changing the new system to previously existing business processes.

Even process owners and top management may not be ready for changes in business processes. Key exits from one business process are inputs to another business process. And this banal rule of modeling business processes fits well on paper, but meets strong resistance in practice. The reasons for the inconsistency of business processes in this case are political in nature and the solution to these inconsistencies is rather painful.

A textbook situation when a sales plan is approved at the enterprise in isolation from the production plan. And when forming a procurement plan, neither a sales plan nor a production plan are taken into account. At the stage of paper workflow, these gaps in business processes are not visible so clearly, or rather, they are visible, but the process owners have learned to deal with them at the operational level. Each of the leaders goes to the director to sign his plan alone. And he makes a plan-fact analysis exclusively according to his plan. At the same time, the integrity of the life picture of the enterprise is lost, breaks in analysts are recognized as practically unavoidable, management of top managers is carried out manually based on irrelevant, incomplete data.

It is necessary to identify such contradictions and gaps in business processes as early as possible and take their decision to the highest level. The strategic enlarged map of business processes “how will” should be perceived and supported by the process owners as a constitution. The introduced ERP-system will not solve these contradictions and inconsistencies of business processes automatically, it will not bury them, but it will be much more expensive to bring them to the surface and resolve these issues during operation. And the late fixation of business process gaps very often leads either to the suspension of the project with all the consequences, or to piecewise automation and deviation from the goals of the project.

What can be done for the most productive change in business processes?


  1. - « » -, -. , , . , 8 , . - , . 10 .

    , - . , - - . - -. ( « , , »), , .
  2. - . - . , , . , , .
  3. - . -, . , -, . , . , -, , , « » . . , . , 10 - , , , .
  4. . ERP-, -. . - - . - , , .
  5. , ERP-, « ». , .
  6. KPI -. KPI , ..

Summary: I think that a project to implement an ERP system will have a much greater chance of success if all the project participants on the part of the customer share the thesis that the information system serves to automate EXISTING business processes, is ready to structure them, put information on the shelves, prepare analytics, but it is not a substitute for the brains of performers and will not be a lifesaver if the enterprise management itself is not ready to deal with the existing chaos.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles