Business process learning on the job: A design science oriented approach and its empirical evaluation

: Today, Business Process Management (BPM) has established itself as an important cross-functional task in companies. The primary goal of BPM is to optimize the business process design and henceforth the actual execution of business processes. However, since optimizing processes on paper is not sufficient to really boost a company’s performance, it is indispensable to optimize the process execution which defines how business processes are actually performed at the end of the day. Yet before employees are able to carry out processes, they need a given up-front learning time. Hence, to research how business process learning can be realized on-the-job is promising in order to reduce up-front learning time; thus, being able to work efficiently on processes already from the very beginning. In this paper we present a tool-supported approach towards business process learning on-the-job using the concepts of task guidance and process guidance. After introducing the approach and its prototypical implementation, the paper presents an empirical study of this prototype showing that the general approach is useful to optimize workplace learning. at Dr. Werth holds diplomas in Business Administration and in Computer Sciences as well as a PhD in economics. His research activities comprise collaborative business processes, business integration and advanced business information systems. He wrote and edited several books and published scientific papers and articles in international journals and proceedings. Peter Loos is director of the Institute for Information Systems (IWi) at the DFKI. His research activities include business process management, information modeling, enterprise systems, software development as well as implementation of information systems. Prof. Loos received the venia legendi in Business Administration. Prof. Loos wrote several books, contributed to 30 books and published more than 100 papers in journals and proceedings.


Introduction
Business Process Management (BPM) has established itself as an important crossfunctional task in many companies (Marjanovic & Bandara, 2010). Especially in the field of process modeling lots of effort is done. The motivation for this is obvious: a strict documentation of business processes fosters the ability to optimize them starting from their modeled as-is state and ending at the optimized to-be state (Koliadis & Ghose, 2006;Kavakli, 2004). However, optimizing processes on paper does not really boost a company's performance. Hence, one important facet in the course of BPM-as a continuous company mission-is the process execution that defines how business processes are actually performed at the end of the day.
Since most business processes are not performed fully IT-based, human beings do often play a central role in their execution. However, in contrast to IT systems, individuals rely on learning as a basis for knowing how to carry out specific processes. Hence, before persons are able to perform them, there is a given up-front learning time needed. In addition, not only these startup costs for being able to perform processes for the first time, but also the risk of conducting activities wrongly are at a high level at the beginning of gaining experience in processes-no matter whether the processes are of transactional or flexible, i.e. less predictive, nature.
During the execution phase of business processes, process guidance-which assists users in questions regarding how to proceed in a business process-has been shown as useful in practice (Grambow, Oberhauser, & Reichert, 2011). Hence, the guidance concept could be a way out of the previously described shortcoming. However, in research less effort is put into the question whether process guidance can foster employees in working on business processes that are unfamiliar to them, i.e. without having to learn these processes basically beforehand and often in a time-consuming and less productive way. Additionally, the same applies when significant changes have been enacted in processes which employees are already familiar with-which might be also interesting from a change management point of view (Martin, 2010). Since working and business environment has come to ever shorter life cycles, the frequency of changes and hence the need for an efficient change management including the training and learning becomes more and more important for doing successful business (Jacobs & Park, 2009). Consequently, it is often a heavy and time-consuming task for employees to learn unfamiliar processes or adaptations of common ones.
Considering a different application domain, lots of effort is done to keep up-front learning costs as low as possible. In doing so, the time needed to learn a business process can, to some extent, be compared with studying an operating manual for technical systems before actually operating with them. State-of-the-art information technology strives to reduce these up-front costs for reading manuals by providing means to learn how something works on the fly. In this regard, Apple's iPhone is a good example since it is basically delivered without a user manual. Its user interface is just designed in a way that users can navigate through the system and learn how it works while actually using it-meaning on-the-job.

Motivation and contribution
Hence, it is promising to examine the concept of guidance to learn business processes onthe-job as well. Hence, this paper presents an approach demonstrating how task guidance (assists in questions regarding which tasks have to be done in a specific process step) and process guidance (assists in questions regarding which process steps have to be done in a process) can be used to help employees in learning unfamiliar business processes and changes within existing ones with which they are already familiar. To minimize the upfront learning effort, the learning procedure will be implemented into the execution phase of business processes.
In doing so, the contribution of the paper is two-fold. First of all, the paper presents an approach that uses the concept of guidance with regard to learn business processes. In addition to that, the paper presents an empirical study showing that the implementation of this theoretical approach is useful in practice and contributes to the goal of reducing up-front learning time to a minimum while keeping conflicts and faults in the execution as low as possible.

Scientific methodology and paper organization
The information systems research is led by two oppositional paradigms: behavioral science and design science (Hevner, March, Park, & Ram, 2004;March & Storey, 2008). Behavioral science explains with theories the human and organizational interaction with information systems regarding the whole life cycle of information systems, i.e. starting with their design and ending with their use and management (Hevner et al., 2004). Design science does not develop theories to explain the interrelation of information systems, but it develops new and innovative IT artifacts. This development is always motivated by existing problems (i.e. business-driven) that should be overcome by the creation of new artifacts (Hevner et al., 2004;Wieringa, 2010). According to March and Smith (1995), a typical design science artifact is an instantiation of a developed approach represented by a concrete implementation of it, i.e. for example a prototype.
Besides developing such an artifact as an output of design science research, March and Smith (1995) also distinguish between two major activities within design science research: build and evaluation. Accordingly, building activities only show the feasibility to construct an artifact. In addition, evaluating an artifact shows whether the underlying problem is effectively overcome by the constructed artifact and therewith some progress is achieved within the problem domain. Consequently, evaluations pursue the demonstration of the utility, quality, and efficacy of developed artifacts (Hevner et al., 2004). This paper follows the design science research paradigm, since it presents a novel artifact that solves or at least reduces the practical-driven problem of the time-consuming way of learning business processes. In doing so, the paper outlines an approach for learning unfamiliar and changed business processes on-the-job. Afterwards, the approach is evaluated against the underlying problem domain (Riege, Saat, & Bucher, 2009) based on an empirical study, which is considered as a suitable method within the design science paradigm (Hevner et al., 2004).
To apply this methodology the remainder of this paper is structured as follows: section 2 examines related work in the field of learning, executing and adapting business processes. Afterwards, section 3 forms the foundation of this paper by introducing the developed approach. Within section 4, the settings of the evaluation are outlined and the findings of the empirical study are examined as well as applied to the general approach. Finally, the paper closes with a conclusion and outlook in section 5.

Related work
In the context of the developed approach in this paper, some related work can be found which will be examined in the following. In doing so, the related work has been selected based on a literature research on the databases EBSCO Business Source Premier and Google Scholar using search terms like "business process learning", "process learning on-the-job", "continuous process learning", "business process guidance" and "crowdsourcing in business process management".
One related approach heading pretty close towards the direction followed by this article is the one proposed by Hawryszkiewycz (2005). He tries to integrate reusable learning components into business processes in order to allow employees to quickly acquire knowledge in their working context. One of his primary goals is to integrate learning resources within the actual workspace of employees. However, his approach just includes "a link to the learning systems from selected screens in the work process". However, even though employees can start a learning unit by clicking on a button and hence the approach partly integrates business process learning into the actual process execution, employees will not improve or even build up their knowledge on-the-job, meaning based on actually conducting business processes. In this context, workplace learning has evolved in literature describing the significant relationship between working and learning (Jacobs & Park, 2009). According to Chen and Kao (2012) workplace learning summarizes activities and processes in the workplace by which employees acquire knowledge ranging from basic skills to high qualifications, which they can straightaway use in their job. As stated before, one dimension of workplace learning is on-the-job learning (Clarke, 2005).
Apart from the concept of workplace learning, also relevant for the approach to be developed are the so-called learning workflows and the adaptation of workflows, to which lots of research can be found in literature. In this context, the goal is to dynamically and flexibly apply changes into workflow systems. In doing so, unwanted side effects of complex changes in workflows are avoided since it is very inefficient and often impossible to stop running activities or workflows in order to enact changes. A recent work done by Weber, Sadiq, and Reichert (2009) presents a detailed review of challenges and techniques that exist in continuously managing the lifecycle of dynamic processes respectively workflows. As an example, one approach towards this direction is proposed by Dadam et al. (2008). With their ADEPT2 Process Management System, they aim at achieving a quick implementation and deployment of new business processes in order to enable ad-hoc changes of running processes. To have a broad overview on these aspects, it is also referred to the recent state-of-the-art analysis provided by Burkhart and Loos (2010).
While the previous research stream primarily focuses on technical issues regarding how to dynamically enact changes into running business processes, other work explores ways how business processes can be improved by learning from their actual business context. A recent state-of-the-art analysis can be found in Ploesser et al. (2009). They state that context-awareness in BPM is a current and future challenge in process management in order to achieve true agility and flexibility. In this context, work dealing with learning how to improve business processes can also be regarded (Ghattas, Soffer, & Peleg, 2008). This learning process is also considered as an evolutionary process like BPM and hence must be managed like other business processes are managed in organizations.
In addition to context-awareness in BPM in terms of organizational knowledge, the involvement of collaborative knowledge is also a valuable source to improve business processes. During the BPM steps of design, modeling and optimization the crowd can be used to create new solutions that no single member of them would have reached on its own. Nevertheless, crowdsourcing techniques are a relative new development in business process management, for which only a few applications have been proposed in literature. From the area of knowledge management it is known that collective knowledge and organizational learning are enabled by interacting humans that work on shared digital artifacts (Kimmerle, Cress, & Held, 2010). These artifacts need to offer a high number of possibilities for influencing and modifying it. Additionally, they need to raise cognitive conflicts which lead to discussions and thereby improve the results. The term "agile BPM" shares the idea of involving all stakeholders into the BPM lifecycle. Every one of them has a specific perspective and might add valuable contributions to all phases. The removal of organizational barriers, a stronger integration of BPM and a high knowledge sharing are prerequisites (Bruno et al., 2011). Besides such explicit crowd-actions, it is also proposed to use the crowd to gather otherwise non-discoverable knowledge (Laredo, Vukovic, & Rajagopal, 2011). User practices as one example can be collected from the crowd and evaluated to gain additional insight.
As a means to implement crowdsourcing into BPM, social software is commonly recommended. It has the benefit of fostering communication and knowledge sharing and removes hierarchies by letting all participants appear as equal users (Bruno et al., 2011). BPM systems incorporating explicit and implicit crowdsourcing are sometimes referred to as "intelligent BPMS" (iBPMS). Such systems cover social media, mobile device support, Complex Event Processing (CEP) and Business Activity Monitoring (BAM) technologies to track the behavior of all crowd members (Gartner, 2012).
After all, the current state of the art on related work shows that there exist no similar research efforts focusing on the underlying research question: whether and how far the process of learning new business processes can be realized on-the-job to minimize the up-front learning time by using the guidance concept. Nevertheless, it is promising to combine the existing related research streams to a comprehensive approach to address the research question.

Business process learning on the job
Within the previous section on related work, some general concepts have been presented and outlined forming the basis of our approach: Firstly, business process learning will be intervened with the actual working on processes, i.e. the learning effect results from the process execution. This is basically what is understood as business process learning on-the-job.
Secondly, the actual learning will be realized by using reusable learning components that are integrated into single process steps. In using the inherent knowledge of these components, users are assisted via task guidance (based on context-oriented knowledge) and process guidance (based on process flow-oriented knowledge).
Thirdly, this guidance will be realized by recommendations that depend on the underlying business process models and is aware of the context-situation in which the business processes are conducted. This is achieved by continuously monitoring the users' behavior and adapting the process models based on their actual process execution-on the one hand for the individual user and on the other hand for all users within an organization resulting in a crowd-aware business process improvement.
Fourthly, these process model adaptations and optimizations will be dynamically applied into the workflow system that guides the user. In doing so, the approach aims at overcoming the trade-off between guidance (recommendations) and being flexible and adaptable to support ad-hoc processes (adaptation mechanism) (see Burkhart and Loos (2010) for more details). Hence, the proposed approach is not only applicable in the context of transactional processes, but also in a less predictive and more knowledgeintensive, i.e. flexible, working environment.
Within the next subsection, the realization and combination of these concepts is described in more detail.

The approach in more detail
According to Abecker, Hinkelmann, Maus, and Müller (2002), Allweyer (2005) and Lehner (2006) business processes and knowledge processes have to be considered as intervened concepts during their execution (see Fig. 1, (1) and (2)). In doing so, knowledge processes "support the flow of knowledge between business units and processes as well as the creation and collection of knowledge" (Remus & Lehner, 2000). Since the major objective is to gain knowledge linked to the underlying business processes, we need to have a closer look at what process knowledge actually means. In this regard, Remus (2002) distinguishes between two kinds of process knowledge: process flow-based knowledge (i.e. basically knowledge on the sequence of process steps within a business process model) and content-based knowledge (i.e. basically knowledge on how to conduct process steps within a business process model) in business processes.
Besides combining business processes and knowledge processes there is also the need for including training and learning processes into the overall process design (Allweyer, 2005) (see Fig. 1, (1) and (3)). This means that employees have to learn both process flow-based and content-based knowledge in order to know how to successfully perform a business process. To realize this, the approach builds upon two concepts of learning that are considered as promising for process learning on-the-job: task guidance and process guidance (see Fig. 1, (b)). While task guidance helps employees in conducting the current active process step (via content-based knowledge)-i.e. which tasks have to be done in this specific process step and what is the actual aim and outcome of this process step in order to proceed with the overall process in a successful way-, process guidance (via process flow-based knowledge) assists them in questions how to proceed in the business process-i.e. which process steps need to be conducted after the current one. Based on this guidance during process execution, the approach follows a passive, structured on-the-job learning methodology, which is also called action learning (Jacobs & Park, 2009). This means "Learning occurs at the actual work setting as a result of using a systems approach, and with limited involvement of a trainer/facilitator". In this regard the adjective "structured" does not describe the underlying business processes (see the beginning of section 3), but outlines the usage of a system that actually helps to learn. To realize task and process guidance, the approach makes use of recommendations (see Fig. 1, (a)) based on the underlying business process models. In this regard, business process models are defined as a combination of single process steps, each of them including task guidance components based on the underlying content-based knowledge, which are considered as learning components (see section 2). In monitoring users in their work on a continuous manner (see Fig. 1, (c)), their behavior can be assigned to a specific process step within a process model. Hence, based on underlying process models, the approach recommends further process steps to the users in order to successfully accomplish the process execution.
However, these process step recommendations are not solely based on the underlying standard process model, but can additionally be crowd-based or user-based. It is distinguished between crowd-based and user-based recommendations since each individual user has a very personalized process that may deviate from the standard business process-as far as it is in line with a company's compliance rules. Of course, user-based recommendations are preferably applied when a user has already acquainted knowledge on the process and not at the beginning when working on a process for the first time. Nonetheless, pure personalized recommendations could reinforce inefficient or even incorrect sequences such as inadvertently skipping important process steps. Crowdbased recommendations mitigate this shortcoming (Burkhart, Werth, & Loos, 2011). In doing so, crowd-based recommendations enrich the set of relevant possible process paths based on the aggregation of the process experiences from multiple users; hence, it builds upon the knowledge of many. After a given amount of deviations from the standard process model, the latter will be adapted to the apparently new business situation.
Thus, there is a continuous learning effect resulting in enhanced personal (user learns how processes are conducted) and organizational (business process models adapt to new context situations) knowledge (see Fig. 1, (d)).
To explain this recommender concept in more detail, the recommendation cycle in Fig. 2 outlines how process model, recommendations and user actions are connected. An incoming external event triggers the recommendation mechanism (1). The Process Instance Manager as a part of the Process Recommender receives information about valid next steps from the individual process model (2). Based on this information the Process Instance Manager updates its directory of active and inactive process steps and provides a set of active steps for further processing. Individual preferences about the next step are obtained from the user's sequence graph (3). Besides these two individual models the aggregated process model and sequence graph provide further suggestions that originate from the crowd knowledge (4). The subsequent combination of user-and crowd-based recommendations results in a self-adjusting recommendation model (see Burkhart, Werth, and Loos (2011) for more details). The recommender subsequently provides the user with the recommended process step (5). Depending on the user's actual decision about implicitly accepting the step or choosing a different one the system will continuously adapt the models to give more adequate recommendations in future (6 and 7).

Fig. 2. Feedback cycle for user-based and crowd-based recommendations
Thus, this recommendation methodology contributes to the knowledge process that is linked to the business processes. Since collaborative knowledge is built up and based on optimizing the process models, the organization´s knowledge will be enhanced as well. Furthermore, changes can be automatically enacted into (running) business processes as one of the concept's preconditions. Through the task and process guidance, users will be able to learn the process execution on-the-job; hence, they experience a learning effect (see Fig. 1, (d)) which reflects the combination of business process execution and the training and learning processes.

Applying the approach to a specific context
Having introduced the theoretical approach, it will be applied to a specific context which will ease the comprehensibility. For this purpose, a prototypical implementation of the approach will be demonstrated. Based on this implementation, the approach will be evaluated based on an experimental study within section 4.
In doing so, we put a particular emphasis on email-based processes since email communication has generally become an integral part of daily business activities within companies at any size. On average, employees spend 2.6 hours a day with sending and receiving 33 respectively 72 emails (Email Equation, 2010; The Radicati Group, 2010). Furthermore, not only the time spent with emails as a means of communication, but also the knowledge that is bundled without structure in companies' email repositories is very difficult to manage. This becomes clear if the number of 75% is taken into mind representing the percentage of a company's knowledge saved in email messages (Messaging Architects, 2012). As a direct consequence, if employees spend 1/3 of their time with email communication and 3/4 of a company's knowledge is stored in email inboxes, it can be concluded that a large number of business processes take place via email communication.
Hence, it is promising to ground the approach for process learning in the context of email-based processes. Since emails are a very flexible and ad-hoc means of communication we also address one of our goals, namely supporting flexible and ad-hoc processes, in an appropriate manner.

