by Kurt Goldsmith, SAP Solutions Director, Tata Consultancy Services

If your organization is like most, you have a dedicated I.T. team just for responding to your SAP software’s business user requests for Break-Fix and small enhancements.

In just a moment, I’m going to list for you four aspects of your SAP Change Control process that are going to cause an I.T. approach known as DevOps to head straight for your SAP team.  And, after that, I’ll offer a couple of action items that your team can take now as a way to prep for that eventual arrival.  But, first, is any of this really necessary?

Yes.  It is.  Houston, we have a problem.  An SAP business users’ support problem.  Or, should I say lack of support?

Requests can take weeks or months to navigate through the typical company’s SAP Change Control process.  That is, if the business user hasn’t given up entirely on even asking for help.  Because although SAP software functionality is possibly the best in the world, you will be hard pressed to find one of its end users saying that.  The problem isn’t the software.  The problem is the Change Control process.

I’ve lived it.  I’ve been on those teams.  As a full-time employee.  And/or as an outside consultant.  Here are the four aspects that I promised to list.

1. Your SAP Change Control process probably contains 50+ discreet work steps.
2. Five or more of those 50+ work steps are probably some form of an approval or a sign-off.
3. For some kinds of user requests, only one person knows how to work in that part of your scope.
4. Documentation, if we can find it at all, is warehoused across 500+ individual, inconsistent Word docs that are almost impossible to search across for understanding design element relationships and business logic interdependencies.

Taken together, these four nearly guarantee a change control process with difficult to predict timelines, ambiguous status updates, and multiple bottlenecks.  Time to Market is in weeks.  Or months.

In short, there has been a big, big mistake made by all of us dating back to the 1990’s when we designed these SAP Change Control ideas.  We optimized a path for a SINGLE change request by a single SAP team member.  Not for dozens or hundreds of change requests by a single TEAM.

The impact to your SAP business users in the 2020’s is Death by 1,000 Paper Cuts.  Small, annoying functionality gaps or flaws that the end user learns to live with because the bulkiness of the SAP Change Control process practically forbids a resolution.  Is the gap impacting a mission critical process?  No.  Is there a known workaround?  Yes.  Okay, then.  Move along.  Nothing to see here.

Is that just the way it has to be?  Is it an unavoidable side-effect of SAP software being so complicated?

Well.  Web sites are kind of complicated, too.  Yet, those four issues in the SAP Change Control process do not exist when business users make requests to your I.T. organization’s Web Site team.  THEIR time to market is in days.  OR IN HOURS!  And, because each and every month your web site becomes more important within the overall I.T. landscape, that team’s responsiveness to its business users is going to sooner or later raise one particular question by a VP or a C-Level about the SAP team’s responsiveness:  “Why aren’t you doing what they’re doing?”

Hint:  Your web team is doing DevOps.

Know-How vs. Words

In this article I will offer three specific action steps that an SAP team’s leads can take to get in front of the DevOps train now, to remove the risk that its arrival next (pick one) month / quarter / year runs you over.

This is a positive for SAP teams that is long, (LONG!) overdue.  Because.  True or false?  Are people in your SAP teams overflowing with fond memories of the as-is 50+-step change control process?  Do they feel immense job satisfaction when a business user asks them to add one or two more fields into an existing report, and they have to quote an ETA of six (best case) or 16 (normal case) weeks from today?

No.  They do not.  That is false.

Let’s just not get too hung up on terminology or vocabulary.

Because who cares what we call it!  The name just happens to be “DevOps.”  With a bit of – okay, a lot of – a playbook.  So what?  Those are words.  Words don’t get us faster, higher quality time to market.  Know-How does.  If you are an SAP functionality expert, you almost certainly are also a DevOps expert.  You just don’t realize it yet.  In the next 10 minutes, you and I are going to get that recognition process into motion.

Note:  Although these first three actions could be applicable to either DevOps for SAP projects or DevOps for SAP post-cutover support, our focus today is the latter.  At most organizations, that will be the more likely DevOps for SAP entry point.

Action 1: Four by Two

I have been on dozens of SAP teams.  I feel confident in sharing my observation that most individual team members in the SAP space prepare and update personal work plans.  These are not necessarily broadcast out.  In some cases, the degree of formality is not much more than a bunch of yellow sticky notes all over the desk or computer screen.

If we look real closely, we will notice that each scribbly note tends to represent one To Do task that is in the four hours or less effort range.  And, the collection of scribbles tends to be kind of, sort of organized into current (next two weeks) vs. future (backlog) reminders.

You call that habit.  I call that DevOps.

Except that in DevOps, we publish those scribbly notes.  And, periodically discuss as a team the priority of each.  And, formally attach to each one a status tracker – NOT STARTED vs. IN PROGRESS vs. BLOCKED vs. IN PEER REVIEW vs. DONE.  Inside a formally declared two-week window.

We can refer to this action step as making a limited number of FOUR hours (or less) promises for the next TWO weeks.  Why do this?  The answer is to achieve a reduction in team Work in Progress (WIP).

An individual team member only has so many hours of capacity.  He or she has WIP.  Meanwhile, new requests keep coming.  Often hot (“stop what you’re doing and focus on this one, instead”).  It can become a vicious circle.  A type of black hole where very little escapes out of WIP into the “Live” system.

“We’re working on it.”  “I think we can get to that by next Friday.”  “Yes, it’s on my list.”

How does that help the other people in their organization plan their week?  It does not.

How does that facilitate 1 + 1 = 3 outcomes?  It does not.

How does a good intention stuck in Change Control WIP help our business user?  It does not.

By contrast, there is at this point very strong evidence that the act of formally declaring the 4-hour (or less) discreet To Do tasks that each team member has decided on, and of formally asking each team member to commit to completing a subset of those during the next two weeks, dramatically reduces each team member’s personal WIP inventory.  Call it the power of teams, if you prefer.

It’s just common sense why this is true.  (1) The short deadlines forces everyone to be realistic about what they can reasonably take on.  (2) It reduces the volume of daily phone calls and emails that a person has to respond to regarding status.  (3) When progress is blocked, as long as the entire To Do task is small enough to fit into a 4-hours window, it is typically much easier to know who and what is needed to jump in to unblock it.  (4) Other people on both the SAP team and the business team can more easily keep an eye on when their time is going to be asked for, which helps to avoid delays due to scheduling conflicts.  (5) The formality makes it easier to cross-share tasks and good ideas.

Your team can start now.  With yellow sticky notes on a “Next 2 Weeks” central white board.

Action 2: Define Done

“I know how to do that!”

Well.  I mean.  Hmmm.  Can we talk sports briefly?  Are any of you weekend warriors?  What if you have been having a lot of trouble with your left knee.  You go to the doctor.  You ask for a cortisone injection.  Do you want your medical professional’s first thought to be:  “Hey – I know how to do that!”

No.  You do not.  You want it to be:  “Let’s see what’s causing this problem for your knee.”

The analogy to an SAP department is that the definition of “done” requires more effort than the correct interpretation of a business user’s request.  Unfortunately, the typical SAP Change Control process does not!  If anything, the “I know how to do that” approach is rewarded!  Get it done.  Get it off the aging list!

How about the Death by 1,000 Paper Cuts list?  Isn’t that the one we should most care about?

To my memory, at least 50% of all business user requests to an SAP team are of the “Doctor, do you have any cortisone?” variety.  The request is not yet actionable.  We need to ask some questions.  Do some research.  Discover a diagnosis.

We can time-block those diagnostic tasks into 4-hours (or less) units of work, and then put them into either the current or the ensuing two-week commitment window.  There are no guarantees as to the quality or efficacy of that work.  But, the define “DONE” aspect of DevOps at least gives us a chance.  One, it must be attempted.  Two, it must be peer reviewed.  So, two sets of eyes:  1 + 1 = 3.  Maybe.

There is an additional benefit.  If we can achieve a valid diagnosis, the number of people in the SAP team capable of performing the deployment goes up 10x.  That’s what we want.  Fewer bottlenecks.

Let’s pause one moment to check if we are making progress towards this article’s goal.

I claimed that if you are an SAP functionality expert, then you probably are also a DevOps expert-in-waiting.  Are you starting to see why?  For example, the key trait of an SAP expert is an ability to appreciate lots of smaller pieces coming together in sometimes original ways to form an outcome.  That is EXACTLY what is needed in DevOps.  An ability to appreciate how a whole lot of smaller (4 hours or less) pieces (tasks) can come together to form an outcome.

