Near-Perfect SAP Is Easier to Achieve than Good SAP Is: Part 1

Near-Perfect SAP Is Easier to Achieve than Good SAP Is: Part 1

Reading time: 13 mins

Meet the Experts

by Kurt Goldsmith, SAP Solutions Director, Tata Consultancy Services

“Kurt!  This client can’t afford perfection!”

Sometimes this is also spoken as: “Let us not allow perfection to become the enemy of the good.”

My comment here is not that either statement is wrong.  Only that a wider perspective belongs.

This article is for Project Managers and sponsors that set out to “save” time and money by aiming at good SAP rather than at great SAP.  In one hour or less, I want to enable you to do three things.

Action Item # 1

Redefine your understanding of Great = Hard while Good = Easier.  Because an SAP Project might be the one exception on earth where Good = Hard while Great = Easier.  We can refer to it as Near-Perfect SAP.

Action Item # 2

Explain three key tactical differences when aiming for Good vs. Near-Perfect SAP achievement.

Action Item # 3

I would like you to be open-minded to the next person, group, or team who asks permission to aim their SAP Project at achieving Near-Perfect, while still supplying the extra time and money that they’d ordinarily ask for merely to accomplish Good.  (more time and money than they’ll need = fun!)


I normally aim my How-To articles at a non-technical audience in small enough bites that the content can be appreciated in 15 minutes or less.  Today’s topic is bigger.  But, I want to respect your time.  I will therefore divide the guidance into two halves.

Part 1 focuses on defining my two classifications.  What criteria am I using when I distinguish “Good” from “Near-Perfect” SAP?

Part 2 identifies the three main reasons why … and I’m fully aware that what I’m about to write seems counterintuitive, if not outright impossible … Near-Perfect SAP is easier to achieve than Good SAP is.

Aiming for “SAP Perfection” does not mean aiming for flawless.  Nor does it mean aiming for Standard or Best Practices.  It only means accepting that SAP is finite.  With a degree of interchangeable pieces.  And, that it has to function as an ERP because, well, that’s what it is.

The software is better than ever.  The number of available SAP Functionality experts is the widest and highest it has ever been.  And, yet.  Compared to years past, Projects are slower?  Less predictable?  Yield less?  And, post-Cutover, our deployed scope invites future break-fix and enhancement requests that continuously add – not remove – complexity.  Maybe we should re-verify a couple of assumptions.  Maybe there are a small number of key misinterpretations of what is means to implement SAP, at all.  My opinion on that starts now.

Cutover Day:  The Ultimate Fact-Checker

The people on your Business and SAP teams are skilled, motivated, and optimistic.

If you have a project where in spite of that every single one of them holds their breath on Cutover Day, please read this section of my article twice!

Oh, we worked so hard.

  • We broke out into logical teams (Order-to-Cash, Procure-to-Pay, Accounting, etc.).
  • We really, really, really asked our business users what they want and need the software to do.
  • We built out the individual functionalities and unit tested.
  • We put everything into 1,000 discrete Word docs, PowerPoints, Excel sheets, and Visio diagrams.
  • We combined the individual functionalities into “Business Process” strings, and ran tests.
  • Unexpected test outcomes went into a trusted Defect Tracker with due dates and owner names.
  • We’re getting pretty close to Cutover now, so let’s have User Acceptance testing.
  • More unexpected outcomes.
  • More entries into the Defect Tracker.
  • Maybe some scope-shrink. Maybe some “Can you live with this until Phase 2” bargaining.
  • Maybe a proverbial 150-pounds of super-complex “Z” programming no one understands.
  • Finally! Made it!  Everybody agrees to Go-LIVE!

Well.  Okay.  Hold your breath.  See Figure 1.  On the left side of the yellow bar are our interpretations.  On the right side of the yellow bar is a sometimes-unfriendly fact-checker.  Seemingly more and more, even though our Projects take longer and longer, the gap between Cutover Day interpretations and reality is growing!  Not shrinking!  What if I told you that the reason for this paradox is that we are aiming for Good SAP rather than for Near-Perfect SAP, and that Near-Perfect SAP takes less time – is easier to do than Good SAP is.  Would you keep reading?

Figure 1:  Uh oh.  It’s Cutover Day!


Perfect, Near-Perfect, Good

Now that we have our mind on Cutover Day, it is quite easy to define what I mean by “Near-Perfect” vs. “Good” SAP.  I’m referring to how well we understood pre-Cutover how, when, and why the business users and the software were going to interact together post-Cutover.

While looking at Figure 2, below, let us imagine three possible post-Cutover outcomes.

  • Perfect: Our pre-Cutover interpretations matched reality 100%.
  • Near-Perfect: Not 100%, but no big misses.
  • Good: Possibly some big misses, including maybe some that are going to kind of remain baked into the delivered SAP design for a long time, but “it works.”  Nowhere near a crisis.

Figure 2:  Perfect, Near-Perfect, and Good Refer to How Prepared We Are for Cutover Day

It’s the “how, when, and why” part of my definition that I want to call your attention to.  We all know that if six months AFTER a cutover we could time-travel back to the project’s kickoff date BEFORE the cutover while retaining all of our post-Cutover knowledge, we’d be able to implement that exact same project with dramatically less time and effort.  And, even if no one cares about the time and effort – everyone surely cares that we’d implement much better business outcomes for our end-users, too!

We all know this.  Yet, there is resistance to aiming for it.  Which I fully understand.  There is an assumption that the software, itself, is so tremendous that it’s “not worth” all the extra effort to achieve my hypothetical “go to the future and then walk back in time” level of understanding about how, when, and why the business users and the software will interact post-Cutover.  This assumption is half-correct – yes, the software is tremendous.  But, the level of preparedness I’m referring to when compared to the alternative is not extra effort.  It’s less effort.  I refer to levels as Categories.  There are five.

 Category 1: Individual Functionality as a One-Off

In a different article (“Part 2”), I offer explanations for why the tactics behind a project that aims for Good vs. Near-Perfect differ, and why the tactics we need to use for Near-Perfect are – although it is counterintuitive – actually easier on your implementation team due to the unavoidable nature of an ERP software package than are the tactics we need to use for Good.

But, for now, for this article (“Part 1”), let us ignore the question of tactics.  Let us instead focus on Cutover Day.  On preparing for it.  On achieving a 100% match between our interpretations on how, when, and why the business users and the software are going to interact together post-Cutover.

Allow me to offer an opinion that there are 5 categories of interpretation.  What’s more important than the count, however, is the awareness that all 5 involve assumptions about variation.  This is not a software thing.  This is a business reality.  Information Technology cannot bring us into an alternate universe.  But, it can make the one we’re in easier to deal with … if … we ask the right questions.  If we develop at least some base level understanding of what the variation Cause and Effect relationships are.

As shown in Figure 3, the Category 1 variations are limited to data types.  They act as context for each in-scope SAP functionality as a one-off.  This means that if we want a functionality such as automated Sales Order Pricing, then we also need to know from the business users each variable and variable combination under which that one-off functionality is to behave at least in some small way uniquely.

Example: Is our Sales Order Pricing functioning as requested with each in-scope Sales Order Type?  Source?  Customer Type?  Product Type?  Wonderful.  How about with each in-scope combination of Order Type + Source + Customer Type + Product Type?

Figure 3:  The Context for Individual Functionality Scope are our Data Variations


Category 2: Individual Functionality in Combination

Our next progression of variation understanding is still limited to data types.  But, now the question becomes slightly more difficult.  Instead of looking at how our various in-scope combinations of Data Type variations interact with a single (“one-off”) SAP functionality, we now look at how those same combinations of variables impact a single outcome.  Such as the creation of one Sales Order.

In other words, if we are confident in each individual functionality within a sales order (Pricing and ATP and Credit Control and Shipping Point Determination and etc.), we then need to ask:  Do any of those react to an in-scope variable or an in-scope combination of variables in a way that brings a negative side-effect onto one or more of the other functionalities that comprise a single outcome?

Figure 4:  The Context for Combinations of Functionality Scope is one Outcome (e.g., one Sales Order)

We can now talk about the one really important take-away that I am trying to communicate with my Two-Part article.  It is the key to your success with an ERP software such as SAP’s ECC and S/4 packages.  It is so important that I’m going to give it its own paragraph!

The act of proving that your in-scope functionality achieves Category 1’s expected responses to in-scope variation does not prove that it achieves Category 2’s.  Etc, et al. (2 does not prove 3’s, and 3 does not prove 4’s, and 4 does not prove 5’s).  Meanwhile, our potential benefits have the inverse relationship in that achieving 5’s expected responses is more valuable to your business users post-Cutover than achieving 4’s, and so on. Given this, what if I told you that when an SAP project manager or project sponsor aims at Good rather than at Near-Perfect, the bulk of your available SAP experts’ time and money will be spent on 1, 2, and 3!  And, almost none on 4 and 5.  Would you keep reading?

Category 3: Combination Outcome in Strings

As represented in Figure 5, as soon as we start to bundle a set of logically-related outcomes into a single iteration (i.e., a string), we now have to account for also a 2nd class of variation:  The Event.

  • Timing: Something occurred earlier or later than expected.
  • Volume: Something that occurred had higher or lower quantity than expected.
  • Content: What occurred arrived with unexpected format, type, or values.

The questions that the SAP implementation team needs answers from the business team on relate to a single instance of a single string.  For example, a single Procure-to-Pay iteration.

  • What kinds of timing, volume, and content variations are unavoidable?
  • How likely are they to occur, both individually and in combination?
  • What is the impact on other business users when these occur?
  • How, if at all, do those answers change depending on the DATA variations?

Uh, that’s only HALF the challenge, though.

Maybe the harder challenge faced by the SAP implementation team is shown in red font in the diagram.  It is an unavoidable reality of trying to connect diverse Job Roles via a single database.  ERP software is a double-edge sword, in that sense.  The tech features that bring the biggest benefit possibilities also introduce the biggest risk possibilities.  They are twins.  Inseparable.  Automated good … and bad!

  • How far in the String do our choices allow an unexpected DATA variation to propagate?
  • How far in the String do our choices allow an unexpected SINGLE EVENT variation to propagate?

Ugh!  The farther a variation can propagate, the more its potential for harm magnifies!

Figure 5:  The Context for Combinations of Outcome Scope is one String (e.g., one Procure-to-Pay)

Category 4: String Combinations at Volume

Time for a breather.  And, to think!  Some people believe that implementing an SAP system is easy!  I mean, all those functionalities are just sitting there in the base package, right?  Someone else already did all the programming!  The screens and the layouts and the database tables.  What the heck is the dang problem – just pick out the ones we need and go convert some data!  Offer some end-user training!  And, then, go “LIVE”.

Well.  I admit.  It would be nice if implementing SAP functionality for end-users in a way that helps more than it hurts was as easy as asking the chefs in a kitchen to produce winning outcomes based on how a set of diners articulated their preferences ordering food off of a restaurant menu.

Alas, most of the variables on a restaurant menu are short-lived in that if they occur at all (“Can I substitute asparagus for the French fries?”), the answer is Yes or No, and we’re done.  By comparison, most of the variables in an SAP system are ongoing in that once we make our choice that choice is now permanently exposed to other variables!  Some of which we can control.  And, some of which we cannot.  And, this brings us to Category 4.

As represented in Figure 6, although one iteration (one “String”) of a business process operates as a discreet set of fixed work steps, the collective usually does not.  On any given moment of any given work day, a business process such as Procure-to-Pay might have dozens, hundreds, or even thousands of iterations started but not completed.  If there are 10 discreet work stations in place to enable the A to Z of that business process, the workload can be distributed amongst those 10 in any number of ways.  Variation can accumulate in-between work steps at random.  In what ways do the business users want or need to interact with their SAP system in order to recover back to a Steady State status?

Figure 6:  The Context for one String at Volume are Bottlenecks (e.g., all in-flight Procure-to-Pay)


Category 5: Business Processes at Volume in Combination

Software such as SAP’s ECC and S/4 are referred to as ERP applications.  The “E” stands for Enterprise.  And, this brings us to Category 5.  As represented in Figure 7, the organization as a whole has to absorb quite a lot of variations.  Both DATA- and EVENT-related.

Figure 7:  The Context for Business Processes at Volume is an Ongoing Concern (i.e., the Enterprise)

I raised a point earlier that I will repeat here in a slightly different way.  Suppose that I could guarantee for you an SAP implementation where each in-scope functionality perfectly achieved in a “One-Off” manner the business users’ requests … but … did less well at achieving the “One Outcome” requirements?

I’m confident that you’d not be in favor of that result.  You’d not want me to aim for that.

The point of an ERP package is to allow the business users to achieve desired ENTERPRISE outcomes in spite of unavoidable variation between, among, in front of, and that (generally speaking) are impacting the individual parts of the enterprise.  But, if you are assuming that by giving your SAP team extremely clear specifications (sometimes called “Requirements”) about which individual functionalities are to be in-scope and on how the end-users are to interact with those individual functionalities, and that this AND THIS ALONE leads to what I’m depicting in Figure 7 as Enterprise net benefits, then I have a question.  If I told you that that assumption is invalid, would you keep reading?

Next Steps

In this first article (“Part 1”) of Near-Perfect SAP is Easier to Achieve than Good SAP is, I introduced a concept related to an SAP project’s Cutover Day.  In this concept, Cutover Day acts as a Fact Checker.  It tells us how well we interpreted pre-Cutover how, when, and why the business users and the software were going to interact together post-Cutover.

I then distinguished for you 5 levels, or Categories, of that kind of pre-Cutover interpretation.

The key point is that the Categories are somewhat independent.  Your requirements for what I presented in this article as Category 1 challenges do not fully “roll up” into the Category 2 challenges.  And, the requirements for the Category 2 challenges do not fully “roll up” into the Category 3 challenges.  Etc.  Each of the 5 Categories has its own challenges!

Among authors, there is an expression: “There is no such thing as good writing, only good editing.”

Among business software implementation practitioners, it would be quite fair to offer a similar expression: “There is no such thing as good software, only good specifications.”

Best Practices and Standard SAP only get us so far.  They help.  They are a great starting point.  They are unable to be, by themselves, the ending point.  If you want consistently predictable Category 4 (“Business Process Resource Management”) and 5 (“Enterprise”) benefits, then you have to give to your SAP implementation team Category 4 and 5 requirements.  You have to go beyond just Category 1, 2, and 3 requirements, plus the proverbial 150 pounds of hope.  Plus a due date.  Plus a budget.  Plus a Weekly Status Report.

If that is all you provide to your team, then your Category 4 and 5 outcomes are going to be somewhat random. The by-product (symptoms) from that randomness will sooner or later be reported after the Cutover as Category 1, 2, or 3 break-fix. The support team will “fix” the symptoms by adding unnecessary tech scope which, yes, makes the end-user happier but which also clutters the deployed scope and, therefore, harms the I.T. team’s ability to respond to future change requests. In short, your SAP system gets on a one-way ride to Gordian Knotsville.

“Come on, Kurt!  This client can’t afford perfection!”

What if I told you that Near-Perfect SAP was easier to achieve than Good SAP is? Less work. Less cost. Less uncertainty. Would you read Part 2 of this Lessons Learned series?


More Resources

See All Related Content