Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

Choosing Approach to Business Process Modeling - Practical Perspective
Ilia Bider Want to know more about business processes? Visit http://processplatsen.ibissoft.se/en/node/29 Research Report, IbisSoft (www.ibissoft.se), 2002, Revision 2003, 2007 Abstract: One of the essential parts of a business process modeling project is choosing an approach to modeling and/or modeling notation/tool. The selection of a “right for the task” approach can substantially increase chances for success. To ensure the “right” choice, the following three sets of factors should be considered: (a) properties of modeling objects, i.e. business processes, (b) characteristics of the modeling environment, (c) intended use of the model. The paper is devoted to the analysis of these factors. It presents a simplified classification of the approaches to business process modeling. It lists the most essential properties of various business processes, it classifies modeling environments, and it discusses some practical tasks where the business process model can be used. Based on the analysis, practical recommendations on what approach to choose are given. Keywords: business process, modeling tool, modeling notation, tools analysis

Foreword
Business process description is a map that helps us to navigate through our business activities. In particular, it helps us to understand: • • • • where we are right now, where we need to go to, where we have come from, and how we have got to where we are.

Using a map for navigation is quite normal in many activities, e.g., it is a must when we need to move something or be moved ourselves from one place to another. We have different maps for navigating in the physical space, marine maps, road maps, hiking maps, etc. The choice of a map depends on what we want to move, where and by what means. If we travel by car we need a road map, if we travel on foot in a mountain area, we need a hiking map. What is more, we may need several different types of maps, in case of A simple road map will emergency. For example, a simplified road not help if you make a wrong turn map that shows how to get from one point to another will not help if we make a wrong turn somewhere on the way. We will need a detailed road map to get back to our initial course.

1

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

Even a detailed roadmap will not help if our car breaks down on a lonely road in a mountain area far from any human dwellings in a stormy weather. A hiking map can help us to find the shortest route to safety in this case.

You may need a hiking map if your car breaks down on a lonely road in the mountains on a stormy day

The most commonly used type of business process maps is a workflow map. The workflow shows in which orders activities (tasks) should be completed in order to reach a goal of the given business process. A workflow map is similar to a road map, more exactly, a simple road map. If you can follow it in the exact manner, you will reach the goal. However, if you need to make a turn because the road is temporally blocked, it might be difficult to get back. A typical project in the area of Business Process Management (BPM) starts with describing business processes that exist in a given company or organization, so-called as-is processes. It is very important to choose a right approach, i.e. right kind of maps, for creating these descriptions. For example, it doses not make much sense to create a road map in the area where no roads exist (just small paths here and there). And it won’t be enough just to draw a road map if you want to be able to find your way through even if you have been “blown off the road”.

1 Introduction
While the ideas of business process orientation become popular, more and more companies and organizations face the task of choosing an approach to identifying and modeling their business processes. In practice, this task can be formulated directly, or indirectly, e.g.: • • • We need to choose a method for business process mapping and analysis We need to choose a consulting company that will analyze and describe our processes We need to choose a notation/tool for drawing maps of our processes

The choice is not easy to make, especially for organizations without previous experience in the field of business process modeling. Independently of how the question is formulated, one will meet a number of vendors, e.g. consulting companies, or tools vendors, each of which will claim that they are the best ones. Quite often, a vendor presentation will be illustrated with a process notation/diagrammatic tool, and for a novice it will be difficult to understand the difference between this tool and the previous one. The material presented in this paper is written with the aim to give some orientation on how to choose an appropriate method/tool for business process modeling. The paper is written in a prescriptive manner having practitioners in mind. The number of references was intentionally kept to the minimum to make the paper easier to read for the intended audience. Despite the practical orientation of the paper, some parts of it might be also of interest for the researchers. The paper is based on the analysis of literature and on our own experience in the field of business process identification and modeling. Our own experience lies in the field of administrative processes, such as bureaucratic decision-making, lobbying (influence decision

2

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

of others), processing customer feedback, inquiries, funeral arrangements, etc. (for examples, see (Andersson et al., 2002)). This kind of processes has not received much attention in the literature, where the standard examples concern production, sales, insurance claims etc. The main characteristic feature of the administrative processes is their relatively loosely structure as far as the exact order of activities is concerned. Experience in modeling such processes complemented by literature on modeling more structured processes gave us a relatively broad basis for the work presented in this paper. The recommendations we are giving were worked out based on the following principles: 1. There is no universal method of business process modeling suitable for all possible projects in this field. 2. There are far too many approaches and tools to consider all of them one by one to see which one suits best the needs of a particular project. Some classification of methods and tools is needed so that first a particular class can be chosen, and after that a method/tool that belong to the class. 3. To be able to match the needs of a modeling project against methods/tools we need to identify characteristic features of a particular project. We believe that analysis of modeling projects can be done in three “dimensions”: • • • Properties of business processes to be modeled Characteristics of the modeling environment Intended use of the model

The paper is written according to the following pan. In Section 2, we introduce the general notions normally used when discussing business processes. In Section 3, we introduce a simplified classification of the approaches to business process modeling. In this classification, we have chosen to stress one particular aspect that we consider to be the most important for our practical task. This is the way of how the dynamics of the business process is represented. The classification is our own invention; it was worked out after a try to find an appropriate for our task classification in the literature. In Sections 4, we discuss the business process properties that are important to consider when choosing an approach to business process modeling. The properties on the list are more or less obvious for specialists in business process modeling. However, the list itself is our own invention; again, we could not find any ready maid list in the literature. We attribute the absence of such lists and classifications of approaches due to that not enough attention is being paid to the practical perspective of choosing modeling techniques/tools. In Section 5, we consider the properties of environment in which the modeling work is being done. In section 6, we consider some practical tasks for which a business process model could be used. While discussing properties of business processes, modeling environments, and project tasks, we refer to the classification of approaches from Section 3, and give recommendations of what approaches suit best specific properties, or tasks. In Section 7 we give some general recommendations based on combination of factors described in sections 4-6. Finally, Section 8 presents concluding remark to summarize the material.

3

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

2 Business Process Modeling - Main notions
We follow the most general definition of business processes, see, for example, (Hammer&Champy, 1994, Kueng&Kawalek, 1997), that defines a business process as a set of partially ordered activities aimed at reaching a well-defined goal. Some examples of goals are as follows: • • • Reaching an agreement in business negotiations. Discharging a patient from the hospital in a (relatively) healthy state. Closing a sale.

This definition can be applied to main industrial processes that produce some “value” to the customers, as well as to support processes. Support processes are the processes that ensure that the main processes have enough resources to work problem free, e.g., hiring and firing personnel. When discussing business processes, it is important to differentiate the process type from the process instance. The notion of process type is used to talk about the process in general, like: • • • Sales process (in general), Processing insurance claims Decision-making

The notion of process instance is used to pinpoint a particular process, like: • • • Processing a sales lead that concern a particular customer. Processing insurance claim #1345678. Passing an elderly care plan for 2002.

Two types of goals can be differentiated when discussing business processes: strategic and operational goals. Strategic goals, like customer satisfaction, growth, profit, etc. are associated with the process type. They explain why the process exists/should exist in the organization, and why it should be driven in a certain way. Analysis of the strategic goals results in the rules/procedures that dictate how the instances of the process should be run. All such rules for a given process type constitute a process definition. Operational goals concern process instances, and they show when a process instance can be considered as finished. Examples of operational goals that correspond to the process types above are as follows: • • Understand the customer’s needs and make an offer (sales process). Insure that all basic documents that concern a particular insurance claim are collected and money are paid (processing insurance claims).

4

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

•

Pass a decision on an elderly care plan based on the needs, available resources, and current legislation (decision-making)

Each process engages a number of participants, which can be roughly classified into artifacts, human beings (people) and organizations. The notion of artifact is used to represent any physical or abstract object like document, product, computer program, etc. The notion of human being represents a person participating in the process. Very often, human beings participate in a business process not on their own, but on behalf of some company, political party, department, team, etc. Any of these unions can be represented by the concept of organization. In relation to a particular process, the participants can be roughly divided into two categories: passive participants, and active participants. Passive participants are the participants that are subjected to transformation (or change) during the execution of activities, for example, a document being written, a car being assembled, a patient being treated in the hospital, an organization being reorganized. Active participants, or agents, are the participants that perform actions aimed at changing passive participants. The active participants can be considered on the level of individual people participating in the activity, or on the level of organizations that they represent. Artifacts can also play the role of active participants, e.g., industrial equipment, robots, computers, etc. Both human and nonhuman active participants are often called resources, as they should be distributed among various activities and process instances.

3 Classification of approaches
We consider that the most essential feature that differentiates various approaches to process modeling from each other is the way of presenting the development of a process instance in time, i.e. business process dynamics. There are many different approaches to representing process dynamics. However, in a simplified manner, we can classified all approaches into 4 categories according to the main view they take over the business process dynamics: 1. Input/output flow. The focus is on passive participants that are being consumed, produced, or changed by the activities. This flow can be represented as a diagram (graph), where activities serve as nodes. The arrows connect the activities in accordance to results of one activity are being used in one or another way by the next activity. Such a diagram does not reflect the order of activities directly, it reflects the causal order, i.e. the results of one activity are used by another activity. The causality establishes a partial order between activities indirectly, i.e. the results should be produced before they could be used. The most common approach to represent this kind of flow is IDEF0 (FIPS, 1993). 2. Workflow. The focus is on the order of activities in time. This flow can be represented as a diagram (graph) where arrows represent activities. Nodes show the results of one or more activities that end in a particular node. Typical notations for representing this kind of flow are IDEF3 process flow diagrams (Mayer et al., 1995), Activity Diagrams of UML (Eriksson & Penker, 2000), and Petri Nets (Aalst, 1999, Deiters&Gruhn, 1998). The Petri nets approach tries to combine the workflow with input-output flow, though the workflow is still a dominating view.

5

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

3. Agent-related view. The focus is on the order in which agents get and perform their part of work. The typical notation to represent this kind of flow is Role-Activity Diagrams –RAD (Ould, 1995), and collaboration diagrams of UML (Rumbaugh et al., 1999). 4. State flow. Each activity produces changes in the part of the real world that embraces the given process instance. Some changes may concern the state of passive participants, e.g., their form, shape, or physical location. Other changes may concern the state of active participants, e.g. the state of the mind of a human agent trying to find a solution for a complex problem. The focus of the state flow view is on changes produced in the part of the world that embraces the given process instance. When the state flow is used as a complementary view, as in IDEF3 (Mayer et al., 1995), the flow is described in form of state-transitions diagrams. However, the state-transition diagrams exploit the state flow view only partially. For details of a full exploitation of the state flow view see our papers (Khomyakov & Bider, 2000, Andersson et al., 2002).

4 Properties of business processes
4.1 Degree of physicalness and mobility of passive participants In order to choose the right focus on the process dynamics, it is important to consider what kind of passive participants the process have. The passive participants can belong to one of the following two categories: • • Physical – parts of the car, a patient in the hospital, etc. Virtual – a decision being made, a company being reorganized (juridical, but not physical person), etc. Normally, a virtual object has some kind of physical representation. A decision being made is fixed in some document, first a proposal, then a law, regulation, order, etc. A company is represented by a number of documents that fixes its business, structure, etc. It may also have some physical office.

The degree of physicalness/virtualness determines the mobility of the passive participants. Heavy physical participants are not very mobile and need some efforts to be moved from one place to another. A virtual objects that are represented as documents are highly mobile, and with the current information technology they may be moved without any efforts. If a process deals with immobile physical objects that should be passed around between different activities, then the input/output flow may be of great value as it can pinpoint all the logistical problems of the process. If the process deals mostly with the virtual objects, current technology may ensure that as soon as the object has been produced/changed it can be seen and used by whoever needs it. In this case, the input/output flow is of less interest. Workflow or state flow can be preferred. 4.2 Level of specialization and degree of mobility of active participants

Active participants are people and equipment that are required for completing activities. They can be classified according to two dimensions: level of specialization, and degree of mobility. As far as specialization is concerned, the level can be from a totally specialized agent to a totally universal agent. Totally specialized agent can be used only in one activity, e.g., a

6

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

