next up previous

WorkBrain: Merging Organizational Memory and Workflow Management Systems

Christoph Wargitsch
Bavarian Research Center for Knowledge-Based Systems (FORWISS)
Am Weichselgarten 7, D-91058 Erlangen-Tennenlohe

Thorsten Wewers, Felix Theisinger
University of Erlangen-Nuremberg
Computer Science Research Group B
Martensstr. 3, D-91058 Erlangen

Abstract. Despite the enthusiasm, the workflow management idea faces currently, some problems occur when setting up large workflow applications for complex business processes. To solve some of these problems, a combination of workflow management concepts and the notion of "organizational memory information systems" is suggested. The basic idea is to create an evolutionary workflow management system using an organizational memory storage component consisting of a workflow case base to save the workflow lessons learned and a storage for the general domain knowledge of an enterprise. The concept and a prototypical implementation of the system are presented. The example workflow we use to illustrate the system functions is the inquiry/proposal process of a roller bearing manufacturer.


Organizational Memory Information Systems (OMIS) can be seen as a tool to support the management of knowledge in an enterprise. One of the distinct characteristics of an OMIS is to support a temporal integration of the knowledge an enterprise generates [StZw95]. Workflow Management Systems (WMS) are an instrument to support the execution of business processes. They provide the possibility to save knowledge along the time axis since workflows have an intrinsic time-logic structure and furthermore mirror the present business context of a certain period of time. Therefore, it seems to be a promising approach to connect the concepts of Organizational Memory (OM) and Workflow Management and merge their technical implementations - the OMIS and the WMS.

Since business environments are obviously dynamic systems, OMIS and WMS must be flexible enough for allowing frequent changes. They have to be able to evolve and improve with time. In this paper, we introduce an approach for an evolutionary OM-based WMS. It is supposed to help enterprises to get error-free, effective and efficient, IT (information technology)-enabled business processes. Key elements of the WMS are a process-oriented OM storage layer and OMIS functions which have the purpose to retain know-how that is generated permanently while running the WMS and ensures progress along a process learning curve. The OM is kept almost automatically updated since it is permanently fed with information from currently performed business processes. The tasks of the OM-based WMS are divided into three parts: increasing mastery of a company's workflows, continuous improvement of the workflow quality, and retention of professional knowledge. These tasks are interdependent. The stepwise mastery of workflows, for example, contributes to an efficiency improvement. In turn, the weakness analysis in the course of the continuous improvement process could lead to a reduction of workflow variety - simpler workflow structures result. The retention of professional and organizational knowledge is the foundation to accomplish the other tasks since it saves "the lessons learned" and ensures proceeding on the learning curve.

Workflow Management

The Workflow Management Coalition (WfMC), an international association of WMS producers, consultants and WMS users, defines workflow management as: "The management of processes through the execution of software whose order of execution is controlled by a computerized representation of the process" [WfMC94].

The life cycle of a workflow can be divided in different phases that usually are summarized into two blocks [MoRW96]: The workflow design phase, also called build time, and the workflow execution phase (run time). The build time contains business process analysis, business process modeling, and workflow modeling. The run time consists of workflow planning, workflow start, workflow execution and control, and workflow archiving. WMS are considered to be one of the most expanding software markets. Analysts predict an annual 47 percent growth rate for the North American and European market until 1998 [NN95]. Especially in Germany the market is booming, particularly for document-oriented systems [Yaki96]. Though the enthusiasm in IT divisions of enterprises is given, workflow management faces currently some problems in "business reality":

Workflow Modeling Problems and Complexity. Many workflow management projects revealed that it is difficult to obtain a detailed picture of the real processes including all procedures, official and implicit rules [Herr95; Iten96; MüSc96; p. 7; Scot94]. Workflow users often state they do not recognize "their" workflow although they got involved in the modeling process by interviews. Different interpretation of terms and gaps between real acting and the information about acting are some of the reasons why organizational analyses only provide an incomplete picture of things [Gapp93]. Additionally, and according to this, business processes are often more complex than assumed [Jost96].

Lack of Flexibility. When managing business processes with the help of WMS the danger to freeze them is acute [AuBo96, p. 9]. The high costs to implement a WMS additionally hampers necessary changes. Complementary to the long-term flexibility, it is important to be able to react properly to exceptions and disturbances within a single business case. Only very few commercial systems are able to do so [Schn96]. Inflexibility and clumsiness often result from the fact that workflows are not designed modularly but consist of large, cumbersome units.

Loss of Know-how. For technology-based companies the retention and quick dissemination of know-how increasingly is an important production factor and critical success factor. However, it turned out to be problematic to collect knowledge, store it appropriately, and retrieve it to solve actual problems within workflows. Additionally, changes of all kind, especially the breaking up of grown organizational structures and the reduction of management levels in the course of business process reengineering measures may cause a loss of know-how. Retrograde steps on the learning curve result. Particularly the middle management turned out to be a key player: technical and organizational knowledge is often highly concentrated here [Fais96, p. 5].