Introducing the underlying three-layer approach
The developed Collaborative Process Assistant (COPA), which implements the approach, automatically hooks onto the existing email infrastructure and collaboration systems, such as Microsoft Exchange, and assigns incoming email messages based on their semantic content to new or already running business processes. This technique allows to provide users with task guidance helping them in conducting the currently active process step within an underlying business process. Furthermore, users will receive process guidance, so that they know how to conduct the following steps within the assigned business process. To explain how task guidance and process guidance is realized, we introduce three layers on which the approach and hence the prototype is based: On the level of the system layer, each received email will be intercepted by the system and subsequently be analyzed, archived, decoded and decomposed. Each part of an email, i.e. header, body and attachment, will be transformed into plain text and merged into a single XML document to allow the other layers to directly access the information for further processing. In addition, the system layer will provide system connectors usable to interface external and legacy systems, required to be accessible throughout a task.
The semantic layer signifies meaningful communication of an enterprise. Starting from pattern-based information extraction, using e.g. regular expressions, the business process and specific process steps within them can be identified and relevant information in this regard will be extracted.
From a task guidance and process guidance point of view, the process layer is the most important one, since it contributes to the actual process learning on-the-job. The layer is further subdivided into one process build-time (configuration) component and four process run-time components, all of which are described in the following subsection.

The process layer as a basis for task and process guidance
In the following, we make use of order processes as an example in order to apply the approach and its implementation to a concrete problem domain which will help to intuitively outline our approach.

Process build time
To allow the assignment of emails to business processes, these processes have to be depicted in the system first. Therefore, users have the possibility to easily model their business processes in the Process Build Time Environment. Beside a manual process acquisition, one important feature of the system is that it automatically builds up company processes and also adapts existing ones to new circumstances (for more details on the scientific approach see Burkhart, Werth, and Loos (2011)). Regardless of the applied process acquisition method, the business processes will be stored in the Enterprise Process Repository reflecting very own specifications and will later serve as input for the task and process guidance functionalities.

Process run time
Having defined business processes, the system can be employed. Therefore, it intercepts the incoming and outgoing email traffic and passes it through the three layers. Fig. 3 shows the actual output of a processed email message. In the following, this figure serves as a feature illustration of the four run-time components that are presented and explained subsequently.

Fig. 3. Screenshot of an enriched email message
Process Detection. The first step along the execution of the process layer is the detection component. Here, the system uses the Enterprise Process Repository to determine whether an incoming email relates to an already running business process or whether a new process instance has to be initiated. In more detail, based on a semantic analysis performed in the prior semantic layer (see Wajid and Marin (2009) for more details on the semantic analysis), the email can either be assigned to an existing process-where it constitutes the next step-or the email is considered as a starting event and triggers a new process. In this case, a new process instance with its specific process ID (see Fig. 3, F) will be created based on the corresponding reference model template from the Enterprise Process Repository.
Further, the information whether the incoming email is part of an already instantiated process or a completely new one, is being displayed to the user (see Fig. 3, F). Future incoming emails concerning this particular business process will be assigned to this process instance henceforth. As mentioned before, the correct assignment of the current process step to the correct template is being realized by an analysis of process characteristics done by the semantic layer. If the detection component assigns an incoming email to a wrong process (step) based on an incorrect semantic analysis, the user still has the possibility to manually reassign the email to another process step (see Fig. 3, H). To assist the user, the system provides information about the semantic matching of the email to a process step based on percentages.
Another feature of the system, which relates to the automatic acquisition of business processes or at least their adaptation to new circumstances, is the following procedure: assuming an underlying process model with the process sequence "A -> B -> C". For a certain number of times, after process step A has been conducted, incoming emails relate to process step C or a user initiates via sending emails process step C. Then, the system automatically adapts the underlying business process model in the Enterprise Process Repository to this changed business circumstance. Such process deviations can either affect the personal process template of an individual user or the underlying process template of the whole enterprise, i.e. for all users conducting this type of process. Hence, a process model within the Enterprise Process Repository can relate to the overall enterprise or on the other hand to a subset of employees. This distinction is necessary in order to realize the crowd-based and user-based recommendations (see section 3.1). How this adaptation technique works in detail can be seen in Burkhart, Werth, and Loos (2011).
In doing so, the process detection component realizes a flexible workflow engine that is beyond current state of the art. For more details on the current state of the art on flexible workflow engines it is referred to Burkhart and Loos (2010).

