SAP & ERP Business Alignment Answers for IT Leaders

“If the software functionality does not do what we need it to do, nothing else really matters.”

Back in the 1980’s, IT department preferences or mandates to use specific proprietary mainframe technologies drove many ERP software decisions. This was about the technologies the IT department could (or would) support not the mainframe software that best satisfied business needs.

Later in the 1990’s the mainframe vs. “open system” (client/server) wars caused many to take a blind leap of faith into open systems only to find out later the ERP software functionality in this arena was not as mature as their mainframe counterparts. Though open systems eventually won, many jumped head first into this brave new world simply at the wrong time.

Today “open source ERP”, upstart internet based application services (SaaS), “cloud computing” and other paradigms represent the same fork in the road. It is guaranteed tomorrow there will be a new one. The point is not to generalize regarding any particular direction; but the lessons of the past must not be ignored…. If the software functionality does not do what we need it to do, nothing else really matters.

When this occurs everyone will forget all the seemingly valid reasons a package was selected in the first place (cheaper, newer technology or everyone else is starting to do it). They will focus on the lousy functionality and lack of project benefits.

In the real world budgets are not unlimited, technology can be a strategic enabler, and there are other important trade-offs. However, nine times out of ten if the software functionality is a bad fit, eventually the project is deemed a failure. This means software decisions that do not weigh functionality the most can defeat the purpose of a new ERP system.

The Future of ERP?

The message above seems simple enough (and almost elementary), but many smart people allow themselves to get caught up in the industry hype.  Let the academics and consultants who really care debate the future of ERP because in the meantime you have a business to run. Unless you are interested in becoming a guinea pig. Believe me, a lot of software vendors are looking for them.

The Right Side of ERP History

Selecting software is not just a quantitative process. It ultimately boils down to a business decision and you want to be on the right side of history. As long as the cost of ownership is affordable, the technology stable, the package is supported, and many other companies are using it; go with the software that best meets business needs. 

If the organization cannot find a package that satisfies at least 85% of the overall software requirements (and almost all of the important ones), it is time to either look at higher-end packages or redesign your business processes.

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

Editor’s commentary - Steve Phillips runs a great blog which is linked here:

http://it.toolbox.com/blogs/street-smart-erp

Be sure to visit his site and support his efforts!

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.

Part 3 of 3

Stages and Components of the SAP Center of Excellence

To wrap up this series we will take a brief look at the post go-live or the production support environment.  On academic study has defined the three production stages of Acceptance, Routinization, and Infusion which has been  written about at The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors .

These three terms fit the requirements for SAP production system stages as you move toward an SAP Center of Excellence so I’m not going to try to change them just to be different.  However, I have defined them in my own way below which may, or may not be 100% consistent with the academic literature.

The ultimate goal of an SAP Center of Excellence is Business Transformation.

Here is a high level SAP Center of Excellence Model for Business Transformation after you are live in your SAP environment:

Acceptance – go-live and productive business use of the system (heavy change management).

• Training
• Process Documentation
• Help Desk
• Internal Collaboration (structured Instant Messaging, Forums, and other structured as well as unstructured information capture)

Routinization – the overall acceptance and sustained productive use of the system (system stabilization).

• Knowledge capture (Wiki and Forums)
• Troubleshooting methods and Company Best practices
• Process overviews, refinement, and business / system adjustment
• External Collaboration (Forums, Customer Channel feedback, marketplace intelligence, vendor collaboration, collaborative product or service development, etc.)

Infusion – long term acceptance and use of the system as well as additional functionality additions (re-focusing on business and SAP to business alignment, i.e. strategic direction).

• Rotating IT staff assignment into business organization (through the process chain)
• Once a month work in department of responsibility
• FAQ Development (Wiki and Forums)
• Enhanced or new system functionality
• System and Process Change Risk Management

SAP Competency Center or SAP Center of Excellence Conclusion

Enterprise applications like SAP are more important than ever in today’s globally competitive and economically sensitive era.  It is simply not enough for IT departments to serve in a more passive support role.  In today’s global economy your SAP and IT support staff can not wait for the business requirements to come rolling in.  For the health and welfare of your business and organization it is more important than ever to ensure that your SAP staff is proactively engaged with the business community.  That engagement must take the form of an active partnership in looking for new and better ways to use technology for competitive advantage and process improvements.

As for the future, this type of alignment between all of the IT functions, under the banner of the CIO is beginning to take place [FN1].  While SAP Competency Center management and development can focus on the operational excellence business proposition (better, faster, cheaper, more automation) the SAP Center of Excellence framework is more closely aligned to the innovation and customer focus value propositions.

———————————-

[FN1]  A four part series on the current and future technology leadership landscape, this includes the direction of technology and the pressures CIOs face now and in the future.

Part 1:  What is the Proper Relationship for the CIO, CEO, and CFO?

What the changing business and IT landscape means to the CIO, IT Director, IT Manager, or other key technology decision makers.

Part 2:  CIO, CFO, and CEO Alignment – Why ROI is Lacking from Today’s System Landscape

This post provides an overview of the current system landscape and the focus on business processes and contrasts that with the emerging trend of the customer focus value proposition.  This piece also looked at the future business landscape and how the technology focus and direction will be permanently changed no matter what happens with the economy and global competition.

Part 3:  Changing the Direction of SAP, ERP, and IT Applications to Focus on the Customer and Innovation

A brief review of the supply side and the demand side of business shows that unless you have lots of customers (demand) to fill a bigger and bigger pipeline (supply) then an operational excellence business model collapses.  While it is hidden during good economic climates, any disruption in those economic conditions which fails to fill the capacity pipeline points out the glaring insufficiency of the “operational focus” to technology.

Part 4:  Future Technology Landscape Alignment for the CIO, IT Director, or Key IT Decision Maker

The final part of the series looks at the emerging technology landscape and what the future holds.  It lays out an emerging technology landscape model which has some re-alignment and some components already in use by some of the world’s most successful companies.  A new alignment of technology with the customer facing processes, and the use of social or collaboration tools across the enterprise with a clear business objective is explored.  The driver for the future change will be because the business does not see the revenue generation prospects of technology–, they fail to see the possibilities of promoting customer retention, customer acquisition, innovation, and marketplace analytics.  The new technology model looks to change that dynamic.

———————————

Toward an SAP Center of Excellence or SAP Competency Center – PART 1

Explaining the differences between an SAP Competency Center or sometimes referred to as an SAP Center of Expertise and an SAP Center of Excellence.  As Peter Drucker wrote either Do Things Right or Do the Right Things.

Toward an SAP Center of Excellence or SAP Competency Center – PART 2

A more complete and thorough explanation of the differences between the SAP Competency Center (or Expertise Center) and the SAP Center of Excellence (or the Business Transformation Center).  An understanding the operating differences and how the Competency Center is focused on reactive processing of things like help desk tickets, problem resolution, data correction, and knowledge transfer.

Toward an SAP Center of Excellence or SAP Competency Center – PART 3

Business model application of steps, techniques, and methods to produce an SAP Center of Expertise or an SAP Business Transformation Center.  The major business transformation steps on moving from an SAP Competency Center to an SAP Center of Excellence.