Will Your ERP Project Succeed Or Fail?

An obvious yet unorthodox method for evaluating the success of your ERP project

3Apr

A majority of the executives we interview about their experiences leading or steering ERP projects note something you yourself may have recognized: there exists some tension between an executive’s need to maintain broad perspectives and the simultaneous need to understand tangible details. So how can a busy executive evaluate the health of their ERP project?

In the same way one gauges the firm’s health based on Return on Investment, Acid Test Ratio, DSO, Turnovers, and other financial indices, an executive can take the pulse of their ERP implementation. This will mean stepping outside the usual feedback loop of project plan updates, UAT percentages of pass or fail, and red versus green headers on status reports. Feedback loops are necessary and valuable, but so is data you can see for yourself. Consider the following to be a health-check of your ERP project in the same way we recently recommended a health check of your general ERP functionality

In this case, you’ll be asking your ERP project managers a question they might not expect. To some, the request will sound banal at first – not the sort of thing that makes for a riveting executive summary. That’s alright. Many good inquiries have unexpected starts.

Ask for the main business process flows diagrams. If the focus is General Ledger, the diagrams should include such processes as entering journals, approving journals, configuration chart of accounts, opening and closing periods. For Receivables it would include applying cash, adjusting invoices, collecting, corresponding. For Payables it would include maintaining supplier records, recording vendor invoices, and paying suppliers.

Consider this deliberately simple Payables flow.   

Like most process flow diagrams, this is somewhat informative, less than surprising, and destined for an electronic shelf. Instead, let’s use it for something excellent.

Next, obtain also a guide of the end-user training curriculum. To keep our example concise, we’ll stick again to Payables.

Subject Area Course Offered Intended Audience
Payables Adding a New Supplier AP Clerk
Payables Updating an Existing Supplier AP Clerk
Payables Obtaining W9 Signatures AP Clerk
Payables Entering Supplier Invoices AP Clerk
Payables Paying Supplier Invoices AP Supervisor

Not bad. Again, a reductive but coherent example. The point of the exercise might already stand out. Either way, continue.

Now gather the end user security Segregation of Duties (SOD) diagram.

Lastly, get the index of User Acceptance Test (UAT) Scenarios

Scenario Actors Expected Result
AP001 Enter a new Supplier Procurement Clerk.

MDM Steward.

Supplier data is entered and pending approval with MDM Steward.
AP002 Approve new supplier record MDM Steward Supplier is available to record invoices and pay
AP003 Update Supplier Address Procurement Clerk MDM Steward Address is updated and supplier is moved to Pending Approval. No payments may be issued to new address until approval.
AP004 Pay Invoices AP Staff Payment process runs, payments issued to suppliers.

Now the work begins. Just a little bit of it. Take twenty to thirty minutes and cross-reference these documents yourself.   

To the extent they were easy to cross reference, your ERP project is well structured, without silos, and positioned for success. Notice even with these simple examples that the little boxes in the process diagram correlate mostly to the courses offered in the training curriculum, to the permissions granted in the SOD diagram, and to the UAT scenarios. So too do the 'Actors' in the former correlate to the swim-lanes in the latter and to their cognates in the other two documents. Intentionally, even in this hypothetical example, they do not exactly cohere. There are processes in the flow diagram that are not being tested in UAT (Approve Invoices for instance). The documents don’t seem to agree about who will be entering supplier invoices. Hopefully it is just a disconnect in terminology between busy team leads on a large project. Definitely, it is an indicator of your project’s health or lack thereof.

The documents in real life will be harder to cross-reference. This is understandable, and the point of the exercise is not to churn out a new document for the electronic bookshelf. Not some Boyce Codd Normal Form super document which synthesizes processes and actors among the QA team, the Trainers, the Business Analysts, and the office of the CISO. You’re too busy for that. 

The point is to gauge how well the documents, and by extension the teams which create them, reconcile. Worst case, the leaders of those four areas will complain, call it wasted time, and question why on Earth you think a business process diagram would have anything to do with a training curriculum. Excellent. If they don’t even get the question, and they sometimes do not, you’ll want to know. And you’ll want to do something about it.

Best case, the structural areas of your ERP will cohere. As a result, your data and processes will appear unified across your enterprise. A fine reason to implement ERP in the first place.

Hong kong

Read next:

Macroeconomic Research At Hang Seng Bank

i