Process Tracking.
As the second step along the process layer's execution, the tracking component monitors all incidents occurring within a running process and stores every performed step in the context of the related process. This component utilizes the Enterprise Process Repository and the semantic information gathered from the original incoming email, to track which process is triggered by this email. Additionally, it updates the assigned process instance within the Enterprise Process Repository with all important data that can be useful or applicable for future process analysis. Each performed step concerns two occurrences, actions and events. Actions signify human or application triggered activities, whereas events have no active part. In the context of email communication, actions mainly correspond to the activity of sending emails and events to receiving emails. Since every performed step is related to its unique process instance, it can be tracked and on this basis recommendations for further steps can be obtained and provided to the user (see Fig. 3, G). In case the system is applied in a collaborative scenario, it may be possible that the incoming email belongs to an overall process whose previous steps have been executed by other system instances. In this case, the tracking component offers a synchronization functionality, which allows to synchronize already executed steps of an overall process throughout several instances of the COPA system. Hereby, the tracking component determines which information has to be gathered from other known instances. Thus, collected information will subsequently be added to the local database and utilized for further enhancement of the generated output. At this point other beneficial aspects of the tracking component reveal.
The gathered information provides a comprehensible documentation for further disposal. Due to the semantic extraction of process information, e.g. customer information and quantity of ordered goods, the system enables a (mostly) automated build-up of a company-specific customer database. The email contains two sets of data informing the user about the present state of the current process, as well as the visualization of the preceding process steps. The first data set contains key information about the email and the process at hand and informs the user about the present status of the process instance the email belongs to (see Fig. 3, G). The second data set shows an overview over all preceding steps in the current process including the corresponding emails.
Task Guidance. As the correct process step has already been identified by the detection component and the semantic layer, the task guiding functionality is now deployed in two ways. Firstly, the task guiding component exploits the Enterprise Process Repository in order to gather relevant process data. Secondly, the task guiding functionality supplies the user with case-related information about the particular process step. This data consists of internal information, like customer history, from an own database (see Fig. 3, A). In addition, external information is offered context-based either in form of a gateway to useful web links (see Fig. 3, C) or email-integrated travel details to a location provided by Google Maps (see Fig. 3, B). Besides the context-sensitive enrichment of incoming emails with internal and external information, the task guiding component provides the possibility to send email drafts that are context-sensitively selected and recommended to the user (see Fig. 3, D). Furthermore, if other software systems are used within the enterprise, e.g. ERP systems, components can be integrated that transfer information out of the email to these systems (see Fig. 3, E). Depending on the context, different kind of information can be useful for a particular process. Hence, the type and level of detail of the information to be displayed can be adjusted using a customization tool.
Process Guidance. Based on prior process instances and actions of users in these instances, there is already knowledge about the underlying process available, which forms the input for the process guidance functionality. Using the Enterprise Process Repository, the guidance component-as the fourth step in the processing of an incoming email-offers suggestions and recommendations for the further proceedings in a particular process (see Fig. 3, G; for detailed information on the recommendation process, see Burkhart, Balzert, Werth, and Loos (2009)). A second functionality of the process guidance component is to provide advice in actually executing the next process step once the user has chosen one of the provided actions.

Empirical evaluation of the designed artifact
Driven by the design science paradigm, the developed approach needs to be evaluated. Hence, we conducted an empirical study using the developed prototype to examine whether and how far the approach contributes to its desired goal: efficient execution and learning of unfamiliar business processes on-the-job. To proof this rather fuzzy statement in the sense of an empirical evaluation, we broke this overall goal down into three hypotheses representing the goal of an artifact evaluation (Hevner et al., 2004)-efficacy, utility and quality: H A,1 (efficacy): The approach contributes to a significantly faster processing of an unfamiliar workflow.

H A,2 (utility):
The approach contributes to a significantly easier processing of an unfamiliar workflow.

H A,3 (quality):
The approach contributes to a significantly higher satisfaction with the result of an unfamiliar workflow.

General evaluation settings
To prove these hypotheses, test persons had to operate a workflow which they are not familiar with twice. One execution was supported by the prototype using the guidance concept while the other one had to be operated in a common way without any support. After each completed workflow execution, the test persons rated their workflow execution in regard to their satisfaction with the processing time, their sensed easiness of execution and their satisfaction with the result of the workflow. Beside these three subjectively measured variables, the processing time of each workflow execution was measured and served as an objective indicator. To avoid any influence of the test persons regarding their subjectively rated processing time, they were not informed about the actual measured time until the evaluation was completed.
The evaluation was conducted in laboratory settings as a controlled experiment (Hevner et al., 2004) in order to realize a comparability of both workflow executions. Therewith, equal conditions for both workflow executions could be achieved.
An important parameter that could influence the measured processing time is the learning effect caused by operating the same workflow twice (Briand, Bunse, & Daly, 2001). This means, a subject might learn various aspects from the first execution, e.g. the testing environment or the course of the workflow in more detail, which will bias the processing time in the second execution. Thus, if the evaluation would have been done in a way that the second workflow execution was constantly supported by our approach, the processing time might have already been decreased in the second execution just based on the fact that a test person is already familiar with the workflow. This applies vice versa, i.e. gained experience in a first supported execution could result in an equal processing time in the second non-supported execution. Consequently, the sequence of the execution types (with support vs. without support) was swapped in an alternating manner.
Technically, the evaluation was conducted with the statistical software SPSS Statistics Version 19. The hypotheses were proved by conducting several statistical tests, all of which were based on a level of significance of α = 0.05. Furthermore, various descriptive techniques were utilized.

Evaluation workflow
The evaluation workflow was about a student registration process for a seminar place. This process should be operated from the view of an employee at a registrar's office. The workflow was initiated by receiving an email from a student who requested for registering to a seminar place at the chair of his/her main subject. This email message (see Fig. 4, 1) is automatically detected as a seminar registration workflow by the prototype and is accordingly enriched with all required information to proceed with the workflow (see Fig. 4, 2 and 3).

Fig. 4. The evaluation workflow with COPA guidance
Now, the test person had to check whether the registration requirement was met by the student. Within the supported workflow execution, this check could be carried out easily due to the fact that the system had enriched the email with this information, so that a test person knows which information is relevant in this specific process step. Without the support of the system, the test person had to look for this information. If the check was positive, the test person had to send an email to the correspondent contact person at the chair saying that the student had achieved the required amount of credit points and therefore a registration request could be accepted and was consequently forwarded to them (see Fig. 4, 4). In a last step, the test person had to send an internal email to their colleague informing them about the event and requesting for an internal data update (see Fig. 4, 5). The sequence of this email communication as part of the underlying workflow is recommended to the test persons in a way as it can be seen in Fig. 3, G. Furthermore, the system recommends pre-defined email messages showing which information is needed by the recipient. Thus, the system does not only guide test persons within the current process step (i.e. task guidance), but also with regard to how to proceed the further steps within the workflow (i.e. process guidance).
This scenario comprises various tasks that are typical for many business email communications. Firstly, the intent of an email has to be identified. Secondly, further procedure within the workflow initiated by the email message must be known by the addressed person. Thirdly, different information retrievals have to take place based on which decisions are made. Fourthly, the workflow is continued by email communication with other persons that are responsible henceforth. Whereas traditionally the person dealing with the workflow has to be really familiar with the workflow, our approach supports the person in different ways. In this scenario, the prototype automatically identifies the email as the first step of a registration process. Secondly, it provides an overview on the following steps within this workflow. Thirdly, the email is enriched with needed information pulled from different source systems and files. Fourthly, pre-defined emails are offered that fit in the workflow.

Results of the evaluation
The study sample had a size of 32 test persons. The sex distribution was almost one-third female and two-thirds male (see Fig. 5, left). The mean of the age distribution was low (26.63 years) and had a standard deviation (SD) of 3.42 years (see Fig. 5, middle). In response to the question "How do you judge your IT-skills" (scaled from 1-"very good" to 5-"very poor"), 44 % judged their skills as "very good", 34 % as "good" and 22 % as "satisfactory". Based on a median of 2.00 ("good"), it can be assumed that the study sample had good skills in information technologies. Regarding experience with workflow systems, two-thirds of the test persons stated to have never worked with a workflowbased system before (see Fig. 5, right). Consequently, the study sample was not very familiar with workflow systems. Without any exception, all test persons stated to use emails as a means of communication "every or almost every day". As a result, there seemed to be no major problems to conduct email-based processes within this study sample.  The objectively measured processing time of the workflow execution types A (with support) and B (without support) as well as the subjectively rated satisfaction with the processing time served as the basis to prove the stated hypothesis H A,1 .

