SAP & ERP Consulting from the Customer Point of View

SAP Business Technology Convergence

How Long Term SAP Steering Committee Integration Changes the Enterprise

One of the biggest benefits of an SAP implementation is the business transformation it can bring.  At first the changes and challenges are uncomfortable, even downright painful.  But in the mid to long-term SAP brings about a business culture transformation.  When that transformation is enabled by ongoing steering committee involvement then business to IT convergence occurs.  Over time this convergence of business and technology produces financial and marketplace improvements.

Use the Steering Committee’s Experience for Ongoing Governance

An SAP best practice is to form a steering committee before the project even begins.  In other words this group should be together before the first RFI is issued.  They (the steering committee) should be key members of senior leadership who have the ability to make business altering decisions.

The most effective SAP steering committees typically:

• Set SAP project scope and then help manage it.
• Define project objectives and evaluation criteria.
• Monitor project progress, including key milestones and deliverables progress.
• Oversee Quality reviews at key check points.
• Evaluate and mitigate organizational impact of business changes.
• Promotes the project throughout the organization.
• Coordinates staffing and resource levels from key business areas.
• Makes critical decisions which the project team is unable to resolve (escalations or key business decisions).
• Etc.

Even on a relatively short duration project of six months, many of these steering committees will have worked together in this fashion for a year or more.  Going through the initial business needs analysis, software selection, vendor selection, the project execution, and then go-live support for some period brings this group together for some time.

Gaining Competitive Advantage through the Ongoing Integration of SAP into the Business

As a steering committee works together over the course of a year or two they develop a unique and key skill set that is well-suited to ongoing technology integration into the business (called “convergence”).  As the SAP project goes live and some stabilization occurs the SAP steering committee has learned more about the enterprise from a leadership perspective than anyone in the company.

While the project team is gaining the focused process skills within an SAP module the steering committee is gaining invaluable insight into the overall operations of the business from a leadership perspective.  This steering committee is also exposed to technology and how it applies to business, solving problems, its capabilities, and its limitations.  They have become the most capable future leaders of business transformation and of competitive advantage in the marketplace.  They have worked through the hard things in an interconnected and integrated way.  They have set the stage for future advances.

What happens next?

Your company moves into maintenance mode and the steering committee disbands!

That my friends is a crime!

Do NOT Disband Your SAP Steering Committee After Go-Live

The ideal solution is to retain the SAP steering committee and convert their role to one of managing technology to business integration.  The skills they gain during the course of their duties cannot be underestimated.  They are invaluable to future IT initiatives of expanding the SAP footprint in the enterprise or other key business centered technology projects. This is a role and a function that is seriously lacking from today’s businesses.

In 2007 the BTM Institute (or Business Technology Management) published research indicating that companies who focused on converging business and technology enjoyed greater revenue growth and net margins than their competitors.  They were also found to have consistently greater returns on their investments than their competitors. [FN1]  The BTM Institute defines four broad categories for analysis of business and technology convergence which are:

• Strategy & Planning
• Strategic Investment Management
• Governance & Organization
• Strategic Enterprise Architecture

Think about it, your SAP steering committee has engaged in all of these broad dimensions throughout their existence.  Assuming the SAP steering committee was in place before the project for RFI and RFP preparation they would determine business objectives, priorities, strategic direction, and then develop scope.  These are clearly strategy, planning, and strategic investment activities.  As the project progresses they would engage in oversight, decision making, high level technical architecture analysis, and organizational requirements.

The steering committee must continue to function but take on a new role as the SAP project goes live and you move into stabilization.  Don’t kill the strategic engine of business transformation just as it is finished being built.  They are a critical component of the conversion to an SAP Center of Excellence after your SAP system goes live.

Steering Committees can ensure SAP or IT to business convergence to move from project, to competency center, to center of excellence.

The idea of a center of excellence is the integration or convergence of technology, leveraged in a powerfully competitive way, to ensure business benefit.

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

For more information on developing an SAP Center of Excellence please see:

• Series on SAP Competency Center or SAP Center of Excellence
• Toward an SAP Center of Excellence or SAP Competency Center – PART 1
• Toward an SAP Center of Excellence or SAP Competency Center – PART 2
• Toward an SAP Center of Excellence or SAP Competency Center – PART 3

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

[FN1] Business Technology Convergence Index, The Role of Business Technology Convergence in Innovation and Adaptability and its Effect on Financial Performance, BTM Institute, June 2007

Related Posts:

• 3 Keys to Reduce SAP TCO & Move to SAP ROI
• CRM, ERP, BI, and IT Investment — Where Do You Find the Business Benefit?
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• SAP Program Management Requires a Type of CMMI
• SAP Offshore Development Project Experience

SAP Best Business Practices

Over the last couple months I’ve seen a few posts developing a debate around the use of software “best business practices.”  The basic takeaway is that if everyone uses the standard delivered “practices” there is no competitive advantage.  While this may be true for many software applications there are two things with SAP which causes this idea to be misleading.

Many of these commentators fail to recognize that SAP refers to different things as “best business practices.”  The key types of SAP best business practices involve the processes included in the SAP software itself– software supported business processes.   Then there is the management and integration practices around software alignment to business — or the whole Business to IT Alignment dynamic which focuses on business value. [FN1]

