Workflow Support for Failure Management in Federated Organizations

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 the contractual loop between customers and providers of
Failure management for complex products (such as services [15, 26]. Their main advantage is an explicit
production machinery) exemplifies a class of reactive modeling of the coordination relationships between agents
workflow management tasks for which current WFMS involved. Their main weakness is that they focus on
offer few solutions. This class is characterized by great coordination only and do not directly address the
variation of tasks and cooperation patterns, the need to knowledge context created and exchanged during
bring rich context knowledge to many different kinds of workflows. Like activity-oriented workflows, but in
workplaces, and the need to interlink effective workflow contrast to the document-oriented ones, they focus on
execution with continuous organizational learning. In the short-term aspects rather than on the long-term creation
German FOQUS project, we have prototyped and and management of organizational knowledge.
evaluated a WFMS architecture which addresses these In this paper, we investigate an extension to service-
problems through (a) the encapsulation of problem oriented workflows which could be briefly characterized
context in electronic circulation folders; (b) a semantic as highly flexible reactive workflow systems with
trading mechanism managing the flow of such folders in a embedded organizational learning support. The
highly flexible manner; (c) a concept for process- application domain we studied for such workflows is
integrated workplaces in which the necessary information failure management for complex technical products, such
is made effectively available in the usual working as those used in production machinery.
environment of the different kinds of users; (d) In section 2, we characterize this domain and its
metamodeling techniques to support change in this workflow management requirements based on
environment. experiences in an interdisciplinary project with
engineering design researchers and industry, the FOQUS
project. We then present an architecture that has been
1. Introduction developed and evaluated within the project (section 3).
The main ingredients of this architecture include: (a) the
Workflow models and workflow management systems use of electronic folders as a movable encapsulation
(WFMS) are determined by the kinds of tasks they are mechanism for task-related context knowledge; (b) a
intended to support. "semantic trading" mechanism which serves both as a
Early WFMS, e.g. FlowMark by IBM, CSE/ workflow engine and as a broker helping the acquisition
WorkFlow® by CSE, and WorkParty by SNI, pursue the of additional possibly necessary context and contact
activity-oriented aspect of workflow management [8, 29, information; and (c) a "bridge" component which enables
18] and are best suited to support long, standardized task an integration of heterogeneous workplaces into the
chains. They have been criticized because they tend to workflow process defined in the trader. All of these
neglect the flexible interaction between agents for components need an infrastructure of sharable and
exchanging complex structured (possibly multimedia) extensible background knowledge in order to function;
information. Two alternative views have emerged. this infrastructure is encoded in meta models described in
Document-oriented WFMS, e.g. DM/Workflow by section 4. Section 5 completes the paper with some
Intergraph or OPEN/workflow by Wang Laboratories, observations from the experimental application of this
Inc., concentrate on the management of complex technology in manufacturing organizations and outlines
structured information in a predefined homogeneous future work.
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 2. Failure Management as a Business Process
no defined information flows.
Service-oriented workflows, such as the Coordinator by In this section, we provide a characterization of failure
Action Technologies Inc., emphasize the need for closing 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 look for causes and to take corrective measures whose
of escalation" that we later use as a guideline for our success is reported back to the process owners. After
design. several assumptions and trials the cause is finally unveiled
: the failure was caused in product assembly planning,
2.1 The importance of failure management propagated to product assembly and not detected by
quality control because test routines were not applied
Global markets with informed customers cause new effectively. Two types of organizational learning can take
competitive pressure. Manufacturers face more and more place: the call center can be informed how to provide a
competitors whose products have comparable quick fix, and the product assembly can avoid the
characteristics. In particular, small and medium-sized problem in future product versions.
organizations with a narrow product range but high
market share can only evade into new markets if they 2.2 WFMS requirements for failure management
continuously improve quality and reduce time-to-market
as well as costs [28, 22]. From the information technology point of view, the
An effective way to reach both goals is to reduce faults example raises several challenges. Since the product life
or failures throughout the product life cycle. According to cycle is distributed in time and space, faults detected in a
[5], 90% of the customers unsatisfied with product quality late stage of the product life cycle phases are not
will avoid that product in the future. Every failure beyond necessarily produced there. Therefore, the process of
the acceptable limit of the market leader leads to sales failure management potentially involves all departments
reductions between 3 and 4%. Despite the TQM taking part in the product life cycle. -- but tasks must be
movement, the potential of this insight is still significant: escalated in a targeted, problem-driven manner, otherwise
surveys performed in the FOQUS project [7, 24] have information overload will be the result.
shown that 60% of the errors made in production lines are Inter- and intra-organizational barriers have to be
repeat errors, causing a loss of 10% of personnel and bridged by workflows and information flows:
machine usage capacity.
Fault-free production is an ideal often not achievable in 1. Informational barriers: For example, the
time and cost-constrained production lines. Thus, not only information available for the assembly planning agent
product quality but also service quality are important for is not available for the service engineer at the
customer satisfaction. Reaction time is the most customer site.
significant factor; our surveys pointed out that the typical 2. Conceptual (or knowledge) barriers: For example,
complaint processing duration is nine to ten days (80% of the knowledge about assembly processes for gear units
responding manufacturers) and that on average three is not available to the CAD engineer.
departments (ten departments) are affected by complaint 3. Technological barriers: For example, the service
processing. engineer has no access to the enterprise networks, thus
Only the combination of both requirements, i.e. no direct exchange of electronically stored data is
reduction of repeat faults in production and increase of possible.
service quality, will satisfy customers, thus strengthening
the ties between customers and enterprises. Both WFMS seem to provide a promising basis for tackling
requirements demand the design of reactive and the problems that result from the named barriers.
preventive management processes based on a quality loop However, most systems have been developed and
within the companies [22], improving capture and implemented based on the following assumptions:
exchange of knowledge about failures. Failure
management (FM) is the modeling, enacting and 1. The workflows established are quite stable and easy to
maintaining of reactive and preventive processes. It must maintain. WFMS work best if well-documented
be investigated in a holistic way, considering the business processes are established and can be
organizational, personnel and technical aspects. supported electronically.
An example will illustrate the complexity of the task. 2. A detailed and consistent business process model
When a complaint by a customer that his newly bought exists which is understood by all people involved in
gear unit loses oil is reported to the manufacturer's call the project. Some WFMS use reference models for
center, and the call center cannot give direct advice a special application domains which can be customized
service engineer drives to the customer. He detects the to individual enterprise needs.
fault (sealing rings are not assembled correctly) and must 3. The agents using the systems have comparable skills.
take measures to correct it (e.g. exchange of gear unit). Because of the overall business process model, WFMS
For preventing further failure occurrences, failure support is given to all agents by the same means.
handling is passed on to the departments which are 4. WFMS work together with existing applications and
responsible for the correction, due to his assumption about solutions in the application area.
the failure cause. Every department involved needs to

