SAP ROI — Enterprise Architecture & Business Solutions

Part of the frustration with the failure of results in SAP implementations is the “hangover” from the Y2K effect.  At that time businesses everywhere simply wanted to install ERP systems to take care of the looming potential “crisis” over the millennial changeover.  The real promise of SAP was lost in the Y2K chaos.  After Y2K, the brief downturn in demand for ERP systems along with the tech bubble burst in the stock market created additional pressure.  The idea of delivering SAP implementations “better, faster, and cheaper” together with business benefit was lost in the confusion.  

Because so many custom systems had been developed from the era when disk space and memory were incredibly expensive, nearly all programs were written with 2 digit designations for the year.  The fear was that as we approached the year 2000, those same systems might read that date as 1900, have a different day of the week assigned, or not know how to handle the 2 digit date at all.  As a result there was a massive rush to implement ERP systems to manage this issue and to replace legacy systems with “off the shelf” software.  

ERP and SAP, Better, Faster, Cheaper but What About Business Benefit and Business Focus?

Leading up to Y2K the demand for replacement of these legacy systems with new ERP systems was so strong it lead to an almost exclusive focus on implementing SAP projects “better, faster, and cheaper.”  Certainly this is not a bad thing, but business alignment and business drivers got lost in the fog of technical system replacements.  Rather than doing system implementations that were focused on genuine business drivers nearly all ERP systems were installed as technical system replacements rather than being implemented for business benefit.

After Y2K, there was a continued emphasis by vendors and companies everywhere to implement and automate current business processes because that is the sales model (and competency) they had developed.  That sales model worked, presentations, approaches, methodologies, implementation tools, consulting training and prep, everything was centered around the Y2K “get it in” model. Projects focused only on existing business operations and on replacing existing IT systems.  Implementation methodologies and techniques for “better, faster, cheaper” implementations were developed to support these “quick hit” IT system replacements.

While every project should be delivered on time and on budget, the focus on only current business processes fails to address the forward looking nature of business.  Even to this day businesses implementing SAP still fail to see the system as any other kind of a capital asset where you build a business case with both a current state justification and a future state justification as well.  The current state is nothing more than the “on time, on budget” back office operational project requirements while the future state looks at business strategy and builds those into the application as well.  What do you want SAP to help you with in the future?

ERP Technicians Replace Systems – Consultants Use ERP to Transform Business

SAP projects fail to deliver for a number of reasons that have nothing to do with the software itself.  SAP projects that focus almost exclusively on “back office” processes or “operational excellence” find that they use lagging indicators.  These are important for evaluating current company health, and today’s (or yesterday’s, last months, etc.) indicators of marketplace performance, but these lagging indicators will not produce world class results most C-level executives are now looking for from SAP. [FN1] 

Today the marketplace still wants the “better, faster, cheaper” model of delivery, but now CEOs, CIOs, and CFOs are insisting that the application software must do more.  It must deliver something more meaningful. It must deliver strategy and forward looking business benefit.

Leading or Lagging Indicators? 

SAP projects, whether they are new implementations, upgrades, or re-implementations should begin with strategy, goals, and KPIs. In developing goals, KPIs (Key Performance Indicators) and performance metrics there are generally two types of measurement categories–, leading indicators and lagging indicators.  Leading and lagging indicators refer to “timing of cash flows within a corporation.”  [FN2] 

In the past, lagging and leading indicators have been applied almost exclusively to economic output, not necessarily to that of business, but the impact of business on economies. 

Recently, with the rise of the use of KPIs as a method to help drive business goals and strategy, the idea of leading and lagging indicators has been applied to business. In the context of economics, Wikipedia defines these indicators as:

Lagging Indicator  

A lagging indicator is an economic indicator that reacts slowly to economic changes, and therefore has little predictive value. Generally these types of indicators follow an event; they are historical in nature. For example, in a performance measuring system, profit earned by a business is a lagging indicator as it reflects a historical performance; similarly, improved customer satisfaction is the result of initiatives taken in the past. [FN3]

Leading Indicator 

[L]eading indicators are key economic variables… used to predict a new phase of the business cycle. A leading indicator is one that changes before the economy does. [FN4]

The Future of SAP – Strategic Implementation 

To finally realize business benefit from SAP, to achieve that elusive ROI and begin to make a difference in the way your company works, you must change the way you approach your implementation.  [FN5]

The Y2K days of any consultant who could learn to make system settings on the fly to support all those implementations are over.  With them, the thousands upon thousands of application “technicians” who got their start in SAP when the demand was so high may not be able to deliver in today’s tremendously competitive market. After all, now that the Y2K scare is long past, businesses everywhere are beginning to ask the really important questions of “how do we make this huge investment actually provide a return?”

The type of vendor and consultant you employ must have business and application experience.  Today more than ever it is critical to ensure you find the right resources and then do some up front planning and prep work yourself. 

Long before your implementation or upgrade project starts the implementation focus must change. 

While it is great to focus on process improvement, and that is critical in today’s market, it is no longer enough to win in today’s marketplace.  All of your competitors are working process improvement so it will not differentiate you in today’s market.  Does that mean you can ignore it?  Of course not, it still has to be done, but it must be done together with a serious strategy focus to your SAP implementation or upgrade.

Start by looking out at your competitive landscape, where are your company’s strengths and weaknesses in comparison to your competitors?  Are there areas in comparison to them that you are not executing particularly well?  Should you then focus on those processes to improve your competitive position?  In the areas you are doing well against your competition, should you emphasize those?  Are there market opportunities you are missing, or are there gaps in your product portfolio that partnering with another firm might help to fill the gap in?  Is your company large enough that you can change the vendor dynamic for certain key products or services by outright purchasing, or possibly underwriting new competitive vendors to ensure better products and services at better prices?

How do you use SAP to enable all of these processes you’ve just answered these questions to?  How do you develop the key goals and KPIs to meet the new market challenges out there in today’s competitive landscape?  What SAP reports or tools will be needed to support your leading indicators?  What KPIs should you focus on first?

There are many more mountains of additional things you can do to use SAP to achieve genuine business benefit, find that “elusive” ROI and make a real difference in the marketplace.  But to get there take the first step to changing your implementation approach–, start by defining the business reason for your implementation or upgrade before you even begin. [FN6]

[FN1]  Using SAP to improve Revenue and Profitability
http://www.r3now.com/using-sap-to-improve-revenue-and-profitability

[FN2] Bloomberg Glossary, http://www.bloomberg.com/invest//glossary/bfglosl.htm (retrieved 9/21/2009)

[FN3] Wikipedia, http://en.wikipedia.org/wiki/Lagging_indicator (retrieved 9/21/2009)

[FN4] Wikipedia, http://en.wikipedia.org/wiki/Leading_indicator (retrieved 9/21/2009)

[FN5] SAP as a Change Enabler
http://www.r3now.com/sap-as-a-change-enabler

[FN6]  Change How You Look at SAP to create ROI
http://www.r3now.com/change-how-you-look-at-sap-to-create-roi

Related Posts:

• Using SAP to Improve Revenue and Profitability
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• Where do you Start with SAP Return on Investment or SAP ROI?

I’ve learned many lessons over the years after participating in many ROI focused projects–, a few of them achieved great results, but unfortunately many more were mediocre.  I’m going to begin a series of articles and “how – to’s” on achieving value and ROI from an SAP implementation. 

For many years there has been a lot of literature, guidance, case studies, success stories and methods for using SAP to automate processes and reduce costs.  Unfortunately there is little to help a company achieve revenue and profitability increases using SAP.  This site explores ways of using SAP to improve revenue and profitability as well as achieving process efficiencies and cost reductions.   

We have to get beyond TCO, or a pure cost focus and start looking at ROI, or what you actually expect SAP to help you do in your business.  What actionable information or operational helps are you expecting from the system?

TCO, Cost Reduction, and the SAP Business Case

Reducing implementation costs, process costs, transactional costs, operational costs, or other cost-based ROI measures is an important part of the business case for implementing ERP systems like SAP.  But it is only one side of the implementation coin.  It seems to be the only side of the coin that most SAP implementations ever realize.  The way to change this is by beginning your SAP project right from the beginning with a value-oriented and benefits-focused approach.  With that as the starting point you can then incorporate that mindset into the project right from the beginning; you can develop project success criteria for your SAP implementation or upgrade that will drive those results, and transform your enterprise or organization.

There are plenty of companies and literature from vendors who promote TCO (total cost of ownership) models, and claim to be able to help you leverage your SAP implementation to realize a reduction in TCO.  Rather than adding another voice to the “easy” area of finding ways to measure cost reductions in processes, operational efficiencies, and other cost-based measurements, it’s time to focus on using SAP for channeling organizational efforts into winning in the marketplace.  Avoiding the focus on operational cost reductions, cost-based ROI or TCO does not mean they aren’t important, only that this is not new ground and not necessary for me to add my voice to the loud chorus singing today.

The New ROI Focus for an SAP Implementation 

