Workflow Management within the ARIS Framework
Business process re-engineering is the key issue for companies to regain competitiveness and profitability in increasingly volatile markets. Customer-focused enterprises are to be structured along their core processes and have to be strictly value-oriented. Workflow Management is becoming more and more based on cooperative, distributed workflow applications that on the one hand need business process re-engineering to be effective, and on the other hand use process models as a specification for the control of the process execution.
The lack of powerful tools as well as methodological deficiencies - particularly with regard to capturing complex process logics and dynamics - are major obstacles for a successful re-engineering of business processes. The ARIS-approach not only provides a generic and well documented methodological framework but also a powerful business process modeling tool. This tool supports the entire process re-engineering project during all life cycle phases. In a research project it has been integrated with a prototype workflow management system to improve the reuse of business process models for the implementation of workflow applications.
Current State of Business Process Re-engineering Methodologies
Enterprise Modeling Frameworks
Issues of enterprise modeling and integration have extensively been discussed at several workshops and conferences. Modeling frameworks, methodologies and life-cycle concepts emerged in different application domains such as Computer Integrated Manufacturing (CIM) [1], office automation [2] and information system design [3].
These modeling methodologies and frameworks are often based on implicit assumptions regarding their scope, objective and level of detail. The ARIS-architecture as depicted in figure 1, for instance, focuses on the analysis and requirements definition phases during the design of managerial information systems. It is a multi-layer - multi-view approach focusing on business-related issues distinguishing between the organization, function, information and control views. Each view is further detailed with reference to the stages of the software life cycle in the levels requirements definition, design specification and implementation description as promoted by CIMOSA [4]. Process chains diagrams support the integral description of business processes on a comparatively aggregate level.
They can further be detailed according to view-specific particularities. Figure 1 indicates suitable methods and contents of the ARIS-framework. It can be used as the schema description of a repository system for organizational information systems. The CIMOSA framework was designed mainly to support the model-driven enactment of manufacturing processes. Its orientation towards 'run-time-modeling' necessitates a formal process description language. This formal strictness imposes restrictions on the day-to-day usability by potential end-users.
Another aspect that leads to the large variety of modeling approaches is the fact that the aptness of modeling methodologies is very much dependent on the purpose of modeling. Some modeling effort might be primarily descriptive by nature while in other cases an optimized implementation solution is sought. In the latter case, the process analysis has to be supported by formal evaluation tools such as simulation. This requires an unambiguous parsable process description which is far too detailed for merely descriptive purposes.
Currently, the need is being felt to reconcile different approaches, identify commonalities and consolidate the various modeling methodologies and frameworks. Throughout the research community a consensus has been reached that there is no 'silver bullet' to enterprise modeling and integration. However, when comparing some major modeling frameworks such as the Purdue Enterprise Reference Architecture (PERA) [5], the CIMOSA modeling framework, the IFIP Reference Model [6] or the ARIS-architecture [7], clearly a substantial overlap can be perceived. Hence, it seems useful to identify the commonalities and differences on the way of consolidating the architectures. This approach is reflected by the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises [8].
Dynamic business process modeling will become increasingly important in the future. The shift from mass production to mass customization in IS-design and the growing interest in high-level system specifications requires well-defined business process models. It is necessary to have a clear understanding of the nature of business processes to modify and re-configure them. Business process models help to identify and remedy deficiencies in the process logic. Such are redundant process components, unnecessary complexity, and insufficient decision support. They might also serve as a software process specification for designing information systems.
Despite the widely felt need for process re-engineering, research in the field is still to be considered as 'pre-paradigmatic'. No methodological platform has been acknowledged as 'de-facto-standard'. Most of the key terms such as event, trigger or condition are used quite differently throughout the research community. Mechanisms for organizational decision making and coordination are not widely incorporated in modeling frameworks. Doumeingts et al. [9] were one of the first who explicitly modeled decision structures in CIM. Sol [10] emphasizes the importance of modeling decision processes when designing information systems. With regard to dynamic process behavior, in-depth modeling methodologies for information systems design are readily available in software engineering such as data-flow based approaches, stimuli-response chains, Petri-Nets and object-oriented techniques. Although these approaches provide valuable insight into the principal problems of capturing dynamic behavior in a 'quasi-static' descriptions, they are not particularly well suited for addressing the dynamics of business processes. They often are too formally described and don't appropriately capture business rules and events that control the business process flow. The dynamic behavior of business processes clearly shows an 'organizational bias'. Business process models are superimposed by human behavior. This behavioral distortion can only partially be represented by formal modeling approaches originating from the IS-domain. A business process modeling methodology has to incorporate aspects such as human roles, responsibilities, and (informal) communication.
Another aspect of business process modeling requiring further research is the topic of reference models. A reference model is a partial modeling block that is not completely instantiated. It is an incomplete representation of a system under a given viewpoint serving a certain purpose for specific users. Reference models are an organizational information resource. They represent and store 'know-how' about systems. Reference models form a 'know-how base for business process modeling'. Benefits commonly associated with (data) reference models [11] such as accelerated modeling processes, cost and time-savings and quality improvements emphasize the need for business process reference models. Although several EEC projects such as CIMOSA, VOICE and CODE took this approach, business process related issues have not been covered extensively. The focus clearly was on structural reference models.
Business Process Reengineering and Workflow Management
Their usefulness to support the automation of business processes in offices as well as manufacturing areas has led Workflow Management Systems (WMS) to become very popular the last years [12]. Workflow applications are often chosen as a technological enabler for business processes which involve many employees on different locations and/or need a better system integration, better process control, higher quality and/or improved customer focus.
Process models are the basis for the development of enterprise specific workflow applications. Whereas the models describe the process structure and logic on a type level the workflow application supports the execution of single processes on the instance level. Like the definition of data structure in a database management systems leads to a specific database, the definition of a process model in a WMS results in a particular workflow application. In contrast to the generation of program code out of models like intended in the classical CASE approaches the development of workflow applications is based on the configuration of existing software building blocks and supports therefore the reuse of software.
Available WMS integrate modeling systems for the graphical definition of process models (see FlowMark, FlowPath, Workparty, Cosa, FloWare, etc.). In comparison to existing architectural frameworks for the business process modeling the functionality of these systems and their modeling concepts are quite poor. They do not support the separate construction of models in views like data, organization, function and their integration in a central process view. Each WMS-provider has defined his own method for modeling processes. These methods are in the most cases a derivation of Petri-Nets. Currently the Workflow Management Coalition is working on a standardization for the process modeling within WMS.
Modeling of Workflow Applications
Workflow projects have a duration between one and three years depending on the field of application [13]. Like in the most BPR projects at the beginning there is no clearness about how to improve the business process structure and workflow. The following describes how the ARIS framework supports the development of workflow applications.
The requirements definition follows primary business oriented and not technical goals, i.e., during the requirements definition aspects like time, costs, frequency, redundancy, etc., are explored. After a current state analysis different alternatives describing how the concerned business processes can be improved are developed. Depending on what kind of solutions are considered to achieve the chosen alternative we can differentiate between organizational, personal or technical approaches or even a mixture of these.
From the technical point of view it is possible to explore business process models with regard to what kind of information system is necessary. On the basis of process models it is even possible to specify the type of WMS needed to support the process (document management, integration of database applications, etc.). Therefore all views have to be integrated in the process model: data, organization and function.
Since exception handling is a central problem in workflow applications we have developed a new approach for the management of such exceptions. Already on the level of the requirements definition exceptions can be considered through the definition of a special exception diagram.
If process models are defined on the requirements definition level and approved as input for the development of workflow applications, they can be refined in the next level.
During design specification the process models have to be refined in regard to the chosen WMS. Whereas on the requirements definition level concrete software systems or exact parameters for the configuration of the workflow application are not focused now these are aspects which have to be considered and elaborated. The following describes some central rules for the refinement of process models into workflow models.
Functions which will be automated by the workflow application have to be specified on a detailed level. If functions are taken over by a software system their is no need to specify them very detailed. Manual performed functions have to be specified as task lists. Therefore we use function trees which are even shown as an orientational help in the workflow application.
The data and data flow is described on the level of the requirements definition mainly as clusters which are input or output of functions. During design specification these clusters have to be specified more in detail regarding the entities and structure of the data clusters. For a detailed description of the data flow it is necessary to define a data flow diagram.
The organizational units described in the process models are often on an abstract level. Workflow applications use the role concept. Roles describe the capabilities a person must have to perform a certain job position. According to such roles at the runtime of the workflow application persons can perform specific process steps. This concept has to be considered.
Beside the described aspects it is important to define exactly the events and decision nodes within process models as well as specify the parameters for the integration of software programs.
At the level of the implementation description it is necessary to adapt the given information infrastructure to the distributed, integrated concept of the workflow application based on the model resulting from the design specification.
The workflow models are used to configure the workflow application. They can be understood as a graphical program. Through this reuse of business process models the manual programming of software code decreases.
Not any WMS supports the graphical definition of workflow applications. In such cases the workflow models resulting from the implementation description can be used as a basis for the "normal" implementation work through programmers.
Integration of Business Process Modeling Tools and Workflow Management Systems
Tool support for business process modeling requires computer-based means for representing and processing (reference) models. It covers functionalities such as model representation and -manipulation. Major functions of a model management system are [14]:
As described, the stepwise development of workflow applications from business process models is a meaningful approach. We have accomplished case studies in 17 companies which have or are in progress to implement company specific workflow applications. From this empirical research we have figured out different strategic success factors for the development of workflow applications, e.g., each of those 17 companies had engaged consultants to elevate the state of the art and develop alternatives for the reorganization of the business processes. Only one of those 17 companies could directly reuse the results of the consultancy services for the implementation of a workflow application. Reasons for this bad integration of reorganizational activities and the implementation of an appropriate system are:
On the background of these situations we have developed a WMS and integrated this system with the modeling tool "ARIS Tool set". The following describes these systems:
The ARIS-Tool set [15] provides comprehensive computer support for business process modeling. Its modular range is depicted in figure 2. The four modules provide means for a computer-aided analysis, planning and introduction of managerial information systems. The systematic approach covers the entire modeling life cycle. The ARIS-Modeler focuses on system modeling. Based on the meta-structure of the ARIS framework, view-specific modeling methods are provided for computer based modeling. This includes extended entity relationship modeling as well as process chain diagrams, stimulus-response chains, and functional and organizational hierarchy charts. The ARIS-Modeler covers the model construction and storage part of the model management activities mentioned above.
The ARIS-Analyzer provides means for examining and assessing the current system with regard to key performance indices. Weak point analysis can be conducted for each modeling view. Furthermore, an idealized integration concept may be derived. It includes target function and data models. Reference models are an essential part of the ARIS-Analyzer. They are used to support the analysis and the modeling activities. The model selection and retrieval process is assisted by a classification scheme (business topology). It contains a table of features and feature characteristics to classify a company. Among the features are e.g. product structure, type of manufacture, complexity of assembly or type of order release. Based upon a company-specific feature profile, the most appropriate reference model is extracted from the model base and used as the starting point for modeling resp. analyzing the current situation. The selection process is supported by rule-based expert system. Model configuration activities such as model adaption and integration also are part of the ARIS-Analyzer. The reference model selected is tailored to the company-specific requirements. This involves steps such as detailing, modifying and enhancing the reference model.
The ARIS-Projectmanager is used for project control tasks. It is designed to plan, control and monitor the entire project in all its phases. The ARIS-Projectmanager defines all the tasks to be dealt with in the course of a business process modeling activity. The aim of the ARIS-Navigator is to provide computerized documentation for the corporate model developed during the modeling phases.
Figure 3 shows a sample screen layout of the ARIS-Modeler. The menu bar and the icons are compliant with the Windows standards. Several windows can be displayed simultaneously. The active window in the upper left part of the screen is highlighted. It shows an excerpt of an ERM-based model. The modeling constructs (object types) for data modeling are activated in the left column of the screen. When another window with another model type is selected, it changes accordingly. On top of the construct column the ARIS-architecture is displayed indicating that the active window is a data modeling window.
The other three windows show the hierarchical functional and organizational modeling as well as a process chain diagram. The latter is associated with the control view of the ARIS-architecture. The modeling objects resp. the modeling instances stored in a database upon instantiation. Comprehensive consistency checking ascertains the correctness of the models. The modeling syntax is checked against rules derived from the meta-structure in the repository. This ensures the correct application of the modeling constructs.
The ARIS Workflow Manager is the prototype of a WMS developed at the Iwi [16]. It is based on a client-server-architecture and fully process oriented. The functionality of the system comprises task management, process oriented searching in archives, the creation and distribution of multimedia documents (text, pictures, audio and video) as well as concepts for exception handling.
The ARIS Workflow Manager uses process models from the ARIS Tool set as basis for the control of business process execution. Therefore the metastructure of both systems has been adapted to each other. Besides the definition of the process structure it is possible to start the process execution directly from within the ARIS Tool set by selecting and activating a single functional step of a process model.
Through a feedback functionality the end-user can leave statements (problems, suggestions, ideas, etc.) in a multimedia form for the process manager. The structuring of these feedbacks is done automatically by the system. Process managers can browse through the process models in the ARIS Tool set and react immediately to new feedbacks.
Figure 4 shows the user interface of the ARIS-Workflow Manager.
There are no easy ways or short cuts on the way to truly integrated enterprises. Undue simplifications in the business process analysis and integration phase are a substantial risk for the implementation of integrated systems. Case studies and the integration of a prototype WMS with the ARIS Tool set has led us to the opinion that the consolidation of methodological frameworks (i.e. meta structures) is an essential prerequisite for the overall integration from business reorganization to information systems implementation.