CAPTURING, FORMALISING, AND ANALYSING COOPERATION PROCESSES: A CASE STUDY

Transcription

1 CAPTURING, FORMALISING, AND ANALYSING COOPERATION PROCESSES: A CASE STUDY Stefanie Kethers CSIRO Mathematical and Information Sciences, Private Bag 10, Clayton South, VIC 3168, Australia Stefanie.Kethers@csiro.au ABSTRACT An organization's success is highly dependent on its ability to cooperate, both within the organization and with other organizations. This is especially true for small and medium-sized enterprises (SMEs). Yet cooperation internal or external does not always succeed, and the reasons for failures or shortcomings are not always obvious. In this paper, an industrial case study involving Co-MAP, a methodology for capturing, formalising, and analysing cooperation processes, is presented. Co-MAP was applied to the new product development process of a medium-sized company, and provided substantial help in locating process shortcomings and problems that had so far been hidden, although their effects had been felt. 1. INTRODUCTION Today s organizational processes require cooperation among the organization s employees. As markets are shifting, technologies are proliferating, competitors are multiplying, and products are rapidly becoming obsolete, cf. (Ramesh and Tiwana, 1999), an organization's success is highly dependent on its ability to cooperate, both within the organization and with other organizations. This is particularly true for small and medium-sized enterprises (SMEs), which can benefit greatly from cooperation (Buse, 1997). The quality of an organization s cooperation processes, which we define as processes that involve several actors sharing common goals and that depend on information exchanges between these actors, and the ability of the actors to synchronize their tasks, is of crucial importance to the organization s success. Yet, cooperation is not always successful, and the reasons behind problems and shortcomings of a cooperation process are not always obvious. To model, analyse, and improve cooperation processes is therefore highly important. One might argue that well-known business process modelling methods, e.g. ARIS, (Scheer, 1998), the IDEF family (Menzel and Mayer, 1998), or languages like UML (Fowler and Scott, 1999) might be sufficient for tackling this issue. However, these methods offer only limited support for representing and analysing the information flows, coordination structures, or goals of the actors involved in the process. This paper describes an industrial case study involving Co-MAP, a comprehensive methodology for capturing, modelling, and analysing cooperation processes. Co-MAP provides a formal, integrative framework that covers the relevant perspectives of a cooperation process. Section 2 describes related approaches for modelling cooperation processes. In section 3, we briefly describe Co-MAP. Section 4 presents an industrial case study where Co-MAP has been successfully applied, and section 5 concludes the paper. 2. RELATED WORK The representation and analysis of cooperation processes is a non-trivial problem. Although methods for business process modelling abound, most of them are activity-oriented, viz., a process is essentially 1113

