Q&A on SAP Instance Consolidation Strategies to Accelerate Business Value

October 22, 2015

Significant cost reduction opportunities are associated with instance consolidation. Studies show that the average operational cost of running a single SAP instance could be up to 30% lower than running multiple instances.

Ian Greenhalgh, Head of Applications Strategy at HCL Technologies, answered readers' questions on instance consolidation strategies, what warning signs to look out for before embarking on a consolidation project, and best practices to ensure the process of aligning a single set of processes is as streamlined as possible.

Below you can view the chat replay as well as read the edited transcript, which includes answers to questions such as:

  • Why should my company consolidate its SAP landscape?
  • What tools exist to quantify how dissimilar a set of PRD SAP systems are at the business process, data, and customization level?
  • Is instance consolidation possible for global companies with regional instances?
  • Does a single, global instance translate to higher risks?
  • How can we move ERP and CRM to one HANA system?

Meet the panelist: 

Ian GreenhalghIan Greenhalgh, Head of Applications Strategy, HCL Technologies
Ian is head of applications strategy for HCL. In this role, he is responsible for developing and delivering new technology-based propositions across HCL’s applications business. He is actively involved in working with clients to analyze issues and opportunities, architecting, and implementing innovative technology, business change and operational improvement solutions to fulfill these needs. Ian has been heavily involved in developing solutions and delivering many of HCL’s largest SAP transformation programs in both North America and Europe.

Live Blog Q&A on SAP Instance Consolidation Strategies to Accelerate Business Value


Natalie Miller, Moderator: Hi everyone! Welcome to today’s Q&A on SAP instance consolidation as a cost reduction strategy. I’m Natalie Miller, features editor of SAPinsider and insiderPROFILES, and I’m happy to introduce today’s panelist, Ian Greenhalgh of HCL Technologies.

Ian is Head of Applications Strategy at HCL and has extensive knowledge on strategies around reducing IT and operational costs. Hello, Ian. Thank you so much for being here today to answer readers’ questions on consolidating SAP instances!

Ian Greenhalgh, HCL Technologies: Hello, Natalie.

Natalie Miller, Moderator: There are already some great questions from our readers, so I will let you jump right into answering them.

Comment from Guest: Can you explain the actual business case around instance consolidation? Why should my company consolidate its SAP landscape?

Ian Greenhalgh: There are three broad categories of benefit that we see in consolidation programs:

  1. IT operational cost reductions
  2. Reduced business process costs
  3. Reduced infrastructure costs

The drivers of these savings are a reduction in the number of environments that need to be supported and the costs of provisioning all of those separate environments. Moving back to standard SAP means that the available knowledge base of problems is greater, while the functionality is more robust than custom developments. Consolidating on a standard set of SAP processes has significant business benefits in that all areas of the business use consistent processes and technologies, which ensures an expanded user knowledge base, improved data consistency and accuracy, reduced manual reconciliation between systems, and earlier identification of emerging trends.

Comment from Guest: Can you provide more details around the three, broad categories?

Ian Greenhalgh: In terms of benefits resulting from instance consolidation, typically we expect to see them in the following categories:

IT operational cost reductions — Benefits in this category are associated with the move to simpler SAP solutions, returning to vanilla SAP and defining an SAP minimum viable product. By simplifying the solution and standardizing on a smaller set of processes and functionality, we typically find that we have a smaller user base running standard transactions more frequently. This change manifests itself in more experienced users, fewer support incidents, and lower costs.

Reduced business process costs — Instance consolidation drives significant business process cost improvements derived from streamlined processes, process rationalization, reduced system complexity, and a standardized data model. The benefits manifest themselves in numerous ways including:

  • Improved data and process quality leading to reduced process errors and hence faster processes
  • Reduced reconciliation effort across systems
  • Reduced manual intervention
  • Shared service efficiencies
  • Increased spend leverage
  • Resource optimization resulting from improved status and process visibility
  • Improved and more responsive decision making resulting from improved process visibility

Reduced infrastructure costs — Consolidated systems require fewer infrastructures, although in larger environments there are significant benefits to be achieved by reducing not only the net hardware requirements but also all of the effort required to run those different landscapes, particularly if they are different (for example, patch application, database monitoring, failover testing, access controls, etc.).

In addition to these major cost reduction categories, a number of clients are able to realize sizeable benefits by reducing their productive SAP application footprint and hence the maintenance that they pay. The ability to realize this benefit is heavily influenced by the terms of the SAP licensing agreement that they have signed.