person who was trained to do only one thing, or some specialized equipment. Totally universal agent can be used in any activity. A typical example of a universal human agent is an owner of a one-man company. A computer represents a universal agent of non-human kind. If a process in question has a lot of highly specialized agents, than the agent-related workflow, which shows the flow of activities through the agents, might be of interest. It may help in optimizing the usage of specialized agents. If most of the agents are universal, then the normal workflow might be better suited to describe the process. The degree of mobility describes how easy, far and fast the agents can travel. Here, we can have totally immobile agents, like heavy equipment, and totally mobile agents like software that can be executed on site. The mobility/immobility factor of agents should be compared with mobility/immobility factor of passive participants. For example, if all passive participants are mobile, than the mobility of the agents is not important. Consider another example where some agents are highly specialized and immobile, and passive participant that the agents consume, produce, or change are physical but relatively mobile. Than both agentrelated workflow-view and input/output view are of interest when analyzing such a process. 4.3 Degree of precision of operational goals

The main parameter to classify the operational goals is the level of precision. The operational goal may be very precise, like manufacture a new car of make Volvo V-70 with such and such equipment, or less precise, like accept a plan for elderly care for year 2002. Less precise goals are specified in a functional manner. Examples: • Accept a plan for elderly care for year 2002 with a total budget of 1 000 000 euro, and main directions as described in law no 789 passed by the parliament on 5 January 2002. Create a software system that supports the decision-making process in the municipality of NN. The maximum budget is 100 000 euro, the deadline is 31 December 2002.

•

The functional specification does not precisely define the result that the process is supposed to produce. It only states constraints that should be observed when delivering the result. Even when an operational goal is defined functionally, there often exists a projected specification of what the result of the process should look like. This may take a form of proposals for the decision, or system specifications. The projected result may change in time, and sometimes the result may differ very much from the first projection. The degree of precision for functionally specified operational goals points to how much and how often the end-result can deviate from the initial projection. When describing processes with functionally specified goals, a special consideration should be given to definition of operational goals in form of constraints. Very few methods of process representation give a clue of how to do it in a structural way. The state-oriented presents a possibility for defining operational goals in form of constraints on the final states. The degree of precision of operational goals has correlation with the nature of activities, and process flow, see sections 4.5, and 4.6. The more precise is the operational goal, the more exact the activities of reaching it could be defined. The same is true for the process flow.

7

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

4.4

Autonomy and characteristics of the process’s environment

Each process interacts with its environment that is beyond the total control from the process. If the level of interaction is low, we speak of highly autonomous internal processes, for example, training personnel, pure manufacturing, etc. The flow of activities in this kind of processes normally follows the internal logic of the process, and it does not depend much on external events. The workflow approach to the description of the process dynamics will suit this kind of processes very well. Processes that include external actors, like customers, supplies, etc., have less degree of autonomy. The order of activities for these processes depends not only on the internal logic of the process but also on the external, not always predictable events. For non-autonomous processes, it is important to understand if the environment in which they operate has a friendly collaborative nature, or a less friendly competitive nature. In the collaborative environment, it is normal that external actors do their part of job as expected. For example, if during the purchasing process the vendor is asked to send a product description, we expect that he/she would do it with pleasure. A maximum disaster that can happen, he/she forgets, and will need a reminder. A process that operates in a collaborative environment can behave like an autonomous process, i.e., the order of activities performed follows the internal logic of the process. Typical examples of processes that operate in a competitive environment are sales in the presence of competitors, lobbying, negotiations, etc. The activities to be completed in this kind of processes may, at large extent, depend on how the environment is being changed by the actors whose actions are outside the control of the process. The processes of this type are sometimes called event-driven. The workflow view is not very helpful in this case. A state flow approach suits better the task of modeling the event-driven business processes. 4.5 Nature of activities