2 Stefanie Kethers seen as a series of tasks or activities, whose control flow is defined by logical relationships. Examples include the event-driven process chain (Keller et al., 1992), which is part of the ARIS framework (Scheer, 1998), or the IDEF family of process modelling languages (Menzel and Mayer, 1998), or even UML (Fowler and Scott, 1999), and many others (for an overview see e.g. (Kethers, 2000)). These methods however provide no way of dealing with relevant softer aspects of a cooperation process, viz. goals, information flows, and coordination elements. In contrast, the i* framework (Yu et al., 1996) describes the process stakeholders goals and dependencies on each other from the point of view of the depender, i.e., the person who depends on others to fulfil her own goals. Yu s approach consists of a strategic dependency model for expressing the actors external dependencies on each other, as well as the strategic rationale model that describes actors internal rationalization processes that underlie these dependencies. Another approach, described by Schäl (Schäl, 1996) and based on the Action Workflow (Medina-Mora et al., 1992) describes a cooperation process as a network of interactions between process customer and supplier that represent the coordination structure of the process. These interactions follow a four-step pattern of request, commit, perform, and evaluate. Request and evaluate are performed by the customer, whereas the supplier is responsible for commit and perform. The overall goal of the process is customer satisfaction, hence, the process is seen from the perspective of the customer. Finally, a method for describing a cooperation process as a series of information flows has been described by (Nissen and Jarke, 1999). The method captures information flows between the process stakeholders in terms of source and target actors, information flow content, media used (e.g., telephone, informal document, or ), and information flow quality (e.g., too slow, too fast, good) as perceived by the recipient of the information. Overall, each of the existing methods described above focuses on some aspect of the cooperation process activities, goals, customer-supplier relationships, or information flows. None of them covers all of these aspects, but all of them are relevant for cooperation processes. We have developed a methodology for modelling and analysing cooperation processes that is based on the integration of these methods as the set of interrelated, relevant perspectives on the process. 3. A METHODOLOGY FOR MODELING AND ANALYSING COOPERATION PROCESSES 3.1 Co-MAP Perspectives This section describes the integration of the four perspectives presented in the previous section. All of them are relevant for modelling the process, as each represents a set of questions that need to be asked and answered in a cooperation process. Figure 1 shows these perspectives and their interrelationships. The strategic perspective is based on Yu s strategic modelling approach as described e.g. in (Yu et al., 1996) and contains goals and dependencies that are relevant to the process and particularly to its stakeholders. It answers questions such as why should we cooperate?, what are our goals in the cooperation?, what do we need to reach our goals?. Note that different stakeholders goals can be (and often will be) contradictory. The activity-oriented perspective represents an implementation of the strategic issues into a bird s eye view of the process as it is intended. It represents mainly activities and their logical interrelationships. Many organizations already have activity-oriented process representations, e.g. for quality management purposes. The representation of the activity-oriented perspective is similar to the event-driven process chain (Keller et al., 1992). The service-oriented perspective describes processes as relationships between customers and suppliers, using an Action Workflow-style representation (Schäl, 1996), thus decomposing the process into its coordination structures. It answers questions about the coordination structures of the process, e.g. who owes me something, or who is waiting for me to do something. 1114

3 Capturing, Formalising, and Analysing Cooperation Processes: A Case Study The information flow-oriented perspective documents the communication flows between process stakeholders, together with their media and quality. It reflects the workload of the individual process stakeholders. In this respect, it implements the coordination structures described in the service-oriented perspective. Relevant questions include who do I need to talk to, or what is the impact of the process on the individual stakeholders workloads?. The information flow-oriented perspective is based on the approach described in (Nissen and Jarke, 1999). Figure 1: The four perspectives of cooperation process modelling Besides these different modelling perspectives, we have considered the representation of the different stakeholder perspectives to be of great importance. Process stakeholders often have very different conceptions of other stakeholders and their work: work has a tendency to disappear at a distance, such that the further removed we are from the work of others, the more simplified, often stereotyped, our view of their work becomes (Suchman, 1995). In addition, the question of informal vs. formal representation of the process needs to be resolved. An informal representation means that the stakeholders can contribute directly to the development of the process representation. This reduces the possibility for misunderstandings in the transfer of information from the process stakeholder to the process representation. On the other hand, a formal representation of the process enables a systematic analysis. We have therefore decided to employ a representation method that is easily understandable and intuitive, but has a defined semantics and can be mapped to a formal representation fairly easily. The resulting formal models can then be analysed in a systematic fashion. 1115

4 Stefanie Kethers 3.2 Co-MAP procedure Co-MAP defines a four-step model for capturing, formalizing, mapping and analysing cooperation processes which is orthogonal to the four modelling perspectives described above. Figure 2 shows the four steps and their interrelationships. More detail about the model can be found in (Kethers, 2000). Figure 2: Co-MAP procedure 1. Capture informal process representation. The first step of the methodology is to capture the as-is process, focusing on the process stakeholders perceptions of the process, their workload, and the problems occurring in the process. To achieve this aim, a group session with participants from all departments and groups involved in the process is performed. During this group session, the process stakeholders develop one, or, if possible, several informal process diagrams depicting the information flows, their contents, media, and perceived shortcomings. Each process diagram should represent a process instance (scenario) as it occurred in reality, shown from the perspective of one or more process stakeholders. If there are two or more stakeholders involved, the process diagram is considered to represent those stakeholders shared vision of the process. It is important that the facilitator encourages discussion about the scenario among the process stakeholders, and that the discussion is recorded in great detail, as the path to reaching the shared vision is crucial to understanding the process. 2. Formalize informal representation. Once the informal models have been developed, they are mapped to formal models representing the information flow perspective. Each formal model is expressed in the knowledge representation language Telos (Mylopolous et al., 1990) and needs to comply with its meta model that defines the concepts, relationships, and constraints of the model. 1116