By focusing only on cost-based ROI measures businesses rarely realize the real promise and value of enterprise applications like SAP.  The real strength of SAP is to transform the enterprise by providing new ways to look at, analyze, evaluate, and then strategize in the marketplace.  Without your SAP project focusing heavily on the value-based business drivers for the SAP project justification, it will become little more than another IT system.  Sadly over the years I’ve seen too many SAP implementations become little more than another IT transaction system.  

Where do you start?  Change your thinking! 

SAP Project Thinking Must Focus on the Business and the Future

Focus on how to perform a successful SAP value-based project, with real ROI value realization, no matter what type of partner or implementation method you choose.  To do this your IT and SAP project thinking has to change.  And the change in thinking, or the paradigm shift, requires the implementation mindset to focus on how to use SAP technology to propel your company forward.  To succeed in this area you must stop looking at SAP or IT as just a tool to enable process automation or process efficiency.  SAP and all technology must become a lever for change, with the application being the vehicle to help manage that change.

Your change in thinking about SAP or any other large IT project should begin by asking yourself what do you want the system to enable you to do? 

What actionable information or automation should it provide? 

What marketplace competitive pressures should it provide you the data to address? 

What data is needed to address those pressures?

How will process automation or actionable reporting help to enhance your marketplace value proposition?
   
SAP’s value proposition lies in its ability to integrate the enterprise with a common set of data which becomes the critical information for strategic business management.  By designing SAP right from the beginning to support the key information you need to strategically analyze your business you will be well on your way to realizing the value of an SAP implementation.

Related Posts:

• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• SAP as a Change Enabler

The first few years of my SAP career was spent doing SAP training and documentation. That time in front of a classroom doing SAP courses helped me gain an understanding of the user perspective, the client perspective, and the ability to facilitate effective requirements gathering sessions.

Many SAP trainers do not have the “luxury” of specializing in a single module.  Usually you learn the transactional processing of whatever module you end up being responsible for on each project.  As a result, many SAP trainers with a few years and a few project experiences have a fair process understanding of the application.  During my first few years of training I covered most of the major SAP modules [FN1].  This background was an invaluable experience for me.  Because of the results I’ve seen when knowledge transfer is done correctly I’ve become a real fan.

Experienced SAP Consultants and Knowledge Transfer

Genuinely seasoned consultants recognize that the time they have spent “in the trenches” cannot be replaced by one project’s knowledge transfer; therefore, they are not threatened by encouraging your understanding.  Many talented consultants thrive in an environment where they are challenged, and learning, and solving problems.  It is a dimension of a successful consultant’s personality and character.  So transferring knowledge is second nature to a skilled and experienced consultant.

Most often the truly skilled consultants with practical business and work backgrounds are the ones who can speak to issues in plain, understandable terms.  They have been through the go-lives, they have done the production support for the user community, they have had to work through the complex or thorny processing issues, they’ve seen where things were done right (and not so well) and they have gained a solid process understanding.  They do not have to rely on “fast talking techie speak” to keep you confused and in the dark.  And if you’re not clear on what they are saying how are the project team and user community going to understand them?

Having explained my bias, one of the most important things a company can require of their software vendor is knowledge transfer.  Done correctly this leads to operational independence.  Done poorly, or not at all, it leads to perpetual vendor dependence.  Worse still, done poorly the long-term organizational change and acceptance of the new system, new processes, and new way of doing business is much slower and more painful. In some of the worst cases strong enough resistance to the needed business change may lead to resistance and eventual failure of the implementation.

More on SAP Knowledge Transfer and Process Communication Skills

Most consultants come to a project with resumes that claim several years of full life-cycle project experience:

• leading requirements gathering sessions,
• developing blueprint documents,
• producing option assessment whitepapers,
• logging and troubleshooting complex issues with users,
• performing actual knowledge transfer,
• training client-side core team members,
•  and post-go-live support.

For many companies looking to install SAP or other ERP applications many of the consulting companies deliver “generalists.”  These “generalists” do not have the critical application and process knowledge to ensure that your company will gain the critical “operational independence” you need for long term success.  Ask yourself how you are ever going to acquire the knowledge transfer your organization needs if the consultants who you are paying are also learning “on your dime.”

SAP Knowledge Transfer Requires Good Communication Skills

How can a consultant do any of the communication intensive project requirements without strong native language skills?  Any language barrier is a red flag that you may not receive the critical knowledge transfer you need for operational independence. The lack of ability to do knowledge transfer is a serious red flag which should be a warning that the consultant may not have the level of experience required for results.

I have seen the results of projects where the vendor team would not effectively transfer knowledge, and projects where it was effectively transferred.  While there are lots of reasons, some of the danger and warning signs of a problem vendor and of problem consultants are those who will not, or cannot, share their knowledge and move the dependent organization toward independence.

