by Kurt Goldsmith, SAP Solutions Director, Tata Consultancy Services Taming the complexity in, of, and surrounding your SAP teams’ projects, upgrades, break-fix tickets, and Level of Effort (LOE) estimations has a starting point.  In the pages that follow, I will share with you in writing the same five opportunities that I have shared in person with any who ask me. These are not tools.  There’s nothing to purchase.  Some might say that there is not even a learning curve. The talent within your SAP team is already substantial without tools, templates, et al.  Something is blocking that talent from producing exceptional SAP outcomes.  Let’s remove that blocker.  Your teams’ SAP productivity doubles.  And, thus, so does the value of your SAP system(s) functionality to your users.

The Game

Here is the task at which I claim the productivity can double.  All SAP functionality – big and small – requires three questions prior to implementation.  How much is this potentially going to cost (time, money)?  What net outcome can we expect (benefits minus disruptions)?  How certain are we? Compared to our answers from our past, here is what we want today. (1) “Half.”  (2) “Double.”  (3) “More.” Is it that way at your organization?  Or, has it temporarily plateaued?  If it has plateaued, you may have tried standardizations (e.g., documentation templates, Change Control standard operating procedures, “Fit To Standard” requirements policies, “Model” company references).  And, newer tools (e.g. Jira, Splunk, automated testing).  Even newer business software (e.g., HANA, IBP, Ariba, MDG, etc.). All that.  And, still!  The same SAP headaches and frustrations from 5 or 10 years ago remain mostly unchanged.  Some may have grown because each year the technology choices even on the end-user functionality side become more numerous and more complicated.  Responding to your business users’ needs and requests keeps getting harder.  Not easier.  Why!

The Game Changer

Let’s change the game.  Is your primary I.T. problem really that you don’t have enough software, templates, tools, procedures, standards, and models?  Let’s be honest.  You already have too much of that. Try something else.  How you hunt.  Stop being random.  Go where the gold already is. How?  Make five changes to the assumptions that dictate how your SAP opportunities are searched for, talked about, approved, budgeted, and implemented.  Then watch that liberate the creativity and innovation of the people on your teams.  Their good ideas become actionable.  From eh?  To Yeah! In the next 10 minutes, you and I are going to critique the most commonly “deployed” SAP assumptions.  By critique, I mean expose as invalid.  Yes, your organization might embrace more than these.  And, I hope that you do.  My only point is that five changes, in the era of mass complexity, seem to offer the most payload. By the conclusion, you should be able to know if your organization has not just one – but five – opportunities for SAP gains from decisions on topics other than newer software or tools.  An opportunity for more actionable ideas.  Ideas your teams will use to produce: (1) “Half.”  (2) “Double.”  (3) “More.”

Assumption 1:  Selection and Configuration is How We Implement SAP

The key deployment feature inside an-SAP system is something called Configuration.  This innovation allows non-programmers to give instructions to the pre-written programs and database tables.  When compared to the challenges of attempting to meet an organization’s business users’ requests for task automation with home grown software, the ability to instead just do “Configuration” is a huge accelerator. An accelerator.  Not a How-To.  Even confining our discussion just to deploying SAP business user functionality – i.e., ignoring tasks such as hardware set up and data migration and security – an Implementation, or “build”, requires far more than just a functionality selection and configuration. I call your attention to this important distinction because if the business users select – i.e., see an SAP functionality that they like – it is our job within the SAP Implementation team to also protect the software’s core value driver.  Because, although an ERP system can deliver business value in a variety of ways – as a reporting system, as an individual job role task automation system, as a central data hub – its main value add opportunity is as a system that is told how to react to highly specific business events (e.g., to a P.O. Goods Receipt’s quantity, quality, or timing).  In highly specific status contexts (e.g., 5 sales orders are right at this moment on backorder). We could describe all that as Enterprise. Resource.  Planning. These kinds of EVENT > CONTEXT > RESUME user challenges are the main targets for an ERP system. ERP’s magic is its ability to make each functionality change how it behaves in one part of the business based on an up-to-the-second context from other parts of the business.  No functionality exists as an island! Configuration is easy.  What’s hard is convincing the business users to be clear with the SAP Implementation team on their current vs. desired tradeoffs:  Speed vs. Economy vs. Consistency. An individual functionality can make a task faster or less expensive or less variable under assumptions X, Y, or Z.  Who cares?  What becomes valuable are COMBINATIONS of functionality that make your entire division of labor’s collective response to any particular event faster and less expensive and less variable under assumptions X and Y and Z. How?  As mentioned, your SAP software is great at context.  If you ask it to be. In your organization, are the business SMEs and the SAP team having these conversations?  Continuously?  Is it built into your Project Management templates?  Is it being looked at during weekly status meetings?  Is it a key criterion when evaluating someone’s SAP idea?  Are the Before vs. After division of labor tradeoffs called out in the Scope list?  Measured?  Monitored?  Targeted?  If no, why no?  Is there fear that doing this adds to workload or to uncertainty? I ask because in an SAP small, medium, or big project, if we are doing this, total effort shrinks.  Shrinks!  And, the explanation on why requires us only to remember our Lego experiences as a child.

