Local, Participative Process Modelling The PICTURE-Approach

Transcription

1 Local, Participative Process Modelling The PICTURE-Approach Jörg Becker, Lars Algermissen, Daniel Pfeiffer, Michael Räckers European Research Center for Information Systems, Leonardo-Campus 3, Münster, Germany {becker; algermissen; pfeiffer; Abstract. Process modelling is regarded as an important activity within Business Process Management (BPM) projects. A common modelling procedure has been established that is based on a prioritisation, documentation, and analysis of the business processes. However, it can be difficult to apply this procedure when only very little is known about an organisation as it presupposes some knowledge about the process structure. In this paper we present local, participative modelling as an alternative to this approach. With the process modelling method PICTURE an implementation of local, participative modelling is presented. With this specific view of knowledge acquisition in mind PICTURE is compared with the workflow patterns of van der Aalst et al. [2] in order to identify similarities and differences. Based on this analysis suggestions for the further development of the PICTURE method are derived. Keywords: PICTURE, workflow patterns, process modelling approaches, sequential modelling, electronic government. 1 Introduction In Business Process Management (BPM) projects process models are used to describe the current state of an organisation, to derive possible improvements, and to specify the resulting structuring of operations [3]. Process models are semi-formal, mostly graphical descriptions of the business processes of an organisation. They can be applied to document what activities are performed but also how things could, should, or must be done to meet the business goals. Thus, they help to create transparency about the sequence of activities within a process, the resulting products and services, the required data, as well as the involved organisational units. Process models are also useful to prepare a complete or partial implementation of business processes in a Workflow Management System (WMS) [4]. In Software Engineering (SE) projects process models are applied to define the functionality of a software system [5, 6]. They support the communication between the software developers and the future users of the product as well as they foster an equal understanding of the requirements and thus increase the quality of the software.

2 A common procedure has been established to acquire process models [7-11]. The procedure has been successfully applied in multiple projects and is used for BPM consulting. It starts with identification and structuring of processes that are relevant for the specific project. If the objective of the project is for example to document all financial workflows of an organisation, all business processes that belong to that area must be named and systemised. However, the resources in a project are always limited. Hence, it is usually not possible to allow for representing all of the processes. Therefore, depending on their impact on the objectives of the overall project in a second step it is necessary to prioritise the processes. Based on this prioritisation as well as the available budget it may be required to select only a subset of the processes for further analysis. In a third step individuals in the organisation are identified who possess knowledge about the chosen processes. These people are interviewed and asked about the processes. The notes from these interviews or group workshops are used to create the business process models. In a forth step the process models are analysed in order to identify weaknesses and potential improvements. Thereof, to-be models of the business processes are derived and implemented. Following this procedure has many advantages. It is driven by the project objectives and in the case of scarce resources useful also provides results for specific processes. It focuses on a limited group of representatives in the organisation who have good knowledge about the processes and involves them in the process acquisition. However, this procedure is geared to scenarios where the scope of the modelling project is clearly cut, a catalogue of processes is available, and the individuals who possess comprehensive knowledge about processes are known and available. It is less well suited if the organisation has no understanding of its business processes and the scope of the modelling project is fuzzy [11]. The objective of this paper is to present local, participative process modelling as an alternative to the established acquisition approach. The process modelling method PICTURE is presented as an example that supports local, participative modelling. The paper proceeds as follows: In the next section in a literature review different characteristics of process modelling approaches are analysed and categorised. In the resulting framework local, participative process modelling is discussed based on different dimensions. In the third section of this paper the public administration domain specific modelling method PICTURE is presented as an example for the realisation of the local, participative modelling approach. In the fourth section PICTURE is evaluated against the workflow patterns of van der Aalst et al. [2]. Deviations from these patterns in PICTURE are discussed based on the specific view of local, participative modelling. The paper closes with a summary of the main results and an outlook to further research. 2 A Framework of Process Modelling Approaches Process models have become a broadly applied and valuable instrument in BPM [12-14]. However, several different approaches have been developed on how to capture those models. In this section we will discuss these approaches based on the dimensions: direction of modelling, the modelling scope of an employee, the relevant

3 interaction object, and the involvement of the employees. The results of this analysis are consolidated in form of a framework that structures the different process modelling approaches. Direction of Modelling: A modelling project can take up a bottom-up and or a topdown perspective [15-18]. The top-down approach starts from a coarse granular description of the domain. In each step of the project the description gets more detailed and more specific. Prerequisite for an application of this approach is that the scope of modelling is defined and that an overview of the processes to be acquired exists. In business process modelling projects a structured overview over the business processes of an organisation does not always exist at the beginning of the project. If the knowledge of the process structure is not available, then it is usually an objective of the project to build up such a structured description. However, in such a situation a top-down approach is not adequate as it requires such a process overview as input. However, in Software Engineering projects the top-down approach is very common [19]. It offers the advantage of only gradually increasing the complexity for the modeller. The bottom-up approach is an alternative to collect the process knowledge in an organisation. Instead of starting with a structured overview of all processes, the modelling activities start from a defined lowest level of abstraction. In a subsequent step the modelled process parts are analysed and combined to whole processes or groups of processes. Thus, the level of abstraction is increased. By following this procedure the structure of the processes is the result of a project and not its starting point. An important criterion to differentiate between the two approaches is whether the knowledge about the process structure is available in advance. Modelling Scope of an Employee: When an employee is involved in a modelling project the scope [20] defines whether he can be interviewed about the processes he actually performs or about the processes he knows. Most employees have relevant knowledge about much more processes than they actually execute. Collecting all this information from the employees corresponds to a Model what you know approach. In the optimal case with this approach only very few employees have to be involved in a project. However, by following this approach one faces the simultaneously increasing risk of overlooking relevant information as the knowledge of each employee about specific details is limited. To avoid this, a strict Model what you do approach can be applied [21, 22]. Following this approach every employee only describes what he or she is doing by himself or herself without stating any other information. This leads to more interviews but reduces the risk of overlooking important information. Especially, if the processes are spanned over the organisation with many dependencies between the organisational units this option can be a more efficient way. Otherwise the modelling experts have to go through the organisation several times to resolve problems. This, however, reduces the efficiency of the modelling project and increases the costs. Relevant interaction object: For documenting business processes, two different views can be taken up. Firstly, considering a process as concerned with a specific case. In this case driven view the relevant object for the process is the case or from a customer oriented perspective the customer. Thus, the case is the only driver for the process activities. The activities of the external process participants have to be considered also and, hence, have to be modelled [23]. This requires an extensive contact to the people involved in a process. Secondly, considering the processes from

4 a more local, information driven view the facts coming in and getting out at the different process interfaces are the only relevant interaction objects. Modelling the processes in this manner means only to react based on these available information. It is not important who provides the information or if the same information comes in several times. This perspective on processes is focused on information only. Involvement of the Employees: To capture the knowledge about the processes the employees carrying out the processes have to be involved. This involvement can be strong or rather weak. Many process modelling projects are performed by external consultants or modelling method experts who capture the process knowledge in interviews and create process models out of them in a second step [24]. In this case the employees are only little involved in the modelling task. To increase the involvement of the employees it is important to enhance their knowledge about the applied modelling method. The long term objective of such training is that the employees can model their processes themselves. As creating process models is a time consuming work, a higher involvement of the employees can significantly reduce the cost of the project. However, at the same time the number of modellers increases. This makes it hard to get high quality process models; because the more modellers participate the more different perspectives on the processes exist. Facing this problem a small team of modelling method experts supporting the employees may be an effective way. To strongly involve employees during a modelling project creates the demand for a less complex modelling method which allows for fast and easy modelling. Such a modelling method must restrict the degree of freedom of the modellers to come to comparable results. Table 1. Framework of process modelling approaches. Dimension Process Modelling Approaches Direction of the modelling project Top Down Bottom Up Modelling Scope of an Employee Model what you know Model what you do Relevant interaction object Case driven view Information driven view Involvement of an Employee Little involvement Strong involvement The analysis of several dimensions of process modelling approaches was conducted to create an understanding of the view of local, participative modelling. Keeping the discussion in mind a local perspecitive on process modelling demands for a model what you do approach. In this local view useful process parts can only be created efficiently if the participating modellers are working independently from each other. This way of modelling directly follows up to an information driven view on process modelling as only process parts are modelled. A single modeller only decides by means of the information coming in and getting out from his or her processes what activies to execute. As the processes are aggregates of more detailed process parts a process landscape can easily be created with a bottom-up approach. By using a modelling approach that supports local modelling with these properties it is easier to involve the employees in the modelling activities as locally defined, small, and less complex modelling tasks arise. So, a strong participation of employees and, thus, an efficient modelling is possible. Table 1 summarizes the different dimensions of process modelling approaches.

5 3 The PICTURE Process Modelling Method The PICTURE-method for process modelling has been specifically developed for the use in the public administration domain. It strives for a flexible, efficient and simple representation of administrative processes. The PICTURE-method consists of a modelling language and a procedure model which guides the application of the language. Both parts are implemented in a webbased tool with the name PICTURE. In this paper the language aspect of the method is focused. PICTURE consists only of a few modelling constructs, which in combination allow for an easy and straightforward modelling of a public administration s process landscape. In the following section these constructs are introduced, and an example is given. Subsequently, the characteristics of the constructs are matched with the process modelling approaches framework developed in the last section in order to show how PICTURE differs from the traditional approach. 3.1 The PICTURE-language constructs The basic constructs of PICTURE are views, process building blocks, and attributes. Additional constructs that rest upon the basic ones are processes, sub-processes, variants, and anchors. Views: Like many other process modelling approaches PICTURE uses views in order to handle and effectively reduce complexity. PICTURE consists of four different views: Process View ( How is a service delivered? ) Business Object View ( What is processed/produced? ) Organisation View ( Who is involved in the modelling process? ) Ressource View ( What ressources are used? ). Process Building Blocks: The main constructs of the PICTURE modelling language are domain specific process building blocks. A process building block represents a certain set of activities within an administrative process and applies the vocabulary of the public administration domain [25]. Process building blocks are atomic, have a defined level of abstraction and are semantically specified by a domain concept. They are either completely executed or not accomplished. With process building blocks problems like naming conflicts [26] in a model comparison are avoided, because the name of a process building block is specified by the language designer rather than the modeller. Examples for process building blocks are Incoming Document, Formal Assessment, Enter Data in IT, or Archive Document. Process building blocks belong to the process view. Attributes: With building blocks a sequential order within administrative processes can be specified. Additional facts about the processes can be collected with the help of attributes assigned to the process building blocks. These attributes specify the properties of the corresponding building blocks in detail. For example, a possible attribute for the process building block Enter Data into IT is Duration. Attributes provide the core information for a subsequent process analysis. They establish a connection to the business object, organisation, and resource view.

6 Fig. 1 shows the modelling constructs introduced so far and how they relate to each other. Fig. 1. Views, Building Blocks, and Attributes within the PICTURE-Method. The Process view is the main view of the PICTURE-method and it contains four additional language constructs: processes, sub-processes, variants, and anchors. Processes: A process performs a certain administrative service. In PICTURE processes are represented as a sequential flow of building blocks. This sequential order restricts the degrees of freedom of the modeller and simultaneously promotes the construction of structurally comparable models. A process can be described further by attributes and connected with organisational units or employees. Sub-Processes: Many processes are quite complex and run through several different organisational units. In order to simplify the modelling processes the concept of sub-process is introduced. A sub-process in PICTURE is defined as a part of a process that is covered by only one employee. With the help of sub-processes the modelling can be performed distributed. Interviews are rendered more effective as employees are only asked what the actually do in their daily business. After the modelling process is completed the different sub-processes are connected in order to create coherent processes. Variants: As the modelling with the PICTURE-language is strictly sequential a possibility is required to describe contextually important ramifications in the process flow. For that purpose PICTURE offers two possibilities: On the one hand attributes can be used to specify different cases with percentage values, e.g. for different source mediums. On the other hand it is possible to specify process variants. A process variant defines an alternative sequence within a sub-process. Process variants often

7 share many common process building blocks with the original sub-process. However, some of the process building blocks have been modified, new ones have been added and some have been removed. The frequency of a process variant can be weighted by percentage values. Anchor: An anchor allows for establishing connections between process building blocks in different sub-processes and variants. Some specific process building blocks provide attributes to create such anchors. For example the process building block Outgoing Document from variant A in sub-process II can be connected with the process building block Incoming Document from sub-process III. The exchanged document is for example a change request. In this case an anchor is established between the two corresponding building blocks. Thus, the anchor connects different sub-processes to form a process. Anchors allow for following a process through the organisation and connect the different model what you do perspectives. Fig. 2 shows how processes, sub-processes, variants, and anchors work together. Fig. 2. Processes, Sub-Processes, Variants, and Anchors within the PICTURE-Method. PICTURE has been designed as a simple and intuitive modelling language focusing on officials in public administrations. The PICTURE-language allows for a strong involvement of the officials in the modelling project. Their active participation in the project helps to efficiently acquire the process knowledge and to cover the entire process landscape. Hence, the collection of the process models is performed in a coarse granular form to reduce time and efforts for modelling.

8 Fig. 3. Example Process Update Citizen Register in PICTURE-Notation Fig. 3 shows the process Update Citizen Register as an example. The process is triggered by a citizen in case he is moving to a new address. By law it is required to inform the government by handing in a change request. This fact is visualised using the process building block Incoming Document. Within the following four columns additional information are given regarding attributes, the organisation responsible, the business object and the resources used in order to process the building block. Within the attribute column for example it is specified that 60% of all change requests are made by letter mail, 10% arrive by fax and another 30% are made by citizens appearing personally. The next step within the process or in other words the next building block used is Formal Assessment in which the completeness of the change request is verified. Afterwards the citizen register database is updated and the change request is archived for at least one year (which is specified in the corresponding attribute). As the example shows the focus lies on an easy capturing of the business facts behind the process and not on a complex modelling of the control flow and exceptions. Practical experience has proven that this kind of visualisation is strongly preferred by public administration users.

9 3.2 PICTURE and the process modelling approaches framework Having introduced the different modelling constructs of the PICTURE-Method it is now possible to link these constructs to the process modelling approaches framework in Table 1. Direction of the Modelling Project: The direction of modelling in a PICTURE project follows a bottom-up approach. The process building blocks are used as starting point in order to model the complete process landscape. This is especially important in the public administration domain because of two reasons. Firstly, the scope of modelling of often not clearly defined and secondly, the processes even their basic names are only partially known and specified within public administrations. The bottom-up approach aims at delivering a complete service catalogue to build up a structure of processes. Modelling Scope of an Employee: The modelling scope of an employee with PICTURE is Model what you do. The language construct sub-process is a good example for that fact as within an interview an employee is only asked to model what he himself is actually doing. There might arise additional information from an interview for example regarding other parts of the processes. However, this is not relevant for a PICTURE project. The Model what you do approach is especially important in the public sector as there are a lot more processes in a public administration than in common businesses [11]. Hence, there are only very few people who have substantial knowledge about the entire process landscape. Relevant interaction object: PICTURE employs an information driven perspective. The Business Object View underlines this fact as within that view the flow of information objects throughout the organisation is in the focus and other facts are not relevant for the flow of the process. The aim behind this is to create transparency and make public administrations activities traceable and comprehensible. Involvement of the Employees: There is a strong involvement of employees due to three facts: Firstly, the overall process landscape has to be modelled so there is a large amount of people which have to get involved in the modelling project. Secondly, the concept of sub-processes requires that basically all people involved in a given process have to deliver their knowledge. Thirdly, in order to handle the task of modelling a large amount of processes the modelling constructs are simplified (e.g. by providing standardised building blocks) so that employees can basically model their processes themselves needing minimal training. These findings show that PICTURE is different to existing modelling approaches in a lot of aspects. In the next section the modelling constructs of PICTURE are evaluated. 4 Evaluation of the PICTURE Modelling Constructs The PICTURE modelling method has been evaluated in multiple projects in the public administration domain [27, 28]. In these evaluations the method has been analysed empirically in terms of case studies [29] and action research [30]. These

10 studies have focused on the suitability and performance of the PICTURE method in comparison to established approaches. PICTURE proved to be an adequate approach to capture the process knowledge within a public administration. PICTURE could also show to be suited to manage this knowledge and to make it available within the public administration. In PICTURE projects the cost of modelling could be reduced up to 50% in comparison to traditional process modelling approaches. However, empirical evaluation is only one possibility to asses the quality of a modelling method. Siau and Rossi [31] also name feature comparison, metamodelling, metrics approach, paradigmatic analyses, contingency identification, ontological evaluation, and approaches based on cognitive psychology as alternative non-empirical evaluation techniques. In this paper we will focus on a metamodel based assessment [32, 33] of the PICTURE method. With this approach the metamodel of the method is compared with the constructs of competing methods or a supermethod in order to identify differences and similarities. Well established modelling languages that are relevant for an evaluation of PICTURE are for example Activity Diagrams (AD) [34], Business Process Modelling Notation (BPMN) [35], or Event Driven Process Chains (EPC) [9]. As a kind of supermethod the workflow patterns of van der Aalst et al. [2, 36] have recently drawn the attention of the information systems community. Based on these findings a number of comparisons between the patterns and modelling languages such as AD [37], BPMN [38], or EPC [39] have been published. Therefore, in the following, we will base our evaluation on the workflow patterns and confront the PICTURE constructs with them. It is important to note, though, that PICTURE does focus on modelling processes in such a fine-grained form that enables their implementation in a workflow management system. PICTURE rather tries to create transparency over a process landscape and to allow for semantic analyses. 4.1 Support of the Workflow Patterns in PICTURE In its original form van der Aalst et al. [2] have presented 20 workflow patterns. Table 2 gives an overview on the support of the patterns in the PICTURE-language. A sequence expresses that a succeeding activity is only enabled when the preceding one has finished. This can be realised in PICTURE as a series of process building blocks. Parallel split divides a process into two concurrently activated branches. It corresponds to an AND-split in many modelling languages. As the modelling in PICTURE is strictly sequential a parallel split is only partially supported. In the process building block Outgoing Document it is possible to send a document to more than one organisational unit. Thus, an anchor connects the organisational unit that sends the document to the organisational units that receive it. Thereby, while executing the process the corresponding sub-processes in the receiving organisational units are activated simultaneously. Synchronisation merges two or more branches when all of them have been enabled. Similar to a parallel split the process building block Incoming Document can also accept multiple documents. That means, the subsequent activity is only activated when all of these documents have arrived. An anchor links processes with (multiple) incoming documents to their corresponding, preceding sub-processes. Exclusive choice selects

11 exactly one of the subsequent branches. It is related to the XOR-split in many modelling languages. This behaviour is supported in PICTURE by variants. However, variants exist only for entire sub-processes and not for single process building blocks. This means that for each exclusive choice within a sub-process a new variant of it consisting of strictly sequential process building blocks must be created. Simple merge reconnects different branches which have been created by an exclusive choice. This is not supported in PICTURE yet but an implementation is planned for the near future. In order to support simple merge and to simultaneously retain a strictly sequential modelling, variants in PICTURE must be extended by the feature to define common process building blocks shared by multiple variants. Multi-choice splits a branch into two or more branches. Multi-choice corresponds to an OR-connector in other modelling languages. It is not supported by PICTURE. Synchronising merge, multi-merge, and discriminator represent different possibilities to reconnect branches that have been split-up by a multi-choice. These connectors are also not supported by PICTURE. Arbitrary cycles stand for the ability of a modelling language to represent cycles with more than one entry and exit point. In PICTURE they can only be represented partially with the aid of case numbers and variants. For example an application process terminates because not all required documents are on hand. A cycle is created when the application is resubmitted and the evaluation steps must be repeated. If the evaluation steps are exactly the same then, from the perspective of the process it is just another case. However, if the evaluation steps slightly differ, a variant of this subprocess can be created that comprises the process building blocks being executed when the completed application arrives. The execution probabilities of the variants can help to weight the different cases of returning applications. Implicit termination means that a process stops when there are no remaining work items. This pattern is supported by PICTURE as sub-processes and their variants can end with every process building block. However, from a public administration domain perspective only a few specific process building blocks are semantically adequate to close a process. Multiple instances refer to the numerous threads that a single process can create. In PICTURE they are partially supported by case numbers of processes in combination with the probability of occurrence of different variants. The synchronisation of threads can be realised by the process building block Wait Until and a corresponding absolute point in time that is attached as an attribute. Deferred choice, interleaved parallel routing and milestone are all three state based patterns. That means they refer to a specific state of a process instance. In PICTURE states are not modelled explicitly but are only implicitly represented as part of the attributes. In a deferred choice a decision about what subsequent branch should be activated is made based on an interaction with the operating environment. In PICTURE this can be represented by a variant and the corresponding attributes of its process building blocks. Within a variant all facts that influence the flow of this particular process are known in advance. In the application example from above the variant of a returning case is only executed if these specific conditions are met. If there are other influencing factors they were covered by an own variant. Interleaved parallel routing means that a certain activity or set of activities is not part of a strictly sequential order but can be executed in different possible orders. For example it does

12 not matter whether a document is signed first and stapled afterwards or stapled first and signed later on. It is not possible to represent this fact in PICTURE yet. A milestone requires that a process instance is in a certain state in order to get a nominated activity enabled. For example the registration deadline must not been elapsed in order to get enrolled as student. Milestones are partially supported by PICTURE in form of the process building block Wait Until where a specific point in time is added as an attribute. Cancel activity and cancel case deal with the abortion of an activity or a complete elimination of an entire process instance. PICTURE does not support these process patterns. Table 2. Support of the workflow patterns in PICTURE. No. Workflow Pattern Name Support in PICTURE Related PICTURE Construct 1 Sequence Supported Process building blocks 2 Parallel Split Partially Supported Anchors 3 Synchronisation Partially Supported Anchors 4 Exclusive Choice Supported Variants 5 Simple Merge Not supported None 6 Multi-Choice Not supported None 7 Synchronising Merge Not supported None 8 Multi-Merge Not supported None 9 Discriminator Not supported None 10 Arbitrary Cycles Partially supported Case numbers, variants 11 Implicit Termination Supported Variants Multiple Instances Partially supported Case numbers, building block Wait Until 16 Deferred Choice Partially supported Variants and attributes of the process building blocks 17 Interleaved Parallel Routing Not supported None 18 Milestone Partially supported Building block Wait Until 19 Cancel Activity Not supported None 20 Cancel Case Not supported None 4.2 Discussion of the PICTURE Method The PICTURE method relies on a bottom up, model what you do, information driven and strong involvement of the employees based approach. The model what you do perspective explains why PICTURE only partially supports the parallel split and why it does not implement the multi-choice as well as the corresponding merge connectors at all. The underlying assumption is that a person can not do two things at the same time in an administrative process. As the process building blocks are semantically fixed it is straightforward to test this hypothesis. Process building blocks are atomic and their permutation clearly shows that none of them can be executed with another one at the same time. For example it is not feasible to do a formal verification of a document and to concurrently archive the document. A single person can do only one thing after the other. The only reason for a parallel split is that a document is forwarded to different organisational units or people who subsequently work on it in

13 concurrently. Hence, the process building block Outgoing Document supports multiple leaving documents and establishing an anchor to the corresponding subprocesses. Thereof, a global view of the process including its branches can be derived and depicted. The same holds for the process building blocks Incoming Document and the different merges. A similar argument explains why there is no explicit support for cancel activity and cancel case. The perspective of process acquisition with PICTURE is what one person does in general when he or she executes a process. Specific instances are not in focus but rather what a person or their colleagues normally do when a process is carried out. Consequently, cancel activity and cancel case coincide with exclusive choice and implicit termination. Multiple instances are annotated in form of case numbers on the process. Milestones and synchronisations of multiple instances can be done with the process building block Wait Until. In PICTURE the modelling is information driven. When a sub-process or a variant is executed then it is assumed that all available information that influences the flow of the process is explicitly known in advance. For a process in a public administration this assumption is not only reasonable but rather required to ensure the traceability of the decision making. That means, for example, based on the information whether it is an initial application document or a revised version of it, it is possible to handle both cases in different variants. However, if this fact is not known then both are treated the same in only one single sub-process. This justifies the abdication of arbitrary cycles as an own modelling construct as they can either be represented in form of a new case (process instance) if the information state is not influenced or as a variant if the iteration has an impact on the information state. A similar argument also explains that no multi-choice construct is implemented in PICTURE. Beneath the fact that it is assumed that a person can only do one thing at a time a multi-choice also goes along with insufficient information. Assume for example that in a model it is specified that an emergency hotline sends out an ambulance or (in the sense of multi-choice) a police car because of a call. The reason for the or specification is that the conditions of this event are not precisely defined. The information driven view of PICTURE and the traceability rules of public administrations, however, require that these facts are available if they influence the flow of the process. Deferred choice also requires additional information from the environment. As PICTURE assumes that this information is known in advance deferred choice coincides with exclusive choice. PICTURE strives for a strong involvement of the employees. Thus, in the optimal case the employees are able to model their processes on their own. This requires a modelling method to be as simple as possible and easily understandable for domain experts. Interleaved parallel routing is a complicated concept as a possible partial order of activities is not obvious and often hidden behind a learned or accustomed sequence of activities. Hence, the inclusion of this concept is in conflict with a highly autonomous modelling. Rather, consultants are required who are able to identify a possible alternative ordering of activities. Nevertheless, PICTURE should be complemented with a way to represent interleaved parallel routing. Depending on the grade of involvement in a project this feature should be enabled or disabled. The missing simple merge can not be explained because of the local, participative modelling approach of PICTURE. An implementation of this pattern should be added to the PICTURE constructs.

14 5 Summary and Outlook This paper has been based on the assumption that the well established procedure to acquire knowledge about the business processes of an organisation is restrained to institutions where an overview about the operational structures is already available. Local, participative process modelling has been presented as an alternative to the established acquisition approach with the aim to avoid its disadvantages. Based on these insights the process modelling method PICTURE has been described as an example that supports local, participative modelling. With this specific view of knowledge acquisition in mind PICTURE has been compared with the workflow patterns of van der Aalst et al [2]. This analysis has revealed some weaknesses of the PICTURE-method but also brought support for its main design decisions. The workflow patterns based analysis of the PICTURE-language exposed a couple of possible improvements. Firstly, support of the workflow pattern simple merge should be provided. This can be done by expanding the construct variant by a notion of shared process building blocks. Thus, the sequential modelling can be retained but the information is gained at what point different variants return to the same execution path. In the current form of the variant this information is not available. Secondly, the workflow pattern interleaved parallel routing should be implemented as PICTURE construct. A possible solution could be an attribute that specifies between what preceding and succeeding process building blocks a specific process building block can freely be moved. Hence, an area is defined where the strictly sequential ordering is partially removed for a process building block. It is due to further research what other enhancements must be made to support a transformation of PICTURE models into descriptions of workflow management systems. Beneath an empirical evaluation and a metamodel based approach Siau and Rossi [31] also define other forms of evaluation. It is subject to further research to asses the quality of PICTURE based on other means. Acknowledgements. The work published in this paper is partly funded by the European Commission through the STREP PICTURE. It does not represent the view of European Commission or the PICTURE consortium, and the authors are solely responsible for the paper's content. References [1] Becker, J., Algermissen, L., Falk, T., Pfeiffer, D.: Reorganization Potential in Public Administrations - Identification and Measurement with the PICTURE-Approach. In: G. Ake, S. J. H., K. V. Andersen, and M. Wimmer, (eds.): Electronic Government. (2006) [2] van der Aalst, W., ter Hofstede, A. H. M., Kiepuszewski, B., Barros, A. P.: Workflow Patterns. Distributed and Parallel Databases 14 (2003) 5-51 [3] Davenport, T. H., Short, J. E.: The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review 31 (1990) [4] Salimifard, K., Wright, M.: Petri net-based modelling of workflow systems: An overview. European Journal of Operational Research 134 (2001)

15 [5] Karimi, J.: Strategic Planning for Information Systems: Requirements and Information Engineering Methods. Journal of Management Information Systems 4 (1988) 5-24 [6] Kottemann, J. E., Konsynski, B. R.: Information Systems Planning and Development: Strategic Postures and Methodologies. Journal of Management Information Systems 1 (1984) [7] Palkovits, S., Wimmer, M.: Processes in e-government - A Holistic Framework for Modelling Electronic Public Services. In: Proc. 2nd International Conference on e- Government (EGOV 2003) (2003) [8] Schwegmann, A., Laske, M.: As-is Modeling and Process Analysis. In: J. Becker, M. Kugeler, and M. Rosemann, (eds.): Process Management - A Guide for the Design of Business Processes. Springer (2003) [9] Scheer, A.-W.: ARIS - Business Process Modeling. 3 edn. Springer Publishing, Heidelberg et al. (2000) [10] Algermissen, L., Delfmann, P., Niehaves, B.: Experiences in Process-oriented Reorganisation through Reference Modelling in Public Administrations The Case Study Regio@KomM. In: Proc. 13th European Conference on Information Systems (ECIS 2005) (2005) [11] Becker, J., Algermissen, L., Falk, T., Pfeiffer, D., Fuchs, P.: Model Based Identification and Measurement of Reorganization Potential in Public Administrations the PICTURE-Approach. In: Proceedings of the 10th Pacific Asia Conference on Information Systems (PACIS 2006). (2006) [12] Green, P. F., Rosemann, M.: Integrated Process Modeling: An Ontological Evaluation. Information Systems 25 (2000) [13] Shanks, G., Tansley, E., Weber, R.: Using ontology to validate conceptual models. Communications of the ACM 46 (2003) [14] Becker, J., Kugeler, M., Rosemann, M.: Process Management - A Guide for the Design of Business Processes. Springer, Berlin et al. (2003) [15] Harmsen, A. F.: Situational Method Engineering. Twente (1997) [16] Soffer, P., Golany, B., Dori, D.: ERP modeling: a comprehensive approach. Information Systems 28 (2003) [17] Fridman Noy, N., Hafner, C. D.: The State of the Art in Ontology Design: A Survey and Comparative Review. Artificial Intelligence Magazine 18 (1997) [18] Speck, M., Schnetgöke, N.: To-Be Modelling and Process Optimization. In: J. Becker, M. Kugeler, and M. Rosemann, (eds.): Process Management - A Guide for the Design of Business Processes. Springer (2003) [19] Bauer, B., Kasinger, H.: AOSE and Organic Computing - How Can They Benefit from Each Other Position Paper. In: Proc. Seventh International Bi-conference Workshop on Agent-Oriented Information Systems (AOIS-2005) (2005) [20] Mendes, R., Mateus, J., Silva, E., Tribolet, J.: Applying Business Process Modeling to Organizational Change. In: Proc. 9th Americas Conference on Information Systems (AMCIS 2003) (2003) [21] Brash, D.: The Contributions of Participants to Enterprise Modeling. In: Proc. Tenth Australasian Conference of Information Systems (ACIS '99) (1999) [22] Gjersvik, R., Krogstie, J., Folstad, A.: Participatory Development of Enterprise Process Models. In: J. Krogstie, T. Halpin, and K. Siau, (eds.): Information Modeling Methods and Methodologies. Idea Group (2005) [23] Ziemann, J., Kahl, T., Matheis, T.: Cross-organizational processes in Public Administrations: Conceptual modeling and implementation with Web Service Protocols. In: Proc. 8th Internationale Tagung Wirtschaftsinformatik (WI2007) (2007) [24] Lankhorst, M. M., van der Stappen, P. J. M., Teeuw, W. B.: Model Types for Analysis and Redesign of Business Processes. Engineering Valuation and Cost Analysis 4 (2001) 31-50

16 [25] Rupprecht, C., Funffinger, M., Knublauch, H., Rose, T.: Capture and Dissemination of Experience about the Construction of Engineering Processes. In: Proc. 12th International Conference on Advanced Information Systems Engineering (CAiSE2000) (2000) [26] Pfeiffer, D., Gehlert, A.: A framework for comparing conceptual models. In: Proc. Workshop on Enterprise Modelling and Information Systems Architectures (EMISA 2005) (2005) [27] Becker, J., Czerwonka, M., Pfeiffer, D., Räckers, M.: Decision Making in Public Administrations based on Analysable Process Models. In: Proc. 5th Eastern Europe e Gov Days (2007) [28] Becker, J., Bergener, P., Pfeiffer, D., Räckers, M.: Management of Process Knowledge in Public Administrations. In: Proc. TED Conference on e-government (2007) [29] Yin, R. K.: Case Study Research - Design and Methods. Sage, Thousand Oaks, CA et al. (2003) [30] Avison, D., Lau, F., Myers, M. D., Nielson, P. A.: Action Research. Communications of the ACM 42 (1999) [31] Siau, K., Rossi, M.: Evaluation of Information Modeling Methods - A Review. In: Proc. Thirty-First Annual Hawaii International Conference on System Sciences (HICSS1998) (1998) [32] Song, X., Osterweil, L. J.: Experience with an Approach to Comparing Software Design Methodologies. IEEE Transactions on Software Enginerring 20 (1994) [33] Hong, S., van den Goor, G., Brinkkemper, S.: A formal approach to the comparison of object-oriented analysis and design methodologies. In: Proc. Twenty Sixth Annual Hawaii International Conference on Systems Sciences (HICSS 1993) (1993) [34] Object Management Group. UML 2.0 Superstructure Specification.[Online]. Available: [35] Object Management Group. BPMN Final Adopted Specification 1.0.[Online]. Available: [36] Russell, N., ter Hofstede, A. H. M., van der Aalst, W., Mulyar, N.: Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22, (2006) [37] Bergholtz, M., Jayaweera, P., Johannesson, P., Wohed, P.: Pattern-Based Analysis of the Control-Flow Perspective of UML Activity Diagrams. In: Proc. 23rd International Conference on Conceptual Modeling (ER2004) (2005) [38] Wohed, P., van der Aalst, W., Dumas, M., ter Hofstede, A. H. M., Russell, N.: Pattern-based analysis of BPMN - an extensive eval-uation of the control-flow, the data and the resource perspectives. BPM Center Report BPM-05-26, (2005) [39] Mendling, J., Neumann, G., Nüttgens, M.: Yet Another Event-driven Process Chain - Modelling Workflow Patterns with yepcs. Enterprise Modelling and Information Systems Architectures 1 (2005) 3-13