by Kurt Goldsmith, SAP Solutions Director, Tata Consultancy Services This article pair (Parts 1 and 2) is for Project Managers and sponsors who are debating whether to “save” time and money by aiming at good SAP rather than at great SAP for an upcoming implementation, upgrade, optimization, enhancement, or Break-Fix.  In the approximately one hour or less it takes an average reader to get through both articles, 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!)

Introduction

In Part 1, we talked about a great many types of variables that come into or that reside within a business.  They become the context for an SAP project’s initial phases – Discovery, Requirements Gathering, and Blueprinting.  In short, these variables impact an SAP team’s ability to correctly interpret prior to a Cutover the how, when, and why the business users and the software are likely to interact together after the Cutover.  Of course, “correctly interpret” is overly ambiguous.  So, I got specific.  I identified and described five different Categories of interpretation. In Part 2, we focus on the tactics that become possible with those five categories as our target. While there might be requests and “sign-off” from your end-users for 1,000 or more individual functionalities that we want to make available to those end-users, that is only a starting point. The much more important conversations in ERP are the variations that those functionalities must:

• Individually Allow vs. Prevent (“Standards”)
• Collectively Count and Allocate (“Signals”).

The main purpose of ERP software is to help you with the collective requirements of the list of individual requirements.  The interrelationships.  Between.  Among.  Across.  The individual scope items are numerous and can be referred to as Standards.  Those can reduce the variations that you control.  The more powerful variations are those no company can control.  We can merely hope to improve our visibility to these and, perhaps, turn those into a competitive advantage by asking our SAP system to help us with a relatively small number of interrelationships that can be referred to as Signals.  SAP can be near-perfect at that.  And, when those get prioritized, your project becomes easier.  Not harder.  Here’s why and how.

Three Tactics

There is a common misunderstanding that the tactics we need to use when attempting to achieve near-perfect SAP are the same that we use when attempting to achieve merely good SAP – just applied with more rigor and detail.  No.  False.  The tactics differ.  A lot.  In “good”, we prioritize all Must-Haves individually.  In “near-perfect”, we start with only a subset of Must Haves and prioritize their relationships. But, before we go there, it is important to reflect on a typical approach to an SAP project.

• Make a proposal.
• Get funded.
• Assemble a team.
• Divide the team based on Business Process Hierarchy nodes (e.g., Order to Cash, Procure to Pay).
• Each sub-team seeks and itemizes each of “their” business users’ requirements.
• Decide what is “Must Have” vs. “Nice to Have.”
• Get “buy-in” or “sign-off” on the individual requirements in order to lock the scope.
• Build out each individual functionality and unit test.

