SAP & ERP Business Alignment Answers for IT Leaders

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.

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 marginal 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.

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.

===================

With much of the background laid out, we will look at some of the details on how to perform a reimplementation for only marginally more than a technical upgrade in the next post.

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 Sales and Distribution (SD) Organization design did not provide you with key information you need for sales reporting.  Or you might find out 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 lied to you about SAP’s capabilities and that all of those pricing or order related processes they told you couldn’t be done are actually possible.  The reasons for why your original implementation was, shall we say “less than optimal” to be politically correct here, may be limitless.

• Maybe there wasn’t enough attention given to how the SD or MM org structures would impact reporting requirements. 
  • Maybe the original SD org structure design wasn’t very good.  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 just flat lied to 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 required way too many pricing conditions, or complex maintenance of master data.
• Maybe the “expert” who handled the original SD processes had no idea on how to help you develop marketing or sales programs, or how to segment and stratify customers, etc.
• Maybe your availability checking is terrible or non-existent and you have bad promise dates.  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. 

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 very reasonable budget, and without the huge pressures and stresses of your original project.  We will look at that in detail in our next post.

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.

As long as SAP implementations are driven by the application consultants’ perspective and their limited understanding of your business, the implementation will only reflect their SAP capabilities.  If you want more, then your project focus must become business driven rather than vendor and consultant driven.

Frequently I see or hear SAP consultants, even those who claim to be “Platinum” level consultants who really do not understand the extent of the capabilities of SAP as a business process and systems platform.  Even though these Platinum consultants may have many years of experience with SAP, many of them started out in SAP and have little practical business experience before their SAP careers.

The SAP implementation environment “includes several stakeholders: from the developers of the system, to the vendors, to the consultants, the project team, and the ultimate users. Each one of these holds a certain cultural assumption towards the ERP implementation and use process. Particularly, the developers’ and consultants’ cultural assumptions are embedded in the very roots of the software (the technology) itself.

Molla, A. and Loukis, I. Success and Failure of ERP Technology Transfer: A Framework for Analysing Congruence of Host and System Cultures, working paper pg. 7, 2005 citing Skok, W. & Legge, M. (2001) Evaluating enterprise resource planning systems using an interpretive approach. Proceedings of the 2001 ACM SIGCPR conference on Computer Personnel Research, San Diego, April, pp.189-197.

Business Driven Implementations MUST REPLACE System Integrator Driven Implementations

The dynamic of a consulting vendor driven implementation must give way to a business driven implementation.  Many SAP consultants have never been directly responsible for business activities before their SAP exposure.  Few of them also have had to do ongoing business production support work after going live with SAP so they have little business and user experience to ensure business benefit. 

As the SAP licensee, paying for the implementation, you must ensure that you drive the project to stay focused on business results.

This can only occur by having defined the business reasons and drivers for the implementation and then incorporating them into the Request for Proposal (RFP) process. In this way the expectation is set with a vendor that business needs and business expectations will drive the direction of implementation. 

• Throughout the course of the project periodically revisit the original business drivers for the project. 
• Insist that the system integrator provide status reports which address the details of how each business driver is being addressed.
• Incorporate business driver progress into weekly team lead / consultant status reports, OR at a minimum in monthly steering committee reports.

Requiring the system integrator to constantly address the business drivers helps to reinforce that expectation throughout the project and to the project team.  It also helps to more clearly indentify skilled consultants and resources from those on the project that you may need to replace and request a credit from the system integrator for.  After all, if they:

• sold you on business benefit, 
• proposed on business benefit,
• if business benefit (goals, objectives, etc.) are spelled out for your project,

then it is important for you to enforce that in your contract and in your project.

A correctly developed business case, RFP, project charter, scope document, system integrator contract (which should include credits for underperforming consultants) and other tools will ensure your project achieves the results you expect. All of these tools serve as opportunities to set the expectation with the consultants, and with the business, that this is a business project for business benefit. A properly done RFP will also help ensure that you are getting the best resources for your money from an implementation vendor.  That RFP will also help to ensure you are getting apples to apples proposals and quotes.  A solid contract which defines you as the sole determining party for which consultants are performing, and then credit provisions for non-performance, will help to keep things on track as well.

Barriers to a Successful SAP Project

In 1999 Deloitte Consulting published a piece entitled “ERP’s Second Wave” which identified several barriers to successful SAP implementations. I have added a designation for whether they fall into the “People, Process, or Technology” areas.

Notice that although certain functional barriers may fall within a Process or Technology area that every one of the barriers is either strongly, or completely, influenced by People. You simply cannot ignore the People involved in your project. The level of discipline required with SAP dramatically affects organizational norms directly related to the tolerance for change because of the new processes incorporated throughout the enterprise. Sumner, M. (2000) Risk factors in enterprise-wide/ERP projects. Journal of Information Technology, 15, pp.317-327.

Since implementation vendors like Deloitte are OBVIOUSLY aware of these barriers to success, why do they continue to repeat them?  Worse still, why do customers still allow system integrators to do this?

SAP Project Risks and Risk Mitigation

This list of barriers provides a great starting point for the project risks you may need to address.  Right from the beginning of your project your  RFI and RFP system vendor or system integrator evaluation should include an evaluation of these risks.  And it can’t stop there either.  You must be diligent throughout the project to ensure that your project team is ready and able to address your ongoing project needs from a business perspective.

If you are not willing to force your vendor to replace under-performing consultants then you are implicitly accepting being stolen from.  After all, when you consider the annualized rate you are paying for those consultants, why again do you pay for resources who are unable to deliver?

Be sure to review and evaluate these barriers to success throughout your entire SAP implementation and business project.