These assumptions cause several problems in a 4. The management and exchange of complex structured
distributed and flexible area like FM. information produced by legacy applications, e.g.
CAD drawings, NC programs, catalogs stored in
1. FM processes are not stable but change frequently. heterogeneous data sources, must be facilitated.
Experiences with WFMS show that they are difficult
to adapt to process changes, thus forcing “cow paths” 2.3 The principle of escalation
[9] to be established. Massive reengineering of
business models is still an open problem [2]. Agents processing failures follow a typical schema.
2. On a detailed workflow level FM processes are not After detecting the failure, they try to find a cause. If they
well-defined and process ownership belongs to the find one, and if it is possible to correct the failure ad hoc,
departments involved in the process. Therefore, they will do so. If agents are not able to find a cause or if
monolithic and complex business process models a local problem solution is not possible, they try to report
which must be understood by all agents do not make the case to another agent, who is skilled enough and
sense for FM. WFMS using them do not reflect the responsible. But perhaps reporting a failure is costly,
federated organization context of distributed or virtual displeasing, or there is no knowledge about
enterprises [1]. responsibilities.
3. Failure processes are often handled in an ad-hoc If a failure must be processed in different departments
manner and spread over several departments, where in order to analyze the problem and define a measure, two
agents with different skills do their day-to-day work problems occur. Either there is no allocation of
using different work environments. Therefore, task- responsibility causing delays in processing and reducing
and person-specific support by a WFMS is needed. the effects of failure elimination, or multiple defined
4. In a heterogeneous system, there is no integration at responsibilities cause mutual obstruction in processing.
all because of the variety of systems. WFMS used here In order to reduce the knowledge and responsibility
rely on simple concepts like task lists, email or PERT problems, FOQUS proposed the escalation principle for
charts. interdepartmental processes with the aim to
• enable a direct processing of failures,
Many studies about implementing workflow concepts • systematically detect spheres of competence, and
in enterprises address problem similar to those stated • give structured support in processing the failure
above [16, 3]. These problems raise certain requirements Escalation describes a mechanism enabling the
to be fulfilled by WFMS support for flexible, distributed processing of failures and the exchange of knowledge
FM processes: between spheres of competence. The elements of the
escalation principle are shown in Figure 1.
1. Flexible mechanisms for modeling, enacting and Spheres of competence describe workplaces or
maintaining workflows and information flows are departments in the distributed product life cycle, e.g. the
needed. New variants of products cause frequently hot-line workplace, the service department, and the
new types of failures. Thus new or changed workflows assembly planning department. These workplaces or
and information flows emerge in which existing departments perform processes and contribute to the
knowledge has to be applied. whole FM process.
2. Workflow management support is not only based on Micro processes describe actions to be performed in
organizational needs but also on the interaction and one sphere of competence. There are three steps,
communication needs of the involved agents. The structurally equal for every area but different in
simultaneous needs for exchanging data and bridging implementation depending on tasks and skills of agents:
existing culture, language, and system barriers create Sphere of
uncertainty and equivocality [4]. Thus, the possibility competence
Correct
to interact with each other to coordinate work and
exchange relevant information must be provided by a Capture
Sphere of
FM system. competence
Analyze

3. For users, tool support must be given on the right level Correct
of usage. Therefore, WFMS have to embed and enrich Sphere of Escalate
existing workplaces. This means the flexible competence Capture
Analyze
failure

integration of existing tools with the WFMS by
Correct
providing several levels of information and service
Escalate
exchange support. Furthermore, collaboration and Capture failure
information exchange tools, like ad hoc querying, Analyze

multimedia, and groupware tools, must be made
Failure
available [20, 24]. detection

up data and processes to extract models of processes,
Figure 1: Escalation principle information sources and their contents.

1. Capturing the failure: the process of gathering and On the conceptual level, internal integration means
documenting available data. documented models with open interfaces and uniform
2. Analyzing the failure: the process of interpreting failure data models. Data models gained from reverse
available information, i.e. determining possible causes engineering for external integration have been described
and defining applicable measures. If no final solution by interface definition for special purposes, e.g. automatic
is applicable or the agent presumes far-reaching gathering of CAQ data for multidimensional coordination
consequences, the failure can be escalated. measuring instruments, or by means of a comprehensive
3. Correcting the fai lure: the process of defining, product, process and machine model [23]. The context of
performing and tracing measures for failure treatment. a failure is helpful for both analyzing and classifying the
Success of measures is communicated to agents failure. Every failure context can be described by a triple
involved in the escalation. (product, process, machine). The coupling with the failure
data model has been reached by means of a data
Macro processes describe a directed graph of dictionary. Finally, processes and information have been
escalation steps. With every escalation step the failure is integrated in electronic circulation folders.
passed to one or more spheres of competence. The On a technical level, internal integration means
conditions for escalation are negotiated between the integration of tools at one workplace (sphere of
agents in the spheres. competence) and integration of workplaces in a
With these elements it is possible to describe micro distributed, interdepartmental environment. The core idea
processes of spheres and to assemble them in a flexible of external workplace integration is the introduction of a
manner. Differences in culture, language and systems can central instance, the Trader system, consisting of a
be encapsulated in the spheres and negotiation between repository with defined models [12] and three components
agents is driven by the escalation principle. Negotiation for folder, workflow, and query management in a
across spheres can be founded on well-defined criteria heterogeneous system world. Bridges make the traded
described in contracts, as in the language-action approach information available to the different kinds of individual
[26] workplaces in a customized manner.

3. The FOQUS WFMS 3.1 Electronic circulation folders

The escalation principle suggests two goals that need To integrate workflows and information flows, we
to be accomplished by a suitable architecture for failure employ the electronic circulation folder metaphor to carry
management: context around with a workflow.
The approach is described best as an object migration
1. Integration within the FM system (internal view on workflow management [16]. The core idea is,
integration): Methods, tools and knowledge have to that the document includes the work to do. Informational,
be integrated in micro and macro processes. The conceptual, and technical barriers are bridged by the
strategy here is to integrate top-down based on management of folders and their linkage to the Trader
cooperative modeling of processes and data. Tools system. All the information needed for processing a
have to be integrated in spheres of competence, and failure is stored in folders or linked to them. Folders
spheres of competence have to be integrated to realize capture all the information gathered in the process, thus
distributed FM processes. creating temporary knowledge bases available to all
2. Integration into the heterogeneous organizational agents processing failures. Folders are further given direct
environment (external integration): Existing access to information sources in the enterprise and to tools
manufacturing and service processes, information specific to the workplaces. Also, negotiation protocols for
sources, and legacy applications have to be defined workflows as well as mechanisms for ad hoc
considered. The strategy here is to reengineer bottom- 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 The overall architecture of the FM system is given in
transfer. If no responsible agent is defined for an Figure 3.
escalation step there is a predefined agent, the The Trader system in the middle of the figure is
process owner, who is responsible for the folder connected via a network or serial lines to enterprise data
by default. This agent will then be contacted by sources and workplaces. The Trader system consists of a
the system. The process owner then decides if central repository, a query manager, a workflow
there will be an ad hoc escalation or if the engine, a folder manager, and interfaces to external and
treatment of the failure is stopped, e.g. for internal sources.
economical reasons. The Trader repository consists of four components for
• Establish contact between spheres (either direct the management integration tasks:
or e.g. by email). Heterogeneous information sources

• Enable negotiation process after direct contact. Network

For every pair of spheres individual negotiation
protocols can be defined. Federated query interface
externe Kommunikation

• Transfer the folder after successful negotiation, Query
manager
External
contact the process owner otherwise. Before the integration Workflow
transfer, temporal links have to be substituted Internal engine
and new versions of the folder are created for the integration Trader
Folder
database
spheres accepting the folder, constituting a manager
DB-Kommunikation
database communication interface
directed graph. The folder life cycle can be
Folder management Workflow management
traced with this graph. with work places with work places
• Gather the receipts of transfer from both Network
spheres. Work places

2. Folder trace. Every person using the FM system can Figure 3: Integrated Trader architecture
monitor the escalation graphs. The grade of
monitoring is defined by the temporary role of the 1. In the external knowledge component the federated
persons. schemata, functions for querying the federated
• Every person involved in the process can query databases, and triggers are stored. The folder
the progress of escalation from the history manager uses this knowledge for the segments
segment (the folder graph). Feedback is given "project management” and "workplace documents”.
automatically to every person involved if the The query manager uses the knowledge for
folder is closed. answering predefined or ad hoc queries built with
• The process owner can monitor folders and stop special tools [20]. The workflow engine uses defined
escalation from the segment project triggers for initiating database actions.
management any time. 2. At the core of the internal knowledge component lies
the uniform failure data model and the escalation
If the user is requesting information not contained in models for enacting and tracing measures. The failure
the folder but in external data sources, the FM system data model allows queries on distant failure databases.
mediates those data to the user (2). Because the FM The folder manager uses the information for the
system treats external data sources and workplaces the segments "project management", "failure data", and
same way, users can also query other wo rkplaces thus "history". The query manager uses knowledge for
supporting communication in failure processing. routing queries to workplaces. The workflow engine
uses the escalation models for handing down folders.
3.3 Folder circulation via traders 3. The third component consists of agent and tool
models. The agent model defines spheres of
Despite the decentralized development process, the FM competence and the tool model contains knowledge
system currently manage the acquired information under about available tools. The folder manager uses that
central control to avoid inconsistencies and to provide an knowledge for the segments "agents" and "tools". The
appropriate version control of folders during their life workflow engine gets the information which person is
cycle. These requirements led to an integration approach linked to an agent on a certain workplace.
that uses a repository as a tool that provides sharing and 4. The component communication knowledge consists of
integration of knowledge and the ability to maintain the negotiation protocols. Possible communication and
consistency of objects, relations and their meanings in the negotiation patterns between workplaces as well as
organizational context. The repository is responsible for protocols for querying external data sources are
the management and exchange of complex structured specified by statecharts [10]. The query manager
information. uses the protocols for automatic interaction with

