Workflow Support for Failure Management in Federated Organizations
Ralf Klamma, Peter Peters, Matthias Jarke
Informatik V (Information Systems), RWTH Aachen
email: {klamma|peters|jarke}@informatik.rwth-aachen.de
Abstract
Failure management for complex products (such as
production machinery) exemplifies a class of reactive
workflow management tasks for which current WFMS
offer few solutions. This class is characterized by great
variation of tasks and cooperation patterns, the need to
bring rich context knowledge to many different kinds of
workplaces, and the need to interlink effective workflow
execution with continuous organizational learning. In the
German FOQUS project, we have prototyped and
evaluated a WFMS architecture which addresses these
problems through (a) the encapsulation of problem
context in electronic circulation folders; (b) a semantic
trading mechanism managing the flow of such folders in a
highly flexible manner; (c) a concept for process-
integrated workplaces in which the necessary information
is made effectively available in the usual working
environment of the different kinds of users; (d)
metamodeling techniques to support change in this
environment.
1. Introduction
Workflow models and workflow management systems
(WFMS) are determined by the kinds of tasks they are
intended to support.
Early WFMS, e.g. FlowMark by IBM, CSE/
WorkFlow® by CSE, and WorkParty by SNI, pursue the
activity-oriented aspect of workflow management [8, 29,
18] and are best suited to support long, standardized task
chains. They have been criticized because they tend to
neglect the flexible interaction between agents for
exchanging complex structured (possibly multimedia)
information. Two alternative views have emerged.
Document-oriented WFMS, e.g. DM/Workflow by
Intergraph or OPEN/workflow by Wang Laboratories,
Inc., concentrate on the management of complex
structured information in a predefined homogeneous
setting for special purposes. Without regarding special
document processing tasks, this view reflects the situation
in most companies. Information is produced and stored,
but may never reach interested persons, because there are
no defined information flows.
Service-oriented workflows, such as the Coordinator by
Action Technologies Inc., emphasize the need for closing
the contractual loop between customers and providers of
services [15, 26]. Their main advantage is an explicit
modeling of the coordination relationships between agents
involved. Their main weakness is that they focus on
coordination only and do not directly address the
knowledge context created and exchanged during
workflows. Like activity-oriented workflows, but in
contrast to the document-oriented ones, they focus on
short-term aspects rather than on the long-term creation
and management of organizational knowledge.
In this paper, we investigate an extension to service-
oriented workflows which could be briefly characterized
as highly flexible reactive workflow systems with
embedded organizational learning support. The
application domain we studied for such workflows is
failure management for complex technical products, such
as those used in production machinery.
In section 2, we characterize this domain and its
workflow management requirements based on
experiences in an interdisciplinary project with
engineering design researchers and industry, the FOQUS
project. We then present an architecture that has been
developed and evaluated within the project (section 3).
The main ingredients of this architecture include: (a) the
use of electronic folders as a movable encapsulation
mechanism for task-related context knowledge; (b) a
"semantic trading" mechanism which serves both as a
workflow engine and as a broker helping the acquisition
of additional possibly necessary context and contact
information; and (c) a "bridge" component which enables
an integration of heterogeneous workplaces into the
workflow process defined in the trader. All of these
components need an infrastructure of sharable and
extensible background knowledge in order to function;
this infrastructure is encoded in meta models described in
section 4. Section 5 completes the paper with some
observations from the experimental application of this
technology in manufacturing organizations and outlines
future work.
2. Failure Management as a Business Process
In this section, we provide a characterization of failure
management (FM) and show why traditional WFMS fail
for this setting. We define some requirements for more
successful WFMS and introduce the so-called "principle
of escalation" that we later use as a guideline for our
design.
2.1 The importance of failure management
Global markets with informed customers cause new
competitive pressure. Manufacturers face more and more
competitors whose products have comparable
characteristics. In particular, small and medium-sized
organizations with a narrow product range but high
market share can only evade into new markets if they
continuously improve quality and reduce time-to-market
as well as costs [28, 22].
An effective way to reach both goals is to reduce faults
or failures throughout the product life cycle. According to
[5], 90% of the customers unsatisfied with product quality
will avoid that product in the future. Every failure beyond
the acceptable limit of the market leader leads to sales
reductions between 3 and 4%. Despite the TQM
movement, the potential of this insight is still significant:
surveys performed in the FOQUS project [7, 24] have
shown that 60% of the errors made in production lines are
repeat errors, causing a loss of 10% of personnel and
machine usage capacity.
Fault-free production is an ideal often not achievable in
time and cost-constrained production lines. Thus, not only
product quality but also service quality are important for
customer satisfaction. Reaction time is the most
significant factor; our surveys pointed out that the typical
complaint processing duration is nine to ten days (80% of
responding manufacturers) and that on average three
departments (ten departments) are affected by complaint
processing.
Only the combination of both requirements, i.e.
reduction of repeat faults in production and increase of
service quality, will satisfy customers, thus strengthening
the ties between customers and enterprises. Both
requirements demand the design of reactive and
preventive management processes based on a quality loop
within the companies [22], improving capture and
exchange of knowledge about failures. Failure
management (FM) is the modeling, enacting and
maintaining of reactive and preventive processes. It must
be investigated in a holistic way, considering the
organizational, personnel and technical aspects.
An example will illustrate the complexity of the task.
When a complaint by a customer that his newly bought
gear unit loses oil is reported to the manufacturer's call
center, and the call center cannot give direct advice a
service engineer drives to the customer. He detects the
fault (sealing rings are not assembled correctly) and must
take measures to correct it (e.g. exchange of gear unit).
For preventing further failure occurrences, failure
handling is passed on to the departments which are
responsible for the correction, due to his assumption about
the failure cause. Every department involved needs to
look for causes and to take corrective measures whose
success is reported back to the process owners. After
several assumptions and trials the cause is finally unveiled
: the failure was caused in product assembly planning,
propagated to product assembly and not detected by
quality control because test routines were not applied
effectively. Two types of organizational learning can take
place: the call center can be informed how to provide a
quick fix, and the product assembly can avoid the
problem in future product versions.
2.2 WFMS requirements for failure management
From the information technology point of view, the
example raises several challenges. Since the product life
cycle is distributed in time and space, faults detected in a
late stage of the product life cycle phases are not
necessarily produced there. Therefore, the process of
failure management potentially involves all departments
taking part in the product life cycle. -- but tasks must be
escalated in a targeted, problem-driven manner, otherwise
information overload will be the result.
Inter- and intra-organizational barriers have to be
bridged by workflows and information flows:
1. Informational barriers: For example, the
information available for the assembly planning agent
is not available for the service engineer at the
customer site.
2. Conceptual (or knowledge) barriers: For example,
the knowledge about assembly processes for gear units
is not available to the CAD engineer.
3. Technological barriers: For example, the service
engineer has no access to the enterprise networks, thus
no direct exchange of electronically stored data is
possible.
WFMS seem to provide a promising basis for tackling
the problems that result from the named barriers.
However, most systems have been developed and
implemented based on the following assumptions:
1. The workflows established are quite stable and easy to
maintain. WFMS work best if well-documented
business processes are established and can be
supported electronically.
2. A detailed and consistent business process model
exists which is understood by all people involved in
the project. Some WFMS use reference models for
special application domains which can be customized
to individual enterprise needs.
3. The agents using the systems have comparable skills.
Because of the overall business process model, WFMS
support is given to all agents by the same means.
4. WFMS work together with existing applications and
solutions in the application area.
 These assumptions cause several problems in a
distributed and flexible area like FM.
1. FM processes are not stable but change frequently.
Experiences with WFMS show that they are difficult
to adapt to process changes, thus forcing “cow paths”
[9] to be established. Massive reengineering of
business models is still an open problem [2].
2. On a detailed workflow level FM processes are not
well-defined and process ownership belongs to the
departments involved in the process. Therefore,
monolithic and complex business process models
which must be understood by all agents do not make
sense for FM. WFMS using them do not reflect the
federated organization context of distributed or virtual
enterprises [1].
3. Failure processes are often handled in an ad-hoc
manner and spread over several departments, where
agents with different skills do their day-to-day work
using different work environments. Therefore, task-
and person-specific support by a WFMS is needed.
4. In a heterogeneous system, there is no integration at
all because of the variety of systems. WFMS used here
rely on simple concepts like task lists, email or PERT
charts.
Many studies about implementing workflow concepts
in enterprises address problem similar to those stated
above [16, 3]. These problems raise certain requirements
to be fulfilled by WFMS support for flexible, distributed
FM processes:
1. Flexible mechanisms for modeling, enacting and
maintaining workflows and information flows are
needed. New variants of products cause frequently
new types of failures. Thus new or changed workflows
and information flows emerge in which existing
knowledge has to be applied.
2. Workflow management support is not only based on
organizational needs but also on the interaction and
communication needs of the involved agents. The
simultaneous needs for exchanging data and bridging
existing culture, language, and system barriers create
uncertainty and equivocality [4]. Thus, the possibility
to interact with each other to coordinate work and
exchange relevant information must be provided by a
FM system.
3. For users, tool support must be given on the right level
of usage. Therefore, WFMS have to embed and enrich
existing workplaces. This means the flexible
integration of existing tools with the WFMS by
providing several levels of information and service
exchange support. Furthermore, collaboration and
information exchange tools, like ad hoc querying,
multimedia, and groupware tools, must be made
available [20, 24].
4. The management and exchange of complex structured
information produced by legacy applications, e.g.
CAD drawings, NC programs, catalogs stored in
heterogeneous data sources, must be facilitated.
2.3 The principle of escalation
Agents processing failures follow a typical schema.
After detecting the failure, they try to find a cause. If they
find one, and if it is possible to correct the failure ad hoc,
they will do so. If agents are not able to find a cause or if
a local problem solution is not possible, they try to report
the case to another agent, who is skilled enough and
responsible. But perhaps reporting a failure is costly,
displeasing, or there is no knowledge about
responsibilities.
If a failure must be processed in different departments
in order to analyze the problem and define a measure, two
problems occur. Either there is no allocation of
responsibility causing delays in processing and reducing
the effects of failure elimination, or multiple defined
responsibilities cause mutual obstruction in processing.
In order to reduce the knowledge and responsibility
problems, FOQUS proposed the escalation principle for
interdepartmental processes with the aim to
• enable a direct processing of failures,
• systematically detect spheres of competence, and
• give structured support in processing the failure
Escalation describes a mechanism enabling the
processing of failures and the exchange of knowledge
between spheres of competence. The elements of the
escalation principle are shown in Figure 1.
Spheres of competence describe workplaces or
departments in the distributed product life cycle, e.g. the
hot-line workplace, the service department, and the
assembly planning department. These workplaces or
departments perform processes and contribute to the
whole FM process.
Micro processes describe actions to be performed in
one sphere of competence. There are three steps,
structurally equal for every area but different in
implementation depending on tasks and skills of agents:
Sphere of
competence
Correct
Capture
Sphere of
competence
Analyze
Correct
Sphere of Escalate
competence Capture
Analyze
failure
Correct
Escalate
Capture failure
Analyze
Failure
detection