A combination of WMS and OMIS ideas and the creation of an evolutionary, OM-based WMS should help to remedy at least some of these problems.

Organizational Learning and Organizational Memory

Learning organizations are characterized by actively supporting learning processes of their members and continuous self-development [Pedl89]. The objective of the learning organization is to recognize and perform necessary change processes itself. Certainly, this institutionalized learning and adaptation culture assumes a "learning culture" which fosters innovations and creativity [BuSc96].


"Learning organizations ... purposefully ... enhance organizational learning" [Dodg93]. "Organizational Learning (OL)" means the learning of an organization that leads to performance improvements. OL refers to gaining know-how as well as to "lessons learned" in its negative and positive sense. Klimecki states that "problem solving networks" that are aligned crosswise to hierarchies and divisions are the most important carriers of organizational learning processes. We will show that the semantics of workflows could be taken for such networks.

Argyris and Schon define OL briefly as "the detection and correction of errors" [ArSc78]. Basically, they distinguish two types of OL: "single-loop learning" and "double-loop learning". Single-loop learning is reactive and means an organization is able to fix errors. Double-loop learning exceeds this by the ability to question procedures, rules, norms, and strategies. Paper and Johnson as well as Nevis et al. emphasize that OL includes personal learning of single members of an organization but goes beyond it [NeDG95; PaJo96]. Therefore, OL is more than the sum of individual learning results [Bala97; Dodg93]. Nevertheless the question arises where learning organizations actually retain their knowledge. " ... for organizational learning occur, learning agents' discoveries, inventions, and evaluations must be embedded in organizational me- mory" [ArSc78].


The term "Organizational Memory" is not coherently used in the literature ("there are as many perspectives on OM as authors") [Acke96]. Argyris and Schon take OM merely as a metaphor that is an aid to explain the behavior of organizations ("organizations do not literally remember"), whereas Sandelands and Stablein grant organizations cognitive capacities and consequently take OM for independent [WaUn91]. One of the most cited definition was made by Walsh and Ungson: " ... organizational memory refers to stored information from an organization's history that can be brought to bear on present decisions" [WaUn91]. This basic definition is extended by Stein: OM lead to a higher effectiveness of an organization, under some circumstances also to a lower one [Stei95].


Whereas OM is a conceptual term, OMIS try to support this concept with information technology. It is difficult to mark off OMIS from conventional information retrieval systems, databases, and general resources like organizational handbooks [AkSt96]. The ambition to create with OMIS shared knowledge spaces that span the entire knowledge of an organization is not realistic [ScBa92]. The main problem is to interpret the stored data correctly if the knowledge domain is large. Instead, tools that support an "OM in the small" have turned out to be useful in order to perform certain tasks in an organization more effectively [AcMa95].

Basic Concepts

Framework: Double-loop Learning with a WMS

Fig. 1: Double-loop learning with an evolutionary WMS

WMS are usually introduced in a company in the course of a reorganization project. They are often the most important information system to put organizational innovation into action. Among others, the main task of the suggested evolutionary WMS is to serve as an instrument for supporting the redesign of business processes. Reorganization can be divided into two basic forms: a radical reengineering (revolutionary) [Dave93; HaCh93] and a continuous improvement process (CIP, evolutionary) [Harr91; Imai94]. In order to support the evolutionary reorganization approaches, a WMS must be able to grow and mature rather than to be a self-learning system.

The double-loop learning approach of Argyris and Schon [ArSc78] is taken to be the basic concept of the evolutionary overall system "WMS + organization". The WMS is an instrument for a learning process within the domain "design, configuration, and execution of business processes". Two learning cycles can be elaborated (see figure 1): an inner learning cycle where a learning by doing is performed, and an outer learning cycle which implies reflexive, observed learning - learning by supervision. Both cycles are supported by WMS functionalities. Core element is an OM storage layer with two categories of contents: In the first place, it contains historical workflows that are stored with their audit data in form of cases, secondly domain-specific knowledge about the organization, products, and technologies, e.g. an organization database that contains the organizational structure, target measures, business rules, responsibilities etc.

Primary goal of the inner learning cycle is to increasingly master the planning and execution of workflows. This works as follows: Upon their introduction, workflows are not modeled completely and in detail. Merely the rough structure and workflow building blocks are pre-designed. For each business case within this rough structure the workflow model is configured out of these building blocks and can be modified during execution (see also sections 4.2 and 6.4). This way we obtain workflows that are stored in a case base after their execution and serve as templates for new business cases.

By learning by supervision, the outer learning cycle ensures a continuous improvement of workflow planning and execution and contributes to an improvement of the basic conditions. Prerequisite is to recognize weaknesses and deficiencies. When they are identified, personnel that is responsible for the workflows or the participating employees themselves can correct the system e.g. by changing target values, business rules, and the activity network. This guarantees a closed control cycle. Additionally, the outer cycle has the function to reach strategic goals with the help of the WMS. The major part of this paper refers to the inner cycle.

Workflow Building Blocks and Case-oriented Workflow Configuration