databases. The workflow engine uses the knowledge existed at customer sites. So only tool wrapping
for enacting negotiation processes. mechanisms (black box integration) as well as simple
data, control and representation mechanisms were used:
3.4 Workplace integration via bridges • Representation integration was achieved by a common
style guide and commercially available user interface
A tool called Bridge is responsible for accepting and classes.
handing down folders as well as for tool integration tasks. • Data integration was achieved by the folder approach
A Bridge has a local database for storing folders and and the uniform failure data model. Common libraries
tool data. The Bridge can read and write on every segment for accessing the local database at the workplace have
of the folders stored in the local database For the Trader been developed.
system the workplaces are federated information systems, • Control integration, defined as offering and accepting
too. All Trader tools can access workplaces via defined services, consists of a task exchange mechanisms
interfaces and communication protocols. The Bridge based on statecharts.
(Figure 4) is communicating with the Trader system via
the database communication interface. On the micro process level, tools have to be integrated
into the heterogeneous organizational environment. Thus,
Acceptance and hand down of folders they access every data resource defined in the Trader
system by using the mechanisms implemented in the
database communication interface
folder segments. For example, predefined queries [12] are
Folder Tool Task
management management Management linked to the segment "workplace documents". The query
User interface
is sent to the query manager and transformed into SQL
Tool control tool feedback
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
Werkzeug
the workflow engine. By assembling the partial answers
Werkzeug
Werkzeug
Folder data exchange Tool task exchange the query manager constructs the answer table and the
Werkzeugschnittstellen
Tool interfaces workflow engine replicates that table to the local
database at the workplace. For example, queries deal with
budgets, schedules, deadlines and actual workflow
Figure 4: Integrated workplace (Bridge) progress information for a folder workflow.
The three main tasks of the Bridge are reflected in the
architecture:
4. Formal Models in the Trader Repository
• Local folder management: For accepting and
handing down folders, primary and secondary copies The WFMS architecture described in the previous
and folder query handling. If a user is logged into his section relies on shared representations of knowledge
workplace, all folder transfer requests will directly be encoded in meta models which offer languages to
notified by a requester, otherwise he will be notified describe workflows and information flows under a
asynchronously, e.g. by email. Every folder can be common conceptualization. In this section, we describe
negotiated on with the requesting Bridge by the main modeling concepts used to organize the
negotiation protocols defined for folders and work information in the trader repository.
places. The core of the formal language (Figure 5) is derived
from the process model proposed by McMenamin and
• Local task management: For every folder transferred
to the workplace, a new task is created. The tasks can Palmer [14]. An input (object) is consumed and
manipulated by a system and an output is produced. The
be refined locally, e.g. by additional control data in the
segment "project management", negotiation results, system itself consists of processes, describing a workflow,
processed by an agent using tools.
and personal preferences.
The formal model, defined in the knowledge
• Local tool management : Tools built with libraries
representation language Telos [17], has three purposes.
developed for tool integration, can exchange data and
(1) Defining the flow of FM processes. (2) Defining the
task information with the Bridge. Proprietary tools can
interfaces for intra- and interdepartmental coordination
be started and stopped from the Bridge.
and communication. (3) Providing the basis for
implementing or reusing tools in every step of the micro
Tool integration [27] has concentrated on data, control
processes as well as for WFMS specification of macro
and integration dimension. Tighter integration with the
processes. These goals can be mapped on two areas;
process can be reached by more sophisticated construction
workflow modeling and information modeling.
of process-integrated workplaces [25]. Tools for micro
process support were developed by our partners or already

