BPMDS'06 137 Defining Requirements for Business Process Flexibility Kuldeep Kumar1,2,3 and Murali Mohan Narasipuram4 1 Visiting Professor, Department of Information Systems, City University of Hong Kong, 83 Tat Chee Avenue, Hong Kong http://fbweb.cityu.edu.hk/staff_info/staff_cv2.cfm?sno=kkumar 2 Professor of IS Research, RSM, Erasmus University, NL 3 Professor of IS, Florida International University, Miami, USA 4 Associate Professor, Department of Information Systems, City University of Hong Kong, 83 Tat Chee Avenue, Hong Kong http://fbweb.cityu.edu.hk/scripts/staff_cv2.cfm?sno=ISMOHAN Abstract. The recent work on business process flexibility focuses primarily on defining and classifying business process flexibility and developing strategies, architectures, and tactics for achieving it. However, to specify the required type and level of business process flexibility it is essential to understand how the need for flexibility arises in the first place, and how this need affects the re- quirements for flexibility. The objective of this position paper is to examine the characteristics of the environmental variations that provide the stimulus for de- signing business process flexibility and its implications for the design and man- agement of business processes. 1.0 Introduction Regev and Wegmann (2005) define flexibility as the ability to yield to a change with- out disappearing. Business Process Flexibility (BPF) is the capability of business process to change. Thus, a business process is considered flexible if it is possible to change it without replacing it completely (Regev, Soffer, and Schmidt, 2006). Regev, Soffer, and Schmidt (2006) go on to compile a comprehensive set of the possible types of changes in business processes, thereby creating a taxonomy of business proc- ess flexibility. This, in turn, leads to significant investigations about concepts and techniques for modeling business process flexibility and strategies, architectures, and tactics for achieving it. Thus business process flexibility can be examined from three perspectives: the char- acteristics of the stimulus that generates the requirements for business process flexi- bility; business process flexibility itself; and the strategies and tactics employed to achieve business process flexibility. These three perspectives together define an over- all framework for examining business process flexibility (Figure 1). 138 Business Process Modeling, Development, and Support Stimulus for Strategies and Business Business Process Tactics for Process Flexibility (BPF) Achieving BPF Flexibility (BPF) Figure 1: A Framework for Studying Business Process Flexibility Ideally all three perspectives of flexibility should work in consonance. Business Proc- ess Flexibility should be designed in such a way so as to meet the demands of varia- tions, whereas the strategies and tactics for achieving business process flexibility would be appropriate to meeting the BPF design requirements. Practically, sometimes the link between these three perspectives of flexibility is sometimes not explicit. The recent work on flexibility in general and business process flexibility in particular focuses primarily on defining and classifying business process flexibility and devel- oping strategies, architectures, and tactics for achieving the requisite levels of flexibil- ity. There is only minimal work that examines the antecedents of business process flexibility, that is, the characteristics of the variations that give rise to the need for flexibility. However, to specify the required type and level of business process flexi- bility it is essential to understand how the need for flexibility arises in the first place, and how this need affects the requirements for flexibility. The objective of this position paper is to examine the characteristics of the environ- mental variations that provide the stimulus for designing business process flexibility and its implications for the design and management of business processes. The paper is organized as follows. The next section describes the theoretical under- pinnings of the need for flexibility derived from Herbert Simon’s conceptualization of the design of an artifact (Simon 1996) and Ashby’s law of requisite variety (Ashby 1958). Section 3.0 presents a definition and categorization of the need or stimulus for flexibility. Section 4.0 relates this categorization to the various responses to this need as outlined in taxonomy of business process flexibility proposed by Regev, Soffer, and Schmidt (2006). Finally Section 5.0 ends with a set of concluding remarks about the implications of this framework. 2.0 Theoretical Underpinnings of the need for Business Process Flexibility “Only variety can destroy variety” (Ashby 1958) In this section we discuss two seminal works from system sciences and cybernetics that underlie our discussion of the rationale or stimulus for flexibility: Herbert Simon’s concept of an artifact, and Ashby’s Law of Requisite Variety. BPMDS'06 139 Following Herbert Simon (1996), we consider business processes to be goal-oriented design artifacts that need to adapt to the requirements of its inner and outer environ- ments. The outer environment of the business process is the environment the process operates in, including the demands (or outcome demands) from its customers, the sourcing of process resources from its suppliers, and its social, technical, and eco- nomic contexts. The inner environment of the business process is its structure, its actors and resources, and the flows and business rules. Simon defines the design of the artifact as the design at the interface between the outer and inner environments (Simon 1991, p.7). Flexibility of the designed artifact (in our case the business proc- ess) is its ability to adapt to the variations in or changing requirements of its environ- ment, in order to continuing meeting its goals. The adaptation in the process artifact can either be reactive, as a result of experiencing a variation in the environment, or proactive, as in anticipation of a variation or changes. The Law of Requisite Variety, often called Ashby’s Law (Ashby 1958), provides guidelines for designing flexibility in systems. The law tells us that a "system" has "requisite variety" if its repertoire of responses (that is, its flexibility) is at least as big as the number of different stimuli it may encounter in its environment. A system without requisite variety will fail whenever it encounters the unexpected and as such is not a "viable system". We see examples of this all the time in business processes where a process with a limited set of responses is unable to react to greater variations in the requirements on the process. We differentiate between two types of business process flexibility – Pre-Designed Flexibility: the need for process flexibility is anticipated and by the process designer and therefore process flexibility is pre-designed; and Just-in-Time Responsive Flexi- bility – flexibility that is created on the fly by the process manager1 at the time of occurrence of the unanticipated or ambiguous variation. Pre-designed flexibility is built into the design of the process; just-in-time responsive flexibility requires an intelligent process manager who can interpret the unanticipated variation and design the flexible response to it at the time the variation occurs. The differences between the two types of flexibilities depend upon the nature of the variability of the environment, the underlying reason or stimulus for flexibility. 3.0 Need or Stimulus for Business Process Flexibility Design of requisite business process flexibility thus requires an understanding of the variations and perturbations that is the stimuli that require a flexible response from the business process. In this section we explore the characteristics of the stimuli and 1 Process manager is a role that is responsible for the management of the overall busi- ness process. The incumbent in this role could be an individual or a team of people. 140 Business Process Modeling, Development, and Support their general relationship to business process flexibility. We provide a taxonomy of stimuli to Business Process Flexibility in Table 1. The BPF stimuli are explained in terms of their description, the number of paths for process fulfillment, the response responsibility and the level of flexibility resolution. Then, we illustrate this taxonomy by using two exam- ples, one from disaster response processes, and the other from the example of an order fulfillment process for computers. A Business Process is a collection of interrelated work-tasks, initiated in response to an event that intends to achieve a specific result for the customer of a process. Work- tasks are performed by Process actors. Actors may manage other actors, tasks may consist of other tasks, actors manage or control resources, and actors deploy the re- sources in performing tasks to meet the customer’s requirements. Process manage- ment is a higher level process that monitors, adapts and controls the overall process. The intended specific result for the customer is expected to be achieved despite the variety and variations in the stimulus to the process. The process identity arises through the identification with the process customer-type and their required process deliverables. Thus, as long as the customer-types and the required deliverable-types are constant, the process maintains its identity even though the tasks within the proc- ess and their interrelationships, or process actors and resources may change. Ilia Bider (2005) in his keynote talk last year in BPMDS 2005 observes: “When you ask people how they do things, they, most probably, will know how things are done in “normal” circumstances, forgetting many of not so normal cases. ….No wonder the end users then start complaining about “lack of flexibility” as soon as the system is in place.” (Bider 2005, p.7) Thus, often systems are designed only for the normal case, and therefore have a monotonic response behavior. However, as Bider points out, monotonic systems are rare, and systems that are designed to be monotonic are often the result of inadequate requirements analysis. Next, following the discussion in Section 2.0 we recognize that the requirements for flexibility may arise due to variety in stimuli that can either be pre-identified and pre- defined, or can be the result of ambiguous or unanticipated variations in stimuli. We further differentiate between ambiguous variations in stimuli, i.e. variations that can not easily be understand and classified, but are still within the range of existing ex- perience, and variations that come as complete and total surprise. In the case of variations in stimuli that can be anticipated and pre-defined the designer of the process can build-in the flexible response at the level of the process itself. This requires that all variations are identified crisply as mutually exclusive and collectively exhaustive. Thus pre-defined selection/decision points in the process can be used to steer the process in line with the contingency. Flexibility is thus resolved within the process. However, in the case where variation in the stimuli is either ambiguous, or is totally unexpected, the requisite flexibility cannot be built into the process. In these cases, process flexibility can be achieved by passing the responsibility for interpreting the variation and designing the response to an intelligent and innovative decision- maker above the process, the process manager. BPMDS'06 141 To illustrate the variations in characteristics of the stimuli for business process flexi- bility we next examine two examples: (i) processes for responding to a hurricane, and (ii) an order fulfillment process for an order for a computer. We will describe the BPF stimulus, typical response and the response responsibility for two examples above in Tables 2 & 3 respectively. 4.0 Relationship between the Stimulus for Flexibility and Business Process Flexibility Regev et al (2006) have classified business process flexibility with respect to the types of changes it enables. Their classification includes three orthogonal dimensions: the abstraction level of the change (type and instance), the subject of change (func- tional perspective, operational perspective, behavioral perspective, informational perspective, and organizational perspective) and the properties of the change (extent, duration, swiftness, and anticipation). We suggest that the characteristics of the stimu- lus defined above can be used to identify the requirements for business process flexi- bility identified by Regev et al. However, before we do so, we need to re-clarify the understanding of the concept of flexibility and change. Above we had defined flexibility as the capacity of adapting to variations. We also demonstrated that this capacity, to some extent, can be built into the design of the process itself (Type B stimulus). Thus in case of stimuli Type B we do not need to change the design of the process. We have a self-adaptive process. The process flexibility is inherent in the process design and manifests itself through the choice of alternate paths for different process cases. However, in cases C and D the flexibility is not completely built into the process design. It requires an intelligent process manager to interpret variations, select or change the design of the process in response to the variation, and execute it. Thus qualitatively, this change is different than the type B change and includes changes in process design as well as process enactment. Tables 4, 5 & 6 show how the BPF taxonomy proposed in this paper explains the three orthogonal dimensions described above. It is possible that in some cases, we may not directly relate the level of stimulus to the type of business process change. Perhaps this could be part of the discussion in the workshop. It is our conjecture that this problem could be due to two types of ambiguity. First, there is considerable am- biguity in the commonly used terms “flexibility” and “change.” For example, it is not clear if the change is with respect to the “normal” case or is it with respect to the designed process. It can be argued that all changes are only with respect to the “nor- mal” case. In that case, any variations from the norm, whether anticipated and de- signed for as a contingency, or unanticipated, will be considered a flexibility require- ment and hence a change. On the other hand, if the change is with respect to the de- signed process, the need for flexibility and therefore change arises only in the case of 142 Business Process Modeling, Development, and Support anticipated change. Second, the difference between ‘Process Type’ and ‘Process instance’ needs clarification. For example, in the case of anticipated and designed variations, each unique path may be considered a process instance. In this situation, the anticipated variation would lead to a designed change as a new process instance. On the other hand, an unanticipated and therefore, not designed for variation may result in changes to the process design (type) itself. Therefore, it is important that such ambiguities in definitions of change be clarified before the levels of stimulus can be substantively related to business process flexibility changes. Perhaps, this could be a matter for discussion and clarification during the Workshop. 5.0 Learning in Business Processes The taxonomy of BPF stimulus described above also suggests that learning occurs in organizations in the way they progressively deal with the different types of BPF stimulus. From the simplistic view of BPF stimulus as Type A (constant), organiza- tions may learn the different exceptions to be handled and mature the stimulus model into Type B. Organizations learn from their ambiguous situations how to model and manage the ambiguities, thus bring down Type C to Type B. Similarly, organizations may learn to move Type D to Type C once the ‘surprise’ has occurred at least in am- biguous terms, and then to Type B by defining a predefined crisp set of stimuli. For example, in the aftermath of 2004 Tsunami, governments and disaster relief organiza- tions are installing early warning systems and revising their standard operating proce- dures to include processes for assessing and managing future Tsunamis. The target of business process flexibility designers is to design processes with re- sponse sets for the utopian Type A BPF stimuli and at least, the more pragmatic Type B stimuli. In addition, the designers should build in continuous learning mechanisms in the processes to move the Type C & D stimuli into Type B. 6.0 Conclusions As the above discussion shows, before we can specify and design flexible processes we need to understand the requirements that lead to the need for flexibility. Accord- ing to both Simon and Ashby, systems, to survive, need to continuously be responsive to and adapt to variations in their inner and outer environments. Thus, an understand- ing and assessment of the variations that drive the need for flexibility are prerequi- sites to designing flexibility. Moreover, we need to establish clear connections be- tween these stimuli for flexibility and the design of business process flexibility. This, in turn, requires a crisper definition and classification of both the stimuli as well as the flexibility options. BPMDS'06 143 References Ashby, W. R. (1958). Requisite variety and its implications for the control of complex systems. In George J. Klir (1991), Facets of systems science. Bider, I. ‘Masking flexibility behind rigidity: Note on how much flexibility people are willing to cope with”, Proceedings of CAiSE05 Workshops – J Castro and E. Teniente (Eds.). Gil Regev, Pnina Soffer, Rainer Schmidt, “Taxonomy of Flexibility in Business Processes”, CFP, BPMDS 2006, CAiSE 2006. Hofstede, G. Cultural dimensions in management and planning, Asia Pacific Journal of Man- agement, Springer Netherlands , Vol. 1, No. 2 , January 1984 , p. 81 - 99 Regev, G., Wegmann, A.: A Regulation-Based View on Business Process and Supporting System Flexibility, Proceedings of the CAiSE’05 Workshop, p. 91-98. Simon, Herbert A. ‘The Sciences of the Artificial’, 3e, Cambridge, Mass., MIT Press, 1996. Volberda, H. W. Building the flexible firm: how to remain competitive. Oxford University Press. 1998 Type of Stimulus Description Number of paths for Response responsibility Level of flexibility 144 process fulfillment resolution Type A: Constant There are no variations in Only one fixed process Process actors are respon- No resolution required the stimulus to the proc- path. sible for performing fixed because of the assump- ess. No contingency pre-defined tasks. No refer- tion of no variation in planning is done. A fixed ence to the process man- stimulus. response is defined. ager is needed because the response is pre-defined and Note: As quoted from fixed. Bider (2005, p.7) above, such situations are rela- tively rare and often exist due to inadequate and inaccurate analysis. Type B: Uncertain A finite set of crisply pre- Multiple paths (all the Process actors perform the Resolution completely but crisply prede- identified and defined possible paths are enumer- tasks. They are provided within the process level fined contingencies, each asso- ated at the process design with the crisp, predefined (The process has built- ciated with a certain stage). The pre-defined set of contingencies that in mechanisms to iden- probability of occurrence. process paths (cases) are they can clearly identify, tify the variation and This can be viewed as a mutually exclusive and and select their associated choose appropriate distribution of contingen- collectively exhaustive. No responses. No reference to course of actions) cies and an associated new paths can be added. Process manger is needed. distribution of responses. Table 1: Taxonomy of Stimulus to Business Process Flexibility (continued on next page) Business Process Modeling, Development, and Support Type C: Ambiguous There are ambiguities in Once the ambiguity in the Process manager is respon- The resolution is above identifying the stimulus. stimulus has been resolved, sible for interpreting and the level of the process The variations in the classifying the stimulus, and happens at the BPMDS'06 the choice between the stimulus form a finite set existing paths can be made and identifying the associ- process manager level. of fuzzy stimuli. using the now unambigu- ated response. Decision This is because the ously identified stimulus. making is centralized at the variation is ambiguous level of Process Manager. and process actors can not clearly identify the options. Therefore, they need to refer to a higher authority, the process manager who interprets the contingencies and determines the path of action. Type D: Surprise The contingency has not Completely new response The reaction and decision The resolution happens been envisaged at all at paths can be added some- making lie in the hands of wherever there is either the time of defining the times involving new set of actors on the ground those an actor or a manager process. process actors and re- are in a position to observe available and capable of sources. the situation and make a making sense of the timely and informed stimulus and choosing a choice. Thus decision path of action. Leader- making may often be de- ship emerges. centralized to the scene of action. Table 1: Taxonomy of Stimulus to Business Process Flexibility (continued from previous page) 145 146 Type of BPF Response Response responsibility Stimulus Type A: Irrespective of the situation, evacuate all people in the region threatened by the hurri- Relief management personnel Constant cane Type B: Pre-specified response according to the classification of hurricane categories into five Relief management personnel are provided with Crisply categories: the categories and responses, and are expected to predefined (http://www.ohsep.louisiana.gov/hurricanerelated/HURRICANECATEGORIES.htm). perform based on this set. categories of hurricanes (Level 1 to 5) Type C: When Katrina hit New Orleans, the possible effects of the hurricane on the levees United Sates government did not interpret the Ambiguous (dams) were not fully understood by the authority. That is, the assessment of the stimulus properly leading to the failure of appro- interpretation stimulus was ambiguous. Consequently the hurricane was treated as a Type B stimu- priate response measures1. It is also to be noted of a stimu- lus and the corresponding response measures only for Level 4 hurricane were put in that when process manager fails to be sensitive, lus. place. However the breach of levees, which was not well understood, caused major the process actors may lower down the Type C long term flooding related problems not associated with normal hurricanes. stimulus to Type B or even to Type A and take actions accordingly. Type D: When 2004 Tsunami hit Asia in 2004, no early warning systems were in place nor Even process managers do not know how to react Surprise were the disaster relief measures and plans world-wide. The Tsunami, its occurrence, as it is a surprise. This is a situation where process its magnitude, and its possible effects were, at that time, much beyond the experience actors assume autonomy and come up with their and imagination of most of the disaster relief agencies. Thus the Tsunami and its decisions, innovative or otherwise. In the case of effects were truly a surprise to most relief agencies and governments. the 2004 Tsunami, in the early days none of the disaster relief agencies could understand its mag- nitude and respond. Most responses were local, organized by local governments and local people to support local devastation. Even in the case of organized response, such as the Indian Navy’s response in helping Sri Lanka, it was due to the local initiatives improvised by local Naval com- manders and district officials empowered to act on their own initiative by the government. Table 2. Taxonomy of stimulus and responses in the case of a hurricane (Note 1 above : http://www.washingtonpost.com/wp-dyn/content/article/2006/03/02/AR2006030201210.html) Business Process Modeling, Development, and Support BPF Stimulus Response Response responsibility Type A: Constant Selling process of a computer for cash/credit card in a Sales person at the retail store or fixed computer retail store BPMDS'06 sales procedure Type B: Crisply Customized order on Dell’s web site with a variety of Dell’s value chain personnel defined sales options in configuration, and payment and delivery options for accept- modes ing and fulfilling sales orders at Dell Type C: Ambigu- Order for Notebook computers for mobile sales force of The Notebooks specifications are not clear; system func- ous a company. The order, in its initial form is somewhat tional and compatibility requirements are not clear; the abstract and fuzzy and therefore the routine order entry process actors cannot fulfill the process; decision making and fulfillment process at Dell can not cope with it. Thus will be pushed up to Process manager who will work to Dell may escalate the order to a higher level where clarify the requirements for the Notebooks. business relationship managers may clarify the Order with the customer and generate unambiguous specifica- tions. Once the ambiguity is resolved, the now unambi- guous order can be processed through Dell’s regular order fulfillment process. Type D: Surprise Tender for computational and storage power require- It is not clear what kinds of computers are required itself. ments by NSF to create an eScience grid. In this case the Process actors and managers as well are in limbo in order is much beyond the experience and imagination of meeting such an order. The responsibility of making most people in Dell’s order entry process. In this case sense out of this surprise order now rests on those groups Dell’s R&D staff may work together with the Dell Sales that are empowered to deal with this opportunity. If Dell staff and customers to develop computing grid architec- does not have this level of empowerment, it may lose a tures and the requirements for distributed computing valuable opportunity of building a very lucrative new nodes. line of business. Table 3. Taxonomy of stimulus and responses in the case of order fulfillment process of an order for a computer 147 BPF Stimulus Flexibility in Business Process Instance Flexibility in Business Process Type 148 Type A: Constant No No Type B: Uncertain but crisply predefined Yes No Type C: Ambiguous Yes No Type D: Surprise Yes Yes Table 4. Mapping BPF Stimulus to the abstraction level of the process change BPF Stimulus Changes in func- Changes in opera- Changes in behav- Changes in informa- Changes in organiza- tional perspective tional perspective ioral perspective tional perspective tional perspective Type A: Constant No No No No No Type B: Uncertain but No No No No No crisply predefined Type C: Ambiguous No No No No No Type D: Surprise Yes Yes Yes Yes Yes Table 5. Mapping BPF Stimulus to the subjects of the process change BPF Stimulus Incremental Revolution- Temporary Permanent Immediate Deferred Adhoc Planned ary Type A: Constant No No No No No No No No Type B: Uncertain No No No No No No No Yes but crisply prede- fined Type C: Ambigu- No No No No No No No Yes ous Type D: Surprise Yes Yes Yes Yes Yes Yes Yes Yes Table 6. Mapping BPF Stimulus to the properties of the process change Business Process Modeling, Development, and Support