Figure 1: Escalation principle
1. Capturing the failure: the process of gathering and
documenting available data.
2. Analyzing the failure: the process of interpreting
available information, i.e. determining possible causes
and defining applicable measures. If no final solution
is applicable or the agent presumes far-reaching
consequences, the failure can be escalated.
3. Correcting the fai lure: the process of defining,
performing and tracing measures for failure treatment.
Success of measures is communicated to agents
involved in the escalation.
Macro processes describe a directed graph of
escalation steps. With every escalation step the failure is
passed to one or more spheres of competence. The
conditions for escalation are negotiated between the
agents in the spheres.
With these elements it is possible to describe micro
processes of spheres and to assemble them in a flexible
manner. Differences in culture, language and systems can
be encapsulated in the spheres and negotiation between
agents is driven by the escalation principle. Negotiation
across spheres can be founded on well-defined criteria
described in contracts, as in the language-action approach
[26]
3. The FOQUS WFMS
The escalation principle suggests two goals that need
to be accomplished by a suitable architecture for failure
management:
1. Integration within the FM system (internal
integration): Methods, tools and knowledge have to
be integrated in micro and macro processes. The
strategy here is to integrate top-down based on
cooperative modeling of processes and data. Tools
have to be integrated in spheres of competence, and
spheres of competence have to be integrated to realize
distributed FM processes.
2. Integration into the heterogeneous organizational
environment (external integration): Existing
manufacturing and service processes, information
sources, and legacy applications have to be
considered. The strategy here is to reengineer bottom-
up data and processes to extract models of processes,
information sources and their contents.
On the conceptual level, internal integration means
documented models with open interfaces and uniform
failure data models. Data models gained from reverse
engineering for external integration have been described
by interface definition for special purposes, e.g. automatic
gathering of CAQ data for multidimensional coordination
measuring instruments, or by means of a comprehensive
product, process and machine model [23]. The context of
a failure is helpful for both analyzing and classifying the
failure. Every failure context can be described by a triple
(product, process, machine). The coupling with the failure
data model has been reached by means of a data
dictionary. Finally, processes and information have been
integrated in electronic circulation folders.
On a technical level, internal integration means
integration of tools at one workplace (sphere of
competence) and integration of workplaces in a
distributed, interdepartmental environment. The core idea
of external workplace integration is the introduction of a
central instance, the Trader system, consisting of a
repository with defined models [12] and three components
for folder, workflow, and query management in a
heterogeneous system world. Bridges make the traded
information available to the different kinds of individual
workplaces in a customized manner.
3.1 Electronic circulation folders
To integrate workflows and information flows, we
employ the electronic circulation folder metaphor to carry
context around with a workflow.
The approach is described best as an object migration
view on workflow management [16]. The core idea is,
that the document includes the work to do. Informational,
conceptual, and technical barriers are bridged by the
management of folders and their linkage to the Trader
system. All the information needed for processing a
failure is stored in folders or linked to them. Folders
capture all the information gathered in the process, thus
creating temporary knowledge bases available to all
agents processing failures. Folders are further given direct
access to information sources in the enterprise and to tools
specific to the workplaces. Also, negotiation protocols for
defined workflows as well as mechanisms for ad hoc
escalation are linked to folders.
 A folder is created every time a failure is detected. All The segment history contains link chains concerning
