Abstract
Benefits
Introduction
Simultaneous Migrations and Component Interfacing
General Discussion of Module Interactions
MANMAN/GL^TM
IFS General Ledger and Accounting Rules
GL Conversion: A Specific Example
How to Convert from MANMAN/GL^TM
How to Convert from MANMAN/OMAR^TM
Conclusions

ABSTRACT

Following on from Mr. Floyd's prior presentations at ERP World (1998's "Porting ERP to the HP3000" and 1999's "Simultaneous Migration and Component Interfacing"), this session discusses phased ERP implementation. Examples will be drawn from the author's recent projects involving converting users from MANMAN® to IFS (Industrial and Financial Systems Applications on the HP3000) and earlier projects, called "Big Bang" conversions, from other systems to MANMAN® in the 1980's.

Like all ERP packages, MANMAN®, although created in the 1970's, is modular. Even though it is not component-based, there are logical pieces of software within MANMAN® that can be "unplugged" and replaced with integration or an interface to a new module or solution.

The obvious places to start a phased migration are with the "easy" modules, like Fixed Assets and General Ledger, or with the modules that were never a good fit for a particular company anyway, usually OMAR (order entry) or Serviceman (Returns, Repairs and Field Service). Another place to "get your feet wet without drowning" in ERP implementation is to start with a module that is weak or non-existent in the current system, such as Finite Capacity Planning (Advanced Planning and Scheduling) or Maintenance Management.

There are advantages and disadvantages to replacing any given module at each company; these will be discussed in detail during the presentation. Pros and cons will be shown with examples of interfacing a few of MANMAN®'s modules to IFS Applications' solutions.

Aside from the specific Conclusions at the end, Attendees will learn that:

1. There are Deployment factors to consider during selection of an ERP Package
2. Slower, phased conversions have fewer negative impacts on a company than all-at-once, everything-or-nothing ERP Implementation approaches
3. Getting immediate benefits from a critical subset of the vast functionality of a new system like IFS Applications is easy, especially if your current system is functioning well (as MANMAN® on the HP3000 probably does at most sites)

The term Big Bang Conversion has been used to both name and describe a method of implementing large software systems. Because of the number of independent divisions and the large number of separate systems in use in many companies, under the general heading of porting ERP, it is actually almost impossible to define a complete Big Bang conversion. Frequently, conversion implementations in large companies are "rolled-out" one division at a time. Therefore, the term Big Bang usually really means a massive implementation project to introduce a new integrated system affecting multiple departments that targets a single go live date.

Despite this simple definition, there can still be quite a bit of confusion about what a Big Bang implementation means. An example reported on Datamation's web page in October, 1999 stated that McDonald's, the huge hamburger chain, converted all their employees worldwide from a legacy system to a new payroll system instead of using a phased rollout. The writer, Larry Marion, goes on to compare this Big Bang project of McDonalds' to "major catastrophes at organizations attempting to implement ERP suites all at once" in the early 1990's. To support his idea that Big Bangs are making a comeback, the article referenced a 14-month conversion to SAP by Rayovac that represented a successful Big Bang implementation completed in 1999. So, is the Big Bang implementation method good or bad?

The name of this section was the title of this author's prior speech at ERP World 1999 in San Francisco. Some of the concepts discussed below may be explored in more detail by referring to the Proceedings of that conference on CD from Interex.

In a company's long-term IT strategy, there are going to be numerous large and medium-sized projects. Even with the selection of a single ERP solution, there are still industry-specific and best-of-breed subsystems in any strategy because no one company (CA, SAP, or Microsoft, for example) offers all of the software components. Every large project must be broken down into its logical pieces for defining and planning the work, then assigning different groups of people to appropriate implementation tasks. So, why not implement the various milestones of really large projects on different dates? The answers to that question will define the tradeoffs between Big Bang and Phased ERP implementations and conversions. Every company has a unique situation requiring careful analysis and planning.

