INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP Service Delivery versus Value Delivery

April 30th, 2012 by
SAP Value Delivery

SAP Value Delivery

In my review of academic literature around SAP or ERP implementations I find some thought provoking items.  Recently I reviewed a study which helped me to form a more complete picture of important issues in IT delivery.  Even though I’ve been writing about it for years I gained a new clarity around evaluating some of the existing delivery models [FN1].  What it comes down to is are you looking for service delivery or business results for your SAP project?

SAP Service Delivery or Business Value Delivery – You Determine Your Future

Because my career started in business and later was exposed to SAP as part of the client core team, and then finally moved on to consulting, I have always recognized the importance of business value.  At the same time much of the System Integrator marketplace has been promoting the same old service delivery model they are familiar with. The biggest reason so many system integrators struggle with business value delivery is because they often focus on hiring a lot of really smart college graduates with little or no business experience.  Fresh out of college and heads filled with textbook ideas about how business works. 

If you just want services delivered then no matter what the sales pitch, all of the system integrators are the same

SAP, ERP, or Enterprise Application customers are looking for something more.  As a recent article I read noted, CIOs do not command the respect of the other key disciplines within the enterprise.  In fact, many of their “C” suite peers question whether or not the technology organization serves much of a useful purpose at all.  That my friends is a frightening and shocking perspective to me.  Stop and think about that a minute, many organizations question whether IT organizations serve a useful purpose in the enterprise.  Is it any wonder outsourcing and off-shoring have become so popular?

What Does This Mean for SAP Projects?

At the end of your SAP project are you satisfied that a project was delivered?  Hopefully on time and on budget, but delivered nonetheless?  If you are satisfied that your SAP project was delivered on time and on budget then you are focused almost exclusively on service delivery

Many senior level IT leaders and delivery folks just want something to get in as quickly as possible.  This is exclusively a service delivery oriented project.  The only thing you are concerned about are the skills needed to address the particular technology / application / solution need right now.  This will not however provide you any type of ROI (Return on Investment) or ROE (Return on Equity) because ROI and ROE (along with other measures) are pure business metrics.  These are not IT metrics and do not measure things like uptime, response time, # of service tickets closed, etc.  The idea of ROI, ROE, or Asset Turns are reflections of business activity and investor / owner value.  Although they may be seen as irrelevant by many in IT they are still useful to understand if any value was delivered for the investment that is made.

Do you want services delivered or business value delivered?

Truth is, if you just want services delivered then no matter what the sales pitch, all of the system integrators are the same.  For that matter, why even bother with a system integrator or SAP consultants at all?  Why not just go to your nearest college and recruit a bunch of really smart graduates for a temporary project and pay them about half what the system integrators charge for a temporary contract? 

Seriously, why even bother with experienced consultants at all? 

If SAP service delivery is your focus and not business results it is just a game of who can best make it through the sales process.  Whether it is IBM and their premium rates or Rajakrishna’s Consultant Shack and their all you can eat offshore rates.  If they can’t speak the local language it really doesn’t matter.  On the other hand if you are looking for business results that is entirely different.

If your only focus is on time and on budget then you are only looking for service delivery.  You are not looking for results, or business change, or IT transformation, or business strategy.

Let me make clear I am not suggesting on time and on budget projects should be ignored.  What I am suggesting is that if your only focus is on time and on budget then you are only looking for service delivery.  You are not looking for results, or business change, or IT transformation, or business strategy.  You are merely looking for resources to deliver services to get you to some date at some budget amount.  Any offshore or consulting shack fake will get you to a dollar amount (that is the brutal truth but they will deliver “services”).

Where is the SAP Value Proposition Focus on Business Results?

While SAP Implementation is an Investment NOT an Event many organizations fail to consider their enterprise application deployments as strategic assets designed to produce business results.  The good news is that is changing.  So the next question is Where do you Start with SAP Return on Investment or SAP ROI?  This goes right back to the basics, you must focus on the WHY of Achieving Business Value from SAP Investment.  Is the effort about technology replacement or is there some business reason behind the initiative?

A recent IBM study under the heading of “The CIO as change catalyst” noted:

As the executive working at the nexus of business and technology, CIOs are uniquely qualified to help their companies leverage available tools to meet current economic challenges and to exploit the opportunities that will arise during this crisis—and opportunity will arise for those businesses bold enough to disrupt competition and restructure their industries. CIOs can help transform their companies by better capitalizing on the value of information assets.  They can help manage and mitigate business risk through better, more timely information. They can improve service management. They can lower enterprise-wide operational costs—including IT’s—through automation. [FN2]

SAP and IT organization heads are gaining insight and experience but at the same time they are being squeezed to cut costs and find value.

Focusing on value entails cutting discretionary spending, deploying resources for the highest return, bolstering core competencies and redefining relationships. Cash flow is central to survival and strategic flexibility, which means businesses and business units need to do more with less. Corporations must conserve capital and cut spending where it produces minimal return. Funds must then be redeployed to activities, products and markets that generate growth, improve margins and truly differentiate one business from another. [FN3]

Make Sure You Are Headed Down the Right SAP Path

To make the transition your SAP project must begin with Creating a Knowledge Centered Learning Organization for Business Transformation for IT Leadership.  Whether you are already live with SAP, in the middle of a project, or just starting out, I would strongly encourage you to get serious about Organizational Change Management Inside the SAP IT Support Organization

What most customers do not know is that SAP has offered the “Value Delivery” methodology as part of the ASAP Methodology for many years

If you want to know Why Use the SAP ASAP Methodology? for your SAP project consider the fact that SAP has offered the “Value Delivery” methodology as part of the ASAP Methodology for many years.  Over the years it has taken many forms, all the way back to the early versions of the ASAP Methodology with the old “KPI” lists.  Today it is integrated into the ASAP Methodology structure. 

Isn’t it time to pursue the value delivery method regardless of whether your system integrator is capable of this or not?

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

[FN1]  Kieninger, A. and Satzger, G., Risk-Reward Sharing in IT Service Contracts – A Service System View, 2011 Proceedings of the 44th Hawaii International Conference on System Sciences.

[FN2]  From fear to value: CIO strategies for propelling business through the economic crisis, pg. 5.  Retrieved 4/24/2012 ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/ciw03057usen/CIW03057USEN.PDF

[FN3] Ibid. pg. 6.




Popular Searches:


  • SAP ROI
  • roi sap
  • sap return on investment
  • sap deployment architecture
  • ROI in sap
  • sap business strategy
  • sap service delivery excellence
  • SAP service delvery best models
  • what is sap investment
  • Business return on SAP investment
  • return of investments on sap
  • https://usngerip2 datamanagement it/
  • why implement sap and its roi

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:

SAP Reimplementation Method Key Considerations

January 30th, 2012 by
SAP REimplementation

SAP Reimplementation

Among three variations for SAP software re-implementations there are two key approaches.  You either make the changes to your existing production system (or a cloned copy of it) or you make the changes in a pristine, newly designed environment. 

SAP Cloned Production System “Re”-Implementations

Making changes in your existing production system (more likely in a cloned instance of it) helps ensure data consistency and ease of adjustment, however there are several difficulties involved.  If you have a significant number of custom-coded solutions you will have to fight them every step of the way.  You will have to work around them, deal with them throughout the process, adjust any out of date coding, and most likely will end up keeping many of them.  As you can tell, I’m not a big fan of an SAP reimplementation in a production system with lots of custom coding.

You either make the changes in your existing production system or in a newly installed instance with no data.

For example if you decided to consolidate organization structures from a multi-system environment you might quickly discover lots of hard coded values in custom programs.  These hard-coded values in the programs themselves, rather than using table driven values and parameters, can cause system consolidation nightmares.  This is just one type of problem from many of the custom-coded solutions so often provided.

Another problem occurs with any of the existing system configuration.  If you make changes to existing objects that are already in production you have the challenge of timing and coordinating your cutover to prevent disruption to existing processes.  Depending on your circumstances if you decide to do a transition in your own production system with the eventual goal of moving away from it and into  cleaner environment then it may be best to create all new custom configuration objects.  You have to make that determination.

Clean SAP Re-Implementation with Old Legacy SAP for History

The other approach to SAP re-implementation is to do a re-implementation in a clean, non-modified system.  That approach assumes that after conversion to the newly designed environment you will leave your old “legacy” SAP system in place for reference and historical data only.  Using a new system for a re-implementation means that you do not have to work around any of the bad setup or design decisions that were made previously.  You avoid all of the headaches with the custom programs and only bring in those custom programs that are really business critical.

If necessary, and if you already have a BI / BW / or other reporting system it will require some additional work to integrate old data structures with new.  However even that will be easier with standard functionality.  The SAP BI / BW / BObj reporting options already contain a number of standard extractors that can be used more easily and with less expense.

The Optimum Solution is a Phased SAP Global Instance Harmonization

The most cost effective way I have found over the years to do a reimplementation is to bring in an operation that is moving to SAP in a “clean” environment.  It is not particularly complicated to integrate two SAP systems using ALE (Application Link Enabling).  In this way you create a new environment, with more up to date and more standard functionality that you can eventually migrate other business units into.

As upgrade projects occur it is only incrementally more expensive to migrate the upgraded companies into the less customized environment.  With an upgrade you still have to do the custom ABAP program reviews, code validations, etc.  With a cleaner environment that does not have all of the custom coded artifacts it is much easier to pick and choose what is really of value and what can be replaced by new, or better understood functionality.

For additional rollout locations there is virtually no additional cost over the rollout project for bringing those companies or organizations onto the more standard SAP environment.  In fact, the reduced custom coding would tend to be less expensive because the amount of time spent regression testing custom functionality, or fixing any organization specific settings, as well as training people how to deal with some of the custom functionality would be lower.  Consulting time, and therefore consulting cost, would be lower as well because the closer you stay to standard the larger pool of resources there is available to make or adjust system settings rather than work with custom programs.

SAP Organization Structure and Master Data Harmonization

One other possible project approach is to do the SAP Org Structure harmonization in all of the separate SAP global instances and then agree on the common master data types.  At “go-live” you extend all of the existing data in each production instance to begin executing with the new structure and master data types in each production instance.  By doing this, the “legacy” data and “legacy” org structures stay in place so that little or no business disruption occurs.  A transition period of approximately a year is needed to complete at least one full annual financial close under the new structures and data in the existing production system.

By using this approach you are actually making the transition in two-steps.  First you build out the new state in your existing system,  then after flushing out and adjusting most of the issues you do a conversion or cutover to a clean system after a financial close.  This approach allows for an orderly transition from the old to the new with relatively little business disruption.  While the old SAP org structure elements and master data types are being made “obsolete” they are still available for all processing and reference purposes.

Some of the key considerations for this approach involve what to do with custom coding and how to transition the master data.  It is impossible to know what custom coding is in place that might be replaced with standard functionality.  However some new data types may help resolve the issue of moving off the custom coding in the same system.  Eventually the goal would be to upgrade away from the custom coding and into more standard functionality unless there is some clear business justification preventing this.




Popular Searches:


  • https://usngerip datamanagement it

Related Posts: