Sometimes, the variation between business models within an organization 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 standardized, consistent business processes across a geographically diverse organization.
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 organizational 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 organization.
Sign up for MIS Asia eNewsletters.