# Business Processes and Standard Operating Procedures: Two Coins with Similar Sides

Gertraud Peinel, Thomas Rose

► To cite this version:

Gertraud Peinel, Thomas Rose. Business Processes and Standard Operating Procedures: Two Coins with Similar Sides. 12th International Conference on Electronic Government (EGOV), Sep 2013, Koblenz, Germany. pp.224-236, 10.1007/978-3-642-40358-3_19. hal-01490909

HAL Id: hal-01490909

https://inria.hal.science/hal-01490909

Submitted on 16 Mar 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Business Processes and Standard Operating Procedures:
Two Coins with Similar Sides

Gertraud Peinel¹, Thomas Rose¹,²

¹Fraunhofer FIT, Schloß Birlinghoven, 53754 Sankt Augustin, Germany

{gertraud.peinel,thomas.rose}@fit.fraunhofer.de

²Information Systems & Databases, RWTH Aachen, Ahornstr. 55, 52056 Aachen, Germany

**Abstract.** Concepts and tools for process management have often been transferred to emergency management projects. The driving objective has been to bring assistance to planning procedures and quality assurance. This seems rather natural, since idea and concept of business processes and standard operating procedures appear like siblings. In this paper we discuss whether the concepts of process modelling are adequate for managing standard operating procedures and whether emergency management organisations can capitalize on off-the-shelf business process modelling tools to prepare for disasters more effectively. This paper presents ample evidence that prevailing business process means are inappropriate for emergency management in light of organisational as well as technology issues. In a nutshell, business process concepts are utilized as a “golden hammer” in many emergency management projects, a suitable tool for all purposes. Yet, the question rises whether emergency management issues are always fitting nails.

**Keywords:** Process Management, Business Processes, Standard Operating Procedures, Emergency Management

## 1 Introduction

We conducted several research projects in cooperation with emergency and relief organisations. Their pivotal objective has been the improvement of planning processes in terms of quality and time. Results of planning processes typically become manifest in Standard Operating Procedures (SOP), be it in medical or emergency management domains. Since SOPs appear rather close to business processes, the suitability of business process management (BPM) tools was obvious. Hence, the question arose on how to utilize BPM methods and tools for designing SOPs.

Once embarking on this endeavour, one faces typically subsequent core challenges:

* Does planning of emergency and relief services differ from planning processes in business environments in terms of objectives, methodology or interests?

* Do formal process models offer benefits to the conceptual design of standard operating procedures of emergency services?
* What changes to business process management means are instrumental for planning of emergency services or can prevailing tools directly been used?

* What is the added value of business process analytics once being used for assessing the quality and effectiveness of planned procedures?

This paper structures our findings along several dimensions in order to expose similarities and differences of both worlds, e.g., standards for business process management versus the prevalent folklore of emergency organisations. To make a long story short: we argue that standard business process means are currently not suitable for emergency management planning.

This paper is organized as follows. After an introduction about business process management, we introduce some pivotal characteristics of the emergency domain and give an overview about our projects in this domain. We present in the fourth section our experiences about the relationship BP management and emergency management. Following an overview table with driving issues we elaborate our findings in detail. Finally, we draw our conclusion for the sake of planning counter measures.

## 2 SOPs and Business Process Management

A Standard Operating Procedure describes 'a set of written instructions that document a routine or repetitive activity followed by an organization' [1] and is a 'written, numbered organizational directive that establishes a standard course of action' [2]. The concept of SOPs is mainly used in emergency management, military, and medical context.

Similarities between these SOPs and the definition of business processes are obvious taking into account that a process is defined as a 'set of partially ordered activities intended to reach a goal' [3] or that 'a process is thus a specific ordering of work activities across time and place with a beginning, an end and clearly identified inputs and outputs: a structure for action' [4].

