Business Solutions with SAP

SAP ROI through Strategic Business Transformation

January 31st, 2011 by

SAP Strategic Business Transformation

Lots of business ideas and paradigms have been proposed over the years.  Some of them turn out to be fads and other have enduring legacies.  While many have merit they all have one thing in common–, they are supposed to address the marketplace in some way.  Whether or not they stand the test of time depends on how well they help businesses compete in a globally competitive marketplace.

Enduring business ideas generally become part of an accepted business strategy.  One example is Michael Porter’s five competitive pressures (as the keys to strategy) for focusing on operational excellence, customer focus, vendor management, and competitor pressures.  The ability to address these competitive pressures is directly related to the quality of consultants your SAP system implementation partner provides.

The only thing that matters is the specific consultants they bring to your business to make a difference in how your business operates.

When changing the enterprise culture to one that is strategically focused and performance based several stages are required. These stages relate directly to the early, up-front work needed for an SAP implementation. Although the following quote is related to implementing a Balanced Scorecard initiative, the same change process applies to an SAP implementation and business transformation.

Initially, the focus is on mobilization and creating momentum, to get the process launched. Once the organization is mobilized, the focus shifts to governance, with emphasis on fluid, team-based approaches to deal with the unstructured nature of the transition to a new performance model. Finally, and gradually over time, a new management system evolves—a strategic management system that institutionalizes the new cultural values and new structures into a new system for managing (emphasis in original) (Kaplan and Norton, pg. 16, 1992)

The authors then note that the “various phases can evolve over two to three years.”

Over my SAP career beginning in 1994 I have seen this over and over.  What SAP causes is a cultural transformation that can be harnessed to achieve great things.  SAP, properly implemented and properly guided through the business transformation process provides front line managers with key information to move from day to day transaction management to longer term strategic management.  The idea would be to use SAP as a change enabler or change lever (Change How You Look at SAP to Create ROI).  By doing this successfully you can transform your business in the marketplace (Why SAP Projects Fail to Deliver ROI and How to Change IT).

This transformation process requires a phased approach that moves you through the process from go-live to competency to excellence (Series on SAP Competency Center or SAP Center of Excellence).  The reality is with an integrated ERP application like SAP it takes about 1 – 3 years to change the middle management culture from one of tactical day to day execution to strategic data analysis and competitive insight.

Mobilization – In SAP terms, the mobilization effort consists of the upfront business planning, strategy definition, goals and performance metrics definition.

Governance – The governance phase would include the necessary project tools to accomplish the organizational transformation. These are tools and resources not only for the SAP implementation itself, but also for the change management program within the enterprise.  In SAP, project governance begins from before the vendor contract is signed and continues on long after go-live to address ongoing business needs and requirements in the live system environment.

Strategic Management – The strategic management system occurs over time as the new metrics, resources, and tools available in your SAP implementation are used throughout the enterprise. It is the old business axiom “what gets measured gets done.”  After go-live new features or functions may be added to address marketplace competitive pressures.  As the actionable data is able to be analyzed by middle and lower level managers over time decisions can be made to more effectively address those competitive pressures.

SAP Organization Change is Ongoing

Depending on your timeline and organizational tolerance for change, by the time the SAP system is stabilized (anywhere from 3 – 12 months after go-live) your organizational transformation will be well underway. Within 12 – 24 months after go-live your organization should begin seeing real benefit from a properly implemented, business focused SAP implementation.

It takes about 1 – 3 years to change the middle management culture from one of tactical day to day execution to strategic data analysis and competitive insight.

My personal opinion is that because so much of the focus has been operational and “getting the system in” for an “on time and on budget” implementation that the upfront business work is little known and even less understood by the wealth of “technicians” that most consulting companies provide. Often times the consulting companies with established client relationships are eager to get as many consultants billing as they can. The several months of up front strategy work, even at super-premium rates, only engages two, and even in large far-flung enterprises, only 4 or 5 consultants. The SAP implementation itself will engage at least 5 – 10 TIMES that many consultants and so if a client does not insist on this up front strategy work, SAP vendors are reluctant to press a client in this direction from the RFP phase on.