Some activities may be described in the exact manner, i.e. as an order of simple operations. For example, activity attach a wheel to the car being assembled can be presented in simple operations, like screw a nut. Most of the manufacturing activities are of this kind. Other activities may be described only from the perspective of what results they should produce. For example, a description of activity review a document can state that the result should be in form of comments, but it is impossible to dictate exactly how and on what basis the comments should be produced. Many of intellectual activities have non-exact nature. Activities that can be described in the exact manner have an advantage that the time and other resources consumed by an activity can be easily established. These parameters belong to the activity description. For activities that cannot be defined in the exact manner, such parameters may only be estimated on the case-to-case basis. The estimation belongs not to the activity definition, but to the process instance for which the estimation is being made. For processes with exactly defined activities, it is possible to make simulations of the type “what happens if we cut the time consumed by a particular activity by 30%”. For this kind of simulations, the workflow view on the process dynamics may be very useful.

8

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

For processes with many non-exactly defined activities, this kind of simulation is practically impossible. Thus, the advantages of time and resource related simulations are not of much importance for this kind of processes. 4.6 Orderliness of process flow

When choosing an appropriate view on the process dynamics, it is important to understand if the activities in the process flow follow each other in some exact predefined order, or only partial order can be established. The degree of orderliness correlates very much with other factors described in the previous sections, such as the precision of operational goals, degree of autonomy, friendliness of environment, nature of activities, etc. For example, a highly autonomous process with a precise operational goal and exactly defined activities will have a high degree of orderliness. Such kind of processes can be properly represented by workflow diagrams. Suppose that in another example we have a nonautonomous process (like “sales”) operating in a competitive environment with a functionally defined goal (like “sell something to X”) and with non-exactly defined activities (like “analyze customer needs”). The degree of orderliness for such a process will be quite low, and it would be very difficult to present its dynamics with workflow diagrams. A state flow approach is more suitable for modeling such kind of processes.

5 Properties of the modeling environment
5.1 Level of process maturity in the organization The level of process maturity (McCormack&Johnson, 2001) characterizes the amount of knowledge an organization have about its own business processes. The following questions can help to determine the level of maturity: • • • Are the processes identified? Have strategic and tactical goals been established for each process? Are personnel aware of in which processes they participate?

If the organization has a high level of process maturity, the process modeling can be done on the process-by-process basis. For each process, a group of experts who participate in the process can be assigned to investigate the details of workflow, state flow, etc. If the level of process maturity is low, i.e. processes have not been identified yet, the first job is to find them in a functionally structured organization. One way to do this job might be by going through the organization on the department-by-department basis (and may be even on person-by-person basis). In this case, an input/output approach can be quite useful: • First, identify what activities are performed in a particular department, wherefrom the input objects come, and where to the results are delivered. Sew together activities through their input/outputs. Select processes from the resulting cobweb.

• •

9

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

For organizations that strictly define responsibilities for each position, the agent-related view may suit the task of identifying business processes. The identification process may start from listing activities for each position/role. Then points of cooperation/communication can be established, and one or several processes can be identified from the resulting net. 5.2 Professional background of human participants

There are two ways to ensure that a process model corresponds to what is going on in the real world. One is to observe the part of the world related to the process in question in real-time. The other one is to discuss the process with the people engaged in it, read operational manuals, etc. The first method is quite expensive (in terms of time), and it is possible to use it only with the processes that produce physical results (e.g., manufacturing). For most of the processes that include intellectual tasks, like design, decision-making, etc., only the second method can be applied. When the second method is applied, only the people engaged in the process can give a confirmation that a process model corresponds to what happens in reality. Therefore, the process description should be understood by the majority of people who are engaged in the process. Confirmation from the management only is not enough, as the management may not know all details of the process. As far as operational manuals are concerned, they may be out of date, and thus they cannot be considered as a reliable source of confirmation. The way of presenting a process should be chosen in accordance to what kind of people are engaged in the process, their background and current assignments. If the process team consists mainly of the people with technical background, e.g., engineers, system developers, etc., it is possible to use highly formalized notations, complicated diagrams, etc. These kind of people use formal definitions in their normal everyday work; thus, for them, there won’t be any problems to understand a formal description of business processes and find out what is incorrect. If on the other hand, the people engaged in the process in question include specialists of nontechnical professions, like office workers, doctors, nurses, lawyers, etc., the use of formal notations should be limited. Simple diagrams will help to understand the matter, but complicated many-pages diagrams are not suitable for this kind of professionals. They won’t be able to detect errors. The input/output flow, workflow, and agent related view, all use diagrammatic notation for presenting the model. To the best of our knowledge, there are no non-diagrammatic approaches related to these views. When working with non-technicians on modeling a complex business process, the diagrammatic presentation can create additional hinder in communication between business analysts and experts in the business domain. When using the state-oriented approach, the focus of discussions is placed on the state structure. The state structure can be expressed not only as a formal structure, but also as a two-dimensional picture (see slides). As far as our own practice is concerned, the state pictures are quite understandable for not-technical professionals. If a diagrammatic presentation may create an obstacle in communication with non-technicians, choosing the state flow view may help in eliminating this obstacle.

10

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

6 Intended use of model
Below, we present a list of usual objectives (the list is not full): 1. To increase the level of process maturity, for example, to make the staff goal and processconscious, to improve cooperation between colleagues, to educate new employers, etc. 2. Create a basis for process analysis and reengineering. 3. Create a basis for building computer support systems. Each of these tasks is considered in more details in the subsections below. 6.1 Increasing process maturity

If increasing the process maturity is on the list of objectives, then we need to choose modeling methods that could help in communicating the process knowledge to all participants of the process. Here, it is particularly important to consider the background of the participants: technical/non-technical, and choose less formal methods for non-technicians. 6.2 Analysis and reengineering

If analysis and reengineering is on the list of objectives, then first, we need to understand what kind of analysis should/could be completed for a given process. Two types of analysis can be applied to a business process: • • quantitative, or performance analysis, qualitative, or structural analysis.

The quantitative analysis means evaluation of the process based on numerical values of important parameters, like rate of success, calendar time required for reaching the goal, costs in time and money, number of activities performed, customer satisfaction, etc. A typical example of this kind of analysis is ABC (Activity-Based Costing). The quantitative analysis requires statistically reliable information on the process activities. Often, this information exists only for the processes with exactly defined activities. For such activities it is possible to establish how much time, material, manpower, etc. is needed for their execution. Based on this information, it is possible to calculate the costs of the process instant, or the needs for some specialized agents, human or not human. For the first task, a workflow view on the process may be useful. For the second task, an agent-related view may be of great use. For the processes that have a great deal of non-exactly defined activities, it is difficult to make the quantitative analysis based only on the process model. The model itself won’t provide the statistically reliable information, see deliberation on the topic in section 4.7. This kind of information is difficult to obtain without first introducing some kind of computer support for identified processes. Qualitative or structural analysis means evaluation of the process based on matching the activities included in it against the goal of the process, i.e. whether they contribute to the goal and in what way. The qualitative analysis can be performed based on a model of the business
11

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

process. This type of analysis requires detailed representation of the process goal. For relatively complicated goals, the state flow view on the process dynamics may be the only option. Process reengineering means suggesting a better way of handling the processes, for example, streamlining the process by eliminating activities that do not contribute to the goal. Results from both quantitative, and qualitative analysis can be used for reengineering. The results from the qualitative analysis can be used to detect the activities that do not lead to the goal (do not add value in other terminologies). Such activities can be eliminated. Another example is rearranging the order of activities execution in such a way that the activities directed at independent sub-goals are executed in parallel. This type of reengineering can be done based on the workflow view for the processes with high degree of orderliness, or based on the state flow view for the processes with low degree of orderliness (see section 4.8). 6.3 Building computer support

If building computer support is on the list of objectives, the following should be understood: 1. If a new system is to be created, or the existing systems are to be integrated? 2. If the system will support only execution of activities, or it will help in running the process. The latter includes: help in keeping track of what has been done, planning new activities, reminding what has to be done, etc. 3. If a new system will impose a strict order in activities execution, division of responsibilities, etc., or it will allow to choose the course of action dependent on how the process is developing in time. If an integration project is in view, then the input/output flow may help to understand how to connect various systems used in the organization. If the system should impose strict rules, the workflow view, or even agent-related view could be very helpful in building such a system. If the system should allow a high-level degree of flexibility, then the state flow approach can be the most appropriate. The result of deliberation above is summarized in the table 1.

System mission
Integrate existing systems Facilitate coordination / communication Introduce strict order in production-like processes Navigate each process to its goal

Process view
Input/output flow Agent-related view Workflow State flow

Table 1. How to choose a view on process dynamics.

12

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

7 What approach to choose?
Based on the discussions in the previous sections, we can conclude that there is no universal approach that would be equally suitable for all types of business processes, all types of objectives, and all levels of process maturity. An organization might need to choose several different methods to apply at different stages of the process modeling work, and for different objectives. As we have seen in the previous sections, many factors should be taken into consideration when choosing suitable methods. Summarizing the discussion, we can give some general recommendations of what methods to choose. • If an organization is functionally structured and processes are not identified, it is suitable to use input/output view (for example, IDEF0), or agent-related view (for example, RAD). Input/output view suit mostly organizations that have formal ways of internal communications via some objects, like documents, files, etc. Then the processes can be discovered by following the movement of these objects inside the organization. Agent-related view suit mostly organizations that strictly define responsibilities for each position. The communication channels may be informal, like phone calls, informal meetings, etc. Then the identification process may start from listing activities for each role. • When the processes are identified the workflow view, or state-oriented view, or both should be applied, as they are better suited for expressing details of each process. Workflow can be used only if there is some normal order in which activities are completed one after another. If this order is difficult to establish, the state-oriented view should be used. In which way the end-result should be documented, depends on the tasks in which this result will be used, e.g., analysis and reengineering, building computer support, etc. Several views may be needed, each one for its own use. • There is no need to work sequentially, i.e. first get a full input/output view, then identify the processes, than describe each process. As soon as (after initial analysis) some process has been suspected, a different method can be applied to map this process. The work with input/output view can continue to identify other processes. We just span a new processmapping project, and continue with identification. The same is true when modeling a particular process. Suppose, for example, we want to represent results in a state-oriented way, but it is easier to start with workflow diagramming. We do not need to completely finish the workflow description before going over to the state-oriented description. As soon as we have enough information to make a sketch of the process state structure, we can continue processes mapping using the stateoriented approach. Our recommendations are summarized in Table 1 below.

13

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

Table 1. Summary of methods Input/output flow Focus on passive participants that are being consumed, produced, or changed by the activities. Important when there is a need to ensure that each passive participant has
Blueprint Seat Legs Back

Agent-related flow Focus on agent cooperation, i.e. order in which active participants get and perform their part of work. Important when there is a need to ensure each active participant doing his part of the job. How he does it is of lesser importance.

Assembler

Chair

Paint
Paint

Painted Chair

Tools Cabinet-maker

Paintbrush Painter

undergone a specified number of operations in a certain order. Who does the operations has less importance. Process description according to this view represents a road map for “transporting” passive participants. Suitable for processes that deal with physical objects. Workflow Focus on order of activities. Important when there is a need to ensure that all activities are completed in the right order. Who does the operations and what passive participants are changed during them has less importance.
Receive payment

Process description according to this view represents a road along which the process pass through active participants. Suitable for processes with specialized agents, or with strict distribution of responsibilities, e.g. decision legalization. State Flow Focus on position reached in relation to the goal after execution of activities. Which activities are executed, and who executes them has less importance. Process description according to this view is more like a hiking map that represents terrain and some paths across it. Suitable for looselystructured administrative processes, the ones which do not have strict order of activities or distribution of responsibilities and which consume and produce information rather than physical objects. Also suitable for handling deviations from one of the three others road maps.

Check payment

[Not OK] [OK]

Contact customer

Ship goods

Inform customer

Process description according to this view represents a road map of activities. Suitable for processes with predefined order of activities (operations).

14

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

8 Concluding Remarks
In the previous sections, we approach/technique/tool based on: demonstrated a way of choosing modeling