Consequently, several security related projects have directly applied process management means to standard operating procedures for emergency management. Many of these projects sought a partial automation of control flows for the execution of standard operating procedures [5-8]. That is, standard operating procedures served as blueprints for workflows, which can be directly translated into executable activities and by the same time impose control structures. Following this line of approaches automation and assisted procedures become the focus of direction. Other approaches strived for seamless information flows by integrating information management and data streams inside as well as between command centres [9-11] or between command centres and rescue units during a crisis [12-14].

In the course of their projects all of them realized that the identification of procedures of rescue organisations is essential for any research contribution that aims to improve the support of rescue workers and their organisations [15]. But unfortunately, they found no adequate means for domain experts to grasp, to describe, or to formally model their courses of action *themselves* for daily routines or even large-scale crisis. Once, third-party experts with a modelling background are involved in the formalisation
tion of standard operating procedures, commercial process management environments become instrumental. Yet, the question of adequacy of the process model comes as a concern, i.e. how close is the model with its abstractions taking into account the domain's inherent complexity and variety.

Our research intention has been to support emergency experts in their modelling endeavours themselves as also promoted in other domains like health care [16] and engineering [17], that is, emergency experts are going to voice their standard operating procedures in terms of process models. But we encountered several obstacles and setbacks when trying to establish process modelling as planning method in the emergency management domain.

## 3 Research Path

Our experience is founded in an array of projects with emergency related organisations including fire brigades as well as emergency management authorities, but also police and rescue organisations. These projects revolved around central aspects of emergency management:

1. *Utilizing BPM tools for SOP capture* – Modelling the operational concept for cross-regional support of mass casualty incidents (MCI) with prevailing BPM methods [18]

This project delivered a proof of the usefulness of business process means towards emergency preparation. An already defined operational concept for the treatment of mass-casualties was translated into a formal process model, i.e. we transferred EM content into formal process models. This exercise demonstrated the virtues of formal process models, i.e. transparency across the organisation. Once processes are modelled by third-party experts, acceptance by domain experts has been high.

2. *User-centred process assistance* – Risk management process support for small to medium-sized communities for planning of natural or man-made disasters (project ERMA) [19]

In the follow-up project we moved our perspective closer to the emergency management domain: we designed and implemented a process management modelling tool with a more intuitive interface supporting the terminology of the EM domain, but still founded in the look and feel of BPM tools (graphs with activities as nodes while edges presented the control flow). Hence, user acceptance improved due to the new interface, which was custom-tailored to domain experts' terminology.

3. *Re-engineering processes* – Mobile Data Capture and Communication for Emergency Medical Services [20]

Another project studied the impact of mobile devices on the processes in particular once seamless information flows are possible. The process for capturing patient data has been the central focus. This process was re-engineered on the basis of seamless communication flows. Once third-party experts model the processes the actual notation language appeared of secondary importance. Now, we came closer to the EM domain: we created a mobile interface hiding the process modelling endeavour and just presenting the process execution results guiding rescue forces with a mo-
bile interface. Still we faced the problem that the EM domain was unable to change the process itself.

4. *Planning support for emergency preparedness* – Process support for emergency management organisations in case of a long-lasting power blackout (project In-foStrom) [21, 22]

The so far last approach was to move directly to the perspective of the EM domain: we elaborated a planning metaphor they already use, and formalised it in order to provide IT support: we framed a checklist model with a respective editor working in a network environment and employed converters to translate into BPM tools.

Even though we succeeded in providing the proof of concept that SOPs like MCI can be translated to business processes, the modelling method and tools –whether commercial or self-implemented– hardly engendered rapt enthusiasm among our emergency management partners. To re-iterate: they liked the modelling results, but disappointed planning process, tools and terminology. We undertook a critical follow-up research to find out why these projects felt a step short. Several indicators amid the projects were unveiled as potential reasons and are listed in the following section. Specific attention has been devoted to their classification along dimensions with regard to BPM as well as EM.

## 4 Juxtaposition of Process Management with Emergency Management Characteristics

The following table shows in summary the findings gained from our project experience. The left column spans topics of interest encountered while the two right columns relate specific properties and characteristics of both domains: emergency and business process management. It has to be noted that our findings are in some parts based on confessions and personal opinions of project partners working in emergency service agencies, rather than on a normative, scientific justification.

