New Processes, New Systems: A Hybrid Solution

Written by

Erica Brevet-Stott, President, EBP Consulting Services

Published July/August 1999    -    Information Executive

            It's an all too common problem, one eventually faced by business organizations of all shapes and sizes: Conditions have changed, the old system is no longer meeting the organization's needs, and it's clear that something has to be done about it.  There are obvious solutions (replace or upgrade the system) and not-so-obvious solutions (re-engineer the processes themselves), but rarely is a combination of the two given much thought.  Instead, organizations that find themselves in such a position usually turn to whatever is the quickest and easiest way out.  In most cases, this "quick 'n' dirty" solution takes the form of a system patch or work-around — a direct, short-term fix with minimal impact on the organization's business processes.

Weaknesses of Patch Solutions

            The main shortcomings of system patches lie not in the fact that they are short-term in nature or that they typically seek to solve only a single, isolated problem.  Instead, their main drawback is the way in which they are implemented — quickly, almost haphazardly and with little or no regard for the organization's underlying process architecture.  While such a strategy may meet the organization's immediate needs, the cumulative effect on efficiency and operation can be disastrous.  As multiple patch solutions are repeatedly added and inserted, they tend to build up like layers of paint on a piece of old furniture.  Over time, the original system becomes so obscured that a kind of critical mass is reached; at that point, there is no choice but to strip off the layers of paint and replace the entire system from the ground up.

            "After years and years of cobbling together short-term solutions, you eventually reach a point where you have to question whether it's better to go on or just scrap the old system and replace it," says Bob Woerner, Vice President of Strategic Enterprise Management at Oracle Corporation.  "To make matters worse, the ultimate cost of a replacement (when one is needed) generally tends to increase as time goes on.  So you can actually end up hurting yourself by delaying."

            For large enterprises like telecommunications companies, the costs of a wholesale replacement can run in the millions or even tens of millions of dollars.   Given such astronomical price tags, it is little wonder that system patches are as prevalent as they are.  But are they effective in the long run?  Usually not, although they certainly can be.  Most patches are quite literally "thrown together" at the last minute, and it is this fact alone that most often accounts for their failure over the long haul.  During a typical system change or implementation, the overriding emphasis is usually not on improving overall performance, but on fixing some immediate, pressing problem.  As Woerner points out, "It's a lot easier to get the board of directors excited about a system overhaul if the alternative is to go out of business because you can’t compete.”  As a result of this short sighted thinking, the crucial examination step — what amounts to a thorough investigation of the involved business processes before any changes to the system are made — is frequently overlooked.

Process Improvement: A System Developer's Best Friend

            At first glance, process improvement seems to have little to do with the technical nuts and bolts of system development.  In fact, the two are much more closely related.  Ever since their inception, technological systems have been structured to automate, refine, and generally improve the efficiency of processes within the organization.  But ironically, the biggest hindrance to this worthy goal is often the processes themselves.  After all, if the underlying processes are faulty or inefficient, of what value is a technological system that automates them?  A bad process might be made faster as a result, but no real value will be added to the organization.

            The extent of this problem has actually paralleled the general swell in system technology, mostly because in today's business environment, system improvements are generally seen as the first and best fix.  This outlook is correct, by and large, but it doesn't change the fact that good system improvements are often hindered by bad processes.  And to compound the problem, most process faults tend to go unnoticed once a system is firmly in place.  The resultant boost in efficiency, however small, can mask the problem and make the process look better than it really is.

Consider the case of a large corporation that needed to annually "cover" (educate) its employees regarding issues such as policy, regulations, performance expectations, and the like.  Traditionally, providing such coverage had proven very costly.  Not only did it require a significant amount of employee downtime, but the process itself was long and tedious.

To remedy these problems, a computerized system was developed which allowed employees to seek out and receive the necessary coverage on their own, during off-peak hours.  Only a short time after implementation, it became clear that the system was a smashing success.  The amount of employee downtime had decreased, and because employees now had the option of seeking out the coverage when it was most convenient for them, productivity remained high.

As striking as these successes appeared, however, they were actually hollow victories.  Later analysis showed that, while the new system had in fact improved the efficiency of the existing coverage process, the process itself was too meticulous and unnecessarily thorough to begin with — employees just didn't need to receive that level of coverage.  Both the process and system could have been later changed as a result, but not without a significant expenditure of time and money.  Had this process analysis been carried out before the system was designed and implemented, the prospect of such expensive backtracking could have been easily avoided.

The Tools of Process Analysis

            There are several tools often used to evaluate and monitor processes within an organization, but chief among them is the process model.  Similar to a flow chart but far more readable, a process model is used to graphically map a process from start to finish, and also to make its relation to other processes more apparent.  To begin with, the model considers the organization's process structure as a whole, and becomes increasingly specific as needed.  All crucial steps are outlined and mapped from the top down, eventually giving rise to a kind of hierarchical picture.  Typically areas targeted for system changes or improvements are then subjected to an even greater level of scrutiny.

            The process model is useful not only because it allows waste and inefficiency to be weeded out, but more simply, because it allows systems to be developed against the solid backdrop of reality.  With the benefit of such a backdrop, systems can be developed which reflect what is actually happening, rather than what "should" be happening, or what might be happening in the organization next door.  After all, when it comes to technological solutions, one size does not fit all, and the flashiest system in the world isn't worth much if it doesn't accurately reflect the situation at hand.

The Big Picture: Making It Work

            As part of the system development procedure, process analysis has shown itself to be a powerful and necessary step.  Though useful at any stage of the system game (even after implementation), process analysis does its best work when introduced early on.  When executed properly, early process analysis can serve as a blueprint for future system changes, allowing developers to identify their targets and more effectively leverage the technology that is ultimately put in place.

            Is this analysis step somehow more crucial than in the past?  Many would say yes, due to the basic fact that technological systems are more prevalent and popular than at any point in history.  The overall explosion in computers and technology has given rise to an ever-increasing dependence on these tools for business survival.  This trend is both promising and potentially hazardous.  On one hand, it holds a potential for unprecedented speed and operating efficiency; on the other hand, a potential for chaos and bloated costs.   As always, speed and efficiency are worthy goals, but in today's business environment, reaching for them haphazardly can lead to severe and possibly detrimental problems down the road.  In order to truly increase performance, system technology must be predicated on a foundation of solid processes.  The organization that recognizes this fact will be leaner, meaner, and in the long run, maintain a healthy lead on its competition.

About the Author:

Erica Brevet-Stott, President of Oakland, CA-based EBP Consulting Services, Inc., has 16 years experience in the field of organizational improvement.  She specializes in improving business results (reduced cost and cycle time, improved quality) through the creation of more effective, efficient and flexible business processes.  She can be contacted at (510) 339-6144 or via her web sit at www.ebpinc.com.

EBP Home Page   Business Assessment   Process Redesign   Process Modeling  Workshops  Results   Erica's Bio