The primary difference between Big Bang and Phased conversion is the need for temporary interfaces between old modules and new ones. The granularity of the components in the old and new systems provides the handle by which the scope of the temporary interfaces can be grasped. Every ERP system is modular and the examples of MANMAN® and IFS used in this presentation are probably typical of the progression from legacy to state-of-the-art.

To quote my 1999 speech on the topic of component granularity:

One thing about Bills of Material that becomes apparent when you try to actually build something is that there are numerous ways to describe even the simplest of products when it comes to the size and complexity (granularity) of structures called subassemblies. What is a subassembly and why does its granularity matter? Think of an engine as a subassembly of a car. Is its carburetor a subassembly also or is it a list of parts directly on the engine? Let’s assume that it’s a subassembly. Are the needle valve and seat, float, gaskets, and accelerator pump a subassembly or a list of parts directly on the carburetor? If you want to be able to buy a carburetor repair kit from the original manufacturer, they might be a subassembly called a kit.

Software, whether for MRP (MANMAN®) or ERP (IFS Applications), is broken into components with various names and sizes or granularities. One way of describing the highest levels of software systems granularity is by studying the pricing of the largest components. In MANMAN®, the largest units are called modules and in IFS Applications they are officially called solutions, but everyone still knows that’s the same thing as a module, and that name is also used.

So, in the functional area: large-grained components are thought of in similar ways by both MANMAN® and IFS. There are isolated interface (batch) and integration (online) points where the modules or solutions interact.

A discussion of component interfacing between MANMAN® and IFS will help demonstrate the concepts.

This session discusses phased ERP implementation. Examples are drawn from the author's recent projects involving converting from MANMAN® to IFS (Industrial and Financial Systems Applications on the HP3000) and earlier projects from other systems to MANMAN® in the 1980's.

There are at least ten reasonable ways to do a phased conversion (of the hundreds imaginable). The choice depends on particular situations, such as: which old modules and which new ones? Which MANMAN® Comin Variable settings are pertinent? How is the existing system actually being used? What is not working? Some combinations will be impractical or impossible and can be ruled out. Each conversion has its own best way, and the Project Team's job is to find it.

The common places to start a phased migration are with the "easy" modules, like Fixed Assets and General Ledger, or with the modules that were never a good fit for a particular company anyway, usually OMAR (order entry) or Serviceman (Returns, Repairs and Field Service). Another place to "get your feet wet without drowning" in ERP implementation is with a module that is weak or non-existent in the current system, such as Finite Capacity Planning Advanced Planning and Scheduling), Maintenance Management, or Document Management.

One of the most obvious module order and combination alternatives is: G/L, then A/P, then Purchasing/Procurement. Another is: OM, then Shipping, then Billing & A/R. In most situations, there’s no reason why these two can’t proceed in parallel. After Purchasing might come Receiving, then Inventory, perhaps overlapping with Engineering, then Production/MFG (Repetitive and/or Work Orders), then Planning (MPS, MRP & Capacity) and Cost Accounting. Each client may have different departments prepared to focus all their attention on conversion and implementation at different times.

MANMAN/GL^TM

Like all ERP packages, Computer Associates International's MANMAN®, although created in the 1970's, is modular. Even though it is not component-based, there are logical pieces of software within MANMAN® that can be "unplugged" and replaced with integration or an interface to a new module or solution. MANMAN/GL^TM is a good example. It is a separate module that some companies who run "MANMAN®" did not purchase. Those who don't use MANMAN/GL^TM tend to think of MANMAN® as the MANMAN/MFG^TM module only.

In Release 9, ASK Computer Systems, Inc. (who created the MANMAN® package) introduced a feature into MANMAN®/GL that allowed for the export of account and posting data to another system, in preparation for porting to their new Advance system replacement for MANMAN® (which eventually failed and was withdrawn from development). Because it was easier to take advantage of the existing subsystem G/L posting and closing routines than to write a new one for each subsystem, they provided a method of interfacing MANMAN® to their new G/L package.