Whoa!  That’s 60% of your runway.  Gone!  Yet, we are still the figurative million miles away from being in a position to deliver an ERP system.  The point of ERP software such as SAP’s ECC and S/4 is not to enable each of the business users as individuals.  That happens.  But, the main goal is to turn them into a team. I depict one common approach to SAP functionality implementation in Figure 1.  The name for this is Outside-In deployment because it is based on an assumption that the challenges when building out the various in-scope functionalities for an SAP project are similar in nature to the challenges one would face when assembling a complex jigsaw puzzle.  i.e., Step 1 is to reach consensus on the border (the scope list).  And, then, start gathering more and deeper details about each piece so that, over time, the entire collection of pieces becomes a whole.  Note that this approach to SAP is beloved by Project Managers because it has easy to identify status (“So, out of your 132 config items, how many have been unit tested?”).  But, pay a close look at the “Readiness FOR Cutover” vs. the “Available Runway (until Cutover)” ratios.  Not good.  Yes, in theory, as with a jigsaw puzzle, we keep getting closer to “done.”  But, SAP is not at all like a jigsaw game. Figure 1:  The Outside-In Approach to SAP Projects The reason those ratios are really, REALLY problematic is shown in Figure 2.  In a jigsaw, as we assemble more and more pieces into the final solution, the remaining challenge becomes easier and easier.  For an obvious reason: every piece in the puzzle is static.  SCALING IS THEREFORE PREDICTABLE. Figure 2:  Some Types of I.T. Do Have Mostly Static Pieces as in a Jigsaw What I mean by that is shown in Figure 3.  With I.T. such as a Data Warehouse or a Web Site, our scaling challenge when going from 1 end-user to (for example) 5,000 end-users, is clear because the key variable to enable that is just more of what we needed for 1 user.  But, UNLIKE in a jigsaw puzzle, with the ERP app, the pieces are dynamic!  Each end-user has the power to put workload onto the other 4,999 users!  In somewhat unpredictable and uncontrollable ways.  Thus, the more that we assemble the pieces, the HARDER (not easier) it becomes to add additional pieces. ERP user scope produces human – more so than technical – workloads!  As we scale scope, we can’t just add more of what enabled 1 user.  We also have to add something completely different. Figure 3:  ERP’s Scaling Challenge is with the Variables that Impact People Because of this completely different kind of scaling challenge, the correct way to approach ERP functionality deployment is shown in Figure 4.  The “Inside-Out” approach.  And, I will save you the suspense by alerting you in advance that your Project Management Office is not going to be in love with this approach.  But, your end-users sure will.  Because we get the key relationships that limit the User-to-User-to-User dynamics Cutover Ready before working on All Else. “Kurt, do you mean standard SAP or Best Practices?” No.  I do not.  I mean a type of business-specific requirement called Signals.  SAP software is tremendous at helping us introduce that.  But, not straight from the box.  Our choices are going to be at least a bit unique for each company that uses SAP ERP because the kinds of variations that exist at each company are always a bit unique.  No two companies have the exact same Division of Labor challenges. Figure 4:  The Inside-Out Approach to SAP Projects Less effort, not more.  SAP Simplicity, not SAP complexity.  Happy end-users, not frustrated end-users. And, even our Project Managers will come to like it better, eventually.  The reason is depicted in Figure 5.   Keeping in mind that unlike with a jigsaw puzzle, if we attempt to assemble 1,000 or so individual SAP functionalities using an Outside-In approach, then the more pieces we establish, the harder and harder it becomes to keep going.  It creates the illusion of being 60% done when, in fact, the hardest work remains. Figure 5:  The Illusion of being “60% DONE” at the 60% Done Mark

 Standards vs. Signals

Standards:  The Most Common Path to GOOD This is analogous to building a border, first, and then the middle – as is done with a jigsaw puzzle. Collect requirements for, and then build out, the individual parts (e.g., Pricing) of individual in-scope tasks (e.g., Enter a Sales Order).  We can then put combinations of these into flow charts, user procedures, and “scenarios” (30+ step test scripts specific to a set of variables we expect will happen together post-Cutover).  For the end-users, these become their standards.

• Key Point: Almost all the focus is on outcomes of one.  1 pricing run.  1 sales order.  1 scenario.  1 iteration of 1 end-to-end business process.  Often with simulated data rather than with real data.  Where variation, if it occurs at all, is contained within a single iteration.

Signals:  The Suggested Path to NEAR-PERFECT This is analogous to building a core, first, and then outward how and where needed – as is done with Lego. It starts with the premise that the post-Cutover (i.e., real life) for any organization involves timing, volume, and content variations that accumulate in front of, within, between, among, and across business processes.  Over dozens or hundreds of iterations.  Unavoidably.  Due to some kinds of variation being external to the organization and/or otherwise random.  And, therefore, blocking, gaining an awareness of, and/or helping inform a response to these Collective variations are a type of opportunity.  A type of need that SAP software can address much more easily than other kinds of business software can.  Because that’s what ERP software is designed to do.  And, for that reason, when implementing SAP software, these needs are prioritized over individual task standardization and automation needs.  They are prioritized even among themselves in that we start with the Top 10 “must haves” rather than equally and simultaneously with all “must haves”.  For the end-users, these become their signals.

• Key Point: Almost all the focus is on outcomes collectively.  We attempt as much as possible to develop our solution with reference to real volumes of real data.