For complex workflow-enabled business processes the authors introduce a new approach that substitutes the conventional workflow phase model that strictly distinguishes between build and run time [MoRW96]. Complex, partly-structured workflows can barely be mapped to a few basic workflow models. On the other side, it is unrealistic to supply a complete workflow model for each special case. Firstly, not each exception can be modeled a priori, secondly, a huge number of variants would result. Therefore, there exists a notable gap between the WMS requirements "easy handling" and "standardization" on the one hand and the need to adequately map the complex business reality on the other hand. A solution for this type of problem is a modularization. We do not think of a componentware approach and take the WMS software to pieces rather than modularize the workflows itself.

For this, workflows are dismantled horizontally and vertically. Since also users themselves should modify workflows, it is necessary to use a plain meta model. Theoretical terms like frames, patterns, class hierarchies etc. appear deterrent and should not be presented to the user. A pragmatic, clear structure helps to divide workflows into "comprehensive chunks".

Fig. 3: FLEXWARE model

Fig. 2: Case-oriented workflow configuration of workflow building blocks

The following structure is suggested (see figure 3): Workflows consist of building blocks of various granularity. At the top level, workflows are divided into workflow phases. Each phase contains a sub-workflow, consisting of a network of activities. The term "phase" indicates that workflow phases should mainly be structured as a sequence. At the finest level, activities consist of elementary actions. For each type of building block there is a catalog, the items of the catalogs are either instances of building blocks used in historical workflows or generic templates. The various building blocks have to be configured suitably for each business case (see figure 4). The case-oriented workflow configuration reduces the complexity of workflow models drastically compared to closed workflow type models. The concept of case-oriented workflow configuration is supported by a prototypical workflow engine we implemented, "FLEXWARE" [WaWe97]. The basic idea for the engine was to strictly separate the "bare workflow engine" and the workflow specification data. The configuration is supported by special search and retrieval functions and a case-based reasoning component.

The suggested approach results in a modified workflow phase model that differs from the conventional one described in section 2. Business process analysis and business process modeling in their existing forms are substituted by a single analysis and modeling of the rough workflow structure and the necessary workflow building blocks. The exact design of a workflow is created when it is started - exactly specified according to the requirements of the current business case. At this point of time it can be tailored to the requirements of the current business case. Thus, the life cycle phases "workflow specification" and "workflow planning" merge to the phase "workflow configuration". The conventional separation of workflow type and single workflow instance fades away. For this reason, a modification cycle is shortened drastically and is executed at the implementation level, not at an abstract business model level. Furthermore problems, typically occurring when transforming business process models into workflow models, vanish. Nevertheless it is not possible to drop the analysis and modeling entirely, since at least "germs" for the maturing of workflows have to be present. Starting point are workflow building blocks which are held in libraries and which can be configured freely (see figure 2). Currently, we are performing case studies with customers of our industry partner COI in order to set up "starting catalogs" which reflect typical building blocks for certain types of processes and industries.

The concepts of workflow modularization and case-oriented workflow configuration are important prerequisites for an OM-based WMS that is flexible enough to cope with the problems mentioned in section 2.

OMIS Functions to Support Workflow Management Tasks

To effectively support the tasks of an evolutionary workflow management with OMIS functions it is necessary to design the structure and contents of the OM storage layer in a process-oriented way.

One aspect of process orientation is to support forward and backward coupling of know-how, i.e. to transport know-how along a workflow in and against the flow direction [Stei93, p. 32]. Intelligent information systems that enable BPR have to support a "reallocation of knowledge" in most early business process stages [Hart96]. For the INA inquiry/proposal process - which we will present in section 6.1 - this means e.g. that an engineer (design phase) might have information from the scheduling department (cost estimation phase) about how to design a bearing in order to produce it economically.

In turn, know-how can be transported in forward direction with a workflow, e.g. it could be beneficial to send hints about technical problems along with the business case folder although it might not contribute to a workflow output directly but perhaps has an influence on the product quality. We implemented a couple of functions to support the forward and backward coupling of know-how (see section 6.4)

Besides these special know-how-coupling functions, there have to be a lot more OMIS functions which foster the processing of workflow knowledge and, in turn, assist the workflow management itself.

Fig. 4: OMIS functions for workflow management tasks

The tasks of workflow management can be divided into two groups:

1. Professional tasks related to single activities of a workflow

2. Workflow configuration and control tasks

Both categories have to be assigned to OMIS functions. In figure 4 possibilities to support workflow management tasks with OMIS functions are shown. We implemented most of these functions prototypically (for a description of some of these see section 6). Functions where users have to fill in information actively in order to obtain a rich and up-to-date OM are critical. At consulting companies like McKinsey & Company [Kiel93; Pete92] and the audit firm Arthur Andersen & Company [Quin92], incentive systems have been implemented in order to encourage the employees to contribute to the OMIS' success. A second possibility to overcome this obstacle is to integrate functions which provide information and functions which require the user's input.


Technical Architecture