information related to the case is collected in the folder. If history and version management of folders needed for
a local correction is not possible, the folder knows from process controlling and knowledge capturing. Process

Segment Purpose Support Data Persistence

Project management Folder life cycle control macro/micro original persistent
Failure data Data core for failures micro original persistent
Workplace documents Documents specific to work place micro link temporal
Agents Linkage between roles and persons macro/micro original temporal
Tools Linkage for available tools micro original temporal
Versions & history History of escalation and split control macro/micro link persistent

Table 1: Folder segments

defined models to which agents it needs to be escalated. history is also needed for documentation and monitoring
Because folders can be escalated to different agents at the of the performed escalation. For guaranteeing
same time, each escalation creates new versions. But completeness and consistence of folders, the content of
version management is simplified by the fact that segments grows monotonously, so that the deletion of
information cannot be deleted from folders. process persistent material is not possible.
Formally and on the user interface, a folder is an object
consisting of six segments which provide access to
workflows, failure data, documents, system information,
and version data. An overview of the segments is given in
Table 1. An example of a segment is given in Figure 2. A
multimedia workplace document is related to the
description of a failure (all readable information in
German)
The segment project management contains persistent
folder data for controlling macro processes as well as a
portfolio for local task management at the work place.
The data will be updated each time the folder escalates.
The data describe folder routing, schedules, cost
estimation plans, time the folder spend at workplaces, and
so on.
The segment failure data primarily consists of
persistent folder data containing the descriptions, context,
analysis and classification of errors, but also technological Figure 2: Segment workplace documents
data concerning storage and representation of failure data
in external data sources. 3.2 Folder management tasks
The segment workplace documentation links to
workplace-specific documents. Documentation contains Workflow management organizes the life cycle of a
textual and multimedia material for describing, analyzing, folder. Primary goals are (1) to guarantee consistency and
and correcting the failure (e.g. CAD drawings, machine transparency in macro processes each time the folder is
photographs, products parts, sounds, etc.). Furthermore, transferred and (2) to support the agent processing the
catalogues for federated queries are linked to this segment folder at the workplace with non-local information and
to give the user (specific to his role) the possibility to services. For (1) tasks for workflow management are
query the failure in connected to data sources [12]. defined as follows:
The segment agents contains temporal assignments
from persons to roles in the FM system. The segments 1. Folder transfer. Primary copies are at the
refers to the concept agent in the language model. workplaces, where the failure is actually processed.
The segment tools consists of temporal assignments Secondary copies are left on each workplace in the
for applications specific to workplace and role. These escalation graph until the folder is closed. These
tools are linked to the folder based on experience. copies are updated after every change in persistent
Additional tool linkage on demand is also possible by folder segments, thus giving feedback to all agents in
querying connected data sources. The segment refers to the escalation graph. For the FM system, the process
the concept tool in the language model. of transferring the folder consists of following steps:
 • Find defined sphere of competence for the