5 Capturing, Formalising, and Analysing Cooperation Processes: A Case Study The meta model is also expressed in Telos, and both model and meta model are stored in ConceptBase (Jarke et al., 1995). The mapping can be done manually, but as this is a fairly tedious and error-prone process, a basic graphical editor, Ikarus, has been developed. Ikarus allows the user to draw an informal process representation, and automatically generates the corresponding, syntactically correct, meta model compliant Telos representation. 3. Derive formal models representing the different perspectives. First versions of the formal models representing the activity-oriented, service-oriented, and strategic perspectives, respectively, are derived from the formal model developed in step 2. For each perspective, a meta model as described in step 2 exists. These meta models are integrated into a shared meta meta model that in turn describes the concepts, relationships, and constraints of the four meta models, and is used to guide the derivation process. The derivation is a semi-automatic process, and user input is requested where necessary. Additional information, e.g. from user interviews, the group session minutes, or organizational documents, can be used to enrich the resulting models. 4. Analyse models. The formal models can then be analysed with respect to a catalogue of process quality criteria relating to operational and strategic aspects of the process. A set of about 80 queries formulated in Telos and corresponding to these process quality criteria, is provided (Kethers, 2000). Some of these queries analyse the individual perspectives, e.g. by finding incomplete workflow loops in the service-oriented perspective, or by counting the number of information flows on volatile media. Other queries examine cross-perspective issues, such as goals that are not being served by any activity in the process. Each of the four steps is supported by two additional sources of information, shown in the leftmost and rightmost parts of Figure 2. First, as described above, there are the formal meta models describing the individual perspectives, and the integrated meta meta model that describes the interrelationships between these meta models. Together, these models define the semantics of the informal models, thus guiding the formalisation and the derivation of the different perspectives from the source model. Second, additional information about the company (e.g., organisational charts, process flowcharts, sample documents used in the process, etc.) are used to support the four steps. As both the formalization and analysis depend on the input provided by the process stakeholders, the results from steps 2-4 are presented to the stakeholders, and open issues, corrections, or criticism are incorporated in the final results. If necessary, further information can then be gathered to augment the models, e.g. by means of interviews or additional sessions with some or all of the process stakeholders. In this paper, the focus is on steps 1 and 4, i.e., capturing and analysing the process. The other steps are described in more detail in (Kethers, 2000). 4. CASE STUDY 4.1 Research Design This section describes the application of the Co-MAP methodology in an industrial case study. The case study took place at a company that has been very successful in its market. The company focuses on new product development: once a new product idea has been judged feasible (in a technological and an economic sense), a new line of business (LOB) is formed, The company thus has a matrix structure, with several relatively autonomous lines of business, and several central internal suppliers, e.g. training & documentation, or the design department. Due to its explosive growth, from 2 employees in 1988 to about 135 employees in 1998, the company had started to experience some problems with its new product development process, and needed an evaluation and recommendations on how to improve the process. 1117

6 Stefanie Kethers Figure 3: Informal Process Diagram The case study consisted of a group session, which was held at the company, the formalization and analysis of the process diagrams resulting from the group session, and a presentation and discussion of the analysis results to all people involved. Before these group sessions, we collected and examined some information related to the company and its business, e.g. organizational charts, product descriptions, etc. We also discussed the list of participants with the person who had contacted us about the analysis. The group session had eleven participants. Eight of the participants were employees of the company, including employees of central departments (IT, design, documentation and training), as well as employees from two different LOBs, Sealing, and the newly established CUS. The Sealing LOB s main business is the optical inspection of O-rings, and the CUS LOB develops customerfocused products and services ( CUS stands for Components and Solutions ). In addition, three researchers from the Information Systems Group acted as observer-as-participants. One of the researchers facilitated the session, while the other two recorded the minutes of the session and any ensuing discussions. This type of group session was not part of the employees' normal work. 4.2 Performance of the Case Study In the group session, the participants decided to split into two groups, each representing one LOB. Each group consisted of employees of the LOB, together with one or two employees of central departments. Each group then developed an informal process diagram that described a concrete product that had been developed. Hence, each diagram represents a specific scenario. In addition to the 1118

