INFORMATION TECHNOLOGYLance B. Eliot, Feature Editor, Eliot & Associates Managing the Corporation via Enterprise Modelsby Lance Eliot, Eliot & Associates There is an old saying that without a map in hand, any path will do. Of course, the path chosen may not lead to the desired destination, or may be excessively long and laborious to follow. Similarly, many corporations are run by managers that fail to have a map in hand, and thus their ability to direct the organization and achieve desired financial and managerial results is significantly hampered or quashed altogether. For most corporate planners and strategists, the reference to an organizational map usually evokes visions of a corporate strategic plan. Though such a plan is an essential element of a total mapping system, in this instance I am referring to the latest corporate mapping addition, namely, enterprise models. An enterprise model is a dynamic rendering of an organization that can readily be accessed, simulated and comprehended by top-level managers of the firm. The use of information technology has greatly increased our ability to create and sustain such models, and the latest improvements in information technology now make enterprise models affordable and attainable. In its simplest form, an enterprise model portrays the various business processes of an organization and allows managers to see the chain of activities that lead from product or service initiation to final delivery to the customer of the firm. These business-process-oriented models are normally developed as part of a business process reengineering effort. And, given the meteoric rise in popularity of business process reengineering, more and more firms are developing these limited variations of enterprise models. Indeed, as a frequent speaker about business process reengineering, I always note that rather than starting with a blank sheet of paper when doing reengineering (as has been advocated by some of the more vocal reengineering gurus), I urge companies to start with a blank screen. In other words, capturing existing or desired business processes on paper is backward and omits the critical capabilities permitted by computer-based models. With a computer-based enterprise model, an organization can track versions of the model as it changes over time, and the model can be viewed from differing perspectives and levels of detail depending upon the specific need (i.e., seeing the entire firm, seeing marketing only, seeing the interconnection between manufacturing and marketing, and so on). Furthermore, no matter how much an organization would like to wave a magic wand and pretend that the existing ways of business do not exist, and pretend that a new design of business will take root instantaneously, the reality of business process reengineering is that you have to map where you are today and then map where you want to be. Then, you can make plans on achieving your reengineering goals. Again, the notion of starting with a blank sheet of paper does not lend itself easily to seeing where you are and where you want to be. But, with a computer-based model, you can continually refine and update the model on-line, and make comparisons to the existing way of business and the proposed way of business. A good enterprise modeling system even allows simulation of changes to detect the impact on the business and the magnitude of business gains or losses that may occur. Though the preceding discussion emphasizes the business process aspects of enterprise modeling, there is also the important aspect of data elements that must similarly be mapped. Data is an integral part of enterprise models. Firms push data back-and-forth between business processes, and the flow of data can help or hinder the best designed business processes. In the information technology field, the most common form of data modeling involves the use of entity-relationship diagrams and techniques. Entities are representations of data and can be described at a high-level (such as "accounts payable data") and at lower levels (specific data items such as a purchase order, a bill, a contract). Data models can be used to understand the flow of data or information and aid the streamlining of business, reduce clutter, and make sure that the right piece of data reaches the right person at the right time. A complete enterprise model should have both a process model(s) and a data model(s), and indicate the interaction between the two. You can have only process models, or only data models, but the big picture is less likely to be seen as a result. As an example of the rise in popularity of enterprise models, a recent issue of Harvard Business Review touts the use of enterprise models for running a business via its informational representation (interested readers might want to read "Managing By Wire" by Stephan Haechel and Richard Nolan in the September-October 1993 issue of Harvard Business Review). It has become common to hear analogies made between flying a plane "by wire" (meaning using computer systems to examine the plane's status and relay pilot commands to the numerous controls and mechanisms that make a plane actually fly), and the similar notion of managing a firm "by wire." The wire reference for organizations brings forth the essential nature of an enterprise model, the equivalent of a cockpit for top-level executives running modern organizations. I like the preceding analogy because it simply and visually gets across the value and purpose of an enterprise model. But use of the analogy should be used cautiously since not all aspects of the analogy really make sense for the organizational equivalents of flying. For example, a plane is a very stable object. After construction, a plane will undergo relatively minor changes, and the cockpit modeling system can easily detect whether a given component is functioning properly or not. The model is static, can be tested for correctness, and can make assumptions about the principals of flight and the impacts of plane problems or errors on the overall flight capability. I doubt the same can be said for organizations. Few organizations remain static. People come and go, procedures are continually being changed, outside forces cause the firm to modify its structure and approach, etc. Suggesting cause-and-effects in organizations is fraught with difficulty and there are, sadly, very few commonplace principals of organizational dynamics that can be applied to why firms do what they do. In that sense, an enterprise model is actually tougher to construct than a model to control a plane. On the other hand, the model of a plane had better be precisely accurate, otherwise the plane will crash. With enterprise models (even a poor model that loosely captures the firm), there is still an overwhelming dependency upon the judgement of managers--and the "crashing" is more akin to stock price drops, sales drops, or other corporate maladies. This last point brings to light the need to understand when and how an enterprise model should be used. Putting a firm on "auto-pilot" by somehow allowing an enterprise model to run a firm directly is not in the cards for present day enterprise models. Currently, enterprise models are aids to managers. Managers still make the decisions and take actions. Interestingly, the analogy between pilots and managers leads to another useful point. Besides the fact that managers should carefully determine whether they can rely upon the enterprise model to be correct (just as a pilot needs to know whether the auto-pilot can be trusted), there is another question that must be posed: Is the manager up to the task of running the organization? A pilot is usually considered sane, skilled, focused, conscious, and can be trusted to fly the plane properly and make judgments about the use of the plane's on-board systems and models. Can the same be said for managers? Suppose that a good enterprise model exists in an organization. Will managers be able to use and apply the model? Will they be sane, skilled, focused, and will the politics and other organizational elements of the firm promote them toward its use? I mention these questions because the rise in popularity of enterprise models offers both good and bad tidings for organizations. Information technologists that merely strive to build a good enterprise model must also take account the managers that will be called upon to use the models. A model that isn't used, or used improperly, is probably worse than no model at all. In any case, the map makers should take pride in not only the look of the map, but whether the map can be used to get people from where they are to where they want to be. As you manage by wire, please do not crash and burn.
Remember that your input is welcomed. If you have projects
addressing the information technology area, and you would like to
share this with readers of ``Information Technology'', please write
to |