transfer. If no responsible agent is defined for an
escalation step there is a predefined agent, the
process owner, who is responsible for the folder
by default. This agent will then be contacted by
the system. The process owner then decides if
there will be an ad hoc escalation or if the
treatment of the failure is stopped, e.g. for
economical reasons.
• Establish contact between spheres (either direct
or e.g. by email).
• Enable negotiation process after direct contact.
For every pair of spheres individual negotiation
protocols can be defined.
• Transfer the folder after successful negotiation,
contact the process owner otherwise. Before the
transfer, temporal links have to be substituted
and new versions of the folder are created for the
spheres accepting the folder, constituting a
directed graph. The folder life cycle can be
traced with this graph.
• Gather the receipts of transfer from both
spheres.
2. Folder trace. Every person using the FM system can
monitor the escalation graphs. The grade of
monitoring is defined by the temporary role of the
persons.
• Every person involved in the process can query
the progress of escalation from the history
segment (the folder graph). Feedback is given
automatically to every person involved if the
folder is closed.
• The process owner can monitor folders and stop
escalation from the segment project
management any time.
If the user is requesting information not contained in
the folder but in external data sources, the FM system
mediates those data to the user (2). Because the FM
system treats external data sources and workplaces the
same way, users can also query other wo rkplaces thus
supporting communication in failure processing.
3.3 Folder circulation via traders
Despite the decentralized development process, the FM
system currently manage the acquired information under
central control to avoid inconsistencies and to provide an
appropriate version control of folders during their life
cycle. These requirements led to an integration approach
that uses a repository as a tool that provides sharing and
integration of knowledge and the ability to maintain the
consistency of objects, relations and their meanings in the
organizational context. The repository is responsible for
the management and exchange of complex structured
information.
The overall architecture of the FM system is given in
Figure 3.
The Trader system in the middle of the figure is
connected via a network or serial lines to enterprise data
sources and workplaces. The Trader system consists of a
central repository, a query manager, a workflow
engine, a folder manager, and interfaces to external and
internal sources.
The Trader repository consists of four components for
the management integration tasks:
Heterogeneous information sources
Network
Federated
externe Kommunikation
query interface
Query
manager
External
integration Workflow
Internal engine
integration Trader
Folder
database
manager
DB-Kommunikation
database communication interface
Folder management Workflow management
with work places with work places
Network
Work places
Figure 3: Integrated Trader architecture
1. In the external knowledge component the federated
schemata, functions for querying the federated
databases, and triggers are stored. The folder
manager uses this knowledge for the segments
"project management” and "workplace documents”.
The query manager uses the knowledge for
answering predefined or ad hoc queries built with
special tools [20]. The workflow engine uses defined
triggers for initiating database actions.
2. At the core of the internal knowledge component lies
the uniform failure data model and the escalation
models for enacting and tracing measures. The failure
data model allows queries on distant failure databases.
The folder manager uses the information for the
segments "project management", "failure data", and
"history". The query manager uses knowledge for
routing queries to workplaces. The workflow engine
uses the escalation models for handing down folders.
3. The third component consists of agent and tool
models. The agent model defines spheres of
competence and the tool model contains knowledge
about available tools. The folder manager uses that
knowledge for the segments "agents" and "tools". The
workflow engine gets the information which person is
linked to an agent on a certain workplace.
4. The component communication knowledge consists of
negotiation protocols. Possible communication and
negotiation patterns between workplaces as well as
protocols for querying external data sources are
specified by statecharts [10]. The query manager
uses the protocols for automatic interaction with
 databases. The workflow engine uses the knowledge
for enacting negotiation processes.
3.4 Workplace integration via bridges
A tool called Bridge is responsible for accepting and
handing down folders as well as for tool integration tasks.
A Bridge has a local database for storing folders and
tool data. The Bridge can read and write on every segment
of the folders stored in the local database For the Trader
system the workplaces are federated information systems,
too. All Trader tools can access workplaces via defined
interfaces and communication protocols. The Bridge
(Figure 4) is communicating with the Trader system via
the database communication interface.
Acceptance and hand down of folders
database communication interface
Folder Tool
management management
User interface
Tool control tool feedback
Werkzeug
Werkzeug
Werkzeug
Folder data exchange Tool
Werkzeugschnittstellen
Werkzeugschnittstellen
Werkzeugschnittstellen
Tool interfaces
Figure 4: Integrated workplace (Bridge)
The three main tasks of the Bridge are reflected in the
architecture:
• Local folder management: For accepting and
handing down folders, primary and secondary copies
and folder query handling. If a user is logged into his
workplace, all folder transfer requests will directly be
notified by a requester, otherwise he will be notified
asynchronously, e.g. by email. Every folder can be
negotiated on with the requesting Bridge by
negotiation protocols defined for folders and work
places.
• Local task management: For every folder transferred
to the workplace, a new task is created. The tasks can
be refined locally, e.g. by additional control data in the
segment "project management", negotiation results,
and personal preferences.
• Local tool management : Tools built with libraries
developed for tool integration, can exchange data and
task information with the Bridge. Proprietary tools can
be started and stopped from the Bridge.
Tool integration [27] has concentrated on data, control
and integration dimension. Tighter integration with the
process can be reached by more sophisticated construction
of process-integrated workplaces [25]. Tools for micro
process support were developed by our partners or already
existed at customer sites. So only tool wrapping
mechanisms (black box integration) as well as simple
data, control and representation mechanisms were used:
• Representation integration was achieved by a common
style guide and commercially available user interface
classes.
• Data integration was achieved by the folder approach
and the uniform failure data model. Common libraries
for accessing the local database at the workplace have
been developed.
• Control integration, defined as offering and accepting
services, consists of a task exchange mechanisms
based on statecharts.
On the micro process level, tools have to be integrated
into the heterogeneous organizational environment. Thus,
they access every data resource defined in the Trader
system by using the mechanisms implemented in the
folder segments. For example, predefined queries [12] are
Task
Management linked to the segment "workplace documents". The query
is sent to the query manager and transformed into SQL
statements for the selected database based on the
repository. The SQL statements are then sent to the
connected databases by means of protocols processed by
the workflow engine. By assembling the partial answers
task exchange the query manager constructs the answer table and the
workflow engine replicates that table to the local
database at the workplace. For example, queries deal with
budgets, schedules, deadlines and actual workflow
progress information for a folder workflow.
4. Formal Models in the Trader Repository
The WFMS architecture described in the previous
section relies on shared representations of knowledge
encoded in meta models which offer languages to
describe workflows and information flows under a
common conceptualization. In this section, we describe
the main modeling concepts used to organize the
information in the trader repository.
The core of the formal language (Figure 5) is derived
from the process model proposed by McMenamin and
Palmer [14]. An input (object) is consumed and
manipulated by a system and an output is produced. The
system itself consists of processes, describing a workflow,
processed by an agent using tools.
The formal model, defined in the knowledge
representation language Telos [17], has three purposes.
(1) Defining the flow of FM processes. (2) Defining the
interfaces for intra- and interdepartmental coordination
and communication. (3) Providing the basis for
implementing or reusing tools in every step of the micro
processes as well as for WFMS specification of macro
processes. These goals can be mapped on two areas;
workflow modeling and information modeling.
 contains
