SAP Change Control Implementation: Measuring ROI – The First 100 Days

[Former Member]

Before launching into this four-part series, let me acknowledge collaboration with Rev-Trac consultants Susan Cannington and Chris Drake, both of whom contribute experience and perspective to this exploration of how to determine an implementation’s ROI.

In my most recent blog post on the RSC Simplifying SAP Change Control Blog, I described four areas where change control managers can gain ROI measurements on their SAP change control implementations. Let's consider why it's crucial to measure ROI. In any industry, if you don’t measure ROI of key initiatives, you won’t know if a project succeeded. You’ll have no ROI measures to help maximize benefit and you won’t be able to show that a project produced as predicted.

One benefit may seem counter-intuitive – research shows that if you calculate ROI before and after a major software implementation, the project will be more successful. No one is sure why but it might come down to: “If you don’t measure it, you don’t manage it.” You can’t extract ROI from an unmanaged system.

To derive ROI, you need to measure against a starting baseline. At RSC, we rarely see a corporation keep detailed problem records so you may have to set a baseline yourself, using personal knowledge of the system ‑ but who is better qualified than you or your team to do so?

The first step: Sit down with your team and decide, before or at some point early in the initial POC or pilot implementation, what issues might lend themselves to meaningful measurement.

Tangible measurements we have seen during Rev-Trac implementations at different organizations can often be phrased as questions. If the answer for you is yes, estimate a count or other metric to use for an ROI baseline:

• Have do-overs and back-outs increased with the complexity of your landscapes? Estimate an average incident count per day, week or month. 
• Have bottlenecks, such as approvals, delayed tasks? By how long? 
• Do manual tasks cost time and delay change progression? Document tasks and count time costs.
• Do you need to bring average time to project completion down? 
• Have transport conflicts increased between parallel teams? Estimate an incident count. 
• Do you hope to see fewer or shorter consultant engagements? 
• Has down-time increased due to system failures, cutover times, etc.? Estimate incident counts or loss of productive time in affected systems. 
• Do you need better business-side support, measured as quicker responses, faster fixes, fewer problems? 

These are just examples. The point is, you can measure, count, or simply estimate a baseline value and use it to assess initial implementation ROI.

The first 100 days are an intuitive first assessment time. Use them to document how the implementation outcome matched up to pre-transition expectations. You can establish that you have satisfied requirements and can identify where further action may be needed.

Next month, look for part II on determining ROI. Hard numbers are essential but intangible benefits can be just as important. We’ll cover process configuration matters that may not be open to hard measurements.