I hope at least a couple of companies took advantage of this seldom-used feature. It is interesting because it shows a way of using 2 different G/L packages to accomplish an interface rather than different brands of subsystems vs. G/L software. This method of conversion allows the old G/L system to continue to run, just for its subsystem posting capabilities.

IFS General Ledger and Accounting Rules

IFS is an extremely modular system at levels not addressed at all by MANMAN®. Through its use of components, which are like subroutines that allow for easier re-use of software, IFS takes a giant step in modularizing its application. There are several ways to move data into an Oracle-based application such as IFS, but just focusing on the "standard" ways shows that the Connectivity components of IFS can be used to move data between shadow tables (exact duplicates of regular tables) and "flat files" used to carry data to and from the legacy system.

Using Connectivity functionality techniques allows for the use of standard validation processing by the standard IFS software components used to maintain the tables from the normal user screens. Another way to migrate is to use the IFS Data Migration tools which also use the standard IFS Applications code to validate data as it is loaded to IFS's database. Still another aspect is the Oracle Gateway for IMAGE/SQL that allows access to legacy data through Oracle's SQL*Net, which means from almost anywhere. Custom interfaces can be developed to read and write in both directions using this gateway or other methods such as ODBC.

Using IFS's standard validation programming is an example of the easy re-use of component-based methods. It is important that the Accounting Rules defined and approved by the users are available for use during conversion of existing data.

No matter how many times a consultancy or vendor has done conversions between packages, each project will be unique and must have its own complete, detailed implementation plan. Each large segment of the overall project/module conversion and implementation would take from 1 to 18 months. Total involvement and commitment to a high-quality implementation could span two to five years per site.

Each client company must decide which modules to purchase and in which order to convert and implement, but one thing is certain: they must commit their best people to the effort. A good place to begin would be a module that does not exist in the legacy package. Implementing these modules first is a way to begin the project without having to commit to a complete ERP conversion.

From the "standard" MANMAN® client’s point of view, MANMAN/G/L^TM will be a likely candidate for early replacement. OMAR (at least the Order Management portion), Serviceman, Purchasing, and Planning (Material & Capacity) may also be high on the current MANMAN/HP user’s list of modules to get away from as soon as possible.

How to Convert from MANMAN/OMAR^TM

Same as GL Conversion and Implementation on prior pages, except:

Change "G/L and Accounting" to "OMAR" in 1.41 and 1.42

Replace Section 1.6 with discussion of Products, Customers, and Orders

Of course, these plans must be customized and completed with much more detail at each different implementation. There are advantages and disadvantages to replacing any given module at each company; these must be discussed in detail during the early planning. Possible pros and cons can be shown with any interface of MANMAN®'s modules to IFS Applications' solutions.

Since every conversion implementation to a new ERP system should be planned in steps with deep drill-down detail, definitions for overlapping sub-projects with different go live dates can easily be added.

Extra work will be needed to define and create/modify temporary procedures and subsystem interfaces.

The amount of work required for each possible temporary interface can be compared to the benefits of focusing on one area at a time.

Smaller successes allow faster deployment.

The Learn-as-you-go approach admits that there will be mistakes, which can be identified and eliminated from subsequent sub-projects.

IT support for existing systems can be farmed out so that the IT staff can focus on training and creating procedures and methods for use with the new system.

Separate "Operational support" such as care of printers, modems, and tapes for backup from "Functional IT support" such as DBA tasks, batch Processing monitoring, security, etc.

ERP implementation takes cooperative teamwork between top corporate management, users, IT management/support, software vendors, and such experts in the use of these complex systems as independent consultants and trainers. Ultimately, though, ERP implementation must be user driven for business purposes. Customization and interfacing are critical, because systems integration is where the real paybacks are found. Because it depends so heavily on accuracy, user ownership of the ERP system is still the most important factor. Without repeatable, proven processes for maintaining data quality, all of the wonderful new metrics for better business decisions derived from improved ERP systems are meaningless.

ERP2Kspring3_pap