SAP ROI — Enterprise Architecture & Business Solutions

I previously noted I would follow up with a post on doing an SAP implementation for only marginally more than a technical upgrade (see Technical SAP Upgrade or SAP Reimplementation).  In the process there are a few assumptions and several considerations to keep in mind.

If an SAP reimplementation is done well the Total Cost of Ownership can be significantly reduced.  Especially when you keep in mind that getting closer to standard functionality in non-business critical areas, or what I like to refer to as “commodity” processes, makes it easier and less expensive to add additional functionality as business needs arise.

Your IT Department Skills and Qualifications

If you are at the point of an upgrade you have most likely had SAP installed long enough to have developed some level of skill and competence with the software.  Along with this your SAP staff has developed an understanding of your business and the application. 

Over the years you have been on your current SAP version complaints and requests from the business have reached your department and staff.  So you have some insight on where the implementation might need to be corrected.  The business has been using SAP for a few years now so the end users are familiar with the interface and the data entry requirements.

Based on this new insight and the business needs that were not met with the system integrator’s guidance on the original implementation you believe you might be a good candidate for a reimplementation. 

Because of your experience with the system and because the end user exposure for a few years the difference between a technical upgrade and a reimplementation is a modest delta in terms of effort and cost.

You’ve Already Worked Through the Hard Stuff in your Original SAP Implementation

Probably one of the most important considerations to remember in a reimplementation is that the hard decisions around the processes, organizational structures and data types have already been made:

• chart of accounts,
• account posting models
• SD / MM / PP / FI / CO / HR / etc., organization structures,
• SD order types,
• PP order types,
• PO types,
• HR info / activity types,
• material types,
• vendor accounts,
• customer accounts,
• pricing structures,
• reports,
• processes of all kinds,
• form outputs (layouts),
• interfaces,
• reports,
• enhancements,
• etc.

Since the really hard part was done in the original implementation it is more a matter of understanding how to take your SAP implementation to the next level.  These decisions and other gaps discovered after you went live represent the difficult and stressful situations your company has already worked through. 

This incomplete list of setup items from your original project were probably the biggest project stress points and key decision points.  Even after you went live you’ve probably discovered a number of gaps, improvements, or corrections you wanted to make but were tied up by the previous design or limited by your staff’s understanding of how to make those changes in the live environment.

What Would SAP Look Like Had You Known Then What You Know Now?

All of those project decisions might have led to completely different SAP solutions in hindsight.  In other words, by the time you went live and finally got your SAP implementation stabilized there were probably a lot of things you would have done differently.

Related Posts:

• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• Technical SAP Upgrade or SAP Reimplementation
• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
• SAP Implementation Partner or Company Selection Criteria

SAP’s application landscape has the depth and breadth of functionality to handle 90% (and usually more) of nearly any business requirement.  Regardless of this huge depth and breadth of functionality there is still way too much custom coding and redesign of the software (see e.g. SAP Implementation Focus, Software Engineering or Business Process Engineering?).

If you are an SAP shop considering an upgrade it may be time to take a hard look at whether you should do a technical upgrade or a reimplementation.  As you probably know, a technical upgrade means taking what you already have, the good, the bad, and the ugly, and then converting it all, as is, to a new version.  This includes the existing custom coding, processes, system settings, and all of the existing landscape.  If there were poor design decisions from the original implementation, or bad coding substitutions for standard functionality, together with security and authorization design problems then you carry all of that trash forward.

In many cases a reimplementation does not have to be much more expensive than a technical upgrade.

A reimplementation when done correctly, looks at the existing system landscape and evaluates the gaps.  You evaluate where the system could be redesigned to deliver on the original promise of SAP’s ERP application suite.

Considerations for an SAP Reimplementation

After you went live with the implementation, if you have heard lots of comments like:

• “if only we had known X?” or,
• “why didn’t the consultant tell us we could do Y?” or,
• this is too slow, painful, difficult, complicated, etc.,

then you might be a good candidate for a reimplementation.

For example after being live you might discover that the original SAP Organization Structure did not provide you with key information you need for good reporting.  SAP standard LIS and SIS reporting provide you with little value because of this less than optimal organization structure.  You might find that the pricing implementation was less than optimal and has lots of restrictions.  After being live for a while you might discover that your supposed “experienced” consultants didn’t really know about SAP’s capabilities and that all of those pricing or order related processes they told you couldn’t be done are actually possible–, not easy, but can be done with fairly standard functionality.  The reasons why your original implementation was “less than optimal” may be limitless but you have learned a lot since then.

