Implementing a new ERP system is one of the most risky projects any company can venture into. If the implementation is not successful, it can bring the company to its knees. If it is successful, the benefits can propel the company into the future leaving all competitors behind for the coming 15 years. In this article I describe an Agile based project methodology that minimizes risk and maximises output of the ERP implementation.

by Thomas Terkelsen

Thomas Terkelsen, CEO of Agili Group
is a senior ERP Project Manager
and Dynamics NAV Business Central
Consultant with more than 18 years of
international experience.

When implementing a new ERP system, you need to know where you need to end – if you don’t know where you are going, you cannot plan the journey. If you do know where you are going however, you can work your way backwards and each milestone along the journey will dictate what you need to do in the phase prior to that.

So, when implementing an ERP system, where do we need to end?

Final Goal:
An ERP platform that most effectively supports the future business, employees who understand how to use it, loaded with the right data.

 

An analogy could be a project to build a car that most effectively can drive across the desert. You need a car that technically works, a driver who knows how to operate it and finally the right kind of fuel. If you’ve got those 3 components you are good to go – if you’re missing one, it will not work.

Now, lets try to break down the goal to make it more tangible. We will first focus on the first part of the sentence “An ERP platform that most effectively supports the future business”. Lets further break down the word “business” into smaller parts and call them business requirements. Then the goal can be rephrased: “An ERP platform, that most effectively supports the future business requirements of the business.”

 

Identify the future business requirements:

So, how do we go about identifying the future business requirements? One approach could be to simply ask the business “what do you need”? But usually, this only works at a very high level and rarely captures everything the business needs to do – the devil is in the detail. The best source of inspiration to identify the future business requirements is to look at today’s business processes, and figure out why the employees are doing what they are doing. In most cases, this will cover the majority of the future business requirements. The formal way to go about this, is for the consultant to write a Business Analysis that describes the business as-is today.

The consultant should also discuss with the business about what ideas or visions they have for the future and formulate those ideas in a “Vision Document”. Combining the “as-is” of the Business Analysis with the Vision Document leads to the future business requirements.

Once the Business Analysis (and Vision Document) has been written (and solved by the companies employees), the consultant can start writing a list of all the future business requirements.

Solving the business requirements:

While solving the business requirement, we need a sandbox (test system) of the ERP platform, which can be used to solve that each future business requirement has a future business process (solution) that will work. This very first version of the ERP platform is created by the consultant based on his findings in the Business Analysis and then presented to the super users. This sandbox environment is continuously changed so that in the end it supports all the business requirements.

The moment, the first business requirement has been written down, we can start solving it based on the following approach:

1) The responsibility for solving the business requirements must be assigned to both a consultant and a super user from the company. Eventually, they must both sign off that the business requirement has a solved business process (solution).
2) The consultant presents to the super user his suggestion as to how the business requirement is to be solved. He does this in the sandbox version of the ERP platform, which was setup based on the Business Analysis. (Simultaneously, this functions as training for the super user.)
3) The consultant and super user continues to work on solving the business requirements. Solving a single business requirement could take 5 minutes, but if the business requirement is very complex it could take several days, even weeks, including writing a more detailed description of the business requirements, writing a solution, writing a development specification, doing development and testing the final solution using written test cases. This is an iterative process that can be redone several times for a single complex business requirement.

Once all business requirements have a solved business process and have been signed off by both the consultant and the super user we have an ERP platform that will support the business – we have the car.

Recall again our final goal:

Final Goal: An ERP platform that most effectively supports the future business, employees who understand how to use it loaded with the right data.

Next goals are to make sure all users understand how to operate the new ERP system (drive the car) and that it is loaded with the right data (the right fuel).

Inputs required to solve the business requirements.

So, the very first milestone is for the consultant to produce (write) a Business Analysis. A Business Analysis is a document that describes how the company performs all relevant activities today. It focuses exclusively on how the situation is today, not how we expect it to be in the future (although that of course is very important).

Relevant Business requirements:

Which business requirements should be included in the Business Analysis? All of them or only some of them? The answer is to only include some of them: When implementing a new ERP system, we are removing old IT systems. For example, we will be removing the old accounting system. It is of course important, that when we remove the old accounting system, we have a new ERP system that can support the same business requirements that were supported by the old accounting system. For example, when we remove the old accounting system and therefore the company’s capability to generate invoices, we must make sure that the new system can handle this.

Therefore, the Business Analysis must focus on those business requirements that are currently supported by IT systems that we expect to remove when implementing the new system. (This can also include other systems and databases, such as important Excel sheets, Access Databases, etc.)

