supporting end-user articulations in evolving … · notations seem to be quite complex. all of...

February 16, 2013 20:13 WSPC/S0218-8430 111-IJCIS 1250004

International Journal of Cooperative Information SystemsVol. 21, No. 4 (2012) 263–296c© World Scientific Publishing CompanyDOI: 10.1142/S0218843012500049

SUPPORTING END-USER ARTICULATIONS INEVOLVING BUSINESS PROCESSES: A CASE STUDY

TO EXPLORE INTUITIVE NOTATIONSAND INTERACTION DESIGNS

JAN HESS∗, CHRISTIAN REUTER∗∗,VOLKMAR PIPEK‡ and VOLKER WULF§

Information Systems and New Media, University of SiegenHoelderlinstr. 3, 57076 Siegen, Germany

∗[email protected]∗∗[email protected]‡[email protected]§[email protected]

Adaptations of business processes are important in work environments, specifically whenprocess-support needs to be tailored according to changing needs. The creation, manage-ment, and adaptation of the process models require typically modeling-experts. Whilethese actors are knowledgeable in formalizing and operationalizing processes end-userswho do not necessarily possess sophisticated modeling skills know typically local prac-tices and framing conditions best. In this paper, we present an approach to supportusers in articulating their needs and to involve them into the (re-)design of processspecifications. We explore how end-users reflect upon and articulate about business pro-cesses. Based on results of a qualitative study, we present a new, paper-based interactiontechnique, which enables users with little skills to model processes. The resulting pro-cess specifications can be transferred either in paper or in digital form into traditionalmodeling systems for further elaboration.

Keywords: Knowledge work; business process modeling; process adaptations; flexibleworkflows; articulation support; end-user development; pen-and-paper based interac-tions.

1. Introduction

In today’s enterprises, well-designed processes guide the creation of goods and ser-vices. For traditional industries that mainly produce for the mass market, an effec-tive and efficient workflow management is crucial. The best practices emerge withtime and process descriptions represent these practices on a formal level for decision,execution and analysis purposes. At the level of knowledge work, process descrip-tions also guide work practices, but are characterized by a less explicit and formal-ized representation. Requirements depend on the context, they often change, andthis requires flexible adaptations of forms that have already been established. Suchtypes of dynamic behavior can often be found in particularly small and mediumsized companies (SMEs) that usually have to react to the changing market situation

263

http://dx.doi.org/10.1142/S0218843012500049


264 J. Hess et al.

rather quickly. Even if those are not necessarily called process models, here employ-ees execute work in a process that is learned, that is being practiced, and that needsto be adapted and improved in order to be able to satisfy changing demands.

The knowledge about framing conditions and requirements for the processesoften lies with several domain experts, i.e. end-users who are experienced in theirarea of work and act on practices established over time. In our work, such domain-experts are referenced as “end-users” with good practical experience but with noadvanced skills in formal modeling. Usually, end-users understand the complexityof the process (in a sense of complexity of practice) but normally cannot influencechange in the process model. Typically, the modeling process is based on complexnotations and tools, which require expertise from the modeling experts. “Modelingexperts”, are defined as users with the knowledge to operationalize and formalizethe modeling, define and structure the schedule of work. Based on that expertise,modeling experts create (complex) models with (normally) complex modeling lan-guages that end-users have to work on. In practice, gaps will evolve between thedefinition (the way how work should be done) and the practice (the way how workis done). In order to bridge the gap between modeling experts and end-users,1 weare interested in new forms of cooperation that require process notations and inter-action concepts that are understandable and intuitively usable by all stakeholdersinvolved. As a precondition, the process language needs to be easy to understandand intuitive to use.

Tools for business process reengineering, workflow management2 or businessprocess execution in Service-Oriented Architectures (e.g. Levardy and Browning3),form an infrastructure of process-oriented adaptive systems that usually requireexpert knowledge in their model management. Adieu4 and SISO5 are examplesthat support modeling with an easier to handle interface. However, as stated byShipman and Marshall,6 formal representations can be difficult to understand andcan also be easily misunderstood by end-users. There is a necessity to expresscontextual issues through informal representations5,6 and while the limited space ofa computer screen makes simultaneous collaboration difficult, pen-based systems7,8

provide an alternative to traditional input concepts. Participants can use differentpens simultaneously and large sheets of paper provide an adequate backdrop forcreating representations that include formal and informal elements.7

In order to support collaboration and interaction, we have chosen to focus ona scenario, where the end-user and modeling experts share a common understand-ing by working on a reference, which is understandable and modifiable by both.As a scenario, an end-user wants to indicate that a current process needs to beadapted, e.g. because the business process pre-defined by the system requires workthat can be done in a much easier way. When articulating such improvements tothe modeling expert, a common language and representation will ease the coop-eration and improve flexibility. By using pen and paper, the end-user can reflecton the processes, add alternatives to a standard process and add informal ele-ments (e.g. comments). In our scenario the activities of such articulation work has


Supporting End-User Articulations 265

been automatically digitalized and recognized by the system. The digital represen-tation of the design sessions can be shared with other users, e.g. to add furtherinformation, and can also be used by the modeling expert as input for the design.

In two explorative studies, we have learned how employees articulate and reflecton their work practices with the help of conceptual modeling examples from theircurrent business. Our empirical work mainly focuses on an explorative understand-ing of how end-users reflect on modeling and what the representation of processesdesigned by end-users will look like. From pre-studies of both cases, we have sum-marized the requirements for a more intuitive and easy-to-understand concept ofhow we can involve the end-user into the process design. As a first answer to theissues mentioned above, we will present an adaptive system that allows computersupported collaborative modeling with pen and paper. The resulting representationcan be used as a shared reference, similar to a shared language in software develop-ment9 that is understandable by different stakeholders. Modeling experts will getan understanding of current practices that can be supported with well-structuredmodels and end-users can reflect on and improve the current work by expressingtheir needs.

Based on the design of an end-user modeling language (Sec. 3), we will addressthe gap between formalizing and (re-)using the output, by following an adaptiveapproach based on digital pen and paper technology (Sec. 4). This should supportinteraction between different stakeholders by supporting the recognition of formaland informal elements, by exporting into different formats and by providing a basisfor (re-)using the boundary objects further. In the discussion (Sec. 5), we furthermap out the importance of combining the ease of expression with the ease of inter-action in the adaptation of enterprise software.

2. Modeling Adaptive Enterprise Systems: Integratingthe End-User

The notion of enterprise software as an adaptive system that needs to evolve basedon the challenges a company faces, and the active role end-users need to play inthis situation, has been formulated very early on (an overview can be found inDavenport10): Today’s systems usually follow the process-oriented perspective thathas been established in the early 1990s following the success of Business ProcessReengineering.11

2.1. Business process modeling

A “business process” is a logical set of activities leading to a special businesspurpose,12 in which they are represented with different notations. In the businessprocess modeling notation (BPMN) several categories were introduced to simplifythe language and to design models on different levels of complexity. Nevertheless,BPMN was developed for technical models of business processes12 and does not


266 J. Hess et al.

include an end-user perspective. Another important approach, the architecture ofintegrated information systems (ARIS),13 aims at enabling companies to model,analyze and optimize business processes. In the field of object-oriented softwareengineering, the unified modeling language (UML) includes different diagram types,such as business modeling, object modeling and component modeling. All thesenotations seem to be quite complex. All of them have been created to supportprofessional process and IT designers with modeling processes.

Computer systems support the process of modeling at different stages. Elliset al.14 underline the difference of the workflow model and the workflow system(execution module). While the model enables analysts and administrators to defineactivities and to assign them to different people, the workflow system consists of theexecution environment and interface as seen by the end-users. Professional modelingtools such as the WebSphere Business Modeler, the Oracle BPEL Process Manageror the SAP NetWeaver Composition Environment are embedded in a more generalbusiness process solution with interfaces to other relevant software subsystems thatsupport the analysis or the semi-automatic execution of pre-defined commands.Such tools are known for their high complexity, their broad range of functionalitiesand as such they require a rather extensive commitment to learning. For users withlow technical expertise, modeling tools are difficult to use, even if supported byvisual representations.15,16 The most common ones are based on the box-and-wiremetaphor that presents sequences and logical connections through lines connectingdecisions or domain concepts.

2.2. End-user development

Software systems are used in different environments where the context differs fromcase to case. As needs and demands of users may change over time, the optimal func-tional range can never be completely estimated during the design process. Adapta-tions are necessary and become especially important at “use-time”.17,18 Conceptsof end-user development (EUD) support such flexible adaptations by enabling end-users to adapt and reconfigure systems on their own.19 Such software systems,which are e.g. based on a component-based architecture,20 are necessary in orderto empower users in easily making their own adaptations. While EUD can be under-stood as an on-going process in relation to the work practice and collaborative use,Pipek and Wulf18 and Stevens et al.21 refer to the concept of “Infrastructuring”:Such conceptual framing underlines the importance of a design-in-use that involvesall stakeholders in designing working infrastructures over a longer period of time.