Easier vs. Harder can be Counterintuitive in SAP In the “Part 1” article, I defined “Perfect”, “Near-Perfect” and “Good” in terms of SAP projects.  The key concept is Cutover Day.  Up until that day, what we have are beliefs and interpretations.  After that day, what we have is reality:  The ultimate Fact-Checker. But, here in “Part 2”, I’m identifying tactics.  For many kinds of business software, tactics that focus on what I described as “Standards” would lead to easier – less work – implementation than the tactics that focus on what I described as “Signals.”  But, as I call your attention to repetitively, ERP software is unique.  A focus on Standards instead of on Signals when trying to implement ERP almost guarantees more (not less) work for your SAP team. And worse (not better) outcomes for your SAP end-users.

Know Your Critical Path

In Figure 6, below, are my statistics based on time spent at 20+ companies (big and small) that use SAP ERP technology.  This is across a dozen different industries.  In my experience, neither the size of the company nor the industry of the business will cause these statistics to change by much. Figure 6:  Standards vs. Signals Business Requirements’ Share of Pre-Build Design Needs It seems to hold universally true that 85% of all the user requirements belong to a category we can refer to as Standards.  But, those 85% only produce 40% of the total design effort.  Now, the good news is that the typical way that project managers and project sponsors ask their SAP teams to perform Discovery / Blueprinting tends to capture a high percent of these kinds of requirements.  But, the bad news is this category’s share of our project’s design challenge is small. If we now consider the Signals category, these usually take up just 15% of the total requirements by raw count.  But, that 15% gives us 60% of our design effort.  And, the bad news is that the typical approach to Discovery / Blueprinting captures just a third of that 60%.  We Can’t Design a Fix for What We Don’t See!

Why This Matters

In your own organization, compared to 5 years or 10 years ago: are your SAP initiatives faster or slower?  Less expensive or more expensive?  More predictable or less predictable?  And, do they yield bigger outcomes or lesser outcomes? Maybe the reason for the unfriendly trend is not the software and not the people we hire to implement the software.  Maybe with ERP software, putting a primary focus on establishing Standards on individual requirements, making that our project planning Building Block, has kind of an unfriendly side-effect on the implementation team. Maybe in the name of “saving” time and money by settling for Good SAP we are forcing our team to take huge guesses on many mandatory design questions.  And, the guessing leads to, unsurprisingly, rework and repetitions during Integration and Acceptance testing that are avoided when we instead aim for achieving what I’m referring to as near-perfect SAP.

Your Least Common Denominator

For purposes of blueprinting, configuring, testing, and deploying a near-perfect SAP implementation, the Business Event is your best choice for building block.  Your least common denominator.  Building block alternatives such as the transaction code.  Org Structure.  Or even a checklist of individual in-scope functionality (automated pricing, the Period-End Closing Cockpit, a Production Order’s Goods Receipt serialization, etc.) are tempting.  But will, inevitably, shift an SAP team’s focus away from what’s SAP’s mechanism.  The thing that it is hardcoded to do most.  Your team will incur rework it could have avoided. WHAT THE (blank) IS A BUSINESS EVENT It is a single occurrence of something that matters.  Example:  the arrival of the 3pm local cutoff for any customer asking for a Next Day delivery guarantee.  Example:  someone in the warehouse discovering that the supplier mislabeled all of the boxes they shipped to us for P.O. # 12345.  Example:  a person in the manufacturing department recording 4 hours of labor to Production Order # 9933772.  But, the most commonly-discussed business event in most SAP systems is Sales Order SAVE. When something that matters occurs, usually more than one person needs to know.  Not necessarily immediately.  Not necessarily everything.  But, something.  And, soon.  Figure 7, below, identifies just a small subset of User-to-database-to-User decision-making handoffs we can trigger in an ERP.  Note that we control data entry of a sales order with Standards, while the SAVE action within that is the Event. Figure 7:  A Subset of Decision Handoffs We Can Ask SAP to Do on Each Sales Order SAVE Event  

