Expand +



HCL's Ian Greenhalgh on the Importance of Consolidating Your SAP Instances

by Ian Greenhalgh, Head of Applications Strategy, HCL Technologies

October 27, 2015


Ian Greenhalgh, Head of Applications Strategy at HCL Technologies, shares his insights on how to implement an SAP instance consolidation strategy that will not only lower your company's IT operating costs, but also set you up for a successful, less coslty migration to SAP S/4HANA.

In this podcast, Ian discusses:

  • A brief overview of what instance consolidation is and why it is so critical for overall IT cost reduction
  • His strategy for executing a successful consolidation project
  • Tips for how companies should best analyze it's existing infrastructure prior to consolidation
  • What types of savings businesses should expect from a consolidation project
  • The benefits of consolidating SAP instances now in preparation for an eventual migration to SAP S/4HANA
  • What companies should know about choosing the best vendor

Listen to the podcast, and read the edited version of the transcript below.

For more information about SAP instance consolidation, read Ian's two blogs on the subject: "Reduce IT Costs with a 3-Tiered Approach" and "Save Millions Through the Consolidation of Your Company’s SAP Instances." You can also check out the chat replay or read the full transcript of Ian's recent SAPinsider Live Q&A and read his answers to readers' questions on this subject.

Or to contact HCL, email

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.


Natalie Miller: Hello, this is Natalie Miller, features editor at SAPinsider, and welcome to the SAPinsider podcast. Today I am joined by Ian Greenhalgh, Head of Applications Strategy at HCL Technologies, who is here to talk about instance consolidation as a vehicle for reducing operational IT costs associated with running SAP.

Hi Ian, thank you so much for joining me today.

Ian Greenhalgh: Hi, Natalie.

Natalie: With organizations’ IT budgets straining under new innovations and infrastructure upkeep, cost reduction strategies are more really important. You previously mentioned an HCL study that found that companies currently running multiple SAP production instances are incurring operations and maintenance costs 30-40% higher than companies operating a single, enterprise-wide instance. That’s quite a percentage.

Can you start us off today by giving a brief overview of what instance consolidation is and what makes it an important strategy in reducing IT costs?

Ian: Sure. An instance consolidation program looks at all of the separate instances that an organization has running SAP; and depending on the history of that organization, its history of mergers and acquisitions, and how it actually implemented SAP, there can be a significant number of SAP instances. So, again, depending on the size of the organization — there is a fairly notorious car manufacture who had 300 SAP instances in just one factory alone — each of those instances obviously has the infrastructure it runs on, it requires some degree of support and maintenance, they are a whole host of potential interfaces between those different instances, and also the manual or pseudo-manual reconciliation between them to produce reports that consolidate data from those separate instances. So, we did this survey a couple of years ago, and what we discovered is what we suspected — that A., there are a lot of instances out there, and B., some of those instances are very old. One of the survey findings was that about 44% of survey respondents were running at least one version of 4.7 or older, which is now well out of support. The consequence of that, linked to all of the sources of costs that I just mentioned, meant that they were paying significantly above the cost of running a single instance.

Natalie: So, having 300 instances just in one factory alone, that seems like quite a big project. Can you talk a little bit about what exactly an instance consolidation project would entail, maybe a high-level overview of the process?

Ian: So I think what it isn’t, first, or what it mustn’t be, is a reimplementation. Because if it’s a reimplementation, then, rightly so a lot of stakeholders will start to get nervous that the project will cost as much as the original project or projects, which many organizations spend hundreds of millions if not more implementing these systems over time. Our view is that there’s absolutely no point not learning from the huge history that organizations have running these SAP systems. And when I say history, I don’t just mean the support calls and the support issues and the logs that they collect on a daily basis to manage these systems. I mean what is actually put into those SAP systems.

The approach that we take is a very tools-based approach, which is to analyze those systems using a set of tools, which we call HCL Insight+.  We run them against the instances that are in scope for consolidation and really try to understand not only how they are configured and customized, but how that configuration and customization is being used. So just because once upon a time in a project somebody actually configured, for example, 320 pricing condition types, that doesn’t mean that in the day-to-day operations of that company, all 320 of those pricing condition types are utilized. There is no better evidence of that than actually running the tool against the individual SAP systems to show that actually — and again, this is real data — in that particular case, of the 320 configured pricing conditions, only about 40 were ever used. And, I think, it was over 98.5% of all sales orders and associated invoices, only actually used 12 condition types.

Armed with that real data, you are able to say, ‘Well, actually we don’t need the effort, the design effort, the build effort, or the test effort associated with320 condition types, we can actually focus them down to 12.’ Now, it’s not as simple as just cutting them to get from 320 to 12. There are those that are used very infrequently, and there’s obviously some degree of customer interaction required to say, ‘Listen, you’re using a pricing type that you only use once a year, and it would be in all our interest to rationalize that.’ In the case I mentioned, when they did that exercise, they were able to rationalize it down from 320 to 12, and in the process, there was only one customer out of — I can’t remember — several hundred thousand who refused to give up that particular pricing structure or that pricing type. And in the end, that particular company said, ‘Well, actually, the cost of doing business with that particular customer is too high so we’re not going to do that.’

So step one is to understand how people are actually using these SAP systems; step two is to understand how far from vanilla SAP they are; and then step three is, based on the data, based on the analysis of the configuration, based on the future SAP roadmap, to propose the consolidated SAP instance solution footprint that will support what actually happens. And in doing that, we try to adopt this approach, which we call SAP minimal viable product, which is to understand what is the smallest SAP vanilla configured footprint that can be implemented, configured, tested, and deployed to support what the business actually does on this future SAP solution.

Part of the reason that we do that is, again, both as a result of the analyses that we’ve done on a large number of SAP instances across a bunch of clients, but also based on the acknowledged fact that when these projects started, however long ago, like any big project it attracts a bunch of people who want to get their pet requirement implemented via the big project mechanism. So they see large projects as an opportunity to get something they always wanted to do into the organizations’ systems environment, and sure enough, when you actually look at a lot of these things several years after implementation, they are either not used or partially used. And to us, that’s just a waste. It’s a waste in terms of the redesign, rebuild, retest effort, but also, it is reasonably obvious that partially-used functionality is more likely to generate support issues, support tickets, and support queries, then very frequently used and therefore better-known and more robust functionality.

Our message is, let’s understand what’s there, let’s understand how it’s used, let’s take it back as close as possible to the vanilla solution, and let’s make sure it’s not over-engineered and there’s not too much of a footprint out there.

Natalie: Can you share a few tips on how businesses should, as you were just talking about analyzing their existing infrastructure, what are some tips for companies starting out this process.

Ian: If organizations with multiple instances are doing it properly, they need a full dev test support environment for each of those instances. Now, obviously, if you consolidate those, the single instance will be larger than the individual instances, but you still only need one promote-to-production path and support path for that instance. What we think about infrastructure is that a consolidation project like this is a great opportunity for an organization to review its infrastructure strategy and standards. Obviously, a bunch of this depends on the nature of, is it in house, is it outsourced, has it migrated to the cloud, where that particular organization is in the contract with an outsourced supplier, where they are in terms of hardware refreshes, and things like that. But there is a whole bunch of data out there that shows that if you put your SAP systems into a cloud, if you are prepared to take the step as far as a public cloud, there are some pretty significant cost savings that can be generated. So to us — understand what you got, understand if you have any constraints around data protection, security, whatever — this is a fantastic opportunity to consider moving a proportion of the estate (it doesn’t necessarily have to include production systems, but we have clients who do that) to the public cloud and generate pretty significant cost savings.

Natalie: Speaking of cost savings, what kind of cost reduction can companies expect from an instance consolidation project?

Ian: We broadly see three or four areas of cost savings. One is the infrastructure savings, which we just talked about, which comes down to fewer discrete instances. Two, the option for reduced disaster recovery costs from having one disaster recovery site or one disaster recovery solution as opposed to many, and three, reduced licensing costs associated with having less infrastructure, less operating systems, database licenses, whatever. And four, reduce support costs associated with running a smaller number of environments — you have to apply patches to one set of environments, not 50 sets of environments, or in that other case, 300 sets of environments.

By moving to single instance — which we try to ensure implies a single concert of processes rather than different processes by instance — there is a concert of processes, which means those processes are used more frequently. This means there’s a greater knowledge base within the house. By moving back to standard SAP, there is significantly more knowledge about the solution. Our observation, and this is measured information from a bunch of clients, is that if you move to the single instance, purely from a let’s rationalize the process, let’s rationalize the technology, let’s rationalize the footprint, there’s a lower cost of IT operations and support. If you go through with this SAP minimal viable product idea, then depending on how your software license agreement is structured, there is an opportunity to reduce your ongoing maintenance costs. Some organizations have a negotiated agreement where they only actually pay maintenance on the components they used, not what was in the original bill of materials. And in certain circumstances, that change can be quite dramatic. And then it’s not just IT, there are business process benefits, both from an upside and from a business process cost. So, I touched on it before about having a single set of processes, having a single system means you have a common mass of data, common understanding of key metrics. That makes consolidation and comparison of data between different sites, different instances, and different parts of the business that much easier. It means that any data quality issues are that much more apparent because there is only one set of data and only one set of processes, so if something is wrong, it’s highly visible — you don’t have to reconcile it against other systems and try to determine the root cause, it’s fairly clear what’s wrong. It allows you to have a much faster, much better understanding of actual performance out in the business. So that means that when you work different divisions, performing at different levels, it’s that much more apparent, it’s visible immediately as opposed to having to request the data reconcilement and produce it. This means following best in class internally becomes that much easier.

There’s a whole load of those and obviously it is specific to the particular organization. But there are significant IT benefits; there are probably even greater business process benefits.

Natalie: Many organizations today are evaluating a possible migration to SAP S/4HANA; what are the benefits of consolidating SAP instances now, and can you talk a little bit about how that relates to migration to SAP HANA?

Ian: Our view is that S/4, as it is rolled out, is a different code base, so it does things in a different way. So although you can migrate to it, you probably wouldn’t do that. You probably want to do what you would do for any normal implementation, which is to streamline the variability of your processes and your requirements such that it is easier to implement a streamlined, cleaner solution on effectively new technology. So to us, the sensible thing is to consolidate, streamline, and clean up now, such that when there is sufficient confidence in the S/4 finance and S/4 simple logistic solutions, that migration becomes a much more technical solution rather than a functional solution. That’s not just being self-serving saying that; I think given the huge benefits in running a single, consolidated instance as opposed to the current proliferation of instances, consolidating now obviously accelerates those benefits and then, when and if the requirements to move to S/4 exist, it’s a much simpler, much less painful migration than it would otherwise be.

Natalie: So this project isn't really something that organizations can likely tackle with their in-house resources. What are your insights on how to choose the right vendor? I know you talked about tools earlier that HCL uses to help their clients. Can you talk a little bit about some tips that companies should consider when evaluating how to begin this process?

Ian: Sure, so to me, if a vendor that you are considering says that this is a complete reimplementation, then they are ignoring the skill, knowledge, and information that is available to them in your organization, and you should probably disregard them pretty much immediately.

How do you leverage that information? You can do it manually, but that’s pretty expensive. So, look at organizations that have developed tools to do this and who have a proven record in accelerating these consolidations. If a consolidation is going take two years, obviously I’m speaking generally here, but if a consolidation program looks the same in duration as a reimplementation would then, again, they probably have the wrong end of the stick. So, [you should choose] an organization that can show that it has used tools and available information to accelerate these implementations dramatically.  We see 40-50% accelerations of this type of project versus a traditional reimplementation.

The other key thing is, building on the fact that you are an experienced SAP user, your desire is to get standard SAP on a single instance, so it’s not just analysis tools that I talked about earlier, it’s also the approach to build the new instance, to test the new instance, to migrate the data — and again, what we’ve done is we’ve industrialized that, pretty much as far as we can go, so we’ve got a series of off-shore industrial capabilities that do configuration, that do testing, that do validate the cleanse in migration, that rebuild interfaces for new landscapes, etc. So I think it’s that combination of, people need to have the tools that do this, they need to have the track record that shows they can do it faster than what would otherwise be the case, and they need to have that industrialized approach so you’re not paying for this being a one-off build.

Natalie: Ok, great. Well thank you, Ian, this has been really interesting, and I appreciate you being here and sharing your insights on this topic of instance consolidation. Thank you so much.

Ian: Thank you, Natalie.

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!