Planning For a Smooth Go-Live: Part 3

3. ERP or SAP Process issues

Let me start with a caveat to this section. No matter how good, thorough, experienced, or conscientious a consultant or a core team member is, a project will always experience a few process gaps, and an occasional completely missing process discovered at go-live. Now that the caveat is out of the way, process problems can occur for many reasons: inexperienced consultants, company employees who miss some of the process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, etc.

The bulk of the items causing process problems generally fit into three core areas: 1) design or blueprinting, 2) change management, and 3) testing.

SAP / ERP Design and Blueprinting

Your business has probably developed numerous processes and exceptions over many years. Some of those processes were developed as the need arose and may have inefficiencies. Because of this, a business generally tasks SAP projects with replacing all of those years of collective knowledge and processes, as well as any “broken” processes, in six months to a year. The team may need to complete some larger projects in a couple years.

That is no small task, and a truly successful project needs an experienced consultant. As I have noted in previous articles, underqualified consultants will cost your SAP project and your company big money, as they will struggle to properly replicate knowledge and processes.

In addition, a successful project requires a good blueprint, which should translate your scope into all of the key business processes and their corresponding components. I generally prefer a blueprint that has inputs (or some type of process trigger), the process itself, and then the outputs. A good blueprint should also contain the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and Enhancements), development objects, and the key business areas affected. If the team has enough time during the Blueprint Phase, the blueprint itself should also begin to capture some of the key change management issues.

On the other hand, poor blueprints constantly delay your project and drag it back into “Design” mode when you should be in full project execution. Other integrated teams need to invest unnecessary time and effort, delaying the overall project and burning up budgets.

Worse still, a consultant who struggles to extract the needed information for a good blueprint may create a “smokescreen.” In this scenario, the company, the department, or the key resource on the project who is responsible for that area may inaccurately receive the blame. If a team member is genuinely causing an issue, an experienced consultant should raise this issue during the process when it is encountered–rather than after the blueprint is due.

ERP Project Testing

The team should also address processes during testing. Any integrated application should include at least four primary types of testing. No matter what name is used, those types are generally individual transaction tests (sometimes called “unit tests”), transaction strings or processes within the same module like Sales and Distribution (“module tests”), full-blown cross module tests that test entire process chains from start to finish (true “integration tests”), and then finally tests that involve the wider user community (often called “user acceptance tests” or “day in the life” scripts).

While you should follow the scripts to check off all the boxes, the team also needs to perform additional tests. “Integration tests” and “user acceptance tests” serve as the last opportunity to find and address process gaps. Sadly, some consultants and firms may see this as an opportunity to absolve themselves of responsibility for potential problems or shortcomings. As a result, they may demand that the script be followed to the letter, with no deviation or exception processing allowed.

While the team needs to control the process to ensure that the work is done and the known processes work sufficiently as designed, an additional mechanism needs to address gaps or exceptions. To accommodate this, the team may create a space on the signoff sheet that directly solicits comments about any process gaps and any exception processing that might be needed. Final signoff of the testing should not be completed until this commentary is converted into additional testing scripts or some manual process defined to address the processes.

For final integration testing, you may wish to select random documents from your current business operations to run through the system with the converted data. For example, you could choose ten or more each of the sales orders, purchase orders, production orders, reports, etc. The key is to use something meaningful that can be verified back against your current system.

ERP Project Change Management

Unless you completely redesign and rewrite SAP to have identical processes as before (which defeats the purpose of a packaged system application), you will need to deal with change management issues. And unless you also rewrite the user interface, you will still need to accommodate training and user acceptance.

Change management generally encompasses a few key areas: training, communication, organizational change, process/job changes, and post production support. Every project will need some change management, which your company may handle reasonably well. However, if your company has many employees who have done the same job for a long time with little change, they may need strong guidance to handle even small adjustments.

You will need to assess your own organization and its ability to absorb change, so you can determine how change management resources should be budgeted. From a project perspective, however, you also need to be wary of consultants who want to add new functionality without understanding the impact on the organization.

Case in point: I was at a client where SAP’s Handling Unit Management functionality was the best fit I had ever seen. The client had high-dollar, custom-made steel transportation racks that needed to be inventoried and returned. The packing was consistent and uniform, their production volume was not intense as a sheer number, and they already had wireless bar codes with some warehouse automation. From a functionality standpoint, this solution was almost a “no brainer” and a great ROI on the automated tracking, inventory, and return of the units.

However, a more careful look at the organization showed a very different picture. The staff responsible for maintaining the data and processing the transactions had not been reliable with data maintenance or with processing in the past, and would likely not be in the future. A less experienced consultant with limited project or change management experience would have seen this as a great opportunity. The consultant could keep billing for the new work (a scope change), they would be needed almost indefinitely for production support, and they would have a great candidate to blame for these additional expenses.

Sadly, I’ve seen this scenario played out over and over again– for instance, with SAP’s Customer Service and Solution Database functionality. The company had an “ugly” but mature and working solution. They were downsizing the customer service area, the SD scope for the project was already pretty significant, sales were beginning to slow, portions of the business were being spun off, and employee morale was already low. The consultant convinced them to replace their solution database and customer service functions from a CRM application that they did not even retire. As a result, the company did not even benefit from software license savings. The consultant stayed on, supported an unnecessary process (the legacy app was not going away and worked fine), and was needed for post-production support.

The process-related issues will quickly separate experience from inexperience. There are lots of good consultants, but there are lots of less-than-satisfactory consultants in the market as well. Unfortunately the good consultants are often penalized for smooth and successful go-lives by early roll-offs. Meanwhile, less-skilled consultants are rewarded by extensions so they can support poorly-designed processes and inadequately prepared user communities at go-live. The old adage rings true here: “You get what you pay for.” In the end, less experienced consultants can tax the company with hidden costs, not the least of which is how their SAP implementation approach impacts your business. A truly seasoned consultant may cost a little more up front, but a quality solution can pay dividends for many years.

In essence, a business cannot underestimate the need for careful process understanding. The amount of change your company can absorb, the impact of processes being brought into a package application like SAP, and the cost to your implementation budget should all be considerations.

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(Introduction, Security, and Authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(Master Data, Data Transformation Methods)

Planning For a Smooth SAP Go-Live: Part 3
(Process Issues, Blueprinting, Testing, and Change Management)

Planning For a Smooth SAP Go-Live: Part 4
(Custom Development, Costs, and Consequences of Inexperienced Developers)