This paper offers a way to ensure ERP implementation projects are effective …and cost efficient.

The solution is a departure from current implementation orthodoxy, which has been made complicated by the need to compensate for failing to gather accurate information in the initial phases of the project.

Almost all IT pundits point to upfront discovery and education as the key to implementation success, but to-date no one has shown how to standardize this so that the results are consistent.

Today, the best chance for success is a hand-crafted ERP implementation from an experienced consultant who has spent time in the industry into which the ERP is going, and who can show a good track record.

This paper proposes a way to make the ERP sales and implementation process effective and replicable, an approach with the simplicity of ‘painting by numbers’ that ensures a successful outcome.

It also recognizes that a packaged approach is required to ensure a cost efficient implementation and that like any packaged product its content must be progressively refined based on experience in the field.

The solution has 2 elements:

1. Defining the ERP Implementation as a Process, to aid management of who does what, when.
2. A software platform that supports upfront discovery and education, used throughout the Process.

Executive Summary

ERP implementations have 3 critical fail points that are remedied by Enterprise Process Planning (EPP):

• ERP implementations veer off track from the point that the customer business is not systemically understood. Catering for this failure makes the implementation process unnecessarily complicated.
• Pre and post-sale customer interviews fail to elicit the necessary understanding of the business. The traditional BPR style of questioning lacks the context that enables users to provide accurate answers.
• Lack of customer industry knowledge means ERP implementers cannot validate what they are told.

EPP provides a common visual model of the entire business, so that from the outset – both customer and vendor have the same picture of how the customer business operates, how the processes within the business interoperate, and how user tasks within the processes correspond to the vendor’s ERP functions.

The consequences of having a shared visual model of the customer business defined in EPP are:

1. It is possible to link customer information, ERP functions and training material to individual users in their workplace so that they know what to do to implement and operate every ERP-based task.
2. A standard implementation process can be tailored for each customer to enable project costing, timeline monitoring, directing POC pilots, document collection and in-situ user training.
3. The resulting model of the business can be used for compliance audits, business analysis and Lean improvement …plus facilitate new vendor service opportunities and upgrades to new ERP releases.

When Whaley Foodservice Repairs sued their ERP vendor in 2011, Michael Krigsman, CEO of consulting firm Asuret observed,

When will customers and vendors learn to manage their expectations more thoroughly? The big takeaway here is the absolute importance of defining requirements accurately up front and carefully managing the expectations between the customer and the vendor.

The same comments can be found on the Web for all ERP vendors – time and again.

The problem is particularly onerous for ERP vendors whose products are extremely flexible. Being able to cater for a wide range of customer requirements is counter-productive without an accurate definition of the prospect’s environment.

It would be useful if a prospective customer were to give ERP system vendors a document that showed clearly how their business operates - its structure, processes and resources …all quantified. They don’t.

To address this, ERP vendors ask the prospect questions. The problem is; what questions to ask? Unless the questioning is coming from a consultant with experience in the prospect’s industry the question is a shot in the dark. Like playing Battleships, you know what you hit, but you don’t know what you missed.

To successfully determine the business environment into which their product has to fit, the ERP vendor needs the prospect to volunteer vital information without being prompted by a question.

This requires a method of engaging with the prospect on common terms; using a vocabulary that means the same to both parties and a visual representation of what happens in the business to ensure that both parties are talking about the business’ processes in the same context.

When staff see themselves in a context that they recognize they present information with greater clarity. And since the environment into which the ERP system is going is rarely perfect, the staff can also identify issues that need correction prior to the implementation of the new system.

All companies should have a documented description of their business. Some undertake this before they implement their ERP solution. But for many, achieving this level of understanding has been thought of as too expensive. We propose a packaged solution which makes the process more affordable.

The Solution

Enterprise Process Planning software (EPP) solves the problem. It offers the most effective way to create a blueprint of a company’s business into which ERP functions can be introduced flawlessly.

In this paper, section 3 (the next 6 pages) covers the problem and solution in detail. Section 4 covers the way in which an EPP-enabled implementation works.

We’d welcome you reading this, commenting on it, and letting us know if you share our excitement in it.

ERP implementations exceed budget, are delivered late, do not provide the functions promised, are only partially implemented and in some cases terminated. Plus, implementations cause business disruption.

A symptom is the re-start, in which a project is halted at some point in the implementation process, and re-started. In August 2010 InfoQ reported, 94% of projects are restarted at least once and restarting a project three times is not unusual.

Poor project management often takes the blame despite its success in other sectors. The real reason has plagued computer systems from the beginning and the high incidence of restarts points to it.

The problem is not with the project per see, although it has resulted in implementations being complex; the problem is a basic lack of knowledge about what needs to be done. Hence the restart; people set off on the project without doing their ‘homework’ and realize at some point that based on what they have learned so far they need to restart the project and do things differently.

The Requirements Gathering Process: Broken by design in 1960