Irrelevant Business requirements:

But what business requirements are irrelevant? If for example the company has a separate CRM system and we expect this CRM system to continue unchanged after the implementation of the new ERP system, then there is no need to describe in the Business Analysis how the sales staff uses this. Of course, if the old accounting system imports data from the CRM system then we must make sure the new ERP system can also import this data. Hence, this data import must be addressed in the Business Analysis.

Level of Detail:

A description of a business requirement can be done on a very high level or on a very detailed level. How, for example, should you describe the manufacturing process of a table?

Should you simply write, “The worker then produces a table”, or should you write: “First, the worker walks over to a tray, where all new production orders are put by the manufacturing manager. He picks up a new production order, understands what he needs to produce and then walks over to the inventory to get his materials...” and so on. Similarly, as for the business requirements of being able to report VAT, should you simply write “Finance must reports VAT once a month” or should you write “The company faces many different VAT requirements since they are registered to report VAT in both Germany, England and Sweden. VAT reporting in Sweden can be grouped in to 5 distinct categories, each explained below…”

So, still I have not answered the question of how detailed the description should be. There is no definitive answer to this, but in general, the more unique the business requirement is to the company compared to other companies the more detailed the business requirement must be described since it is unlikely to be “common knowledge”. In addition, the more complex a business requirement seems to be, the more the need to describe it in detail. Level of detail therefore depends on two things: Uniqueness and Complexity.

Outcome:

So, the outcome of this phase is a document, preferably written in as plain and easily read language as possible that describes all the business processes that are going to be replaced by the implementation of the new ERP system.

Once the Business Analysis has been written in the first version by the consultant, it must be send for review to the super users who will then comment and send back for revision. After 2-3 revisions, everyone agrees that the Business Analysis is correct, the milestone has been reached and this phase is finalized. (More about super users further down).

Keep in mind, that the reason we write the Business Analysis is to expand the consultants understanding of the company, so that he can: 1) Set up the first version of the ERP platform, 2) contribute to the list of Business Requirements and 3) help design business processes to support those business requirements. The Business Analysis is not for the employees of the company – they already know how the company works – but they need to read it to confirm that the consultant has understood correctly how the business works. 

VISION ANALYSIS

If the company expects to function radically differently after the implementation compared to today, then a Vision Analysis should be produced formulating the different visions of the future. For example, let’s say that today the company’s warehouse is outsourced. If a main driver for implementing a new ERP system is to move the entire warehouse to an internal location, then this vision needs to be formulated in the Vision Analysis. Another vision could be to stop selling to customers via email/telephone but instead to handle all sales via a web-shop. This must also be formulated in the Vision Analysis.

SANDBOX

Based on the discoveries from the Business Analysis and Vision Analysis, the consultant sets up the first version of the ERP system. This will be used in the coming phase where each business requirement needs to be solved with a business process. More info in the next section.

Such a system is called a "Sandbox" because, this is where we setup/test/play/experiment/educate ourselves before having to face the real world. All this playing and experimentation ends up with a solution (business process) for each of the business requirements.

The consultant (in cooperation with the super users) will now start developing a Business Requirements List, typically organized in Excel. This list will be the main controlling tool for managing the overall progress of the project.