Assumption 2:  SAP To-Do Tasks Become Static Like a Jigsaw Puzzle’s

How can 1 hour + 1 hour = 4 hours? An SAP team is asked to give an estimate of effort on a proposed project.  Let us say the project is a roll-out of the as-is SAP system to a newly acquired company who is either using their own SAP system or is using a system other than SAP. A task force is sent to ask the target company’s Subject Matter Experts (SMEs) a bunch of questions.  Who, what, when, how, and how often.  The goal is to determine opportunity scope. Next, that scope is chopped up into Function-specific sections (Sales, Mfg, Inventory, HR, Accounting, etc.), and the relevant SAP specialist lead (SD, MM, PP, FI, CO, etc.) is asked to estimate the workload to set up / implement their portion. You, I, and everybody else knows that total effort is in the neighborhood of Y hours. But, magically, when all the individual leads’ estimates get summed, we have 2Y hours. How? This occurs on SAP projects – even those attempting to remain strictly inside the “Best Practices” box – where Selection and Configuration is viewed too literally as the How-To for reaching the targeted benefits.  As if the task list for bringing an SAP system up to Go-Live readiness after the scope decisions have been made is static.  Like a jigsaw puzzle’s.  A known and frozen To-Do list.  Such as:  Document the decisions.  Assemble the edge pieces.  Build.  Test.  Convert or migrate data.  Train the users.  Cutover. But, with an SAP system, your implementation team knows that even “Best Practices” tasks stay dynamic continuously.  Like Lego.  This is because the core, not edge, pieces determine sizing.  And, because the puzzle pieces are in many cases multi-purpose.  Yet, finite, in that if we use piece X for business requirement # 34, now X is no longer available for business requirement # 17.  Which can force us to frequently revisit / reverify subjective user priorities at sometimes random points during the project. As depicted in Figure 1 (next page), the implementation impact from the division of labor demands that are embedded in most SAP functionality is worthy of caution.  This impact is nothing like what we’d face from the static To Do list of a jigsaw puzzle.  Whereas a jigsaw puzzle becomes easier and easier to complete the farther we get, with an SAP system (as with Lego) we are at a serious risk of it becoming harder and harder. Worse, the increasing need for more and more effort occurs when our runway (the days until the promised cutover) is getting smaller and smaller! There are two key reasons for this risk.  (1) As mentioned, no functionality is an island.  The integration of each design decision has a sometimes difficult to predict impact on every other decision that came before it.  (2) Each nuance to an in-scope business requirement that becomes clear only after a design decision had been “finalized” causes a need to revisit both that decision and seemingly unrelated scope decisions. In SAP Talk, this is sometimes expressed as:  “Oh, (blank)!”. Figure 1 shows the degree of implementation difficulty increasing as an SAP project’s remaining days shrink. (Depending on the project’s size, the variable “Y” could represent 10, 25, 50, or 100+ days.) Figure 1—What We Do Not Want That is how an SAP team’s math can become 1 hour + 1 hour = 4 hours.  There is too literal of an embrace of Selection and Configuration as the How-To.  The Lego type challenges of our SAP functionality deployment were either overlooked or incorrectly viewed as the easy tasks.  And, were thus compensated for in the Level of Effort estimation with what is known as buffering. Quite literally:  My Best Guess times two. In the next section, we will look at ways to change that math back to 1 hour + 1 hour = 2 hours.

Assumption 3:  Unit Testing Comes Before Integration Testing

