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:
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
8 | |
7 | |
6 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |