In today’s rapidly changing and globalised business environment, even traditional mid-market companies are becoming global enterprises — but without the large IT organisations and structures of traditional, large scale multi-nationals.
This means that more and more companies are developing an interest in global ERP, and are confronting daunting barriers to getting to their goal of a single global ERP instance.
Global enterprise resource planning (ERP) is sometimes defined as the integration of a global, multinational corporation’s business on a single instance of an ERP product and on a single database. But that definition is probably too narrow, as a company with multiple sites or divisions within a single large country may face many of the same challenges as a multinational, and can also benefit from standardising on a single ERP instance.
In this article, we explore the challenges and benefits of achieving global ERP, and take a close look at why some companies that would very much like to get to that global instance of ERP just can’t get there.
Why Achieve Global ERP?
There are really two reasons so many companies would very much like to get to a global instance of ERP. The most universal reason is that consolidation of IT assets can drive down overall IT cost.
It is costly to run multiple enterprise software applications with multiple license agreements, different support agreements in different countries and different hardware. From a cost standpoint, global ERP allows consolidation of these IT resources in one location where you can build centers of excellence, consolidate license management and pool your negotiation possibilities.
In order to achieve many of these cost efficiencies, it is not necessary to run on a common database, but rather out of a common data centre. But over and above IT resource consolidation, global ERP can allow for process consolidation across far flung and diverse business interests in different geographies. Running the same instance of an enterprise application is one way to ensure that consistent processes are being used to achieve consistent quality results. It also allows for efficiencies across a global organisation by eliminating things like duplicate part numbers and streamlining intra-company transactions. The global instance also provides senior management with visibility of the global organisation through one data model across all enterprises and entities. The company can serve customers better once it can refer to a customer by a single customer number no matter what geography they are in.
So simply put, achieving global ERP is one way for a CIO to drive down cost while driving up business value.
No Shortage of Impediments
As is the case with any worthwhile venture, there are different challenges to overcome when moving towards that single global ERP instance. The greater the degree of consolidation, the greater the benefit and the greater the challenge, with the ultimate gold standard being consolidation of IT assets down to a single enterprise application release and a single database that supports the entire enterprise typically through multi company or multi site views.
Sometimes the ideal solution may turn out to be a single data center with a couple different databases but one application code where you can handle different divisions or collections of divisions that have radically different data models and are difficult to consolidate on the database level. But at the very least, the goal ought to be consolidating down to a very small number of databases and data models and a single application instance — or a couple application instances at most — that support all of your different operations.
The biggest challenges turn out to be not difficulties with hardware or software, but rather with the people involved in the process. Five to 10 years ago, when we talked a lot about global single instance, the technology was there to support it, but only in major cities in developed countries around the world. While it requires careful planning, at this point it is fairly certain that a company can get the bandwidth with maximum latencies required to connect users from wherever they are in the world. Certain parts of the developing world still have some challenges with connectivity, but most locations where a company might set up a distribution hub or a manufacturing facility, or where a sales manager may need to access customer relationship management (CRM) software are adequately served.
Regional barriers including multiple languages, time zones, currencies and units of measure are typically handled effectively by a modern enterprise software product. There may be limits to the number of languages and currencies supported by some products, and that ought to be a factor in selecting ERP for a global instance. But the primary barriers to this high level of global consolidation have to do with people rather than technology.
One concern is whether or not all of your different divisions can agree on a common set of standards like product nomenclature, customer naming conventions, customer views and credit management policies across different divisions around the world. As you move into a single data model, each entity has some ability to make adjustments to deal with their regional issues, but fundamentally, you are dealing with similar processes and a common set of master data. From a business standpoint, this can be a very positive thing, but each division may find it unappealing to, for instance, renumber hundreds or thousands of parts or restructure some of their supply chain or remanufacturing data to comply with a new corporate data standard.
Other impediments are inherent in how the different divisions or entities want to use the software. Most software today like IFS Applications is highly configurable and flexible, and can be modeled to conform to various business processes within an operating unit. But there is often a limit to how much variability you can achieve with a single instance of an application. That means that achieving global ERP requires overcoming some resistance to change, overcoming resistance to commonality. All of these are management problems rather than software problems, so they can be overcome by a strong ERP project team that has solid management backing.
Sometimes, the variation between business models within an organisation and the different philosophies on how you run the business, make getting to that gold standard of the single instance impractical. If you have two different divisions in radically different lines of business, asking them to conform to the same types of interfaces or data exchange frequencies and accept the same software model may require too much work. In that case, you may want to have a consolidated IT infrastructure with a couple of data models that can adequately accommodate both of them.
If you are running a hybrid model where some divisions are on a global system and others are not, are running the same application suite enterprise-wide but with different implementation models or have a multi-product strategy where different divisions are using different enterprise software products, your situation starts to get a lot more convoluted.
In these cases, you can build front end portals that provide views into these different applications across the enterprise. One common way to do this is to build a data warehouse and extract, transform and load data from these diverse applications to deliver a common view of data from across these multiple applications. This is done purely for purposes and information consolidation.
While a data warehouse may offer a tool for consolidated reporting and viewing of data, it can be difficult to achieve from a technical standpoint as well as a data modeling standpoint. Differences between the way different applications interpret data mean that certain quantities, part numbers or structures in your disparate systems may be in different states and therefore must be interpreted differently. What that means is that, when you get that data into the data warehouse, things don’t always make sense.
Another downside of using a data warehouse as a substitute for global ERP is that this is typically a one-way street. You will typically be pulling data out of your transactional systems and into your data warehouse, massaging the data along the way. And that always opens the door for data consistency problems where the transactional system says one thing and the data warehouse says something slightly different. So if you do build that, the ability to move backward from the data warehouse to the source system for auditability must be a consideration.
Conclusion: Selection and Implementation
There is a strong business case for moving to a global instance of ERP. Getting to a single global instance can reduce cost, increase global visibility, accelerate decision-making and extend standardised, consistent business processes across a geographically diverse organisation.
Selecting an ERP application for a global instance requires that some specific questions be asked at the beginning of the process. For instance, can the software handle the “multi-multis” … the multiple currencies, the multiple languages, multiple units of measure, multiple sites, multiple manufacturing modes or business models, multiple organisational structures or hierarchy of sites. Lacking this degree of flexibility, it is unlikely that an enterprise software product can satisfy current much less future needs across a global organisation.
It is also important to determine how much experience the ERP vendor or Systems Integrator has when implementing across multiple geographies. An implementation organization must know how to navigate not just the IT challenges, but the human factors of a diverse implementation.
A successful selection and implementation also requires that the implementation methodology used supports a phased implementation approach. Global ERP is typically not implemented all at once. Individual countries or sites are implemented in steps to reduce the disruption of the enterprise. Your enterprise software partner must not only offer software that is flexible enough to do this, but needs to be capable of planning your entire global implementation in advance so that you arrive at a successful global instance even though you will be rolling out one phase at a time. Your implementation partner needs to guide you through the process so that you do not implement one or two sites and then find that your configuration is incompatible with subsequent sites. It is imperative that the implementation plan address the entire project holistically going in to avoid false starts, rework and cost and timeline over-runs.
Selecting an ERP application and implementing a global single instance can be challenging, but the benefits and return on investment can be considerable.
Rick Veague is Chief Technology Officer with IFS North America, and is based at the company’s Itasca headquarters. In this role, Veague provides direction for IFS’ use of Service-Oriented Architecture (SOA) and works with IFS Applications leading users throughout North America to leverage SOA to provide state-of-the-art ERP.