You are doing it already.  DevOps merely introduces some formality and structure to that, as a way to increase our opportunities to benefit from being in teams.  As a way to improve our likelihood of 1 + 1 = 3.

Your team can start now.  Formally insist on diagnosis – i.e., define “DONE” – as Step # 1 for all new break-fix and enhancement request tickets.  Formal in the sense that agreement is reached on a set of five standard questions such as the examples, below.  And, the answers can be peer reviewed.

• “In which business process is the requestor reporting an unexpected result?”
• “On what date did this start to occur?”
• To more fully compare Good vs. Bad, ask the requestor to identify a recent similar sales order or P.O. or Mfg Order (or etc.) from Prod that ‘worked’ end to end.

Action 3: Fail Fast

I know.  It sounds weird.  But, we are human.  The requestor is human.  The configuration expert is human.  The RICEF developer is human.  Anyone setting up a test case’s master data or transaction data prerequisites in a nonProd system is human.  There will be human errors, misinterpretations, and faulty assumptions.  THAT is not the question.  The question is how fast can we discover where they are!

If we are adding to or subtracting from a currently “Live” SAP scope, then when we are developing our changes in the lower environments, we want discovery via failure.  Fast.

How fast?  Well, how long does an automated test script take to run?

THAT fast.  For a simple reason.  Slower discovery grows WIP.  Faster discovery shrinks WIP.

Easy to say.  Hard to do.  What’s the secret to making this action step useful?

Your teams can start now.

First, good data.  And we know where to get it!  From your “Live” instance!  Your Prod box has the world’s best test data!  All we need to do is get it into your nonProd instances with a refresh from Prod.  Once a year?  Twice a year?  Sorry Basis team, but that needs to get upped.  To at least once a quarter.

Second, as is a recurring theme in DevOps, keep stuff small.  In this case, scope.  Lots of small changes to scope add up to one big change.  Well.  Why not just do the one big change?  Sometimes there is no other option.  But, part of DevOps is looking for those options.  Because, if we are attempting one big change instead of a series of smaller changes, there are a lot more human errors to discover prior to cutover.  It becomes super difficult to fail fast.  And, for the duration it takes us to find all those human errors, there is exactly ZERO benefit occurring for our business users.  Six weeks.  12 weeks.  18 weeks.

BY CONTRAST, suppose that the business users were getting things they asked for every day.  True, not giant things.  Smaller things.  But, if those small improvements occurred daily?

“Death by 1,000 paper cuts.”  DevOps is the flip side of that.  Victory by 1,000 small cures.

How can we know how small a change can be yet still act as a cure?  We ask.  Our business users.

How can we co-exist a larger number of small scope changes with a 55-step SAP Change Control process?  We can’t.  The admin commitment in total across those 55 steps typically exceeds 10 hours of touch time and four weeks of cycle time.

The middle ground is to have a single review and approval for a category of scope changes.  As long as any future change meets the agreed upon parameters for that category, its implementation can be self-approved by passing predefined test cases.  Usually automated.

Summary

I began the article by calling your attention to a prediction that DevOps is coming to your SAP team.

I supported this claim by making an observation about Corporate dynamics. If one department or group – such as a Web team – seems comparable to another – such as an SAP team – then performance differences will sooner or later generate the question:  “Why aren’t you doing what THEY are doing?”

Your web team is doing DevOps.

By comparison, if your SAP team is like most, its members are doing the best they can with a Change Control process that is cumbersome, that offers ambiguous status updates to requestors, and that contains multiple bottlenecks.

In this, my introductory article for you to DevOps for SAP, I intentionally steered clear of rigid vocabulary.  Instead, I opted to offer an opinion that words don’t matter as much as know-how does.  Most people on an SAP team have a lot of know-how.  Know-how that overlaps very well with DevOps.

• 4 by 2: SAP experts already do this informally with yellow sticky notes or similar.
• Define Done: SAP experts already have an ability to see how small pieces form a whole.
• Fail Fast: SAP experts already know small scope changes that fit standard risk profiles.