1. Classification of modeling approaches/techniques 2. Analysis of properties of modeling objects (business processes in this particular case), modeling environment, and the intended use of the model We do not insist that our classification of approaches presented in section 3 is the only one, or it is the best one; we just found it useful for our practical task. The same statement concerns the list of business process properties, characteristics of modeling environment, and possible tasks for which a business process model could be used. The lists are not full and they should be complemented when new properties or tasks are discovered. The material of this paper has been used in several tutorials for researchers. It was also presented in printed and/or oral form to practitioners in the field, all of whom considered the material consistent with the common sense and their own experience. One particular group remarked that the material both “made the subject more complex, and more clear”. Under “more complex”, they meant that there was a need to consider much more details than they anticipated, for example, the task for which a model was being built. Under “more clear”, they meant that the material structured the reality in a way that shows how to complete their task. The ideas presented in the paper are also used in our own modeling practice, though not in every detail. Our main method of modeling is the state-oriented one, thus the final model is expressed and documented in the terms of the state-flow model. However, on initial stages of analysis, when the essence of the processes that exist in a particular organization have not been discovered yet, we use other methods, e.g., simplified workflow-diagrams. The recommendations included in this paper are not presented in a formal manner. Actually, the paper does not give ready-made answers on what methods to use in such-and-such situations. It gives only some directions on how to deliberate when considering modeling approaches/techniques. For the moment, we do not have any theory that can prove that our ideas are the right ones, and we do not know if such theory can be built. The only basis for our suggestions is common sense, and own experience complemented by analysis of the literature. However, the practitioners do need a methodology that can help to choose an appropriate modeling approach/technique/tool, and they need it now. We believe that our work can serve this aim until a more theoretically based methodology is worked out. We also hope that this paper will stimulate researchers to pay more attention to the practitioners needs. The latter may result in appearing a more theoretically based methodology for choosing among numerous modeling approaches.

9 Acknowledgements
Many thanks to Paul Johannesson and Gil Regev whose comments helped to improve the text.

15

Published in Inconcept issue 34, January 2005 http://www.inconcept.com/JCM/january2005/index.html

10 References
(Aalst, 1999): Aalst, W.M.P. van der. How to Handle Dynamic Change and Capture Management Information? An Approach Based on Generic Workflow Models. http://wwwis.win.tue.nl/~wsinwa/genwf.ps, 1999. (Andersson et al, 2002): Andersson, T., Andersson-Ceder, A., and Bider, I. State Flow as a Way of Analyzing Business Processes – Case Studies. Logistics Information Management, Vol.15 (1), pp. 34-45, 2002. (Deiters&Gruhn, 1998): Deiters W. and Gruhn V. Process Management in Practice. Applying the FUNSOFT Net Approach to Large-Scale Processes. Automated Software Engineering, 5(1), pp. 7-25, 1998 (Eriksson & M.Penker, 2000): Eriksson, H.E., and M.Penker, M. Business Modeling with UML, Business process at work, John Wiley&Sons, 2000. (FIPS, 1993): Standard for Integration Definition for Function Modeling (IDEF0), National Institute of Standards and Technology (NIST), FIPS publication, 183, December 1993. (Hammer&Champy, 1994): Hammer, M., and Champy, J. Reengineering the Corporation – A Manifesto for Business Revolution, Nicholas Brealey Publishing, London, 1994. (Khomyakov&Bider, 2000): Khomyakov M., and Bider, I. Achieving Workflow Flexibility through Taming the Chaos. OOIS 2000 - 6th international conference on object oriented information systems, pp.85-92, Springer, 2000. (Kueng&Kawalek, 1997): Kueng, P., and Kawalek, P. (1997), Goal-Based Business Process Models: Creation and Evaluation. Business Process Management Journal, 3(1), pp.17-38, 1997. (Mayer et al., 1995): Mayer, R.J., Painter, M.K., Menzel, C.P., Perakath, deWitte, B.P.S., Blinn, T. Information integration for concurrent engineering (IICE) IDEF3 process description capture method report. KNOWLEDGE BASED SYSTEMS, INCORPORATED, http://www.idef.com, 1995. (McCormack&Johnson, 2001): McCormack, K.P., and Johnson, W.C. Business Process Orientation: Gaining the E-Business: Competitive Advantage. St. Lucie Press, 2001. (Ould, 1995): Ould, M., Business Processes – Modelling and Analysis for Re-engineering and Improvement, John Willey & Sons, Chichester, 1995. (Rumbaugh et al., 1999): Rumbaugh, J., Jacobson, I., Booch, G. The unified modeling language reference manual, Addison Wesley Longman Inc., 1999.

16