Several EUD techniques are available to support professional and less techni-cally experienced users. As mentioned by MacLean et al.22 in their Buttons con-cept, tailoring power depends on the skills that are required to be able to do thetailoring. A tailoring culture requires flexible systems that support all users in a gen-tle slope. The Buttons system also enables the sharing of individual improvements,which benefits the whole community. Such collaboration support is often stressed



as being one of the main drivers of the EUD. The system developed by Kahler23 forexample, enables a structured exchange of modifications made in Word, by usingpublic and private repositories. In order to design a gentle slope of complexity, sev-eral EUD techniques are available. Liebermann24 introduced the programming byexample paradigm, which enables the capturing of an often-used series of interac-tions and their (re-)use with different parameters as input. Concepts such as naturalprogramming address users with little or no experience in using (traditional) formalprogramming languages. The natural language of the focused user group has beenused as input for the computer systems to realize programming options.25 Insteadof using less complex commands, forms of visual programming can ease (re-)creationof virtual artifacts by using representatives that are oriented at the specific appli-cation domain.26 The interface of such systems often is realized as a constructionkit that makes the (re-)positioning and connection of components that representdifferent activities and data possible.

2.3. Process modeling for the end-user

For end-users, changes beyond the idealized version of the preferred process areonly very difficult to realize or not at all. This is problematic because businessprocesses are not always static, nor are the work steps always the same. As alreadystated in Van der Aalst et al.,27 it is necessary to combine the very structured andprocess-centered workflow domain with more (unstructured) information-centeredsolutions. As an approach, van der Aalst introduces adaptive workflows as a systemsupport that is able to deal with certain changes. Such changes include individual(ad-hoc)and structural (evolutionary) changes. In order to handle dynamic changes,van der Aalst et al.28 presents a generic process model approach that describes afamily of variants of the same workflow process.

Mendling et al.29 point out that end-users receive less support in creating processmodels that can be easily analyzed and understood by business modeling experts.Based on previous experience, they present seven process-modeling guidelines thathelp experts simplify their model and therefore make them immediately usableand more comprehensible. The work of Agostini and Michelis30 focuses on flexibleprocess changes for process instances by end-user themselves. In order to han-dle exceptions and breakdowns, the MILANO workflow system allows end-users toalter the workflow. The system supports such adaptations by enabling forward andbackward jumps. Even if the end-user can change the flow of the work this way, a(well-proven) model does not need to be altered continuously.

Conceptual modeling becomes important in various areas of business life. Asshown by Davies et al.,31 the use of ER diagrams is the most frequently used mod-eling technique in practice. One of the main reasons for modeling is the support ofcommunication among stakeholders. As language and expertise may differ betweenthe practices, the different stakeholders have to find ways to come to a shared under-standing. As a solution, boundary objects can be used to support communication


268 J. Hess et al.

between members of different communities.32 In order to interlink the end-user anddesigner/developer domain, participatory design oriented methods can also supportthe modeling process. Of special importance is the CARD technique (CollaborativeAnalysis of Requirements and Design) described by Tudor et al.33 Here, differentcards can be (re-)arranged in collaborative sessions to (re-)design activity or taskflows. The cards are (semi-)structured templates that describe an activity in moredetail. Cards are usually taped on a large sheet of paper to serve as medium forother stakeholders who are also interested in the results.

Muller34 extended the CARD approach so that it can now be used for morestructured and layered participatory analyses. A similar approach is the collabo-rative users’ task analysis (CUTA) as described by Lafreniere.35 The color-codedcards depict activities, their duration and frequency, and are put in order on a tableto create the correct schedule. Further concepts and modifications include Situa-tion Cards,36 Inspiration Cards37 and the Instant Card Technique.38 All of thesetechniques try to build a bridge between modeling experts and end-users, by cre-ating a conceptual model in the sense of a boundary object. However, even if suchCARD-techniques have proved to be a valuable source in creating a shared under-standing, and involving users in the design, there is still a gap between formalizingand (re-)using the output of such creative sessions.

2.4. Visual metaphors to support process modeling by end-users

In order to support users in modeling, the choice of abstraction level is crucial.39

Visual metaphors can support the appropriation of systems. Such a metaphor isrelated to a graphical representation with meanings similar to analogies, e.g. fromthe real world. As described by Hsu,40 visual metaphors stimulate the excitementand attention of the user. In order to support visual programming, Blackwell41

recommended using implicit metaphors. One example is the use of the dataflowmodel, where data moves along wires.42 Such representations strongly relate to thebox-and-wire metaphor: Functionalities or modules are represented as boxes thatare connected with lines, different kinds of boxes, lines and gateways can be usedto represent different types of logic. Component-based software environments makeuse of such representations to create a new artifact by re-using exiting modules. Insuch an understanding, software packages are presented as components with well-defined interfaces that can be connected with each other, without considering theprecise implementation.43

Several tools are available that support modeling and modifying services viaeasy-to-use interfaces. Visual programming tools, as e.g. implemented in the FreE-volve platform,44 support the (re-)composition by choosing relevant elements andconnecting them in a meaningful way. Web 2.0 based modeling tools such as YahooPipes or MS Popfly enable the creation of process descriptions called mash-ups.By adding, combining or (re)adapting web-based services, functionalities that aremore complex can be realized. Daniel et al.45 point out that many approaches for



web service orchestration help coordinate pieces of software, but hide the humanaspect. Their systems allows composition of distributed UI’s. Costabile et al.46

present another approach that considers the needs of different user communitiesin the design process of interactive systems. The adaptation of complex softwaresystems can also be increased by the use of “pragmatic adaptive user interfaces”.47

Another example is ADIEU, developed by IBM,48 an assistant-based tool that cre-ates service compositions and web-based interfaces. Another approach called SimpleService Orchestration (SISO) is realized as a graphical BPEL editor and supportsmodeling experts in creating new service compositions49 more easily.

Modeling on the computer screen is the most common method. However, asalready shown by Nardi,39 the limited space on the screen is a problem when itcomes to visual modeling. Brainstorming sessions are also often interrupted by dif-ferent actions within the physical space, e.g. by discussions, looking to each other vs.looking at the screen and using informal descriptions. In the last few years, differ-ent alternatives have been developed that make modeling more intuitive. Conceptsthat are based on haptic interactions have become especially important,50 systemsfocusing on a more natural interaction, e.g. by using pens, enable a stronger focus onthe interaction rather than on formal aspects.8 Different techniques can be used torealize sketch-based modeling tools. In previous work whiteboards, tablets or digitalpaper technologies were used. The SILK system51 enables the fast creation of elec-tronic interfaces, by recognizing interface elements drawn with a pen. “Knight”15

supports the collaborative modeling of UML diagrams by sketching on an elec-tronic whiteboard. MaramaSketch52 supports the recognition of different types ofdiagrams.

Pen and paper-based user interfaces bridge the gap between the virtual andphysical world in order to make use of both.7 The creation of models and designsis a creative process, very often done by first making sketches on paper.51 Sketchesof models can be created quickly and without much effort.53 Instead of modelingin a rather formalized way, sketches on paper can easily be enriched with informalelements, such as comments or images. Un-experienced users usually contribute inthis way rather than in reference to a computer-based model,54 and this collabora-tive work can be supported by using large sheets of paper.7 Other advantages arethe familiarity with the media, the common access from different viewpoints andoptions to annotate and enrich the project in a collaborative and creative manner.On the other hand, paper is a static medium that does not offer options for feedbackand flexible re-creation of the content written on it.

2.5. Integrating the end-user: An interactive process

In order to empower end-users in adapting processes they are working with, our con-ceptual frame distinguishes between the complexity of the process, the complexityof the model and the complexity of the language. End-users with a profoundunderstanding of the complexity of the processes (their current work), normally


270 J. Hess et al.

have not expertise as modeling-experts. While formal modeling requires a differentkind of expertise (abstraction, using special tools, considering the complexity ofrelated activities, etc.), we explore alternative directions to reduce the complexityfor influencing processes. Easier options for end-users to reflect and express theirwork can be reached by reducing the complexity of the model. To support such userinvolvement, the complexity of the language needs to be adapted in a way thatuser can make sense of it. The interface to create and change the model (includeslanguage entities and visual representations as well) needs to be easy to understandand intuitive to use. At the same time the language needs to be powerful enoughto abstract with more formal elements. The resulting model does not need to becomplete in a sense that it automatically can be transferred to a system for processsupport. But as shared reference it can be used by modeling-experts further on tointegrate (sub-)models and support them by the system.

We have seen that the challenge of allowing end-users to understand, adapt andmanipulate adaptive software systems has been addressed by developing simplernotations. These nevertheless still are not to easy to use, as a certain level ofcomplexity is necessary to define the behavior of adaptive systems, and to supportthe interactions between actors, covering different aspects of the expertise necessaryto implement and change adaptive software. Neither of these strategies has ledto a complete success in integrating end-users, so we are specifically looking atthe question of how users understand and perform visual modeling using the box-and-wire-metaphor (Chapter 3), and how the interaction between end-users, moreexperienced users and modeling experts can be further simplified (Chapter 4).