Can two opposite SAP efforts co-exist in parallel? Even an SAP project that is as small of an effort as a Break-Fix ticket is better off if it can be viewed as two efforts in parallel to each other.  One effort being an attempt to isolate whatever we are touching from everything else that is in scope.  The other, an effort to integrate whatever we are touching into everything else that is in scope. While there might be a template on recommended ways to approach the integration task, the ultimate path and outcome in each case are going to be at least in some small way completely original. The temptation is to hope or assume that SAP’s software’s built-in integration functionalities handle the bulk of this second task.  Even with “out of the box” SAP, that assumption usually falls short.  Worse – much worse – is that assuming SAP, itself, handles integration, leads us to view Unit Testing sign-offs prior to Integration Testing even starting as evidence of implementation progress.  Which it is not. The hardest part of making progress is to find the User-to-User handoff logic gaps.  And, the easiest way to do that is to put a small amount of Integration Testing earlier in your project plans than Unit Testing.  Then, the bulk of the Integration Testing after Unit Testing. A 2^nd simple tactic is to name the in-scope SAP user handoffs in your Project Plans as your milestones. Meanwhile, there are Integration parameters.  Have these been called out?  The decisions that your implementation teams will find helpful to their LOE estimates are things such as the examples, below:

• Out of the 50 to 100 “must have” requirements, does consensus exist on the 3 to 5 most important?
• Has agreement emerged on which EVENT(s), including time-based (e.g., end of day) matter most?
• For any given business process, one bottleneck is unavoidable, but do we have two that ping-pong?
• If yes, has consensus formed around one diagnosis on why there are two that ping-pong?
• Other than budget, due date, and scope list, do we all agree on the same Before vs. After criteria?

You also have a Change Control Board (CCB) and/or experienced resources that perform the Enterprise Solution Architect (ESA) role.  Are they being asked to, basically, second guess all other team members’ SAP scope and individual functionality opinions?  If yes, stop.  Doing that hurts – not helps – your functionality team leads prepare LOE estimates.  Ask the CCB / ESA to instead focus on publishing overall value drivers that individual functionality choices can be evaluated against.  Here are some examples:

• Advocate cherry-picked SAP functionality earmarked for the top 3 to 5 of the 50 to 100 must-haves.
• Insist that all data entering the database is real (no workarounds that introduce “harmless” fake data).
• Identify where we need user handoffs better than a Step 1, Step 2, Step n linear flow (e.g., hub-N-spoke).
• How is our A to Z deployed design adaptability? (is change becoming easier or harder).
• How do we keep realistic enough data in the nonProd boxes to enable meaningful user feedback?

There is one very special responsibility that deserves its own section.  We will look at that next.

Assumption 4:  SAP Agnostic Requirements Slow Us Down

“Oh, come on!  EVERYBODY knows what I mean by THAT!” Well.  Not sure about “everybody.”  I am sure about the SAP system.  It doesn’t. This particular point.  I’m not saying that it occurs on every SAP project.  I am only saying that it occurs more than is helpful.  And, that when it does occur, the reason is sometimes due to an odd, subtle team dynamic that might or might not be something that your organization wants someone keeping an eye out for.  I will ask it as a question. When an SAP project team on Day 1 knows that they will be responsible on Days 31, 61, 91, etc., for reporting “progress”, do the team members collectively (without anyone actually saying it) either allow or directly ask the business users to give solutions disguised as requirements?  In an attempt to “increase” speed? Keeping a business requirement or request separated and distinct from the technical functionality choice (the solution) is known as being SAP Agnostic.  In total, it speeds you up.  A lot.  Here’s why. Helpful “Here is what I need.  Meanwhile, the SAP solution you are proposing (pick one) does / doesn’t meet that need.  And, here is why I say that.” Not Helpful “Okay.  So, in the dropdown list of the Order Reason field on the header tab of the VA01 screen, I need to see these 7 values - - ….”. The assumption that convincing an end user to sign-off on an in-scope SAP functionality is the harder part of an SAP implementation, and that identifying the business requirement is the easier task, is backwards. The reason is that when business users become the defacto architects of their own SAP system, …?  Well, what type of impact do you suppose that has on overall quality.  But, there is a much bigger issue.  The ambiguity. SAP is more Lego-like than Jigsaw Puzzle-like.  The more progress we make, the harder it becomes to make additional progress.  Exacerbated by ambiguity!  Any misunderstandings are a much more serious risk to an implementation timeline in an SAP project than, let’s say, the implementation timeline of a Data Warehouse project.  Or, an Office365 global rollout.  Or, a migration to SalesForce.com. Of course, it’s not just pre-baked solution requests that lead to rework and progress blockers.  Just as often, it is direct ambiguity.  For example: “My most important column in my current report is the ‘Top Link’ field.” I am only using “Top Link” as an example of a word that is not an SAP word.  It is not even a business word.  That is a you word.  It is vocabulary that exists only in your organization.  Perhaps “everyone” in your organization knows what it means.  But, the integration portion of an SAP system is hyper-literal.  Even a tiny misinterpretation that gets into the Work-in-Progress functionality choices can trigger a need for enormous rework once discovered.  And, then, when we ask for a delay to the expected cutover date, no one is going to “know what we mean by that.”  Requirements’ clarity matters more than a functionality sign-off does.