Comment from Marcus: Hi Ian. Please elaborate on choosing the right vendor for the required hardware or platform. What criteria should I look at? What are the drivers for the price of the solution? What can be done to prepare the move from HP (or XYZ) to the new platform?

Ian Greenhalgh: Choosing the right vendor is a function of a number of factors. In our view, the first question to ask is whether or not you, as an organization, are prepared to run either your non-production infrastructures in the public cloud. If the answer to that is yes, then the selection criterion takes a different tack.

If you’re not prepared to consider the cloud — and you should note that pretty much 80% of all new SAP engagements we undertake run their non-development environments in the cloud — then you’re back to the usual: where do you have current technical skills, strong vendor relationships, etc.

One trend that we are seeing is a shift to generic hardware at cost savings of up to 80%. Microsoft tells a fantastic story: They run one of the largest SAP instances anywhere. Their SAP landscape includes over 500 servers and they run generic hardware which cost them less than $500,000 to acquire — that makes badged hardware seem extremely expensive.

Comment from Guest: What tools exist to quantify how dissimilar a set of PRD SAP systems are at the business process, data, and customization level?

Ian Greenhalgh: HCL has its own set of proprietary tools, HCL Insight+ for SAP, which we use to analyze different instances as part of an instance consolidation project. The tools are able to identify opportunities for:

  • Unused / partially used functionality
  • Process simplification opportunities
  • Process optimization opportunities
  • Process performance benchmarking
  • RICEF-W rationalization opportunities
  • Redundant data
  • Licensed user rationalization

In addition, they also look at systems from a technical perspective and help in making recommendations around:

  • SAP module / component rationalization
  • Server virtualization / rationalization
  • Archiving and data compression
  • Batch optimization
  • Landscape / infrastructure rationalization opportunities
  • Migration off x86
  • Migration to cloud

Comment from Arne Maagaard: We currently have ECC 6.0 EHP5 and CRM 7.0 EHP2 as our two primary applications. We are currently planning a migration project to HANA where we expect to consolidate these two systems on one HANA instance. We know that this also means upgrading ECC to EHP7 and CRM to EHP3, which we plan to do as part of the same project so that we can run one full test cycle with our business users. What recommendation can you give when it comes to preparing for this consolidation, and are there any things to consider when it comes to database schema, etc.?

Ian Greenhalgh: Sizing for the HANA appliances will be key for running both the ECC and CRM systems on one HANA “instance.” While MCOD (multiple components in one database) is available, there are several other options for running MCOS (multiple components one system) and multi-tenancy options. HANA SP11 will bring a great new functionality in this area and is scheduled for GA in the next couple of months.

Comment from Guest: What are key things to look at when analyzing our existing SAP installations prior to starting a consolidation project?

Ian Greenhalgh: We use a tools-based approach that seeks to identify several things, such as:

  • Which configured processes, code blocks, and custom developments are actually being used by the business?
  • How efficient are the existing SAP processes, etc.?
  • Manual intervention in processes
  • On-time in full process completion
  • Process re-work
  • Process durations
  • Process cost
  • Who is using SAP and to do what?
  • How does this correlate to ticket volumes?
  • How far away the configured SAP processes are from standard SAP

This analysis gives us factual insight into what is actually being used rather than what was configured. It’s not uncommon to find that heavily-customized processes are actually used very infrequently and have high associated error rates and support ticket volumes — and this makes them candidates for elimination or streamlining.

Equally, we regularly find large numbers of users who only use SAP for one thing, such as approvals or timesheets, so they struggle. This analysis finds out who these people are and allows us to consider moving them onto more intuitive platforms, whether it is Fiori, SharePoint, or another platform that has intrinsically low support and development costs. Wherever possible we try to steer the user back to standard / vanilla SAP as the solution set that is most robust and cheapest to support.

Comment from Sal: Is instance consolidation possible for global companies with regional instances? Can you supply examples of companies that have done this?

Ian Greenhalgh: It is absolutely possible to consolidate regional instances into a single global instance. We've worked with a number of global aerospace and defense manufacturers, all of whom operate a global single instance, the one exception being for one company that felt the compliance risk of having its China operations on the same instance as the rest of the world was too great.

It’s worth analyzing the reasons for the original regional instance policy — it might have been that the perceived database size was too great or that network latency would not deliver acceptable response times in Australia. Most of these reasons have now been at least technically resolved. If the issue was organizational / political, that’s clearly more difficult to solve, but it isn’t a technical reason. Another reason that’s often cited is data privacy and the need to comply with the country’s laws.

