Business Solutions with SAP

Achieving Business Value from SAP Investment

February 27th, 2012 by
SAP Business Value & ROI

SAP Business Value & ROI

As a follow up to last week’s post on Sustained Business Value from SAP Business Software I did a little research on the study authors and discovered their continued focus on this issue.

Recently Peppard (one of the authors) and a couple of other colleagues provided real business value success findings in an upcoming journal article called “Factors Affecting the Successful Realization of Benefits from Systems Development Projects: Findings From Three Case Studies” [FN1].

While I read through and reviewed the draft 35 page study I couldn’t help but notice the striking similarity to my nearly 5 year old post on the subject of SAP as a Change Enabler. What SAP as a Change Enabler summarized in a few pages appears to have been empirically tested by comparing and contrasting a few case studies of live software implementations.

Following my personal experience around SAP since 1994 I’ve added additional insight on how to gain SAP ROI through Strategic Business Transformation by also Using SAP to Improve Revenue and Profitability.  The “how-to” instructions, and detailed guidance is starting to gain some traction. To amplify their initial research I’ve cross-linked many posts throughout this one.

Changing from SAP System Delivery to Business Benefit Delivery

Before anything else a benefits focus must be the guiding framework for your SAP project. Every major business software project must begin with some clear guidance on the “why” of the project.

Business Centered SAP Change Management is Required

The authors highlighted several key observations around organizational change management and the need for user participation but missed one of the key areas of success–, knowledge transfer (see Change Management and Knowledge Transfer Part 1, and Part 2). Not just end user training, but more holistic knowledge transfer about the new system, its capabilities, and how to maintain them.

SAP business transformation is an ongoing effort. To achieve this one of the goals of SAP projects has got to be to create a learning organization. An organization where knowledge exchange and benefits centered collaboration is key to SAP program success (see ERP III – Is the Integration of Collaboration the Future of Enterprise Applications).

WHY do an SAP Project?

So, what is the basic idea here? Their findings indicate that a large scale software program requires a business benefits focused approach. An approach which addresses the “WHY?” of the project.

[A] project might be successful in meeting its internal targets, yet not deliver beneficial business outcomes. [FN2]

For too long enterprise software vendors and SAP system integrators have focused on everything but the genuine business “WHY?” of the 5 W’s and the H of SAP projects. For too long companies have addressed:

  • “WHO” (who will implement, who will support, who will the core team be, etc.)
  • “WHAT” (what is the scope, what technology, etc.)
  • “WHERE” (both project logistics as well as the organization structure that is impacted)
  • “WHEN” (project timeline, business timelines, milestones, etc.)
  • “HOW” (use our custom methodology [i.e. make it up as we go], or use ASAP)

Few companies get down into the details of the “WHY?”

WHY is Management Engagement and User Participation Lacking?

It is the “WHY” which will engage the larger business community and senior leadership and that is The Real Reason Executive Participation Creates IT Project Success. It is the “WHY” that will bring about badly needed business process changes from the user community. Unfortunately it is my opinion that because the compelling “WHY” part of the business case has been missing for so long senior leadership and ultimately the user community is generally disengaged from the project delivery process.

Think about it, how many multimillion dollar investments, with such wide organizational impact, do management stakeholders and end users take such as “hands off” approach to?

If you want your SAP project to be a business project, GET THE BUSINESS ENGAGED! If you want it to be a technology project, nothing else is required. Just put the system in and when people complain tell them to shut up. It was never really about the business anyway!

Do Your SAP System Integrator Consultants Have Business Knowledge or ANY SAP Experience?

This leads to the next issue. If the business is engaged and you decide to bring in a system integrator then define BUSINESS expectations from your system integrator up front. If they only speak to the business in techie terms then get rid of them because do no one  needs “consultants” who can’t consult? (see Screening and Interview Methods to Find the Right Consultant – Part 2).

Think about this a minute and let it sink in. If you hired a system integrator for an SAP business application project then shouldn’t they be focusing on the business? If they can’t speak to you in business terms then why again did you hire them?  Are they really consultants? To gain real competitive advantage in the business marketplace you must Change How You Look at SAP to Create ROI because SAP Implementation is an Investment NOT an Event.

During the sales cycle you as an SAP prospective customer have GOT to ensure there is a clear business vision. Again I ask, if not, then why are you even doing this?


[FN1] Doherty, N., Ashurst, C., and Peppard, J. (2011) Factors Affecting the Successful Realization of Benefits from Systems Development Projects: Findings from Three Case Studies. Journal of Information Technology (upcoming).