OPTION	DECISION HANDOFF
Market Analysis	Are customers responding to a new sales deal or promotion?
Procurement Planning	Which products do we need to buy more of vs. less of?
Credit Line Analysis	Are we okay with our current A/R exposure trend line?
Warehouse Scheduling	Must we stretch outbound capacity limits temporarily in two weeks?
Profit Forecasting	Where are we on or off target for next quarter’s number expectation?

Look at those questions!  Are those linear?  No.  Are those sequential?  No.  Do they fit into a flow chart?  No.  Instead, each downstream decision-maker here evaluates collective data.  From dozens or hundreds or thousands of sales orders.  These “Signals” tell us how well all the different variables – both inside and outside the company – are in synch.  In the hands of a business expert, they lead to Start/Stop/Resume decisions.

Why This Matters

Well, it wouldn’t matter if SAP software functionality had infinite utility.  That would be pretty cool.  Let me know when that version of the package becomes available!  Until that day… The “system” is a number of somewhat interchangeable and finite SAP puzzle pieces.  The risk you take if you choose “Business Requirement” or “in-scope End-User Functionality” as your Least Common Denominator (LCD) is that this incentivizes your implementation team to take a Jigsaw Puzzle approach to the Build and Deploy phase.  In a quest to “make your dates” on all the individual scope items, the team proceeds with full vigor towards trouble.  Towards a status where the runway keeps shrinking while the challenge to make additional progress keeps increasing.  That is not a destination that anyone wants to visit.  All your options become bad – some combination of scope shrink, tech workarounds, or a revised cutover date / budget.

CASE STUDY:  Near-Perfect SAP Is Easier to Achieve than Good SAP

For the next 5 minutes, pretend that YOU are the Project Manager.  The task is an SAP Rollout.  The host is a $7 billion business-to-business distribution company located entirely in the U.S.  Their growth model has been acquisitions of smaller competitors.  Such as.  The one that operates only in the state of New Hampshire that it is now your task to transition off of whatever business systems they use today and onto the parent organization’s SAP systems (ECC, BW, etc.).  The target company’s annual sales revenue is just 1% of the pre-acquisition parent’s.  There is no manufacturing.  It is a Buy in Bulk, Sell in Ones / Twos kind of business.  But, in really high volumes.  To huge numbers of customers.  Mostly via in-person sales reps.  With an expectation of Next Day delivery.  And, quite complicated sales deals, promotions, and government regulations.  Still, as SAP projects go, this one is on the smaller side.  Ready?  Go. If you believe that a focus on the Standards-related business requirements will save time and money, you might consider starting with the parent org’s as-is SAP scope choices as a type of Global Template.  And, next, bring on 4 or 5 different SAP functionality experts – one for each of your Business Process Hierarchy “Level 3” nodes (Order to Cash, Procure to Pay, Record to Report, Analytics, etc.) – to do a Fit-Gap analysis against the target company’s processes.  On completion of that, plus a Review/Approval of the analysis by the project sponsors and stakeholders, you might divide up the Build workload.  Again, probably, by function (OTC, PTP, RTR, etc.).  Meanwhile, an ABAPer or two might be working on data conversion and other WRICEFs programming.  You’ll likely allocate a couple of months’ time for Fit-Gap, Blueprint, and Build, and keep your sponsors informed on progress via weekly status reports.  At some point we get to Integration and User Acceptance testing which, inevitably, feeds a fair number of unexpected outcomes into the Defects Tracker.  Hmmm.  We’re getting kind of close to our promised Cutover Date.  We might have to push some of those defects out into a post-Cutover phase.  We might have to think about some Scope Shrink.  But, all in all, we make it to the finish.  On time!  (about 6 or 7 months).  And, on budget! (somewhere between $500,000 and $750,000). Yes, that will work.  Or, you can do what I did: prioritize the Signals portion of the business requirements. Four months.  Two functionality experts.  No scope shrink.  With a quick ROI (paid for itself by Day 100). WHAT!  HOW!  Were those two SAP resources absolute super stars?  Was Hasso Plattner the PM? As shown in Figure 8, the answer to the mystery simply comes down to basic math:  Addition vs. Multiplication.  Keep in mind that at any given moment each workday, the many different business events occurring inside an organization are simultaneous.  Not a flow chart.  And, each event can incur three kinds of variations – Timing, Volume, and Content.  Two ways.  Sequential.  Collective.  Pretend that an entire Org is just 3 Business Processes with 3 in-scope Events in each process.  If during Build, we make our Standards-related business requirements the primary focus, and we successfully develop in SAP those 9 events from a Standards POV, we have a problem.  There are now 81 possible combinations of variation of unknown business significance aggregately.  As we gain our answers, we almost certainly will have to revisit our choices on how we individually and sequentially set up the 9 events to function. If, instead, we focus on the Signals-related requirements during Build, our chances are much better of setting up the 9 events on the first try in a way that reflects the business users’ preferences on how to deal with various combinations of aggregate variation.  In a very real way, the workload that accumulates onto our SAP team is being generated via addition rather than via multiplication.  Result:  Less work. Figure 8: The dynamic of Multiplication vs. Addition during the Generation of Build/Test/Deploy Workload Multiplication Happens If We Make the Standards-related Requirements our Primary Focus Addition Happens If We Make the Signals-related Requirements our Primary Focus