7 Capturing, Formalising, and Analysing Cooperation Processes: A Case Study two LOBs, the two representatives of the design department, which acts as an internal supplier to all LOBs, decided to develop their own process diagram, which also describes a concrete instance of the product development process. Figure 4: Different perceptions of the design department in the information flow perspective Figure 3 shows the informal process diagrams developed by one of the two LOBs. Each rectangle represents an organizational unit, with the dark rectangles representing external units, e.g. external suppliers. The dark heart shape in the middle of the diagram also represents an external unit, viz. the customer. Information flows are represented by arrows and annotated with a textual description of the contents of the information flow (e.g., product order, product specification), and graphical symbols representing the information flow medium or media (e.g., telephone, informal document, spoken, ), as well as the quality of the information flow (e.g. too slow, too fast, good), as perceived by the recipient of the information. These graphical symbols carry well-defined semantics and are mapped to attributes of the formal models during the formalisation process. The set of graphical symbols is customisable in that new symbols can easily be added or existing symbols be changed in their meaning as long as the new or changed meaning is propagated to the formalisation process. Additional graphical symbols that are not mapped into the formal models can be used to describe the organizational units and the way they are perceived in more detail. For example, the image of a 1119

8 Stefanie Kethers factory was pasted to the organizational unit representing the manufacturing department, and another image, depicting a judge, was attached to the management unit. (At another company, the rectangle representing the CEO was even embellished with a dentist symbol, a clear expression of the process stakeholders view of meetings with him). Note that these additional symbols do not have a welldefined semantics; their interpretation is strongly situated and relies on tacit knowledge and cultural context. The resulting informal process representations were then mapped to formal models expressed in Telos and stored in ConceptBase, as described in section 3. These formal models, depicting the different modelling and stakeholder perspectives, were then analysed with respect to different quality criteria. In this paper, we will focus on the information flow and service-oriented perspectives, as, in this case study, they revealed the most interesting aspects of the process. Information flow perspective. Comparison of the different stakeholder groups information flow models indicated that there were misconceptions of others (esp. the design department s) work. Figure 4 illustrates the contrast between the CUS and Sealing LOBs views and that of the design department. The CUS LOB considered the interaction with the design department to be fairly simple and straightforward, as shown in the left part of Figure 4. There is one bi-directional information flow with the project manager, and one flow from the design department to the documentation and training group. Both information flows carry graphical symbols expressing the perceived lack of quality: the tortoise expresses the fact that the information flows too slowly from the design department to the project manager, and the shopping cart attached to the other information flow represents the fact that the documentation and training group has to put a large amount of effort into getting the information from the design department. The Sealing LOB s view contains more interactions between the design department and other organizational units than the newly established CUS group s view does, but also considers six of those information flows two from the design department, three to the design department, and one bi-directional flow between design department and an external design unit to be unsatisfactory. In particular, interaction with customer service, and external design units is considered unsatisfactory both ways, whereas the purchasing department is deemed to be too slow in notifying the design department of delivery times and arrival of ordered goods. Not surprisingly, the Sealing LOB considers its only information flow to the design department consisting of a one-time task description as good enough and is unhappy with the slow flow of information about the status of the task back from the design department. The design department s process diagram, shown in the upper half of Figure 4, tells a different story, however. It shows 12 arrows, 7 of which represent more than one information flow. Most of the information comes from different developers, and represents problems with, and modifications of the original product specification. From the design department s perspective, the incoming information consists of bits and pieces of relevant information that often arrives in an untimely fashion. Furthermore, each of the different LOBs, and often also different developers working for the same LOB, have different ways of working, which means that the design department has to be highly flexible and adaptable to be able to cope with different requirements. In addition, the design department depends on other units, both internal and external, and communication with them was at least partly perceived as problematic (as evidenced by the tortoise and thumbs down symbols on the upper right side of Figure 4). A more general problem that became visible in the information flow perspective is that most of the company s communication occurs in spoken form, in a spontaneous, ad hoc fashion. This means that information is highly volatile, and knowledge resides mostly in the employees heads. Lack of written process specifications aggravates this tendency for informal communication. In addition, the company recruited mostly young graduates without much previous work experience, which meant that employees had very little knowledge of what was expected of them when they found themselves in project leader roles. Together with the lack of process specifications and increased ad-hoc communication, this resulted in the fact that each project leader had their own way of working in a project, which created more difficulties for the central departments, e.g. the design department. Our 1120