Fig. 6. Distribution of the workflow processing times
Objectively measured processing time. The first step in this evaluation was to analyze the processing time of each workflow execution. In case of a support by our system (type A), the mean of the workflow executions was 134.22 seconds (sec) with a standard deviation (SD) of 49.20 sec. In contrast, the mean of the execution without a support (type B) was 186.97 sec with a SD of 54.98 sec (see Fig. 6). A dependent Student's t-test for paired samples proved a significantly faster processing of the workflow execution type A compared to type B. Therefore, as hypothesized in H A,1 : The approach contributed to a significantly faster processing of an unfamiliar workflow.
The mean for type A within the execution sequence type B -> type A was 106.73 sec with a SD of 35.48 sec. In contrast, the mean within the sequence type A -> type B was 162.63 sec with a SD of 45.76 sec. For type B, no significance was identifiable (mean 183.19 sec with SD 53.49 sec vs. mean 191.00 sec with SD 58.13 sec). This fact can be interpreted in the way that, within type A, there is still a margin in the processing time and this time will decrease in further workflow executions until it levels off. On the other hand, execution of type B can be seen as stable. Consequently, the fact that our approach contributes to a significantly faster processing of an unfamiliar workflow is stronger the more experience a user has with a workflow. As stated in section 3, the sequence of the process execution might have a significant influence on the processing time. This influence was tested in both types (A and B) of the workflow execution. Interestingly, for type A, the sequence had a significant influence on the processing time.
Satisfaction with the workflow processing time. Beside the objectively measured time, which the test persons needed to proceed with the workflow, it is also important that test persons are subjectively more satisfied with their processing time.
This should be analyzed because it could be the fact that test persons operate an unfamiliar workflow faster with our approach, but do not notice this decrease in time subjectively and sense the time due to a new working experience as even higher. Therefore, the subjects were asked to rate their satisfaction with the processing time (scaled from 1-"very satisfied" to 5-"very dissatisfied"). To ensure a more valid result, the test persons were not informed about their actual processing time until the entire evaluation was completed. In type A, more than half (53 %) of the subjects expressed themselves as "very satisfied", 38 % were "satisfied" and less than 10 % were "neither" satisfied nor dissatisfied. On the contrary, in type B, not a single test person was "very satisfied", 28 % were "satisfied", 38 % "neither", 31 % "dissatisfied" and 3 % even "very dissatisfied" (see Fig. 7). A conducted Wilcoxon signed-rank test proved a significantly higher satisfaction with the processing time in type A compared to type B. In contrast to H A,1 , the second hypothesis H A,2 could not be proved based on objectively measured variables. Therefore, this test of the hypothesis relied on the subjectively rated satisfaction of each test person. The rating was scaled from 1-"very easy" to 5-"very difficult". Workflow executions of type A were rated as "very easy" by 38 % of the test persons, more than the half (53 %) rated them as "easy" and less than 10 % as "neither" or "difficult". In contrast, in type B more than two-thirds (69 %) judged the easiness as "neither", 6 % even as "difficult" and only 25 % as "easy" (see Fig. 8). A conducted sign test showed that the test persons judged the workflow execution as significantly easier if it was supported by our approach. Therefore, the hypothesis H A,2 was accepted. The last hypothesis is whether a significantly higher satisfaction-in regard to the achieved and perceived quality of the workflow result by the subject-can be guaranteed by a supported workflow execution. Negative results of the workflow execution would be that due to a subject-based process error the workflow could not be operated successfully or that not all steps within a workflow execution could be operated without problems. The analysis was also based on subjectively measured variables that were scaled from 1-"very satisfied" to 5-"very dissatisfied". In type A, almost half (47 %) of the subjects were "very satisfied" with their achieved workflow result and 44 % were still "satisfied". Only 9 % expressed themselves as "neither" (3 %) or "dissatisfied" (6 %) with the result (see Fig. 9).

Fig. 9. Satisfaction with the workflow result
Workflow executions of type B also resulted in "very satisfied" subjects (13 %) or even in more than half (53 %) of the cases in "satisfied" test persons. However, more than one-third were "neither" or even less satisfied with their result. Beside some minor problems, one workflow execution of type B stopped because of a self-inflicted process error by a test person (consequently a "very dissatisfied" perception with the workflow result was expressed). On the contrary, within the executions of type A, no process error took place. A conducted sign test showed a significantly higher satisfaction with the workflow result, as hypothesized, if the test persons were supported in their work by the system. As a result, the hypothesis H A,3 was accepted.

Limitations of the study
Due to the broad variety of business processes, it is impossible to achieve a general applicable and representative result by executing just one empirical study. Nevertheless, we tried to choose a scenario that represents a common email-based process as outlined in subsection 4.2 in order to cover at least email-based processes with the developed approach.
Furthermore, the laboratory setting in which the evaluation took place endangered the external validity, since controlled experiments always implicate the awareness of test persons that they work under laboratory settings and not in a real-world scenario as it would be in case studies or field studies (Hevner et al., 2004). However, to have a direct comparison of a test person's workflow execution, this way seemed to fit best to prove the hypotheses. Hence, the internal validity of the evaluation was quite high based on the same fact. Moreover, we set up the study in a way to avoid different influencing factors, e.g. the gained process experience based on the execution sequence, which could bias the learning performance of the workflow.
However, the evaluation did not cover the conduction of changed and adapted processes. Another aspect is how the learning curve will be after a longer period of time consisting of several iterations of a given process.

Conclusion and outlook
After all, the evaluation has demonstrated the benefits of guidance for carrying out unfamiliar business processes and learning them on-the-job. Consequently, the study proved that the test persons were able to process an unfamiliar workflow significantly faster by task guidance and process guidance. Furthermore, they experienced the processing as significantly easier and, moreover, they were significantly higher satisfied with the result of the conducted workflow.
In the next step, we are going to evaluate our approach using the implementation in a real-world scenario or even in a large-scale field study. Moreover, further highlyimportant features, which are only testable in a time-consuming way, e.g. the adaptive, flexible and self-learning features, will be evaluated to see how learning is progressing and how organizational knowledge and collaborative knowledge will increase over time. Furthermore, we plan to apply the approach to another application domain that is not email-based to prove the applicability in more general terms.