<table><caption>Table 1. Table of Different Characteristics</caption><thead><tr><td>Topic</td><td>Emergency Services World</td><td>Business Process Modeling World</td></tr></thead><tbody><tr><td rowspan="4">1. Planning philosophy</td><td>a) Checklists prevail</td><td>Formal processes</td></tr><tr><td>b) No planning of big events</td><td>Focus on large-scale procedures</td></tr><tr><td>c) Liability questions</td><td>Transparency for quality</td></tr><tr><td>d) Secrecy and privacy of information</td><td>Interfaces with other organizations</td></tr><tr><td>e) Concentration on planning and post-processing</td><td>Concentration on planning, analysis and execution</td></tr></tbody></table>
<table><tbody><tr><td rowspan="3">2. Mode of operation, Practice and work</td><td>a) Manual operation</td><td>Office automation</td></tr><tr><td>b) Improvements by exercises</td><td>Improvements by analysis and optimisation</td></tr><tr><td>c) No cross-organizational or collaborative planning</td><td>Design and operation of value networks</td></tr><tr><td>3. IT Technology, Implementation and Usage of Tools</td><td>a) Unsteady abstract thinking, no modelling experience<br>IT aversion or mistrust</td><td>IT and/or business-management user</td></tr><tr><td rowspan="3">4. Models and Concept</td><td>b) Ease-of-use important</td><td>User interfaces crammed</td></tr><tr><td>a) Own, domain specific meta-model</td><td>Fixed, often standardised meta-model</td></tr><tr><td>b) Specific process features (escalation)</td><td>Escalation concept missing (turnaround required)</td></tr><tr><td rowspan="3">5. Organisational Issues</td><td>c) Incomplete, macro-structured, dynamic, ad-hoc processes</td><td>Static and complete processes</td></tr><tr><td>a) Temporal units</td><td>Permanent units</td></tr><tr><td>b) Organizational changes due to phases</td><td>Mostly no organizational changes</td></tr><tr><td rowspan="3">6. Terminology</td><td>c) Legal regulations for ranks and corresponding capabilities and authorization</td><td>Organizational model underrepresented</td></tr><tr><td>d) Demographical and recruitment problems</td><td>Worker and terminology adapt to technology</td></tr><tr><td>a) Organization specific, traditional terminology<br>Use of acronyms</td><td>Fixed terminology according to standards<br>Business domain terms</td></tr><tr><td rowspan="3">7. Goals and Decisions</td><td>b) Translations and explanation required for cross-organisational planning</td><td>No glossary<br>No user specific interfaces</td></tr><tr><td>a) Concentration on strategic and tactical goals and its fulfilment</td><td>Goals underrepresented, analysis not according fulfilment of goals, but according business interest</td></tr><tr><td>b) Tracking of decisions in planning needed (why changes)<br>Descriptions of reasons (legal rules, experiences made) needed</td><td>Only tracking of versions<br>Text fields for further descriptions</td></tr></tbody></table>

We admit that the naming of topics and the assignment of issues to topics might formally not be orthogonal or even overlapping. Our findings of differences are described in detail subsequently.
1. **Planning Philosophy: a)** Investigating the planning processes of German emergency services by analysing regulations, rules, directives, we surprisingly detected only rudimentary process structures [22]. Checklists or task skeletons prevail that are sometimes even distributed across organizations. In all documents examined we did not find any formalisation or common notation presenting regulations or rules. They are kept as mostly unstructured text or checklists. Activities are hidden behind terms like "responsibilities" and "duties", which we believe could not be converted one-to-one to the definitions of business processes or activities. Rarely, any list of activities found had been sorted in temporal or logical order. What we detected is that most operating procedures of our fire brigades are described by means of checklists. Yet, most of them are merely paper-based documentation.

b) The operating procedures we found in regulations and handbook are mostly generally described and not adapted to specific disasters. When asked, rescue forces, fire departments, and police agencies of our projects are arguing that in the majority of cases a large event can be broken down to a set of smaller events, which in turn can be handled "as usual". As such, only specific events are pre-planned, aiming to guarantee sufficiency of resources. An anticipation of "what could happen", "who will call when and why" does currently only take place, if major events are planned such as a soccer world cup or other happenings with such an anticipated high number of visitors. Another argument for not-planning we received from an emergency service of a commercial organisation (harbour), which argued that they do not plan for events which might happen, but have not happened yet, because of a waste of time and resources and because there is no regulation, which forces them to plan more than evacuation paths and contact persons details.

c) Also, an argumentation came up that one might be responsible for any damages or worse, cases of deaths, if a plan can be proved wrong by hindsight or if an actor deviated from such a predefined SOP (see also a discussion on standard operating procedures and resulting liability by Bentivoglio [23]). Such arguments turned out to be the reason for an often hesitant response of emergency units concerning formalized planning. Business actors, on the other hand, want to unveil problems for smooth operation in order to bring a product or service better to the customer.

d) Another problem we experienced was that responsible organizations do not want to expose their activities to other organizations; specifically fire brigades and medical services are tight-lipped due to data privacy, and police units due to matters of secrecy. But, to formalize procedures in order to unveil resource conflicts partners have to disclose what they are doing where and with what. This would allow emergency services to discuss their courses of actions and resolve potential conflicts (of goals, of resources etc.). Even our proposal of a careful selection or automatic filtering could not overcome the distrust; and we heard that the police are insulating their command and control systems understandably in general.

e) Emergency services we talked to were interested in planning support before and documentation of actions after the operation. A direct operation support (means computer support during courses of action in operation) is still out of their scope: they say that most actions are manual tasks, any office automation is good for office workers but not for rescue organisations in the field. Simulation is done by training and exer-
cises, and an analysis is made by evaluating the results of these exercises. BPM software on the other hand is used for process planning, analysis and simulation, improvement and finally execution in a product or service environment. However, we were surprised when staff responsible for the deployment documentation approached us with interest in mobile checklist support in order to initiate, track and finalize operation documentation on and in time.

**2. Mode of operation - Practice and Work: a)** In many BPM applications the automation of processes is the driving objective, because process automation by information technologies saves time and costs. As indicated above, an overwhelming body of activities for emergency management is judged to be outside the scope of IT choreography. Hence, methods and tools for automation in the realms of process management do currently not affect emergency preparation and planning.

Most BPM tools are geared towards an automatic execution of processes as workflows. While doing so, this intention impacts strongly the methodology on how and in which order to model. Often, it forces users to enter details unnecessary for a non-automatic planning process. For the same reason, user interfaces are packed with complex functions, most of them unnecessary for planning without execution. We did not find any tools allowing one to scale up or down the interface according different application purposes. Consequently, our end users (fire fighters) were claiming that they are not able to use any BPM tools we proposed.

**b) While companies analyze according to costs and resources, emergency management organizations try to improve their procedures according to tactical and operational goals and time until these goals are reached [24, 25]. But since their courses of actions are not ruled by predominant repetitions, they cannot stipulate and consequently inspect predetermined courses of actions in advance. Hence, they rely to date on exercises and subsequent expert evaluation.**

**c) The few emergency plans we found are concentrating on internal processes within the organisation, while external connections and relationships are somehow neglected or only superficially mentioned. A clear “when what who with whom with which means” is mostly missing. Moreover, if processes have been identified at all, they merely revolve around the rather abstract observe-orient-decide-act cycle in order to improve communications inside this cycle. Commercial companies reveal a quite different attitude. They try to open their operations in order to establish efficient and effective value networks interacting with partners, retailers, and consumers.**

**3. IT Technology, Implementation and Usage of Tools: a) We experienced that abstract thinking about procedures and then translating these procedures into a diagram of icons with computer software is still mostly too abstract for many local crises managers. Formalization and abstraction are normally not the business of “normal” fire department chiefs or respective staff responsible for planning. Not to forget that staff also comes from voluntary organizations and thus they are normally following a completely different business in everyday life. We often experienced that while we can easily translate the description of courses of actions in entities of the process world, many persons of this domain struggle with this net of concepts and its logical linking. Thus, any tool support can only partly overcome the missing routine to abstract; we should allot a moderator or translator operating the tool, too.**
b) We also detected that most BPM tools are somehow over-sophisticated offering hundreds of functions for different typical business operations: modelling, printing, sharing and loading, analysis, simulation, load paths, evaluation, documentation, import/export and so on. Taking into account that planning staff from e.g. fire brigades are not necessarily IT and modelling experts, learning on how to use such tools (with a completely different terminology as used in emergency services) is far too laborious and appears to be distant from the real work. Actually, some older staff appeared to be IT-adverse or computer-illiterate, but this might change when the smartphone- and Internet experienced youth succeeds them in position.

4. Models and Concepts: a) BPM tools describe a business process as a list of *functionalities*, triggered by *events*, executed by *organisational units* (referenced by *roles, positions*), passing and creating *information objects*, and linked by *connectors* allowing one to control the flow of functionalities, i.e. how functions are called (*and, or, xor*) (Example EPC [26]). Apart from different naming (for example, our fire fighters said they do not execute *function(alitie)s* or *processes*, they insisted on *carrying out measures*), they also have additional concepts in use like a *measure carrier* and a *measure carrier type* with *capabilities*, which can be derived from the *rank* and are necessary for a *position*, with each measure following *tactical* and *strategic goals* [24]. These models are similar, but obviously not identical. Further research has to unveil whether important and necessary information is lost when switching to such a standard business process model.

b) In an execution stance, concepts for dynamic control flow are required for the emergency management domain. One typical control flow element in emergency management is escalation (going from a lower alarm level to a higher) with a complementary de-escalation. Emergency management planning does cover different procedures according to different warning levels, be it flooding, storm, or rain with respect to gauge levels, wind speed, or precipitation rate. Procedures of a higher level often include activities of lower levels, increased or extended specific measures, and possibly replacement of resources or activities, if a level is skipped. The same goes for de-escalation, where activities have to be “reversed” step by step (e.g. evacuation of a hospital or rest homes). Currently, modelling and execution of such “escalation” processes is neither implemented nor in research investigated as far as we know. Such dynamic control flows are typically not part of prevailing tools for business process management. Although they can be implemented with so-called worklets for different instances of a sub-process in principle [27], more natural implementations are desirable.

c) The most decisive impediment of process modelling is the quest for completeness. A process model always claims by nature a complete understanding of the intended course of action without any discrepancy. Incomplete and partial models are not “valid” with regard to the philosophy of process modelling. Unfortunately, many courses of action in emergency management have to be prepared in a stepwise approach and call for customisation during the event [9], since “effective response to a crisis is a combination of anticipation and improvisation” [28]. Although process modelling has given birth to adaptive and ad-hoc workflows, incompleteness and flexibility is still an open research issue.
**5. Organisational Issues:** a) Important differences revolve around the representation of the organisation and their units. While enterprises are mostly built upon permanent organisational units, emergency organisations rely on temporal units, with changing locations, roles, capacities, and the like.

b) Also, organisational changes might happen due to changes of phases caused by triggers [29] and this is limited supported by BPM or workflow tools [25]. Worse, some BPM tools often have only a rudimentary organisational model (for example, the BPMN standard only supports roles as pools and swim-lanes [30]). And if they have an organisational model, these tools expect a permanent assignment of persons to roles and positions. Capacities or capabilities are rarely elaborated.

c) In many instances, specific roles or positions require and also expect specific capabilities of a person by law or directives. On the other hand, resources sometimes require certain capabilities, i.e. only specifically trained persons can use a specific resource (e.g., rescue diver, rescuer from heights and depth, special crane driver).

d) While commercial organisations can easily adopt new systems and technologies (due to education in school and Universities, qualification measures and training), emergency service agencies with voluntary staff often have problems to train and educate their personal apart from emergency related issues. While companies select the person with the best qualification, voluntary organisations often have to live with the staff available regardless of general knowledge and qualifications. A responsible from a fire brigade told us off the record: "Well, we also have to work with staff, which works full-time as a forklift operator and has a helper syndrome. How to I educate him to think in terms of processes?" and how to train them to use and also to trust a computer.

**6. Terminology:** a) Most process modelling tools available stick to their own terminology and that is basically not changeable and not adaptable to other nomenclatures. This is inacceptable for somehow military oriented organizations like fire or police departments, who, even more difficult, also cultivate the use of acronyms for explicitness. They have to follow their own rules, legislation, and standards; a change of terminology could lead to confusion and failure especially with respect to the command structure.

b) We concentrated our research specifically on processes intersecting with processes of other organizations to unveil communication needs concerning use of the same resources (machines, places), mutual help, and the like. We focussed on these intersections, since they bear the most critical problems [31-33]. Thus, planners have to read and understand plans from other organisations, but ambulances, fire departments, and police forces use different terminologies, with –worse– also false friends. We obviously need translations and explanations of terms. Most BPM tools we know do not have any interfaces to something like glossaries or dictionaries.

**7. Goals and Decisions:** a) Underlying meta-models and analysis services of prevailing process management tools are tailored to business activities, not emergency management activities. Thus, they mostly suppose business interests of their users. To give an example, these tools can analyse concerning resources like time and money, but not according the achievement of objectives or goals. Correspondingly, the underlying meta-models of the tools do not tackle goals or objectives adequately. But we
learned that the fulfilment of tactical and operative goals is the core driver of opera-
tions in the emergency management domain. Although several criteria for process
analysis appear crucial for rescue organisations, the ultimate question and criterion for
process design remains unanswered: does my process adequately address the disaster?
In order to address this question, strategic and operational goals have to be assessed
and orchestrated rather than restructuring control flows in courses of actions. Unfor-
tunately, the majority of methods and tools for process modelling do not support the
elicitation of goals and objectives. At best, some tools support the representation of
linkages among activities and respective processes with goals, but they do not support
the networking of goals and their dependencies. For better collaboration of emergency
services, different goals and their consequences have to be unveiled [34].

b) Since goals and their balanced consideration are of crucial importance, process modelling means have to be enhanced by means for unveiling design rationales [35] important for reuse and exchange of plans: who has changed which plan why? Independent of the lack of goal-orientation, leveraging the quality of processes is the driver for modelling processes, i.e. different users should implement a comparable level of quality. This certainly also applies to rescue organisations, which is perfectly illustrated by the definition and use of standard operating procedures for fire brigades and standard medical services.

5 Conclusion

Although process modelling for emergency planning has been utilized by many se-
curity related projects, essential questions about the applicability of process modelling
concepts for emergency management practice have not yet been researched, e.g. does
the functional design of tools for process modelling coincide with the way of working
and thinking of rescue organisations or do the modelling concepts adequately address
the objectives of rescue organisations.

Our experience suggests the conclusion that business process management meth-
ods and tools cannot be directly applied to the emergency management domain be-
cause of mismatches among tool support, intentions, organisational practices and
experts' folklore.

To re-iterate, major impediments are:

* Available BPM tools do only fractionally support a change of terminology and never a change of model.

* Available BPM tools are typically targeting the automation of execution and this governs modelling method and user interfaces.

* The abstract world of process modelling is often incomprehensible for realistic and practical thinking rescue workers, fire men, and police men. Thus, they cannot use the BPM tools as is for planning. However, once courses of actions are modelled by process experts, processes become understandable and transparent for them.

Process modelling unveils laurels & darts for emergency preparation. Transparency and leveraged quality of courses of action are definitely a surplus of process model- ling for rescue organisations. But what is needed is a more generic and more flexible
approach for emergency management planning incorporating its specific peculiarities. BPM tools should at least allow a change of terminology and a modification of the model, should invest more in goal and organisation modelling and its analysis, and should provide a scalable, user-oriented interface leaving complexity to BPM experts or advanced learners.

