Implementing an SAP Change Control Solution would be simple if every enterprise had the same objectives – but they don’t. They may have similar concerns but the tooling decision to address their concerns will have a very large impact on whether objectives are met. This is why it’s so important to start with the big picture and then drill down to specifics.
Some considerations at the change-control level may seem obvious but it’s essential not to ignore them:
- Flexibility: As changes move from development through testing to production, how do established policies or procedures affect progress? Do you use different tiers of authorizations for changes or do they all funnel through a single manager or office? How important is it to be able to modify or change these on the fly? Can you put a value on being able to manage changes quicker, easier or more specifically?
- Current automation: SAP sets its “factory” goal as no more than two full-time employees per shift for shepherding changes through the landscape, but it’s just a rule of thumb. No two companies are the same. Still, automated change control needs fewer staff to shepherd changes, allowing others to work on higher-value activities. If achieving this goal is a requirement – what would be your ROI?
- Required or future automation: Having identified manual steps, you can look at where manual errors have contributed to issues and can define points where automation could help prevent problems. Work out your automation requirements accordingly and the potential value by way of cost savings, error detection improvements or manual task removal.
- Documentation: Incomplete documentation causes more than audit exceptions. It can impede development if, for example, a staff change leaves a new developer scrambling to figure out why something was done. In all but the most straightforward, simple systems, poor documentation can become a very sharp thorn in your side. What is the value of a fast and clean audit or an effective and speedy development handover?
- Compliance: If your industry is highly regulated or publicly traded, poor change and policy enforcement can lead to cascading problems and even legal difficulties for the business side. If you could guarantee compliance to all your regulated processes this would bring peace of mind and reduced risk. To what degree would this be part of your requirements and, once again, what value would be placed on it?
- Visibility: You and your teams need fast, reliable information on process flows, scheduling, and change transport handling, just to pick out three examples. How much digging does it take to identify who requested a change, why and when, and to locate a transport in the process (DEV, QAS, PRD)?
- Process Management: Most organizations with large, complex infrastructures have settled on a ‘multi-lane’ or ‘multi-track’ approach that reflects different priorities for different types of change. Can a change solution allow IT to follow different development, QA, review and approval policies with different types of change?
These questions can help you avoid selecting, or even evaluating a solution that may leave your team unable to respond when unanticipated demands (or opportunities) arise – even though a less capable (or seemingly less expensive) approach might correct a few current pain points. I cannot stress enough the value of getting this right before inviting solution providers to present their solutions. More than once have we been part of an abandoned evaluation due to the evaluation team having not been thorough during the requirements establishment phase.
If you get this part right, you will save evaluation time and will may even eliminate some solution providers early – which will save time and money. And you will be half way towards your ROI justification as well.
Next month, I’ll discuss how to view business-side requirements in the assessment process and how best to do battle with the status quo to meet your goals.