"Boxes and Lines”

By John Blair and Ralph Loftin

 Each month a group of Arizona entrepreneurs get together to "network" and to listen to how a new company has faced the rigors of marketing, products, legislation, lawyers, competition . . .

During a meeting in early 1993, the CEO of the featured company described how the organization had recovered from a horrible negative cash flow position and had evolved from a "delivery" business to a "logistics" business.

The CEO described how he and his team would analyze their own business processes in conjunction with the business processes of their clients. Through these analyses, it became apparent that the "delivery" company had many of the tools (and a greater incentive) to manage the client's inventory more effectively than the client.

The technique of business process analysis was quite straightforward. When important work was done in support of a client, the CEO would draw a box. When products or information moved, he would draw a line. Looking at these messy sketches of the way products and data moved from shipper to customer unearthed new business services, turned the cash flow positive and created a company with a margin of over 70%!

. . . just "boxes and lines."

The CEO didn't claim to do "reengineering" or "business process redesign." In order to "reengineer" a process or a company, the company would have had to be "engineered" in the first place. Theirs wasn't. Most aren't.

That's why we call our method of streamlining an organization Enterprise Engineering. Most enterprises have never engineered their organizations for the first time. But, because "reengineering" has become so common a term for the work of developing major changes to an enterprise, we will often use it instead of "engineering." Generally, when we use "engineering" or "reengineering," we mean the same thing.

What you'll find in this book is based upon a technique which depends upon "boxes and lines" much like the delivery company had used. The idea of "boxes and lines" is simple. By reducing our (often unnecessarily) complex enterprises to the most vital work ("boxes") and the crucial flows of material and data ("lines"), we can concentrate on the important activities and results. Without the clutter of the trivial, we can see what to do about the activities and movements that are holding things up, causing quality to drop and increasing the cost.

 Enterprise Engineering in Five Minutes

The next five pages will require about five minutes to read. These five pages cover the key ideas behind Enterprise Engineering.

Every headline in the business pages stresses the need for successful companies to be focused on their customers. "Reengineering" is touted as the means to become more customer-focused and achieve great economies in the process.

Missing in most of these articles is a description of just what has to be done to become more customer-focused through reengineering. The journals let us down on "how to." There seems to be no published body of knowledge that will guide us through the reengineering of an organization. We don't claim to have read everything published on the subject. This is being written during the spring of 1994. Our stacks of books and articles fill at least ten feet of shelf space. The material is current. We talk to our colleagues. None so far have had any better luck.

We believe this book fills a major void. It describes how to do a reengineering project. Much of it was first written during a reengineering project in order to capture the day-to-day details that weigh so heavily on success.

What follows has been "field tested" for the last eight years.

It works.

Enterprise Engineering is being used right now by some of the most effective and successful public and private organizations as they shape themselves for the future.

My colleague, Ralph Loftin, and I started our consulting careers assisting companies to align their information systems with the corporate strategies. We used an engineering process with step-by-step procedures to define the appropriate information and information systems to support a specific corporate strategy.

Quite often we found it necessary to encourage change in the way the organization performs work in support of a strategy. These changes needed to be done prior to making information systems recommendations. We gradually realized we were "engineering" the enterprise in order to effectively engineer the information systems. Some time during 1990-1991, we started to call the process Enterprise Engineering.

Enterprise Engineering is:

. . . a means to quickly analyze an organization. The results of the analysis can be used to improve the products and services of the organization and to improve the way these products and services are delivered by the organization.

Graphical views of an organization ("Boxes and Lines") and the way it does work are developed as an integral part of the analysis. These graphics provide insight into an organization's character and suggest improvements in the way work is done. Business process redesign and/or business reengineering result. Improved quality, shorter cycle times, greater client satisfaction and lower costs are the tangible outcomes.

Enterprise Engineering uses the information developed by a strategic plan to define the specific areas within the organization that have the greatest impact on performance. Focusing change efforts on these high-leverage areas produces the greatest improvement for any given investment of resources.

If an organization does not have a strategic plan, Enterprise Engineering provides a framework for developing one. The Enterprise Engineering analysis and synthesis process calls for information on how the enterprise now operates and how the enterprise desires to operate. Often this information is available from other studies. Extracting the data from these other studies and placing it in the Enterprise Engineering format leads to a strategic plan.

The Enterprise Engineering methodology provides a framework for an organization to search for the work having the greatest potential to improve its performance.

Enterprise Engineering has:

. . . six distinct phases. These phases start with a preparation phase and complete with a "define work" phase. A seventh phase is included, that of "do it again," since everyday events begin to affect plans the moment those plans are defined.

The phases of work are:

	preparing
	defining the current situation
	developing a target for the future
	understanding the trends affecting the organization
	understanding the constraints faced by the organization
	defining the work to be done
	repeating the first six phases as necessary

Enterprise Engineering uses:

. . . a simple yet powerful business model as a basis for defining the current situation. The model allows people with a variety of interests and skills to view the enterprise in its simplest form, yet see how things work and why some things do not work as well as desired.

The business model has three major aspects:

Business Processes - The ways those outside an organization see, measure and are affected by the enterprise.

Business Functions - The accountabilities or responsibilities of the organizations within the enterprise.

Intersection Roles - The support provided by an organization (business function) to business processes. All the vital work done by an organization is done at the intersections of business processes and organizations. This is where the real work occurs and the accountabilities or responsibilities are fulfilled. The specific characteristics of the intersection roles provide a basis for specifying information support uniquely focused on the business process.

Enterprise Engineering develops work initiatives:

. . . by comparing the targets for the organization to its current situation and determining the roles or intersections which have the greatest influence on meeting the targets. The difference between "what is" and "what should be" develops a constructive and creative tension, drawing the enterprise staff towards improvement.

The intersection roles which have the most influence on achieving the target are identified and analyzed to define changes which will

move the organization closer to its targets. External trends and internal constraints are analyzed and accounted for as a part of developing action plans to improve the organization's performance.

An action plan is developed as a part of the methodology and includes:

	what is to be done,
	why it is a high-priority task,
	the resources required, and
	the time needed to perform the task.

 

These descriptions form the basis for implementation budgeting and project planning.

Enterprise Engineering:

. . . implements customer-centered business process redesign. The business model developed within Enterprise Engineering starts with the interactions the enterprise has with its customers, clients, vendors and regulators. All other work is done within this context. Any proposed change is tested against the external environment and the targets for servicing those outside the organization. The changes are forced to be in the best interests of those who give the enterprise its right to exist.

Enterprise Engineering analyses:

. . . typically require three months of half-time work by a team of knowledgeable insiders from the organization. The team needs to be supported by a facilitator experienced in the use of the approach. The organization must also be "open" to the probing done by the team.

Several "quick and dirty" sub-sets of the methodology are available. These use portions of the methodology so that the impact on a resource-limited organization is controlled. These alternatives focus on one or two phases of the methodology and give immediately useful results.

Enterprise Engineering fits:

. . . nicely with the reengineering approaches described in the new books that have hit the stands recently touting the importance of "Reengineering" and "Redesign." Those authors have forcefully and colorfully developed the need. But none have done much to tell us how. We like to think of ourselves as the 21st century version of Frederick Taylor doing the equivalent (uninteresting) work of helping the shovelers of sand do just a bit better. He took the "process" of shoveling sand apart in great detail and analyzed each of the "roles" that was necessary for the workman to perform in order to effectively move the sand from the railroad car to the siding.

We provide the analogous techniques to take apart the many processes that make up knowledge and service work, along with the guidelines for putting these processes back together in an engineered fashion.

 By John Blair and Ralph Loftin 

1994