Spring 1996 € Volume 1 € Number 1

Fighting Obsolescence

Will your applications grow with you?
A new approach to solutions development.

By Julie Fraser


History has a tendency of repeating itself. Software we now call legacy systems -- because we've considered them obsolete for a few years -- were the hot ticket 10 or 20 years ago. The information systems you acquire today will be obsolete one day also, but your job is to make it later rather than sooner.

Most manufacturers are turning to commercial software products because they ease the custom developed problems of implementation time, staffing and maintenance. Unfortunately, packaged software does not necessarily solve another problem -- systems that are too rigid to change when the business does. The original justification for custom development has not vanished, either: packaged systems may not match your business processes. It's critical to choose systems that support your processes, especially if you have gone through some re-thinking or business process re-engineering.

The typical checklist for technology, features and functions is clearly not enough. A checklist type of evaluation may begin to indicate whether the software system solves your current manufacturing management challenges, but it usually does not reflect the process. Even to the degree it does, it's not a good indicator of whether the package will support your operations five or 10 years down the line when your way of doing business will have drastically changed with the world around you.

Still, a product's ability to reflect your business processes now and as they change is something you can examine before buying. It is tightly linked to the architecture of information systems, to the design of applications, and at its core, to the development philosophy of the software supplier. So while the traditional RFP checklist cannot systematically examine tailorability and ability to change, other questions can. Before we examine those questions, let's look at software development processes and their results.


The Traditional Development Process
There are several factors that, when judiciously applied to systems development, ensure that information systems can evolve with the company and its business issues. But first, let's examine a simplified model of how information systems are traditionally developed. Figure 1 illustrates the typical evolution of an information system.


Figure 1

Most manufacturing companies -- and most manufacturing software suppliers -- have legacy systems and investments in hardware, software and personnel training. These current capabilities (or sunk costs) are significant, and are at the root of most traditional development efforts. The basic tenet is, "We have these systems and this knowledge, we should try to maximize them." As a result, legacy systems architecture is the primary driver in many new applications developments.

Now we have an outdated architecture. Unfortunately, the systems' inability to match business processes is further compounded because the users' input and requirements are usually not taken into consideration. Software suppliers certainly can involve customers in their development process, but usually, the mechanisms are not in place.

This leads to applications that do not support current business processes and rules. For the end user, the new application becomes just one more system to feed and maintain. In many cases, users resist or even sabotage these systems. When this happens, management believes the users are not supporting their business goals; however, in most cases, users resist because they do care. Users are the ones who can see how procedures forced to feed an application keep them from processes that run the business effectively.

Any number of manufacturing companies are still buying systems that force data-oriented business processes on the users. We have met quite a few managers who first led successful re-thinking or re-engineering efforts, only to see the benefits and momentum dwindle when a new information system de-rails the processes. Re-engineering costs then become essentially wasted.


A New Approach
Looking at this chain of system development and its results, you probably are thinking, "There must be a better way of developing information systems." Fortunately, there is. Let's call it the "Customer-Driven, Business-Process-Oriented Development Cycle." Figure 2 is a representation of this new paradigm in information systems development. This solution may seem trivial. It is so simple and natural that you'll wonder why it has not always been this way. The mark of solutions that work is: They make sense!


Figure 2

The first consideration in this new way of designing and developing information systems is to determine what business processes and rules the applications will support in the manufacturing environment. The questions to ask next are: Who are the users that need to perform them? How do they accomplish their tasks? What information -- not data -- do the users need to perform these activities?

It is only in the context of answering these questions that developers can start to design and develop applications that will serve as true decision support systems. It is essential, however, to factor in change. Although the phrase is becoming old hat, change is the only constant in the new business environment. As a result, applications must be designed and developed as tailorable parts of the whole system. Look for standard systems, because support will always be an issue with custom ones, but also look for configurability in these standard systems.

To support solid business processes, software must truly aid efficient diffusion of information. Look for robust implementations of technologies that have become much more than trendy buzzwords: graphical user interface, open systems, client/server architecture, object-oriented design, agent-based technology, optimization algorithms, etc. These leading-edge technologies are fast becoming recognized as efficient and powerful in real-life, day-to-day decision support systems. They actually contribute to the system's ability to model real business processes and change when needed. They also foster an ability to turn data into answers to questions users must pose to do their jobs.


Where Do We Go From Here?
As the rate of business change accelerates, finding an information system to help improve productivity and efficiency is not only a major responsibility, but also a genuine challenge. A few things to look for in choosing systems are:
Those of you in manufacturing and not IS are probably thinking, "This is all well and nice, but how does it help me in manufacturing more intelligently?"

The answer, in and of itself, represents the new paradigm in systems and manufacturing: To manufacture intelligently, you must manage intelligently and to do that, you must give the right information to support your decision-making process at every stage, instantly and in real-time. Only an information system that is designed to totally support your processes and that is tailorable can, in the long run, help you keep your competitive edge. As in other aspects of intelligent manufacturing, it is crucial that you ask the right questions of your information systems.

Julie Fraser is corporate strategic advisor for Berclain USA Ltd. (Schaumburg, Ill.), a provider of software and methods for manufacturing synchronization & scheduling to discrete and batch process manufacturers. Fraser is based in Cummaquid, Mass.

  • Return to the Table of Contents
  • Go to the CiME homepage
  • Go to the Lionheart Publishing homepage
  • Go to the Subscription Form for the print edition of CiME.
    CiME  is a publication of Lionheart Publishing, Inc. ©
    2555 Cumberland Parkway, Suite 299
    Atlanta, GA 30339 USA
    Phone: +44 23 8110 3411

    e-mail:
    URL: http://207.69.204.147