Last post I discussed formalizing and tuning ROI measurement using a pilot program with ROI data points built into the design, and doing the same during rollout. At this point the set of hard data points you established for ROI measurement can contribute to monitoring your system’s KPIs, or Key Performance Indicators.

Setting up KPIs is a different discussion but, in terms of ROI, using this data in a larger set of system KPIs will be doubly useful as it ensures your ROI measurement won’t slip. With the help of Ken Shields from the RSC Consulting team, these are some examples of possible ROI data that can become KPI data after implementation:

  • Number of Severity 1 emergency changes in a given period before and after implementation
  • Mean time to migrate normal changes from development to production
  • Mean time to migrate emergency changes from development to production, number of emergency incidents, etc.
  • Time by required resource level – senior Basis, SME team members, QA testing team member, release management team, etc.
      (taking into account the additional cost of higher staff levels required before implementation compared to post installation)

Monitoring during and after rollout lets you cite current ROI data on demand. Your ROI data feeds into KPIs and SLAs, enabling you to monitor and measure whole system performance over a period of time. Following standard ALM methodology for continuous process improvement, measure/monitor your change control processes over a period of time utilizing your pre-defined KPIs, analyze the results, make adjustments to improve performance, and repeat.

We still see “big bang” rollouts in simpler environments but phased implementations are increasingly preferred. There are various approaches to phased deployments. A geographically segmented approach rolls out to individual regions, divisions, or departments. Deployment by business unit or by increasingly business-critical landscape might make sense, depending on your organization.

With a phased deployment, the pilot does not set your strategy in stone. You can further tune the implementation during successive phases, which can help avoid problems that might otherwise frustrate your users or overwhelm the technical support staff.

Also, with phased deployment, you can launch a combined program of user education and system remediation. The pilot team super-users mentioned in last month’s post can be invaluable here since they’re already familiar with the planned implementation and can work with your users.

With a gradual approach, you won’t have to browbeat users with overly stringent, inflexible change control policies. Flexibility will let you stay nimble and respond to day-to-day business requests that are ultimately driven by competitive market forces far outside your control. And you demonstrate that your SAP change control strategy can evolve with the business.

Here are some basic points to bear in mind during implementation:

  • Have you monitored ROI data points both during and after implementation?
  • Have you used pilot or early implementation data to “tune” for better ROI?
  • Have you used ROI data points to help continually tune the implementation during a phased deployment?
  • Have you structured your data so it can serve double-duty with SLAs and KPIs when implementation is complete?
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply