Collaborative Practice-oriented Business Processes - Univ. Nantes

Download PDF
1 downloads 62103 Views 261KB Size Report
Comment
case of these BPs, process support need to co-evolve with process execution itself, and therefore ... from transactional business processes (BP), at the operational level to other types of .... (Steve Jacobs from. Apple Computers as cited by [5]).
Collaborative Practice-oriented Business Processes Creating a new case for Business Process Management and CSCW synergy

Olivera Marjanovic

Hala Skaf-Molli, Pascal Molli, Claude Godart

BIS Discipline, Faculty of Economics & Business University of Sydney Sydney, Australia [email protected]

ECOO Team LORIA, INRIA-Lorraine Nancy, France {skaff-molli, molli, godart} @ loria.fr

Abstract—In very recent times, organisations have started to shift their focus from highly standardised operational business processes (BPs) to other types of processes that cannot be easily replicated due to the knowledge, skills and creativity of people involved. Consequently the field of Business Process Management (BPM) has gradually evolved to now include four different, but equally important components: strategy, people, processes and technology. The renewed interest in process-related knowledge and collaboration has opened a new case for possible synergy of BPM with CSCW (Computer Supported Cooperative Work). The paper argues that the key to this synergy lies in the field of Knowledge Management. The paper introduces the knowledge dimension of BPs and uses it to determine how collaborative processes, in particular practice-oriented BPs, differ from other types of organizational processes. The paper argues that in the case of these BPs, process support need to co-evolve with process execution itself, and therefore could be also considered as an ever evolving, “organic” system, creating a new set of interesting research and practical challenges in the future. Keywords: Business Process Management; Knowledge Management; CSCW; Practice-oriented business processes

I.

INTRODUCTION

While looking for new opportunities for competitive differentiation, organisations are starting to shift their focus from transactional business processes (BP), at the operational level to other types of processes that cannot be easily standardised, replicated and acquired by their competitors , due to human knowledge, experience and creativity. As knowledge processes, such as co-creation, sharing and transfer of knowledge, assume collaboration, there is an increased interest in the collaborative aspect of BPs. “Visionary companies will proactively foster collaboration, share knowledge and organise around customer-centric processes. All organisations will eventually move in this direction, but risk losing competitive advantage if they delay too long” [1]. Business processes or processes in general have been investigated by both Business Process Management (BPM) and Computer Supported Cooperative Work (CSCW) fields for many years, always from very different standpoints and with directly opposing underlying assumptions about the nature of work practices in an organisation. “As the years have passed, and the arguments have raged back and forth, little compromise has been south and little afforded” [2]. The BPM “camp”,

represented by the workflow community, has remained mainly focused on the inflexible coordination, while the CSCW community has placed the main emphasis on flexible collaboration. However, the very recent developments in the field of BPM open new opportunities to bring these two fields closer than ever before. While the term BPM is still most frequently used to describe technologies for business process (BP) automation, these days, business leaders are starting to adopt a more holistic view of BPM. This is best described by a recent report published by Gartner: “the BPM discipline employs methods, policies, metrics, management practice and software tools to discover, model, simulate, execute, analyse, optimize and govern ongoing adjustments to processes toward the goal of improving business agility and operational performance” (pg.2) [3]. BPM has evolved to include four equally important components: strategy, people, processes and systems. These recent developments in BPM industry have created a need to better understand processes beyond the operational level, in turn, has prompted researchers to follow the industry lead. However, this has also resulted in a wide variety of BPs that have been labeled as “collaborative”, for one reason or another. Even highly structured, operational processes are considered to be collaborative, because they are designed in a collaborative manner. Obviously, there is a need to better understand the nature of collaboration in different types of BPs and what makes business processes truly collaborative. This problem has traditionally been a domain of CSCW. However, in this field collaboration is not typically investigated in the context of business processes. Thus, once again, there is a need to “reopen” the case for possible synergy of BPM and CSCW fields. Rather than repeat the past attempts and explore this synergy, yet again, either from the BPM or CSCW perspectives, it is necessary to step back, and look at it from a completely different pespective. In this paper, we argue that the field of knowledge management (KM) offers this new perspective that can be used to identify and describe types of BPs that require a real synergy of BPM and CSCW research and practice. Even more, this synergy creates opportunities to advance both fields and provide added value to organisations. Why KM? First of all, there is overwhelming evidence coming from industry that collaboration processes are naturally

intertwined with knowledge processes. “In the past, firms have relied heavily on closed, hierarchical approaches to producing and harnessing knowledge. Increasingly, though, knowledge is the product of networked people and organisations looking for new solutions to specific problems. ...Collaboration, publication, peer review, and exchange of precompetitive information are now becoming keys to success in the knowledge-based economy.” (pg. 153) [4] Furthermore, knowledge is considered to be an integrated part of any business process as process knowledge is inseparable from individuals performing those processes. It is a combination of experience, context, interpretation and reflection, and involves more human participation than information [5]. At the same time, business processes provide a much needed approach to address the well known problem of KM field, related to the overall purpose of KM activities in an organisation. “Knowledge Management activities are all over the map… But no one claims the big question Why?” [5]. In fact, this “Why?” question, or rather, the lack of it, has been identified by a number of researchers, as the key flaw of knowledge management today [5]. In essence, BPs integrate knowledge and action, that in the case of complex, knowledge intensive processes need to be collaborative. This is because these complex processes are typically cross-functional and no single individual in an organisation has all the knowledge and expertise required by these BPs. More importantly, these processes need to bring together and reconcile different, and often opposing, perspectives held by different functional units, or even organisations, in the case of cross-organisational processes. This could be only achieved through collaboration. The main objective of this paper is to critically analyse a possible synergy of BPM and CSCW fields from the KM perspective. The special emphasis is placed on knowledgeintensive, practice-oriented collaborative business processes that could especially benefit from such synergy, more than any other types of BPs. We also illustrate how this type of BP creates a need for a very different type of support than what is currently available, certainly in the domain of BPM. The paper is organised as follows. Section 2 gives a brief overview of the latest, relevant development in BPM, KM and CSCW and fields. Section 3 introduces a theoretical framework used to identify and analyse the knowledge dimension of three different types of BPs. Section 4 uses the same framework as the new “viewing platform” to investigate the nature of collaboration in all three types of BPs. Finally, Section 5 describes the main characteristics of practice-oriented knowledge intensive collaborative BPs defining a case for better synergy between BPM and CSCW fields and a new type of process support system. II.

RELATED WORK

This section gives a brief overview of recent developments in the area of BPM, KM and CSCW, relevant for this research. In particular, we consider coordination and collaboration aspects as they have been the key points of differentiation between BPM and CSCW communities.

A. BPM: traditional and emerging views According to the leading business analysts, Business Process Management (BPM) is now perceived as the number one business priority by CIOs world-wide [3]. There is no doubt that companies have always been looking for new ways to support and improve their work, with and without technology. Over many years, methodologies and tools have evolved with our improved understanding of human work practices as well as with emergence of new technologies that have made new work patterns possible. This is especially the case with the field of BPM. Over the last two decades, it has evolved from various process-related theories, and practices such as Business Process Reengineering (BPR), Total Quality Management (TQM), Lean management, Six Sigma, supply chain management etc. as well as various process-related technologies such as workflow management systems, enterprise integration systems and, since recently, technologies for web-service integration and management. Compared to its predecessors, BPM represents a fundamental change in thinking and organisational practice that focuses on business value creation via ongoing business process (BP) improvement and innovation supported by BPM-enabling technology [3]. Rather than a single project with its start and end dates, BPM is now perceived as an ongoing process of organisational evolution and improvement based on reflection-in-action. Contrary to the popular belief, BPM is not an updated version of BPR [6] as it often perceived by the people outside of this discipline. The main focus of BPM is no longer on process automation and radical re-design. Rather, the focus is on ongoing management and improvement of all organisational processes. The emphasis is placed on business value creation (not necessarily cost-cutting), making sure that processes contribute towards organisation’s strategic goals. Most importantly, BPM now considers various BP-related strategies organisations apply to leverage human expertise, knowledge and potential to innovate, while using the available technology in the best possible way. “BPM is an ongoing process of understanding, designing, executing and optimization of enterprise-wide business activities that incorporate people, processes, systems and strategy” [7]. The relationship among these components is simple to describe but not simple to implement in practice. Thus, strategy defines how organisations deliver value to their customers. Organisations implement their strategy via business processes i.e. coordinated activities of people with different responsibilities and obligations, as defined by their organisational roles. The role of technology is to help people to execute ( and not necessarily fully automate) their processes and, ultimately, make them more effective. In spite of the holistic view of BPM, promoted by business leaders and led by industry, the current BPM research still lingers behind, as it remains focused mainly on BPM technology and not enough on the other three components. This often includes a “very mechanistic view of business processes, mainly at the operational level” [8]. The same criticism applies to the vendors and developers of BPM systems. BPM systems are often equated with workflow

management systems. In fact, “many business analysts still do not differentiate between BPM and workflow systems, or treat BPM systems as providing workflow management capabilities combined with enterprise application integration”. [8] In essence, workflows are designed to specify, execute, manage, monitor and streamline business processes by allocating the right task to the right person at the right point of time, along with the resources needed to perform the assigned task [9]. They have been always criticized by the CSCW community on the basis of their predefined models and their inflexible coordination mechanism (e.g. [10]). However, in spite of their limitations, these systems continue to be used by numerous companies in many different domains. On the positive side, Dourish [2] argues that workflow technology can be considered as “the technology of accountability” as well as a visualisation technology, helping organisations to better understand their processes.

unstructured processes was best suited for the traditional “view” of BPM, as the ability to automate BP was directly related to BP structure or the lack of it. Section 3 illustrates how process-related knowledge can be used to classify business processes in a different way in order to facilitate better understanding of the nature of collaborative activities within each process type.

It is important to note that workflow technology is best suited to support highly structured processes at the operational level. However, business practice confirms that these highly structured processes cannot be used for competitive differentiation. This point is also illustrated by [8] “...the nonproprietor, idealised business processes tend to evolve towards a public definition and don’t directly afford competitive differentiation” (pg. 6).

B. Knowledge Management (KM) Over the last decade, the field of knowledge management has also evolved. For many years, KM research and practice followed the so-called Technology-Push model of KM [14]. In fact, this is still the most dominant research and technology paradigm in KM. It is based on the idea that technology could be used to capture, codify, store this knowledge and then transfer (send) it to a user who needs it at a particular point of time. However, there is a strong evidence that, in spite of extensive investments and very sophisticated systems, this approach fails to deliver business value to organisations [15].The fundamental problem is in the underlying, mechanistic, information-processing model of KM [14]. This widely used model assumes that technology can be used to push the right knowledge to the right people at the right point of time. However, as Newell at al. [16] pointed out, ICTs marketed as KM systems obscure and deny the socially constructed nature of knowledge.

Companies are now interested to move beyond operational BPs, because the efficient execution of operational BPs is now considered to be the necessity, and no longer an opportunity for competitive differentiation. They are now interested to better understand processes that cannot be standardised and replicated due to the knowledge and experience people bring to these processes. Most importantly, they are now interested to better leverage human potential and creativity for ongoing process improvement done by domain experts, i.e. people who are actually involved in these processes. “It doesn’t make sense to hire smart people and tell them what to do; we hired smart people so they could tell us what to do.” (Steve Jacobs from Apple Computers as cited by [5]).

On the other hand, collaborative creative, knowledgeintensive BPs confirm the relevance of, and the need for, the emerging “Strategy-pull model of KM”. Essentially, “this model embodies organisational processes that seek synergistic combination of data and information-processing capacity of information technologies and the creative and innovative capacity of human beings” (pg. 15) [14]. In fact, in complex BPs, knowledge and action are integrated through the process of sense making and reflection. [17] “This is why the codification process for the richest tacit knowledge in an organisation is generally limited to locating someone with knowledge, point a seeker to him/her and encourage them to interact” [18].

Some of these knowledge-intensive processes are performed by individual employees such as, for example, design of a personalised version of a financial service to best suits the needs of a particular VIP customer. Other examples include collaborative processes such as design of a new marketing plan, design of a new product, even the meta-process of design of a new BP. Traditionally, some aspects of these processes been considered by the CSCW community, but necessarily in the business context and as business processes. This point will be revisited in the next section.

As already pointed out, a combination of BPM and KM fields helps to address another widely recognised problem of KM, that is related to the overall purpose of knowledge processes. Thus, BPM provides the much needed context for knowledge processes. People create, co-create, share, transfer and apply knowledge in the context of their everyday activities i.e. business processes they participate in, in order to achieve organisational goals and create value. In fact, BPs can be considered as knowledge-in-action or actionable knowledge.

It is becoming clear that, the holistic approach to BPM opens up new research & practical challenges created at the crossroads of strategy, people, business processes and technology. Some of them are certainly related to the collaborative aspect of business processes. One of the first tasks is to clarify what this term “collaborative BPs” really means. This requires a different classification of business processes, because the most popular ones are based on the process structure (see for example [11], [12] and [13]). Thus, the existing distinction between structured, semi-structured and

Hence, this paper reinforces the need to better integrate knowledge management with business process management. At the same time, it is important to recognise that this is a very challenging research problem. The relevant knowledge management literature confirms that “it is still not clear how to integrate knowledge management more thoroughly into business process management… connecting knowledge activities to core business processes is the second and more effective stage of knowledge management in an organization” [19]. Here, the term “core BPs” is used to denote standardised,

highly-structured, repetitive processes at the operational level (e.g. “revenue collection”, “purchase-to-pay” BPs). They are called core because they are needed for day-to-day business and without them a business organisation would not be able to function. However, this paper extends Smith and McKeen’s argument, by saying that it is not enough just to connect knowledge activities to core BPs, it is necessary to move beyond these processes and consider the other, more knowledge intensive processes. Section 3 offers a theoretical framework used to explain (rather than define) the knowledge perspective of three different types of business processes. C Computer Supported Cooperative Work (CSCW) – a process perspective The CSCW field has a long history of research and practice and has resulted in many different systems, tools and methodologies used to support collaborative activities in organisational setting or human collaboration in general. Even the most prominent BPM technology, workflow management system, has its origins in the CSCW field. In fact, workflow technology is considered to be “CSCW’s first child to reach the adulthood” [2]. Systems designed to support different aspects of human collaboration have been around for many years. Typically, they are categorised on the basis of the space/time dimensions into systems that support same/different time and same/different place collaboration [20] or simply as synchronous and asynchronous systems [21]. It is important to note, that not all CSCW systems are designed to support and incorporate a concept of a process that, in general, could be defined as a set of coordinated activities performed toward the same goal. Note that this generic definition does not make any assumptions about the nature of coordination. In order words, it does not assume that this coordination needs to be predefined or flexible/inflexible. However, a coordination perspective is the core concept that makes a set of tasks – a process. Thus, very often CSCW tools are designed to support individual collaborative tasks without any attempt to place them within the context of a process, they naturally belong to. Furthermore, CSCW field also considers collaborative activities outside of the formal organisational boundaries, governed by rules and policies. For example, very recent developments in the area of self-organising communities demonstrate strategies and tools for mass collaborative systems (see for example [2]). However, even those systems require a coordination mechanism in order to manage activities of their members and make any such as system functional and even viable. In order to explore possible synergy between BPM and CSCW field, in this paper we consider collaboration within the context of business processes, especially those that are considered to be knowledge intensive (e.g. design of a new marketing strategy). Among all CSCW systems, we choose to explore the process perspective of Group Decision Support

Systems, as they have been often used to support some aspects of practice-oriented business processes. Thus, when GDSS are analysed from the process perspective, it is possible to observe that most of them are designed to support what is, in fact, a high-level problem solving process. Typically, they provide tools for information gathering (e.g. electronic brainstorming), information organisation, analysis of different alternatives (e.g. alternative analyser, stakeholder analyser etc.), selection and evaluation of possible solutions (actions), as well as tools for collaborative writing and report generation. For an example of different tools used to support high-level tasks in a problem-solving process, see [22]. Obviously, tasks supported by GDSS are high-level problem solving tasks, independent from the context of a particular problem that needs to be solved. Consequently, these systems can be effectively used in many different problem-solving scenarios. However, the concept of a “task” in GDSS is very different than what is considered to be a task in a business process as they involve fine-grained, domain specific tasks. Furthermore, in general, BPs do not follow the same problem solving pattern as their main objective may not even be problem solving. In GDSS, collaborative problem solving sessions are prepared and guided by an experienced facilitator, usually in collaboration with the group leader and other participants. During the preparation phase, facilitator creates a session agenda that is, in fact, a high-level model of a collaborative problem solving process. Even though the high-level model may be the same for different sessions, the actual execution of high-level tasks will be different in each session. Thus, the same tools will be used in different ways and in different contexts. The same high-level tasks will be combined with different face-to-face tasks (e.g. group discussion). While participants have domain knowledge that facilitator may or may not have, facilitator’s experience and skills are considered crucial for coordination of individual collaborative efforts. Therefore, from the process perspective it is possible to observe that during the actual execution of a collaborative process, the facilitator is in fact in charge of coordination of different tasks making sure process progresses towards the goal of finding a solution for a particular problem. GDSS provide tools such as “Meeting Agenda”, however, coordination remains human-driven. Even though collaborative systems do log data generated during collaborative sessions and even could produce selfdocumented meeting report, the purpose of this form of “process log” is very different from process logs in typical BPM systems. In collaborative systems, these reports are typically used to support the reflection phase of the problem solving process, describe the action plan in more details or serve as “organisational memory” used to provide continuity between different sessions. On the other hand, in typical BPM systems, process logs could b used to analyse process instances and in some cases, even derive new process models. Finally, practice-oriented BPs involve both collaborative and individual tasks that need to be coordinated in a way that

facilitate knowledge transfer and sharing among people involved in all different tasks within the same process, regardless of their collaborative nature. This also creates the need for seamless integration of different tools across different tasks by process participants rather than process specialists as well as integration of data to provide a “single version of truth” about process execution to all process participants. These issues have been traditionally considered within BPM systems rather than CSCW systems. III.

UNDERSTANDING THE KNOWLEDGE PERSPECTIVE OF BPS

The field of KM offers many different definitions of knowledge. Thus, knowledge could be seen as an object, action, process, a result of reflection-in-action etc. [23], [24]. This paper starts from the basic concepts of explicit and tacit knowledge. Explicit knowledge can be written down or drawn and described to other people. Consequently, it can be organised, distributed and managed by technology. Note that the explicit knowledge requires the shared context. In other words, even though it can be documented, only people sharing the same context will be able to understand it and use it (e.g. operational manuals in an organisation). Good examples of explicit knowledge are various documented organisational policies and procedures. Typically, they define roles and responsibilities for different tasks. Policies are important from the normative (legal) perspective to protect the rights of all parties involved, organisation' as well as their customers'. Furthermore, organisational procedures are also used to define (prescribe) how things should be done. This is related to the concept of accountability, as described by [2]. Obviously this is applicable only to highly structured, repetitive, normatively regulated BPs where people are required to follow certain procedures (e.g. in hospital environment). But, there are certainly other, more creative processes that also count as business processes, as they also contribute to business value creation, even more than operational processes. In these processes policies can be only used to define roles and responsibilities but certainly, not to restrict people. “Consider an international bank – everyone would agree that the teller should not get creative with bank drafts. Tellers have very strict procedures (and systems) for handling money directly. On the other hand, try applying a rigorous procedural approach to those developing new trading instruments or those managing the bank’s largest corporate customers. They would rebel if everything they did fit within rigid computerised procedures developed beforehand” [25]. Thus, tacit knowledge are things known by people but usually not documented anywhere such as the know-how, understanding mental models and insights of an individual or disciplines [23]. Very often, tacit knowledge is very difficult to communicate, but could be externalised to some degree trough problem solving and “working things out”. Externalisation of tacit knowledge in an organization results in development of organisational practices. They evolve from the accumulated experience gained through reflection-in-action. Therefore, practices are examples of externalised tacit knowledge developed by the empowered

participants (i.e. knowledge workers) through their ability to make decisions and reflect upon their experience. Practice confirms that even in the case of highly prescriptive processes, people are likely to develop their own practices [8] with the accumulated experience. However, in the case of these processes, these practices are better described as competencies. In reality, all business processes combine to some degree both procedures and practices (i.e. explicit and experiential knowledge). Fig 1 depicts the theoretical framework that can be used to describe the knowledge dimension of different types of business processes. This is an extension of the framework previously introduced by [25]. Thus, highly repetitive, operational BPs have their procedural component much more prominent. Typical examples include the above mentioned core business processes. Among other things, the procedural component defines the process structure i.e. individual tasks and their order in a particular process. It is typically represented by process models. In fact, technology developers often rely on standardisation and predictability of organisational procedures to design BPM solutions that store and execute BP models. This is why the existing solutions remain the most suitable for the operational business processes. In the case of operational BPs the main emphasis is placed on speed, quantity (no. of transactions) and control via standardised procedures. Traditional management disciplines have developed a wide of variety of methods and tools that can be used to measure the performance of these processes (e.g. process throughput, work-in-process and cycle time). Knowledge

Knowledge Explicit Procedures (speed, quantity, control)

Procedureoriented BPs (e.g. purchaseto-pay BP)

Tacit

Processes

Case-handling BPs (e.g. customerfacing BP)

Practices (experiential tacit) (quality, agility)

Practice-oriented BPs (e.g. creative & emergent BPs)

Figure 1. The knowledge dimension of BP

On the other hand, in the practice-oriented BPs, their practice component is much more prominent than the procedural component. It is related to the execution of individual tasks rather than process structure. In other words, people develop new experiential knowledge while participating in creative tasks and problem solving activities. Some of these

tasks are collaborative while others are performed by individual employees. The explicit knowledge comes in the form of policies that are used to help the participants to stay within the normative/legal boundaries of their organisations. However, they are not used to prescribe their behaviour and restrict the execution patterns. In the case of practice-oriented BPs the main emphasis is placed on quality, on satisfying customer’s needs, finding creative solutions and on creating better customer-relationships. The third category of BPs, called case-handling BPs also combine procedures and practices. Typically, these are customer-facing processes. While in most cases, a customerfacing officer will follow procedures (models) predefined for different typical customer types, more and more organisations are interested to offer personalised, value-added versions of business processes to some of their high-value customers. These processes are defined “on-the-fly” by an experienced, knowledgeable employee while »looking for the best way to satisfy customer needs«. Initially, case-handling BPs included only very complex processes such as, for example, “Registration of a new patent” in a government agency authorised to handle the intellectual property issues and processes. However, in recent times this category is emerging among other »mainstream« customer-facing processes, even those that have been considered, for many years, as procedureoriented BPs. This emerging trend is caused by at least two reasons: need to further differentiate their services in highly competitive industries that, from customer perspective offer very similar, if not identical services as well as emergence of new technologies, such as various solutions in the area of business intelligence (BI) that enable organisations to categorise their customers based on their “business value”. Therefore, standard »cases« are mostly based on explicit knowledge expressed via pre-defined processes for different customer types while the experiential knowledge comprises practices employees develop while handling the non-standard, even personalised cases of BPs. For more detailed discussion of case-handling processes and especially BI and BPM integration, see [26]. The next section will explain the relationship between process-knowledge and collaboration in all three types of BPs. IV.

UNDERSTANDING THE COLLABORATIVE ASPECT OF BUSINESS PROCESSES

Understanding what type of knowledge is created, used, transferred and applied in each type of BP enables us to establish the link between process-related knowledge and collaboration. First of all, it is necessary to acknowledge that the KM field confirms that the best way to co-create and transfer some aspects of tacit knowledge is via collaboration [5]. Although transfer of explicit knowledge could also involve collaboration, this type of knowledge could be shared by other means i.e. documented and even distributed by technology. Consequently, better understanding of tacit/experiential knowledge components in a particular BP, can help us to better understand its collaborative nature, especially if it requires

collaboration to ensure process execution. If this is the case we say that collaboration is an integral part of BP. Thus, procedure-oriented BPs involve predominantly the explicit knowledge specified by process models. Among other things, models define coordination patterns among different tasks, typically via control-flows. As models are not designed by domain experts, modelling requires knowledge transfer from domain experts (people who have the experiential knowledge) to process analysts that can only work with the explicit knowledge (expressed by models). This practice raises some issues related to the experiential knowledge that cannot be easily transferred. Consequently, process analysts often rely on documented organisational policies to create models that become explicit knowledge. However, business practice confirms that the so called “shadow” BPs often occur as the result of over-prescriptive but inefficient models (for an example see [6]. Furthermore, in the case of procedure-oriented BPs, experiential knowledge is created predominately via various exception handling situations. Exception handling activities may require collaboration to facilitate knowledge sharing. However, this type of collaboration is considered to be “outside” of the process, as it is not required to ensure process execution. In the case of case-handling processes, explicit knowledge is created while dealing with personalised instances of business processes. »People interpret rules and do what is best for a customer« [25]. While in some organisations this could be a collaborative process (e.g. a team of medical experts looking for a best treatment for a particular patient), it is often a »casehandling« (i.e. »customer-facing« officer) that is in charge of a particular process instance. Therefore, again collaboration is not considered to be an integral part of the process, as per previous definition. Even more, in some organisations, this knowledge is considered to be a source of competitive advantage for customer-facing employees (e.g. financial trading agents). Obviously, this will influence their willingness (or lack of it) to share this knowledge. Practice-oriented BPs involve components that are predominately experiential rather than explicit knowledge. For example, coordination among fine-grained tasks is completely human driven and cannot be predefined. Tasks emerge during process execution. Although this knowledge cannot be ever entirely captured and turned into BP models, some of its aspects could be documented and preserved in order to be reused to promote organisational learning. However, current research from the knowledge management field confirms that documented best practices, stored in organisational repositories (or memories) are rarely used [15]. Furthermore, most of these practice-oriented processes are collaborative in nature. In fact, collaboration is considered to be their integral part, for several reasons. First of all, these BPs cross functional and often organisational boundaries. In addition to different skill sets, different functional units bring different perspectives to the equation. These perspectives need to be understood, because shared meaning is a pre-requisite for any knowledge sharing and co-creation. Quite often this also means that it is necessary to reconcile different, often opposing

points of view. The best way to facilitate these knowledge processes is via collaborative activities. Furthermore, these are complex processes and it is impossible for one employee to have all required knowledge and information. Consequently, collaboration is considered to be an integral part of these processes, as it is required for process execution. The above critical analysis of different types of BPs confirms that, in spite of a current practice in BPM to label all types of processes as collaborative, only practice-oriented BPs are truly collaborative processes. The key component is their experiential knowledge that needs to be co-created, shared and transferred via collaborative knowledge processes. The following section describes some important requirements for the possible support of practice-oriented collaborative BPs. V.

POSSIBLE SUPPORT FOR PRACTICE-ORIENTED COLLABORATIVE PROCESSES

The following critical analysis of practice-oriented collaborative BP is founded in authors’ combined experience with different types of these processes accumulated over many years of research and professional practice in the areas of BPM, KM and CSCW, including real-life implementations of these processes. The main issues, described in this section, were identified in a series of focus group discussions. It is possible to say that these issues can be considered as a result of externalisation of authors’ collective experiential knowledge, via collaborative problem-solving with the main goal to describe practice-oriented BPs from several perspectives including possible technology support. As it is always the case with any experiential knowledge, the list is never complete, but could be used to raise some important issues and reopen the case for better synergy between BPM and CSCW fields. 

Coordination

In addition to collaboration, the coordination aspect is equally important even in highly creative processes. Thus, various activities need to be coordinated as they require organisational resources (including people’s time) and need to be oriented towards the same goal(s). However, coordination patterns emerge as people progress though the process. Rather than coordination of tasks, collaborative practice-oriented processes require coordination of knowledge processes. In essence, coordination is human driven rather than dictated by technology as it is the case with typical BPM systems. It is interesting to observe a new type of relationship between coordination and collaboration in these processes. Thus, coordination is defined through collaboration as people often need to agree when and how to proceed. At the same time, collaborative activities need to be carefully coordinated to ensure that they are all contributing to the same objective as required in a particular BP. 

Nature of knowledge processes

According to [23] knowledge processes in any organisation include creation, storage, reuse, transfer and application of

knowledge. In the case of practice-oriented BPs, collaborative activities facilitate knowledge creation and co-creation, transfer and application. As already pointed out, only some aspects of this knowledge could be documented to be used in other future process instances or to facilitate organisational learning. However, KM confirms that static repositories of best practices often turn into information junkyards [15]. Consequently, experiential knowledge is best reused in the future, via people who have acquired this knowledge in previous instances of the same or similar processes. 

Involvement of domain experts

Domain experts have the experiential knowledge required to complete practice-oriented processes. In fact, new practices are created with newly accumulated experience, though reflection in action. Consequently these processes should be guided, executed and driven by domain expects. Thus compared to the problem solving processes facilitated by an external facilitator, practice-oriented collaborative business processes are often self-facilitated processes. 

Concept of a BP “task”

“Traditional” BPM uses a concept of a task inherited from the system theory. Thus, BP tasks are defined by their input and output and types of processing performed within the task. In practice-oriented processes, a concept of a task needs to be preserved for several reasons. First of all, these processes combine collaborative with individual tasks that need to be separated. The existence of a task in a BP, enables process monitoring, not for the purpose of control, but to facilitate shared understanding of the process execution. Having in mind that these processes operate in a business environment, separation of different tasks is required in order to facilitate monitoring of key performance indicators that may be linked to individual tasks. At the same time, the very nature of task in practiceoriented processes is somewhat different from a typical task in a BP model and that makes process monitoring difficult to implement in practice. For example, even though in some domains coarse-grained, high-level tasks could be identified in advance, it is often very difficult to identify and sometimes distinguish among fine-grained tasks, especially in highly creative processes. The high-level tasks could indicate different phases of process execution that could be used to, for example indicate different skill sets for each coarse-grained task as they may be performed by different teams. However, fine-grained tasks emerge with process execution. Very often, tasks are even identified though reflection-in-action, after they have been completed and participants are given time to look back and reflect on the experience. However, it is important to keep track of tasks or at least decision made in order to facilitate reflection in action and help participants to learn from the experience. 

Decision making

Practice-oriented collaborative processes include both individual and collaborative decision making tasks and processes. Participants need support for situated decision making – situated because it is deeply imbedded in the context of a process being currently executed. This opens new

opportunities for possible application of various business intelligence tools that could be used to help users to “make sense” of current situation based on integrated company-wide data and make decisions. Notice, that ultimately, it is human intelligence not computer “intelligence” that is required to make decisions. In summary, it is possible to observe that in the case of practice-oriented processes, the main objective of process support shifts from coordination and scheduling of tasks to situated-decision making by individuals as well as groups. In this process, selection of the most appropriate tools for each fine-grained task needs to be left to domain experts creating new challenge of ad-hoc integration of different tools that need to appear seamless to the domain expert (end-user). This also means that the selection of tools, their combination and possible use also become experiential knowledge as people learn from the experience which tool to use in which context and how best to use it. However, just having a system that provides flexible coordination is not sufficient. Finally, effective support of practice-oriented collaborative BPs requires “organic” solutions i.e. systems that will continue to grow with user’s knowledge and experience without any programming intervention. Consequently, it is possible to conclude that any process support needs to co-evolve with the process itself. This process of co-evolution will ensure that tools are not prescribed and then used to restrict participants in the process. The latest developments in the area of wikis and semantic-wikis offer a very promising direction for future research because they have been used for dynamic knowledge sharing. Although this is still considered as emerging technology with a number of problems that are yet to be solved, the number of applications is rapidly increasing both within formal organisational settings (see for example [27], [28] and [29]) as well as self-organising virtual communities [2]. So far, applications of this technology appear mainly in the KM and CSCW fields while their use within the domain of BPM is yet to be seen. Research and practice in the area of collaborative, practice-oriented BP certainly provide an interesting domain for future research and development in this area, from the Information Systems (IS) as well as IT perspectives.

offers a theoretical framework that could be used to identify different knowledge components in three different types of business processes and then use them to explore collaborative aspect of each process. By investigating collaborative practice-oriented business processes, from the knowledge management perspective, this paper aims to advance the existing research and practice in the field of Business Process Management as well as to create a new case of better synergy between BPM, KM and CSCW fields. This paper argues that, in the case of these BPs, any possible support needs to co-evolve with process itself. This particular finding could open a new domain for possible applications of emerging collaborative technologies such as, for example, semantic-wikis. Our future work in this area includes further investigation of BPM, KM and CSCW synergy via more exploratory case studies in different domains and organisational settings. This research is expected to create new strategies, frameworks and tools to support organisations to better manage and support their collaborative, practice-oriented BPs. REFERENCES [1] [2]

[3] [4] [5] [6] [7] [8] [9]

[10]

VI.

CONCLUSION

New developments in the area of Business Process Management (BPM) are urging organisations to start to shift their focus from highly-structured, repetitive operational business processes to other processes that can be used as a basis for competitive differentiation. The key ingredients of these processes are human creativity, knowledge and experience that cannot be easily replicated and acquired by the competitors as it is the case with operational processes that are becoming more-or-less standardised. This trend has lead to the increased interest in collaborative BPs.

[11] [12]

[13] [14]

[15]

This paper illustrates that in order to understand collaborative BPs and how they differ from other types of BPs, it is necessary to analyse their knowledge dimension. The paper

Moore, C (2000): Process Knowledge, Workflow Management Coalition (available from http://www.wfmc.org). Dourish, P. (2001), “Process Descriptions as Organisational Accounting Devices: The Dual Use of Workflow Technologies”, Proc. of Group’01, Sept, Boulder, Colorado, USA, pg. 52 – 60. Gartner (2006), Gartner’s Position on Business Process Management, 16. February 2006, ID No. G00136533, Gartner Inc. Tapscott, D. And Williams A.D. (2006) Wikinomics: How Mass Collaboration Changes Everything, Portfolio, Penguin Group, USA Davenport T.H. (2004) Thinking for living, Harvard Business School Press, Massachusetts. Garner (2006b), Shadow Processes are the Dark Side of BPM, 8 May 2006, ID No. G00139489, Gartner Inc. Business Process Management Group (available from http://bpmg.org) McGoven, D. (2004) “An Introduction to BPM and BPMS”, Business Integration Journal, April. Workflow Management Coalition, WFMC Interface: Process Definition Interchange Process Model, 2001, available from: http://www.wfmc.org. Suchman, L. (1987). Plans and Situated Actions, Cambridge: Cambridge University Press. Keen, P.G. and Scott-Morton M. (1978): “Decision Support Systems: An Organisational Perspective”, Addison-Wesley, Reading, MA. Mohan, C. (1997): Tutorial: State of the Art in Workflow Management Systems Research and Products, Proc. of the 5th International Conference on Database Systems for Advanced Applications (DASFAA’97), Melbourne, Australia. Pava, C. (1983): Managing New Office Technology: An Organisational Strategy, Free Press, New York. Malhotra Y. (2005): Integrating knowledge management technologies in organisational business processes: getting real time enterprises to deliver real business performance, Journal of Knowledge Management, Vol. 9, No. 1. pp.7-28. Malhotra Y. (2004): Why Knowledge Management Systems Fail? Enables and Constraints of Knowledge Management in Human Enterprises, in Koenig & Srikantaiah (eds.), “Knowledge Management Lessons learned: What Works and What Doesn’t”, Information Today Inc. pp.87-112.

[16] Newell, S., Robertson, M., Scarbrough, H. and Swen J. (2002): “Managing Knowledge Work”, Palgrave. [17] Gartner (2006c): Business Process Management Leverages Organisational Knowledge to Create Better Business Value, 23 January 2006, ID No. G00136713, Gartner Inc. [18] Davenport, T. and Prusak, L. (1998): “Working Knowledge: How Organisations Manage What They Know”, Harvard Business School Press, Boston, Massachusetts. [19] Smith H. and McKeen, J.D. “Developments in Practice XII: KnowledgeEnabling Business Processes”, Comm. Of AIS, Vol. 13, 2004, pp.25-38. [20] Johansen, R. (1988) GroupWare: Computer Support for Business Teams, The Free Press, New York, NY, USA. [21] Elis, C.A., Gibbs, S.J. and Rein, G.L. (1991) Groupware: Some Issues and Experiences, Communications of the ACM, 34(1):39-58. [22] GroupSystems II (www.groupsystems.com) [23] Alavi M.and Liender D.E. (2001): Review: Knowledge management and knowledge management systems: Conceptual foundations and research issues, MIS Quarterly, Vo. 25, No. 1, March, pp.107-136.

[24] Nonaka, I. “A dynamic theory of organisational knowledge creation, Organisation Science, 5(1): 14-37, Feb 1994. [25] Miers, D. (2004): The Split Personality of BPM, BPTrends, February 2004 (available from www.bptrends.com). [26] Marjanovic O. (2007) “The Next Stage of Operational Business Intelligence: Creating New Challenges for Business Process Management”, Proc. Of the Hawaii International Conference on Systems Science, HICSS’40, Hawaii, January. [27] Fuchs-Kittowski, F. And Kohler, A. (2005), “Wiki Communities in the Context of Work Processes”, Proc. Of the WikiSym ’05, October 16-18, San Diego, CA, USA. [28] Wagner, C., Cheung, K.S.K. and Ip R.K.F. (2006), “Building Semantic Webs for e-government with Wiki technology, Electronic Government, Vol, 3, No 1. [29] Wagner, C., “Wiki: a Technology for Conversational Knowledge Management and Group Collaboration, Communications of the Association for Information Systems, 13 (2004), 265-289.