contains
contains The elements of the language model are linked by
uses attributes. Thus, the link between spheres of competence
Agent Tool can be defined by the objects exchanged, providing a
defined interface for task relevant information exchange.
processes supports The problem of responsibility is solved through linkage of
contains agents with processes. Based on this specification, intra-
produces contains
and interdepartmental workflows and information access
Object Process can be supported by a WFMS. The workflows in one
consumes sphere can be described at a sufficient level of abstraction
isA to serve as basis for the specification of tools linked to
agents and processes.
Activity contains
produces contains

Figure 5: Workflow modeling concepts Object Process
consumes
described by

Workflow modeling means the modeling of FM stored
Content represents
processes but also the interaction with other processes in
the organizational context.
Describing the processes assists Media allows Presentation
• a company-wide understanding of certain concepts
and workflows, needed for coupling systems Figure 6: Information modeling concepts
• defined interfaces between spheres of competence
• identification of agents and exchangeable information Information modeling (Figure 6) is the modeling of
in every step the information needed at the interfaces in micro cycles
In short, the concepts and their relations are as follows: and macro processes. Describing the information flows
assures
1. The concepts process/activity describe workflows • the avoidance of media breaks and information holes
(e.g. capture, analysis and correction of failures) in and between spheres
performed by agents. Processes can be refined by the • a common data specification at system level
contains attribute. Refined processes are coupled by • the support of information exchange in a
objects. They can branch (produced objects are used heterogeneous system world
by different processes) and unite (produced object are • the availability of a complete and as far as needed
used by one process). The concept activity is a uniform description of information
specialization of the concept process describing
atomic processes. Agents can perform these steps The concepts added are described as follows:
autonomously as long as the modeled objects are 1. Content is a description of the information /object
produced. structure. Especially objects structured by contains
2. The concept agent describes humans performing a attributes (e.g. parts lists) need an overview of the
process. The concept agent can consist of a team of contained information.
agents, e.g. the quality control team. 2. Media describes the form in which an object is saved.
3. Tools are technologies supporting the agents Non-computerized forms of information management
performing their tasks. There is a clear distinction can cause special activities like scanning or
between tools and additional resources. Tools can be transforming data.
structured by a contains attribute. 3. Presentation can (but need not) depend on the media.
4. Objects are artifacts consumed, manipulated or In particular, computerized forms of information
produced in FM processes. Objects can be management allow different presentations with
decomposed by a contains attribute. available front ends. The usage of presentations
depends on the consuming process of that object.
The additional concepts event, action, and condition
are not shown in Figure 5. External events like a Modeling is needed for common understanding and
telephone call at a hot-line can start FM processes. FM defining interfaces for real information and work
processes can also start actions outside the system. Pre- exchange between agents. The granularity of modeling
and post conditions are used for situations in which the the spheres themselves is left to local departments. Even
existence of objects is not sufficient for deciding whether other approaches are possible as long as the modeled
a process should be performed or not. information is produced. Therefore, our approach avoids
monolithic process models. Communication and