The posts and comments complaining about “best business practices” I refer to are the ones where the authors complain about software supported business processes.  The common denominator I find in all of these authors’ complaints is they have little or no exposure (let alone experience) with SAP.  Their commentary is a bit misleading because of the depth and breadth of options available to any SAP customer.

SAP Best Business Practices for Business Software Integration

Few of the “best business practice” detractors are aware that SAP best business practices are far more than just the software business processes you put in scope and implement.  SAP’s best business practices include structured decision making and governance around applying software solutions to business (shocking isn’t it!) [FN2].  The whole idea behind these types of “best business practices” are to find ways to gain tangible benefits from the application of technology.  By identifying value based governance and project criteria you can achieve measurable Return on Investment (ROI).

Use of SAP’s Best Practices for Speeding Time to Benefit [FN3]

Best-practice value identification, transformation, and measurement approaches include:

- Incorporation of business case objectives throughout the project lifecycle
- Communication and documentation of process objectives and project success criteria
- Use of both existing and new program-specific financial and operational key performance indicators, based on the business case objectives, to measure project success.

The points above come from the SAP literature.  If you look at what SAP is proposing in those points you will see a company that is encouraging accountability to the business in the implementation and integration of its software.  Unfortunately few of the SAP implementation vendors or partners encourage this type of accountability.

SAP as a business software company spends over $1 BILLION Euros a year on Research and Development (R&D) (or over $1 Billion US).  That is to support both types of “best business practices” and is more than nearly all of SAP’s competitors generate in gross revenue each year [FN4].  Is it any real surprise that most of these complainers do not work with SAP?  Many of them are from competitors.

SAP Software Supported Best Business Practice Process Design and Setup

The SAP software supported best business practice processes generally refers to a broad type of functionality that the application contains.  For example, in the automotive sector, on the materials management side, it means that you have special functionality for JIT (Just in Time) or Forecast schedule agreements.  Along with that it also includes “sequencing” for automotive manufacturers and suppliers to guarantee that components and assemblies are delivered to the production line in exactly the order the OEM manufacturer builds them.  This is industry specific business process functionality.

In that one small example, what is not “understood” by many of the best business practice software process detractors is that there are literally dozens, if not hundreds of individual and granular system setup options for how each step of that process works.  On top of that there are also dozens, if not hundreds of master data points between the vendor, materials, pricing, and other possibilities that directly influence how the steps of that process are carried out.  So in a generic sense you have SAP “best business practices” processes in the form of industry accepted JIT and Forecasting along with automotive specific sequencing.  The details of how you execute that functionality can be finely controlled along the way without custom coding.

Conclusion on SAP Best Practices for Business Processes

The example just provided above is one small processing example of hundreds of processing options, within one single industry vertical.  SAP supports over 20 major industry verticals covering industries as diverse as Chemicals, Public Sector (government), Retail, Pharmaceuticals, Consumer Goods, Healthcare operations, Hi-Tech, Services, Aerospace and Defense, etc.

Even though SAP offers a “best practice” setup library with documentation on system settings to support specific business processes, they are a starting point.  The SAP documentation and resources do not cover all of the fine details of setup that only experience brings.

The ability to finely tailor or “tweak” system settings to meet a particular need or requirement, with hundreds, and in some cases thousands of variations, means that two companies using the exact same functionality can create entirely different processes to support different business strategies.  Together with that you have dozens or even hundreds of master data settings which rely on this system setup to create a virtually unlimited set of options.  And then before building some completely separate, stand-alone application there are user exits (or enhancement points in ECC versions) to program very specific requirements.

In the end an experienced consultant can guide you through the process of making the finely detailed adjustments to handle nearly any requirement with a minimal amount of custom coding.  And that is where true “best business practices” intersect with IT. Combine the right consultants with proper project or task governance and you have an optimal solution for the least Total Cost of Ownership (TCO).  Together with reduced TCO you gain real Return on Investment (ROI) with the application of “best business practices” surrounding good governance to create business solutions with IT (rather than IT solutions for business).

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

[FN1] This site focuses more on “best business practices” related to business and technology alignment. There are any number of great resources for the business process related topics so another site would add little benefit.  In fact I’m not sure anyone could compete with SAP’s own “SAP Community Network” (or SCN, http://scn.sap.com ).

[FN2] SAP Executive Insight Series (September 7, 2009).  Accelerate Value Creation: The Virtuous Cycle of Using Technology to Maximize Business Value.  http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/70fa08b0-cf81-2b10-a396-89d18932fbd0&overridelayout=true (retrieved 4/23/2010).

[FN3] SAP Executive Insight Series, pg. 6, 2009.

[FN4] SAP Annual Report for 2009.  Review of R&D Operations.  http://www.sapannualreport.com/2009/en/annual-report-2009/review-of-operations/research-and-development.html (retrieved 3/05/2011).

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• SAP Implementation is an Investment NOT an Event
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• Where do you Start with SAP Return on Investment or SAP ROI?

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:

• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• ERP Project Plan: Getting Real Part 3
• Reduce SAP Project Stress Part 3
• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4