contains
uses
Agent Tool
processes supports
contains
produces contains
Object Process
consumes
isA
Activity
Figure 5: Workflow modeling concepts
Workflow modeling means the modeling of FM
processes but also the interaction with other processes in
the organizational context.
Describing the processes assists
• a company-wide understanding of certain concepts
and workflows, needed for coupling systems
• defined interfaces between spheres of competence
• identification of agents and exchangeable information
in every step
In short, the concepts and their relations are as follows:
1. The concepts process/activity describe workflows
(e.g. capture, analysis and correction of failures)
performed by agents. Processes can be refined by the
contains attribute. Refined processes are coupled by
objects. They can branch (produced objects are used
by different processes) and unite (produced object are
used by one process). The concept activity is a
specialization of the concept process describing
atomic processes. Agents can perform these steps
autonomously as long as the modeled objects are
produced.
2. The concept agent describes humans performing a
process. The concept agent can consist of a team of
agents, e.g. the quality control team.
3. Tools are technologies supporting the agents
performing their tasks. There is a clear distinction
between tools and additional resources. Tools can be
structured by a contains attribute.
4. Objects are artifacts consumed, manipulated or
produced in FM processes. Objects can be
decomposed by a contains attribute.
The additional concepts event, action, and condition
are not shown in Figure 5. External events like a
telephone call at a hot-line can start FM processes. FM
processes can also start actions outside the system. Pre-
and post conditions are used for situations in which the
existence of objects is not sufficient for deciding whether
a process should be performed or not.
The elements of the language model are linked by
attributes. Thus, the link between spheres of competence
can be defined by the objects exchanged, providing a
defined interface for task relevant information exchange.
The problem of responsibility is solved through linkage of
agents with processes. Based on this specification, intra-
and interdepartmental workflows and information access
can be supported by a WFMS. The workflows in one
sphere can be described at a sufficient level of abstraction
to serve as basis for the specification of tools linked to
agents and processes.
contains
produces contains
Object Process
consumes
described by
stored
Content represents
Media allows Presentation
Figure 6: Information modeling concepts
Information modeling (Figure 6) is the modeling of
the information needed at the interfaces in micro cycles
and macro processes. Describing the information flows
assures
• the avoidance of media breaks and information holes
in and between spheres
• a common data specification at system level
• the support of information exchange in a
heterogeneous system world
• the availability of a complete and as far as needed
uniform description of information
The concepts added are described as follows:
1. Content is a description of the information /object
structure. Especially objects structured by contains
attributes (e.g. parts lists) need an overview of the
contained information.
2. Media describes the form in which an object is saved.
Non-computerized forms of information management
can cause special activities like scanning or
transforming data.
3. Presentation can (but need not) depend on the media.
In particular, computerized forms of information
management allow different presentations with
available front ends. The usage of presentations
depends on the consuming process of that object.
Modeling is needed for common understanding and
defining interfaces for real information and work
exchange between agents. The granularity of modeling
the spheres themselves is left to local departments. Even
other approaches are possible as long as the modeled
information is produced. Therefore, our approach avoids
monolithic process models. Communication and
interaction needs are based on well-defined interfaces.
Changes on micro process level are handled within the
departments. Changes or inventions on macro process
level are negotiated between the spheres.
The process of modeling was performed in a
cooperative manner. Like in the predecessor project
WibQus [19, 23], the object base management system
ConceptBase [11] was used as conceptual modeling tool
and for storage of the repository. Two case studies were
performed with industrial partners. The partner engineers
trained in using the language worked as mediators with
the company people. Every department described their
local processes and objects autonomously. The coupling
of wo rkflows and information flows was reached by
bilateral negotiation processes. The constructed models
served as vocabulary with project wide validity and as a
starting point for system, interface, and tool specification.
To guarantee a uniform data model for FM tools, the
project partners in FOQUS developed a common failure
data model on the basis of identified objects to be
exchanged between spheres. Four main modeling areas
for FM have been identified: Failure description
(attributes of capturing failures), failure context
(products, processes, and machines, typically transferred
from organizational data sources), failure analysis
(symptoms, reasons, and measures), and failure
classification.
With the models created in the cooperative process a
first step to a flexible and distributed FM system is
reached.
5. Summary and Outlook
In this paper we have introduced fundamental concepts
and technologies to support the workflows and
information flows for flexible, distributed FM in a
federated organizational context, namely
• the escalation principle, to preliminarily structure the
distributed FM processes by systematically identifying
spheres of competence and assembling them in a
flexible manner,
• the modeling language for FM processes which
enables a sufficient degree of common understanding
of workflows and information flows in distributed FM
processes
• defined interfaces at system level and support for
system and tool development,
• the electronic circulation folder approach to integrate
workflows and information flows,
• the workflow management concepts based on the
defined models and folder approach, and
• the system architecture to support distributed FM
processes in organizations which depend on federated
information systems.
Most of the more than 350 enterprises surveyed in
FOQUS are planning for FM systems in this decade, but
so far little support is given by software companies.
Therefore, our approach was regarded with great interest
at the workshops performed in the project. Most of the
system architecture has been implemented and shown in
an integrated demonstration at the final project review.
The many constructive comments and suggestions made
by the participants will be included in further
specification and implementation tasks. In the context of
FOQUS, the special problems of variant rich and
innovative productions which were not discussed in the
paper have also been tackled. Our deliberations have
shown that available WFMS generally are not suitable for
this problem context. Thus, more sophisticated methods
of information and workflow management are necessary
for the continuous maintenance of knowledge in variant-
rich and innovative product or service life cycles.
Acknowledgements: This work was supported by the
German Federal Ministry of Education, Science, Research and
Technology (BMBF) under grant 02 PV 710 25 and by the
German Research Society's Graduate College 'Computer Science
and Technology' at RWTH Aachen. The authors wish to thank
our colleagues Manfred Jeusfeld and Peter Szczurko for their
many fruitful comments and discussions. For the
implementation of the FOQUS prototype we thank our students
Marco Essmajor, Nico Hamacher, Gregor Lietz, and Axel Stolz.
References
[1] M. Amberg, "Modeling Adaptive Workflows in Distributed
Environments", 1 st Int. Conf. on Practical Aspects of Knowledge
Mangement, Basel, Switzerland, Oct., 1996.
[2] M. Amberg, "The Benefits of Business Process Modeling for
Specifying Workflow -oriented Application-systems", WfMC
Handbook, Workflow Management Coalition, 1997.
[3] F. Burger and R. Reich, "Usability of Groupware Products
for Supporting Publishing Workflows", G. Chroust, A. Benczur
(eds.), Proc. CON '94, Workflow Management: Challenges,
Paradigms and Products, (Linz, Austria), 1994, pp. 51-63.
[4] R. Daft and R. Lengel, "Organizational Information
Requirements, Media Richness and Structural Design",
Management Science, 32(5), 1986, pp. 554-571.
[5] R. Desatnik, "Long live the king", Quality Progress, 22(4),
1989, pp. 24-26.
[6] A. V. Feigenbaum, Total Quality Control, McGraw-Hill,
New York, 1991.
[7] H. Förster, P. Klonaris, T. Pfeifer, G. Warnecke, "Der
Regelkreis ist noch nicht geschlossen", Qualität und
Zuverlässigkeit, 41(10), 1996, pp. 1128-1132 (in German).
[8] V. Gruhn, "Business Process Modeling and Workflow
Management", International Journal of Cooperative Information
Systems, 4(2), 1995, pp. 145-164.
[9] M. Hammer, "Reengineering Work: Don’t Automate, [23] T. Pfeifer (ed.), Wissensbasierte Systeme in der
Obliterate", Harvard Business Review, (July/August) 1990, pp. Qualitätssicherung - Methoden zur Nutzung verteilten Wissens,
104-122. Springer-Verlag, Berlin, 1996 (in German).