That is not to say that consulting companies have not tried, only that customers or host companies, have focused so strictly on getting the existing transactional processes into SAP that they often fail to have the upfront business case for change created before the project begins.

To be successful, this upfront business design and change work must become the central focus of the SAP implementation.

SAP Business Transformation for Competitive Advantage

Business transformation with SAP is entirely possible even in massive enterprises if the business transformation effort begins by mobilizing your team at least a few months before an SAP RFP.  After the RFP you will need active change management throughout the SAP implementation.  For more information on various insight and ideas on SAP RFP strategies please see:

The RFP process is your first real opportunity to find the right vendor and the right consultants to transform your business.  By navigating this process successfully you can start out on solid footing.  One thing to always remember is that it is the quality of consultants on your project that makes the difference in the results of your implementation.  It is NOT the size of the company, the scope or reach of the consulting firm, how many offices they have, how much marketing material they put out, or how many fancy clients they can name.  The only thing that matters is the specific consultants they bring to your business to make a difference in how your business operates.


Kaplan, R. and Norton, D. (1992), “The Balanced Scorecard – Measures that Drive Performance”, Harvard Business Review 70 (1).

Related Posts:

Global SAP Instance Consolidations

January 24th, 2011 by
SAP Business Software Integration

SAP Integration

Over the last several years a number of companies have undertaken a global instance consolidation.  And it’s no wonder why, a global SAP consolidation presents opportunities for significantly reducing Total Cost of Ownership (TCO).  But this type of system consolidation brings numerous change management issues to address.

As you embark on your consolidation there will be some major issues that are easier to resolve because the hard decisions around processes and scope were resolved during an initial implementation and production support process.  On the other hand there will also be difficulties around resolving the conflicts about standardizing organization structures, business processes, and “sacred” developments which were done in some of the instances.  Each of these areas presents a point of possible conflict requiring cooperation, compromise, ownership, and change management.

To reduce the amount of customizing, shorten the duration of the consolidation, and ensure needs are met with more standard functionality rather than ever expanding lists of custom programs it will be important to:

  • Take inventory of the implemented system landscape (modules implemented, external systems, interfaces, middleware, etc.)
  • Inventory of all custom developed SAP programs or applications
  • Inventory separately any custom fields and table extensions and their use
  • Harmonize the organization structures
  • Standardize business processes
  • Both harmonize and standardize master data types and requirements
  • Develop the sizing and new hardware requirements for the consolidated environment

While I am generally opposed to “As-Is” process mapping (see How “As-Is” Process Mapping Can Damage Your SAP Project ) it is important from a scope perspective.  In other words, to do a system consolidation correctly, an inventory of the existing systems is needed.

The successful companies who can focus on moving away from custom coded solutions will find their TCO reduced and application maintenance to be easier overall.

Prototyping Possibilities After SAP Global Instance Evaluation

There are some great places to start with analysis on how to integrate the different systems.  Generally I am a big advocate of using the SAP IDES system that is available to all SAP customers for evaluation.  It serves as a great platform to review standard SAP options that have not been dirtied by custom-coded solutions.

SAP IDES stands for “Internet Demo and Evaluation System” and can be used like other SAP applications, however it does not allow for transports to other systems and should only be used for evaluation reasons.  This explanation from a recent SAP OSS Note explains the SAP IDES use, and some of the summary information is provided here (see Note 799639 – IDES – General Information about the usage of IDES systems):

IDES demo systems and IDES demo landscapes are copies of SAP internal demo systems with the data of the IDES model company in several clients. The IDES systems can support demos, functional and tests, self-study or functional evaluation based on the preconfigured data/clients. IDES must not be used in production!

The IDES systems do not contain training data that are used in the SAP training courses.

Customer training etc. based on the IDES systems are not supported.

Client transports are not available.

Standard SAP Support Packages can be applied to the IDES systems.

