The paper describes a project in the domain of business process modeling that concerns loosely-structured business processes, i.e. processes for which it is difficult to establish an order of activities. The process in focus is the lobbying process, i.e. a process aimed at influencing decisions of others, e.g. politicians. The project was carried out at a non-profit interest organization, and the paper describes the project's motivation, structure, methodology, results, and how the results were exploited, including a short description of an IT system built to support the lobbying process. As the commonly spread workflow technique is not particularly suitable for loosely-structured business processes, the project exploited an original state-flow technique for developing a model of the lobbying process. The state-flow technique is based on the state-oriented view on business processes that has been used as a foundation for building the support system. The paper reports a number of problems encountered during the introduction of the system into operational practice. These problems led to the needs of reducing the level of details initially introduced into the system; they will be reintroduced at the later stage when the users become more accustomed to work in the process-oriented manner. In the conclusion, the paper discusses success factors important for modeling projects, and pros and cons of the modeling method used, as well as a broader research context of which the work presented in the paper is a part.
The category of "Experience Report" is unusual for a research conference category. Therefore, we will begin by explaining our understanding of the category. In our opinion, an experience report is about a project that:
(a) had practical motivation and achieved practically useful results,
(b) is representative for some class of tasks/projects that are of interest for practice and/or research in general, and
(c) belongs to a class of tasks/projects that are not adequately represented in the literature.
This paper reports on a project at a non-profit interest organization of building and exploiting a model for a lobbying process. A lobbying process is a process aimed at influencing decisions of others, e.g. politicians, managers, etc. Though the business process literature is vast, the examples of business process discussed, as a rule, belong to the domain of relatively well-structured, production-like processes. The most often cited examples are production, order processing, and processing of insurance claims, see, for example (Aalst & Hee, 2002; Grover & Kettinger, 1995; Jablonsky & Bussler, 1996; Sheer, 1998).
Lobbying (Jokinen, 2000) belongs to the domain of loosely-structured processes. Business processes of this kind have received less attention in the literature, see, however, (Aalst & Berens, 2001; Bernstein, 2000). By loosely-structured, we mean processes for which it is difficult to pre-determine the order of activities. This term has a connotation with the concept of ill-defined problems in AI, see, for example (Simon, 1973), and with such terms as ad-hoc, emergent and dynamic workflows, as discussed in (Bernstein, 2000; Jorgensen & Carlsen, 1999).
Considering loosely-structured processes is very important for today's business practice. To survive and grow in the global economy, companies and other organizations need to take measures aimed at increasing their efficiency. One way to increase efficiency is via lowering operational costs, and such costs may be roughly divided into two categories: production costs, and administrative costs. Many production processes nowadays are highly automated, and the use of robots in industry is growing. In our view, there are fewer opportunities to gain significant savings through lower production costs. Therefore, companies and other organizations turn their attention to achieving higher efficiency in administration and management, the areas where loosely-structure processes are the rule, rather than exception.
From a research perspective, the project described in this paper represents a typical example of the action research theory in action. For an overview of the action research theory see (Baskerville & Myers, 2004). According to the classical definition (Lewin, 1947), action research includes the iteration of six phases (1) analysis, (2) fact finding, (3) conceptualization, (4) planning, (5) implementation of action, and (6) evaluation. The focus of this paper is on the conceptualization phase, i.e. building a model.
The paper is written according to the following plan. Section 2 presents the practical motivation for the project. Section 3 describes the project goal and an approach to business process modeling chosen for the job. Section 4 describes the project organization and how the work has been completed. Section 5 presents both the results of the project, and how they were used this far. It contains an informal description of the model of the lobbying process that was developed, and a short presentation of the IT system designed to support the process based on this model. Finally, Section 6 suggests a list of factors that we believe are most important for a modeling project to succeed. It also discusses pros and cons of the modeling method used, and directions of our future research.
The paper concerns a project of creating a business process model for the lobbying process at a regional office of the non-profit interest organization, called the Association of Tenants, Region West Sweden (in Swedish: Hyresgastforeningen, Region Vastra Sverige), abbreviated to HGF. The organization unites more than 60 000 tenants and the purpose of the regional office is to guard the interests of its members. This is done in a number of areas, such as:
* Giving legal and practical advice to its members.
* Conducting rent negotiation on behalf of its members.
* Lobbying, i.e. influencing decisions made by authorities on local, national, or international levels.
Lobbying is an important part of HGF's business. First, it influences the authorities to make decisions that favor the members of the organization. Secondly, it promotes a strong positive image of the organization. Such an image can attract new members to the organization.
HGF had no standard routines to handle lobbying. When information on a new legislation that touched the interests of the organization was received, there was no clear plan of how to oppose or promote this legislation. Strategy and tactics to deal with a new lobbying case were often reinvented on a case-to-case basis. In addition, the following problems were often encountered:
* Information on a decision came too late to HGF (the decision had already been approved; there was no way for HGF to influence it).
* HGF had no channels to exercise its influence on the decision makers.
* There were too few employees experienced in lobbying at HGF, and they did not have time to consider all decisions that touched the interests of HGF's members.
* Information on previous cases of lobbying, successful as well as unsuccessful, was not readily available. In the best case, it existed in the heads of the few experts who worked on these cases. This information was easily lost when these employees quit or retired.
To deal with the problems listed above, the HGF management decided to start a project to go through the lobbying process and find solutions for these problems.
PROJECT GOALS AND CHOICE OF MODELING TECHNIQUE
The goal of the project was two-fold: (1) investigate the experience of lobbying that HGF had possessed, (2) based on the investigation, design a suitable lobbying process that could be used for a majority of lobbying cases at HGF.
There exist quite a lot of practical manuals on lobbying, e.g. (Avner, 2002; Guyer, 2003). However, they were not investigated in the project, since the objective was to use experiences that already existed within the organization and not to find new approaches to lobbying. Behind the decision was the evolutionary way of thinking; the existing experience should be optimized first, and only then new ideas could be tested. Therefore, one of the main tasks of the project was to build a business process model for lobbying, based on existing experience.
According to a general definition of a business process, see (Hammer and Champy, 1993), a business process is a partially ordered set of activities performed to reach a well-defined goal. A process engages a number of participants, which can be divided into two categories: "passive" and "active" participants. Passive participants are consumed, produced or changed through the execution of activities. A document being produced, an organization being reorganized, or a patient being treated in the hospital represent typical examples of passive participants. Active participants, or agents, are those participants that perform activities aimed at the passive participants. The roles of "passive" and "active" participants can both be filled by humans or artifacts (for example, an IT system can serve as an active participant).
There are many different techniques of modeling business processes that could be used in a business process modeling project. The choice of the technique for the project described in this paper has been done based on the general recommendations from (Bider, 2005). (Bider, 2005) differentiates four categories of modeling techniques based on the way they reflect the business process dynamics:
1. Input/output flows. The focus is on passive participants that are being consumed, produced, or changed by the activities. A typical notation to represent this kind of flow is IDEF0 (IDEF0, 1993).
2. Workflows. The focus is on time ordering of activities performed by active participants. Typical notations to represents this kind of flow are IDEF3 diagrams (Mayer et al., 1995), Petri nets (Aalst & Hee, 2002; Reisig, 1985), and Activity diagrams of UML (Rumbaugh et al. 2004).
3. Agent-related workflows. The focus is on agent cooperation, i.e. order in which active participants get and perform their part of work. An agent-related workflow adds a new, agent dimension to the time dimension of an ordinary workflow. A typical notation to represent this kind of flow is Role-Activity Diagrams (Ould, 1995).
4. State-flow view. The focus is on changes produced by activities executed in the frame of a 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. a state of the mind of a human agent trying to find a solution for a complex problem. An example of a state-flow notation is IDEF3 state-transition diagrams (Mayer et al., 1995); these diagrams are complementary to the IDEF 3 workflow diagrams. However, the state-transition diagrams exploit the state-flow view only partially. For a more extensive exploitation of the state flow view, see (Andersson et al., 2002; Khomyakov & Bider, 2000).
The lobbying process at HGF did not have predefined passive participants, except documents of general nature. Nor did the process have a very well defined distribution of responsibilities between the members of the lobbying team; task assignment was done "on the fly". In addition, the lobbying process belongs to the category of loosely-structured processes; activities in lobbying process instances are defined based on the current situation, actions of opposition, current public opinion, etc.
Based on the properties of the lobbying process, and according to the method of choosing a modeling technique presented in (Bider, 2005), the state-flow view was chosen for building a process model for lobbying. More specifically, the state-flow technique described in (Andersson et al., 2002; Khomyakov & Bider, 2000) was used in the project. As this technique is not widespread, below we present some basic notions on which it is built.
The main concept of the state-flow view modeling technique is a process's state. A process's state is aimed to show how much has been done to achieve the operational goal of the process and how much is still to be done. A state of a process is represented by a complex structure that includes attributes, and references to various active and passive participants of the process, such as process's owner, documents, etc. A state of a process does not show what activities have been executed to reach it; it only shows the results achieved so far.
The process is driven forward through a set of stipulated states until its goal has been reached, e.g., a delivery has been paid for. The operational goal can be defined as a set of conditions that have to be fulfilled before a process can be considered as finished. A state that satisfies these conditions is called a final state of the process.
The process is driven forward through activities executed either automatically or with a human assistance. Activities can be planned first and executed later. A planned activity records such information as type of action (goods shipment, compiling a program, sending a letter), planned date and time, deadline, name of a person responsible for an action, etc.
The process's state is used as a primary tool in deciding on what should be done to reach the process's goal from the current state. All activities planned and executed in the frame of the process should be aimed to minimize the difference between the current state and the projected final one. However, in some cases, a history of the process's evolution in time is important when deciding on actions. The history is defined as a time-ordered sequence of all previous states.
Let us incorporate in a process's state all activities currently planned for this process. As a result, we get a generalized state that includes both a passive part (attributes and references mentioned above) and an active part, i.e. a plan. The active part is responsible for moving the process forward. Considering the plan as an integral part of the generalized state allows us to define the notion of valid state that can be applied to any intermediate state of a process. For example, a process that is not in the final state, but has no activities planned for moving it to the next stipulated state is considered to be in an invalid state. Formal rules can be defined to specify what planned activities could/should be added to an invalid state to make it valid. The use of these rules can be combined with manual planning.
When an activity is executed, a process changes its generalized state. Changes concern both the passive and active parts of the state. The active part, i.e. plan, changes due to the executed activity disappears from the process plan and some new activities are planned instead of it. Changes in the state constitute an internal time axis of the process. To link this axis to real time, event registration is performed each time an activity is executed. A registered event is a record that links the change in the state of a process to the reality outside the process. For example, it can record the date-time when the event happened and/or was registered, name the responsible for the event, register comments on the event at the moment of registration (or even later), etc. A list of all events that happened within the frame of a given process constitutes the chronicle of the process, i.e. its written history.
PROJECT ORGANIZATION AND WAY OF WORKING
The project group consisted of three domain experts in the field of lobbying from HGF, and two business analysts from a consulting company. The role of the experts in the domain was to provide information, and verify the suggested business model. The expert group had practical operational knowledge on all aspects of lobbying, and they could describe a number of lobbying cases completed in the past. However, none of the members of the expert group had any previous experience in business process modeling.
The role of the business analysts was to initiate discussions, ask relevant questions and provide the drafts of the model for review. The analysts had experience in business process modeling and in using the state-flow technique. However, none of them had any knowledge on lobbying.
The modeling work consisted of a number of iterations that in a simplified form can be presented as a sequence of the following steps:
1. Get unstructured information from domain experts.
2. Process information abstracting from the unimportant details, and make a sketch of the model, i.e. put a structure upon the information received.
3. Present the sketch to the domain experts, discuss it, acquire new information, and go to the step 2 for refining the model.
Abstracting from details of the current way of handling the process, and uncovering the deep structure of the process were considered as the most essential part of the modeling job. The material presented to the domain experts was not a paraphrase of what they stated during the interviews; it contained new information.
When the state-flow modeling method is used, abstraction from details means concentrating, first of all, on what should be achieved during the process, before going into details of in what way it is done now, or how it could be done in a more efficient way in the future. This means that the task of building a model is focused on designing a structure to represent the state of the process. To be able to communicate the model to the domain experts, the state space is represented in the form of a screen mock-up from a probable future IT system. This gives the possibility for domain experts to understand the model without studying such abstracts concept as state, movements in the state space, etc. The screen mock-ups can also be used as a base for creating an IT system to support the process. An example of such a screen for lobbying is presented in the next section. Details on the use of the state-flow modeling technique are presented in (Andersson et al., 2002).
RESULTS AND THEIR EXPLOITATION
Upon completion, the project produced a final report (in Swedish) that consisted of three parts. The first two parts describe the lobbying process and the third part gives recommendations on organizational changes.
The descriptive section of the report consists of a conceptual model of lobbying (38 pages), and detailed description of activities included in the lobbying process (43 pages). The conceptual model defines all concepts of the model and describes in details the state space constructed for the lobbying process. The state space is presented as a screen mock-up, parts of which can be seen on Figure 1. In addition, an informal description of the lobbying process has been added to the report to make it easier for the reader to understand the details of the full conceptual model. The informal description is presented in Subsection 5.1 below. This description is a generalized one; details specific for HGF were intentionally omitted, as we considered them of less interest to the reader. Due to the lack of space, we do not present other parts of the model here; see, however, description of similar projects in (Andersson et al., 2002), which gives more details on these parts.
The actions recommended in the final report were as following:
1. To deal with the problems described in Section 2 and make the optimal use of available resources, it was suggested to carry out lobbying according to the process model presented in the report.
2. In order to be able to implement the above, it was suggested to acquire and introduce in operational practice an IT system to support the lobbying process. General requirements on the system were listed in the report as well.
3. To ensure that the lobbying experts get information about decisions under preparation in a timely fashion, it was suggested to introduce into operational practice a business intelligence process for monitoring mass media, protocols from the public sector offices, etc.
4. To ensure that there always exist channels to decision makers, it was suggested to introduce into operational practice a new process of maintaining contacts with decision-makers on various levels (international, national, municipality, company).
[FIGURE 1 OMITTED]
The management of HGF accepted all recommendations above. So far only actions 1 and 2 have been implemented. An IT support system has been purchased and introduced in operational practice. The system was built based on the model as a specification. The system and the experience of its introduction in operational practice are summarized in the rest of this section.
Informal Description of Lobbying Process
A lobbying process may be initiated in two ways: actively and passively:
* Active initiation means that the interest organization decides on its own to persuade, or press, an authority, i.e. the decision maker, to make a decision that lies in the interests of its members.
* Passively means that information has been received about a new decision planned, under discussion, or already taken. The decision might affect the interests of the members positively, or negatively, thus the interest organization will support or oppose the initiative.
Independently of active or passive initiation, a decision that the interest organization wants to influence should be analyzed from several perspectives:
* Level of decision: international, national, municipality, company
* Type of decision-maker
* The area to which the decision in question is related: level of rent, housing availability, etc.
* The status of the decision-making: planned, under discussion, made, implemented, etc.
After this analysis, the main course of action, e.g., to promote the decision, to oppose it, or to search for a compromise, could be determined. It is impossible to choose a main course of action without completing the consequence analysis. The decision should be analyzed from the view-point of how it would affect the members of the interest organization. A number of parameters should be chosen for this end. These parameters depend on the nature of the organization. In the case of HGF, the parameters are: level of rents, housing availability, housing standard, etc. For each parameter, an evaluation should be made of how this parameter will be affected by the decision; whether its value would go up or down. The evaluation should be supported by past experience, theoretical studies, etc. This kind of information can be very useful when trying to influence the decision in the chosen direction, create public opinion, etc.
When the main course of actions is chosen, e.g. to oppose the decision, support from the organization's members should be secured. An opinion poll might help for this end. Following, a strategy and tactics need to be designed. The strategy prescribes what channels to use when influencing the decision-maker(s), and in what order. The tactics describes how to use each channel.
The channels for influence are chosen according to the type of the decision-maker. Roughly, all channels to the decision-maker(s) can be divided into two groups; direct channels and indirect channels. By a direct channel, we mean a person or a group at the decision-making organization, e.g. a member of the parliament, a high-level employee of the local authority, etc. By communicating with such a person/group in a certain way (tactics), the decision can be affected directly. Examples of tactics for direct channels are: inform about consequences, ensure support, threaten, or search for a compromise.
Indirect channels should lead to organizations that are not involved in making the decision, but have some influence on the decision-maker(s). The most important indirect channels are the ones that lead to mass media, e.g., daily press, weekly magazines, TV, and radio programs, etc. Examples of tactics for mass media channels are: inform the public about the decision, initiate a debate, build up public opinion, and provoke the decision maker(s) to answer difficult questions. Other indirect channels may lead to local, national, or international authorities that have some power to stop or promote the decision. Examples of tactics for such channels are: inform about the decision and its consequences, get support, and pursue to take actions.
Following the chosen tactics for a given channel means completing one or more acts of communication with the person(s) who represent this channel. Communication may be oral, e.g. meeting, press conference, phone conversation, etc., or written, e.g. fax, mail, email, etc. After all communication activities via the channel have been completed, the result achieved should be understood: whether the tactical goal has been reached or not. By constant evaluation of the results, the overall strategy may be revised, new channels may be tried, or tactics may be changed for some of the channels.
During the communication through the channels, various messages are sent and received. It is important to keep track of these messages, and have operational procedures in place for reviewing them. This can help when writing the answers, and revising the strategy. If the bookkeeping works properly, the documents can also be reused. For example, a document prepared for communication via one channel may be resent via other channels.
The operational goal of the lobbying process can be defined by a number of propositions on the state of the world we want to achieve:
* The decision is classified according to the type of decision-maker.
* Consequences are calculated according to the set of parameters that represents the interests of the members. Consequence analysis is supported by arguments based on past experience, and theories.
* The chosen main course of actions is based on the results of consequence analysis.
* The support of majority of the organization's members has been acquired.
* The channels for influence were chosen according to the type of the decision-making organization.
* The tactics for each channel corresponds to the nature of the channel.
* The massages sent through each channel correspond to the tactics chosen for the channel, the nature of the channel, arguments gathered during the consequence analysis, and information received back through this channel (or maybe other channels).
[FIGURE 2 OMITTED]
A simplified graphical representation of the lobbying process is presented on Figure 2. Representation is done in the form of a state-transition diagram. The circles represent different states of the process, and the arcs name the activities that move the process from one state to another.
IT support for lobbying was built as a special module in a business process support system called ProBis. The system, besides lobbying, supports a set of administrative processes that were identified in the HGF's business. The module was built based on the model that had been worked out in the project. User-interface screens in this module reflect mock-ups developed in the model.
ProBis belongs to the class of case-handling systems. It can be considered as a database interface with group communications capabilities. The heart of ProBis consists of
* Historical database that automatically stores information on all events and all past states of all processes, documents, and other business objects.
* Principle of dynamic and distributed planning. Dynamic means planning when needed, distributed means planning to each other.
The system, among other things, provides:
* A virtual calendar that allows the users to plan tasks to each other, and gives immediate access to all information required for completing individual tasks. The latter includes information on the currents situation and all relevant events and documents in the past and future.
* Automatic support of history recording that allows not only seeing what happened but also, how things looked like at any particular time.
* Document management that facilitates getting access to any internal or external document without knowing its name or storage placement. The documents are found through association to their usage (e.g. purpose of creation). In addition, via support of history, all internal documents are automatically versioned.
Currently, the system is built as a client/server solution, where clients run under Microsoft Windows, and a server runs an SQL DBMS, Oracle, or MS SQL Server. The historical database is implemented as a set of stored procedures and triggers in an SQL database. User interface is built with the help of Prolifics application development tool from Prolifics Inc. More details on the architecture and implementation of the system can be found in (Bider 1997, 2002).
Introduction into Operational Practice
The introduction of ProBis, supporting the lobbying process, proved to be difficult and painful. This introduction is described in detail in our other experience report (Andersson et al., 2005), which covers both experience of Probis introduction, as well as other introduction projects.
Some of the problems were purely technical. They concerned user interface expectations on the part of the users. These problems were fixed by a substantial revision of the user interface. Other problems concerned the introduction process itself. These problems were not unique to our project, and they are often encountered during introduction of new IT systems, see, for example (Markus, 2004; Purvis et al, 2001; Sharma & Yetton, 2003). These problems included:
* Inadequate planning of the introduction, e.g. absence of a formal responsible for introduction of each module
* Unwillingness from the management to enforce the employees to start using the system
* Assigning people that were not part of the modeling project to test the system
* Inadequate training programs
However, the most fundamental problem we encountered was the new way of working, i.e. the change from the functionally oriented to the process oriented way of working. Here, we discovered a "catch 22" dilemma. On one hand, the employees were not accustomed to work in a process-oriented way, because this way could not be introduced without an IT system. On the hand, the employees had difficulties to learn how to work with the IT system because they were not accustomed to the new, structured way of working.
To make this transition easier, the initial ambitions were somewhat lowered. The number of processes introduced through a support system were substantially diminished and the complexity of the screens were significantly reduced. The latter was done by temporarily hiding part of the information fields. These fields will be opened later when the end-users are ready for the extended complexity.
Lobbying was one of the most complicated processes to be supported by the new system. It was decided to postpone its introduction until the time the users became more accustom to the system. At the time of the writing of this paper, the decision was taken to reinstall the support for lobbying in the IT system, and introduce this process into the operational practice. As with other processes, the complexity of the screens was substantially reduced to make it easier to start using the system for lobbying. All adjustments have already been implemented and IT support of lobbying is currently being introduced into operational practice.
In our consulting practice, we often meet people from various organizations and industry sectors who have completed a project of process identification and mapping by themselves, or with the help of consulting company. They can proudly produce quite complicated process maps to show the results of such a project. However, when faced with the question on how the results achieved in the project have been used in practice, many people are unable to address the issue. In their minds, creating the maps was the ultimate goal of the project. Our feeling that something is wrong in the "process modeling industry" is not unique, other practitioners have expressed the same opinion. For example, (Alexander, 2003) complains that business processes modeling projects cost too much, and produce too little value.
This paper describes a business process modeling project that we consider to be successful. The project had practical motivation described in Section 2, and well defined objectives described in Section 3. As a result, it produced a model, and recommendations for organizational changes. The domain experts that worked in the project stated that after the project was completed, they had a better understanding of lobbying. (Lobbying was an area where they considered themselves to be experts prior to the start of the project.) The model was successfully used as a requirements specification for building a support system. Despite the difficulties in introducing the IT support system into operational practice, the HGF management still considers that the project produced the proper process description that should be introduced into daily operations. The simplifications currently made to the system are planned to be reversed later. In addition, the project had not been exceedingly expensive. The consulting company contributed approximately 200 man-hours.
In the text below, we will try to analyze success factors of modeling projects. The analysis is done based on the list of factors presented in Figure 3. The first three factors in the upper level of hierarchy are often mentioned in books and manual on system implementation, requirements engineering, etc (Markus et al, 2004; Purvis et al, 2001; Sharma & Yetton, 2003). The principles of the fourth factor are outlined in (Bider, 2005).
[FIGURE 3 OMITTED]
The factors are the following:
1. Well-understood objectives. The management needs to understand the objectives of the modeling, which the management at HGF also did.
2. Right composition of the expert group. It is important that people in the expert group possess practical knowledge that covers all aspects of the business under analysis. Having management representation in the group is not enough, as the management may not know the details of the process. The experts do not need to have any prior knowledge on modeling; they should just know their job. The expert group at HGF fully satisfied the above criteria.
3. Competent business analysts. Business analysts must know how to extract information from the experts without teaching them complex formal modeling techniques. They also need to be able to present their results back to the experts in an understandable format, so that the model can be verified. No prior knowledge in the domain in question is mandatory. However, it might be useful if the analysts posses some knowledge of the domain. The knowledge on the modeling technique that will be used in the project is not mandatory, but it might be required for short projects. The analysts in our project had experience working with experts and of the modeling technique used in the project. They did not possess any prior knowledge on lobbying.
4. Adequate modeling technique. This is a complex factor. The adequacy should be analyzed against three types of parameters: the type of business process, the type of modeling environment, and the intended use of model.
4.1 Type of business process. Business processes can vary in nature. Some processes are production-like, i.e. the order of their activities can be predefined, while other processes are more loosely-structured, i.e. the order of their activities is difficult, if ever possible, to establish. The lobbying process at HGF belonged to the domain of loosely-structure processes, and this was considered when the state flow modeling method was chosen.
4.2 Characteristics of modeling environment. We consider this parameter to be complex and break it into three sub-parameters: level of prior knowledge, background of the expert group, and experience of the business analysts.
4.2.1 Level of prior knowledge. This parameter characterizes the amount of knowledge that an organization has about its own business processes. This important factor has not received much attention. For example, if the processes have not been identified, such techniques as workflow, and state-flow cannot easily be used, while input/output flow, and agent related view can be used (Bider, 2005). In our project, the lobbying process has been identified before the start of the project, thus the state-flow modeling method could be successfully used.
4.2.2 Background of the expert group. If the expert group consists of people with a technical background, e.g. engineers, system developers, etc., it is possible to use highly formalized notations, and complicated diagrams, etc. This group typically uses formal definitions in their everyday work. Thus, for them, there would not be problems to understand a formal description of business processes and find out what is correct/incorrect. If, on the other hand, people engaged in a process in question include specialists of non-technical 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 diagrams are not suitable for these types of professions. The expert group at HGF consisted of specialists of non-technical professions, which was considered when the state-flow modeling method had been chosen.
4.2.3 Experience of business analysts. Though having a working knowledge of a modeling technique prior to a project start is not mandatory, it should be considered when choosing among techniques that equally satisfy all other criteria. The analysts in our project had experience of using the state-flow modeling technique in several other projects.
4.3 Intended use of model. In our case, building a model pursued two goals: to get a better understanding of the lobbying process, and create a specification for a IT support system. The abstraction from the flow of activities in the state-flow method allowed us to concentrate on uncovering some hidden structure in this loosely-structured process. The mock-up screens constructed when designing the state-space for this process where sufficient for designing a module to support lobbying.
The list of factors presented in Figure 3 and their interpretation above were derived from our own experience. No investigation based on the projects completed by others has been made so far. However, we believe that these factors and their interpretation have general applicability, which we hope to prove in our future research.
Pros and Cons of the Method Used
The main benefit of the modeling method we used in the project was that it allowed uncovering all the details of such highly complicated and loosely-structured process as lobbying. We found two limitations of the method used in the project:
1. The method can be applied only after the existence of a given business process has been established. It took a number of less formal and structured discussions with HGF before the lobbying process has been identified. In these discussions, we visited the various departments of the organization, and asked what they do, for whom, and with what purpose. Other methods listed in (Bider, 2005) can also help with the process identification task.
2. Because it was easy to arrive at a consensus with the customer, we first believed that all of the details of the lobbying processes uncovered during the modeling project could be introduced in a IT support system from the beginning. This proved to be false. An increment introduction of the details should be agreed upon while building a model if the purpose of the model is to serve as the requirements for a support system.
In addition, as stated in (Bider, 2005), this method may not be appropriate for other types of business processes, e.g. highly structured, production like processes.
Current and Future Research
The work presented in the paper has been completed in the framework of a more ambitious project of creating a consistent methodology for introduction of the process-oriented way of working into the administrative practice. The methodology includes business analysis and process modeling, building a support system and introducing it into operational practice. Our current focus is on the system introduction stage where we work on creating a model of an introduction process. In the future, all stages should be tied together so that starting with the modeling stage, the experts can get practical experience of working in a process-oriented way. This will give them a better understanding of how many details, and which ones, should be introduced in the first version of a support system. One possibility of acquiring such experience can be by using ProBis to support the modeling project in which the experts participate.
Acknowledgements: Writing of this report was partly supported by the Swedish Agency for Innovation Systems (Vinnova) under the grant for a project on Integrating Business Process Support with Knowledge Management. We would also like to thank all people who participated in the project, our colleagues, as well as experts in the field that worked for HGF. We also are grateful to the anonymous reviewers and Melinda Perjons who helped us to improve the structure and the language of the paper.
Aalst W.v.d., and Berens P. (2001). Beyond Workflow Management: Product-Driven Case Handling, in: GROUP'01, Boulder, Colorado, USA, ACM.
Aalst W. v. d., and Hee K.v. (2002). Workflow Management--Models, Methods, and Systems, The MIT Press.
Alexander I. (2003). Are There Requirements for BPS? CAiSE '03 Workshops Proceedings, University of Maribor Press, 393-397.
Andersson T., Andersson-Ceder A., and Bider I. (2002). State Flow as a Way of Analyzing Business Processes Case Studies, Logistics Information Management 15 (1), 34-45.
Andersson T., Bider I., and Svensson R. (2005). Aligning people to business processes. Experience report, Software Process: Improvement and Practice (SPIP) 10(4), 403-413.
Avner M. (2002). The Lobbying and Advocacy Handbook for Nonprofit Organizations, Amherst H, Wilder Foundation.
Baskerville R. and Myers M.D. (2004). Special Issue on Action Research in Information Systems: Making IS Research Relevant to Practice--Foreword, MIS Quarterly, 28(3), 329-335.
Bernstein A. (2000). How can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specificity Frontier, CSCW 2000, 279-288.
Bider I. (1997). Object Driver: A Method for Analysis, Design, and Implementation of Interactive Applications, Data Base Management, 32-10-25, Auerbach.
Bider I. (2002). State-oriented business process modeling: principles, theory and practice, PhD Thesis, Stockholm, KTH, Available at: http://media.lib.kth.se:8080/ dissengrefhit.asp?dissnr=3375.
Bider I. (2005). Choosing Approach to Business Process Modeling--Practical Perspective. Inconcept, issue 34, Available at: www.inconcept.com/jcm.
Bider I., and Khomyakov M. (2002). New technology--great opportunities. How to exploit them, Enterprise Information Systems IV, Kluver, 11-20.
Grover V., and Kettinger, W. (1995). Business Process Change: Reengineering Concepts, Methods and Technologies. London, Idea Group.
Guyer R. (2003). Guide to State Legislative Lobbying, Engineering THE LAW, Inc.
Hammer M., and Champy J. (1993). Reengineering the Corporation--a Manifesto for Business Revolution, Brealey, London.
IDEF0 (1993). Integration Definition for Function Modeling, IDEF0, Draft Federal Information Processing Standards, Publication 183 (Fips 183), Available at: http://www.idef.com/Downloads/pdf/idef0.pdf.
Jablonski S., and Bussler C. (1996). Workflow management, modelling, concepts, architecture and implementation, London, International Thomson Computer Press.
Jokinen A. (2000). Lobbying as Part of Business Management, Acta Universitatis Laapeenrantaensis, 98, Diss. Lappeenranta University of Technology.
Jorgensen H.D., and Carlsen S. (1999). Emergent Workflow, Integrated Planning and Performance of Process Instances, Workflow Management '99, Munster, Germany.
Khomyakov M., and Bider I. (2000). Achieving Workflow Flexibility through Taming the Chaos, OOIS 2000--6th international conference on object oriented information systems, Springer, 85-92.
Lewin K. (1947). Frontiers in Group Dynamics II. Human Relations 1(2), 143-153.
Markus M. L. (2004). Technochange management: using IT to drive organizational change, Journal of Information Technology, 19, 3-19.
Mayer R., Menzel C., Painter M., deWitte P., Blinn T., and Perakath B. (1995). IDEF3 Process Description Capture Method Report. Information Integration for Concurrent Engineering (IICE), Interim technical report, Available at: http://www.idef.com/Downloads/pdf/idef3_fn.pdf.
Ould M. (1995). Business Processes--Modelling and Analysis for Reengineering and Improvement, Wiley.
Purvis R. L., Sambamurthy V., and Zmud R.W. (2001) The assimilation of Knowledge Platforms in Organizations: An Empirical Investigation, Organization Science 12(2), 117-135.
Reisig W. (1985). Petri Nets: an introduction, Berlin, Springer.
Rumbaugh J., Jacobson I., and Booch G. (2004). The Unified Modeling Language Reference Manual, 2nd Edition, Addison Wesley Object Technology Series.
Scheer A.-W. (1998). Aris--Business Process Frameworks, Springer.
Simon H. A. (1973). The structure of ill-structured problems, Artificial Intelligence 4, 181-201.
Sharma R., and Yetton P. (2003). The Contingent Effects of Management Support and Task Interdependence on Successful Information Systems Implementation, MIS Quarterly, 4 (27).
DSV, Royal Institute of Technology, Forum 100, 164 40 Kista, Sweden
IbisSoft, Box 19567, 10432 Stockholm, Sweden
DSV, Royal Institute of Technology, Forum 100, 164 40 Kista, Sweden