[10] D. Harel, "STATECHARTS: A Visual Formalism for
Complex Systems", Science of Computer Programming 8, 1987,
pp. 231-274.
[11] M. Jarke, R. Gallersdörfer, M. Jeusfeld, M. Staudt, and S.
Eherer, "ConceptBase - a Deductive Object Base for Meta Data
Management", Journal of Intelligent Information Systems, 4(2),
1995, pp. 157-192.
[24] T. Pfeifer, (ed.), Fehlermanagement mit objekt-orientierten
Technologien in der qualitätsorientierten Produktion,
Forschungszentrum Karlsruhe Technik und Umweld, FZKA-
PFT 183, March 1997 (in German).
[25] K. Pohl, R. Klamma, K. Weidenhaupt, R. Dömges, P.
Haumer, and M. Jarke, "A Framework for Process-Integrated
Tools", Aachener Informatik -Berichte, 96-13, Aachen 1996.

[12] M. Jarke, M. Jeusfeld, P. Peters "Model-Driven Design and
Operation of Cooperative Information Systems", in
M.Papazoglou/ G.Schlageter (eds.): Advances in Cooperative
Information Systems , Academic Press, 1997, pp. 263-290.
[13] B. Karbe and N. Ramsperger, "Concepts and
Implementation of Migrating Office Processes", In W. Brauer
and D. Hernandez (eds.): Verteilte künstliche Intelligenz und
kooperatives Arbeiten, Springer-Verlag 1991, pp. 136-147.
[14] S.M. McMenamin and J.F. Palmer, Essential System
Analysis, Prentice-Hall, Englewood Cliffs, 1984.
[15] R. Medina-Mora, T. Winograd, R. Flores, C.F. Flores.
"The action workflow perspective to workflow management
technology", Proc. 4th CSCW Conf., Toronto 1992, pp. 281-288.
[26] T. Schäl. Workflow Management Systems for Process
Organizations. LNCS 1096 (Diss. RWTH Aachen 1995),
Springer-Verlag, 1996.
[27] A. I. Wasserman, "Tool Integration in Software
Engineering Environments", In F. Long (Ed.), Proceedings of
the Intl. Workshop on Software Engineering Environments,
Springer-Verlag, Berlin, Germany, 1990, pp. 137-149.
[28] H.-J. Warnecke, The Fractal Factory, Springer-Verlag,
Berlin, Germany, 1992 (in German).
[29] M. Wersch, Workflow Management - Systemgestützte
Steuerung von Geschäftsprozessen, Deutscher Universitäts
Verlag, Wiesbaden, Germany, 1995 (in German).