The basic system we use is the document and workflow management system BusinessFlow 3.3 of our industry partner COI GmbH. It is coded in a C++-like language: OEL (Object-oriented Extensible Language), a proprietary language designed by COI [COI96]. We made two severe modifications of the system's architecture: First of all, we exchanged the workflow engine FLOWARE against FLEXWARE. It is based on graphical description files and a database-oriented control mechanism. Secondly, we implemented a web-based user front-end, called WAX (Web-AXessed Workflow Management). For the latter we added a special HTTP server to the existing server architecture, also implemented in OEL. The server is tightly coupled with the DMS/WMS functions and is able to use the whole functionality of the basic system and FLEXWARE. Its functioning can be described like this: Each URL request to the server is transformed into a method call of the DMS/WMS. The system outputs the desired information - folders, documents, workflow status reports etc. - which the server transforms to HTML code, sometimes enriched with Java applets, and returns it to the browser. Therefore, the major part of the original client functionality of BusinessFlow and all of the OMIS functions could be mapped to a WWW browser. Each WMS user receives a start URL leading him to the login page. According to his permissions, e.g. the right to change workflow models, specific functionality is offered to him.

For displaying certain graphical information like activity networks and business charts we implemented Java applets. These and other graphics are provided by a second server, the freeware HTTP server Apache.

Logical Architecture

In principle, our system consists of three logical layers: the storage layer, the service layer, and the user interface. Each component within the layers is described in the following sections. The architecture is quite similar to most of the client/server-type information systems.

Storage Layer

The storage layer includes several databases and file systems which can be clustered into three categories. The workflow storage contains a workflow case base where completed workflows are stored. Each case consists of extended feature vectors which are used for a similarity search of workflows, stories and remarks about the workflow. Additionally links to a description file that contains the graphical representation of the workflow and its process logic is provided. Furthermore, audit data like cycle times, processing times, and costs which are logged are part of the workflow memory. Beyond this episodic knowledge, the workflow memory holds the building block catalogs (workflows, sub-workflows, activities, checklists, application system calls) and a "general knowledge database" where the product groups of INA, the different kinds of engineering applications, the market areas, and the responsibilities are stored. A rule base is used to decide for what combination of these attributes of a business case which organizational unit should perform which activity within workflows. The organizational storage mainly holds the organization database (roles, rights, units, and positions) and a bunch of "organizational documents" like ISO 9000 handbooks. The technical storage consists of databases that belong to KODAS (a mechanical design database), MEDIAS (an electronic product catalog), and TADDY (Technical Application Documentation and Description System) as well as all kinds of technical documents like drawings, norms, and calculation sheets that are stored in the DMS.

Service layer

The service layer components are either directly related to storage layer components like KODAS and MEDIAS or serve for different storage elements like the HTTP server. Some types of application systems are clearly INA-specific or at least typical for an engineering environment. The service layer can be divided into three basic sections: The control/basic services, the information services, and the communication services. Document server, update server, the database server, the short message, and electronic mail mechanism are components which are part of BusinessFlow. KODAS and MEDIAS are systems we integrated into our prototype. All the other components have been implemented in our project and added to the prototype. ExperienceFlow is a case-based reasoning (CBR) application that is used for workflow planning. TADDY is a know-how database for engineering solutions. Each TADDY document folder contains problem descriptions, problem solutions, and the related drawings. The discussion forum WIBIS (Workflow Issue-based Information System) serves as a communication platform to discuss technical and organizational problems.

The user interface is explained in the next section with the help of an example workflow.

Usage of WorkBrain in the INA-Inquiry/Proposal Process

The OMIS user interface components are part of WAX. With WAX we made almost all "regular" workflow client functions available in a WWW browser. We are able to: model and configure workflows, monitor workflows, provide to-do lists, show workflow document folders, edit and upload documents, and offer application systems that should be used for certain activities.

It seems to be natural to use a WWW browser as the user interface for all OMIS functions, too. It integrates all kinds of application systems inside and outside a company homogeneously, elegantly, and at little costs. This closeness and homogeneity of information and the possibility to connect informational chunks to stories enforce the imagination of the user to navigate through a unified knowledge space. Some authors speak of the WWW as global brain [MaBa94]. It is transparent for the user where the information comes from.

Our system has - of course - a smaller focus. However, since the multiple relationships and links between all the information categories resemble kind of a system of neurons and synapses we called the OMIS part of our prototype "WorkBrain". We tried to visualize the information network in form of a "knowledge map" which is clickable. Each icon symbolizes an information category. The notion of a "workflow" defines the semantics of the network.

One element of the user interface is the "control panel" of WorkBrain. It provides access to all parts of the storage layer components except the technical application systems and databases. Extended search and retrieval functions are given.

Process Example

In order to illustrate the concept and the system functionality we consider the inquiry/proposal process for special bearings of our industry partner, INA Wälzlager Schaeffler KG in Herzogenaurach. INA produces roller bearings, motor elements, and linear-guidance systems for car manufacturers and the machine tool industry. Standardized catalog bearings as well as customer-specific bearings are produced. The set up of a proposal for a customer-specific bearing is organized in the process phases depicted in figure 5 details of the process are described in [MoRW96].

