How to Fashion Your SAP Change Control SOP (Standard Operating Procedure) (Part II of IV)

[Former Member]

You undoubtedly have a set of change control processes but some processes deliver better results than others. Your current processes might be managed manually or be semi-automated but either way, they need to be formalized as a standard to deliver good results.

To arrive at a standard set of SOPs begin with your current process set. Examine how they were developed and why they move changes through your system the way they do. Look towards the future when new applications need to merge into your processes, or new mergers and acquisitions bring new mandates and governance requirements. Take such possibilities into account so your SOP design can accommodate them flexibly.

Don’t assume there were good reasons for the status quo. Those who developed your original processes might have lacked experience at change control and set redundant or unneeded approvals, for example. Look closely at each status and ask if it’s truly needed. Does it provide value to the system’s governance and audit trail? If not, it only hinders the process you’re trying to achieve and should be reviewed.

Configuration, Development, and Security Change SOPs

These are the three most common types of change SOP. You might need an additional SOP for Java changes, or for pushing manual changes through the system. Based on current practice, identify the SOPs you will need to change or create new.

That will require a clear understanding of each change landscape. What low-impact or everyday configuration changes have little effect on production stability? They may not require unneeded, resource-intensive approvals. Can your process dynamically identify and downgrade them? What configurations have high impact on production stability, and so need higher approvals or more rigorous testing? Maybe you need more regression testing or more testing phases. Ensure the right stakeholders sign off moving such changes into production.

Your SOP may need to accommodate non-SAP changes in a hybrid operating system. More complex architectures might need additional requirements for development changes. It all depends on the scope of the change - you need to look at the criticality of the intersection points, how one thing may affect everything else.

You‘ll also want to make sure the documentation is suitable to the specific type of change. For example, a low-impact configuration change might need only simple documentation, while a higher impact change needs more extensive documentation.

What about an unusual or unique requirement not part of the SOP? Again, determine how critical it is. Maybe it’s obsolete, something from the past. Find out why it’s there. If you identify it as both unique and necessary, you can fashion a custom change process or find a way to bring it into your SOP so it is not “stand alone.” As emphasized in Part 1 of this series, unique or un-normalized processes create future confusion for new stakeholders who do not understand the need. This can create instabilities.

Your upgraded SOP strategy will need to consider all of these scenarios.