Typically the Excel sheet will have the following columns:
- Name of business requirement.
- Description of business requirement.
- Business process (The solution in the new ERP platform)
- Responsible super user name.
- Responsible consultant name.
- Status (There can be several statuses here, but most important is the status “Solved by both Super user and Consultant”.

Additional columns can be added, such as:

- Deadline.
- Super user knows how to use the system.
- Development needed.
- Remaining staff has been trained.
- Postpone to after Go-Live (indicating that this is a process that can be pushed to after go-live, for example the development of a new web shop that does not exist today).

 

Working on solving a business requirement.

Once a business requirement has been put into the Business Requirements List, the responsible consultant will reach out to the super user to start working on solving the business requirement with a business process.

The initial proposal should come from the consultant, who explains to the super user how he proposes to solve this on the new ERP platform. The super user must deliver detailed knowledge on the goals of the business requirement and judge whether the solution will work for the business. When both the consultant and the super user feel comfortable that they have solved the business requirement, they can set the status to “Solved by super user and consultant” and we now know the new ERP system can support this business requirement. When all business requirements have been “Solved by super user and consultant” (has a business process) we have an ERP platform that can support the business and we are almost ready to go live.

If the Business Analysis has been done very well and in great detail, then the first test version of the ERP system (set up by consultants after the completion of the Business Analysis) can be used with few changes. In this case, it is simply a case of the consultant showing the super user how we propose to solve a business requirement and if the super user is satisfied, the business requirements can be set to “Solved” right away. If the super user is not satisfied and/or if the business requirement is complex, more work must be done. We must think, discuss, propose, test, develop, etc. in order to eventually have a solution for the business requirement. Solving a business requirement can therefore take anywhere between 5 minutes and several weeks.

The responsibility of the consultant, super user and project manager.

The consultant and super user are responsible for solving the business requirement with a business process. In addition, the super user is responsible for ensuring that all the company’s business requirements have been listed in the Business Requirements List. For example, the super user from the sales department is responsible for ensuring that all business requirements related to the sales department are captured in the Business Requirements List. So, when performing his daily tasks, he should continuously ask himself “Do we have this particular business requirement in our list? Oh, we don’t – I will let the consultant know so he can add it to the list”.

The project manager needs to focus on the broader picture and preferably should not be involved with how each business requirement is solved. The responsibility of solving the business requirement is delegated to the consultant and the super user. It is the decision of those two what activities need to be carried out to solve it. Does the business requirements need development? Do we need to write test cases for the business process? Will the business requirement be handled with standard functionality or with development? Is the business requirement pushed to after go-live? The project manager should not be involved in all these decisions – all the project manager should be concerned with is whether all business requirements have been listed and whether they are solved by the consultant and the super user by the agreed to deadline. (Of course it does not hurt if the project manager has an understanding/knowledge of the details of the business requirements but strictly speaking it is not his responsibility).

If, after go-live, a business requirement turns out not to be supported, the consultant and super user who were responsible are to be held accountable. Knowing that they are ultimately accountable will motivate them to make sure the business requirement has a good business process to support it after go-live. It is up to the company’s management to ensure the super users have understood their responsibility.

Supporting documents

From an overview point of view, it is important to organize the business requirements in an excel sheet (or the like) so that there is one central place to get an overview of the progress of the project, but if a business requirement is particularly complex, one or several support documents could be produced, incl. solutions design, development specification, test cases, etc. Ultimately all such documents have one purpose: facilitate the solving of the business requirement by the consultant and super user.

An ERP project is tremendously complex. It poses great potential but also great risk. Therefore, wherever there is an opportunity to reduce this risk without any significant downside, that opportunity must be taken.

The most impactful opportunities to reduce risk lie in postponing parts of the project to after go-live – a staged go-live, or multiple go-lives. The way to judge which parts of the project can be moved to after the first go-live is by the following logic: When we implement a new ERP system, we are simultaneously removing old IT systems from the company. As a bare minimum, we are ripping out the old accounting system. Therefore, as a bare minimum, the new ERP system must be able to support whatever business requirements this old accounting system supported. But what about a new web shop? Lets assume implementing the new ERP platform was partly motivated by the company’s desire to get a web shop and start selling products online – today, they do not have such a web shop.

The initial impulse is probably, that obviously the implementation of this web shop needs to be part of the initial project! But that impulse is probably incorrect. Postponing the go-live of the web shop is a great opportunity to reduce risk – usually, the only downside is that the web shop will go live a bit later, but the upside is potentially huge: avoid risking an ERP implementation that brings the company to its knees. It is much more important to not destroy your current business, than it is to get a new web shop.

From this logic the initial implementation should be what I call a 1-to-1 implementation, only focusing on supporting existing business requirements. Then once the business has stabilized after go-live, the additional projects can be initiated.

SUPER USERS

If you recall, the goal with the implementation was:

Final Goal: An ERP platform that most effectively supports the future business, employees who understand how to use it, loaded with the right data.

So far, we have not discussed how to achieve the second part: “…and employees who understand how to use it.” Some companies think that they can keep their employees isolated from the project until that Monday morning when the new system has been implemented and the users sit down to use it for the first time. This assumption is one of the main reasons why ERP implementations fail. You need to involve the employees of the project for two reasons:

1) They must participate in verifying business processes for each of the business requirements.
2) They must acquire deep knowledge about how the system works before going live.

The way to achieve this is to appoint a team of super users who work on the project along side the consultants. Typically 4-6 super users are appointed, one from each department (Sales, Purchase, Finance, Manufacturing, Warehouse, etc.).

TRAINING THE STAFF

Once all business requirements have been solved by the consultants and the super users, the super users must conduct sessions, training the rest of the staff. This serves 3 purposes:

1) It ensures the rest of the staff understands how to use the system.
2) It motivates the super users to REALLY understand how the system is going to work as training others require you to really understand the topic.
3) It serves as a last safety valve for confirming that the ERP system will be able to support the business requirements once exposed to the rest of the staff.