• Maybe there wasn’t enough attention given to how the SD or MM org structures would impact reporting requirements. 
  • Maybe it has too much granularity or too little.  Maybe you needed geographical elements included in the org structure, or maybe product line dimensions, or maybe sales office / sales territory information. 
• Maybe that “experienced” consultant had no clue about your GL Account Determination, or about complex pricing, and maybe they misled you and told you SAP didn’t support what you wanted to do with pricing or accounting because they didn’t have the level of expertise you paid for. 
  • Maybe the SAP “expert’s” design produced way too many pricing conditions, or huge amounts of master data to maintain.
  • Maybe they didn’t consider the live system master data maintenance requirements so the solutions they designed did not even consider the amount of ongoing support that would be needed
  • Maybe the consultants didn’t know how to segment and stratify customers for better sales and pricing processes, etc.
• Is your availability checking terrible or non-existent and you have bad promise dates. 
• Is the backorder processing difficult or non-existent?
• Maybe the SD or MM or PP consultants were completely clueless about Sales and Operations Planning (S&OP) and left you with little or no forecasting and supply planning abilities.
• You might find that your Materials Management (MM) consultant was clueless about MRP or about supply chain planning. 
• Maybe the MM consultant didn’t have the critical experience for a good design around purchasing organizations, purchasing groups, PO pricing, material account determination, etc.
• Maybe your Inter-Company supply processing is painful with full transaction processing for an entire sales and purchasing process when your “expert” never told you there is a simpler way with standard functionality.  Or, you might have to manually do eliminations for Inter-Company clearing but your “consultant” never told you there is standard SAP functionality to do this automatically.
• Maybe your PP consultant told you that you couldn’t do in-process-subcontracting for subassemblies in the production process.  Or, maybe the MM consultant made a mess out of your subcontract process by setting up storage locations or plants to represent the subcontract vendor (rather than using standard SAP subcontract functionality).
• Security authorizations are a mess and nearly everyone has their own “custom” authorization.  It is taking far too long to provision security and there are significant delays in provisioning user roles.

The number of dumb SAP design and implementation scenarios I’ve seen over the years are too numerous to list.  I could go on and on with different examples across the entire application. 

Your SAP Implementation Should Not Have Been So Painful

What it comes down to is your initial implementation was less than optimal.  You paid a FORTUNE for a  bunch of custom hacks rather than using standard SAP functionality, or a lot of functionality gaps for important business functions.  You may have ended up with overly complicated processes and difficult to manage data requirements.  There could be any number of issues or reasons, but let’s just say you’re not too happy with your previous implementation results.

If you’re not too happy with your results you are probably a good candidate for a reimplementation. 

Before you panic, there is a way to do a reimplementation on a reasonable budget, and without the huge pressures and stresses of your original project.  

SAP Technical Upgrade Considerations

If you are very happy with your system, and your user community has seen improvements and efficiency gains with the original implementation you are probably a good candidate for a technical upgrade.  Keep in mind that a technical upgrade is taking exactly what you have, without any significant changes, and then converting the system landscape to a new version.  Regression testing is done to ensure that previous functionality is not broken and that any custom programs still work as desired.

One other consideration for a technical upgrade verses a reimplementation is whether or not you kept the application fairly close to standard.  And by close to standard I do not mean that you didn’t do any user exits or with newer versions make use of any of the enhancement points–, in other words, your “experts” didn’t “invent” new custom-coded applications where a standard solution would work.

Even during a technical upgrade you may be able to make some adjustments and modifications, but they are more like minimal tinkering. 

Conclusions on SAP Upgrade or SAP Re-Implementation

At the end of the day, when you are considering your SAP landscape, the key issue to remember is the application is supposed to support the business and produce business value.  When you consider the huge investment and the impact to the business it is important to get real value from your SAP implementation.  As you prepare for your upgrade, that is the key time to evaluate, or re-evaluate the business drivers for your technology spend and consider what can be done to gain real return on investment.

Related Posts:

• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• Where do you Start with SAP Return on Investment or SAP ROI?

Series Introduction Note:  The next 3 parts of this series contain step by step instructions and pointers on managing the RFP process (Part 2), conducting the vendor selection (Part 3), and then how to use the blueprint process to correct any discrepancies and lay a solid foundation for succes (Part 4). 

If you are an IT decision maker and you’re tired of pressure to achieve results that your system vendors or integrators can’t seem to deliver, use these steps to get the most for your money and achieve breakthrough results. Much of this article can be applied to any major project effort your company undertakes.  While some of the suggestions offered here can seem harsh or difficult from a people management perspective they can make a huge difference in your career prospects, credibility, and any future budget requests. 