[16] S. Morschheuser, H. Raufer, and C. Wargitsch, "Challenges

and Solutions of Document and Workflow Management in a
Manufacturing Enterprise: A Case Study", Proc. of the 29th
Hawaii Intl. Conf. on System Sciences (HICSS-29), 1996, vol. V,
pp. 4-13.

[17] J. Mylopoulos, A. Borgida, M. Jarke, and M. Koubarakis,

"Telos - a Language for Representing Knowledge about
Information Systems", ACM Transactions on Information
Systems, 8(4), 1990, pp. 325-362.

[18] A. Oberweis, R. Schaetzle, W. Stucky, W. Weitz, and G.

Zimmermann, "INCOME/WF - A Petri Net Based Approach to
Workflow Management", In Krallmann, H. (ed.): Proc. of
Wirtschaftinformatik’97, Physica-Verlag, 1997, pp. 557-580.

[19] P. Peters and P. Szczurko, "Integrating Models of Quality

Management Methods by an Object-Oriented Repository", 2nd
Biennial European Joint Conf. on Engineering Systems Design
and Analysis, London 1994.

[20] P. Peters, U. Löb, and A. Rodriguez-Pardo, "Structuring

Information Flow in Quality Management", Proceedings. of the
Fourth Intl. Conference on Data and Knowledge Systems for
Manufacturing and Engineering, Hong Kong, 1994.

[21] P. Peters, Planning and Analysis of Information Flow in

Quality Management, Dissertation, RWTH Aachen, 1996.

[22] T. Pfeifer, Quality Management, Carl Hanser Verlag,

Muenchen, 1993 (in German).