I have two views on this: First, most of the data that is held in SAP systems isn’t subject to data privacy regulations and second, where it does exist, the data can be encoded both inflight and at rest for relatively small additional costs.

The issue with data privacy is usually the unwillingness of the client to challenge the perceived law or the perceived risk. One company I’ve worked with didn’t want to take on the issue of exporting German data outside Germany, so they put the single instance in Germany.

Comment from Guest: How do you use the information gathered by your assessment tools to accelerate the consolidation project?

Ian Greenhalgh: The information tells us what is being used, what isn’t being used, and what’s broken. Each set of functionalities follows a different track.

For the functionality that is being used, we can be confident that it needs to form part of the core build, and hence our offshore configuration factories analyze the functionality in detail, streamline it where possible to remove obsolete custom code and enhancements, and then rebuild it in the clean single instance DEV client.

Where similar business processes are used in slightly different ways by different business units, we run design consolidation workshops to try to get them to agree on a common way of operating a process. For the broken processes, again we do a deeper analysis of what’s not working and why there are constant process blocks or excessive manual intervention. Armed with this data, we run process re-engineering workshops with business process owners to determine how best to streamline the process to reduce the current error rate and improve process efficiency.

In all of these cases, we try to use real data showing the cost of process inefficiencies to not just IT but also to business operations as a means of ensuring a fact-based, unemotional answer to questions.

Comment from AV: Does single, global instance translate to higher risks?

Ian Greenhalgh: I think that it’s often perceived that a single, global instance is a higher risk, but the reality often tends to be different. Because it’s a single, global instance, much more attention is paid to the design of the architecture, which ensures that it has an effective disaster recovery solution that is frequently tested and that it has been designed to meet specific RTOs and RPOs. It’s our observation that when an organization runs many SAP systems, this architectural rigor and even disaster recovery provisioning has not been included, making these systems high risk in themselves.

Comment from Sebastien: When talking about consolidation and back to vanilla, we usually think about Z code. However, consolidation is not only about programs, but also about processes as well as configuration. After running 20 years on two separate SAP ERP systems maintained by two different teams, it seems almost impossible to merge one ERP into the other. Is the recommendation to go with a third instance?

Ian Greenhalgh: If you’re running two different teams to support two different instances presumably on two different sets of infrastructure, you are hitting all of the cost components I mentioned in an earlier response.

Our approach is to use our Insight toolset on both environments to see what it is they are doing the same. As an example, many SAP implementations took the standard vanilla sales order types and renamed them ZZOR or Z01 or whatever; when you look into what they actually do, it’s not uncommon to find that even though they are perceived to be different, they are actually very similar.

Irrespective, if the two instances are so far from each other and standard SAP, I’d recommend an approach that uses the data generated by Insight as an input into a “why can’t we go back to standard SAP” set of workshops. It’s a known fact that SAP 20 years ago needed a whole host of enhancements, customizations, custom transactions, etc.; the latest releases have done away with the need for a huge number of these requirements.

Comment from Arne Maagaard: We are aware of the sizing issue when consolidating ERP and CRM on one HANA platform. What I would like to know more about is what are the possibilities we have when it comes to moving ERP and CRM to one HANA system — can we somehow put them on the same database to avoid all the BDOC integration traffic in our current environment?

Ian Greenhalgh: Putting both CRM and ECC into one HANA system, even in same DB, will not eliminate the BDOC communication at the application layer that is currently the standard integration pattern between ECC and CRM.

Comment from AV: What are key operational considerations for a single, global instance?

Ian Greenhalgh: The most common concerns that drive multiple instances as opposed to a global single instance are export control, planned / potential divestiture, network latency, and data privacy.

Comment from Guest: My company is evaluating S/4HANA. How can we best position our SAP environment now for a low-cost migration to S/4HANA later?

Ian Greenhalgh: We are currently rounding out our approach to S/4HANA migrations, but talking to many customers, almost all of them see the end goal as a single S/4HANA environment in place of the multitude of SAP systems that they currently operate. Put another way, irrespective of the S/4HANA migration, they’ll have to perform instance consolidation and system rationalization.

Our view is that any project that just attempts to technically upgrade to S/4HANA is likely to suffer a world of pain as it tries to iron out legacy configuration and customization across the different source systems, which is a long way of saying that our recommendation is clean it up and take the considerable benefits associated with running a single instance now, while paving the way for a much cleaner and trouble-free upgrade to S/4HANA when that comes.

Comment from Krushanu: If you already have a common single instance with FICO and FSCD, is SAP ready for FICO and FSCD both ported on HANA? If yes, when was the general release of FSCD on HANA, and if not, what is the roadmap? Are there any changes required in the database and applications (FICO and FSCD) due to a move on HANA? Assuming we are not moving to Simple Finance, how significant are those changes?

Ian Greenhalgh: Our understanding is that financial services collections and disbursement is part of Simple Finance. Simple Finance is still listed as 1.0, and we believe that FSCD has been part of the solution from the start. A move to HANA without S/4HANA will not require any changes in the application, but it does require NetWeaver 7.3.

Comment from AV: What are the compliance implications of instance consolidation in the life sciences industry?

Ian Greenhalgh: This is not a straightforward question, and the answer very much relates to the degree of synergies between your different business units and their supporting SAP instances. We have a global pharmaceutical client that has a regulated pharma business and an unregulated consumer-packaged goods business — their view is that the supply chain for the two business units is common, so there are huge benefits of having a single instance.

Conversely, we worked with a client who has a global single instance and acquired a regulated business that it intended to add to that single instance. When we analyzed it, it became clear that there were very little business and operational synergies between the acquired company and the rest of the business, and further, that the degree of business-driven SAP changes to the existing single instance would force a situation of almost constant revalidation if the regulated business was added to that single instance. In the end, the cost analysis showed that the costs of a single instance outweighed the benefits. I would say that this is an unusual case.

Comment from Guest: How do I avoid having to re-implement SAP at similar costs to the original implementations?

Ian Greenhalgh: The key here is not to tackle the consolidation in the same way as you did the original implementation. The difference between now and then is that you really know how SAP works. You fully understand the data model and the tradeoffs between different pieces of functionality, and you have tons of real data showing how your SAP systems have performed over the years, where there were challenges, and where manual workarounds were required.

If you leverage this data wisely, you can dramatically reduce the cost of a consolidation project versus an implementation. By way of example, you can rapidly identify the core 80% of standard functionality, which can be leveraged as vanilla SAP, and this can be configured offshore at minimum cost.

Comment from Guest: How will agility be preserved in the consolidated instance if the processes are not homogeneous?

Ian Greenhalgh: This is the conundrum. While you can deliver significant changes by migrating to a single “technical” instance, it’s only if you consolidate on a common set of business processes that you get the real and much greater business benefits.

Comment from Mike Zylstra: Can you please comment on SAP instance consolidation with regard to failover and DRP (disaster recovery plan) and improving service level agreements (SLAs)?

Ian Greenhalgh: Clearly the more you consolidate your SAP instances, the simpler the failover solution should be; for example, it’s easier to build, easier to test, and therefore likely to be more robust and cheaper if you only need a single failover option. One of the areas we are very interested in is DR to the cloud. When you think about it, failover is the most elastic compute event that you’ll have, so a cloud-based solution has huge potential savings.

Comment from Guest: Our company has three ECC instances supporting three somewhat distinct business units. How would you compare the level of effort of simply upgrading each instance separately as opposed to an effort to consolidate business practices and instances into a single, global template?

Ian Greenhalgh: It’s difficult to answer this question without having a better understanding of the extent of the upgrades that would be required. For example, if you are just contemplating a technical upgrade on your three instances, that will clearly be a lot lower cost than an upgrade in which you move to a more recent functionality (such as classic G/L to new G/L). Many of the benefits that I have talked about in this Q&A session are driven by a reduction in the number of systems, the required infrastructure to run them on, and a rationalization onto a common set of processes. The first two of these cannot be achieved without instance consolidation; the latter is very difficult to achieve across multiple instances.

Natalie Miller, Moderator: As we come to the end of today’s Q&A, I’d like to thank you all again for joining us. And a big thanks to Ian for his time today and these insightful answers!

Ian Greenhalgh: Thank you, Natalie. Readers, if you have any further questions relating to instance consolidation, please feel free to contact me at Also if you would like to get a copy of the Future of SAP survey that we conducted, you can download it here.

Natalie Miller, Moderator: Thanks again, everyone! It’s been a great discussion today. For even more information on this subject, you can check out Ian’s blogs on SAPinsiderOnline, where he further details how to reduce operational IT costs with SAP instance consolidation, "Save Millions Through the Consolidation of Your Company's SAP Instances," and takes about how to "Reduce IT Costs with a 3-Tiered Approach." You can also listen to a podcast with Ian as well, where he answers more questions about this topic of SAP instance consolidation!

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!