Fig. 5: Phases of the INA inquiry/proposal process

The inquiry/proposal process has a long cycle time and passes through several hierarchy levels of INA. It consists of well- and poorly- structured process parts. This spread is challenging for a WMS designer. The processing of inquiries needs a lot of know-how. The involved employees are mostly highly-qualified specialists with long-term experience. The high specialization results in a strongly functional orientation and a ramified organizational structure. The process costs for completing a proposal are about US-$ 3,000. According to habits in the machine tool industry, these costs are not billed. The process is important because special bearings often become catalog bearings and special system solutions that are generated within the process are used as competitive weapons. The process leads to innovation, and the developments launched by the customer ensure that INA stays close to market needs. Even though the catalog business has a higher revenue, the special bearings are of importance because a lot of customers want to get all bearings they need from a single source. The complexity of the process can simply be shown by some figures: About 700 people and 300 organizational units can be involved in inquiry/proposal processes. There are more than 100 elementary actions that have to be performed. The cycle time is 55 days on average whereas one business case can include up to one hundred documents. 2.000 inquiries have to be processed per year.

The next section describes the WMS functions of WorkBrain. We take the modified workflow life cycle phases to structure the description.

Design of Workflow Building Blocks

The first phase in the modified workflow life cycle is the design of building blocks. Reference process models or reference function models which mirror the characteristics of an industry seem to be a promising starting point for setting up building blocks [MoRJ94]. The first one - the process reference model - faces the problem to be either too abstract (then the information needed to design workflows is too poor) or it is too specific (then what is left over after an adaptation to the own situation tends to zero). The second one - the function reference model - does not provide any process logic. The authors suggest the already explained approach of reference building blocks to overcome these problems: Process logic can be provided at the desired level (workflow or phase level) and the building blocks can be continuously shifted between the abstract and the concrete level. The building blocks stem from three sources:

* a sample library containing real case studies of our workflow project of our industry partner COI,

* a template library which contains generalized elements from the case studies,

* and an enterprise-specific database which consists of parts of the sample database and the case study databases, both modified according to the INA process requirements.

Fig. 6: Creation of activity variants

The only library that is released to be modified is the enterprise-specific library. It contains building block templates for the INA inquiry/proposal process and instances (the workflow case base). This library is evolving with time and can be adjusted continuously. New building block variants can easily be created by copying and changing existing ones. Figure 6 shows how a variant of an activity is created. The father-son-relationships of building blocks are stored in order to be able to trace its evolution. Each building block can have the status "active", "obsolete", or "planned". Due to the outer learning cycle presented in section 4.1 it is necessary to align the building blocks with higher level business tactics and strategies. It is a future task of our work to systematize the realization of strategic goals at the operative workflow level while simultaneously reacting to the recognized weaknesses of the current workflows and external influences.

Workflow Configuration

The start phase of a workflow instance is split up into three parts: the workflow triggering, the automated workflow pre-configuration, and the manual fine configuration. An inquiry/proposal process is triggered by an inquiry a customer or a field service employee posts. In WAX both groups have dedicated access to special forms where they can fill in data like the customer name, the desired product category, the application of the product etc. By sending this HTML form to the WAX server a workflow folder is created, automatically pre-configured, and the workflow is started and routed to the first person handling the workflow. The pre-configuration already uses know-how saved in the OMIS storage: Depending on a set of parameters, a default template workflow is combined of building blocks according to business rules found in a pre-configuration rule table. The desired proposal date, e.g., is decisive for the "length" of the workflow: If this date is closer than ten days to the present date then in the workflow phase "cost estimation" a special sub-workflow is assigned (a shortened estimation procedure that drops the detailed handling of the expected manufacturing costs at the involved plants). Additionally to the regular role mechanisms, we implemented case-dependent roles that may override default roles subject to certain parameter constellations. Parameters are the customer size, the customer region, the industry, the product category, and the application category. Figure 7 shows the role "abt_leiter_antr" which is chosen if the customer is large, located in South/West Germany, the product type is "Axial-Nadelkranz", the application is "Fahrwerk", and the industry is "Personenfahrzeuge". If this combination is valid for a workflow, the role is taken for every activity having the default role "angestellt_ott".

The first employee dealing with the workflow is the "workflow planner", a person who can be seen as the counterpart of the classical "work scheduler" for manufacturing operations. He takes a look at the specification of the pre-configured workflow and makes changes if necessary. The first thing he has to do is to search workflow cases which might be logical predecessors of the current case. For instance, an order by a customer is related to an offer he received from INA several months ago. At INA people think very much in "business cases". They even sometimes remember the arbitrarily chosen project numbers of past inquiries, the so-called "F-number". Old business cases and their related engineering solutions are often been taken to solve actual problems. To use existing process know-how for his changes, the workflow planner has two possibilities: He can regularly search the workflow case base or use a CBR component. The result of the case search is the complete specification of (one or more) historical workflows. Suitable building blocks of this specification can be reused by copying, pasting, and adapting it to the current business case. Figure 8 shows the search mask for historical workflows.