Data migration is not relevant until a few weeks before going live for mainly two reasons:

1) Data changes all the time. Even master data such as customers, vendors and items change. New customers are added, addresses are changed, etc. So if you migrate any of this data early on in the project, odds are you will have to change it later on creating a lot of noise and repetitive activities.

2) Not until all business requirements have a solution, will we be able to understand the format of the data we need to migrate. For instance, we will not know the content of the field “Payment Terms” on the customer card until we have come up with a solution for managing payment terms and hence cannot effectively import customers until this has been determined.

This same logic applies to items. For example, what will be the BOM’s / Routings in the system? And for vendors, what are going to be the Vendor Posting Groups. Are we going to use 1, 5 or 10 vendor posting groups? We do not know this until the super user and consultant has come up with a solution for this.

During the phase of solving business requirements, however, we do need data in the system, but we don’t need all customers, items and vendor. So what do we need? The answer is, that we need just enough to solve the business requirements. Typically, we need a handful of customer/vendors (maybe 5 of each) and a hand full of items (maybe 30). These customers/vendors/items are created manually by the people working on solving the business requirements.

How can senior management monitor the progress of the project? As opposed to the Agile approach described in this paper, one of the apparently appealing features of a waterfall project methodology like Sure Step is that you get to finalize each phase. This gives senior management an apparently valid way of measuring the progress of the project. For example, if senior management is told, that we have now finalized the design phase, and can see that a design document has been produced, they will feel the project is progressing.

But with an agile approach we do not have the same kind of strict phase structure and therefore senior management must have another way of monitoring the progress of the project.

Since the first step of the implementation is a Business Analysis, one first measure of progress is a written and accepted Business Analysis.

Until this has been finalized, senior management can ask, “How is the Business Analysis coming along? When do you expect it to be done?” The next important milestone is the creation of the Sandbox ERP platform and senior management can ask when that is expected to be finalized. Next is the Business Requirements List – “How are we doing with the Business Requirements List. How many Business requirements have we identified in each department?” And finally, senior management can enquire: “Of all the identified business requirements, how many of those have been solved by the super user and consultant”. You can even have a completion percentage that measures the number of solved business requirements against the non-solved for each department.

Finally, when all business requirements have been solved the questions can be “Do we have a data migration plan in place?” and “Has each super user conducted training for the staff in their departments?”

Now, let me ask you:

1) Do you agree that the end goal of an ERP implementation is “An ERP platform that most effectively supports the future business, employees who understand how to use it, loaded with the right data” ?
2) Do you acknowledge that we do not know the final design of the solution when we start the project and that the design is like to change again and again?
3) Do you agree that implementing a new ERP system comes with significant risk?

If you can answer Yes to those 3 questions, then this is the project methodology you must follow – there is no better alternative. If you compromise with any part (for example expect to keep your employees isolated from the project), then the outcome is unlikely to be what you hope for.  

If, on the other hand you accept these realities and organize your project accordingly, your ERP implementation will be a huge success and benefit you for the next 10-15 years to come.

When it comes to project methodology, there are fundamentally two approaches: The Waterfall approach (Microsoft Surestep for example) and the Agile approach (as described in this paper).

The waterfall methodology (Surestep) originates from the construction industry and works very well when you need to build a house or a bridge, where the goal is very clear from the onset of the project and everything can be executed according to planned. In software development however, the goal is very unclear at project start and nothing goes according to the plan – enter Agile. (SCRUM / Kanban are agile based methodologies).

There are several reasons why a waterfall methodology (such as Surestep) will fail when implementing ERP. Firstly, it only allows the project to be in one phase at a time and you cannot go back. If, during the development phase, you realize you need to change the design, this methodology breaks down.

Secondly, there is no definition of the goal, so in essence we do not know what we are aiming for. People end up completing various more or less random tasks that do not really contribute to moving us closer to the goal and if you ask them why, they will say “Oh, I’m doing this because the plan says so but I really have no clue why.”

A third issues has to do with the “too-many-chefs-in-the-kitchen” syndrome (we need 5 chefs to chop a carrot): Because so many people need to be involved in every little decision nobody really understands what is going on and no-one feels responsible.

I will not go any deeper into this discussion as there are plenty such discussions online. Just google “Waterfall vs. Agile”.

If you are in touch with an IT consultancy pitching to do your ERP implementation and hear/read the phrase ”We use Microsoft Sure Step as our implementation methodology. It’s been developed by Microsoft and used in thousands of implementations. It works fantastically due to the way one phase seamlessly delivers input into the next one”, you might want to think twice.