9 Capturing, Formalising, and Analysing Cooperation Processes: A Case Study recommendations therefore included to provide training to the new project leaders, and to support more uniform ways of working with other departments. Figure 5: Service-oriented perspective (excerpt) Service-oriented perspective. Mapping of the information flow-oriented perspective to the serviceoriented perspective revealed communication gaps in the triangle formed by customer, sales, and development departments. In the case of this company, the communication worked particularly well between the customer and the development department the customers tended to speak to the developers directly about modifications or additions to the product. On the other hand, the developers did not pass information about these modifications on to the sales department and/or management, so that the cost and price calculations could not take them into account, and customers would be charged too little. Figure 5 illustrates this problem, which is not easily visible in the information flow-oriented perspective, where missing information flows are only recorded as perceived by their recipients. As the service-oriented perspective shows the overall structure of the process in the shape of customer/supplier relationships, however, missing information flows can be detected even though they are not perceived as missing by their recipients. To alleviate the communication problem, we therefore recommended increased communication and information sharing between the developers and the sales department during the whole process. Note that this is clearly a social process that can be encouraged and supported, but not enforced. The analysis results, recommendations, and their basis in the formalisation were presented to the process stakeholders who participated in the group session. The process stakeholders reaction was very positive; the analysis was considered to be correct, and participants were pleasantly surprised that the real problems had surfaced. Before, they had only been aware of the fact that something was going wrong in the process, but could not pinpoint the actual problems. Most of the suggestions to improve the process that we made were also accepted and later implemented to some extent. 4.3 Lessons Learned from the Case Study The case study reported in this paper confirmed several of the considerations on which we based our methodology. We found that different stakeholders indeed have fairly different views of the same process (this comes as no surprise), and that it is important to let all stakeholders have their say. As described in (Suchman, 1995), the perception of other stakeholders work is often wrong and leads to misunderstandings and conflicts that can be very unproductive. The problem with these misunderstandings and conflicts is that they are very often below the surface of the process. Thus, they inhibit the cooperation, but are very difficult to detect and resolve. The participants perceived the way of capturing the as-is processes as very intuitive, and also accepted and understood most of the formal models that we showed them, the only exception being the service-oriented models. To the participants, the service-oriented perspective was a very novel way of representing and looking at processes, and they needed detailed explanations to understand it. 1121