[FN2] Sauer, C. and Davis, G. B. (2010) – Information Systems Failure, Encyclopedia of Library & Information Sciences, Third Edition, pp 2643-2652.

Additional Resources for Successful SAP Implementation

Check out these posts for specific ideas, thoughts, and experience on achieving real results from your SAP project or other enterprise software projects:

Related Posts:

Sustained Business Value from SAP Business Software

February 20th, 2012 by
SAP Benefit and ROI

SAP Benefit and ROI

From time to time I review academic literature about the application of technology and offer my SAP experience based perspective.  Recently I was reviewing one of these studies from a few years ago when the authors made a key clarification: they recognized two types of implementations which are  problem-based (i.e. address your “pain points”) or innovation based.

Their suggestion was that some elements of both would be present on any large scale IT project, like an SAP implementation for example, but each type of application presented its own special set of challenges.


Throughout the study (linked to at the end) the authors managed to clarify key points so they are easy to understand.  I have always considered the hallmark of genius the ability to take the complex and make it simple. 


There are many situations where a strong business case has been made for an investment together with a well-considered ROI calculation, yet the business benefits sought never actually materialized, despite the fact that the project was delivered on time, within budget, and met the technical specification.

The benefits to an organization from IT-enabled change essentially emerge from three causes: either stopping doing activities, doing what [was] always being done but better (i.e., cheaper and/or faster), or doing completely new things. If organizations are to increase the likelihood of success from their IT investments, they must separate out the different sources of the benefits before developing an implementation plan.  (Peppard and Ward, pg. 53).

They warn against one of the most common hidden pitfalls of Enterprise Software (ES) like SAP turning into a technology project rather than a change lever for advancing corporate strategy.  It is sadly very common to lose sight of the purpose of the technology being applied.  The study authors’ description provides great insight around enterprise applications.  Read carefully how they describe CRM.  Substitute your favorite SAP application, whether it is ERP (ECC), HCM, SRM, SCM, APO, BI/BW, or any other product for their description of CRM and the message is the same.

CRM is not a product that can be purchased; it is a discipline, a framework, [an] integrated approach to managing relationships with customers that requires continuous improvement.  It is a strategy, not a tactic; and although supported by IT, it involves considerable organizational re-design, often changing the focus and culture of the organization.  CRM implementation is not easy and the evidence suggests that many companies are struggling with their efforts. (Peppard and Ward, pg. 54).

One of the problems they noted with the case study they used was at a retail bank they wanted inconsistent goals for their CRM system.  I run into these frequently and call them “mutually exclusive requirements.”  Or, as some say, they “want their cake untouched and want to eat it too.” 

The case study noted the company wanted to implement a CRM system for better customer management and servicing but at the same time wanted a quick payback.  The whole idea of developing customer relationships–, through gaining intelligence, aggregating customer data, and analyzing customer interactions so you can manage and service customers better takes time.  Not only that, one of the key goals of the initiative was to deepen customer relationships to reduce their servicing costs while selling them better products and services.  If they had that level of awareness of their customers to do this within a short payback time period they wouldn’t have been looking at the CRM project.  The company had set themselves up for failure by insisting that a business approach which naturally takes time should have an immediate payback.

Attempting to resolve the current and future business models often highlight a major disconnect between the strategic intent of implementing the system and the resulting actions that must be completed. One UK bank had difficulty in getting branch staff involved in defining requirements during their CRM project. Senior management’s vision of the project was built around customer retention and cross-selling. Branch staff, on the other hand, just wanted a system to process transactions speedily and to get the customer out of the branches as quickly as possible. Getting appropriate engagement and buy-in proved difficult and progress was laborious at times. Yet, after the system had been up and running for a year, staff began to see what was possible and became very active in making suggestions for further development.  (Peppard and Ward, pg. 59).

This point where I will leave off this week is critical.  Frequently companies purchasing enterprise software solutions like SAP are not aware of the capabilities or how to apply them.  Only after some period of time, or a shakeout period, users begin to see and understand how the functionality and information can help achieve strategic business goals.  That is generally when the second phase of implementation, or new functionality, or new enhancements, or even a reimplementation begin to gain consideration.

This study was really well written and easy to understand.  The authors offered tremendous insights into the world of Enterprise business applications which are important for every business software customer and consultant.  I’ve included a link below and it really is worth taking the time to read through. 