Fig. 7: Modificaton of case-dependent roles

Much of the organizational knowledge is implied in the activities, that are performed in a company, and their relationship to each other (the workflow phases). In WorkBrain, all workflow activities can be searched and browsed. Since it is important to get a visual impression of a workflow we implemented a Java applet that illustrates the activity network. We use different layers to visualize the workflow structure. At the top level, each rectangle represents a workflow phase that contains a sub-workflow. With a mouse click on the phases, the underlying sub-workflow pops up in a different window.

The part organization memory of the WorkBrain control panel provides access to an organizational database. The database can be browsed entirely. Each relation between information categories is represented by hyperlinks. For a role, e.g., the corresponding users, activities, and rights are hyperlinked. For the workflow planer it is easy to get an overview of the multiple relationships in the organization and manually change activity-role-assignments if necessary.

Fig. 8: Workflow search mask

The second possibility for the workflow planer to access workflow knowledge is the CBR component that is coupled via DDE (dynamic data exchange). It uses flat feature vectors to find workflow cases. Different similarity measures can be chosen. Results of a CBR search are past workflows. The process logic, the graphical description file, the documents, and the plan data can be taken to configure a new workflow or to just take a look at the solutions and copy the drawings, business data etc. Accordingly, sub-workflows and activities can be found and reused as building blocks in a similar manner. After the termination of a workflow, it is completely stored with all related information. Figure 9 shows the CBR search window of the workflow phase case base and the result list. A detailed description of the similarity measures and the implementation of the CBR component can be found in [Oed97].

Fig. 9: CBR search and retrieval

Workflow Execution and Control

After the workflow planner terminated the workflow fine configuration, he saves it and the actual processing of the inquiry starts. The workflow folder is passed from employee to employee and is gradually filled up with documents like drawings, calculation sheets, forms, price lists, and finally the proposal letter to the customer. Due to the process's complexity and its creative nature, it must be able to change the workflow design "on-the-fly". Every user who has the right to change workflow specifications can redesign the workflow with the graphical editor and save the modified version in the engine's database. Changes can be made for all future activities and their relationships to each other. All past activities are blocked.

The rights for workflow modification are coupled with the regular rights-role administration. It is reasonable to keep the number of employees who are allowed and able to modify workflows as large as possible since disturbances and suddenly occurring needs to change the workflow structure can appear at every state of the business case. If someone else than the affected employee has to be involved in order to change the workflow, the advantage of "on-the-fly" changes is lost. On the other side, it is desirable to keep the number of workflow variants as small as possible. Therefore, only certain people should have the possibility to declare workflow instances to be generic workflow templates. Furthermore, the top level workflow that connects the workflow phases should be "stable", i.e. not be changed for a period of time longer than one or two orders of magnitude of a single workflow's cycle time.

Each activity that has to be performed appears in the to-do lists of all users who possess the related role. If a user chooses an activity with a mouse-click, the activity disappears from all other to-do lists. A new browser window with the "to-do mask" pops up containing the workflow folder with all documents, some workflow data, and the trigger button of application systems which support the execution of the activity, e.g. TADDY. Additionally, checklists are available which have the purpose to guide the employee when performing complex activities like the technical assessment of an inquiry and also in order to document what has been done. The items of the checklists can be connected via hyperlinks with documents like ISO9000 instructions or explanations. The results of the work done with the application systems can be transferred to the workflow folder. When the activity is completed, the user closes the to-do mask and the workflow is continued. Figure 10 shows the principle of the workflow processing.

Knowledge Transfer

In order to transfer knowledge between organizational members in general and to couple know-how forwards and backwards within a business process, several mechanisms and components have been implemented:

* The storage of interdependencies between workflows is established. One of the reproaches against process orientation is that business processes are "cuts through an enterprise's body" and do not consider the relationships orthogonal to these cuts [Mert96]. We are at least able to retain the relation of subsequent processes (see section 6.3).

Fig. 10: Principle of workflow management with WAX

* The cross-sectional transfer of know-how is supported by a special "know-how counting function". Each time a user performs a workflow activity the counter increases by one. Thereby, it is possible to find out who is experienced in certain activities. Figure 11 shows the know-how table of Samsa Gregor. Especially in a know-how-oriented enterprise like INA with a high degree of specialization, it is advantageous for a workflow planner to assign the right person to perform a task. Of course, people often simply know who has special skills for a certain task, but sometimes this is not the case and a know-how bearer storage is an aid.

Fig. 11: Know-how of Samsa Gregor

* One of the most important design elements of the system is the hypermedia user interface. It allows to present the context of formerly isolated workflow information according to the philosophy: "everything is a link".

* A similar effect is accomplished by the possibility to retrieve workflows via document searches. Especially checklists which store also "soft information" like episodes, problems, etc. contribute to making procedural and technical knowledge available - detached from the strict time-logic structure of processes.

* Automated storage of knowledge along with the audited activities is just one part of the management of OM. The other element is communication that generates and distributes knowledge. The discussion forum "WIBIS" (Workflow Issue-based Information System) is based on the idea of issue-based information systems (IBIS).With this forum, it is possible to assign certain topics to roles and activities. The roles automatically receive all new messages in WIBIS. Therefore, the discussion of problems can be proliferated in both directions (future and past of a workflow state) within a business process since e.g. certain roles are only "active" in confined workflow phases. The role bearer are actively notified about issues exceeding these limits. Discussion topics can be generated about business case problems (technical or commercial) or workflow management itself. WIBIS can be "started" anytime. It provides functionality to place statements and add pros and cons or examples to them (see figure 12). It is also able to set hyperlinks to certain topics or statements that point to electronic documents (filed anywhere, e.g. workflow folders of the WMS or external WWW documents) that are of some interest for the topic.

Fig. 12: WIBIS

Summary and Next Steps

The proposed concept addressed the problems of WMS and OMIS described in chapter 2. The difficulties of both systems can be remedied by combining the underlying ideas and designing an integrated system with common functions - an OM-based evolutionary workflow system. It represents an OM in the small with the specific task to support the planning, control, and execution of complex industrial core business processes. Double-loop learning is supported by the concepts "case-oriented workflow configuration" and "hybrid workflow management", a process-oriented OM storage structure, and special OMIS functions. Procedural and professional know-how is retained workflow-aptly in the OM. The extension of a WMS to an OMIS appears promising since daily work practice and know-how management are integrated. The main focus of the implementation was to integrate the OMIS functions into the working environment of the employees and to create an "easy-to-use" interface that presents information and functions contextually.

There are still deficiencies concerning the outer learning cycles. Work has to be done to systematize the workflow evaluation, the implementation of improvement measures, and the related OM maintenance. Also a framework for breaking down strategic goals to the workflow level is still not available.

We currently perform case studies investigating further complex project-like business processes like the inquiry/proposal process at INA. The results will be used to fine-tune the WMS prototype and to implement further process examples and to create a workflow component library that can be used as a starting point for the workflow evolution process when implementing WMS in companies.

Parts of the concepts and solutions of our prototype are transferred to the running workflow system at INA and to the WMS products of COI: e.g. the FLEXWARE approach is used for the workflow engine of the next release of BusinessFlow.


This project is supported by our industry partners: INA Wälzlager Schaeffler KG and Consulting for Office and Information Management (COI) GmbH and the Bavarian Research Center for Knowledge-Based Systems (FORWISS).