Shortly after the computer industry was born the Swing diagram (figure 1) was penned to explain why computer system implementation projects failed. Cartoons of this ilk have an element of tongue-in-cheek, but when it comes to IT implementations, while customers and vendors laugh at the diagram, they also recognize its inherent truth.

The diagram describes the 3 major fail-points of the ERP-requirements gathering process perfectly:

1. The customer must know what they really do
2. The customer must be able to articulate what they really need
3. The vendor must be able to understand what the customer says, and what they require.

While new techniques and technologies to supposedly help the customer and vendor gather requirements more effectively have emerged over the last fifty years, nothing has happened to address the fact that the way user requirements are gathered is flawed.

Let’s look at the breakage-points in greater detail:

1. The customer needs to know what they do.

   At face value, it sounds patronizing to suggest that customers do not know what they do. Of course managers and staff understand what they do as individuals. The issue is that staff rarely know how they fit in the value-chain and each level of management has a poor understanding of what happens under them. Consequently discovery is not comprehensive and is marred by conflicting statements.

2. The customer must be able to articulate what they really need.

   The way a customer expresses what they perceive to be their requirements can be flawed. The way they describe their perception of a solution to a need can cause problems if taken literally, and a good consultant will interpret the solution based on past experience of other customers’ needs. All customer communication comes in a context with which the consultant really needs to be familiar.

3. The vendor must be able to capture what the customer really does, and what they require.

   The lack of standards for the way business people describe a business and what they do means that when they communicate with IT people their words may not convey the picture they are seeing. Staff in different parts of the company may use different words to describe the same thing. Consequently consultants do not gain an accurate picture of what happens in the company or what users require.

The ERP implementation project relies on business people learning about ERP and IT people learning the customer’s business. But the tools to help achieve this have in fact made the problem worse.

The Missing Dimension: Understanding real life

When determining the characteristics of a business system, consultants usually asks 2 types of question: quantitative, How many orders do you process a day?, and procedural, “How do you process orders?” The first is recorded as a table of data; the second is more complex; words alone cannot easily describe the complexities of business process.

The IT industry has from the beginning used logic flow diagrams to describe the actions that a computer program performs. This is a chart of boxes, diamonds and lines designed to represent actions, decisions and flow. The same paradigm is being used for describing what happens inside a business, and this gives rise to a miscommunication problem.

Flow diagrams describe activity in an abstract manner. Words in the boxes may be actions or they may be purely narrative, and as shown in figure 2 decisions can be shown as actions. Two separate boxes may be describing something that happens at the same time. The content of a flow diagram does not show what is happening in real life. Yet currently, flow diagrams are used in the requirements gathering process.

For prospects and vendor consultants that operate under the constraints of this process, specifying and delivering the ERP solution is akin to asking a man to walk through a forest blindfolded.

Once he has bumped into a few trees he opts for a ‘restart’. Returning to square one armed with what he now “knows” he again tries to avoid the trees.

To address this problem the blindfolded man is given the ultimate compendium of how to walk blindfolded through a forest. This comes in the form of a hard to follow and unrealistic Implementation Guide.

Obviously – the real solution would be to remove the blindfold, so everyone could see the “real life” forest in front, and successfully navigate through it with eyes open. This would forgo the need for restarts, complex implementation guides, and the recriminations when the ERP implementation fails. EPP represents the removing of this blindfold.

XSOL EPP has addressed this problem with a predefined model of business, a template of structure, activities, roles and resources that visually enables an organization to define its unique way of doing things.

With XSOL, both ERP consultants and the customer’s management and staff have a common language with which to describe their business, and images that define their process flows in a form that can be directly tied back to their own physical world, rather than a conceptual flowchart model that can be interpreted differently by each person involved.

XSOL EPP identifies the desks or factory workstation at which work is performed. It uses pictures that resonate with the people who do the work. The forklift driver can see his forklift vehicle in the process flow, immediately linking his thoughts back to the real world in which he works.

This is the critical issue. ERP implementation will only happen smoothly if the software fits the way a business already operates. Modest changes in process and procedure can be accommodated. But in any situation where someone’s job has changed the opportunity for error is high. So the goal has to be to fit software to the organization not vice versa.

Understand, Simulate and Activate (USA)

The USA methodology has been around for a while and offers the most pertinent advice for ensuring a successful ERP implementation. However, the challenge for the bulk of the ERP industry has been the effort associated with understanding a customer’s business, and achieving a reciprocal effect on the customer’s staff that are going to be affected by the implementation.

The principles behind USA are simple:

1. Understand: Discover and document what happens in the business through the eyes of the people that are undertaking the work, not what their supervisors and managers think they are doing.
2. Simulate: The group discovery process invariably reveals duplicate or wasted effort, but the Simulate process specifically focuses on configuring operational processes for improved efficiency and proving that the understanding of the operations is correct.
3. Activate: With the previous steps completed the risk of misunderstanding what is to be automated with ERP software is slashed. Having the workforce in the process makes them far more receptive to the changes that are to take place. They understand both the up and down stream implications of the changes and they are armed with greater flexibility in the event of problems arising.

First ensure that the results of a work activity are consistently replicable, then, and only then, automate.