3. End-User Process Adaptations: Understanding and Expressing

The aim of this study is to investigate how end-users articulate and reflect onbusiness processes they are involved in. This work presents an empirical study thattook place at an airport in Germany. We will present the adaptation practices inseveral departments that use a disposition system. To enable end-users to reflect ontheir processes and accomplish adaptations more easily, a business process modelinglanguage is needed. Such notation should also allow end-users without professionalIT training to model their processes and to change them accordingly. We conductedseveral explorative workshops with end-users and asked them to visualize businessprocesses from their current work. Without pre-structuring the activities, e.g. aswas done in the CARDS technique,34 we based our exploration on a plain box-and-wire metaphor. Based on an analysis of how users represented their processes, wededuced the requirements for an end-user friendly business process representation.Based on this, we present an intuitive notation, the end-user process language(EUPL), which was evaluated in the field. The aim of this language is not to enableend-users to model formal processes, but to articulate their view to the processmodelers.



3.1. Empirical study

In order to understand the organization and the practice of agents, we conductedan empirical study at a leading international service provider for the aviation indus-try/airport business. The company is the operator and owner of a major airport inGermany. Furthermore, they offer services in different areas of airport managementat other national and international airports. “Ground handling services” is a strate-gic business unit and is an important revenue driver of this company. The companymanages the handling of both people and luggage. They use a variety of softwaretools to monitor, plan, and schedule the processes that make an airport work. Thesystems handle some services autonomously and automatically, for other servicesthey just deliver visualizations and notifications that allow the ground staff actaccordingly. Nevertheless, the systems need to constantly be adapted as the orga-nizational environment changes, e.g. due to new safety regulations, construction atthe airport, or the changing needs of the airlines.

For our study, we focused on different actors, who deal with the software appli-cations and their adaptations on different levels. Besides explicit requirements, wewanted to explore other implicit requirements, such as informal information aboutbusiness processes. To understand the application field we used several methods: weconducted participatory observations, interviews and document analysis. In a firststep, we evaluated the business analysis documents of the departments (more than500 pages), system analysis documents, and decimations of the disposition systemsand the handbooks of quality management. Furthermore, to understand currentneeds, we read the requirements of a new disposition system. It became clear thatspecific abbreviations like ATA, KSS, HOT, AVI or Off-Block-Time, Walk-OutAssistant or Ramp-Agent made it difficult to understand the entire context. Fur-thermore, we conducted participatory observations: Aside from unstructured par-ticipatory observations of about 45 days, we conducted structured observations ofthe operation management of the disposition system (three days). Additionally, weconducted six semi-structured interviews55 with administrators of different depart-ments ranging from 27 to 92min, with an average time of 60min. The interviewswere recorded and transcribed. Afterwards we analyzed the material with regardsto the following questions: Who does the tailoring of the disposition system (role,education, IT expertise)? What are the reasons for tailoring? How is tailoring thedisposition system done? What are the limits of tailoring? How relevant is the tai-loring of business processes?

3.2. Tailoring in practice

In the field, it is possible to distinguish between several different roles: drivers, whodo operative work at the airport, like driving passengers from the airplane to theterminal, schedulers, who are responsible for the disposition of resources, such as thedrivers and buses, and system supporters, who are responsible for the maintenanceof the master data. After analyzing our data, we found several reasons for tailoring


272 J. Hess et al.

in the field. Some are based on new customer requirements, many are based onoperational requirements, while others are based on new security regulations, easyadaptations that consider the master data of the system. Actors adapt data of cars,airplanes, airlines, airplane types and other resources. These adaptations were doneby system support with the master data editor.

It is possible to distinguish between the adaptation of master data, rules andbusiness processes. These categories differ in the power of their tailoring function-ality and the tailoring expertise of the actor. MacLean et al.’s22 model about thetailoring of workers, local developers and programmers, coincides with this observa-tion. Our observed tailoring of master data, rules and processes can be transferredto this model (see Fig. 1). It shows that usually a lot of effort is needed if someoneon the level of master data adaptations wants to do adaptations on the level of rules;their own staff usually does both kinds of tailoring. Adaptations on the level of pro-cesses are usually done with the help of a software development company. However,it also became obvious that the company would like to be able to do adaptations onthe level of processes, thus making employees more flexible. An easy, user-friendlyprocess-modeling notation is a precondition for easy process adaptation. This canbe based on other descriptions, but it needs to be simple and easy to use for thetarget group of end-users, not just for developers. Therefore, the current practiceand knowledge of those actors needs to be considered.

3.3. Modeling workshop

In order to support employees with different roles and expertise in modeling, adescription needs to be easy to understand and use. The language also needs tobe powerful enough to enable system operators with different experiences to adaptand modify processes (compare Fig. 1). To develop the requirements for a processmodeling language, we used participatory design workshops.56 These workshopswere conducted at the work places of the system support. We asked three differentactors to model their business processes. Although all of them are system operators,

Master Data

Rules

Processes

Fig. 1. Adaptation of the disposition system on the different levels of the “Taylorability Moun-tain” (based on MacLean et al. 199022).



they each had different experiences in modeling. One of them had already accom-plished a course on modeling, while the other two were less experienced. First, theparticipants reflected on often-used transport services by drawing on paper withpencils in four different colors. In the second step, the same participants had todesign more complex processes with the box-and-wire metaphor, so they could usematerials from the first step and then edit cards of different colors (see Fig. 2). Weintroduced the cards and then gave some examples. We asked the participants todraw and explain what they were doing by thinking aloud. After finishing one task,the participants were interviewed with regards to the requirements for developing avery easy-to-use process language. Therefore, it was possible to add exceptions, spe-cial cases and coordination processes to their model. The duration of each workshopwas in average about 2 h.

3.4. Results from modeling workshop

The aim of the first step of the workshop (free modeling phase) was to understandhow participants draw services. During the workshop, the airplane carrying processwas modeled with participant A. In this process, the airplane is carried from oneplace to another at the airport before takeoff. Participant A was very inexperi-enced with process modeling and thought about it for quite a long time before hestarted to draw. He used boxes-and-wires: boxes for systems and then he addeddescriptions. Furthermore, he modeled only the standard process; he only addedexceptions after he was asked to (see Fig. 3, left, red circle). Participant B mod-eled an inbound bus transport process. This process coordinates the transport of

Fig. 2. Workshop with one system operator.


274 J. Hess et al.

Fig. 3. Overview about the free modeling of the airplane transportation process of participant A,the inbound bus transport process of participant B, the inbound luggage transportation processof participant C.

passengers from the field to the terminal. Since he was already a bit experienced inmodeling, he used boxes-and-wires in an efficient manner, and used different col-ors for different aspects. He first thought of how to draw the process and what hewanted to focus on, and then designed a good process model. The colors symbol-ized operative processes (blue), the confirmation status of the driver (green), thedemanded new status (red) and the exceptions (black). Participant C modeled aninbound luggage transportation process, it contained the transport of luggage fromthe field to the terminal. The process was based on a storyboard and he did notuse boxes and wires explicitly. He had drawn on a blackboard as done in school:The different aspects were explained in a structured way on the sheet, the resultwas not a process model, but a description of the process, and the different stepsinvolved.

In the second phase of the workshops, we wanted to test the use of boxes-and-wires more explicitly. The participants were asked to use pre-defined cards to drawthe processes. Participant A had to design the push-out-process, a process thatdescribes the steps involved when an airplane has to be towed to position to beable to start. Contrary to the first task, the participant understood the aim of the



second phase very quickly. To help him understand the process of modeling, somecards had already been prepared and covered existing events. After the participantwas asked, he also added exceptions. The task of participant B was to design aramp-direct-service, that brings passengers from one airplane to another, in casethere is little time between flights; this process is used when a plane is late and theairport management wants to avoid passengers missing their connecting flight. Theparticipant did not use the pre-designed cards, but designed his own cards. He usedcolored cards differently for different purposes. Participant C had to model a directtransfer process, which is when luggage has to be transferred from one plane to theother when passengers change planes. The participant used the cards, but did notdraw connections between them. He arranged them in a line and the activities weredrawn on the paper.

In general, the participants used the cards for events and activities very well.After we introduced boxes-and-wires, the quality of the results of the process model-ing increased and became more structured and clear (especially for participants Aand C, see Fig. 2). The box-and-wire metaphor is easier to use with pre-definedcards and should be a basis for a process modeling language. The box-and-wiremetaphor seemed to be easy to handle for our participants, especially when weasked the participants to do changes in the process.

3.5. Implications for the design of a common

process representation

Based on the results of the workshops, we identified several elements that needed tobe supported in an end-user process language. Business processes are understood asa sequence of steps, the models contain activities (process steps) and events (theirtrigger or the results). Therefore, these categories need to be supported. A specialevent is a gateway to other processes. Lines were used to draw connections betweenboxes. In addition, alternative and parallel processes were also used. Commentscontained other information relevant for the process.

