Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Workflow Support for Failure Management in Federated Organizations

                                   Ralf Klamma, Peter ...
successful WFMS and introduce the so-called "principle          look for causes and to take corrective measures whose
of e...
These assumptions cause several problems in a              4. The management and exchange of complex structured
up data and processes to extract models of processes,
   Figure 1: Escalation principle                                inf...
A folder is created every time a failure is detected. All        The segment history contains link chains concerning
• Find defined sphere of competence for the                The overall architecture of the FM system is given in
databases. The workflow engine uses the knowledge                                     existed at customer sites. So only t...
                                                  contains          The elements of the language model are linked...
interaction needs are based on well-defined interfaces.         so far little support is given by software companies.
[9] M. Hammer, "Reengineering Work: Don’t Automate,               [23] T. Pfeifer (ed.), Wissensbasierte Systeme in der
Upcoming SlideShare
Loading in …5

Workflow Support for Failure Management in Federated Organizations


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Workflow Support for Failure Management in Federated Organizations

  1. 1. Workflow Support for Failure Management in Federated Organizations Ralf Klamma, Peter Peters, Matthias Jarke Informatik V (Information Systems), RWTH Aachen email: {klamma|peters|jarke} 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
  2. 2. 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
  3. 3. 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
  4. 4. 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.
  5. 5. 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:
  6. 6. • 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
  7. 7. 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 Werkzeugschnittstellen 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
  8. 8. 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
  9. 9. 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
  10. 10. [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).