ROI Data and SAP Change Control Configuration

[Former Member]

Last month’s post showed how, with some planning, you can  establish a baseline to help you extract hard ROI data for any major IT  project, our focus being on change control of course. With a baseline, you can compare “before” data with what you gather after the first 100 days or so and there’s your ROI.

With hard ROI data, you can show  that a project did indeed deliver as expected – and back it up. Most  chief executives complain that IT projects don’t provide dependable ROI data. When you do provide it, you’ll find that your later projects are  that much easier to gain approval for because management is confident  you know how to deliver on your promises.

For the second post of our ROI series, let’s look at before and after process configuration issues that may not be obvious or even open to direct measurement, and  how they can affect a project’s “real” ROI. Intangible benefits or connections can be as important as hard data results, but harder to  identify.

For an extreme example, let’s say one of your ROI values was user satisfaction and the hard data baseline you established was the number of user inquiries about work in progress (addressing slow  response) or user complaints about how requested changes were delivered  (addressing QA issues or user buy-in). In this case, you can improve your ROI data by providing more timely change delivery or by inviting requester buy-in during the QA phase, when problems are most effectively resolved. You can also improve this ROI data metric by simply  automating a wider range of FYI notification emails to ensure everyone  is well informed each step of the way. Keep in mind too that you can change the user interaction process to make it harder for users to make  queries, request changes or register complaints and this see  improvements too. Good for the numbers but not really an accurate data  point.

Either approach will shrink the number of inquiries or complaints from users and give you solid ROI data to report when asked, but clearly the intangible value of user satisfaction is actually only  enhanced by improving the process, not by raising barriers against user  input.

Disconnects can always occur between what you thought you measured and the intangible benefit or value you sought as your goal. In change control, how you configure your project can make all the difference to how well your hard data actually reflects what you want to  measure.

I cited an obvious “user inquiry” example in order to prove the point, but there are more subtle ways to miss the mark while  still showing good hard data results. For example, an improved economy may contribute to fewer rejected credit transactions in a retail operation but if you just tightened approval processes to eliminate  problems – how do you then interpret hard data showing that fewer  transactions were rejected?

You need to keep a sharp eye on how  you configure your change control automation processes for each new project to keep from accidentally stacking the deck to deliver the data you want, rather than configuring it to meet the objectives you set for  the project.

Next month, look for part three of this series on determining ROI. We’ll cover pilot group enforcement and how it can affect your project ROI.