ERP Implementations are at risk when existing business processes are not well defined

A quick definition: A business process is a collection of related tasks that are performed in a specific order to produce a result or product. An example of a business process is the addition of a new customer to the ERP system. Adding a new customer may require input from the Credit department, Collections, Inventory Management, Pricing and other business units who have tasks to complete in a defined order before the customer can become active in the ERP and able to order products.

At the start of a new ERP project, the team performing the implementation will need to determine to what extent the new ERP software matches the existing processes used by the business. Typically called a Fit/Gap analysis, this step results in a list of business processes that can be fit into the functionality or features delivered by the ERP packaged versus those processes (gaps) that will require either modification of the ERP system or changes to the existing processes to match the delivered functionality. 

If differences that exist between the as-is (or desired) business processes and the new ERP system are not properly understood and planned for at the beginning of the project then the ERP implementation will either fail completely or fail to deliver the promised benefits. 

The accuracy and completeness of a Fit/Gap analysis is dependent upon the accuracy and completeness of the as-is business processes definitions. An accurate and complete Fit/Gap document (the result) has a direct impact on the ability of the implementation team to create project plans, define requirements and create a list of work to be performed including:

• Configurations in the new system to be completed
• Modifications in the new system to be developed to cover gaps
• 3rd-party products to be implemented to cover gaps

Many ERP implementations run into trouble either completing the Fit/Gap analysis in a timely manner or creating an accurate gap list when the as-is processes are not completely understood.  When the implementation team seeks to understand a task and relate it to the new ERP system, interviews of the users might miss critical information unless all of the variants, inputs and outputs of a process are documented. As an example, pricing for an item to be sold by a wholesaler might normally be derived from the purchase cost of the item plus a standard amount. If there is a circumstance where a customer’s geographic location causes the sale price to be adjusted up or down based upon the distance of the customer from a distribution center and the new ERP system does not handle this scenario, then this is a gap that must be handled. Microsoft Dynamics 365 Enterprise for Finance & Operations will handle the normal pricing method using out of the box features but would require a 3rd-party product or modification to handle the distance derived pricing.  If this variant is a rare circumstance and the pricing processes are not properly documented before the Fit/Gap analysis, then the gap is likely to be missed until final user testing or after the new system is in production.

In an ideal world, the following should be completely documented by the business implementing the new ERP system before the start of the Fit/Gap analysis:

• Well defined scope that documents the subject areas, major modules and high-level processes to be implemented (Accounts Receivable, Warehouse Management, Procurement, etc.)
• List of business processes performed by the current (legacy) systems for each high-level process (Create a new customer, create a new invoice, pick inventory from a warehouse bin, etc.) commonly known as the ‘as-is’ processes. This should include operational as well as governance processes
• List of business processes to be performed in the new ERP system commonly known as the ‘to-be’ processes
• Definition of each as-is process that includes:

1. Event(s) – triggers a task or tasks to be performed as part of a business process
2. Actors – the users or employees that perform tasks for each process and include a process owner (Controller, warehouse manager, etc.)
3. Actions – the steps taken to perform a task
4. Inputs – Data, products or requirements that must be provided or met before starting each task
5. Outputs – the results from each task

Often a business process and its variants are documented or visualized using a flowchart, data flow diagram or other business process modeling tool. Microsoft provides common and industry standard business process flows from the American Productivity and Quality Center (APQC) that are related to the ERP system in a tool in its Lifecycle Services system called the Business Process Modeler. Use of a standardized list of business processes and flows can reduce the total effort required for the Fit/Gap Analysis as well as improve the quality of the resulting Fit/Gap document.

To summarize, for an ERP implementation to be successful, the as-is business processes should be completely understood and documented before a Fit/Gap analysis can be completed. Without an accurate understanding of the gaps, it will be extremely difficult to create a system that correctly handles all of the tasks that the users will need to perform.