Back to Top

WHAT ATTENDEES WILL LEARN

Detailed lists of migration tasks with decision points which trigger selection and understanding of their importance for different enterprises

An understanding of the tradeoffs between functionality and technology (with an example from "old" vs. "new" systems: Error Tracing and Debugging

Encouragement to participate in the decision making processes that determine the future of their enterprises.

Back to Top

OVERVIEW and INTRODUCTION

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 has been 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 architecture is almost a pre-requisite for their long-term plans. Simultaneous with this on-going migrations/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 area are better prepared to migrate than others, but where one may be weaker, and another stronger, none have all the pieces of necessary 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 months or 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 many different definitions and levels, but can be most broadly classified as "big bang" vs. "phased". Another comparison of styles describes conversion as bringing forward either 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, while big bang cutover with no historical data available may be gut wrenching and harmful to customer service levels.

The many decisions in each particular situation can be made by default or through careful investigation of facts and integration of alternatives, with ideas and involvement from all departments and functions within the enterprise. This paper includes lengthy lists of tasks to be performed during migration and discusses a few of the decisions that trigger their importance. The dichotomy of total functionality vs. bleed-edge technology naturally polarizes the two camps who want every feature ever dreamed up and also 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 systems. 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.

The remainder of the presentation will cover a comparison of specific manufacturing solutions with which the author is familiar. Examples will be taken from experiences with two packages that run on the HP3000: MANMAN® from Computer Associates of New York and IFS Applications from Industrial and Financial Systems of Sweden and North America. A short discussion of User Interfaces and their error debugging will be followed by a discussion of the various elements that can be called components in a discussion of manufacturing software.

Back to Top

COMPARISON: Functional and Technical Components

The lists of activities near the end of this paper provide useful reminders of the many topics available for discussing most aspects of both the functional and the technological issues involved in the transition from a proprietary legacy software system like MANMAN® to a more open, heterogeneous one like IFS Applications. The point of perspective chosen here is a discussion of "components" as defined for both the functional and technical areas.

Functional Areas

Everyone in manufacturing can relate to the word component. It can be defined as the parts that comprise an assembly. Nothing is mentioned in this simple definition about Bills of Material or subassemblies versus purchased raw parts, but most people can picture an engineering drawing of a product that is made up of various component parts. Each person may think of different products, like automobiles or appliances or whatever their company makes, but many parents who have assembled a toy for their child will think of a bicycle or playhouse.

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.

Technological Areas

In the technological area, the similarities are more difficult to see and understand. MANMAN/HP uses FORTRAN and the IMAGE DBMS on the proprietary parts of MPE/iX for the HP3000. IFS Applications use Oracle's DBMS and it's PL/SQL stored procedures on a server like the HP3000, with a GUI front end client that can be deployed from either the workstation or an intermediate server.

Instead of IFS's entity relationship diagrams in Rational Rose's UML (Universal Modeling Language) for the data definitions, MANMAN® uses an EDITOR file called a schema to describe the datasets and fields (tables and columns). That schema file has precious few comments and the relationships between fields are limited and difficult to see.

Technologically, IFS Applications are object-oriented with classes and methods, while MANMAN® is procedural with variables and subroutines. At the smallest level of granularity, objects are components. At a simple level and in a simple way of description, the mid-grained components of the object-oriented world are similar to the subroutines of the FORTRAN world. We have already seen that at a functional level, large grained components are called modules. This then begins to describe the API for both systems. It sets the stage for a real technological comparison.

Back to Top

Application Program Interface

An API is a set of program code segments that are strictly structured and have defined inputs and outputs. In MANMAN® terminology, they are the subroutines. The callable routines accomplish the work, are components, and are like intermediate subassemblies in the Bill of Material analogy; they are made up of other, smaller software components and themselves are part of higher-level software components.

MANMAN/HP uses many subroutines and they are almost all documented. Originally, the subroutines, their descriptions, and their calling parameters were printed in the MANMAN/HP system manager's manuals. After Release 5, in about 1985, the documentation for those routines was removed from the manual and was made available on line from within files delivered with the MANMAN® software system.

The problem with this "MANMAN® API" is that it is inconsistent in several ways. First is the granularity problem. These routines are all over the place as to size and function. Users know about some of them when they see a description of what they do. Some of them do specific small tasks like prompt for "output option" or prompt for a part number and remember it the next time the user is asked to input a part number. Very standard, commonly used, handy stuff. Other routines are used only once because they are really very specific to a particular application command. The documentation makes no distinction between the kinds of subroutines.

Another problem is that most of the needed subroutines are missing completely! For almost every field in an IFS table, there is a standard routine for maintenance. That covers adding, listing, changing, and deleting some entity like a part or a customer. This makes it easy to write an interface to whatever the table contains. Aside from these maintenance components, many other routines can be delivered with the IFS Applications. They are designed to be mixed and matched because the tools and conventions used for IFS Application development encourage reuse. MANMAN® doesn't have a callable subroutine to add a customer or a sales order.

Back to Top

COMPARATIVE Example: ERROR Tracing and Debugging

The ability to trace errors and provide diagnostic detail information as a program or process runs is very important to the support of an MRP or ERP system. There is so much complexity, for reasons we will discuss later, that being able to quickly diagnose and isolate the causes of problems and eliminate them is critical to both implementation and use of the system.

A comparison of MANMAN/HP and IFS Applications would provide a broad contrast in error tracing and discovery methods and techniques but, because of its inconsistent User Interface, MANMAN® alone can provide several examples of some of the different approaches. For example, the use of several levels of components (explained in more detail later) can pose a challenge to even legacy software designers when it comes to being able to interrupt the flow of data entry in order to provide the user with feedback about problems.

To the users the most obvious sign of there being "levels of components" is in access through the "screen-oriented" User Interface. MANMAN® uses at least four different User Interfaces, each with its own ways of interrupting the user when something goes wrong. The different approaches can really be traced to the differences between character-mode dialog and block-mode screen handling. For purposes of this discussion, Wingspan and "cursor-controlled" character-mode are considered to be screen-oriented data entry, like true block-mode. The basic differences to a programmer are that there are protected areas on the screen, which simulate a picture of a form. Since in character-mode dialogs, which began in the days of teletypes hammering on paper, the "cursor" is always at the bottom of the conversation, there is no restriction about when you can perform a command to display or write to the screen (or paper).

Because in this "conversation" every prompt and response in a dialog provides an interruption in processing, the programmer has time to check the last response before proceeding to the next one. Block-mode entry is different. In a crude way, it's like a client/server process. The program suspends operation while the "screen handler software" deals with the user. There are, in effect, separate components handling the data entry vs. the normal processing and validation that the programmer controls. When the programmer encounters an unusual situation or error, there must be some way to tell the user.

Most block-mode programs have an error message area reserved at the bottom of the screen. When a particular field has some problem, a good programmer will place the cursor in that offending field, perhaps with highlighted or colored shading, after printing a meaningful error message. If the problem does not concern a field on the screen being displayed, some way must be found to tell the users which screen has the error.

IFS Applications have trace methods built in through standard interfaces. As commands execute in routines on the client and on the server, audit trails may optionally be created in files that can be analyzed in several ways. Each trace features several levels of tracking of events. For instance, there are ways to determine exactly which routines are being called, including which parameters are passed and the values they contain. Other trace methods available in IFS Applications allow the viewing of every field transferred from or to the Oracle database tables.

Aside from these automatic trace capabilities, the client side presentations that the GUI is handling are still very similar to block-mode screens. There is a similar remote control aspect that implies a message handling protocol and there are protected areas that represent the form. Although the Windows "folder tab" metaphor makes it more intuitive to see and understand the relationships of the various "data entry screens", the need for passing control to the offending field on the correct screen when an error occurs remains the same as in MANMAN®. The number of fields and the complex associations among them makes it very difficult to please the user in all cases when it comes to providing assistance when an error has occurred.

The complex validations that are required and the invisible use of defaults for more and more fields make the linkages difficult to learn. Anyone who has used a 10-tab transaction screen to try to create the complex relationships of their own company's supply chain of customers, vendors and other institutions has seen the need for setting up many defaults. The ease and intuitiveness with which the validation errors are explained will help users during their inevitable trial-and-error implementations. It is a sign of a very powerful system, designed by respectful and caring developers, when the levels of frustration users have experienced in such situations is minimal.

This "more formal" and "less formal" comparison of IFS Applications and MANMAN/HP is based on my own personal experiences with the two systems. I admit that I have much more experience with MANMAN/HP (about 21 years) than with IFS Applications (1 year), but I can confidently state that they are both very complex underneath. This stuff is not simple. For a glimpse into the reasons for the complexity, we don't have to look far into the following lists. And remember this is just for the conversion and implementation, not actually running the business!

Back to Top

MIGRATION and IMPLEMENTATION ACTIVITY LISTS

Planning

Assignments

Actions

Back to Top

SUMMARY and CONCLUSIONS

Functionality is still the leading criterion for measuring the desirability of a new system, but the retraining needed for the implementation of deeper functionality is daunting. Technology is the second most important consideration, but it 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.

Any presentation about ERP at the beginning of the 21st Century would be incomplete without references to two important trends. One is Application Service Providers (ASPs) which are similar to service bureaus but are ubiquitous because they use the Internet and will be cost effective very soon. The second is Telephony which is the catch-all phrase for switching and bandwidth discussions and will be critical because of its cost and impact on response-time for World-Wide Web applications. Both of these have been important in the past, but are being re-incarnated for a new generation of buyers.

A warning is in order for anyone in transition toward ERP. There are likely to be some very disappointed users who will think that there is a lot more work in the new applications because of increased functionality and the changes in the User Interface. It is very important to understand that without automated data collection systems and interfaces to other systems through EDI, ecommerce, or other connectivity, there is likely to be more work in data entry for a new ERP system than with a legacy system. Being smart about decisions as simple as naming conventions and part numbering schemes can save or create lots of unnecessary work.

To sum up the differences between development environments used by MANMAN/HP and IFS Applications: one was done with informal brilliance and the other was done with scientifically engineered standards. The components are much more consistent when engineered using strict conventions and the detailed documentation is more specific. It is this author's opinion that brilliance is now mostly irrelevant and those informal systems are history.

There is a range of granularity in the various "components views" of software that mirrors the solar system's obvious gradation in structure from pebbles to planets. Although the universe continues downward from pebbles to dirt and to dust and to molecules and atoms and electrons and who knows how much further and although it continues upward from planets to solar systems and galaxies and clusters and who knows how much further, the part that usually concerns humans is the part we can see. The same is true for MRP and ERP systems; users don't care about unseen bits and bytes or grandiose platform architectures, they care about the data in the fields they are responsible for maintaining and using. Users don't even really care very much about other users' data until errors or inconsistencies cause problems. Better use of components and better definitions of their relationships will make ERP systems more consistent and much easier to implement and interface in the future.

On the technical side, it might not matter which component technology your new package uses. Software vendors would lead you to decide between Microsoft and Sun. Maybe you've been told to invest in either EJB (Enterprise Java Beans) or COM, but that may not be as important as deciding that it must be based on the CORBA standards that have been around since the early 1990's. On the functional side, if a software platform does not have a standard API (Application Programming Interface) with all the relationship diagrams that document what the system delivers and a test suite or verification protocol to prove that's really how it works, it should not be taken seriously.

Back to Top