**Acknowledgment.** This article was partly supported by the German Federal Ministry of Education and Research (BMBF) security research program and also partly by the B-IT Foundation. Special thanks go to the fire brigades of the City of Cologne as well as Rhine-Erft and Siegen-Wittgenstein County.

# 6 References

1. United States Environmental Protection Agency: Guidance for Preparing Standard Operating Procedures (SOPs) In: Office of Environmental Information Washington, D. (ed.), vol. EPA QA/G-6, Washington, DC 20460 (2007)

2. Cook, J.L.: Standard operating procedures and guidelines. Fire Engineering Books & Videos (1998)

3. Hammer, M., Champy, J.: Reengineering the Corporation–A manifesto for Business Revolution. Harper Business Essentials, New York, NY (1993)

4. Lindsay, A., Downs, D., Lunn, K.: Business processes—attempts to find a definition. Information and Software Technology 45, 1015-1019 (2003)

5. Rüppel, U., Wagenknecht, A.: Improving emergency management by formal dynamic process-modelling. In: 24th Conference on Information Technology in Construction. (2007)

6. Khalilbeigi, M., Bradler, D., Schweizer, I., Probst, F., Steimle, J.: Towards Computer Support of Paper Workflows in Emergency Management. In: Proceedings of the 7th International ISCRAM Conference. (2010)

7. Paulheim, H., Döweling, S., Tso-Sutter, K., Probst, F., Ziegert, T.: Improving usability of integrated emergency response systems: the SoKNOS approach. In: Informatik 2009: Im Focus das Leben, Beiträge der 39. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 28.9.-2.10.2009, pp. 1435-1449. (2009)

8. Becker, T., Lee, B.-S., Koch, R.: Effiziente Entscheidungsunterstützung im Krisenfall durch interaktive Standard Operating Procedures. Workshop "IT-Unterstützung von Einsatz- und Rettungskräften: Interdisziplinäre Anforderungsanalyse, Architekturen und Gestaltungskonzepte", Conference Software Engineering 2011, Karlsruhe, Germany (2011)

9. Kittel, K., Sackmann, S.: Gaining Flexibility and Compliance in Rescue Processes with BPM. In: Sixth International Conference on Availability, Reliability and Security (ARES), 2011, pp. 639-644. IEEE (2011)

10. Soini, J., Polancic, G.: Toward adaptable communication and enhanced collaboration in global crisis management using process modeling. In: Kocaoglu, D.F., Anderson, T. R. & Daim, T.U. (eds.) (ed.) Proceedings of PICMET '10, Portland International Center for Management of Engineering and Technology, Technology Management for Global Economic Growth, pp. pp. 981-990, Phuket, Thailand (2010)
11. Ziebermayr, T., Huber, J., Kollarits, S., Ortner, M.: A Proposal for the Application of Dynamic Workflows in Disaster Management: A Process Model Language Customized for Disaster Management. In: Proceedings of the 22 International Workshop on Database and Expert Systems Applications, pp. 284-288. IEEE (2011)

12. de Leoni, M., Mecella, M.: Mobile process management through web services. In: 2010 IEEE International Conference on Services Computing (SCC), pp. 378-385. IEEE, (2010)

