on the needs of the business, but it would not require any software support. In a process that requires software support because of advancing technology, several generations of software, each with its own life cycle, could be employed without changing the process. Alternatively, for competitive reasons, a process could undergo considerable change during its life with corresponding implications on the software that supports it. In fact, one of the goals of the new view of process support software is to allow a process to undergo considerable change without the need to greatly change the underlying support software, which is designed to be process independent. Techniques for realizing that goal are examined in the discussion of software components in Chapter 14 as well as in Part III. The model defines four main subcycles of the overall process life cycle: plan, design, operate, and manage. The plan cycle is further divided into two additional subcycles: the business events plan and the business structure plan. Cycles are called cycles because they may be visited over and over during the lifetime of the process. They are not considered phases in the sense that, once a phase has been completed, it is never again invoked for the same development instance. In the methodology discussion, the term spiral is used to indicate a repeatable set of activities. That is in keeping with generally used methodology terminology. Using two different terms also helps differentiate between the life cycle model and the methodology that enables it. Each subcycle is discussed briefly to ensure that the definitions of all the assets in the subcycle, their major relationships, and their place in the overall enterprise process context are well understood. Details of most of the assets of interest are contained in other chapters. The purpose in this discussion is to understand the life cycle and its components as a whole. 8.2.1 Plan cycle The plan cycle is where the enterprise defines the business it is in and how it intends to support that business. In many, if not most, businesses, the definition is informal and has grown and changed throughout the life of the enterprise with little or no attention. Even businesses that devote a considerable amount of their resources to a planning function of some type do not have a model for describing and quantifying their expected interactions with customers or the structure by which they intend to meet the requests of those customers. Most businesses have been quite successful over a long period of time without a defined approach. That was possible because of the inherent constraints imposed by the hierarchical organization and function-based automation support. Those conditions, to a great extent, mitigated the lack of formalized models. With the change to a relatively flat, process-based organization and client/server distributed automation support, the lack of a planning model puts any enterprise at a considerable disadvantage. That disadvantage is external with respect to competitors who are able to model and understand their business. The disadvantage is also internal, in that the efficiency of operation will be far less than it could or should be with a well- thought-out model. For the remainder of this discussion, it is assumed that the enterprise has a formal planning structure of the type described here. Although other approaches to the plan cycle can be defined and successfully utilized, a discussion of their structure and characteristics and how they would fit into the other subcycles is beyond the scope of this presentation. The plan cycle is used to determine the definitions of the relevant business events and the enterprise operations processes. It contains two basic types of structures: (1) those devoted to understanding what the customer intends to request of the enterprise and expect in return and (2) those devoted to how the enterprise intends to respond to those requests. It would be expected that the two types of structures would be closely interwoven and their specifications performed in concert. In practice, that is not the normal situation. Both types of plan structures usually are defined and specified independently. The customer interaction definitions are provided by front-line or first-line supervisory personnel, who are intimately involved with the customers and understand their needs and expectations. The business structures, including high-level process definitions, generally are provided by executive personnel, who are far removed from “real” customers, and result from history, internal politics, and in many cases a lack of understanding of how the needs of the customers are being met. Considerable friction results from those two parts of the planning function being independent degrees of freedom. What should be a smooth response to a customer request or other business event becomes difficult when it is handled by a business structure not designed to accommodate it. Process reengineering was supposed to fix that problem, but the existing organization structure proved to be extremely resistant to change. The organization can remove layers, it can downsize, it can change technology, it can emphasize process over function, but it usually retains the old organizational structure boundaries. The engineering organization remains the engineering organization; the sales organization remains the sales organization; and the manufacturing organization remains the manufacturing organization. Whether one organization or another is the best one to meet the needs of the customer is relegated to secondary importance. There is turf to protect, careers to consider, and a general fear of the unknown. When everything around you is changing, there is usually something that is made to be stable. That “thing” in current enterprises is the existing organizational structure. Because the disconnection between defining customer needs and structuring the enterprise to provide for those needs is unlikely to change, the best approach is to develop frameworks and procedures designed to accommodate the two different views and mitigate any resultant friction and conflict. That is the approach taken in this presentation and in the methodology presentation in Part III. Experience has shown that such harmonization has worked well when put into practice. Sections 8.2.1.1 and 8.2.1.2 discuss the plan cycle areas and their major interrelationships. 8.2.1.1 Business events Business events are occurrences that elicit some type of response from the enterprise. The purpose of predefining expected events is to determine how to produce an effective response. An effective response is one that satisfies the requester (if the event is a request), is cost effective for the enterprise, and is consistent with the enterprise view of its purpose. Business events can be external or internal. They can be caused by customers, suppliers, employees, or other individuals associated in some way with the enterprise (including those with criminal intent). Business events also can arise from nonhuman sources, such as storms and earthquakes. To illustrate the usefulness of explicitly defining business events, consider the following example. An enterprise is in the retail shoe business and a customer requests the custom manufacture of a shoe. This event could be handled by the enterprise in a variety of ways: § The request could be rejected outright if the enterprise does not want to be in the custom shoe business and has no knowledge of organizations that perform that type of work. § As a service to the customer, the requester could be referred to another enterprise that manufactures custom shoes with no further involvement on the part of the retail establishment. § The order could be taken by the retail shoe business, sent to another enterprise for manufacture, and returned to the retail business, which would then deliver it to the customer. § The retail shoe business could manufacture the shoe itself using its own facilities and resources. The possible responses to the same business event are listed in the order of the business’s increasing involvement in the event. There is no right or wrong response to this event. Each response is possible depending on what business the enterprise believes it is in, what its resources are, and how it presumes its customers should be treated. However, if there is no attempt to predefine expected business events, the business will not have the opportunity to make this type decision explicitly. That could result in, among other problems, lost revenue opportunities, inefficient use of resources, and unhappy customers. The major automation asset used in the plan cycle is the scenario. Scenarios represent detailed business events that the enterprise expects to occur in the course of business and that it wants to be able to effectively and efficiently address. Scenarios provide a framework on which to model and examine the definitions and consequences of business events that the enterprise is prepared to handle. Scenarios are described in detail in Chapter 9. In addition to providing a structure on which to model business events, scenarios are also useful to distinguish planned business events from those that actually occur during the operation of the business. As would be expected, planned business events are referred to as scenarios, while actual ones are referred to as business events. Although that may seem a small point, considerable confusion occurs when the same term is used in the planning sense and in the operational sense. Scenarios are grouped by “story,” and many scenarios can have the same story. Individual scenarios are differentiated by the context, or specific set of circumstances associated with the scenario. The context for each scenario in a story group must be different. As an example, several scenarios can have the story “a customer places an order.” Individual scenarios with that story have different contexts. For example, the context could be formed by attributes that indicate the customer’s size, credit rating, frequency of ordering, and size of order. Each unique set of values for those attributes would be a different context and hence a different scenario. Depending on the specific need, scenario story groups or individual scenarios could be used in the individual subcycles of the process life cycle. 8.2.1.2 Business structure This cycle contains assets related to the structure of the enterprise and includes process definitions as well as the specification of the organizational units and their responsibilities. Ideally, these assets should be contained in a comprehensive business model along with the enterprise view of other models of critical importance, such as a data model and network model as appropriate for the business. This business model could be used in a number of different ways, including comparison of the business to competitors, determination of the validity of software product requirements, and measurement of the internal efficiency of the business. Unfortunately, in most cases, a formal business model does not exist, or it is at such a high level that no real use can be derived from it. In that case, the necessary models still can be defined, but they may not be as tightly coupled as would be desirable. Process class model If a business model does not exist or does not contain a process class model, a process class model must be created. That is accomplished by defining the overall business operations process and then decomposing it into subprocesses. The decomposition continues until processes are obtained that can be implemented through manual and automated operations and deployed so that individuals can utilize them in performing their job assignments. Such a procedure is illustrated in Figure 8.2. The root process is decomposed into branch processes, which are then further decomposed as necessary until the leaf processes are reached. The leaf processes eventually are implemented and deployed. The root process and the branch processes are utilized only to arrive at the implementable leaf processes. The resultant structure defines part of the class model. The remaining part of the class model is determined by the relationships among the leaf processes. Figure 8.2: Decomposition of the business process. The definition of the leaf processes that will best support the business is one of the two most important activities in a management-by-process approach. The other activity is implementation of those leaf processes. When all is said and done, specification and implementation of the leaf processes are the heart and soul of process engineering. With any decomposition procedure, there is always a question as to how many levels are needed and what the termination criteria should be. In the case of business processes, it is strictly an issue of management of complexity and resources. Process decomposition should continue until the leaf processes are of such a number and complexity that the enterprise feels comfortable about its ability to define each of the processes in detail. Another important question in process decomposition is the information that should be included in the initial definition of each process. At a minimum, the name; description; relevant business events, products, and services; business rules; and resources utilized should be included in this high-level model. For example, consider a leaf process defined to satisfy some maintenance business events. The process initially could be documented as shown in Table 8.1. Eventually, as detail is added in Chapters 13 and 15 and Part III, other models of the leaf process are specified and introduced during the appropriate discussions. Table 8.1: Example of Leaf Process Documentation Name Maintenance Process Description: The purpose of the maintenance process is to keep the equipment in good operating order and to minimize the time a given piece of equipment is unavailable. The maintenance process must also provide for the timely repair and testing of Table 8.1: Example of Leaf Process Documentation Name Maintenance Process inoperable equipment. Resources: The maintenance process utilizes dedicated resources (people and facilities). It has a fixed yearly budget for all aspects. Business rules: The maintenance process is not responsible for repair in the aftermath of a disaster, such as a fire or flood. The maintenance process is responsible for initial setup and certification of new equipment. Except in emergencies, it cannot completely shut down another process or result in a significant increase in manufacturin g costs. Business events: Report of inoperable equipment Arrival of new equipment Time for equipment maintenance Products and services delivered: Equipment Table 8.1: Example of Leaf Process Documentation Name Maintenance Process repair New equipment certification Scheduled equipment maintenance Organization charts The most often created model of an enterprise is not the process model but the organization chart. Almost every business with more than a few employees has one. An organization chart defines the partitions of the business (usually called organizations), the responsibilities (usually called functions) of the organizations, and the reporting relationships of the organizations. The organization chart is a static model that is suited to the hierarchical structures of the past. It cannot show how the enterprise organizations would respond to a business event. Usually, responses to business events generally were documented informally or through written practices or procedures. Usually, the process by which an event was handled was “just known.” For example, “First the order goes to the order department, then it goes to the engineering department, then it goes to the manufacturing department, and finally it goes to the shipping department.” Other departments may be involved for billing, purchasing, and so on, and their roles in responding to the order usually are defined in the same informal way. Those major partitions of an enterprise probably are not going to change significantly. Almost always, too much history and politics are involved. How, then, is the enterprise going to formally model its response to expected business events without eliminating the organization chart? The current and most obvious answer is to define each major partition as a process. The billing organization gives rise to the billing process, the shipping organization defines a shipping process, and so on. This type of partitioning occurs quite often, even if the enterprise pretends that it is entirely process based and defines and decomposes high-level processes in the manner presented in Figure 8.2. Decomposing those high-level processes seems to result in a one-to-one relationship between a leaf process and an organizational unit. The major problem with that one-to-one relationship is that an organization-based process may not be the most appropriate one to handle a set of expected business events. That is especially true for those events that need more than one organization to be involved in the response (the usual case). It is also possible, even with the best of intentions, to arrive at leaf processes that are inappropriate for the set of business events that must be serviced. That can result from inexperienced staff performing the decomposition or from lack of knowledge concerning the vision and the goals of the enterprise. What happens in that case is that the vertical automation silos (discussed in Chapter 1) resulting from the traditional organization- or function-based approach are replaced with horizontal silos based on an organization approach to process definition. The horizontal silos are, in essence, the vertical silos rotated 90 degrees. Figure 8.3 illustrates this rotation for the vertical silos of Figure 1.2. In either case, because of the lack of integration, the silos inhibit the development of the needed end-to-end processes. Fortunately, there is a relatively easy method of mitigating problems with leaf process definitions, regardless of how they occurred. That method is discussed in Part III. Figure 8.3: Horizontal silos of automation. Business rules The general definition and structure for business rules were described in Chapter 5. Business rules as applied to processes are of particular interest in the context of the process life cycle. In that context, business rules are defined to be constraints on the enterprise processes or their relationships. Business rules can be defined that apply to all enterprise business processes, a set of processes, or only one process. Business rules can be defined at any level of process decomposition or specification, including implementation. Business rules can assume different forms and contain different information, depending on the level at which they are defined and the particular process(es) to which they are applied. Business rules also can be applied to different aspects of a process and its implementation, including the flow control of the process, the functionality required by the process, the data used in the process, and the assignment of human performers to the process. Process maps Once the leaf processes have been defined, considerable detail must be added to their specification to allow for their eventual implementation. A model that can accommodate that detail in a structured way and serve as a framework for the necessary analysis and testing must be defined. Because of the difficulty in working with the strictly text-based representation model utilized in the decomposition procedure, the new leaf process model is usually a combination of graphical, text, and data formats in a well- defined configuration. For simplicity, at the risk of introducing some confusion, this discussion of process representation and analysis utilizes the word process to mean a leaf process. Because only leaf processes are implemented, that should not cause undue confusion. Detail is added to the process specification in several ways throughout the implementation period, which starts with the availability of the leaf process(es) definitions and ends with product deployment and operation. Because the detail-adding activities are under control of the implementation methodology, most of this discussion is given as a part of the methodology presentation. Only enough of the procedures are covered to provide an understanding and motivation for the overall life cycle and its individual components. The detail that is added to the process specification during the business structure cycle is designed to accomplish two basic results: The first is to determine and specify, at a relatively high level, the functions, information flows, and skill definitions necessary to implement the process. The second is to determine if any of the automation assets have been previously defined so they can be reused. The structure and detail level of the process model must be such that reuse of any previously defined functions, information flows, and skill definitions is facilitated. There are guidelines for determining the proper size and complexity of those assets so that reuse is maximized. The guidelines are discussed during the methodology discussion. The ability to reuse assets specified at the process level can result in significant savings in implementation and deployment costs. One representation model that seems to allow processes to be detailed and examined effectively from the business perspective is the process map. The format of the graphical portion of a process map is shown in Figure 8.4. It consists of process steps arranged according to their assigned roles and precedence order. If desired, organization information also can be included, although it is not strictly required. Figure 8.4: Example of a process map. Process steps can be either functions or decisions. Process steps can occur in parallel, although the map usually tends to be highly sequential for two reasons: § Business function subject matter experts (SMEs), using explicit or implicit scenarios, tend to think in a sequential manner when determining the functions and decisions that can be utilized to realize a specific process. § The sequential format simplifies the use of the map in determining if the map assets can support the handling of associated business events as defined in appropriate scenario groups and individual scenarios. Although the process map realization has certain characteristics that are not an inherent property of the process it represents (e.g., very sequential functionality), those artifacts do not matter as long as the map is successful in showing that the scenarios are capable of being satisfied through the defined functionality. The representation artifacts can be removed later during the design/build activities. Roles are shown as horizontal segments on the process map. The purpose of roles is to define the skill sets necessary for performing a given part of an implemented process. The definition and utilization of roles are examined in Chapter 10. Optionally, organization units that contain those roles also may be incorporated in the same format as the roles. Incorporating organizations does provide an additional comfort level to many SMEs and their management, but it is not necessary and, indeed, may prove to be an unwanted distraction. The process map framework requires that additional information be specified for each process step, including the following: § A comprehensive description of the process step (function or decision) in addition to a descriptive name of some sort; § Specification of any particular approach or algorithm that must be used in an implementation; § The information needed by the process step; § The information produced by the process step; § Operational data as known (e.g., throughput, number of performers, physical locations). The additional specifications generally are documented in a separate text format so that the graphical map format does not become too cluttered. How the two formats are related and utilized is a tool implementation issue and is not discussed further at this time. The difference between information and data as specified in the process map is discussed in Chapter 11. Connections between process maps During the development of a given process map, the determination of the relationships that need to be established between its process steps and the process steps of other maps needs to be made. That usually is performed at two levels, depending on the amount of information available concerning other maps. Level 1 simply specifies that there is a relationship between a process step (input or output) and another process. The existence of a relationship should be communicated to the developers of the other map involved (if they are a different set of individuals), but detailed coordination is not necessary at this level. The communication also should be made to any stakeholders (concerned individuals) of both maps. Level 2 requires identification of the specific process step in the related process map and the exact nature of the relation (e.g., precedence order of the two steps). This requires agreement from the developers of the related map who must reflect the same relationship in their map. Eventually, all process step relationships must be defined on a process step–to–process step basis, whether the two process steps are in the same map or in different maps. During the initial development of the process map, the scenarios that form the scenario group specific to that map (e.g., billing scenarios for a billing process) are used as an aid to ensure that the map can accommodate those scenarios effectively. Without the availability of the scenarios, it would be much more difficult to determine if the map assets were capable of providing the response to the business events that the process was defined to handle. After the basic map has been developed, scenarios that require multiple processes for resolution can be used as an aid in determining the needs for specific process relationships. Process relationships are further refined as multiple processes are tested together. Process understanding While the development of the process map is oriented toward arriving at a representation of the process that can serve as the basis for an implementation, there is another important consequence of the map specification activities. That consequence is the fostering of a much improved understanding (from what is usually available when a process is first defined) of the function and the purpose of the process as well as its projected use in the enterprise. Although it is an implicit by- product of the map specification, this improved understanding probably has as much (if not more) impact on the final implementation of the process as the map structure itself. During the design/build cycle, it is relatively easy to find and correct any structural problems with the map (e.g., steps that should be decomposed or missing information flow). It generally is much harder to find and correct fundamental misunderstandings concerning the function and the use of the process in the enterprise (e.g., because of some natural affinity, parts of the process should be placed in other processes). Detection of such later types of problems is best accomplished during the development of the process map representation, hence the emphasis on process understanding during development of the map. Process prototypes Construction of the process map is extremely useful in producing a greater understanding of the use and the context of the process and determining the process requirements for function, information, and skills. However, to be useful as an implementation vehicle, the process map must be tested as rigorously as resources permit to determine if it is constructed in accordance with the definition and the purpose of the original process. The testing is accomplished by utilizing all the scenarios that in any fashion require the functionality of the process map under test. If possible, for scenarios requiring multiple processes, it is also desirable to test the process in the context of the other processes so that the connections between them also can be tested. That does not have to be done at the time of initial process map testing, but it does have to be performed at some time before the completion of the design/build cycle. Before testing starts, the process map is converted into a process prototype. If tool support is not available, that simply means that a wall-size copy of the process map is printed and declared to be the prototype. The process prototype engine in that case is human. (The author has been an engine of this sort many times and frankly enjoys the experience.) If tool support is available, the process map definition is made available to the tool that contains the process prototype engine. The specific mechanism used depends on the tool and the environment being used. The process prototype is one of a number of prototypes that are defined and used throughout the life cycle of the process. Each prototype is used to test a different aspect or level of a process representation. It is only through the prototypes that the detail required for process implementation can be tested for compliance with the definition of the original process and its associated business events. Testing is initiated by selecting a scenario that is of critical importance. Using either a human or an automated prototype engine, the sequence of process steps that result from applying the conditions of the scenario to the process map is identified. There can be several possible outcomes from that activity. Some of those outcomes are outlined in the following list, along with an indication of the action that needs to be taken. In actual practice, there are many possible results and even more actions that can be taken, depending on the specifics of the problem and the process. § Result: A sequence of process steps occurs, ending with a normal termination point, that provides the desired outcome. Action: None required. The scenario test has been successful. § Result: A sequence of process steps occurs, ending with a normal termination point, that does not provide the desired outcome. Action: Change the process map so the desired outcome occurs. That may involve changing the definition of a process step, adding process steps, or changing the relationships between process steps. § Result: A sequence of process steps occurs, ending with an internal process step for which there is no reasonable successor. Action: Change the process map so the desired outcome occurs. That may involve changing the definition of the terminating process step or previous process steps, adding process steps, or changing the relationships between process steps. § Result: The scenario is not detailed enough to be able to identify the path that should be taken for at least one decision point. Action: Change the scenario so that the decision point is explicitly defined. This will also usually involve the creation of another scenario that will indicate that the opposite decision point should be taken. Once the scenario run is successful, the next most critical scenario is selected and the procedure repeated. That continues until several of the most important scenarios run successfully. The actual number of possible scenarios is extremely large, and only a fraction can be utilized in this procedure. The main purpose of the process prototype testing is not to test the process exhaustively (not a tractable activity) but only to obtain confidence that the process representation is reasonable. Achieving such confidence does not mean the process map will not change in the future (it undoubtedly will) due to many other possible factors. Successful runs of a number of critical scenarios at this stage of definition mean only that the process has been successfully represented in a form that can be communicated to all enterprise personnel who need a working knowledge of how the implemented process will function. That can be demonstrated through the use of the map and scenarios of interest. The scenarios used in the testing of the process map are saved and will be used again when other representations of the process are defined during the design/build and operate cycles of the process life cycle. By using the same scenarios, the reactions of the process representations can be compared. That greatly assists in the determination of the correctness of a representation. Additional scenarios can, of course, be added to the test suite at any time during the implementation. Regardless of how it is accomplished, the result of a scenario run against the process map is a process step sequence called a process scenario trace. Examples of scenario traces for the process map in Figure 8.4 are shown in Figures 8.5 and 8.6. Exactly how the sequence is identified, displayed, and documented is a function of the tool or human procedures utilized. The exact formats are not critical but need to be defined, with an efficient transfer of information as the main goal. [...]... 1998, pp 43 48 Pennell, J., J Stepper, and D Petrozzo, “Concurrent Engineering of a Service Order Process, ” Proc 46 th Ann Quality Cong., Nashville, May 1992, pp 6 34 641 Profozich, D., Managing Change With Business Process Simulation, Englewood Cliffs, NJ: Prentice-Hall, 1997 Sheer, A.-W., Business Process Engineering: Reference Models for Industrial Enterprises, 2nd ed., Berlin: Springer-Verlag, 19 94 Sundstrom,... the information contained in the map, including further specification of the control, data, and functionality required; 3 To represent the process in a format that will provide a more efficient implementation than the process map format will permit; 4 To allow previously defined and implemented functionality to be reused in realizing the process, greatly increasing the implementation productivity; 5... relevant portions of a process map when the logical design with which it is associated changes Of course, the same is true for a process map change The logical design associated with the area of change also must be examined and modified as appropriate It is possible for the process map to change without affecting the logical design and for the logical design to change without affecting the process map Although... appear similar superficially § The process map format lacks information essential to designing a workflow (e.g., detailed functionality, data, and workforce descriptions) § The purpose of the process map format is to gain a business- oriented understanding of the process and the functions, information, and skills involved It is not intended to be directly implemented o The process steps are significantly... technical information necessary for eventual implementation in the enterprise environment As initially specified in the process map, there is no guarantee that the process is implementable Environment, technology, and financial constraints may not allow the process to be effectively implemented without changes to the process map or the original process specification Implementation- oriented process representations,... al., Business Process Components for Distributed Object Applications,” Communications of the ACM, Vol 41 , No 6, 1998, pp 43 48 Briccarello, P., G Bruno, and E Ronco, “REBUS: An Object-Oriented Simulator for Business Processes,” Proc 28th Ann Simulation Symp., Phoenix, Apr 9–13, 1995, pp 269–277 Chung, L., and B A Nixon, “Dealing With Non-Functional Requirements: Three Experimental Studies of a Process. .. to be defined on which to perform the tests The implementation representation structure is based on the physical design representation discussed in Section 8.2.2.2 The implementation format must allow a great degree of flexibility With that flexibility, process updates required by the changing business climate can be made quickly and accurately In addition, of course, the implementation must be an accurate... of the process As such, the physical design must be tested by using the scenarios in a fashion similar to that described for process maps and the logical design 8.2.3 Operate cycle The operational process implementation is the representation of the process that is used to respond to real-life business events As a process representation, it also should be tested through the use of scenarios before being... design/build cycle is to translate the process map and associated information, as described in the plan cycle, into a product that can be deployed and used to handle business events That involves changing the process representation format from that of the process map, which emphasizes the business needs of the process, to other formats that are more technically (implementation) oriented The latter representations... from a business point of view To translate that information into a form more suited as the basis for eventual implementation, a more technically oriented representation of the process must be created and utilized The initial representation is called the logical design The logical design comprises different parts, each emphasizing a different aspect of the information needed by the implementors It is . tested for compliance with the definition of the original process and its associated business events. Testing is initiated by selecting a scenario that is of critical importance. Using either. of complexity and resources. Process decomposition should continue until the leaf processes are of such a number and complexity that the enterprise feels comfortable about its ability to define. process. Business rules can be defined at any level of process decomposition or specification, including implementation. Business rules can assume different forms and contain different information,