How will your ERP work FOR the business?

This article is a continuation of our ERP Pyramid series where we explore the building blocks critical to a successful implementation of an Enterprise Resource Planning (ERP) system. In Chapter 5 we start to Develop (Level 2) the ERP.

Level 2 of the ERP Pyramid is the development or build phase of the ERP. Development of the ERP is a progression of integrating business process & technology to form a unified system.

For the first block of the Development phase, the focus is on how the business will function with the ERP. What will the future processes need to look like for the business and how will those processes be managed?

How mature is the business? 

Prior to defining how the business will work with the ERP, the business needs to take an initial look at the maturity of internal controls, standards, policies, processes and people. These levels of maturity and their baseline in terms of whether they are siloed or more enterprise-capable will impact the success of the ERP and thus define the best implementation plan to enable and later support the ERP. Business functions with siloed (low maturity) levels will require more work to implement than those already at an enterprise level of maturity.

Some examples of low maturity would include: 

• Controls – Quality check points exist, but only for some product lines and only completed sometimes
• Policies – Invoice payment policies on similar services that differ between lines of business - e.g. terms 
• Standards – Employee or customer information that is inconsistent or not shared between business functions
• Processes – Functions such as vendor management that are duplicated across groups but have different activities for staff to follow
• People – Roles or sub departments (such as Accounts Payable) that are duplicated across functions

An improved level of technology maturity will presumably be driven in part by the ERP implementation itself, but all other maturity levels need to be in alignment across the enterprise for Business Readiness (Level 3). This is not easy work, but is needed to simplify the ERP design and increase the adoption of the new/improved business processes.

Business Processes

Ideally the ERP will automate and enforce the processes to be used by the business functions. Automation will require a clear map of what the business process will look like including its variations. Firstly, a business process model of the current state must be made. These process maps or flows will help identify gaps and opportunities for simpler activities, enterprise standards and roles in the ERP system. The process map could be as simple as how a vendor invoice is submitted and queued for Accounts Payable (AP). The current state process map should also define what is needed to start (trigger) the process and how much information (inputs) is required to assign the AP clerk. Other process attributes include:

• Roles – e.g. Who does the assignment and approval
• Metrics – e.g. How long it takes from submission to scheduling
• Associated policies and standards
• Audit control points
• Exception paths
• System data

It is important that “big” processes (those that cross multiple functions) be mapped especially where there are hand-offs or transitions. One example would be Requisition-to-Pay processes where mechanical parts are ordered by one group, received by another and the supplier is paid by Accounts Payable.

SMEs and stakeholders in the processes should be involved in the building of the process or at least its validation. These same people will likely be the “owners” of the future state enabled by the ERP, so they should be involved in these efforts. 

At a simplistic level, the future state processes should include the activities, related business standards or policies, ERP functional requirements, process control points, measurement, roles and enterprise data. Ideally these future state processes are also optimized to remove bottlenecks (think lean) and have ownership.

Process Governance

The ERP with future state processes is an opportunity to ascertain ownership of the process including its results. Even if the process crosses different functional groups, establishing a single business process owner is recommended to measure its effectiveness and efficiency of the results. Establishing ownership also places accountability to educate the workforce expected to perform the process. Process owners will be the go-to source for non-compliance issues, low performance results and improvements. Internal audit or control groups are possible candidates to ensure that processes are being followed, supported, measured and improved. Now is the time to design how processes will be managed after “Go-Live”.

In Chapter 6, we next look at the Technology & Data Integrations for the ERP. 

Allen Miko is a Senior Partner at Chrysylys