13. Franke, J., Charoy, F.: Design of a Collaborative Disaster Response Process Management System. International Conference on the Design of Cooperative Systems (COOP'2020), Aix-en-Provence, France (2010)

14. Franke, J., Widera, A., Charoy, F., Hellingrath, B., Ulmer, C.: Reference Process Models and Systems for Inter-Organizational Ad-Hoc Coordination-Supply Chain Management in Humanitarian Operations. In: Proceedings of the 8th International ISCRAM Conference. (2011)

15. Kunze, C., Rodriguez, D., Shammas, L., Chandra-Sekaran, A., Weber, B.: Nutzung von Sensornetzwerken und mobilen Informationsgeräten für die Situationserfassung und die Prozessunterstützung bei Massenanfällen von Verletzten. GI Jahrestagung 2009 (2009)

16. Sedlmayr, M.: Proaktive Assistenz zur kontextabhängigen und zielorientierten Unterstützung bei der Indikationsstellung und Anwendung von Behandlungsmaßnahmen in der Intensivmedizin. Shaker Verlag, Aachen (2008)

17. Fuenffinger, M., Rose, T., Rupprecht, C., Schott, H., Sieper, A.: Management von Prozesswissen in projekthaften Prozessen. Geschäftsprozessorientiertes Wissens- management, Springer, Heidelberg (2002)

18. Rose, T., Peinel, G., Arsenova, E.: Process management support for emergency management procedures. In: eChallenges 2008. (2008)

19. Peinel, G., Rose, T., Berger, E.: Process-oriented Risk Management for Smaller Municipalities. In: 4th International Conference on Information Systems for Crisis Response and Management (ISCRAM). (2007)

20. Soboll, M., Binder, B., Quix, C., Geisler, S.: Prozessmodellierung der mobilen Datenerfassung für den Rettungsdienst bei einer Großschadenslage. Tagungsband zum 16. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.V. (GI), Düsseldorf (2009)

21. Peinel, G., Rose, T.: Deploying process management for emergency services - Lessons learnt and research required. Future Security - 6th Security Research Conference, Berlin, Germany (2010)

22. Harand, A., Peinel, G., Rose, T.: Process Structures in Crises Management. Future Security 2011, .Fraunhofer Group for Defense and Security, Berlin (2011)

23. Bentivoglio, J.T.: SOPs and Liability. Fire Engineering. PennWell Corporation (1995)

24. Arsenova, E.: Unterstützung der Prozessmodellierung im Notfallmanagement. In: Informatiktage 2008. Gesellschaft für Informatik (2008)

25. Reijers, H., Jansen-Vullers, M., Zur Muehlen, M., Appl, W.: Workflow management systems+ swarm intelligence= dynamic task assignment for emergency management applications. Business Process Management 125-140 (2007)

26. Keller, G., Nüttgens, M., Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi), Universität des Saarlandes 89 (1992)
27. Adams, M., ter Hofstede, A.H.M., Edmond, D., van der Aalst, W.M.P.: Implementing dynamic flexibility in workflows using worklets. BPMCenter Report 6, 06 (2006)

28. Lalonde, C.: Changing the Paradigm of Crisis Management: How to Put OD in the Process. Buono, AF, Grossmann, R. Lobnig, H. & Mayer, K.(2011). The changing paradigm of consulting: adjusting to the fast-paced world. United States of America: Information Age Publishing, inc. Department of Management, University Laval (2011)

29. Hoogendoorn, M., Jonker, C.M., Popova, V., Sharpaskykh, A., Xu, L.: Formal modelling and comparing of disaster plans. In: Proceedings of the Second International Conference on Information Systems for Crisis Response and Management ISCRAM '05, pp. 97-107. (2005)

30. BPMN O.M.G., Business Process Model and Notation (BPMN), Version 2.0, http://www.omg.org/spec/BPMN/2.0/PDF (4/2013)

31. Jäger, B., VFH in Wiesbaden, Studienort Gießen, http://www.polizei.hessen.de/ (web page restructured) (3/2011)

32. Lasogga, F., von Ameln, F.: Kooperation bei Großschadensereignissen. Gruppendynamik und Organisationsberatung 41, 157-176 (2010)

33. Schafer, W.A., Carroll, J.M., Haynes, S.R., Abrams, S.: Emergency management planning as collaborative community work. Journal of Homeland Security and Emergency Management 5, 10 (2008)

34. Smith, W., Dowell, J., Ortega-Lafuente, M.: Designing paper disasters: An authoring environment for developing training exercises in integrated emergency management. Cognition, Technology & Work 1, 119-132 (1999)

35. Potts, C., Bruns, G.: Recording the reasons for design decisions. pp. 418-427. IEEE Computer Society Press (1988)