interaction needs are based on well-defined interfaces. so far little support is given by software companies.
Changes on micro process level are handled within the Therefore, our approach was regarded with great interest
departments. Changes or inventions on macro process at the workshops performed in the project. Most of the
level are negotiated between the spheres. system architecture has been implemented and shown in
The process of modeling was performed in a an integrated demonstration at the final project review.
cooperative manner. Like in the predecessor project The many constructive comments and suggestions made
WibQus [19, 23], the object base management system by the participants will be included in further
ConceptBase [11] was used as conceptual modeling tool specification and implementation tasks. In the context of
and for storage of the repository. Two case studies were FOQUS, the special problems of variant rich and
performed with industrial partners. The partner engineers innovative productions which were not discussed in the
trained in using the language worked as mediators with paper have also been tackled. Our deliberations have
the company people. Every department described their shown that available WFMS generally are not suitable for
local processes and objects autonomously. The coupling this problem context. Thus, more sophisticated methods
of wo rkflows and information flows was reached by of information and workflow management are necessary
bilateral negotiation processes. The constructed models for the continuous maintenance of knowledge in variant-
served as vocabulary with project wide validity and as a rich and innovative product or service life cycles.
starting point for system, interface, and tool specification.
To guarantee a uniform data model for FM tools, the Acknowledgements: This work was supported by the
project partners in FOQUS developed a common failure German Federal Ministry of Education, Science, Research and
data model on the basis of identified objects to be Technology (BMBF) under grant 02 PV 710 25 and by the
exchanged between spheres. Four main modeling areas German Research Society's Graduate College 'Computer Science
and Technology' at RWTH Aachen. The authors wish to thank
for FM have been identified: Failure description our colleagues Manfred Jeusfeld and Peter Szczurko for their
(attributes of capturing failures), failure context many fruitful comments and discussions. For the
(products, processes, and machines, typically transferred implementation of the FOQUS prototype we thank our students
from organizational data sources), failure analysis Marco Essmajor, Nico Hamacher, Gregor Lietz, and Axel Stolz.
(symptoms, reasons, and measures), and failure
classification. References
With the models created in the cooperative process a
first step to a flexible and distributed FM system is [1] M. Amberg, "Modeling Adaptive Workflows in Distributed
reached. Environments", 1 st Int. Conf. on Practical Aspects of Knowledge
Mangement, Basel, Switzerland, Oct., 1996.
5. Summary and Outlook
[2] M. Amberg, "The Benefits of Business Process Modeling for
Specifying Workflow -oriented Application-systems", WfMC
In this paper we have introduced fundamental concepts Handbook, Workflow Management Coalition, 1997.
and technologies to support the workflows and [3] F. Burger and R. Reich, "Usability of Groupware Products
information flows for flexible, distributed FM in a for Supporting Publishing Workflows", G. Chroust, A. Benczur
federated organizational context, namely (eds.), Proc. CON '94, Workflow Management: Challenges,
• the escalation principle, to preliminarily structure the Paradigms and Products, (Linz, Austria), 1994, pp. 51-63.
distributed FM processes by systematically identifying
spheres of competence and assembling them in a [4] R. Daft and R. Lengel, "Organizational Information
flexible manner, Requirements, Media Richness and Structural Design",
Management Science, 32(5), 1986, pp. 554-571.
• the modeling language for FM processes which
enables a sufficient degree of common understanding [5] R. Desatnik, "Long live the king", Quality Progress, 22(4),
of workflows and information flows in distributed FM 1989, pp. 24-26.
processes
• defined interfaces at system level and support for [6] A. V. Feigenbaum, Total Quality Control, McGraw-Hill,
system and tool development, New York, 1991.
• the electronic circulation folder approach to integrate
[7] H. Förster, P. Klonaris, T. Pfeifer, G. Warnecke, "Der
workflows and information flows, Regelkreis ist noch nicht geschlossen", Qualität und
• the workflow management concepts based on the Zuverlässigkeit, 41(10), 1996, pp. 1128-1132 (in German).
defined models and folder approach, and
• the system architecture to support distributed FM [8] V. Gruhn, "Business Process Modeling and Workflow
processes in organizations which depend on federated Management", International Journal of Cooperative Information
information systems. Systems, 4(2), 1995, pp. 145-164.

Most of the more than 350 enterprises surveyed in
FOQUS are planning for FM systems in this decade, but

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

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

[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).

Workflow Support for Failure Management in Federated Organizations

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Workflow Support for Failure Management in Federated Organizations

Ähnlich wie Workflow Support for Failure Management in Federated Organizations (20)

Mehr von Ralf Klamma

Mehr von Ralf Klamma (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Workflow Support for Failure Management in Federated Organizations