Assumption 5:  Staying Near to Standard SAP Speeds Us Up

I could also have titled this: Our Goal is to Implement the Scope List. Yes … and … there is a more important point that is at risk of being ignored. A Scope List of individual job role tasks, reports, and data is important.  But, as we looked at earlier, that is less important than the Event > Context > Resume dynamics that are the primary source of SAP’s power to enhance what an organization’s collection of business participants can achieve each work day. Similarly, we have a need to be very careful with our assumptions about the speed benefits from embracing “Standard” SAP.  I have seen many examples where this battle cry becomes a blocker of, rather than enabler to, good ideas. This is at times also referred to by an even more intimidating word choice:  “Best Practices.” What is harder than protecting standard SAP is protecting the database. I will explain what I mean by that with a simple example.  One that I have seen implemented in many SAP systems.  It is the “harmless” data entry of an inventory goods receipt that never actually happened.  But, which the team felt was unavoidable in order to convince another part of SAP or BW or a 3^rd Party (non-SAP) system to do what a 2^nd end-user has asked for.  And, the deployed SAP functionality is 100% standard SAP. The point:  It is relatively easy for creative, motivated, time-pressured SAP functionality experts to find ways to apply “standard” SAP that cover up a misunderstood or slightly miscommunicated business requirement.  It never speeds up total implementation time.  It always slows you down. How do we know that a requirement has been misunderstood or miscommunicated? The tell-tale sign is fake data in the database.  It is a 99% accurate indicator.  Show me fake data in the SAP database, and I will show you a misunderstood or miscommunicated business requirement. Why does this matter?  Why would small amounts of “harmless” fictitious (sometimes called “dummy”) data, slow us down, even if it proves that a lone business requirement was not quite accurate? Your SAP system is not a jigsaw puzzle.  It is far more similar to a Lego puzzle.  With a hyper-literal Integration of Event > Context > Resume.  Which means that “slightly not real” data in one database table forces us to compensate in one or more additional database tables with extra complexity. In a system where the primary goal is to integrate as many different Job Roles as an ERP does, it is absolutely guaranteed that one misunderstood end user will lead to a second.  And, the second to a third.  We can try to “fix” that with ever-increasing SAP scope.  But, even if this extra scope is “Standard”, all else equal, we get faster Time to Market if we just fix the misunderstanding.

Next Steps

I began the article with a productivity action item that is not a tool.  Where there is nothing to buy. I named five SAP assumptions.  My claim is that these five contribute at most organizations to how SAP opportunities are searched for, talked about, approved, budgeted, and implemented.  And, that if there has been a plateau among your SAP team, business team, Change Control team, Project Management team, and/or Executive Sponsor team in terms of getting better over time (at finding low cost, high reward, less uncertain SAP functionality opportunities), that inherent gaps in those five might be the reason. What if what we have assumed are the hardest SAP tasks are instead the easiest? If yes, then in the body of my article, I offered my own Lessons Learned on which SAP assumptions seem to lead teams to better and more actionable ideas, based on 25 years of implementing, merging, optimizing, upgrading, and break-fixing dozens of companies’ SAP systems across a myriad of industries and business objectives.  In short, as more likely to give us what both we and they want in terms of improvement over time in SAP implementation costs, benefits, and certainty: (1) “Half.”  (2) “Double.”  (3) “More.” We could summarize my list of five as this:

• To solve an as-is vs. to-be resource tradeoff, we must talk in terms of events, not of tasks.
• More than with any other type of software, SAP implementation challenges are Lego-like.
• Integration testing offers the best evidence of progress. (so do it sooner!)
• SAP Agnostic user requirements bring faster outcomes than Functionality Sign-Offs do.

Real data in the database is more valuable than Standard SAP functionality options are.