Understanding a customer’s business before automating with an ERP system is critical to the success of the project. However, it is not a straightforward process.

EPP is the user face of ERP

Defining a customer’s business starting with a ‘blank sheet’ is a relatively expensive approach but until now has been seen as the only way to get a reasonably good understanding of what happens inside a business. But as the ERP software market itself showed, a package approach is more cost effective.

XSOL uses EPP to drive down the cost of an implementation. The model structure in EPP contains two significant cost-reducing attributes:

1. Speed of Definition: The model provides a template of interrelated components, this helps steer people through the business definition process quickly, and helps them avoid mistakes;
2. Change: In the model the components of a business are defined only once and then reused if they occur in many parts of the business. This means that making changes is fast and secure.

These attributes allow an ERP vendor to create standard model templates for individual industries, such as manufacturing, that give customers in those industries a ‘warm start’. This approach is usually termed Best Practice, and while it does provide the customer with a valuable starting point there is no reason to believe that the customer cannot improve on this and obtain a better practice.

The challenge for the ERP consultant is to quickly convert the industry template into a description of the customer’s business. The next section describes how this may be achieved using XSOL EPP and USA.

Once a customer’s EPP model is complete it can be used to link in documents and software that relates to a person’s job function - materials that support their role in the implementation and in the live system. This includes access to training videos, implementation instructions, access to the ERP software they use, as well as pictures, diagrams and work instructions that are held in corporate data stores.

This means in an ERP implementation staff can have at their workplace all the information they need to learn their new job and perform it. If there is a change they will be provided with new instructions in situ.

This reduces implementation errors, cuts training time and provides greater flexibility for deployment in the workplace. Staff understand their role and their part in the overall business process that comes from ‘seeing’ themselves at their desk or their machine in the factory, in the EPP model of their business.

Understanding starts day 1

Understanding a customer’s business occurs in two stages - pre- and post-sale. The information gathering process must be seamless between stages, and the information captured pre-sale must be pre-defined.

Information gathered pre-sale should:

1. Be captured in templated documents that steer consultants through questioning and data collection.
2. Provide an accurate picture of the business at a high level and the list of processes that this entails.
3. Identify processes critical to the customer so the vendor can prove a high level of understanding.

4. Identify:

   • Any software modifications - defined in full
   • Key parameter settings identified for customer specific needs
   • Data volumes and other constraints
   • Unusual features and potentially challenging issues
   • Specific unresolved issues and promises
5. Be the basis for the contracted deliverable.

Pre-sale information gathering should come in to two steps:

1. Initial analysis to identify the prospect’s industry, their unique features and key processes to demo.
2. More detailed analysis to define the contracted deliverable or to support a fixed price proposal.

The EPP ERP Implementation process model should cover the pre-sales activity to provide certainty of information capture. The accompanying Industry Best Practice model provides the documents to support the early stage analysis and the framework for storing the information gathered in a form that is readily usable by implementation consultants.

Using the EPP model to give a customer valuable insight into their own business, especially their most critical processes, helps win the customer’s confidence that the vendor can be seen as a trusted advisor.

Gathering a prospect’s process details and presenting this to them in a considered and professional form gives the prospect confidence that their business system needs will actually be met.

Building the perfect implementation

Regardless of when they are undertaken there is a series of process configuration steps that are required to ensure that the ERP implementation is a success.

Since a pre-sale environment is more challenging to control than post-sale, the aim of Stage 1 information capture is primarily to collect whatever is possible and file it in the EPP model in the areas consultants will need to employ it post-sale. In Stage 2, however, following a fixed protocol is important – as follows.

Using a model preconfigured for the customer’s industry a consultant conducts a discovery in four steps. The objective is to modify the model to reflect a customer’s business and then populate it with specific ERP software elements that support the business. The result is a blueprint for implementing ERP.

The steps in Understanding are as follows:

1. Verify with the company’s executive and senior management team that the representation of their business at a high level is accurate, and if not, make modifications and have it signed off.
2. Working with middle level managers responsible for aspects of the business take processes from the high-level model and fit them to the work that people are undertaking in their departments.
3. For each person or team undertaking a particular piece of a process verify and modify their tasks.

By this point the model will accurately reflect what is happening within the business, so all that remains is to replace appropriate tasks with the vendor’s specific ERP software functions.

Provided the model roughly reflects the customer’s industry processes there should be little change at the high-level. The key is to ensure that each process is reasonably self-contained.

At the high-level, describing the company should be like describing the human body. Complexity comes from connections between processes, so, just like a body is easier to connect at the joints, so it is easier to split the definition of a company’s processes at points where intra-process communication is lowest. These points occur with the completion of the use of a document such as a quote, order or invoice.

The difficult part of the discovery process is Step 2, where workflow takes place between people at their desk or machine. The key is to find exceptions to regular flow If this doesn’t happen, what do you do?

Defining what happens at a person’s desk (or machine) is relatively straight forward since the tasks they undertake are confined to their workspace. Again, exceptions to regular workflow need to be defined.