Next Steps

In this article, we talked about the two kinds of Business Requirements an SAP system can help with:

1. Standards: Prevent variation by controlling and automating individual data entry & display tasks.
2. Signals: Recognize accumulated variation and assist a decision-maker’s response to it.

An example of a Standards-related requirement is: “We must be able to communicate our inventory P.O.’s to our suppliers via EDI.” An example of a Signals-related requirement is:  “We must be able to reconcile once each day our records of Supplier-owned inventory against our supplier’s records.  Because.  If those two do not reconcile, our ATP will begin to make false promises to random customers.” In the first, we seek to eliminate variation each try.  In the second, we seek to measure it aggregately. Why Signals Matter:  The Scaling Challenge The article called out why it is important to our SAP project planning and tactics to distinguish between these two types of requirements.  It is because as we try to enable more than one end-user, the puzzle pieces, themselves, become dynamic.  Not static.  And, it is these interactions among the individual functionalities and the end-users, at volume / collectively across dozens or hundreds of iterations, that produces a scaling challenge that cannot be solved with Standards.  It can only be solved with Signals. Why Signals Matter:  Variation The article noted that the most important forms of variation that impact the day-to-day operations of a business tend to be at least somewhat unpredictable and uncontrollable.  Variations that can impact us both on each try and / or aggregately tend to be in any of three categories.  Time (something occurred earlier or later than expected).  Volume (what occurred had higher or lower quantity than expected).  Content (something arrived at an expected time and volume, but with an unexpected format, type, or values).  By “aggregate”, the article mentioned that the impact of variation(s) can accumulate.  In front of.  In-between.  Among.  Across.  End user work steps and processes.  Whereas Standards can help us to avoid and control variation, we need Signals to measure and allocate the aggregate variations that accumulate so that individual end-users don’t feel compelled to resort to individual responses that when done in an ERP system get converted into massive and somewhat random workloads on other end-users. Bottom Line The article offered a small snippet from a Case Study of an actual ERP project where an attempt to achieve “good” SAP takes more time and money than the author needed to produce “near-perfect” SAP.  But, that was that company.  How about your own?  The software is better than ever.  The number of available SAP functionality experts is wider and deeper than it has ever been.  What are your results?  Compared to 5 or 10 years ago, are your SAP project faster?  Or slower.  Less expensive?  Or more expensive.  Are the project outcomes more predictable on Day 1 of the project?  Or less predictable.  In short, are you being forced to make tradeoffs?  More predictability by taking on a longer timeline.  Shorter timelines by taking on more expense.  Less expense by agreeing to less predictability.  The point of my two articles is to help you to see that these are false alternatives.  It’s not more of one thing we want at the cost of a second thing.  It’s more of all three.  Simultaneously. More speed. More economy. More predictability. If we accept that ERP technology is unique in how we need to approach it.