Back in the old days (20 years ago or so) companies that wanted to expand or update their telephone systems had to do what was called a “forklift migration.” In other words, they had to remove big, heavy and very expensive boxes of electronics from an equipment room and replace them with newer big, heavy and very expensive boxes. The process of adding, deleting or changing people, offices and phone numbers was equally burdensome and costly. This all seems quaint now because digital telephony and voice over IP (VOIP) have completely changed the technology underpinnings of voice communications. I bring this up because we may be on the verge of substantially reducing the “forklift migration” equivalent of replacing or updating on-premises ERP systems and other enterprise software. This possibility is important for software vendors as well as users. Retaining a maintenance base and revenue stream has become a key strategic objective for any enterprise software provider. In North America in particular, companies that have outgrown their enterprise system or want to replace it almost never exhibit total brand loyalty. Instead they begin the replacement process by looking at alternatives, winnow it down to a short list and then select the best of the lot. If migration is as much work as implementing a new system, organizations are likely to view replacement as an equally attractive option, increasing the probability that the incumbent vendor will lose a customer. But if there’s little pain in changing an ERP system to acquire new functional capabilities or meet other objectives, incumbent vendors stand to benefit.

It seems to me that facilitating migration is the rationale behind Oracle’s creation of a data integration hub (which I covered in a blog last fall). Infor also is heading in the same direction for the same reason. (SAP doesn’t have this problem because it hasn’t pursued a roll-up strategy.) Software companies that have acquired a set of similar business applications software vendors have a big incentive to move established customers onto a new or substantially updated system. Reducing migration pain makes it much easier for them to keep customers on maintenance and hold onto an important and highly profitable source of revenue. Moreover, it’s a way for these vendors to consolidate the number of code bases they are maintaining, which will offer operating savings. Easing migration to a more capable, standard platform will benefit vendors that provide this option to its users. I expect companies that are operating multiple enterprise systems from different software companies will be more likely to standardize on the system that is easiest to consolidate – if their features and capabilities are roughly the same.

 Oracle and Infor take the approach of constantly feeding data from each of their applications to a multidimensional data store. This immediately enables them to use the data store for business intelligence and analytics. (SAP achieves much the same result with its HANA In-Memory Appliance software and promises to deliver multidimensional capabilities in future versions, which my colleague David Menninger recently discussed.) Since a company may have a broad range of functional applications feeding this data store, it also becomes easier for users to perform complex analytics because more information is centralized and therefore more accessible to a larger number of individuals and business analysts. For example, since it dispenses with the traditional financial ledger structure, it’s possible to do some degree of instant consolidation of financial data. (This can be complete or nearly complete for internal business reporting although likely not for statutory accounting purposes.)

Both Oracle and Infor plan to run their next generation of enterprise applications on a multidimensional database. The effect of this should be that when the time comes to switch from, say, Oracle’s PeopleSoft to its Fusion Financials, or from SyteLine or Baan to Infor’s next-generation ERP system, it will involve considerably less effort from the standpoint of handling the database layer since few if any changes would be required, if you don’t want them. (One exception would be if a company decides to split a set of data among two or more dimensions.) If the software vendor keeps the user interface (UI) in its next generation the same as one available in legacy products, it can eliminate or substantially reduce employee training and learning curves in adapting to a new UI or workflows. Indeed, Infor has rolled out Infor Workspace, a universal UI that can be used today for its LN, SyteLine, EAM, FMS SunSystems and Expense Management applications. When the time comes to switch from legacy to new system, it will be possible for these users to keep the same UI, which in theory means transitions can be smoother and less time-consuming.

“In theory” is the operative phrase, since we won’t really know where the “gotchas” are and how best to address them until the first wave of pioneers go through the process. The history of the adoption of new information technology by business is littered with examples of extravagant analyst optimism that did not pan out. ERP itself was touted as a panacea because it enabled central collection of related information for the business enterprise, but it did not substantially address the need to make the information accessible and useful. Historically, too, companies have used any change-over in financial applications as an occasion to clean up and rationalize their charts of accounts and other items. This can be time-consuming by itself, but it doesn’t have to be part of the move from one system to the next.

Use of multidimensional databases as the data store for accounting and other enterprise transactions systems has another potential plus for users of these systems: greater flexibility. Our ERP research finds that companies underutilize the capabilities of their financial systems. One reason is because most larger companies find it difficult to make the changes necessary to do more. Although there can be many reasons why making any sort of change to an ERP system is time-consuming and expensive, some types of changes can be accomplished more readily in a multidimensional structure than in a relational one. This may prove very useful for, say, HR and tax departments because accounting systems are rarely provisioned with their needs in mind. Typically ERP financial management systems are configured around an organization’s business structure: for example, divisions, functional silos and geographies. Although it’s possible (and to my mind recommended) to set up a company’s books to be tax-aware, they rarely are. Most large companies’ legal structures do not align perfectly with the business structures. Consequently, people who work in tax departments routinely waste valuable time doing work to adapt tax reporting to the structure of the business. Since making an accounting ERP system tax-aware would just involve adding another dimension, I believe it would be far easier to implement the change than in a system built on a relational data store. The same applies to having an HR system that is more adaptable to the fluid organizational structures and broader categories of employees (such as outsourced and contract workers) that companies need to count these days.

In an effort to find a way to hold onto their maintenance base, some enterprise software vendors may have inadvertently come upon a way to improve the usability and utility of their complex software systems – by making it easier to access and use the data contained in them and add and split dimensions to the data structure over time. It remains to be seen how much pain the vendors will be able to take out of migrating from their legacy to their new applications but at first glance, it’s a promising innovation.

Regards,

 Robert Kugel – SVP Research