From the technical point of view Enhancement Packages can be implemented into IDES systems.

IDES should only be operated as a separate installation. Each new release requires a new installation!

We do not recommend to upgrade an existing IDES systems.

As an SAP customer it is important to read through this note, and other SAP OSS notes carefully.

I advocate here, and always have advocated the use of the SAP IDES system as a reference model for evaluation of a totally standard application.  In this way you have a great platform to evaluate future state differences in a possible upgrade situation from the perspective of a “clean” vanilla system.  By using the IDES system you bypass any custom coded solutions and can see for yourself whether or not the newest solution will handle your issues.

By using the IDES system as a baseline you can quickly determine scope for what business processes you may wish to adopt while eliminating custom solutions or additional external systems.

Related Posts:

ERP Education: Losing Our Religion

January 17th, 2011 by
Planning, coordinating, training

synchronizing success

Most ERP software packages are designed around industry accepted business practices, operating philosophies and techniques that have evolved over many years. Today the issue is not whether there is a body of knowledge with supporting software tools, the question is… are clients educated enough to see the value or understand the proper use of the tools. The short answer is no.

Education versus ERP software training

First, many have lost site of the fact there is a difference between education and software training. End user software training is very important but it is mainly about how to do transactions in the software and how these transactions related to your business processes. However, this can be very different from understanding the original design intent and industry application of the tools.

For example, the issue of education vs. software training is analogous to training someone to fly a 767 but not educating them on the concepts of jet propulsion or flight; or how to start-up a chainsaw but not the best way to cut down the big tree. Both of these are scary propositions, but in terms of ERP projects it is about failure to achieve the business benefits. At the root of the problem is senior managers and end-users never changed their behaviors to take advantage of the tools; and a big part of this is lack of education.

Independent Sources of ERP education

Keep in mind, education is more than just a seminar of “best practices” put on by a software vendor (with a hidden agenda) in room full of 300 other clients. It is about getting some real independent education, not focused on any specific package. In addition to understanding key concepts, one must also delve into the mechanics in order to implement.

Baked into the ERP implementation methodology

There once was a time when management and user education were part of the standard implementation methodologies. Interesting enough the project success rates was much higher.

For example, it is worth noting the great Joseph Orlicky wrote the first groundbreaking book on the topic of MRP (forerunner to ERP) back in 1975 (updated and still a good read). It focused on concepts and techniques on how to plan and control materials in a manufacturing plant. However, the most interesting thing is Mr. Orlicky (an employee of IBM) never glorified the role of the computer. He believed if one did not understand the underlying principles of MRP, the computer was not much help anyway.

However, the late Ollie Wight (the godfather of MRPII) said it best “MRPII is not a computer system, it is a people system made possible by the computer”. Orlickly and Wight went on to build and grow the “religion” called APICS (The American Production and Inventory Control Society). The best thing that ever happened to manufacturing practitioners.

Back to ERP Basics

Today there is a disconnect between industry best practices and what clients attempt to do with their systems. It might be time to get back to the basics of blocking and tackling or at least try to understand the intent of the package you just purchased.

Instead, we focus on the gee-whiz aspects of software, technology, implementation tools, and turnkey solutions (which usually exist only in the marketing literature). Cheaper, faster and the slam-dunk mentality is the name of the game, even when we do not accomplish anything worth the effort. We naively assume the mere existence of better tools automatically results in a change in employee behavior (if we build it, they will come). We fail to educate senior management and then wonder why they are not committed to the project. We set higher expectations of our employees, yet as leaders, we fail to provide them with the knowledge they need to succeed. When our projects go down the tube, we blame software vendors, consultants, the entire senior management staff, all employees, our spouse, and everyone else except ourselves.

No, education is not glamorous so proposing it will not make you a hero. Nevertheless, it is the stuff successful IT projects are made of. If Ollie knew what was going on today he would roll over in his grave.


Contributed by Steve Phillips of the Street Smart ERP Blog – Visit his site for more great project insight.

Related Posts: