Process Design – Sometimes You Start at the End (Part I of IV)

[Former Member]

All processes lead to an outcome. Some processes we develop ourselves (what needs to happen to get everyone out the door in the morning). Others we learn and must adhere to (like driving on a freeway). Some can be flexible, others are rigid.

SAP change control is a process. A poor automated process is still a poor process. Still, it’s okay to start with an imperfect process as a starting point. From there, you can polish the steps, then document it to provide the auditability and competitive advantage you’re looking for.

Gathering requirements lies at the heart of any process design effort. Requirements might include compliance (ITIL/SOX/FDA, etc.), seasonal variations, regional needs and more. We have literally seen hundreds and hundreds of organization's SAP change control processes and can quite safely say that no two are the same. Therefore, it is very likely your unique system and context will need some unique processes, but the design goal should be simple, repeatable processes that you can adapt easily to most of your environments. Methodology (Scrum, Agile, Waterfall) matters but they share a basic commonality that processes can use. Think of making dinner: First you might make a salad, then prepare the main course, then dessert. You organize many independent steps. Do you need it in 10 minutes? You’ll adapt your methodologies but probably use the same building blocks (food groups, pots, utensils, etc.), adjusted to the new circumstances.

In IT, the key question becomes - what do your various procedures have in common? One way to find out is to reverse-engineer the result, noting and using the commonalities.

Another question: Who will lead the team effort? It is crucial to have an administrator experienced at setting up processes, because your team needs to spot commonalities they can adopt across multiple environments. It’s a KISS (Keep It Simple Stanley) problem, and finding the best path to the goal takes experience.

You’ll need to be ready to document your processes for analysis and enforcement purposes. Key players in this phase include business and technical staff, testers, and compliance managers. Training, compliance and release strategies all get much easier once you all agree on the process design.

Proper change control will help you apply change faster, with fewer problems and without risk to the productive environment. To stay nimble in today’s fast moving business environment, an SAP change control technology must have flexibility. When you need to change a process, you can’t wait 3 months and spend $50K. And sometimes an emergency fix can’t wait for extended testing or over-complicated procedures. That’s when your simple-as-possible process pays off.

Over the next few months, as we delve into process design, we’ll explore:

1. How to fashion the needed SOP (Standard Operating Procedure), including how to automate and test it and how to handle unique requirements that occur occasionally but may not be part of the SOP
2. Why you need a CAB (Change Advisory Board) and who should be on it
3. Top success factors in the deploy phase of process design

Process design is a big topic and certainly one worth investigating before you start your SAP HANA projects, so if you’d like me to explore a particular area, feel free to comment and I’ll work it into my series!