None of the participants used Swimlanes, like in BPMN, which differ in theresponsibilities of different actors, departments and organizations. Also, the junc-tion and disjunction of processes like in UML, were not presented explicitly. Fur-thermore, XOR and OR, like in ARIS, were not used. Although many of theseconstructs may be necessary to maintain the logical completeness of a formal lan-guage, or to keep an overview in complex models for professional modelers, they maynot be necessary to describe the needs of end-users, and sometimes that may evenbe confusing. Based on our findings we recommend that different aspects should beconsidered when developing a process language.

R1: Box-and-Wire-Metaphor: The box-and-wire metaphor is an intuitive foundationfor a notation that enables system operators to reflect and model processes on theirown. Even though two of the three participants used this kind of modeling withoutany input from us, the results were clearer in the second step when we asked the


276 J. Hess et al.

participants to use them. Also other business process languages like ARIS or BPMNuse this metaphor, but with different boxes and lines. An end-user language shouldreduce this to the required minimum.

R2: Focus on the work practice of the user: If end-users model business processes,they mainly focus on their own work practice and model processes in which theyare involved. Therefore, this process might only represents one part of the overallprocess and is only easy to understand for the participant herself or himself. Ifan overall process has to be modeled, more participants could design the processcooperatively and thus create a more objective representation. We also observedthis in our workshop: in the RDS process both participants used gateways to otherprocesses. If those processes are combined, an overall process can be displayed.

R3: Events as the center of the process: One question in the analysis of the workshopwas what the center of the language could be. Based on the workshop, we thinkthat events are the center, because those were used in every case. Between thoseevents, activities can be added to enrich the process and to focus on specific details.

R4: Slim processes: Another very important demand of the process representationis the facility to understand the process easily. This concludes in a reduced amountof process elements to be easy to understand. Furthermore, this leads toward com-ments to explain difficult aspects of a process. Furthermore, a fixed direction of theprocess and not many exceptions make it easier to understand. If a process is toocomplex, a separation into several sub processes is necessary.

R5: Focus on standard processes: If end-users model processes, they should focuson the standard process. Operative business processes in the field of our studyusually follow a fixed model. We found that the participants understood the pro-cess better when it followed a fixed procedure. End-users should not try to add allpossible and improbable exceptions, which would make the process less easy andclear. These users are not very experienced in business process models, and there-fore these exceptions would make the whole process much harder to understandfor them.

R6: Design from the top to the bottom: Another question was what direction aprocess should follow. All processes were modeled from the top to the bottom ofthe paper. Process steps that followed another one, were drawn underneath the firststep. It was only when the paper was full that the participants started with a newcolumn. Alternative events were drawn horizontally.

R7: Predefined events and activities: In the second step of the workshops espe-cially participant A, who had no experience with process modeling, used pre-definedevents and activities. This enabled him to use the language in a proper way. Herealized the meaning of the elements — especially recurring events, and used them.A provision of probable elements can help end-users to start modeling. This is espe-cially important from the software adaptation perspective when existing elementshave to be included into other processes.



R8: Comments: An easy process model, based on box-and-wires, cannot containall important aspects that describe a process. Further, important aspects of the“context” can be added as comments. They can contain everything a user cannotexplain with the existing elements, e.g. information about regulatory environments,examples, informal exceptions or special cases.

The derived requirements lead toward an end-user process language (EUPL).This language could empower the user to draw, change and explain their processes.The focus of this language is not on formalizing the processes in a very detailedway, but to describe the process in a language familiar to the user.

The language itself consists of four different symbols. The centers are events,which are drawn as blue boxes. The events are connected with arrows. Events canbe marked with an “S”, representing a gateway. This enables one to distinguishbetween different responsibilities. Other boxes represent activities. They are rep-resented, as a green box with a double line on the side (see Fig. 4). They are notobligatory, but can be added between two events. It is also possible to add morethan one activity between two events. This language has no specific rules, like inARIS, where after each event an activity has to follow. In our language, eventsare the center and can be added with other elements. Furthermore, annotationsare possible, which can combine further descriptions or required resources, actors,systems or requirements. If after one event two arrows and two events follow, thisrepresents alternative or parallel processes. When using this language in softwareapplications, the software should ask the user if they are parallel or alternative. Wechose not to distinguish between alternative and parallel processes, because the aimwas to design the language as easy as possible and not with the aim of focusing ona technical interpretation of the created processes, but to explain them to processdesigners, who use them to create processes in required tools.

Event

Event

EventEvent-

Gateway

S

Comment

Condition Activity

Fig. 4. Elements of EUPL.


278 J. Hess et al.

3.6. Evaluation of a common process representation

To evaluate the end-user process language we designed the process models of theworkshop participants in EUPL and gave these representations to them. Based onthis, we did three interviews that lasted in average of 16min with each participant.All participants recognized their processes and understood the symbols. One partof the process model was a brief description of the different symbols. Participant Bsaid that the meaning of the symbols was also easy to understand without thedescriptions. Participant C mentioned that different colors for activities and eventswere very important. Participant B said that a differentiation of elements was good,but further differentiations would be “very circumstantial” and would result in asituation where “nobody knew what is meant with a symbol”. Participant A alsosaid that more differentiation would increase circumstantial representations. Allparticipants agreed that they could express all necessary elements related to theirbusiness processes, and that EUPL contained all important elements. Participant Bproposed that all activities could have a comment showing who is doing this activity.The other two participants wanted to use this only in special cases. Participant Balso proposed adding numbers to all elements, to be able to refer to them in com-ments. All participants agreed that events were the center of an operative businessprocess language. All participants also recognized the alternatives in the model.Participant C said, he would just model the standard process, “which takes placein 95% of all cases” to improve the clarity. To express alternatives, participant Bcriticized constructs as XOR, like in ARIS, because those would always be difficultto understand.

All participants thought other co-workers would understand these processes.All of them gave positive feedback and mentioned that the symbols were easy tounderstand and the overall usability of the language was good.

In general, we think that a representation like this can help bring business andIT closer together by providing an easy to use language based on boxes-and-wires.Participants were able to understand the process and judged the power of thelanguage to be big enough for their processes.

4. End-User Process Adaptation: Interaction Issues

As shown in the previous chapter, an easy to use representation can support end-users in the modeling of their work processes. An easy to understand notation,as presented in the form of EUPL in the chapter before, is a step toward a moreintuitive process handling. As another step we focused on new interactive conceptsfor modeling that also support the collaborative and creative character of a groupwork. While modeling with paper and pen seems to be a natural way of creatinga representation with formal and informal elements, we were interested in how acomputer-based adaptive system can support the process. In the following chapter,we will present the results of a collaborative process modeling session with paper and



pen, describe the developed adaptive system and draw implications by presentingresults of a small explorative evaluation.

4.1. An experiment in pen-based modeling practice

In order to understand the practice of pen and paper based processes modeling,we conducted a pre-study with three users, who only had little experience or noexperience at all in modeling. Participants should collaboratively sketch businessprocesses on paper already known to them. In some aspects, this study has similar-ities with the study described in the previous chapter. However, compared to thefirst case where each of the participants sketched models by her- or himself, herethe participants all sketched a model at the same time. Three people from a smalland medium sized company (SME) with around 150 employees attended this pre-study. None of them had formal expertise in modeling business processes, but askey users of SAP they all had solid knowledge of customizing internal SAP softwaresystems (see Table 1). Six people, involved in the research project, also attendedthe workshop in order to structure and guide the meeting, conduct interviews andmake field-notes/images. The five-hour workshop took place at the university andwas divided into two parts: an introduction and a design phase. The basis for themodeling process was a large writing pad with paper sheets the size of 1 × 1.40m(see Fig. 5). Additionally, different kinds of office supplies were available for themodeling session, including paper sheets in several sizes, post-its, colored pencilsand a board.

Table 1. Participants of the modeling workshop.

Participant Role Modeling Experience

P1 (male) Leader of the IT-department SAP key user, alreadymodeled in Microsoft Visio

P2 (female) Assistant of the executive board SAP key user, no advancedmodeling expertise

P3 (female) Purchasing manager SAP key user, no advancedmodeling expertise

Fig. 5. Boxes and wires (left) and design workshop.


280 J. Hess et al.

In the introduction phase, several business scenarios from the work domain ofthe participants, were discussed and specified. Afterwards, one of the scenarios waschosen for collaborative pen-based sketching. The chosen scenario was related to theplanning of order processes. In order to get an overview of all the product groups, acomplex list is necessary, which includes stock, change of stock, planned selling andcurrent selling. The relevant data can be found in different ERP modules and needsto be combined in a structured Excel list. Within that list, additional calculationsare necessary.

Before the start of the design phase, we introduced the box-and-wire model.On a large sheet of paper (1 × 1.40 meter) several actions were possible. Pre-prepared boxes cut out off paper, with an input and output port drawn on it, wereused as empty entities for events and activities. It was possible to position theseentities on the larger paper sheet and connect them by drawing lines between them.Additionally, annotations were possible by using pens with different colors.

At the beginning of the design phase, participants started to discuss the aimof the chosen business scenario as well as implications for modeling. As a firststep, a table with columns was drawn on the paper that represented the SAPmodules, where the relevant data could be found. In the following discussion, theparticipants started to think about how to represent the scenario on a box-and-wirelevel. They decided to use a separate box for each module involved. A summary ofthe sketched model is shown in Fig. 6. The input port of the box was annotatedwith keywords relating to the needed data, e.g. from SAP modules. Additionally,

Fig. 6. Representation of the sketched model.



the participants mentioned “experience” as a further source of information. Withthis annotation, the participants underlined the fact that experience was necessaryin order to calculate the correct planning. In this specific case, the planning processalso included trend predictions and estimations from the marketing department onnew trend colors. Such experience was mentioned as a human factor that cannot beautomated. The output ports of the boxes were annotated with the target format(mostly Excel). Further search, selection and transformation criteria were written inthe middle of the box. Participants also sketched event-driven connections betweenthe boxes, as e.g. indicated by the grey connection line in Fig. 6. This connectorwas labeled as the “watcher” — a process that supports the automatic updatingof data at the end of each month. Together with the output of other boxes theinput for the central calculation box was directed to a final box that representedthe combination of all relevant data within an Excel list. The numbers drawn onthe lines going to the final box, represent the ordering of the resulting columnswithin the list.

As shown in the previous chapter, the workshop provided insights into how end-users without special knowledge in modeling, represent and reflect relevant businessscenarios in an explorative way. By using a pen- and paper-based environment, theparticipants were able to “model” in an informal, collaborative and creative manner.Beside the formal elements provided (empty paper boxes), annotations (e.g. forthe ordering of the columns) and informal extensions (e.g. by using “experience”as input) of the process model were used to create the process representation.The workshop also showed that the prepared boxes were used for different things,e.g. for calculation, conditions and data sources. The method to model this way,was easy to understand, and the box-and-wire metaphor supported the processquite well.

4.2. Articulation support for conceptual modeling

From the experience gathered in pre-studies, several lessons were learned. It hasclearly been shown that paper-based modeling can be used as an easy-to-use andintuitive method, to let end-users express activities they are involved in. End-users — also with no or little experience in modeling — can articulate their work(and process steps) quite easily by sketching on paper and using the box-and-wiremetaphor. Many advantages of such a form of modeling became obvious, so ques-tions arose of how these paper-based modeling activities can be integrated in anIT-supported socio-technical modeling practice, where different stakeholders areinvolved. The focus system should support users in the collaborative creation ofa model, in the transformation into a digital representation, with the extensibilityand convertibility of the model, the computer generated feedback and guidance.The sketched model (the paper-based one as well as the digital representation) canbe used as a boundary object that mediates between members of different Com-munities of Practices (CoP) — especially between end-users and modeling experts.


282 J. Hess et al.

An ideal process flow includes three parts:

Step 1: End-users can reflect upon their work practice in collaborative modelingworkshops. Processes are sketched on interactive paper that allows theautomatic transformation into a digital (not necessarily formal) represen-tation. Users from different CoP and with different roles can also attend,in order to understand and/or guide the scenarios.

Step 2: The digital representation can be exported into different formats, so thatmodeling experts can continue working with the material, e.g. transform itto an executable workflow model. Formal parts of the sketch as events andactivities will be automatically transferred to the relating formal elements,so that modelers can check and correct them if necessary. In addition,informal elements will be recognized in order to provide meaning andremarks that are understandable to different stakeholders.

Step 3: The existing representations of the process (paper-based as well as thedigital one) can be further used as a boundary object that bridges theend-user and the developer domain. The representation can be connectedto the formal model in order to empower end-users, enabling them toinform other stakeholders about changes.

4.3. Supporting modeling interactions with a paper-based approach

As a first answer to dealing with pen-based input and transferring it to a digitalrepresentation, we would like to present an adaptive system that supports collabora-tive modeling. As a basic technology, we decided to use the digital pen technologyfrom Anoto (www.anoto.com). Small cameras at the tip of the pen capture theinput written on paper with a very fine dot pattern printed on it (the paper looksa bit greyish because of the pattern). The dot pattern makes every location (andevery pen mark) on every sheet of paper recognizable. The captured data can thenbe batched or streamed to a computer via Bluetooth. By choosing this technology,every user can be part of a collaborative modeling session with his or her own pen.Just as with a standard pen, modeling can take place by sketching on paper. Severalframeworks are available that support the creation of paper-based functionalities.In our case we chose the Paper Toolkit ,57 as an open source framework with highlevel API that already includes basic functionalities to support several pens, relatedevents and interaction modes. To recognize gestures, we chose the $1 Recognizer ,58

which allows for fast recognition without training. The recognition of text was han-dled by a Tablet PC Recognizer Pack,a which is included in the Microsoft TabletPC Platform SDK.b For the auditory feedback the Microsoft Speech API c was alsoused.

ahttp://www.microsoft.com/austria/windowsxp/tabletpc/muiprodguide.mspxbhttp://msdn.microsoft.com/en-us/library/ms840465.aspxchttp://www.microsoft.com/speech/speech2007/speechdevarticle.mspx



Fig. 7. Architecture of the pen and paper-based recognition system.

The architecture of the whole system is shown in Fig. 7. Input from the digitalpen will be transferred to the Pen Server, which handles low-level communicationvia pen and PC and then calculates the current position. The Pen Server can handleand identify several pens. The stored data is then transferred to the Ink Manager,which is responsible for the high-level calculation of the pen input. The activecontext is calculated based on the type of paper (analyzed by the Paper Manager)used, the kind of current modeled element (analyzed by the Recognition Engine),the relating pen and the current pen state. The result of that calculation is directedto the Process Manager, which inserts the element into a digital process model. Inorder to connect the virtual model with the physical region on the paper, resultsare then remapped to the Paper Manager. At the end of the calculation process,the Feedback Manager is triggered to activate an auditory or visual feedback. Theglobal file handling of load, save and export is done by the Persistence-Manager.

In order to support the creation of models in a flexible and dynamic form, theconcept uses different types of paper (see Fig. 8). A “process paper” is used asbackground for the modeling activities (1). The size of that paper can vary and beextended beyond any screen size. Events (red) and comments (blue) are representedwith post-its (4). These post-its can be positioned freely on the process paper.Drawing lines between the stickers will represent the process flow from one event toothers. Events and comments can also be drawn directly on the paper by choosingthe correlating process mode on the “action card” (3). However, in those cases theevent cannot be replaced. Every event can be further described with a “description


284 J. Hess et al.

Fig. 8. Elements of digital pen and paper-based interfaces.

of event” (2). Such a description is realized as a pre-structured questionnaire, wherefurther details, including name, event description, function, input and output-data,can be specified. Additionally, the already mentioned “action card” (3) providesan overview over all available process notations and pen commands. The usage ofdifferent sizes of process-paper and the simultaneous use of different pens at thesame time, enable spatial arrangements in a flexible manner, e.g. in collaborativeworkshop settings with many end-users.

4.4. Usage of the system

One advantage of the system is the synchronous (semi-)automatic creation of adigital representation of the sketched model. In order to bridge the physical anddigital domain, several design decisions had to be made for the feedback mechanism.As the digital pen does not provide sufficient feedback, a combination of visual andauditory feedback on a computer was chosen. Audio output indicates an error inthe automatic recognition of the modeling process. Feedback that is more detailedis realized through feedback dialogues that are shown in the corner of the digitalrepresentation screen (as shown in Fig. 9). The pens are marked with a color thatis related to the feedback dialogues on the screen. By using this color code, thecurrent state of each pen can be displayed.

The whole model is then transferred synchronously to a digital representationas shown in Fig. 10. Events, comments and annotations are represented in differentcolors to ease readability and to indicate if an element was recognized correctly.Even if linked to an event, the related description of the activity will not be dis-played. Every modification of the physical model needs to be explicitly defined byusing different states of the pen interaction. Removing an element requires choosingthe “delete” mode on the action card and to strike it out. Afterwards, the elementor the link (line) can be replaced (when a post-it was used) or re-drawn.

In order to support the exchange with other end-users and with modelingexperts, the digital representation of the sketched model can be exported in dif-ferent formats. In the easiest form, the model can be saved as an image. Such a



Fig. 9. GUI with visualization of recognized elements and feedback boxes.

Fig. 10. Same representation in the physical (left) and digital world after recognition (right).

form of representation is easy to access by others who are interested in the domain.The model can also be used as a foundation that can be further adapted to includemore complex options and integrate them into an existing IT support. The rep-resentation can also be converted into an XML file with a defined document typedefinition (DTD). As another option, the model can be exported to Marama inorder to enable a clear separation of formal and informal elements. By using theMarama sketching toolkit,59 the sketch can be transformed into different parts offormal elements. This way the model can be optimized and be used as an input formodeling experts who work with professional modeling tools (also compare Sec. 4.2,step 2).

The introduced system supports end-user and modeling experts in differentways. As already described in the introduction, a user may indicate changes to a


286 J. Hess et al.

given business process, e.g. as a result of an improved practice established over time.End-users mainly involved in those (sub-)tasks can meet with experts in a collab-orative brainstorming session. The paper-based sketch is automatically transferredinto a digital representation with formal and informal elements. Based on the repre-sentation, modeling experts can transform user-needs into a formal structure. Later,the end-user can indicate demands and needs for changes based on the sketch, e.g. ina collaborative manner, or based on the electronic representation, e.g. to highlightcontext-specific requirements. Concerning the importance, quality and quantity ofsuch requests, modeling experts and decision makers can decide to adapt the modelin order to synchronize it with the (best) practice. There may be different reasonsfor working with a shared reference, including process documentation, end-usertraining or quality management.

In order to adapt systems, the paper-based, as well as the digital representation,can be modified. For collaborative modifications, paper-sheets from previous brain-storming meetings can be used to remove entities or include new ones. The inputis then captured and the digital representation, with the recognized formal andinformal elements, will be updated as well. Changes can also be indicated individ-ually, by changing the digital representation directly. For further work interestingfunctionalities may include marker for recommendation, adaptation and sugges-tions. The (semi-)formal digital representation can be used as input for modelingexperts to transfer end-user indicated changes to the model which is executed bythe system.

4.5. Evaluating paper-based modeling interaction

The computer supported pen-based modeling and interaction concept was evaluatedin an expert walk through before testing it with users. In order to track down criticalincidents, several scenarios were tested. Based on these results the prototype wasfurther improved, e.g. by using a bigger font for the digital text or by providing morestable action cards made of heavier paper. After that, the system was evaluatedin a two-hour workshop with two users, who had already participated in the pre-study. Both participants (P1 and P3, see also Table 1) worked in small and mediumsized enterprise (SME). One of them was the manager of the IT department andalready had some knowledge in modeling processes with Microsoft Visio, while theother was manager of purchase with no advanced experience in modeling on a PC.Before the evaluation started, the system was introduced to the participants. Whileplaying around with the system, the basic functionalities, the process elements andpen states, were explained. The usage test was done in the form of a walkthroughbased on a collaborative scenario, where the participants were asked to articulatetheir thoughts (thinking aloud). After this test, separate semi-structured interviewstook place with a focus on personal opinions, satisfaction and usability. In order toanalyze the study later, the evaluation was recorded on video (user test) and audio(interviews).



For the scenario-based walkthrough, participants had to model a process fromtheir own working context in a collaborative manner using the system. In order toreflect and model freely and ad-hoc, the chosen scenario was related to a processfrom their everyday tasks. The scenario chosen included the creation of a newarticle in the set, which required several sub-processes, including an analysis of salesoptions, the creation of the article and relevant views in SAP, planning the amountof sales, the triggering of ordering processes, and a quality check and payment.While focusing on the modeling of sub-parts of the entire process, participants wereasked to express their thoughts, in order to understand issues and mental reflections.During the modeling phase, the participants were seated around a large, round tablewith access to the pen- and paper-based material described in the previous chapter.The pens were connected to a laptop, that also provided the audio feedback. Thegraphical interface of the resulting representation was projected on the oppositewall via a projector.

Participants only had few problems in modeling the process with the systemintroduced. The syntax and the meanings of the different process elements wereeasy to understand and therefore intuitive to use. As shown in Fig. 11 both modesof drawing (with and without post-its) were understood and applied. However, someproblems occurred, when post-its were re-positioned. It was considered to be lessintuitive when the connection from the post-it to the process-paper in the back-ground had to be removed by choosing the correlating pen mode and then crossingthe small connection line. The participants expected a mode to misalign elements,

Fig. 11. Sketched models in evaluation (left) and recognized digital representation.


288 J. Hess et al.

so that the post-it, with the correlating content, could be easily repositioned after-wards.

The good usability of the system overall, was confirmed through positive feed-back from the participants. “. . . It is only the question of dealing with the systemand practicing and then, when you know how it works, it becomes your secondnature.” In the beginning of the evaluation, participants had some problems tryingto get up to date on the current status of the pen. Even if the status of each penwas displayed on the screen, participants did not focus on it. “For me it was clear[that there were different statuses of the pen], but I did not pay attention to themat first, even though you can see the status in the top right window”. More directfeedback mechanisms, such as LEDs positioned on the pen to indicate its status,may ease the usability here. The audio feedback can support the process, if one ismodeling alone; in collaborative sessions, it is more irritating, as mentioned by oneparticipant. However, the idea of triggering a different status of the pen by choosinga symbol on the action card, and to then use the pen in different modes, was easyto understand and therefore appreciated by the participants as a “good solution”“that is easy”.

As one of the main issues, the realization of the feedback has to be consid-ered problematic. While the audio feedback was more irritating than helpful in thecollaborative session, the participants focused their work on the visual feedbackprovided on the wall via the projector. The participants constantly checked thecurrent status of the pen on the virtual image, which in the on-going session led toa stronger focus on the virtual representation, instead of simply brainstorming onpaper. It is also important to note that participants only used formal elements (seeFig. 11) and avoided making comments as done in the pre-study. One of the usersmentioned as a reason, that he tried to make a “clear” digital process model withoutinformal elements, but that this might change depending on the task. The informalbrainstorming character of the workshop was lost a bit, as the technological settingsuggested a less playful modeling behavior to the participants. The results visibleon the paper were also constantly checked on the wall as well. A deduction for fur-ther improvements refers to the organizational schedule of the workshop: it seemsto be valuable to separate the brainstorming phase on paper (sketching) from thedirection/correction phase of the recognized model (checking). Technically, our sys-tem would have also supported this type of collaboration. One of the participantscould shift the elements sketched on the paper to the digital form, e.g. by typingon activities or comments with the correlating pen status.

5. Integrating the End-User: Combining Easeof Expression with Ease of Interaction

Systems for process modeling, as they can be found in many adaptive enterprisesoftware tools, need to provide appropriate interactions to be able to remodel theprocesses for which they provide services. Software tools that support modeling



are normally mainly designed for expert use. The concepts of EUD enable end-users to adapt and reconfigure systems on their own,19 but the tailoring powerdepends on the skills that are required for the tailoring22 itself and most notationshave also been created to support modeling-experts.12–14 A broad functional rangethat operates on complex notations enables the creation of fine-granulated formalmodels that guide the workflow. However, the models, normally designed by model-ing experts, need to be (re-)adapted over time. Especially for knowledge work, suchconcepts need to be (re-)configured frequently, as processes are less structured androutinized. When a process is already modeled in a formal representation, end-usersnormally have no or little influence in the adaptation of that processes. Althoughemployees may be able to articulate and describe best the process context thathelps adaptive enterprise systems to deliver their services, they may not be able tomodel it in a formal sense. Employees can contact the modeling expert and ask forchanges, but important informal aspects, e.g. that are related to the personal expe-rience or that were identified in collaborative work practices, are not consideredor can be misunderstood due to(re-)interpretation by others, and the remodelingcycles may take more time than is available. User modeling in human computerinteraction60 tries to address this issue.

The big challenge we want to overcome with our research, is how to integrateall experts necessary to adapt enterprise software (end-users as domain experts,expert modelers and mediating actors), so that their expertise can be articulated ina sustainable way. Many of the approaches we mentioned in Sec. 2 worked out wellwith actors on the more professional end. With our concepts and studies, we aim toimprove the understanding and the options for actors at the other end of the scale.EUD techniques, such as programming by example24 or natural programming25

provide less complex commands. Visual programming adds virtual artifacts orientedat the application domain.26 In our studies, we looked at the intuitiveness andappropriateness of the box-and-wire-metaphor that is considered as the basis formost visual modeling languages (Sec. 3), and we looked for different interactionmodes with regard to a simpler, more collaborative modeling (Sec. 4). In two studies,employees with less experience in modeling were asked to reflect on their workpractice by sketching processes and using graphical representations. As shown inboth pre-studies, the pen-and paper based interaction proved to be a successfulway of sketching models in a more intuitive and creative way. Participants withless technical expertise in modeling were able to reflect on their work routines ina structured manner. The box-and-wire-metaphor was confirmed as adequate, butfor process modeling languages it may be helpful to provide room for structuredinformal model content as well, which may not be on the same level of abstraction,and may even be describing a very local use practice. Comments could be madeabout process executions that are just relevant for one department and not forthe organization as a whole. Again, this may not help the configuration of theadaptive system directly, but it may add to a user’s understanding of its innerworkings or to its being embedded in the user’s practice.


290 J. Hess et al.

Supporting use and configuration of enterprise software tools by appropriationsupport functionality (supporting collaborative appropriation61) and appropriationinfrastructures (means to also connect the designers21), can improve technology-related interactions among users as well as between users and designers. This workhas demonstrated that this interaction can be the key factor in achieving both: cor-rect configuration of software tools and also working configurations, as well as thetight-knitted integration of the changing needs of end-users into the software main-tenance loop. In this contribution, we wanted to address more fundamental issuesin end-user driven adaptation of process-centered enterprise infrastructures, as cur-rent tools for process modeling only provide weak support of a direct involvementof end-users.29

In order to integrate end-users, it is necessary to follow a dual strategy that com-bines “ease of expression” (using visual languages that allow end-users to expressand describe the process context an adaptive system has to function in) with “ease ofinteraction” (providing interaction concepts that allow end-users to become creativein modeling work). An adaptive system should not only provide means to model itscontext or behavior, but also support the interactions that need to happen betweenend-users and expert modelers in order to cope with continuous changing needsin enterprise software systems. The ways of expressing processes has also becomeimportant to the point, where such representations can be (re-)used to guide oth-ers, or to provide the best practice31 solution. Articulation support for end-usersshould consider formal and informal descriptions and representations for sub-areasof work practice, e.g. in supporting local groups of knowledge workers or providingthe best practice examples.

Taking the findings from previous works and our pre-studies as an implication fordesign, we encountered the question of how a computer-based system can supportsuch collaborative interaction by (semi-) automatically capturing and transferringit to a virtual representation as a foundation for further optimization, e.g. by direct-ing it to experts, sharing it with others, modifying or recreating it. As a first steptoward an easy solution for end-users, we presented a digital modeling tool thatbridges the physical and digital domain by transferring and linking paper-basedresults from collaborative brainstorming sessions to a semi-structured, formalizeddigital output. Our prototype is able to recognize formal and informal elementswritten on paper and to transfer them to a digital model that can be forwardedto formal process modeling tools and be re-used later on. It is important though,to recognize that process representations do not provide the only computationalbasis for the services the system provides.They also become a boundary object forreflecting on activities at work, and a medium for conserving experiences. End-users can use the paper-based model as a means for mediating the communica-tion with the modeling experts that support the adaptation in an e.g. more globalframework. As an artifact, they make the complex work organization of an enter-prise tangible, and the creativity that is invested during its creation forms a solidbasis for the acknowledgement and the acceptance of the adaptive services. They



may also foster the identification with the organization and its work practice asa whole.

The haptic interaction in the paper-based setting had particular advantages overscreen-based, and even touchscreen-based, interaction. It resembled other types ofcreative work in enterprises that virtually all users were familiar with. The hapticqualities also added to an atmosphere of creativity that cannot be established on aordinary computer screen, and even with large touchscreen displays the immediacyof touching and moving the material would be missing — these all are importantaspects to win end-users with low familiarity of interactive technologies. The paper-based process model is also almost indefinitely extensible, as more paper can beglued and connected to the model, visibility issues due to screen size do not apply,and screen input control and turn taking is not an issue when working collabo-ratively with paper. The introduced system supports collaborative modeling byadapting changes synchronously in the digital visual representation. Thereby therepresentation looks exactly like the physical model on paper; the characteristicsand creative character of the sketched output remains. By using the (re-)post-itmechanism the digital model of an already sketched process can be (re-)configuredin the original physical process. Based on the tool, further interesting developmentsare possible. Physical paper-based elements could trigger commands for executions,e.g. a notification for modeling experts if the paper-based model was modified toarticulate changes.

To better connect our approach with the work processes of expert modelers,modeling tools need to make transparent, how informal descriptions become formal.They also need to support visualizations in much simpler end-user process modelinglanguages that may even be ill-defined. A continuous, integrated maintenance ofend-users’ modeling expressions and modeling-experts’ actual process models alsofaces new challenges. User knowledge encoded in these expressions may be lessabstract and quite local to a certain usage context. While process models representgeneralized “global” descriptions that will be used by enterprise systems to providetheir services, the management of modeling data needs to respect these local spheresand hide comments or other informal information of local groups from each other.Adaptive systems should also show these representations if usage problems occurwhere these descriptions can help end-users to analyze their own mistakes, to discussnecessary adaptation or use a service breakdown to find a new requirement for thefurther development of the systems.

6. Conclusion

Modern organizations will strongly rely on IT in general, and on adaptive serviceinfrastructures in particular. Therefore, practitioners with little or no experience informal process modeling will need to become involved in articulation, adaptationand (re-)design activities. However, current systems are mainly designed for useby modeling experts. In order to also involve users with none ore little experience


292 J. Hess et al.

in modeling, information systems need to be designed with sufficient flexibility aswell as usability to enable end-users to (re-)model process descriptions.62 Whilethe choice of the abstraction level is crucial,39 visual metaphors can stimulatethe excitement and attention of the user.40 EUD approaches ease the process ofservice-(re)composition, e.g. FreEvolve platform44 or Simple Service Orchestration(SISO) — a graphical BPEL editor for service orchestration,63 but still are desigendfor modeling experts. In comparison to previous work, we focus on the involvementof end-users, in the sense of domain experts with no or little experience in modeling.In order to also involve these persons in the process of flexible service adaptation,easy to understand process notations and interaction modes are necessary.

In knowledge work, processes are changing quite often, depending on the cur-rent context. Thus, easy ways to modify and comment on process descriptions areimportant. Our paper identified important aspects in supporting the articulation ofcurrent processes by the end-user. A case study with end users based on paper andpen indicated that besides formal aspects, informal process descriptions are of highimportance. These findings underline earlier work48,49 by highlighting the necessityto express contextual issues through informal representations. In our case we wereable to show, that the use of visual languages based on the box-and-wire metaphorare helpful, but even on a language level the provision of informal and localiz-able structures and even free-hand drawing may contribute to making sense of thework in practice. Based on recommendations for an end-user description language,we established a concept based on a pen and paper-based interaction mode forprocess modeling that adds to an open, creative atmosphere and supports differ-ent modes of collaboration. The information on the physical paper-based artifactsof the brainstorming sessions, is automatically recognized and transferred into adigital representation, including formal and informal elements. Both process repre-sentations are related to each other and establish a common ground by acting as aboundary object among the different stakeholders. As an important characteristic,the system also supports (re-)use. Based on an evaluation with real practitionersfrom SMEs, we were able to conduct a first evaluation study, which resulted in anumber of improvements, such as better separation between a sketching mode anda recognition mode, or a more appropriate audio/video feedback during modelingsessions. As a further improvement, the system may allow end-users to indicateneeds for changes and improvements (on the physical and the digital model aswell), which automatically triggers notifications and proposed suggestions on theside of modeling-experts.

The studies and prototypes we described have to be considered as part of alarger research effort to prepare enterprise infrastructures in supporting their owncontinuous development. Activities of remodeling or reconfiguration do not onlyaffect the technological level of an infrastructure, but they also contribute to pro-cess of making sense and the appropriation of these technological artifacts. Thisphenomenon is conceptualized as “infrastructuring”.18 When designing modelinglanguages, environments, and techniques for process specifications, these insights



need to be considered to involve all levels of expertise (modeling and domain) in abetter way and to include all types of experts and end-users. With our environment,we have taken a step in this direction.

Acknowledgments

This research was supported by the German Federal Ministry for Education(BMBF) in the project EUDISMES and the German Research Foundation (DFG)in the project CONTICI. We thank Bjorn Borggrafe, Christian Dorner and MarkusHofmann for their contribution to this work.

References

1. G. Fischer, Symmetry of ignorance, social creativity, and meta-design, Knowledge-Based Syst. 13 (2000) 527–537.

2. P. J. Kammer, G. A. Bolcer, R. N. Taylor, A. S. Hitomi and M. Bergman, Techniquesfor supporting dynamic and adaptive workflow, J. Comput. Supported Coop. Work(CSCW ) 9 (2000) 269–292.

3. V. Levardy and T. R. Browning, An adaptive process model to support prod-uct development project management, IEEE Trans. Eng. Management 56 (2009)600–620.

4. H. Shinomi and S. S. Adams, Say goodbye to complexity when developing Web ser-vices — ADIEU: The End-user Computing Tool for Web applications and Web ser-vices. IBM ed. (2005).

5. C. Doerner, Tailoring Software Infrastructures: Integration of End-User Developmentand Service-Oriented Architecture (Josef Eul Verlag, 2010).

6. F. M. I. Shipman and C. C. Marshall, Formality considered harmful: Experiences,emerging themes, and directions on the use of formal representations in interactivesystems, J. Comput. Supported Coop. Work 8 (1999) 333–352.

7. G. Dai, Pen-based user interface, Proc. 8th Int. Conf. Computer Supported CooperativeWork in Design (2004), pp. 32–36.

8. J. Subrahmonia and T. Zimmerman, Pen computing: Challenges and applications,Proc. 15th Int. Conf. Pattern Recog. 62 (2000) 60–66.

9. B. Hedberg and S. Jonsson, Designing semiconfusing information systems for changingorganizations, Account. Org. Soc. 3 (1978) 47–64.

10. T. H. Davenport, Process Innovation: Reengineering Work Through Information Tech-nology (Harvard Business School Press, Boston, MA, USA, 1993).

11. C. Mielke, Geschaftsprozesse — UML — Modellierung und Anwendungs-Generierung(Spektrum Akademischer Verlag, Heidelberg, 2002).

12. S. A. White, Business Process Modeling Notation (BPMN) Specification 1.0. (2004).13. A.-W. Scheer, Architektur Integrierter Informations Systeme (Springer, Berlin, 1992).14. C. Ellis, K. Keddara and G. Rozenberg, Dynamic change within workflow systems,

Proc. Conf. Org. Comput. Syst. COCS 95 (1995) 10–21.15. T. Schummer, S. Lukosch and R. Slagter, Using patterns to empower end-users —

The oregon software development process for groupware, Int. J. Cooperative Inf. Syst.15 (2006) 259–288.

16. X. Liu, G. Huang and H. Mei, Towards end-user service composition, Proc. 31stAnnual Int. Computer Software and Applications Conf., Vol. 1 (COMPSAC 2007) 1(2007).


294 J. Hess et al.

17. G. Fischer and E. Scharff, Meta-design — Design for designers, Proc. Int. Conf.Designing Interactive Systems (2000), pp. 396–405.

18. V. Pipek and V. Wulf, Infrastructuring: Toward an integrated perspective on thedesign and use of information technology, J. Assoc. Inf. Syst. (JAIS ) 10 (2009)447–473.

19. H. Lieberman, F. Paterno and V. Wulf, End-User Development (Springer, Dordrecht,The Netherlands, 2006).

20. V. Wulf, V. Pipek and M. Won, Component-based tailorability: Enabling highly flex-ible software applications, Int. J. Human-Computer Studies 66 (2008) 1–22.

21. G. Stevens, V. Pipek and V. Wulf, Appropriation infrastructure: Supporting thedesign of usages, Proc. Second Int. Sympo. End-User Development (IS-EUD 2009)(2009) pp. 50–69.

22. A. MacLean, K. Carter, L. Lovstrand and L. Moran, User-tailorable systems: Pressingthe issues with buttons, Proc. SIGCHI Conf. Human Factors in Computing Systems:Empowering People, Seattle, Washington, United States (1990).

23. H. Kahler, More than WORDs — Collaborative tailoring of a word processor, J. Univ.Comput. Sci. (j.ucs) 7 (2001) 826–847.

24. H. Lieberman, Your Wish is My Command: Programming by Example (Morgan Kauf-mann, 2001).

25. B. A. Myers, J. F. Pane and A. Ko, Natural programming languages and environ-ments, Commun. ACM 47 (2004) 47–52.

26. N. Mehandjiev and L. Bottaci, User-enhanceability for organizational information sys-tems through visual programming, Proc. 8th Int. Conf. Advances Information SystemEngineering (1996).

27. W. M. P. van der Aalst, T. Basten, H. M. W. Verbeek, P. A. C. Verkoulen and M.Voorhoeve, Adaptive workflow — On the interplay between flexibility and support,Proc. ICEIS (1999), pp. 353–360.

28. W. M. P. van der Aalst, Generic workflow models: How to handle dynamic change andcapture management information? Proc. Int. Conf. Cooperative Information Systems(1999), pp. 115–126.

29. J. Mendling, H. A. Reijers and W. M. P. van der Aalst, Seven process modelingguidelines (7PMG), Inf. Softw. Technol. 52 (2010) 127–136.

30. A. Agostini and G. D. Michelis, A light workflow management system using simpleprocess models, J. Comput. Supported Cooperative Work 9 (2000) 335–363.

31. I. Davies, P. Green, M. Rosemann, M. Indulska and S. Gallo, How do practitionersuse conceptual modeling in practice? Data Knowledge Eng. 58 (2006) 358–380.

32. C. Ardito et al., Visual mediation mechanisms for collaborative design and develop-ment, Universal Access in HCI (2011), pp. 3–11.

33. L. G. Tudor, M. J. Muller, T. Dayton and R. W. Root, A participatory design tech-nique for high-level task analysis, critique, and redesign: The CARD method, Proc.HFES’93 (1993).

34. M. J. Muller, Layered participatory analysis: New developments in the CARD tech-nique (2001).

35. D. Lafreniere, CUTA: A simple, practical, and low-cost approach to task analysis,Interactions 3 (1996) 35–39.

36. A. Klær and K. H. Madsen, Participatory analysis of flexibility, Commun. ACM 38(1995) 53–60.

37. K. Halskov and P. Dalsgard, Inspiration card workshops, Proc. 6th ACM Conf.Designing Interactive Systems. DIS ’06 (2006), pp. 2–11.



38. E. Beck, M. Obrist, R. Bernhaupt, M. Tscheligi and T. Cedex, Instant card technique:How and why to apply in user-centered design, Proc. Particiapatory Design Con.(2008), pp. 162–165.

39. B. A. Nardi, A Small Matter of Programming — Perspektives on End-User Computing(The MIT Press: Cambridge, 1995).

40. Y.-C. Hsu, The Effects of Visual Versus Verbal Metaphors on Novice and ExpertLearners’ Performance. Human-Computer Interaction, Vol. 4 (Springer, Berlin, 2007),pp. 264–269.

41. A. F. Blackwell, The reification of metaphor as a design tool, ACM Trans. Comput.Human Interaction 13 (2006) 490–530.

42. A. F. Blackwell, N. Kirsten, K. N. J. Whitley and M. Petre, Cognitive factors inprogramming with diagrams, Think. Diag. (2001), pp. 95–114.

43. P. T. Cox and B. Song, A formal model for component-based software, Proc.IEEE 2001 Symp. Human Centric Computing Languages and Enviroments (HCC’01)(2001).

44. M. Won, O. Stiemerling and V. Wulf, Component-based approaches to tailorablesystems, End-User Development (2006), pp. 115–141.

45. F. Daniel, S. Soi, S. Tranquillini and F. Casati, From people to services to UI: Dis-tributed orchestration of user interfaces, Proc. BPM (2010), pp. 310–326.

46. M. Costabile, P. Mussio, L. P. Provenza and A. Piccinno, Supporting end users tobe co-designers of their tools, Proc. 2th Int. Symp. End-User Development (2009),pp. 70–85.

47. L. Strachan, J. Anderson, M. Sneesby and M. Evans, Minimalist user modelling ina complex commercial software system, User Model. User-Adapted Interaction 10(2004) 109–146.

48. T. Hermann, Communicable models for cooperative processes, 7th HCI Int. Designof Computing Systems: Cognitive Considerations (1997), pp. 285–288.

49. S. S. Hussain, D. Veiel, J. M. Haake and S. Lukosch, Integrating context-enrichedexplanations und communication in an adaptive collaboration environment, Group-ware: Design, Implementation, und Use: 16th Int. Workshop (CRIWG 2010) (2010).

50. G. Iacucci, V. Pipek, G. Jacucci and K. Kuutti, Continuing design in use of tangiblecomputing environments, The Good, the Bad and the Irrelevant — The User andthe Future of Information and Communication Technologies (COST 269 Conference)(2003), pp. 209–216.

51. J. A. Landay and B. A. Myers, Interactive sketching for the early stages of userinterface design, Proc. SIGCHI Conf. Human Factors in Computing Systems (1995).

52. J. Grundy and J. Hosking, Supporting generic sketching-based input of diagrams in adomain-specific visual language meta-tool, Proc. 29th Int. Conf. Software Engineering(2007).

53. M. Nakagawa, N. Kato, K. Machii and T. Souya, Principles of pen interface designfor creative work, Proc. Second Int. Conf. Document Analysis and Recognition (1993),pp. 718–721.

54. T. Winograd, From programming environments to environments for designing, Com-mun. ACM 38 (1995) 65–74.

55. D. W. Randall, R. H. R. Harper and M. Rouncefield, Fieldwork for Design: Theoryand Practice (Springer, London, 2007).

56. F. Kensing, J. Simonsen and K. Bødker, MUST — A method for participatory design,Proc. Fourth Biennial Conf. Participatory Design (1996), pp. 129–140.

57. R. B. Yeh, S. R. Klemmer and A. Paepcke, Design and evaluation of an event archi-tecture for paper UIs: Developers create by copying and combining, Technical Report,Stanford University Computer Science Department (2007).


296 J. Hess et al.

58. J. O. Wobbrock, A. D. Wilson and Y. Li, Gestures without libraries, toolkits ortraining: A $1 recognizer for user interface prototypes, Proc. 20th Annual ACM Symp.User Interface Software and ACM (2007).

59. J. Grundy, J. Hosking, L. Li and N. Liu, Performance engineering of service com-positions, Proc. Int. Workshop of Service-Oriented Software Engineering (2006),pp. 26–32.

60. G. Fischer, User modelling in human-computer interaction, User Model. User-AdaptedInteraction 11 (2004) 65–86.

61. V. Pipek, From Tailoring to Appropriation Support: Negotiating Groupware Usage,Ph.D. Thesis, Oulu, Finland, 2005.

62. C. Doerner, S. Draxler, V. Pipek and V. Wulf, End users at the bazaar: Designingnext-generation enterprise-resource-planning systems, IEEE Softw. 26 (2009) 45–51.

63. C. Doerner, F. Yetim, R. Singh and V. Pipek, SISO — A process design environmentfor business users, European Conf. Information Systems (2010).

supporting end-user articulations in evolving … · notations seem to be quite complex. all of...

Documents