Peppard, J. and Ward, J. “Unlocking Sustained Business Value from IT Investments,” California Management Review, vol. 48, 2005, pp. 52-70.

Related Posts:

SAP Landscape Consolidation

February 13th, 2012 by
SAP Landscape Consolidation Direction

SAP direction

For any number of reasons many companies who run SAP end up with fragmented and piecemeal landscapes.  It happens for lots of reasons:  roll-outs, independent Business Units, mergers and acquisitions, immature software procurement processes, lack of a Software Asset Management program, etc.  The results can leave your SAP application and business solution looking like someone set off an explosion scattering pieces everywhere. 

More and more I am seeing companies looking to consolidate onto either a single platform or at least a few regional platforms.  This makes sense for a lot of reasons.  It is easier and more cost effective to manage user licenses, engines, solutions, and create centrally supported business processes. 

Getting the SAP application space all together makes it simpler to manage and helps to control overall costs–, both from a solution cost perspective as well as internal maintenance.  Done properly a consolidated SAP landscape can help to reduce TCO and improve your ROI.

SAP Total Cost of Ownership is reduced by more than just any hardware or architecture savings, there are also real savings in the ability to centralize support and maintenance.  Your overall consulting costs will be reduced as well because in a fragmented environment any consulting efforts that are needed in the broader enterprise tend to be duplicated as well as fractional.  On top of that there is also the cost of bringing each of those fragmented consulting resources “up to speed” on that particular business unit.  Then there is the cost of short-term spot consulting.  I’m sure I’m not alone here but on shorter engagements I charge a higher rate than on longer term engagements.  And those are just a few examples of the impact on SAP TCO.

If you are considering an SAP application consolidation all of the previous posts and information on re-implementation are very similar to what you deal with on a consolidation.

Consolidating Fragmented SAP Solutions

Because of SAP’s focus on business application solutions their application footprint tends to expand into many areas of the business.  Aside from more traditional application offerings like SAP ERP, CRM, BW / Business Objects, and HR, there are many engines SAP also licenses and you can quickly end up with a jigsaw puzzle of SAP solutions spread around your enterprise.

Done properly a consolidated SAP landscape can help to reduce TCO and improve your ROI

Over time this jigsaw puzzle leads to licensing headaches where you can be over-licensed or under-licensed even on the same SAP solution across instances.  You can end up with a huge architecture headache where the hardware, interfaces, infrastructure, security, and usefulness of the systems are impacted.  Remote use of the systems creates duplicated access and duplicated security problems.  Reporting across the various solutions becomes little more than critical compliance rather than business insight across the enterprise.  And the list goes on. 

There are also struggles even after a successful consolidation.  One of the better components which likely led to some of the fragmentation was the autonomy and freedom to set up the system to run it the way the business thought was best.   In a consolidated environment that freedom becomes more difficult because it must be coordinated with all of the other players.

Even though there are benefits there are still a few drawbacks.  But many of these drawbacks were the same things you likely considered when each SAP instance was used to replace some legacy application. 

Where Do You Begin SAP Landscape Consolidation?

Just like with an SAP reimplementation one of the first decisions to make will be whether to use an existing system as your starting point or whether you should do a “clean” start with part of the application landscape?  My personal preference is to start clean and challenge any custom development as to how necessary it really is.  That is one issue. 

Then there is the issue of defining global standards around data, authorizations, user provisioning, development, processes, etc.  How you will segregate legitimate needs for differences between the various businesses?  What are your processes for this?  There are also political realities.  It is tough to get some very profitable or flagship business units on board with these types of initiatives. 

Then there is the issue with how do you start such an initiative?  Once again, I suggest you begin where it makes sense, and where it has the least financial impact.  Begin with either a rollout location OR with a location that is in need of an upgrade.  While the effort and impacts are different the project work and some budgeting around these areas is already being planned for.  It is just a matter of systematically rolling any upgrade or rollout efforts into the newly determined “central” instance as time goes on.  This way each phase can take lessons learned, refine project standards, improve on delivery processes, enhance deliverable templates, etc. 

And then there will be the issue of negotiating agreements with SAP that allows for the changes in the application footprint and user licensing.  Do not underestimate this effort.  At this point I would suggest you hire an outside IT spend management firm to help with determining what a new contract or license agreement should look like.  For example I work with a company called “NPI Financial” from time to time.  There are others out there but this is also an important component of your landscape consolidation.

Good luck on the journey and if you need architecture, solution, spend management, or other consolidation help please feel free to reach out and contact me.

Related Posts: