- Implementation begins with a prototype, in which chains of business processes have already been implemented, which can be accepted by the customer as target. At the same time, there may be differences that must be eliminated during the project.
- To work on the project, a single team is created consisting of consultants, customer representatives from the business and IT service. Customer representatives are trained during the project and together with consultants test prototypes of the system, formulate the requirements for the system and accept their implementation. The IT service takes an active part, implements some of the requirements, and at the end of the project takes the system for support.
- During the project, several more prototypes are set up, which with each iteration become closer to the customer's requirements. During the course of the project, the requirements are specified and changed several times.
In fact, in a large ERP implementation project, agile principles are applied - people and interaction are more important than processes, a working product is more important than documentation, cooperation with a customer is more important than a contract, and readiness for changes is more important than following an initial plan.
However, in the conditions of a signed contract with a fixed price, working with a large unified system, these principles need to land. Without additional conditions and restrictions, the project will most likely not be completed, and it will certainly go beyond the budget.
First, this is not a system development that can be started in pieces, as is often the case in agile projects, when each iteration must end with the development of a complete functional block ready to use. An ERP system can only be run in its entirety, and not in parts.
Secondly, if you do not limit the requirements, then their refinement and change will be endless, the project will stretch, and will require additional funding.
So, the first problem is that the ERP system consists of parts that are closely interconnected, permeated with end-to-end processes. Therefore, we need a holistic system in all its scope at each iteration. The task is facilitated by the fact that the system is not created from scratch, it is a finished product. Often there is an industry solution or a pre-configured system with standard processes that you can use as your first working prototype.
It takes time to prepare the next prototype. The system is large, complex, there are many project participants, so it takes at least two months to prepare a prototype, test it and form comments on it. In our case, iterations are not two weeks, as in a typical agile, but 2-5 months.
At each iteration we make a complete system, but there are differences between them. In the first iteration, this is a typical system with standard or industry-specific processes. Standard processes can be quite far from what the customer expects to see in the end. The processes at the top level are the same, but the details will be very different. When I say "customer" I mean people who will use the system - regardless of what relationship connects him with the contractor - contractual, or it is an internal project of the company, where the contractor can be the IT department.
After collecting the requirements based on the results of testing the first prototype, we set up the second prototype, in which all the requirements that can be implemented with the settings are implemented, the customer's test data is loaded, all the questions that surfaced during the testing of the first prototype are worked out. The customer goes through the business processes in the system, checks to what extent the current implementation suits, how efficient the system is and meets its requirements.
At the second iteration, future users of the system see it not for the first time, feel more comfortable, put forward new requirements that are already more meaningful and detailed. Ideally, all key issues should be resolved during this period, because changes become more expensive the less time remains before launch.
At the third iteration, we can already afford to start developing extensions or, as we call it in the jargon, "customizations" of the system. These can be reports, procedures, forms that are absent in the standard system, but they are very necessary, because it is not always possible to adjust business processes to the standard of the system. The decision to develop extensions is made after considering all other possibilities, since their development and support is a rather expensive pleasure, and this is additional money.
We have been preparing the third prototype for several months so that it becomes a full-fledged system close to the target one. Typically, the system is fully configured, with a substantial amount of data loaded, and all critical extensions installed. It is being tested very thoroughly with a large number of users. This testing usually lasts about a month.
After testing the third prototype, comments and questions remain, on which we draw up a plan for their development. And all critical remarks should be eliminated by launch.
The pace of the project by this time becomes very intense, time is compressed, like during a fight. It is necessary to prepare instructions, train users, convert data, carry out organizational changes. Previously unsolved issues emerge, someone remembers that he forgot to announce some important circumstance ... Before the launch, one more, acceptance testing is carried out - and forward, the start of a new system.
This, of course, is a very superficial description of an iterative approach to the implementation of an ERP system. The methodology describes in detail all processes, including documentation, training the project team and users, converting data, carrying out organizational changes, etc., which in fact do not differ from any other approaches to project management.
A reasonable question arises: how to organize the process in such a way as not to go to the fourth, and then to the fifth or sixth iteration? How can you avoid the risk of uncontrolled changes and clarification of requirements, which naturally develops as you delve into the details, and sometimes due to business changes?
Of course, there is such a risk, and it is very significant. At the entrance to the project, the requirements are fixed in the contract, but as a rule they are formulated in a general way, and the devil is in the details.
With the "waterfall approach" at the beginning of the project, the requirements are fixed, the technical assignment is signed, which becomes a formal basis later to refuse to change the requirements or ask for additional money for the change. In an iterative approach, this trick is not applicable.
We understand that requirements are subject to change and will change without fail. We are investing in time and money. The question is the extent of these changes. We can make a big mistake, and get a wave of new comments at the end, especially if the customer at first refers to participation in the project "slipshod", selects the wrong people for participation, does not formulate clearly requirements, hopes that "everything will be fine" relies on consultants - then in the end we have serious problems.
Therefore, the most important component of reducing the risk of sprawling requirements at the end of the project is customer involvement. The very same implementation of the principle of agile development, according to which the team works together - the customer and the developer, in close contact from the very beginning of the project. This has several important consequences. Firstly, early identification of real needs and non-compliance with these needs of the system. Secondly, being involved in the process of preparing the system, the customer becomes its owner not at the time of its transfer in its finished form, but gradually, during the entire project. It becomes the result of his work, and by the end of the project it becomes impossible to make claims like “your system is not working”, because this is his system.
It is good practice when the most qualified people capable of making decisions are allocated to the project 100% of the time. In our practice, these were the owners of business processes, their deputies, or employees who enjoy the full confidence of service managers. Yes, it is difficult, yes - there are no extra people, yes - it is difficult to give the best. But this is the only way to make a project quickly and get a high-quality system. Project participants get a huge leap in understanding how an enterprise works, acquire new knowledge, learn to work in a new way, and, as a rule, this creates new career opportunities for them. You can consider the ERP implementation project as an extremely powerful personnel development event, as the creation of a new personnel reserve for managers.
The second thing to look out for is the tight project time limits. The project schedule should be aggressive and the launch date should not change. If the project is stretched, then the likelihood of changing business requirements increases. If the project date shifts, new requirements appear, and the situation repeats: again the system is not ready, let's postpone the launch. The perfection of the systems will not reach even with very long project terms, and all the requirements will never be fully identified before launch. Only real operation shows all the bottlenecks and what is really important. Therefore, after the launch, there is a stabilization period of at least three months, during which the project team helps and educates users, corrects errors, receives new requirements and makes the necessary improvements.
To resist the temptation to push back deadlines and expand demands, everyone must have a strong incentive to meet those deadlines. For the contractor, of course, these are contractual obligations and a budget. The customer's motivation is usually formed from above, from the management or shareholders of the company. For example, a CEO making a launch readiness decision may be shackled by an obligation to shareholders. The project manager and project team can be motivated by a bonus at the end of the project, subject to deadlines. The heads of departments will be faced with the need to start up by order of the enterprise.
It rarely happens when there is a sincere desire to launch the system as soon as possible because of the pleasant expectations of the new opportunities that it provides. The new system is, first of all, stress and the need to move from the familiar to the initially inconvenient interface, to more control, to the need to enter more information. End users almost never welcome a new system. It takes time for them to come to terms and find advantages in it. And if the internal motivation to launch on time is not initially built into the project, the launch will be postponed, because the systems will never be 100% ready to launch.
Given the tight launch dates, it becomes impossible to endlessly expand and refine requirements. The project team, which includes the customer's representatives, stops nominating them and starts thinking about priorities, about the possibilities to postpone something, in the face of an inevitably impending deadline. The task of the project manager is from the very beginning of the project to form this feeling of an early launch, lack of time. Too calm an atmosphere in the first half of the project means that the second half will be extremely stressful due to the race that is inevitable. To do this, intermediate goals must be set, and the project schedule is formed in such a way that the first phases of the project are compressed in time, and due to this, a reserve is formed for the last phases before launch. There are different strategies in long distance running,but here the strategy should be the same - you need to run quickly from the start, you may not have enough strength to accelerate at the end.
Summary of all of the above:
- The iterative approach gives much better results in terms of the closeness of the system to the stated and implied customer requirements.
- Full involvement of the customer in the project is absolutely essential to implement this approach.
- To avoid the proliferation and endless refinement of requirements, project timelines must be tightly constrained, and project participants must be motivated to meet them.
Of course, these are only the basic principles, there are still many subtleties that depend on the specific conditions, the characteristics of the company and the personality of the participants. In each case, everything is decided individually.