Neutralizing the vendor proposal scams, clearing the smoke and looking past the mirrors for your ERP, SAP, or technology project requires a little clarity up front before you start your vendor selection.  It is possible to achieve breakthrough business results using technology and business software systems like SAP if you approach your project with the right perspective. 

That Brown Smelly Stuff they are Selling is NOT Chocolate

Promises, promises, sales scams, smoke, mirrors, and vendor proposals, you’ve heard it all before–, the sales pitches promise you a chocolate pie but all you get is some very expensive, and very smelly, dark brown fertilizer.

What these sales pitches never tell you and never deliver on is the “how” to make all of those chocolate pies.  As former General Electric front man Jack Welch calls it “the secret sauce.”  Sure, they describe some super-special secret sauce, they tell you all about their wonderful “Willy Wonka Chocolate Factory” but they only describe a fictitious place, an imaginary state of being. 

Fairy Tales and Vendor Selection Promises

I’ve been on lots of projects where someone dreams up what I call “mutually exclusive requirements.”  These are things that are completely contradictory, they are the old “either / or” logic gates.  You can have one, or the other, but you can’t have both.  Lots of presentations have the sales person delivering tons of promises that no one can deliver on.

Then reality sets in after you’ve signed the contract and the sales person leaves.  A strange odor begins to permeate the whole project.  But this usually happens very slowly over time so that you go through the “boiling frog” syndrome.  You smell a little here and a little there, but like most people you get used to it and think this is just the way it is.  You dismiss early signs that there may be something wrong, or you chalk it up to isolated incidents.  After you transition to a live environment and it is too late you suddenly realize it was not a chocolate pie you were getting but something else that is brown and smelly. 

When someone on the project has to deliver on the sales person’s promises some members of the vendor selection team are no longer involved in the day to day project delivery of those sales promises–, even if they are they often forget everything that was promised.  They only remember a few of their pet peeves they saw or heard during the presentation.  When the sales person describes lots of what sounds like chocolate you end up with lots of brown smelly stuff that is NOT the chocolate you were promised!

After the sales pitches and the promises what you end up with are blown technology project budgets, blown technology project timelines, and buggy custom-coded solutions for “off the shelf” packaged applications.  Fear not, there ARE things that can be done to reduce these results that are so very common with technology projects.

And even if you are misled by a vendor there are still things that can be done after you start with that vendor to ensure you don’t get taken.

SAP, ERP, and Technology RFP – Getting the Most Out of Your Technology Investment

There are several opportunities in early stages of your SAP, ERP, or other technology project to lay the ground work for genuine breakthrough results.  Along with the breakthrough results these early steps can help to set the tone and foundation for a very successful on time and on budget project.  There is just no reason for companies to continue to get taken by some of the unscrupulous or questionable practices in the technology and IT marketplace.

Even after you have selected your system integrator or implementation vendor you still have several chances to make sure they deliver their very best–, the very best tools, resources, and quality of workmanship.  If you change out questionable consultants early in your project then you will set a clear expectation of the caliber and quality of resources you will accept from your vendor.  Doing this early is the best time before they can do any serious damage.

General Patton once said that “War is Hell!” and business in today’s global economy is WAR!  The question you need to ask yourself is if you are in a war in the marketplace do you want raw recruits who are going to go through boot camp at your company, on your dime?  Or do you want veteran Navy Seals, Marine Snipers, and Airborne Rangers?  Raw recruits are usually cheaper, and that experience from those veterans comes at a cost, but who do you think will give you the best chance of winning the war for marketplace position?

Let me tell you, that Marine Sniper will hit his targets at 1,000 yards, but the raw recruits will not only miss, but in doing so will also give away your position and open you up to attack.  So in the end you decide which is more important.  You decide if it is better to take your chances or to take steps to make sure you’re not paying Navy Seal prices for raw recruits.

There are three key events or timeframes early in the project when you can create the best environment for breakthrough project success.  Two of these areas have no risk and at all and one of them contains a moderate amount of risk.  These three key events are:

1. During business case development, RFP creation, and first pass rough project scoping.
2. The actual vendor selection process, vendor proposal reviews, and system integrator contract.
3. During and at the end of the blueprint process.

These key events contain several ways you can take control of your own business destiny and help to ensure the technology investment you make will move your business forward.

Four Part Series:

Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results

Related Posts:

• Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
• Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
• SAP Reimplementation for Little More Cost than a Technical Upgrade Part 2
• SAP Reimplementation For Little More Cost than a Technical Upgrade Part 1
• SAP Implementation Partner or Company Selection Criteria