How to Compare Global Versus Single Software Instances of ERP

Executive Summary

• ERP is sold on the ability to be used as a single instance.
• Learn why the proposal that ERP works as a single instance is incorrect and what this means for projects.

Introduction to Global Instances

This article is based on real experiences taken from global software implementations. You will learn the positives and negatives associated with global instances.

How Accurate Are the Single Instance Benefits of ERP?

A primary selling point of ERP was that a company could move to a single instance of their ERP system. This idea continues to be a selling point of vendors such as SAP, even though, in most cases, only smaller companies have single instances of ERP.

“An ‘instance’ refers to the number of discreet versions of ERP software you have in your company. The original vision of ERP was that companies should have a single instance—that is, a single implementation of the software running on a single database— that serves the entire company. It would mean no duplication of information in different departments or in different geographic divisions and thus better integration and information quality across the company. Upgrading the software would also be easier than with multiple customized instances of ERP across the company.” — The ABCs of ERP

Historically, companies have been unable to move to a single instance of ERP, yet no one questions why, especially since this is presented as a desirable end state. As the complexity of a company increases with the addition of regions or subsidiaries, the value of having a single instance of an ERP system with only one database becomes questionable. Vendors know this but present a single instance as a desirable option that benefits the customer. The reasons why companies are unable to move to a single ERP instance are well documented and are not going away; some of the major causes are listed below:

1. Database Management and Query Efficiency: ERP systems are supposed to be single database systems, which belies their integration. There are issues with reduced efficiencies at higher data volumes, but what is the value of having sales figures from different subsidiaries that may have no relationship to each other in the same sales order table? For instance, if a user performs a query for all sales in a quarter, do they mean the sales of subsidiary one or subsidiary two? How do proponents of the single instance ERP system consider the increased complexity of the data in their presentation of this solution?
2. Which Region/Division/Subsidiary Gets Its Way?: If different regions do business differently and must move to a single instance, which region gets the system configured or customized to its requirements? What happens to the company’s productivity that gets its configuration adjusted for no other reason than the desire to normalize the functionality across the subsidiaries so that the move to a single ERP system can be facilitated? Most often it is the region with the political power (i.e., the region where the headquarters are located), and has absolutely nothing to do with logic or what is best for the business. I have been on several global implementations and would recommend to any independent contractor who could choose between a global implementation and a regional one to choose the latter. Global implementations are exercises in one region enforcing its will upon the other regions. At one client site, the region with the headquarters left out functionality that was available in the application when the new application was explained to the other regions. The functionality they left out would have allowed the application to be configured differently. They did this to prevent the other region from choosing a configuration different from what they had already decided. The region that selected the configuration assumed it was right for everyone, seeing as they had selected it. They called this the “Global Template,” a convenient way of getting the other regions to do things their way.
3. Negotiation Leverage: A single ERP system is considered a cost savings because more business is aggregated to one vendor. Surely this is a one-sided view on the matter: single sourcing also increases the negotiating leverage of the vendor (why they like it so much). What happens when the ERP vendor knows they have 100 percent of a customer’s ERP business? Well, this is just the starting point for Tier 1 ERP vendors; their eventual goal is to replace all enterprise software used by the company with their other applications, to turn the client’s IT infrastructure into a monoculture, and to staff the IT departments with 100 percent compliant executive decisionmakers. If this sounds vaguely familiar, it is because it is the same desire of every significant IT consulting company. When I first got into consulting, my KPMG partner explained that our role was to “penetrate” the client and then “radiate” through them.
4. What About Functionality?: From 30,000 feet up, it’s easy to state, “If we use one system, we can save money.” However, another side of the equation is the value the system provides. When a company moves to a monoculture, having regions/divisions/subsidiaries—the people who know the business, reduce the functionality benefits—choose their solutions. This leads to the next point.
5. How Much Does Customization Increase With a Single Solution?: Proponents of a single instance ERP leave this point out of the analysis for good reason. Using a single instance ERP system will mean more customization or taking a wrecking ball to the business requirements, as so many IT proponents prefer. However, customization translates to real money, both upfront and in long-term maintenance, and the costs must be estimated as part of a strategy of moving to a single instance ERP.
6. What About Flexibility?: Moving toward a single ERP system negatively impacts the company’s flexibility. If the acquisition is eventually sold, what is the cost of breaking the acquisition out from the combined ERP system? Hold on to your hats! Tier 1 ERP vendors are not doing this or have done the analysis but don’t want their customers to know the truth. Instead, they continue to bang the gong of single-instance ERP. In truth, that a single ERP system was never a realistic proposition should have been apparent to buyers from the beginning. It is now well documented that most companies do not have a single ERP system, and the reasons are pretty well explained.

The following quote is just one of many examples.

“Well, it sounded great on paper, but unfortunately reality bites. The stories started to leak out—multi-million dollar never-ending ERP projects, high profi le ERP project failures, inability to tailor the deployment to local subsidiary needs, and over-tapped local IT resources overwhelmed by a monolithic on-premise ERP deployment. And if a division is run as a profi t-center, these kinds of deployments can quickly paint red all over the P&L.” — The Decline of Single Instance ERP

The Use of Multiple ERP Systems

As the quotations below explain, multiple ERP systems in companies are now the norm, not just two or three ERP systems.

“On average, big companies worldwide are running fi ve SAP instances, while almost four in ten have more than six, according to a study from IT services firm HCL Technologies.” — When SAP Sprawl is Cool, ZDNet

“The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus, many companies ended up having several instances of the same ERP systems or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.” — The Trouble with Enterprise Software

According to one IDC survey, 72 percent of respondents ran multiple ERP systems. People will say that multiple ERP instances can be consolidated into one, but that is not practical in most cases. There are several excellent reasons why a company cannot reasonably be expected to move to a single ERP instance.

“‘A lot of people run multiple instances because of geographic reasons, regulations, or business-sector reasons,’ Illsley said. “If you’ve got part of your business that is outsourced, for example, you’d probably want to run an instance that your outsourcing provider could use and that would be different to the one you would want to keep inside, so that it’s easier to do things like that.” — When SAP Sprawl is Cool, ZDNet

How to Understand ERP as The Original Monolith

ERP systems can be considered the original monolithic system. This article covers what monolithic systems try to pretend to be based on microservices.

The Mother of All Monoliths, the ERP System and Its Influence on Present-Day IT

The ERP industry is massive and, because of this, infrequently criticized because of its enormous economic power. When ERP systems were first marketed, consulting companies became partners with packaged software companies, effectively parroting everything they said. Even to the point where almost no one in IT is aware that academic research going back to the 1980s on packaged ERP systems consistently shows the same results, a negative ROI. One author of this book, Shaun Snapp, covers this in The Real Story on ERP: Separating Fiction from Reality.

This is why the ERP system can be viewed as a Trojan Horse as is covered in the article How ERP System Was a Trojan Horse.

ERP implementations were instant money makers. ERP consulting firms were careful never to expose any problems with the ROI ERP systems. Everyone “knew” that ERP systems benefited companies. Also, if you had any doubts, you could read a report from Gartner that would say how good ERP systems were. Gartner is a “trustworthy” firm with significant undeclared revenues from ERP vendors.

ERP sales reps have done their job well, with software “stuffing” after the initial ERP sale being quite ordinary. Moreover, the maintenance of ERP systems has proven higher than anyone imagined. The estimates vary, but let us review some we could find.

• According to Rimini Street, 89% of the average IT budget is dedicated to keeping the lights on, leaving only 11% for innovative projects.[i]
• “Some agencies are spending 90 percent or more of their IT budgets on operations and maintenance. A report released last week found. The IDC Government Insights report found 77.7 percent of proposed agency IT budgets for the fiscal year 2017 are going to operations and maintenance, with the remaining portion dedicated to systems development and enhancement.” [ii]
• “The federal government spent more than 75 percent of the total amount budgeted for information technology (IT) for the fiscal year 2015 on operations and maintenance (O&M) investments.” [iii]

Stuffed Accounts

IT departments are so stuffed with unused or little-used software that a major complaint of SAP and Oracle sales reps is that they can’t get more growth from their current customers, which is why “net new” customers, which are customers who have never been SAP or Oracle customers, are considered so highly valued.

In the case of SAP, the question is how to unlock value from the massive investment made into the ERP system and the associated systems purchased by SAP customers. (Hint: it is not by buying more SAP).

• In some cases, it is decommissioning some SAP applications. Leveraging cloud services is a primary way to improve the investments made into SAP and ERP systems generally.
• There are many ways to unlock value from SAP environments, but they aren’t from leveraging more SAP or from leveraging most of what SAP has to offer, as most of the new things SAP offers don’t work out.

The first step is to stop listening to SAP or the SAP consulting partners who won’t tell their clients anything independently but repeat whatever SAP says. All of the advice from these entities leads right back to buying more of what SAP has to offer. And when it comes to the cloud, SAP is just a big pile of liability.

What is a Single Global Software Instance?

Let us discuss what a single global instance in enterprise software means. This is where the software is installed in one region, which is then used by multiple areas.

• Single Global Instance: An excellent example is when a multinational company installs an application in Germany. Still, this instance, not only the European region but the North American and Asian regions as well.
• Multiple Regional Instance: The opposite of a single global instance is a multiple instance implementation where each region has its software and hardware, which is run from a location within that region.

The Conceptual Appeal of Single Global Instances

Using a single global instance of software to support multiple regions is an appealing concept to many companies, and global instances work quite well under some circumstances.

Companies often like a single global instance, standardizing how the software is used within the enterprise. This restricts how the company can configure, customize, and use the software by region and is consistent with a particular philosophy where IT is emphasized over the business.

IT organizations look for maximum IT efficiency, which means systems that can be applied to most users with the lowest IT infrastructure. Email and communication systems are excellent examples of systems that scale very well and exhibit little need for variance per region.

The Single Global Instance Concept Generally

When a global software instance is used for supply chain planning, where I have worked on many projects, it typically leads to projections that the planning will finally be “integrated” between the different regions.

Multinationals will often transfer materials between the regions. This transaction is covered by either purchase orders (which behave as if the two companies are foreign companies to one another) or preferably intra-company stock transport orders).

However, this results in other complexities that are easy to gloss over during the high-level planning sessions before the project begins. Two of the major complications are listed below:

1. Uptime: All applications require their uptime to be coordinated when supporting regions across different time zones. A single global instance means downtime is harder to organize.
2. Processing Time: For applications that require substantial processing (and not all do), the processing schedule must also be coordinated between the regions. For instance, if an application runs a procedure, it may lock the activities for other areas, such that the people in the “up” regions may not even be able to change the data. This means that a coordinated “batch scheduled” of when processing is run. For those interested in the details on this topic, which explain the challenges, I cover some of them in this article.

Applications that require substantial processing reduce the ability of an application to be set up” as a single global instance. Secondly, the processing time for batch jobs may seem manageable at a high level but can turn out to be a problem once the jobs are scheduled, leading to contention once the software has been implemented.

Regional Management of Instances

Companies that are experienced and advanced in their use of APO may have two regions up on SNP, but often not the third. Living with multiple regions does not necessarily mean the implementations were planned effectively between the regions. Whether they are or not is strongly related to the organizational planning design within companies. Some companies, particularly companies that rely on 100% outsourced manufacturing, perform all planning in one country, but it is more of a rarity.

While there is much discussion of the “global economy,” supply chain planning continues to be regional and, in many cases, a local affair.

Planners who understand the local markets provide an edge over global planning. At least, that is the storyline.

Decentralized Planning

Most companies have decentralized planning (Europe planners plan European supply networks, US planners for the US supply network, Latin American planners for et…). Multiple planning departments mean different ways of doing things, various directors and VPs, and traditional political rivalries. While companies accept regional planning organizations, most view having all regions on a single planning system as desirable. It is no simple matter to meet this objective. When implementing supply planning globally, the following issues arise.

1. When the processing is performed daily, will the processing load impact the system’s responsiveness, and will users be locked out of their user interface? Setting up a global system means analyzing the technical implications of how supply planning processing jobs are set up. This includes locking planning books for product locations processed by a supply planning method. Evaluating issues of contention leads to implications for hardware sizing, the methods selected, and how the various planning runs are set up.
2. Supply planning systems have a structured way of transferring demand through the supply network, as is described in detail in this link. The situation does not change when locations are in different international regions. It will move distribution demand between locations in the same way. Suppose a location in Ohio has a supply source in Hungary, and the operational workflow only processes US locations during one-period distribution. In that case, demand will be created for the Hungary location. The Hungary location will have to wait until the European threads are processed for distribution receipts and planned orders to be built in that factory. Processing the supply network for the entire globe once per week could eliminate this issue. (this way, all regions would be synchronized when they start work on Mondays. It should be noted that there is no simple 48-hour window in which to perform processing. Instead, the window is when the last region closes for business on Friday, and the first region opens for business on Monday morning.) The regional processing model and its implications for what appears and when it seems at other the locations which is a source of supply, is shown in the graphic below:
3. When a global instance is used, while the initial supply plan and deployment plans are required to be globally aware, the rough cut capacity/ S&OP / MPS plan and the redeployment plan are not. This is because rough-cut capacity / S&OP / MPS planning is regional. Secondly, redeployment is also regional. Therefore, these plans’ processing and coordination needs are lower than for the initial supply and deployment plans.

The Global Schedule for the Supply Planning System

The different methods for the S&OP/ MPS/ Rough Cut capacity plan and the initial supply plan are listed (in SNP) (in an example SAP SNP supply planning system) below:

Regional Differences in Political Power and Conflicting Interests

A problem with single global instance implementations is they often lead to seemingly endless debates with the other regions as to how the system will be configured, and each region has a strong tendency to believe that the configuration settings that work for them should be the ones to be used in the global instance.

What is supposedly cooperative will often become competitive once control of a customized and highly configurable application is in play.

Typically, the region where the company is headquartered gets its way – and the other regions must deal with a poorly configured system for their needs. Putting the needs of the outlying regions on a second level is a great way to have the regional users reduce their use of the system.

Secondly, the more one gets into how each region manages its business, the more the differences in how the business operates become apparent. This lengthens both the time of the implementation as well as the risk of the implementation. These are, of course, significant issues to be considered before giving the thumbs up on a single global instance.

Getting the Real Story on an Application from the Hosting Region (Headquarters)

In the 1st article in this series, I pointed out that typically, the region where the company is headquartered gets its way – and the other regions must deal with a system that is maybe poorly configured for their needs. Putting the needs of the outlying regions on a second level is an excellent way to have the regional users reduce their use of the system. Having participated in global rollouts, I can say that headquarters getting its way most often has nothing to do with “best practices” or choosing the best design. Instead, it is often merely the group based at headquarters and, therefore, has the power that gets its way.

Secondly, there are specific ways in which this can be accomplished in a way that can be hidden, to restrict the choices of the other regions, but without coming out directly saying to the regions that they had their options limited.

Is the functionality a secret of being tightly controlled and kept from the other regions? The country where the headquarters is located typically implements first, and therefore, they are at a great informational advantage versus the other regions.

How Headquarters Can Steer Application Design Decisions

Even where documentation exists on the functionality in question, they can be told by the IT support team at headquarters that the functionality “was tested and just did not work properly or simply did not meet the business requirements.” Especially in the early parts of the rollouts for the other regions, where many of the decisions are made, there tends to be a natural trust in the information that comes out of headquarters regarding the application. The knowledge difference between a group that has already participated in implementation versus a group that is beginning an implementation is enormous. Not all implementations begin at the headquarters region before they are rolled out to other regions, but many do.

The experience above came from a global implementation where I worked. In this case, the region (where headquarters was located) that first implemented the software deliberately misled the other regions as to what functionality was available so that the system would only be configured the way they wanted it to be rather than letting the other regions know the whole story of what the application could do.

The other regions paid for the system (through transfer payments to the headquarter region) just as the headquarters did, however, their ability to get the system to fit their needs was quite small. The IT support organization worked at headquarters, and their bosses all worked there, so the regions had very little sway over the overseas IT organization.

Standardization sounds nice, but it often means a reduction in the ability to adjust locally and the “standards” determined by people who don’t have the best interests or who understand or are interested in the complications of local individuals and institutions.

Positives and Negatives of Standardization

Standardization works when the variances are minor, and the benefits from standardization are clear.

• The metric system is an example of a standard that benefits those who adopt it. The metric system takes the time to implement. Still, it is undeniably superior to the imperial system, and once adopted, the country is better integrated into other countries in its weights and measures.
• Some standards are presented as virtuous when, in fact, they merely benefit the entity that is in the position to determine the standard that will be set. Colonialization is one example of this type of standardization, which consists of a series of rules and regulations passed and enforced by the ruling entity for the primary benefit of the governing body.

Thus, while companies may look integrated between their regions from the outside looking in, I have found from some projects that the firm’s regions primarily care about themselves first. One region cannot trust other regions to perform solution design for them.

Meeting Business Requirements

While there is a wide variety of business requirements in companies, which can often differ significantly based on the region, IT departments will frequently attempt to generalize the business requirements to present them as more uniform than they may be. This allows more regions (in the case of a multinational), at least in concept, to use a single global instance of an application. However, are the total costs lower once one moves to a single global instance?

The answer to this depends on the business requirements and how the implementation is performed.

Business needs drive differences regarding how applications need to be configured. Suppose one region requires configuration and follows a particular business process that another region will not follow. In that case, there can be difficulty in using a single instance, reducing the benefits of going with a single global install.

The second question is whether the business value is as high with a single global instance versus multiple regional instances. I will provide an example of where the business value is, in fact, higher when a single global instance is used.

Identifying Opportunities for Using Single Global Instances by Enterprise Application Category

Some categories of enterprise applications make a lot of sense to have as a single instance.

One is the bill of material management software (aka Product Life Cycle software or PLM). This software allows multiple departments within companies to collaborate on the draft law of equipment – it also will enable suppliers and contract manufacturers to work on the BOM. Also, it is of primary importance for both the efficiency of product development and design and for enabling the company to get a better price. This is because more suppliers can bid on the BOM components. BOM/PLM software does not usually need to be individually configured for different regions.

For instance, the BOM management company Arena Solutions provides a SaaS solution to many customers from a single global instance, which services all clients. This is where a vendor supports multiple customers who may use the application globally from a single global instance. Still, there are divisions between the customers, so they can’t see each other’s data.

Having a single global instance of a BOM or PLM system is incredibly important for this type of software. The BOM is probably the most collaborative master data object in systems.

Not only should different regions collaborate on the same BOM information, but suppliers and other partners should also be logged into a single system with an excellent security model.

How the BOM is Shared

The BOM is shared and sits between some applications and interfaces with users inside and outside of the company, which controls the BOM.

When a vendor works in a software category of this type, they can substantially reduce the costs of delivering the application as well as increase its functionality. Another application group that is also not coincidentally often sold under the SaaS model, which typically requires little customization and has light configuration, is CRM.  PLM and CRM software are good candidates for single global instance implementations.

However, the more configuration, customization, and configuration any application requires, the more difficult it is to make those applications a single instance. ERP applications are some of the most intensively customized applications in any software category.

From the examples provided above, it should be clear that the discussion of the costs and benefits regarding a single global instance versus multiple regional instances very much changes depending upon the enterprise application category. This is true, as well as the degree of similarity in the configuration and customization of applications — which are questions specific to the company.

How The Cost Categories Change

We have estimated the cost components to single versus multiple instance implementations at our quantification research site. It is essential to have this adjustment regarding estimation because the costs change in different areas depending upon whether single or multiple instances are used. (other factors are essential to adjust for as well, including the following)

1. The Number of Software Instances
2. The Number of Languages Supported
3. The Number of Regions Supported

The following costs behave the following way as a company moves from a single instance to multiple instances:

1. Maintenance Costs: Increase
2. Hardware Costs: Increase (although hardware costs are such a low percentage of the total cost of ownership of any enterprise software application that this is not a deciding factor)
3. Implementation Costs: Decrease. Single instances – for most applications (those requiring more specific configuration) mean more effort in driving to compromise on how the software will be configured. This is because the configuration will serve the needs of some regions, subsidiaries, etc.. but not others.
4. Software Costs: Neutral

All of this drives towards costs. And as much as I like calculating TCO, TCO has nothing to do with benefits received from an application.

As I stated in the second article in this series, costs should not be the determining factor in an IT strategy. Any concept that reduces the fit of the application to the business reduces the probability of success of that application and, therefore, its ROI. If application implementation were simply about costs, we would select the cheapest applications, the least experienced consultants, and the lowest cost outsourced IT support available on the market. So, costs do not define the ROI.

Conclusion

It should not be accepted blindly that single global instance applications save money and offer the same business capabilities as multi-instance regional implementations. This applies particularly when the application is processor-intensive and requires significant configuration or customization (and substantial to moderate variances from region to region). It also means substantially increasing the risk of the project.

CIOs or IT department heads often oversimplify the trade-offs inherent to the global versus regional instance question. This is because the IT cost is often lower, but that is not all of the expenses, as seen if the headquarters region controls the functionality and design used in other regions. The other regions can end up with a system designed to meet the needs of the headquarters region but which does not meet the needs of the outlying regions. That is a problem.