The successful implementation of enterprise resource planning software is not a matter of course. Every phase has to be executed professionally in order to get step by step to the current ERP solution. What is to be noted and how the phases look exactly, you will learn in our article.
Determine of project participants
Clear competencies and short decision-making paths are the motto here. On the client's side, there should be one main responsible person who understands the business processes very well. In addition, at least one second person is important, who sees everything from a different perspective and with his soft skills (such as logistics, accounting) can improve requirements and also assess the current state of development.
On the part of the ERP agency (contractor) there is a project manager; there can be more for big projects. It is also important here that there is one main person responsible. The programmers work alongside the ERP project manager. It is they who blindly master the ERP and implement the requirements. The programmers need to be fully involved in project management because they see everything from a technology perspective and thus have a decisive influence on the software architecture and design.
Goals generate new requirements on the ERP that go far beyond the execution of a requirement list - they influence the entire course of the implementation of the new ERP. Example: In the first step of the launch, one goal may be to map only the current processes and, after the first launch, to add further processes in a modular way. Also, the timeline should be set realistically to have control over the status of the project.
WHAT DO WE WANT TO ACHIEVE WITH THE NEW ERP?
Improved order processing
Make processes more efficient
Reduction of administrative expenses
MAIN OBJECTIVES OF EACH ERP´s ARE
Adapting the ERP to the company processes and mapping / controlling the business processes in the ERP.
The beginning of an ERP project is the actual analysis. In an existing ERP project, it shows what is mapped and which processes are controlled within the ERP. If the company does not yet have ERP, the actual state analysis can summarize the current functioning processes, which are controlled and displayed in other tools and software. The recording of the actual state can be very time-consuming - but should absolutely be carried out thoroughly. Here we find the basic building blocks of the future target state, with the already functioning and illustrated business processes - these data can be applied immediately in the conception and planning phase.
Furthermore, when the actual state is recorded, potential problems are uncovered and valuable experience gained, which is also incorporated in the design and planning phase. In the ERP area, a functional specification sheet should be prepared by the client. Last but not least, it should be mentioned that the ERP agency can feel empathy with the company and understand the processes in depth.
Tip: By simply mapping the processes, a first board should emerge here that shows the big picture (actual state). Furthermore, already possible chances and problems can be marked here
The analysis of the actual state is the preparation for the target state (objective of the project).
CONCEPT & PLANNING
After recording the current status, the new ERP can be conceptualized together with the ERP Agency. In the first step, the first requirements have to be defined. They result from the client's functional specifications, from the analysis of the current status, which is worked out again together with the ERP service provider, as well as the goals and wishes of the contracting company. During conception, further important requirements are worked out. How this works, read in the following paragraphs.
For the sake of common understanding and clarity it should be standard to have a large backboard. This backboard is a large wall on which the parts of the requirements can be found. All the first requirements are sorted in large areas on the backboard, so that a good overview is created and they can also be assigned to the corresponding ERP modules. The headings (backbones) of the large subareas can be: Warehousing, Sales, Purchasing, Finance, Employees - but there are also processes that belong together. The first division may like to contain 10 or more points.
Requests that belong together and are arranged in one area are now clustered into other contiguous areas. The whole thing can be done in the beginning in Excel, but then should be brought to the big board. This helps to build a common understanding of the processes and to develop the conception further.
At this and the next stage, we do not distinguish between the different releases, but try to record the whole thing. Requirements that are not expected to be finalized in the first release, can already be marked here with a different color, so that you focus on the essential. It is important, as in the other planning sections, that all project participants build a common understanding and have a positive influence on conception and planning.
Tip: It is also useful to have a higher-level board to have an overview of the whole project. It shows only the backbone and the largest parts!
STORY MAPPING (USER STORYS)
Now that all requirements are on the board, the sections can be examined more closely. We recommend story mapping, which shows processes from the point of view of different users. Story mapping should help to understand users and processes, to recognize improvements and opportunities, and to avoid mistakes. The Story Mapping Boards should be photographed and saved after being created so that they can be used later. Results are documented and new requirements recorded in the backboard. Incidentally, not more than 4 people should participate in the story mapping, first, not to blow up the financial framework and second, not to end in counterproductive discussions.
COOPERATION WITH THE PROGRAMMERS
Programmers know the ERP better than anyone else. They have the technical know-how and the experience to correctly assess processes and sequences of implementation. For this reason, there should always be a programmer in the planning process.
INTERNAL RELEASES & ORDER OF THE IMPLEMENTATION
When all requirements have been met, the order of work and priorities must be determined. It is possible to work with several internal releases, which in turn are divided into sprints - the whole here now concerns the implementation of an ERP. Should an existing ERP be extended, each release is a real "release". The aim is to complete parts of the backboard as far as possible or to conclude process chains. Time-consuming new developments, which do not belong to the core process of the enterprise and also do not impede the processes of the enterprise, should be implemented only after successful implementation of the ERPs - this applies above all to larger projects.
Tip: Ideally, the company's standard processes are first implemented that conform to the standard functionality of the ERP.
PROJECT MANAGEMENT SOFTWARE
Nothing works in software development without project management software. It enables process and project tracking at the project, epic and ticket level - if they use Jira, or similar software. But that's not all: good project management softwares track time for every ticket and employee, show statistics and enable communication through all processes.
CREATING THE SPRINTS AND TICKETS
Once the rough sequence of work has been completed, sprint planning and ticket preparation for each job can begin - which is also a recurring process. Sprint planning and ticketing should be done on a task board and in the project management software. An important point is to set the sprint length - the time to complete the work until a new sprint starts. Each ERP agency has its own experience, as well as the structure of the entire sprint. We, the Odoo agency bloopark, use the process model Kanban to be in control at all times. If the sprint is scheduled, the implementation will start on day X.
WORKING WITH BASE DATA
After creating the first sprint and the tickets, the implementation can begin by the programmers. The programmers can take and process individual tickets. For dependencies on other tasks (tickets), a certain order must be adhered to. When using the process model Kanban, a predefined process is used. This kanban process has several columns in which the tickets are located.
First column is usually "open", here are tickets that need to be done. For example, the second column is called "Progress," which contains tickets that one or more programmers are working on-ideally, the tickets are tagged with a picture of the editing programmer. Once the task has been done, the programmer has to write another test that checks the code automatically. The third column is called "Review", here another developer controls the written code (if it is a change of the default state). Reviews are necessary to keep the quality of the work high and to detect mistakes early on.
The fourth column is "UAT" (User Acceptance Tests), where the function of the completed task is manually tested again. Testers do not have to be programmers. The last column is "Done". If all tickets are in this column, the completed work can be reviewed by the whole team and the client. Within the sprints, the development team meets each morning. Here almost every team member compiles his completed work of the previous day and says what he will do on the current day. This helps to assess where the project is and if there are problems.
When using the Kanban procedure, make sure that there are not too many tickets in one column (bottlenecks). The goal is to complete work and not to stay open for too long.
AGILE SOFTWARE DEVELOPMENT
Ideally, the ERP agency should work agile. This means that the teams organize themselves and quickly adapt to possible changes (constant changes). For example, if the sprint detects that there is not enough functionality, it does not work hard, but creates new epics or tickets to implement in the current sprint or the next. In summary: Planning and implementation can be changed at short notice - for better software.
The training of the employees is very important, because they will work later with the ERP - they are therefore a crucial factor in the successful implementation of ERP. The training should start relatively early and best with technically savvy people on the part of the contractor. They can pass on their knowledge to colleagues and thus act as additional trainer. Training can be general in nature and showcase the ERP in its entirety or tailor be to employees and their area. In any case, it is important not to underestimate the training courses and to operate them until the ERP system runs smoothly. For this reason, as described at the beginning, there should be key employees who receive more intensive training and then pass on their knowledge.
TAKEOVER OF ACCURATE BASE DATA
The rollout is the most critical phase in the implementation of the ERP, especially when replacing an existing ERP solution. If the company does not have ERP yet, things are much more relaxed.
BEFORE THE ROLLOUT
Before the actual rollout, there should be at least one test rollout, which is tested with a live dump and (fake) customer data. This ensures that the hardware and software runs safely and there are no unforeseen serious errors.
The rollout is usually done in the evenings, to minimize changes to the base datas and in case of difficulties, to have enough time to fix the bug. Immediately after the rollout, the live test will be used to detect weak points, which will then be fixed promptly. The whole procedure should involve all internal and external team members.
For the ERP implementation is absolutely the risk assessment, so that the responsible persons of the enterprise are aware of the dangers of the ERP implementation.
Which are critical system processes and business processes?
What precautions have to be taken to be able to continue working normally after the rollout fails?
Which areas of the ERP need to be operationally reliable?
Are the time goals realistic until the ERP implementation?
Are there enough resources if the budget is exceeded?
Are the requirements and goals of the new ERP the right one?