Ackerman, M., Mandel, E., Memory in the Small: An Application to Provide Task-Based Organizational Memory for a Scientific Community, in: Nunamaker, J., Sprague, R. (eds.), Proceedings of the 28th Annual Hawaii International Conference on System Sciences, Vol. IV, Los Alamitos 1995, p. 323-332.
Ackerman, M., Stein, E., Organizational Memory and Organizational Memory Information Systems, Tutorial, 29th Annual Hawaii International Conference on System Sciences, Wailea, Maui 1996.
Ackerman, M., Organizational Memory, URL:, 14th December 1996.
Argyris, C., Schon, D., Organizational Learning: A Theory of Action Perspective, Reading 1978.
Aulbur, W., von Bonin, T., Zementiert das System unproduktive Abläufe?, in: Standardsoftware (1996) 7/8, p. 5-9.
Balasubramanian, V., Organizational Learning and Information Systems, URL: http//, 9.5.97.
Bullinger, H., Schäfer, M., Lernende Organisationen, Oracle Welt (1996) 3, p. 4-9.
Consulting for Office and Information Management (COI) GmbH (eds.), BusinessFlow 3.3 User's Manual, Herzogenaurach 1996.
Davenport, T., Process Innovation, Boston 1993.
Dodgson, M., Organizational Learning: A Review of Some Literatures, Organizational Studies 14 (1993) 3, p. 375-394.
Faisst, W., Wissensmanagement in Virtuellen Unternehmen, Working Paper no. 8/1996 of the series "Information and Communication Systems as Design Elements of Virtual Enterprises", University of Erlangen-Nuremberg, Nuremberg 1996.
Gappmaier, M., Kooperative Vorgangsbearbeitung - Eine empirische Untersuchung der Arbeitsorganisation, Working Paper of the Institute of Computer Information Systems of the University of Linz, Linz 1993.
Hammer, M., Champy, J., Reengineering the Corporation, Boston 1993.
Harrington, H., Business Process Improvement, New York 1991.
`t Hart, M., Matching Intelligent Systems with Business Process Reengineering, Intelligent Systems in Accounting, Finance and Management 5 (1996) 5, p. 41-53.
Herrmann, T., Workflow Management Systems: Ensuring Organizational Flexibility by Possibilities of Adaptation and Negotiation, in: Proceedings of the Conference on Organizational Computing Systems (COOCS), Milpitas 1995, p. 83-94.
Imai, M., KAIZEN: Der Schlüssel zum Erfolg der Japaner im Wettbewerb, Berlin 1994.
Iten, A., Workflow-Management bei Landis&Gyr, in: Österle, H., Vogler, P. (eds.), Praxis des Workflow-Managements, Braunschweig/Wiesbaden 1996, p. 253-270.
Jost, K., Pilotprojekterfahrungen, in: Österle, H., Vogler, P. (eds.), Praxis des Workflow-Managements, Braunschweig/Wiesbaden 1996, p. 229-238.
Kiely, T., Learning to Share, CIO (1993) 7, p. 38-44.
Mayer-Kress, G., Barczys, C., The Global Brain as an Emergent Structure from the Worldwide Computing Network, and its Implications for Modeling, in: Tech-Report CCSR-94-22, Center for Complex Systems Research, University of Illinois at Urbana-Champaign, 1994.
Mertens, P., Process focus considered harmful, WIRTSCHAFTSINFORMATIK 38 (1996) 4, p. 446-447.
Morschheuser, S. et al., Referenzmodell einer integrierten Daten- und Dokumentenverarbeitung im Industriebetrieb, dargestellt am Beispiel der kundenwunschorientierten Anfrage-/Angebotsabwicklung von Maschinenbauunternehmen, Working Paper no. 2/1994 of the Department of Information Systems I, University of Erlangen-Nuremberg, Nuremberg 1994.
Morschheuser, S., Raufer, H., Wargitsch, C., Challenges and Solutions of Document and Workflow Management in a Manufacturing Enterprise: A Case Study, in: Lynn, M. (ed.), Proceedings of the 29th Annual Hawaii International Conference on System Sciences, Vol. V, Los Alamitos 1996, p. 4-13.
Müller, S., Scheidt, M., Geschäftsprozeßoptimierung - mehr als nur ein kurzlebiger Trend!, Industriemanagement 12 (1996) 5, p. 6-9.
Nevis, E., DiBella, A., Gould, J., Understanding Organizations as Learning Systems, Sloan Management Review, Winter 1995, p. 73-85.
N.N., Workflow-Software wird ein Renner, Computerzeitung 26 (1995) 34, p. 17.
Oed, J., Entwurf und prototypische Realisierung einer Know-how-Datenbank zur fallabhängigen Workflow-Planung und -Steuerung, Diplomarbeit, University of Erlangen-Nuremberg, Nuremberg 1997.
Paper, D., Johnson, J., A Theoretical Framework Linking Creativity, Empowerment, and Organizational Memory, in: Lynn, M. (ed.), Proceedings of the 29th Annual Hawaii International Conference on System Sciences, Vol. IV, Los Alamitos 1996, p. 20-33.
Parsons, T., General Theory in Sociology, in: Merton, R. et al. (eds.), Sociology Today: Problems and Prospects, New York 1959, p. 3-37.
Pedler, M. et al., Towards a Learning Company, Management, Education and Development 20 (1989) 1, p. 20-38.
Peters, T., Liberation Management, New York 1992.
Quinn, J., Intelligent Enterprise: A Knowledge and Service Based Paradigm for Industry, New York 1992.
Schmidt, K., Bannon, L., Taking CSCW Seriously - Supporting Articulation Work, CSCW 1 (1992) 1-2, p. 7-40.
Schnitzke, M., Konzeption einer flexiblen Komponente zur Steuerung und Integration in ein Workflow-Produkt, Prediploma Thesis, University of Erlangen-Nuremberg, Nuremberg 1996.
Scott-Morgan, P., Die heimlichen Spielregeln: die Macht der ungeschriebenen Gesetze im Unternehmen, Frankfurt/Main 1994.
Steinmetz, O., Die Strategie der integrierten Produktentwicklung, Braunschweig 1993.
Stein, E., Organizational Memory Review: Concepts and Recommendations for the Management, International Journal of Information Management 15 (1995) 2, p. 17-32.
Stein, E., Zwass, V., Actualizing Organizational Memory with Information Systems, Information Systems Research 6 (1995) 2, p. 85-117.
Walsh, J., Ungson, G., Organizational Memory, Academy of Management Review 16 (1991) 1, p. 57-91.
Wargitsch, C., Wewers, T., Wirthmüller, A., WWW-Front-Ends for Document and Workflow Management Systems, in: Proceedings of the IT-Vision-Week, CD-ROM, Paderborn 1997.
Wargitsch, C., Wewers, T., FLEXWARE: Fallorientiertes Konfigurieren von komplexen Workflows - Konzepte und Implementierung, Müller, M., Schumann, O., Schumann, S. (eds.), Proceedings of the 11th Workshop 'Planning and Configuration' on the 4th German Conference "Knowledge-based Systems" (XPS-97), Erlangen 1997, p. 45-55.
Workflow Management Coalition (ed.), Glossary, A Workflow Management Coalition Specification 2/1994, Brussels 1994.
Yaki, A., Germany - A high growth market, poised for major change, Document World (1996) 5, p. 14-16.