10 Stefanie Kethers We found that all four perspectives are necessary and relevant, because problems and bottlenecks that are hidden in one perspective often surface in another, and, generally speaking, it is not known beforehand where the problems will become visible. The formalization of the informal process diagram and the mapping of the resulting information perspective model into formal models representing the other perspectives were thus very helpful to the analysis. In the case study reported here, e.g., the fact that information flows are highly volatile became visible in the information flow perspective. The missing communication between development and sales departments, however, only surfaced in the service-oriented perspective. The case study also indicates that Co-MAP s procedure for capturing the as-is processes is useful: the process stakeholders quickly generated comprehensive process diagrams, and the ensuing discussion during creation of the process diagrams and afterwards, when different stakeholders diagrams were presented to the other participants, provided the foundation for a shared view of the process. Both informal and formal models of the process were thus important for gaining an understanding of the process and its shortcomings. 5. CONCLUSION This paper describes the application of Co-MAP, a methodology for capturing, formalising, and analysing cooperation processes, in an industrial case study. In this case study, the process capturing, as well as the mapping of the informal process diagram into the service-oriented and the information flow-oriented perspectives, were very useful. As described in (Kethers, 2000), further industrial case studies dealing with new product development have been performed at two other small companies. Another, more comprehensive case study dealing with the evaluation and redesign of a medium-sized company s complaint management process (Kethers and Schoop, 2000), and a fifth case study on engineering change management at the same company, have been performed as well. In addition, the transferability of Co-MAP to other contexts has been demonstrated in non-industrial settings. In one case, the communication and cooperation structures in a large, heterogeneous humanities research project have been captured and analysed, and in another case, the communication and knowledge exchanges between staff and volunteers have been captured for a women s non-profit organization as part of the requirements engineering process for the introduction of a knowledge management system. In all cases, Co-MAP was perceived as very useful for detecting the real problems and possible solutions, and participants felt that they were finally getting to the heart of the issues that bothered them. In particular, the participants felt a kind of ownership for the process diagrams, so that they were happy with the analysis results and our suggestions for improving the process. The work described here deals only with static aspects of cooperation processes, snapshots of a process at a given point in time. This is sufficient for many cases: Once changes are made to a process model representing a given perspective, e.g., the impact of theses changes on the other perspectives can be examined by mapping the changed model into the other perspectives. Often, however, a simulation of the cooperation processes under consideration would be useful when highly dynamic factors need to be examined. Further development is therefore currently being undertaken to extend Co-MAP by a dynamic component for a dynamic simulation of the development of trust in social networks (Gans et al., 2001). 6. REFERENCES Buse, H.P. (1997). Kooperationen. In: Betriebswirtschaftslehre der Mittel- und Kleinbetriebe. (Pfohl, H.-C., ed.). 3rd edition. Erich Schmidt Verlag, pp Fowler, M. and K. Scott (1999). UML Distilled: A Brief Guide to the Standard Object Modeling Language. 2nd edition. Addison-Wesley. Gans, G., M. Jarke, S. Kethers and G. Lakemeyer (2001). Modeling the Impact of Trust and Distrust in Agent Networks. In: Proceedings of the 3rd Workshop on Agent-Oriented Information Systems (AOIS-2001), Interlaken, Switzerland, June 2001, pp

11 Capturing, Formalising, and Analysing Cooperation Processes: A Case Study Jarke, M., R. Gallersdörfer, M. A. Jeusfeld, M. Staudt and S. Eherer (1995). ConceptBase - a deductive object base for meta data management. Journal of Intelligent Information Systems, 4(2), Keller, G., M. Nüttgens, A.-W. Scheer (1992). Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten (EPK). Technical Report No. 89, Institut für Wirtschaftsinformatik, University of Saarbrücken, Germany. Kethers, S. (2000). Multi-Perspective Modeling and Analysis of Cooperative Processes. Ph.D. thesis, Aachen University of Technology (RWTH Aachen), Aachen, Germany. Kethers, S. and M. Schoop (2000). Reassessment of the Action Workflow Approach: Empirical Results. In: Proceedings of the Fifth International Workshop on the Language-Action Perspective on Communication Modelling (LAP 2000), Aachen, Germany, pp Medina-Mora, R., T. Winograd, R. Flores and F. Flores (1992). The Action Workflow Approach to Workflow Management Technology. In: Proceedings of the Conference on Computer-Supported Cooperative Work (CSCW 92), Toronto, Canada, pp Menzel, C. and R. J. Mayer (1998). The IDEF Family of Languages. In: Handbook on Architectures of Information Systems. (Bernus, P., K. Mertins, G. Schmidt, eds.). Springer Verlag, pp Mylopoulos, J., A. Borgida, M. Jarke, and M. Koubarakis (1990). Telos: Representing Knowledge About Information Systems. ACM Transactions on Information Systems, 8(4), Nissen, H. W. and M. Jarke (1999). Repository Support for Multi-Perspective Requirements Engineering. Information Systems, 24(2), Ramesh, B., and A. Tiwana (1999). Supporting collaborative process knowledge management in new product development teams. Decision Support Systems, 27 (1), Schäl, T. (1996). Workflow Management Systems for Process Organisations. Lecture Notes in Computer Science vol Springer Verlag. Scheer, A.-W. (1998). ARIS. In: Handbook on Architectures of Information Systems. (Bernus, P., K. Mertins, G. Schmidt eds). Springer Verlag, pp Suchman, L. (1995). Making work visible. Communications of the ACM, 38 (9), Yu, E. S.K., J. Mylopoulos and Y. Lespérance (1996). AI Models for Business Process Reengineering. IEEE Expert: Intelligent Systems and Their Applications, 11(4),