The Migratory Patterns of ERP Customers

Enterprise resource planning (ERP) migrations within the same product family (e.g., PeopleSoft 7 to PeopleSoft 8) can be complex, but migrations from one ERP vendor to another are more like installing a new ERP package.

META Trend: During 2003/04, Tier 1 ERP vendors will focus on the small and medium business (SMB) market, vertical extensions, and technology infrastructure. During 2004/05, vendor viability concerns will drive SMB ERP market consolidation as these vendors become increasingly threatened by Tier 1 vendors and Microsoft. By 2005/06, Tier 1 ERP vendors will leverage their application breadth and component architectures to reduce application complexity significantly.

With the recent acquisition flurry (e.g., PeopleSoft/JD Edwards, Oracle/PeopleSoft), there has been considerable discussion about ERP migrations. In the simplest case, two companies merge and leave both product lines relatively intact. Over time, the client might be able to use components from one ERP package to enhance the capability of another. In the more radical case, one ERP vendor might buy another ERP vendor and announce a strategy to retire the second vendor’s software. In that situation, the client must consider how to achieve this migration and plan accordingly:

• Reassembling the team: The company with an installed ERP package should be relatively happy with its assignment of staff to post-implementation jobs. Once the migration has gone live, typical staff teams support the migration, travel to sites to get the software working, and work on the next phase of the ERP project. These teams must be disassembled and a new team put in place (many members of which may have just recovered from the trauma of a difficult ERP implementation).
• Hiring a systems integrator (SI): The creation of a new ERP system is a complex task, and the client must interview, select, and manage the SI (again). Moreover, the suggested vendor implementation approach (e.g., ASAP from SAP) will vary from vendor to vendor and must be relearned.
• Planning the future state: A new ERP system represents an “opportunity” to once again plan the future state of the organization. The current state is represented by the current functions performed in the current ERP system. The organization needs to go through a formal design phase to re-establish this future state within the confines of the new ERP system. The most challenging aspect will occur where the new ERP system does not perform functions that existed in the old system (e.g., global trade logistics). In this case, the client can customize the new package or forgo the functionality. This phase is likely to take at least three months.
• Configuring the software: Current business processes may be modestly useful toward a new configuration, but the work of configuring the software and re-establishing the workflows (along with associated identities, roles, permissions, etc.) remains. Once the basic system has been reassembled, it must be tested iteratively by end users to ensure the correct functionality is present. This phase can easily take six months.
• Establishing the data model: There will be new data architecture, and the client will have to migrate data from the old ERP system (and other systems) to establish the data foundation for the new application, regardless of whether the underlying DBMS remains the same.
• Warehousing the data: Each ERP vendor has a unique approach to data warehousing, and the client must re-establish an approach to populating the new ERP data warehouse. The architecture is likely to be different as well (e.g., OLAP, ROLAP, MOLAP, relational tables). In addition, each vendor has a different approach to business intelligence, complex reporting, and which reports are “canned.” Time must be allocated to establish a new decision support environment, what reports are to be canned, and how end users will be empowered (yet again). Moreover, the new ERP data warehouse must be made part of larger data warehouse architecture for the enterprise.
• Re-establishing analytical applications: The two vendors will have different out-of-the-box approaches to analytical applications (e.g., business performance management), and the new collection of analytical applications must be re-established.
• Integrating with other applications: There will be a requirement to integrate this application to perhaps dozens of other applications in the enterprise, and a middleware strategy (including potentially application servers, EDI mappings for partner integration, etc.) must be re-established.
• Determining or retrofitting portal strategy: The new ERP system will come with its approach to portal technology, and the strategy for empowering end users must be re-established. At the very least, new “widgets” to integrate the new applications will be required. At worst, third-party applications must be reintegrated, dashboards established, and a closed-loop approach decision support must be rebuilt (whether through the portal or otherwise).
• Reconfiguring infrastructure and operations: IT staff members will have to resize the application and create an approach for areas like servers, network, database, security, backup and recovery, disaster recovery, systems management, output management, etc. This will require a thorough understanding of the internal architecture of the new application (e.g., application servers).
• Testing: The new application must go through single and multithreaded testing. Moreover, an approach to “promote to production” must be established to enable the testing of post-implementation patches, new configurations, etc.
• Re-establishing the center of excellence: The functions of a center of excellence must be re-established, as well as the approaches to help desk, continuous testing, customization, integration, etc.
• Training and documenting: The new ERP system will require a unique approach to training and documentation. Classes must be planned for both IT and line-of-business staff. Moreover, there is an expectation that the ERP vendor will offer training software that can be installed and maintained by the client.
• Teaching: In most cases, the client must assemble a traveling team to go to multiple locations to teach the usage of the software. This problem is made more complex, of course, if there are “N” installations of the software in data centers around the world.

Bottom Line: Swapping one ERP system for another is a complex project that should not be underestimated. Most Global 2000 companies should allocate at least one year for the transition.

META Group originally published this article on 1 July 2003.