ERP Migration and Component Integration
ERP IMPLEMENTATION STRATEGIES:
Simultaneous Migration and Component Integration
by Terry H. Floyd
the Support Group, inc (tSGi)
3305 Northland Drive, Austin TX 78731
Phone: 512-451-1135 Fax: 512-451-2990
tfloyd@supgrp.com
Presentation #059 for HP World . 99
San Francisco
ERP Migration and Component Integration
ERP IMPLEMENTATION STRATEGIES:
Simultaneous Migration and Component Integration
by Terry H. Floyd
Presentation #059 for HP World . 99
San Francisco
Functionality is still the leading criterion for measuring the desirability of a new ERP system but the re-training needed for the implementation of this deep functionality is daunting. Technology is the second most important consideration, but is not sufficient in itself to drive a project as big and serious as migration from a known, presumably working, system to a new one. Only the combination of the two can truly enrich the enterprise.
1. Detailed lists of migration tasks with decision points which trigger selection and understanding of their importance for different enterprises
2. An understanding of the tradeoffs between functionality and technology (with examples from . old. vs. . new. systems)
3. Encouragement to participate in the decision making processes that determine the future of their enterprise
Enterprise Resources, managed with the right processes and software, can be put to their best use for Service and Manufacturing industries when a clear plan has been agreed upon and firm commitment to a long-term strategy is established. Among Hewlett-Packard customers, there are as many solutions as there are enterprises because each opportunity is unique.
Within the framework of implementing a new ERP system, analysis and planning must be focused on near-term functionality and, at the same time, on mid-term technology futures. For those enterprises with legacy systems, or those in transition, migration of their core applications to a client-server/internet architecture is almost a pre-requisite for their long-term plans. Simultaneous with this on-going migration/upgrade, they must select, develop or customize and then interface best-of-breed industry-specific application components to surround that core.
Some enterprises in the Service and Manufacturing areas are better prepared to migrate than others, but where one may be weaker, and another stronger, none have all the pieces of needed infrastructure in perfect place. In short, no one migration strategy works for every enterprise and there are many required steps. Some of the steps can take years, as evidenced by failed MRP and ERP implementations where the structural or cultural changes needed for successful implementation of a new system were too great.
Migration Strategies have different definitions and levels, but can be most broadly classified as . big bang. vs. . phased. . Another comparison of styles describes the aspect of conversion concerning whether to move forward complete, partial, or no history. These two simple decisions can mean months of difference in the time required for completion of a successful project and the happiness of the users with the results. Phased implementations with all history available take longer, but big bang cutover with no historical data available may be gut-wrenching and harm customer service levels.
The many decisions in each particular situation can be made by default or through careful investigation of facts and integration of ideas from all departments and functions within the enterprise. This paper will include lengthy lists of tasks to be performed during migration and the decisions that trigger their importance.
The dichotomy of total functionality vs. . bleeding-edge. technology naturally polarizes the two camps who want both every feature ever dreamed up and robust, proven, crash-proof capabilities that run on the internet with fail-safe security. Let. s face it: the proven systems that always work (like MANMAN on MPE/iX) are mostly character-mode, non-GUI, non-relational, non-object oriented and are difficult to modify and interface to other subsystems. Conversely, the first of the . latest, greatest. internet store-front order entry software didn. t go much beyond part number and quantity. Floyd. s Axiom: Bullet-proofing takes many years and is obsolete by the time it is attained.
Planning
Business Objectives
Goals
Scale of Project
Costs
Budgets
Justification
Schedules
Expectations
Scope/Limits
Motivation
Team Organization
Needs/Backgrounds
Members
Capabilities
Communications
Skills
Verbal
Written
Listening
Methods
Project Marketing/Publicity
People Skills
Board/Owner Participation
Reporting Structure
Roles
Goals/Progress Tracking
Process Documentation
Startup
Technical
End User
Participation
Milestones
Change Tracking & Approval Lifecycle
Corrective Actions
Needed
Taken/Finished/Integrated
Understand Existing System?
Training/Education Assessment
Phased or Big Bang?
Work Breakdown
Segmenting
Grouping
Data: All/Some History or Active only?
Module Mapping
Module Implementation Order
Performance Simulations
Backup Strategies/Availability
Field Mapping
Fit
Gap
Output Needs
Reporting
Distribution
Access/Storage/Retention
Conversion Methods
Tools
Structures/Formats
Interfaces
Temporary
Permanent
Test Plans
> Methods
Monitoring
Detail Cutover Plans
Security/Access
Review
Assignment
Leadership
Ownership
Responsibilities
Negotiations
Agreements/Contracts
Quality
Performance Metrics/Specifications
Defect/Compliance Notification
Shutdown/Stop Work
Improvement/Change Tracking
Decisions/Authority
Delay/Reschedule
Cutover
Functional
Technical
Modeling
Prototypes
Structured Walkthrough
Simplicity/Ease of use
Documentation
Change Control
Forms
Input
Spreadsheets
Laser
Pre-printed
Training
Testing
Results
Continuous Feedback
Module Mapping
Module Implementation Order
Field Mapping
Programming
Audit
Review
Actions
Planning
Assignment
Brainstorming
Review/Update Planning Documentation
Installation
Platforms
> Hardware and Wiring
Operating Systems & Infrastructure
Database
Applications
Utilities
Phases
Timing
Ramping
Training
Develop Processes/Procedures
Build Environment
Production
Test
Monitor Quality
Meetings
Regular
Special
Populate Fields
Simulate Conversion
Manual Setup
Assess Project Schedule Conformance
Develop Monthly, Quarterly, Annual Closing Procedures
Test Processes
Validate Data
Develop Scripts, Batch Jobs
Train End Users
Customize
Document
Test Conversions
Checkoff approval
Finalize Procedural Documentation
Decide to Switchover
Synchronize
Live Switch/Cutover
Integrate
Other Subsystems
EDI
Support
Audit
Review
Iterate next modules
Improve
Functionality is still the leading criterion for measuring the desirability of a new system but the re-training needed for the implementation of this deep functionality is daunting. Technology is the second most important consideration, but is not sufficient in itself to drive a project as big and serious as migration from a known, presumably working, system to a new one. Only the combination of the two can truly enrich the enterprise.
HPWorld99_Paper MSWord98 TFinspiron 0499