There are a number of warning signs indicating a serious problem.  For example:

• Fast talking “jabber” that sounds sophisticated but is difficult to really understand.
• “Techie” terms and jargon rather than plain native language terms that make sense and even help the uninitiated to understand (frequently this is an indication of a LACK of experience because the exposure the individual has is to the “technical” material they have reviewed or are learning online).
• Lots of “consultant only” meetings where client counterparts are not invited to participate (some of these, like weekly team lead meetings for consultants only may be needed.  But excessive use of these should be seen as a red flag).
• Layers of bureaucracy to get answers or to resolve problems from the “keepers of the knowledge” by the active or extended implementation team members (again, some of this is necessary as a practical measure from the extended user community).
• Frequent failures to communicate changes in direction, or new requirements.
• Constant refrains like “you don’t need to worry about that now” or “we’re not there yet” or “don’t worry, we’ve got that covered.”  Or worse still, “why do you need that?”  If you’re getting these types of responses without adequate explanations this should be seen as a danger sign.
• Or, the all time classic “I’m (or we’re) too busy to worry about that now.”  And while many projects are busy, the knowledge transfer can not be neglected.

Effective SAP Knowledge Transfer Requires the Ability to Make the Complex Seem Simple

The important skill in all of this is the ability to take the complex and make it simple.  Anyone can take the complex and keep it that way, or even make it more complex, however those with real talent can help you understand what you need to know for success.  They are often able to do this in terms that you understand, and when the introduction of completely new and foreign concepts are introduced if they have enough experience they will have worked through it enough internally to be able to present understandable explanations.  Often times those fast talking consultants, who are hard to understand and use lots of jargon or technical talk that “sound” so brilliant are most often the fakes.

All of these fakes are more common than many clients realize, and more damaging to your implementation than you can imagine.  Even many vendors are duped and hire these consultants who hide behind their own lack of knowledge or experience by preventing you from gaining knowledge, or the ability to meaningfully challenge or review their work.  By preventing meaningful review of the consulting work you are billed for it is difficult or impossible to recognize the level of competence and skill (or more likely, the lack of it).

Knowledge Transfer Exceptions

There is one other perspective and cause to consider here: there are some projects where the client company (not the vendor) does not provide enough resources for the project, or will not commit enough of their core team member time that makes it very difficult to transfer much knowledge.  To achieve operational independence a company MUST commit their resources to learning the system, and learning it well, for long term health.

Trying to have core client team members do an SAP project while maintaining some additional responsibilities of their other job only hurts you (the client) in the long term.  The reason is that once you go live things will change, SAP will be your new system and the old ways of doing business will not all be supported.  As a result the more knowledgeable and capable your core team is the better and more productive it is for your business.

If you’re one of those clients where you really don’t care, money is virtually limitless, and you just want a warm body, then these types of consultants, their vendors, and the long term dependence on them are ideal for you.  If you’re looking for results and meaningful long term value, run from these consultants and their vendors like the plague.

Operational Independence is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer

To avoid this problem, your vendor contract might include a provision where you commit to the number of resources and time (client staffing levels) and the vendor is required to reach a point of operational independence within 2 (or 3, or whatever number) months after go-live.

Define operational independence as the client resource’s ability to troubleshoot and resolve transaction problems within the scope (or list) of the transactions that are implemented.  Also, the terms of your agreement might spell out that as of “x” date, the vendor agrees to support all client resources at “y” discounted rate (say 50% or less of the project rate) until operational independence is achieved.  See how your vendor reacts to this.  If they raise concerns, and want some contract language changed or modified to make things fairer and to spread the responsibility more appropriately that is fine.  But if they are resistant to such an arrangement without a clearly compelling reason you may want to reconsider whether they are the right fit for your project.

Combat this throughout the project by building some of these knowledge transfer expectations into other parts or phases of the project.  For example, by the time the project begins integration testing, the client resources should be able to configure or resolve “x” or “y” as part of the knowledge transfer.

How you resolve this is up to you, but let me assure you that knowledge transfer is a key component of every GOOD SAP project.  If your project is lacking in the knowledge transfer and you have provided sufficient resources you may want to take a long, hard look at your vendor and consultants.  You may be headed for more problems and more unnecessary expenses and cost than you know.

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

[FN1] I had trained classes on various parts of PP (Production Planning), SD (Sales and Distribution), MM (Materials Management), WM (Warehouse Management), FI (AR, AP, GL, and Asset Management)

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Planning For a Smooth Go-Live: Part 3
• Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• Opportunities for INNOVATION SAP, HELLO?