Content uploaded by Keith Harrison-Broninski
Author content
All content in this area was uploaded by Keith Harrison-Broninski on Mar 23, 2019
Content may be subject to copyright.
Metadata of the chapter that will be visualized online
Chapter Title Dealing with Human-Driven Processes
Copyright Year 2014
Copyright Holder Springer-Verlag Berlin Heidelberg
Corresponding Author Family Name Harrison-Broninski
Particle
Given Name Keith
Suffix
Organization Role Modellers Limited
Address Bath, UK
Abstract Current BPM deployments focus on routine work and low level
knowledge work, lacking integration with higher level knowledge
work such as research and development, marketing, complex sales,
services delivery, complex problem resolution, organizational change,
new initiatives and other strategic management activities. To gain full
benefit from operational improvement via a process approach, higher
level knowledge work must also be brought under process control and
integrated with lower level operations (For a report on the evolution of
BPM also see Harmon (The scope and evolution of business process
management. In: vom Brocke J, Rosemann M (eds) Handbook on
business process management, vol 1, 2 edn. Springer, Heidelberg, 2014)
in the first volume of this Handbook). However, this requires a new
approach to process management – one that not only has the right
balance of structure and flexibility, but that also allows collaboration
across internal and external organizational boundaries. As a solution,
this paper presents a means of describing adaptive, collaborative human-
driven processes, and supporting them with software, that streamlines
interactions between colleagues to reduce costs, focuses on goals to
be more effective, and improves organizational memory by tracking
work, keeping the knowledge and re-using best practices. The approach
is based on the theory of Human Interaction Management (HIM),
which facilitates the management of teams, communication, knowledge,
time, and plans. HIM also shows how to automate processes involving
human collaboration across organizational boundaries of any kind.
HIM can be introduced into the enterprise, and integrated with both
organizational strategy and mainstream BPM, via supporting Human
Interaction Management System (HIMS) technology and an associated
change management methodology, Goal-Oriented Organization Design
(GOOD).
1Dealing with Human-Driven Processes
2Keith Harrison-Broninski
3Abstract Current BPM deployments focus on routine work and low level knowl-
4edge work, lacking integration with higher level knowledge work such as research
5and development, marketing, complex sales, services delivery, complex problem
6resolution, organizational change, new initiatives and other strategic management
7activities. To gain full benefit from operational improvement via a process
8approach, higher level knowledge work must also be brought under process control
9and integrated with lower level operations (For a report on the evolution of BPM
10also see Harmon (The scope and evolution of business process management. In:
11vom Brocke J, Rosemann M (eds) Handbook on business process management, vol
121, 2 edn. Springer, Heidelberg, 2014) in the first volume of this Handbook AU1).
13However, this requires a new approach to process management – one that not
14only has the right balance of structure and flexibility, but that also allows collab-
15oration across internal and external organizational boundaries. As a solution, this
16paper presents a means of describing adaptive, collaborative human-driven pro-
17cesses, and supporting them with software, that streamlines interactions between
18colleagues to reduce costs, focuses on goals to be more effective, and improves
19organizational memory by tracking work, keeping the knowledge and re-using best
20practices. The approach is based on the theory of Human Interaction Management
21(HIM), which facilitates the management of teams, communication, knowledge,
22time, and plans. HIM also shows how to automate processes involving human
23collaboration across organizational boundaries of any kind. HIM can be introduced
24into the enterprise, and integrated with both organizational strategy and mainstream
25BPM, via supporting Human Interaction Management System (HIMS) technology
26and an associated change management methodology, Goal-Oriented Organization
27Design (GOOD).
K. Harrison-Broninski (*)
Role Modellers Limited, Bath, UK
e-mail: khb@rolemodellers.com
J. vom Brocke and M. Rosemann (eds.), Handbook on Business Process Management 2,
International Handbooks on Information Systems, DOI 10.1007/978-3-642-45103-4_24,
©Springer-Verlag Berlin Heidelberg 2014
28 1 Introduction
29 Current mainstream BPM practice derives from techniques developed throughout
30 the twentieth century to improve business operations, starting in the 1910s with
31 Scientific Management (Taylor 1911), then continuing in the 1930s with Statistical
32 Quality Control (Shewhart 1931), developing in the 1950s and 1960s into Total
33 Quality Management (Deming 1950; Ishikawa 1968), and resulting by the 1980s in
34 Lean Manufacturing (Ohno 1988) and Six Sigma (Harry 1988), which were subse-
35 quently combined into a unified methodology Lean Six Sigma (George 2002). AU2
1
All
36 these techniques were designed for the improvement of routine and repetitive work,
37 typically production processes such as manufacturing.
38 This background is reflected by the notations developed to support process
39 analysis, of which the latest, and the current de facto standard in everyday practice,
40 is BPMN (Object Management Group 2011). All such notations assume that a
41 process is essentially a set of operations that control the movement of inputs from
42 one state to another until they result in outputs, typified by the assembly of a product
43 in a factory or the handling of an insurance claim by low level knowledge workers.
44 Modern process notations allow parts of the process to take place in parallel, and
45 elements of the process to be grouped together, resulting in the formal treatment of
46 a process as a concurrent, hierarchical, finite state machine.
47 While it may appear to be possible to adapt such techniques and notations to
48 handle collaborative, adaptive human work, there are serious limitations that
49 become apparent very quickly. Higher level knowledge work such as research
50 and development, marketing, complex sales, services delivery, complex problem
51 resolution, organizational change, new initiatives and other senior management
52 activities not only requires the right balance of structure and flexibility, but also
53 must allow collaboration across internal and external organizational boundaries.
54 These requirements introduce new dimensions that are not catered for by main-
55 stream BPM notations. Consider, for example, the following questions, which
56 someone might ask when presented with a BPMN diagram describing a collabora-
57 tive, adaptive process in which they are expected to play a part.
58 What are my goals and responsibilities? A swim lane is simply a grouping of
59 activities – it is not an organizational role, with associated contextual information.
60 Fundamental aspects of knowledge work (acceptance of responsibility, capabilities,
61 personal characteristics, and so on) are quite literally out of the picture. This is a
62 particular problem with regard to delegation of assigned work.
63 How do I know what is required from my deliverables? With only a task
64 description to go from, a knowledge worker has no idea on what basis their work
65 will be reviewed, or even by whom, meaning they cannot understand the criteria
1
As to he relation between Process Management for Knowledge Work also see the chapter of
Davenport (2014) in the first volume of this handbook. The role of people is also highlighted by
Hammer (2014) and further conceptualized by Rosemann and vom Brocke (2014) in the first
volume.
K. Harrison-Broninski
66that will be applied to approve it. Similarly, a diagram shows no indication of the
67policies, regulations and other constraints to which their work must conform.
68Does everyone in this process have appropriate skills, experience, and person-
69ality type? A diagram provides no information about who is involved, so gives the
70false impression that collaborative work is somehow independent of the people
71carrying out the activities and of their interactions.
72What if I need help? If producing specific deliverables turn out to be too much
73work in the time available, the assigned person may need to work with someone
74else – but a diagram offers no means to achieve this. For example, there is no way to
75add more players of a certain role in a BPMN process, or more generally, adjust the
76resource levels assigned to a work package. It is hard even to imagine how the
77notation could be extended to support the notion, as the formal principles on which
78BPMN is based do not support such a concept. Yet human resource planning is
79fundamental to the management of collaborative work.
80What if I need to discuss matters with colleagues? To prepare deliverables a
81worker may need to discuss them with colleagues prior to submission, in a struc-
82tured way – but a process diagram does not allow the depiction of interactive, multi-
83party communication channels (only one-off messages sent from one pool to
84another as part of a workflow). Message flow in BPMN, for example, is limited
85to a single, one-way sending from one pool to another. The sending can be repeated
86if the appropriate looping constructs are used, but it is very hard to depict message
87flow between more than two parties, and any attempt to reproduce the flexible
88manner in which people exchange messages is doomed to failure. Mainstream
89Business Process Management System (BPMS) software typically deals with this
90limitation by treating message exchange between colleagues as outside the work
91process itself – i.e., as an ad-hoc activity on which no structure can (or needs to) be
92placed. In other words, what is perhaps the most fundamental aspect of knowledge
93work – human interactions – is relegated to floating around under the organizational
94radar, in an unmanageable backwater.
95What if work additional to that shown is necessary to prepare my deliverables?
96A deliverable is often just the tip of the iceberg compared to the research, evalu-
97ation, and analysis that underpin it, and such associated activities tend to be hard to
98predict in advance – a process diagram does not allow these activities to be created
99and adjusted, or recognition to be gained for the mental work involved in carrying
100them out. This not only hinders but also demotivates knowledge workers.
101What supporting information do I need, and where can I get it? Knowledge work
102typically relies on a variety of associated reference materials, but a process diagram
103shows only activity inputs and outputs – meaning that knowledge workers struggle
104to identify the necessary resources, to determine what form they are in, where to
105find them, and how to access them (e.g., to obtain the account details for their
106organization’s subscription to a technical journal containing relevant articles).
107These are only examples of the sort of questions that mainstream BPM notations
108fail to answer. The result of this failure is that critical processes involving collab-
109orative, adaptive human work are poorly managed by many organizations, as shown
110in Fig. 1.
Dealing with Human-Driven Processes
111 At the top of Fig. 1is a grid of the different process types within a single
112 organization, showing the technique appropriate to support each process type:
113 • Step-by-step work in which the sequence of steps can be predicted – for
114 example, manufacturing, licensing or order fulfilment – is generally described
115 using a flowchart-based notation (such as BPMN) and supported using Business
116 Process Management or Workflow systems.
117 • Step-by-step work in which the steps and their sequence adapt to the situation at
118 hand – for example, claim processing, medical diagnosis or invoice discrepancy
119 handling – is generally described again using a flowchart-based notation but this
120 time supported using Case Management systems.
121 • Work in which deliverables are provided through collaboration rather than each
122 person carrying out steps individually, but is nevertheless predictable – for
123 example, laying an oil pipeline or building a power station – is generally
124 described using a Work Breakdown Structure and supported by Project Man-
125 agement systems.
126 • Work that is both collaborative and adaptive – which may in fact represent a very
127 large proportion of organizational activity, since it includes areas such as
128 research & development, marketing, complex sales, services delivery, complex
129 problem resolution, merger & acquisition, and organizational change – is gen-
130 erally not described in any formal way but rather using documents and illustra-
131 tive diagrams. As a result, it is not supported by specific systems, but rather left
132 to fend for itself in a minefield of workplace technologies such as email and
133 content management systems.
Fig. 1 The process gap
K. Harrison-Broninski
134Figure 1shows how this problem and the resulting technology support gap exist
135not only for collaborative, adaptive processes within a single organization, but for
136collaborative, adaptive processes that cross organizational boundaries – as they
137typically do.
138To remedy the situation, the theory of Human Interaction Management (HIM)
139was developed to streamline interactions between colleagues to reduce costs, allow
140focus on goals to be more effective, and improve organizational memory by
141tracking work, keeping the knowledge and re-using best practices (Harrison-
142Broninski 2005a “Human Interactions – The Heart And Soul Of Business Process
143Management”). A HIM “Plan template” – i.e., a set of Stages in which people play
144Roles to provide deliverables – is a natural, intuitive way to structure adaptive,
145collaborative work. Further, if a process is implemented as a HIM “Plan” via a
146Human Interaction Management System (HIMS), its participants can use different
147HIMS servers – or even regular email – to work together in a structured, manage-
148able way across professional, geographical and organizational boundaries.
149However, for many people it is hard to distinguish the different types of work
150process. Where exactly should one apply each type of process description tech-
151nique, and use each type of technology? It can be particularly difficult to separate
152adaptive work processes into step-by-step and collaborative, since even adaptive
153processes that are step-by-step typically involve multiple people (each carrying out
154their own set of steps).
155A simple solution is to use an analogy to classify “adaptive” processes as either
156“step-by-step” or “collaborative”. Consider what happens when you build a Lego
157model as compared to what happens when you cook a stew. When you’ve com-
158pleted a Lego model, you can still see the parts – and each part is the same as it was
159when you took it out of the box. With a stew, you can detect (most of) the
160ingredients by tasting it – or even just looking at it – but you cannot disassemble
161the stew into its components.
162In other words, the constituents of the stew have been changed by the process of
163cooking, into something new – something that is quintessentially to do with that
164particular stew, and the chemical reactions that took place during cooking. A sea
165change has taken place, into something rich and strange. It may or may not be
166possible to repeat the sea change on future occasions – and the ability to do so is part
167of the learning curve a chef goes through. But one thing is sure – you cannot undo
168the sea change for a specific stew, and isolate each ingredient in its original form.
169Making an analogy with human work, collaboration between the people (typically
170members of a virtual team) who carry out an adaptive process changes the original
171elements of that process irrevocably.
172So this is how to tell the type of an adaptive work process: once it is complete,
173can you look back and identify what took place as being exact sequences of steps
174copied from standard templates? Or have the virtual team members used the
175original template processes as illustrative guides rather than prescriptive instruc-
176tions – changing, repeating, adding and omitting steps as required by the situation at
177the time, based on their skills, experience and collective judgement? If the step
178sequences are identical to their original templates, your adaptive process is “step-
Dealing with Human-Driven Processes
179 by-step”, and you could consider using a BPM or Case Management system to
180 support it – as long as it all takes place within a single organization, that is. If on the
181 other hand your process changes the template steps – or involves multiple organi-
182 zations – then you are in the territory of HIM and its supporting technology
183 the HIMS.
184 In a HIM process, as John Seely Brown said, “processes don’t do work, people
185 do” (Brown and Gray 2005). BPM, Case Management and Project Management are
186 about tasks. HIM is about virtual teams – and, depending on the scale, often about
187 what might be thought of as virtual enterprises. Many projects, programmes,
188 initiatives, ventures, or other collaborative efforts involve people from multiple
189 organizations, with multiple professions, in multiple locations. Effectively, each
190 such effort results in the creation of a dedicated virtual enterprise – and the
191 management structures required to ensure that a virtual enterprise achieves its
192 desired goals are non-trivial.
193 The UK healthcare advisory organization The King’s Fund (www.kingsfund.
194 org.uk) provides a useful discussion of the issues associated with such a virtual
195 enterprise, which it terms an “extended enterprise”, in its analysis of 12 pilot
196 projects between 2008 and 2011 to introduce new technology into UK health and
197 social care (“the WSDAN sites”). In particular, the authors explain how the issues
198 are not simply those of communication (i.e., data sharing) but more widely of
199 collaboration (i.e., purposeful interaction):
200 When organizational and, by implication, individual goals are different, how can they be
201 brought into equilibrium? It is not enough to settle on standards; what is needed is a
202 different way of conceptualizing the combined services so that data could flow from one
203 service sector to another (possibly incorporating user-held data), and be used to the benefit
204 of users, patients, and other stakeholders. One approach might be to view integrated social
205 and health care as an example of an extended enterprise – a loosely coupled, self-organizing
206 network of organisations that combine their services to provide new products or services to
207 a specific market [Ross et al. 2006]. This, perhaps, largely describes the current relationship
208 between telehealth and telecare projects and their commercial partners and collaborators at
209 the 12 WSDAN sites – it certainly describes those sites that are involved in forming social
210 enterprises, trading arms and other service configurations. This arrangement, however,
211 lacks the ability to answer the questions, ‘What should the objective function of this
212 enterprise be? Who is responsible for delivering quality of outcomes and for managing
213 budgets? How can such responsibilities be enforced?’
214 It is not uncommon to ask the first two questions, but the third is often neglected. The
215 third question, however, is critical, and should be asked before any telehealth/telecare
216 equipment is deployed in someone’s home, because its answer leads to the programme’s
217 governance structure. In their landmark paper on the theory of the firm, Jensen and
218 Meckling [1976 AU3] view the organisation as nothing more than a nexus of contracting (both
219 implicit and explicit) relationships that, among other things, control individuals and help to
220 ensure that individual and group activities meet the needs of stakeholders. The contractual
221 relationships are important because they make explicit who the stakeholders are, and the
222 limits and types of individual and groups activities that serve stakeholder interest.
223 Jensen and Meckling write that this view of the firm is not limited to corporations, but to
224 any organisation:
225 This includes firms, non-profit institutions such as universities, hospitals, and founda-
226 tions, mutual organisations such as mutual savings banks and insurance companies and
227 co-operatives, some private clubs, and even governmental bodies such as cities, states, and
K. Harrison-Broninski
228the federal government, government enterprises such as ...the Post Office, transit systems,
229and so forth.
230So, the data management problems that the WSDAN sites face highlight a larger
231problem concerning the overall governance of their programmes.
232[Giordano et al. 2011]
233This governance problem is not limited to healthcare, or to the public sector. It
234applies in all walks of life. Whether you are organizing a small town festival, laying
235an oil pipeline, or sending a rocket to Mars, you need to “make explicit who the
236stakeholders are, and the limits and types of individual and groups activities that
237serve stakeholder interest.” In other words, you must find a way to show who is
238involved and what each person is responsible for. Until you do this, there is little
239chance that the responsibilities will be enforced appropriately and hence that people
240will deliver what is required of them in order to meet the goals of the effort.
241This is a process-related question, but not one that can be solved using traditional
242BPM or case management techniques. Stakeholder responsibilities cannot be help-
243fully described or managed using flowchart notations or by assigning tasks in
244isolation. Rather, it is necessary to depict in a simple way:
2451. The overall goal and sub-goals of the collaborative effort
2462. The stakeholders in each sub-goal (i.e., those with an interest in achieving it)
2473. The nature of each stakeholder’s involvement – in RACI terms, whether they are
248Responsible, Accountable, Consulted or Informed
249In the Human Interaction Management approach to collaborative work, these
250items become a Plan containing Stages,Roles,Activities and Deliverables:
2511. A Plan represents a collaborative activity with shared high-level goals.
2522. A Stage represents a sub-goal of the Plan. If you are included in a Stage, then
253you have an interest in achieving it, so you will receive its outputs and be on in
254its messaging channel. The current status of each Stage represents its progress
255(“Not Started”, “Started”, “Completed”, “Cancelled”, “Issue Raised”, and so
256on).
2573. A Role is a Plan-specific job title. The Roles assigned to you define your
258responsibilities in each Stage that you are included in. You use a Role to
259contribute to the work of each such Stage, or simply influence Stage progress
260via messaging.
2614. An Activity is how a Role contributes Deliverables to a Stage. An Activity may
262have inputs, such as the outputs (i.e., deliverables) of other Activities or refer-
263ence materials to support its execution. If an Activity is just for review purposes,
264there may be no outputs as such – review comments can be submitted via Stage-
265specific messaging.
266The Stages, Roles and Activities may well change during the life of a Plan, as the
267Plan owner responds to circumstances by adjusting the way the work is to be carried
268out, often in response to advice and suggestions from other Plan members. A Plan is
269typically made from a standard template, and then evolves throughout its life – and
270the final version of the Plan can then be re-used as a template if desired.
Dealing with Human-Driven Processes
271 In the remainder of this paper, we show how to introduce HIM into the enter-
272 prise, and integrate it with both organizational strategy and mainstream BPM via an
273 associated methodology, Goal-Oriented Organization Design (GOOD). The fol-
274 lowing sections present:
275 • Some example HIM Plan templates;
276 • An overview of HIM theory;
277 • Description of the supporting HIMS technology;
278 • The supporting change management methodology, Goal-Oriented Organization
279 Design (GOOD);
280 • A case study of enterprise HIM usage;
281 • Conclusions drawn.
282 2 Example HIM Plan Templates
283 Figure 2shows an example Plan template illustrating how the HIM approach can be
284 used to run a transformation programme for a local authority via the Agile meth-
285 odology Scrum:
286 As captioned on the screenshot, on the left hand side you can see the various
287 Stages (sub-goals) of the work. The first two Stages are Scrum-specific, and run
288 throughout – to manage the Product and Spring Backlogs respectively (i.e., the
289 work required overall and in the current Sprint). Each of the other Stages is specific
290 to a service area of the local authority, and contains artefacts relating to that specific
291 aspect of the overall change programme.
292 Also as captioned on the screenshot, on the right hand side you can see the Roles
293 involved in the currently selected Stage – in this case, Manage Sprint Backlog. In
294 this Stage, only the Scrum Master has work to do:
295 • “Prepare Next Sprint”, which delivers the Sprint Backlog
296 • “Manage Burn Down Chart”, which delivers the Burn Down Chart (the work
297 remaining in the current Sprint).
298 The other Roles in this Stage are the Product Owner (typically the executive with
299 responsibility for the change programme), the Programme Office (the administrator
300 for the change programme) and people with responsibility for different aspects of
301 the change programme (planning, risks, issues, change, finance and configuration).
302 None of these have work to do in the selected Stage, but are included in it so that
303 they have visibility of the Sprint Backlog and Burn Down Chart, and can contribute
304 to the Stage by receiving and sending messages on its channel.
305 The other Stages have specific Roles and Activities of their own, out of scope
306 here due to space restrictions.
307 Figure 3shows an example Plan template illustrating how the Human Interaction
308 Management approach can be used to streamline a commercial Sales Bid – typi-
309 cally a pressurized undertaking with a tight timescale:
K. Harrison-Broninski
310Here the selected Stage is “Create Opportunity”. At this point, the lead has been
311qualified as worth pursuing, and the Nominated Sales Lead has the responsibilities
312to assess the client, arrange a follow-up meeting and record progress on the CRM
313system.
314The Lead Owner has no deliverables in this Stage, but will follow progress
315closely and may contribute advice throughout the Stage.
316There are other Roles in this Plan – Sales Manager, Technical Expert, Commer-
317cial Authority, and so on – but none of these are included in the Stage “Create
318Opportunity”. The responsibilities of these Roles are specific to other aspects of the
319work (i.e., other sub-goals) so they only see what is of interest to them. In other
320words, they are not deluged with unnecessary messaging in the usual way.
321Returning to the public sector, Fig. 4shows an example Plan template for
322managing the case of a Youth Offender. This work typically involves many
323different parties, and is subject to rigorous legal and ethical constraints, which
324means it must be managed with great care:
325The screenshot shows the work required to supervise a disqualification order,
326which has deliverables from the Case Manager and Crown Prosecution Service
327Liaison, with the Youth Offending Team Manager involved only in a supervisory
328capacity. In order for the CPS Liaison to do their work, they use the deliverable
329from the Case Manager, the “Concerns About Breach”.
Fig. 2 Plan template for a Scrum project
Dealing with Human-Driven Processes
Fig. 3 Plan template for a Sales Bid
Fig. 4 Plan template for managing a Youth Offender Case
K. Harrison-Broninski
330At the start of the case it will not be known whether or not this Stage is necessary
331at all, but by default all Stages in a Plan are optional, as are all Activities and
332production of all deliverables. The Plan indicates rather than prescribes the work
333required to meet the goals of the effort overall. As the work progresses, it will
334become clear exactly what should be done, and the best way in which to do it.
335A Human Interaction Management approach guides those involved to work in a
336structured way that is amenable to management, while allowing them to use their
337skills and experience to determine the most efficient and effective route through
338the work.
3393 Human Interaction Management Theory
340HIM is a formal theory of processes that extends, alters and re-frames ideas
341originally developed in the early 1980s (Holt et al. 1983) and subsequently associ-
342ated with Role Activity Diagrams (Warboys 1989; Ould 1995; Warboys
343et al. 1999). The mathematical foundation of HIM draws on and unifies petri nets
344and the pi-calculus (Harrison-Broninski 2005b “Managing Process Change? Easy
345as Pi (and Petri)”).
346The theory of HIM shows how to describe processes so as to facilitate effective,
347efficient management of teams,communication,knowledge,time, and plans (the “5
348Principles of HIM”).
349A further concern of HIM is to provide software support for processes involving
350human collaboration, including those that cross organizational boundaries, which
351it does via the definition of a new kind of software system – a Human Interaction
352Management System (HIMS). A HIMS is not a centralized server managing the
353progress of concurrent, hierarchical, finite state machines (like current mainstream
354BPM software), but rather a means to manage distributed objects. A HIM process is
355a set of objects (known collectively as a “Plan”), of which copies are owned by each
356player in the process. Each player does work in the process using their own HIMS,
357which uses messaging to ensure that their own copy of the Plan is synchronized
358with the copies held by their peers.
359Note that it is possible to take part in an HIM process without using a HIMS – as
360long as one player is using an HIMS, the others can collaborate via email, for
361example, and the sole HIMS instance will still ensure that the work is structured
362according to the Plan definition for all players.
3633.1 The 5 Principles of HIM
364HIM analyses collaborative work processes in terms of their inner structure rather
365than from their external manifestation in terms of particular communications.
366Rather than being based on a specific aspect of human collaboration such as
Dealing with Human-Driven Processes
367 messaging or document sharing, HIM is based on five fundamental features of
368 human-driven processes, the “5 Principles of Human Interaction Management”. As
369 an organization is effectively a manifestation of long-term human collaboration, the
370 “5 Principles of HIM” apply equally to organizations and to any other form of
371 project or venture. The five principles are discussed below, along with their
372 implications for any modelling framework that aims to capture human
373 collaboration.
374 (1) Team building: To create effective teams, it must be clear who is involved in a
375 particular process, and what each person brings to the table. As a starting point,
376 the identity, skills, experience, and personal characteristics of each person must
377 be captured. It is then necessary to define each individual’s responsibilities, and
378 negotiate his/her commitment to accepting these responsibilities.
379 A modeling framework for collaborative, adaptive human activity must
380 contain Role and User objects, both as types and as instances of those types.
381 (2) Communication: If people are to manage their interactions with others better,
382 their communications must be structured and goal-directed. Within a process,
383 there must be specific channels of communication for different purposes, each
384 of which unifies messages transmitted via a variety of means (email, text
385 message, FAX, voice-over-IP, etc.).
386 A modeling framework for collaborative, adaptive human activity must
387 contain Interaction objects representing interactive, multi-party communica-
388 tion channels.
389 (3) Knowledge: Organizations must learn to manage the time and mental effort
390 their staff members invest in researching, comparing, considering, deciding,
391 and generally turning information into knowledge and ideas. The people
392 responsible for creating and managing this knowledge must be able to control
393 its usage and distribution.
394 A modeling framework for collaborative, adaptive human activity must
395 contain Entity objects that can be created, versioned, and shared in a struc-
396 tured way.
397 (4) Empowered time management: Humans may not sequence their activities in the
398 manner of a software program, but there is always structure to human work,
399 which must be understood and institutionalized so that it can be managed and
400 improved. This means empowering people to choose and/or create their own
401 work activities from an appropriate range, guided by understanding of organi-
402 zational context (so that they can aim to deliver maximum value) and restricted
403 by business rules that prevent contravention of applicable policies and
404 standards.
405 A modeling framework for collaborative, adaptive human activity must
406 contain Activity objects that can be marked up to enable validation and control.
407 (5) Collaborative, real-time planning: Human activities are concerned often with
408 solving problems, or making something happen. Such activities routinely start
409 in the same fashion – by establishing a way of proceeding. Before you can
410 design your new widget, or develop your marketing plan, you need to work out
K. Harrison-Broninski
411how you are going to do so – which methodology to use, which tools are
412required, which people should be consulted, and so on. In other words, process
413definition is an intrinsic part of the process itself. It takes place via negotiation
414between all involved parties, and is not a one-time thing but happens continu-
415ally throughout the life of the process.
416A modeling framework for collaborative, adaptive human activity must
417support creation, update and deletion of objects and their user interfaces as
418part of the work process itself.
419The HIM modelling framework includes objects of over 30 different types, and
420provides a diagrammatic notation to depict them, as shown in Fig. 5.
421However, most HIM users never use this object model or even know of its
422existence. Rather, they create, use and manage Plan templates in a simple, intuitive
423way by dealing with Stages, Roles, Activities and Deliverables.
424HIM also provides guidelines on use of the approach, by identifying a number of
425patterns resulting from the five principles. Some of these patterns are described in
426following sub-sections.
4273.2 REACT and AIM
428The REACT and AIM patterns shown in Fig. 6underlie any form of human activity
429(collaborative or not) – taken together, the REACT and AIM patterns describe all
430human working behavior. The patterns capture the way that people respond to
431assignments, fulfill responsibilities, achieve goals – the way they “react” to the
432work they take on. REACT and AIM help simplify complex situations, as the
Fig. 5 HIM modelling framework
Dealing with Human-Driven Processes
433 patterns can be repeated, overlapped, and nested in order to reduce any work
434 assignment to the same fundamental elements.
435 REACT has five elements:
436 (1) Research: Map out the terrain, investigate the principles, talk to those in the
437 know, locate potential threats, and so on, in order to gain information from
438 external sources, and turn it into personal knowledge. The external sources may
439 be close at hand – members of a “community of practice,” for example.
440 Alternatively, information may be acquired from an impartial expert in the
441 field, a textbook, or a search on the Web. The details are different every time,
442 but the principle is the same. Before you can start to work on something, it is
443 only common sense to find out what you are getting yourself into.
444 (2) Evaluate: Step back and consider the knowledge thus acquired. Internalize it, in
445 a sense, by making connections between different opinions or facts. Once you
446 have discovered the general lay of the land, you need to familiarize yourself
447 with it. You may need to carefully read a pile of papers on your desk, or to mull
448 over some advice that you do not yet understand. This element of REACT may
449 take minutes or years, but it is crucial – there is no point doing an investigation
450 unless you make an effort to take on board the information you gathered.
451 (3) Analyze: On the basis of your new-found understanding, decide on an approach
452 to the problem. In general, the approach you settle on may result partly from
453 applying logic to reduce the problem to more manageable sub-problems – and
Fig. 6 REACT and AIM
K. Harrison-Broninski
454partly from an intuitive judgment on what feels “right”. The balance varies both
455with the type of problem and with the type of person trying to solve
456it. However, you arrive at a conclusion, though the decisions made at this
457point are not necessarily a final say on the matter – they are simply a way
458forward for now; enough to let you proceed further with the work in hand.
459Sometimes it is hard to be sure whether you are doing the right thing, so you
460might choose a way forward that hedges our bets – following multiple paths at
461the same time, in the hope that at least one will work – or decide only on the first
462few steps, and leave decisions about other steps for later. But you have to make
463some kind of decision at this point, at least on how to start.
464(4) Constrain: Divide the work into separate chunks, and organize them. This may
465be simply a matter of deciding an approximate order to do them in, or it may be
466a huge task involving all the techniques of project planning: dependency and
467impact analysis, critical path definition, resource allocation, budgeting, contin-
468gency planning, and so on. However, you are dealing with human-driven
469processes here – in which people rarely do things in the order laid down, and
470rightly see it as part of their work to determine how things should proceed. So,
471this part of the REACT pattern is not about defining workflows, in the sense of
472ordering activities into strict sequence – rather, it is about chunking the work
473into separate Stages, each with its own sub-goal.
474(5) Task: You have determined how to break the work into Stages, put Roles in
475each Stage with Activities and Deliverables, and assigned the Roles to appro-
476priate people (typically including yourself), so now all those concerned can get
477on with the tasks at hand. For a large programme, doing the work may involve
478many different people and organizations working together to deliver a complex
479product or service.
480The first part of REACT, Research, can be further broken down into a
481sub-pattern AIM, which describes any research activity. Similarly to the way
482REACT describes human work in general, AIM describes the particular activities
483of information discovery.
484(1) Access discovery services: Decide where you will go to obtain information, and
485obtain any necessary authorization. This might be permission to contact some-
486one, login details for a database, or funds to use some kind of finder agency.
487(2) Identify resources required: From the above-mentioned service(s), choose
488resources likely to be of interest. At this point, you will have only cursory
489understanding of their content – what matters is that they seem likely to be
490useful.
491(3) Memorize information obtained from particular resources: It is important to
492focus on committing information to memory, even if the information is only the
493outline of an idea you will use later on. Unless you have memorized informa-
494tion gathered during this first element of REACT, it is no use in the following
495element, Evaluate – you cannot synthesize ideas you have forgotten, or need to
496look up in order to understand. This element of AIM is all about internalizing
497the ideas in question.
Dealing with Human-Driven Processes
498 3.3 Stage
499 A “Stage” (originally known in HIM theory as a “Collaborative Transaction”) is an
500 archetypal structure for describing a phase of collaborative work. The structure
501 includes two separate interactions, one for discussion about the work of the Stage
502 and one for controlling the status of the Stage. A Stage includes Activities divided
503 among several Roles. Stages can be nested, may run in parallel and their status is
504 controlled ultimately by the Plan owner (although other Plan members can make
505 provisional changes of certain kinds to the status of a Stage).
506 3.4 Levels of Control
507 Levels of Control refers to a natural division of responsibility and authority between
508 strategic, executive, and managerial Roles. In brief, strategic control is about
509 identifying goals and measures; executive control is about identifying key roles
510 and interactions; management control is about constructing, implementing,
511 supporting, and reporting on an executable process.
512 4 The Human Interaction Management System
513 Implementation of HIM in an enterprise environment (i.e., design, execution and
514 management of business processes according to HIM principles) is facilitated by
515 software support from a Human Interaction Management System (HIMS), for
516 which the reference implementation is HumanEdj (Role Modellers 2012b
517 “HumanEdj User Guide”). The aim of a HIMS is to facilitate collaborative,
518 adaptive human work without forcing people to follow a set of predetermined
519 steps rigidly. By bringing human collaboration into a unified and supportive process
520 context, the HIMS promises to make knowledge work genuinely more effective.
521 Integration of a HIMS into enterprise architecture is shown in Fig. 7.
522 4.1 Speech Acts
523 A HIMS helps people to see the bigger picture of a process and understand their
524 responsibilities within it. This calls for suggestive rather than prescriptive process
525 description and support: a HIMS provides support and enforces basic control on
526 behalf of the organization, providing an indication to people of what they are
527 expected to do then letting them learn collaboratively how best to meet their
528 assigned goals.
K. Harrison-Broninski
529A key aspect of this collaborative learning derives from autopoietic theory
530(Maturana and Varela 1973), which asserts that communication is founded not on
531transmission of information but rather on transmission of intent. Research in
532biology shows that the purpose of animal communication is largely about synchro-
533nizing the behavior of parties. This understanding has been adopted in business via
534the classic “Conversation for Action” (CfA) pattern (Winograd and Flores 1990), in
535which communication between people and organizations is structured in terms of a
536small set of request/response pairs – request/promise, offer/acceptance, and report/
537acknowledgement.
538However, many business people have found the traditional use of speech acts in
539CfA too rigid for practical use. Hence, HIM generalizes the approach by allowing a
540much broader and less restrictive set of structured communications. HumanEdj, for
541instance, provides full support for speech act theory (Austin 1962; Searle 1969),
542according to which a communication act is not only composed of content but also,
543and at least as importantly, of an intention. HumanEdj permits business people not
544only to share data and documents, but also to make a wide range of assertions about
545the status of Deliverables and Stages. For example, the creator of a Deliverable can
546specify its intended usage as a draft for review, as a submission for approval, as
Fig. 7 Modern business systems
Dealing with Human-Driven Processes
547 having known issues that need to be addressed, or as having one of various other
548 statuses.
549 In general, a HIMS suggests actions rather than prescribes them, allows not only
550 for communication but also for action, does not assume that all communication is
551 direct and does not prevent tangential discussion – i.e., unexpected interactions that
552 go beyond the conversation originally expected. This permits processes to evolve
553 via a collaborative learning process. The HIMS provides helpful structure by
554 modelling work formally as a process, but retains a light touch by allowing people
555 to work according to their judgement at the time.
556 4.2 Cross-Boundary Processes
557 A key aspect of human collaborative work is the common necessity to include
558 people from multiple organizations, location and disciplines. Hence a HIMS such
559 as HumanEdj has a distributed peer-to-peer architecture, more akin to a Multi-
560 Agent System than to a workflow or BPMS engine. Participants in a Plan may
561 belong to different organizations and use different HIMS servers, since each HIMS
562 automatically synchronizes the Plan states for its users via a messaging technology
563 such as email. This also makes it possible to participate in a Plan using only a
564 standard email client.
565 Plans may also generate sub-Plans, for instance in order to carry out the details of
566 a public process as distinct private processes.
567 4.3 Continuous Improvement of Collaborative Work
568 Plan templates are used to generate Plans for projects, initiatives, ventures, etc. –
569 i.e. executable business processes that may cross organizational boundaries. Each
570 Plan is configured appropriately for the requirements of the situation, and the
571 participants themselves adjust the configuration throughout its life, as they collab-
572 orate to evolve the definition of the Plan instance in response to external circum-
573 stances and internal progress.
574 Hence a Plan acts not only as a mechanism for learning but, once complete, as a
575 source of learning materials. Plan instances from a repository show how other
576 people dealt with problems of a certain type, and new Plan templates may be
577 created from successful Plan instances (or parts thereof).
578 With regard to assessment of learning results, Plan instances are self-monitoring
579 – they include automatic feedback mechanisms both within the Plan and across
580 Plans to higher management levels. Taking part in a Plan instance in itself both
581 measures and provides evidence of achievement. Plans may also use external
582 services to provide:
K. Harrison-Broninski
583• Learning materials customized for the Plan instance
584• Standardized evaluation of learning progress
585• Trusted competency assessment
586• User profiles
5874.4 Semantic Mark-up
588Information within a Plan instance automatically has semantic mark-up, as do all
589communications between participants. This mark-up can be sent to external ser-
590vices to help streamline data harvesting and analysis.
5915 Goal-Oriented Organization Design
592Each key element in a HIM process has a direct equivalent in the Business Layer of
593the ArchiMate®2.0 Architectural Framework (Open Group 2012; Role Modellers
5942012a “HumanEdj FAQ”). However, this alone is not enough to ensure full
595integration of HIM processes into enterprise architecture, which requires a struc-
596tured, manageable approach. Hence introduction of HIM into the enterprise, and its
597integration with both organizational strategy and mainstream BPM, is facilitated by
598an associated methodology, Goal-Oriented Organization Design (GOOD)
599(Harrison-Broninski 2009,2011). GOOD differs from mainstream BPM method-
600ologies in being derived formally from an underpinning set of consistent principles,
601i.e., those of HIM.
602GOOD supplies a step-by-step method for applying HIM patterns to human
603work, by starting from a basic observation – that the primary value delivered by
604humans to an organization lies in their ability to collaborate, adapt, and innovate as
605required to deal with changing and unexpected circumstances. As described earlier,
606human-driven processes are not precisely repetitive – rather, they typically evolve
607during usage, as the participants repeatedly collaborate to agree on next steps.
608Hence, GOOD emphasizes effectiveness over efficiency. Human work should not
609be managed using the measures of waste and cycle time typically applied for
610improvement of production processes. Rather, people at all levels of an organiza-
611tional hierarchy must have some leeway to judge for themselves the most effective
612actions according to circumstances. Hence, GOOD focuses on enabling structured
613partial decentralization of management authority while ensuring continued align-
614ment with strategic organizational goals.
615In particular, GOOD supports process and service development, maintenance,
616and improvement via governance processes – human-driven processes defined
617using HIM notation, and inter-related via HIM levels of control. GOOD governance
618processes apply quality techniques drawn from HIM principles – metrics and
Dealing with Human-Driven Processes
619 indicators that measure the effectiveness of a process by tracking how well it makes
620 use of the humans involved.
621 Full description of the GOOD methodology is out of scope for this paper, but an
622 overview is provided in Fig. 8.
623 6 Human Interaction Management Case Study
624 To illustrate how HIM supports adaptive, collaborative processes, considered
625 below is an innovative company whose products are improvement programmes
626 that it delivers to public sector organizations. The management structure is flat and
627 staff members are encouraged to propose, seek internal funding for, and implement
628 new improvement programmes on a regular basis. While the culture has resulted in
629 innovations beneficial to their customers, and consequently in growth, the company
630 struggled to make its operations profitable. It was not possible to optimize or even
Fig. 8 Goal-Oriented
Organization Design – high-
level roles
K. Harrison-Broninski
631obtain the cost of sales, given the complex way in which improvement programmes
632were created, sold, and delivered. It became necessary to standardize and monitor
633customer-facing operations.
634The company expected to continue its previous success with standardizing back-
635office administrative processes using traditional workflow techniques. However,
636standardization of customer-facing operational processes met with resistance from
637staff, who were accustomed to using their skills, experience and judgement to adapt
638their working approach to each customer engagement. Hence, there remained wide
639variance across the organization in the way that core customer-facing and internal
640processes were carried out.
641The solution required a means of process standardization that provided indica-
642tive rather than prescriptive processes (i.e. processes that could be adapted flexibly
643during execution), and that supported the harvesting of innovative ideas into new
644products (i.e. improvement programmes). The company used HIM to develop Plan
645templates for core operational processes including:
646•Sales Funnel. Developing a sales lead into a new customer engagement.
647•Product Delivery. Implementing an improvement programme for a customer.
648•Non-Standard Product Development. Developing a custom improvement
649programme for a customer.
650•Standard Product Development. Turning a custom improvement programme
651into a standard off-the-shelf product offered to all customers.
652Shown in Fig. 9below is a HumanEdj “Grid view” of the Plan template for the
653Sales Funnel process. Across the top are the Roles in the process, which in an actual
654Plan would be assigned to named people. Down the side are the Stages in the Plan
655template. The numbering is only suggestive, since the Stages may be carried out in
656any order, and they often run concurrently. HumanEdj Stages are used to represent
657sets of related goals, helping to ensure that people focus on objectives and thus
658work effectively.
659During the lifetime of a Plan, the Stages are assigned statuses by the Plan owner,
660such as “Started”, “Completed”, “Cancelled”, and so on. Different Roles belong to
661different sets of Stages. Any documents, data or messages created in a Stage are
662visible to all the Roles in that Stage and only to those roles. Here we see the
663emphasis on mental work that is critical to learning (and a core principle of HIM),
664via deliverables identified and recognized as a natural part of Plan execution.
665Two Activities in particular are to be noted:
6661. “Initiate Non-Standard Product Development” in Stage “Develop Opportunity”,
667which involves the creation of a new sub-Plan for developing a custom improve-
668ment programme, if required. The sub-Plan will be based on a standard Plan
669template, adapted as required. If the standard Plan template is adapted, the new
670version may itself become a standard Plan template for use by others. The
671creation of the sub-Plan not only draws on organizational knowledge about
672custom improvement programme creation, but may well contribute to it by
673addition of a new special case. Here we see how the creation of a particular
Dealing with Human-Driven Processes
674 sales proposal contributes to evolving organizational structure, since the way in
675 which it was done is automatically made part of enterprise knowledge
676 management.
677 2. “Initiate Delivery Plan” in Stage “Await Decision”, which involves the creation
678 of a new sub-Plan for delivering the improvement programme. The Plan tem-
679 plate used for this is created as part of the proposal and adapted for each
680 customer engagement. As above, creation of a sub-Plan for a particular Delivery
681 may well result in an adapted Plan template that can be re-used for future
682 Deliveries of the same type. This creation of one Plan from another is typical
683 of HIM, and can be used at any level in an organization to align operations with
684 strategy.
685 Statistics from the Delivery sub-Plan are used together with statistics from the
686 Sales Funnel Plan itself (shown for an example template in Fig. 10) and any
687 sub-Plan for Non-Standard Product Development to generate accurate total cost
688 for provision of the improvement programme to the customer, and hence to create a
689 price that ensures the engagement returns a profit (or a deliberate loss).
Fig. 9 Excerpt AU4from HumanEdj grid view in tabular format of plan template for sales of
improvement programmes
K. Harrison-Broninski
690By explicitly associating the different aspects of customer engagement with one
691another, the organization is making its customer-facing operations and their internal
692relations visible. This means not only that senior management can learn to manage
693the processes as a unified whole (and hence improve the way in which the
694organization operates), but also that new staff can learn what the organization
695actually does and how they fit into it. These means of learning are fundamental
696enablers as the organization grows, since geographical expansion means that teams
697are increasingly virtual and operational staff includes more and more
698sub-contractors rather than employees.
699Further opportunities include passing on the benefits of HIM to client organiza-
700tions in the form of Plan templates that support their resulting change management
701initiatives and help to develop their future strategy. The company has effectively
702started the latter already, by creating Bottom-Up Plan templates for core operations.
703Next steps include building a Process Architecture to represent their domain of
704interest, defining vision and mission at multiple levels via a Business Motivation
Fig. 10 Excerpt from HumanEdj summary view in tabular format of Plan template for sales of
improvement programmes
Dealing with Human-Driven Processes
705 Model, developing understanding of their stakeholders, and creating Benefits Pro-
706 files for the changes that they plan.
707 7 Conclusions
708 The current inexorable trends toward outsourcing, partnering, and subcontracting as
709 the fundamental means of doing business in a globalized economy mean that it is
710 critical to support decentralized, cross-boundary processes in which humans col-
711 laborate to reach shared goals, adapting en route in order to meet complex,
712 changing business needs.
713 To deal with such processes, a new analysis paradigm is required for high level
714 knowledge work – one that is based not on state machines in which the process is a
715 clockwork mechanism that moves from stage to stage, controlled centrally by a
716 single engine, but rather on object models where a process is a set of objects in
717 different domains, whose interaction and synchronization are controlled collabora-
718 tively by agents acting on behalf of each player. This new paradigm is what HIM
719 notation and the underpinning HIM semantics provide.
720 On an everyday level, the different types of knowledge work process can be
721 understood by means of an analogy – comparing Lego and cooking. Both may
722 involve multiple model-makers or chefs. The critical difference lies in the interac-
723 tion between constituent elements (bricks and ingredients, respectively):
724 1. A Lego model is always exactly the sum of its original bricks – it can be
725 disassembled at any time, since the bricks remain unchanged by usage.
726 2. Cooking fuses ingredients into something more than the sum of their parts – into
727 new flavors and textures, generated by a non-reversible chemical process.
728 Similarly, flexible, innovative business processes (“adaptive” processes) are of
729 two kinds:
730 1. A process amenable to analysis via BPM or Case Management techniques is a
731 collection of pre-defined fragments – in exactly the same way that a modern
732 software application is a bundle of pre-built components and/or services.
733 2. A process required a HIM approach, on the other hand, uses fragments only as a
734 starting point – as the process unfolds, the participants shape the collection of
735 fragments into something uniquely and holistically suited to the situation
736 at hand.
737 Case studies (Harrison-Broninski 2011) make it clear not only that BPM and
738 Case Management practitioners who deal with knowledge work focus exclusively
739 on the first kind of process, but also that many such people only see processes of the
740 first kind. Processes of the second kind are the elephant in the room – the hidden
741 bulk of the iceberg, unsupported by mainstream techniques and tools. This hidden
742 bulk conceals a huge amount of business-critical knowledge work, as shown in
743 Fig. 1.
K. Harrison-Broninski
744A HIMS meets the need for software support of collaborative, adaptive human
745work by having a basis in what Gartner Inc. calls “design-by-doing”. In its BPM
746Cool Vendors 2012 report, Gartner Inc. said that “design-by-doing” exemplifies the
747trend towards social BPM, noting that the ability to “do, then plan” – that is, to alter
748plans quickly and easily as time progresses and the overall goal evolves, and then
749reuse plans as new templates – will be useful to teams that need to collaborate on
750the fly, and then learn from their successes and failures (Cantara et al. 2012)
751Flexible, innovative processes are currently high on many organizations’ radar.
752So it is worth understanding the difference between Lego and cooking, and apply-
753ing the analogy to adaptive work processes. Buildings are made of bricks, but
754organizations are made by teams – and modern teams are usually virtual. To support
755collaborative, adaptive human work across a virtual enterprise, new techniques and
756new tools are required – HIM and the HIMS.
757A key benefit from taking the HIM approach to a virtual enterprise is that it
758requires no training, process skills, or technical aptitude in order to understand what
759is going on and take part effectively. The simple intuitive approach makes it
760immediately clear to everyone involved what their own responsibilities are – and
761if they are interested, what the responsibilities of other people are. As the Plan
762evolves, and responsibilities change along with circumstances, the updated Stages,
763Roles and Activities ensure that everyone stays on the same page.
764Further, it is not necessary to use specialized software. A Plan must be created
765via a Web browser by its owner (usually by customizing a standard template in a
766HIMS), but can then be used by others via standard email. The invitation message to
767join shows the outline of the Plan, and after that deliverables and messages can be
768sent and received via email messages in the usual way. Even if no-one but the owner
769ever uses a Web browser to do work, all deliverables and messages will be stored in
770the correct Stage via the owner’s copy of the Plan, and in due course will be
771archived when the owner marks the Plan complete.
772In effect, taking a HIM approach to collaborative work allows virtual enterprises
773to be created and managed with close to zero technical or administrative overhead.
774The global economy is undergoing a sea change. To operate efficiently and
775effectively in a globalized economy based on an explosive proliferation of niches,
776one must abandon the hopeful notion that all business processes can be defined once
777then run thousands of times with only minor change. One must create an operational
778environment in which change is not only possible, but structured, encouraged, and
779aligned with strategic objectives.
780This means taking a much richer view of “process” – a view in which people,
781communication channels, knowledge, time, and plans are all managed along with
782the activities that are more easily visible – across multiple domains that include not
783only you and all your trading partners but also your customers. Bottom–up empow-
784erment is not enough. Top–down control is not enough. Organizations need an
785enterprise management framework that supports both, at the same time, using the
786same approach.
787In the twenty-first century, improving routine processes using current main-
788stream BPM and Case Management techniques only brings you up to the level of
Dealing with Human-Driven Processes
789 your competitors. To stay ahead, and stay in the game, you need to improve the
790 human- driven processes that cannot be fully planned in advance – and do it on
791 enterprise scale. This requires a new approach – HIM, the HIMS, and GOOD.
792 AU5References
793 AU6Austin JL (1962) How to do things with words. Harvard University Press, Cambridge
794 Brown JS, Gray ES (2005) The people are the company. http://www.fastcompany.com/magazine/
795 01/people.html. Accessed 28 July 2013 AU7
796 Cantara M, Sinur J, Jones T, Hill JB, Jacobson SF (2012) Cool vendors in business process
797 management, 2012. Gartner Inc
798 Deming WE (1950) Lecture to Japanese management. http://hclectures.blogspot.co.uk/1970/08/
799 demings-1950-lecture-to-japanese.html. Accessed 28 July 2013
800 George ML (2002) Lean Six Sigma: combining Six Sigma with lean speed. McGraw-Hill
801 Professional, New York
802 Giordano R, Clark M, Goodwin N (2011) Perspectives on telehealth and telecare – learning from
803 the 12 Whole System Demonstrator Action Network (WSDAN) sites. The King’s Fund,
804 London
805 Hammer M (2014) What is business process management. In: vom Brocke J, Rosemann M (eds)
806 Handbook on business process management, vol 1, 2nd edn. Springer, Heidelberg
807 Harrison-Broninski K (2005a) Human interactions – the heart and soul of business process
808 management. Meghan-Kiffer Press, Tampa
809 Harrison-Broninski K (2005b) Managing process change? Easy as Pi (and Petri). http://www.
810 bptrends.com/publicationfiles/03-05%20ART%20Managing_Process_Change%20Harri
811 son-Broninski.pdf. Accessed 28 July 2013 AU8
812 Harrison-Broninski K (2009) Goal-Oriented Organization Design. Cutter Consortium
813 Harrison-Broninski K (2011) Change management processes. Social BPM: work, planning and
814 collaboration under the impact of social technology, Workflow Management Coalition
815 Harry MJ (1988) The nature of six sigma quality. Motorola University Press, Rolling Meadows
816 Holt AW, Ramsey HR, Grimes JD (1983) Coordination system technology as the basis for a
817 programming environment. Electr Commun 57(4):308–314
818 Ishikawa K (1968) Guide to quality control. JUSE Press, Tokyo
819 Jensen MC, Meckling WH (1976) Theory of the firm: management behavior, agency costs and
820 ownership structure. J Financ Econ 3(4):305–360
821 Maturana H, Varela F (1973) Autopoiesis and cognition: the realization of the living. D. Reidel
822 Publishing Co
823 Object Management Group (2011) Business process model and notation (BPMN) version 2.0.
824 http://www.omg.org/spec/BPMN/2.0/. Accessed 28 July 2013
825 Ohno T (1988) Toyota production system: beyond large-scale production. Productivity Press,
826 Cambridge, MA
827 Open Group (2012) ArchiMate®2.0 specification. https://www2.opengroup.org/ogsys/jsp/publi
828 cations/PublicationDetails.jsp?catalogno¼c118. Accessed 28 July 2013
829 Ould MA (1995) Business Processes - modelling and analysis for re-engineering and improve-
830 ment. Wiley
831 Role Modellers (2012a) HumanEdj FAQ, section 2.16, “How do I integrate HumanEdj deploy-
832 ment with our enterprise architecture?” www.rolemodellers.com. Accessed 28 July 2013
833 Role Modellers (2012b) HumanEdj User Guide, section 4, “The Objects in a Book”. www.
834 rolemodellers.com. Accessed 6 Sep 2012)
K. Harrison-Broninski
835Rosemann M, vom Brocke J (2014) The six core elements of business process management. In:
836vom Brocke J, Rosemann M (eds) Handbook on business process management, vol 1, 2nd edn.
837Springer, Heidelberg
838Ross J, Weill P, Roberston DC (2006) Enterprise architecture as strategy: creating a foundation for
839business execution. Harvard Business School Press, Boston
840Searle J (1969) Speech acts. Cambridge University Press, London
841Shewhart WA (1931) Economic control of quality of manufactured product. D. Van Nostrand
842Company, New York
843Taylor FW (1911) The principles of scientific management. Harper & Brothers, New York
844Warboys B (1989) The IPSE 2.5 project: process modelling as a basis for a support environment.
845In: Proceedings of the first international conference on system development environments and
846factories SDEF1, Pitman, Berlin, May 1989
847Warboys B, Kawalek P, Robertson I, Greenwood M (1999) Business information systems – a
848process approach. McGraw-Hill, Maidenhead
849Winograd T, Flores F (1990) Understanding computers and cognition: a new foundation for
850design. Ablex Publishing, Norwood
Dealing with Human-Driven Processes
Author Queries
Chapter No.: 24 188830_2_En
Query Refs. Details Required Author’s response
AU1 The reference “Harmon (2014)” has
been removed from the reference list
and placed it in the respective cita-
tion in abstract. Please check, if okay.
AU2 Please provide details of Davenport
(2014) in the reference list.
AU3 Should the citation (Jensen and
Meckling 1976) provided in block
quote be set as per the manuscript?
Please advise.
AU4 Please provide artwork for Figures 9
and 10.
AU5 Please confirm if year “2014” have
been changed to “in press” both in
reference list and citations.
AU6 Please check if inserted publisher
location for Austin (1962), George
(2002), Giordano et al. (2011), Har-
rison-Broninski (2005), Ross
et al. (2006), Searle (1969), and
Winograd and Flores (1990) are
okay.
AU7 Please provide publisher location for
Cantara et al. (2012), Maturana and
Varela (1973), and Ould (1995).
AU8 Please update Harrison-Broninski
(2009, 2011), if possible.
