Enterprise Integration: operational models of business processes and workflow systems *

Transcription

1 Enterprise Integration: operational models of business processes and workflow systems. 1 Enterprise Integration: operational models of business processes and workflow systems * G.Bruno 1, C.Reyneri 2 and M.Torchiano 1 1 Politecnico di Torino - Dipartimento di Automatica ed Informatica; bruno@polito.it, mtorchia@athena.polito.it 2 Fiat Auto MAINS - Metodi e Strumenti; reyneri@mains.fiat.it Abstract. The complexity of modern enterprises makes enterprise modeling a major issue. The need for integrating several different features requires a powerful modeling technique, such as CIMOSA, able to represent functional, control, informational and organizational aspects. However, the study of a system yields limited results as long as it only consists of inspecting a static model. More effective results can be achieved if an operational (i.e. executable) model is available. This paper presents an approach to enterprise integration and a technique for building operational enterprise models based on the modeling language Opj. An interesting feature of Opj is the possibility of deriving a workflow prototype from an enterprise model. 1. Introduction While there is an increasing number of enterprises that are changing their business operations from a functional approach to a process-oriented approach, enterprise modeling is perceived as a necessary step to perform this change. Current modeling technology allows the use of enterprise models to go far beyond descriptive purposes; in fact, such models can play a major role in defining and managing business processes and in mapping business processes to support systems such as workflow systems. Enterprise models can be used for different purposes, but it is important to observe that, at least, they act as a repository that semantically organizes the knowledge about the enterprise; this knowledge can be used to achieve specific goals by means of suitable tools. Models describe processes, their interactions and their relationships with the organization and the information system and provide qualitative and quantitative results during the whole lifecycle of the process. However, building effective enterprise models is difficult as it requires handling a large number of classes which are needed to express the functional, information, organization and resource views and managing a complex hierarchical architecture where many interactions take place between subsystems. Making such models operational is even more difficult because execution mechanisms have to be associated with the modeling constructs. This paper presents a methodological and architectural approach to enterprise integration and a technique for building operational enterprise models based on the modeling language Opj (Operational Objects)[4]. Section 2 discusses model-based enterprise integration; section 3 illustrates operational enterprise modeling with Opj by presenting a case study that concerns a travel-approval business process and showing the architecture of the resulting workflow prototype. 2. Enterprise Integration 2.1. The Enterprise System The complexity of the interactions between the variables influencing the manufacturing and commercial scenario has dramatically increased in the last ten years. This is mainly due to the extreme variability of leading economies, to the increasing globalization of competitors and to the markets, which are strongly conditioned by emotive and socio-environmental factors. Further, demand has considerably decreased, becoming more and more unpredictable, while markets require higher and higher quality in products and services. Markets, in fact, are highly conditioned by customers who * Appeared in Enterprise Engineering and Integration: Building International Consensus: Proceedings of ICEIMT'97, Torino, Italy, October 28-30, 1997, K.Kosanke and J.G.Nell editors, pages , Springer- Verlag, Berlin 1997

2 Enterprise Integration: operational models of business processes and workflow systems. 2 require a great effort in design and technology innovation and in customer service improvement from enterprises, along with a very clever evaluation of product prices. R&D COMPETITORS orders SUPPLIERS materials MARKETS ENTERPRISE CLIENTS REGULATION STRATEGIES Figure 1: The Scenario The search for enterprise competitiveness involves, therefore, organizational aspects and human resources, at any level of responsibility. A great care is being devoted to quality, starting from the product design, the manufacturing system, the logistics, the organization, and ending up with services. A general reengineering effort affects the whole enterprise: from design to manufacturing, from customer management to supplier management. This complex and wide reengineering activity, because of the great number of factors influencing enterprise processes, cannot be achieved without a sound methodological approach, supported by innovative tools. The enterprise is a very complex system, characterized by a great number of activities, products, actors, resources, which are often distributed worldwide, need different and complex communication systems, and are conditioned by frequent, unpredictable, troubling events. Such a system has to be controlled dynamically. Methodologies and tools should, therefore, enable as-is and what-if analyses, so as to detect bottlenecks and to validate technological improvements, alternative planning or organizational solutions, from the points of view of cost, time and quality; the same tools should also support the monitoring and real-time management of enterprise processes A model-based architecture for enterprise integration Experience has shown the benefits of suitable models as tools for process analysis, optimization, test and management. But all that is not enough to ensure consistency of the efforts devoted to optimizing specific aspects and/or processes with the global goals of the enterprise itself. The solution to the above-mentioned problem requires the integration of all enterprise processes (in terms of activities, information, organization and resources) in a global model in order to better evaluate the global achievement. Further, relationships between the available information and the enterprise have to be highlighted in order to better exploit the information itself. Thus a conceptual model is needed to show both the information structure and its use. Therefore, throughout the life cycle of a business process we will refer to a single conceptual model of it, even if, in different phases, we could use only some parts of it, with different tools, on the basis of specific needs and goals. What we need is an integrated architecture that supports: = the definition and maintenance of reference processes; = the definition of a specific process as a particularization of a reference process, such a particularization taking place on the basis of parameters coming directly from the enterprise information system; = the optimization, by means of simulation, of particular processes on the basis of specific goals, such as time, cost and quality; = the enactment of a particular process.

3 Enterprise Integration: operational models of business processes and workflow systems. 3 TECHNICAL DOCUMENTATION MANAGEMENT TOOLS PROJECT DOCUMENTATION TOOLS MODELISATION TOOL STRUMENTI SIMULATION SIMULAZION TOOLS RULES PRODUCT/PROCESS BKD. STRUCTURE REFERENCE MODEL MODEL Figure 2: Integrated Architecture 3. Modeling approach and implementation technique The above-mentioned conceptual model must be based on a methodology that addresses different aspects with different levels of detail; we selected CIMOSA [5] as the starting point and then we made it operational by means of the Opj language. CIMOSA and the European Prestandard ENV provide a framework for enterprise modeling in terms of business processes, information, resources and organization. In order to manage complexity the framework organizes the modeling task into four sets of constructs, called views, each view focusing on a different aspect of the problem. Using CIMOSA constructs we can build descriptive models that help us to better understand the actual or intended operation of an enterprise or of a particular business process. Because of the evolving state of the art, the framework leaves room for further extensions. One such extension is to make modeling constructs operational so as to simulate or execute models. Making modeling constructs operational involves introducing some processing capabilities into them; thus an operational construct integrates a business perspective with an IT support. We cannot run a descriptive model but we can run an operational one. Running an operational model yields qualitative or quantitative results because operational constructs incorporate mechanisms that make the constructs evolve over time and interact with each other. The kind of results produced depends on the mechanisms associated with the modeling constructs. Simulation mechanisms are commonly used in order to investigate the performance of a system in terms of throughput and usage of resources. In other cases we might be interested in viewing the model as a prototype of the intended system. A prototype exhibits the major functions of the intended system, including user interactions, but is based a simplified implementation. An operational model fit well for this purpose and, in addition, it retains its descriptive function too. For example, in business process (re)engineering a prototype might be needed when a new business process is designed in order to study the impact on the organization and on the information system. When a humanbased business process is concerned, such as an engineering process (in contrast with a manufacturing process which could be totally automatic), the mechanisms involved are those related to the workflow system [6] and the information system: the former because it is responsible for assigning the right job to the right person at the right time on the basis of the process model the latter because it provides the information objects to be acted on during the activity. Therefore if the enterprise model must yield a prototype of the business process, it must incorporate an organization model, a workflow mechanism and also an information system model in addition to the process model. In this case the mechanism associated with a construct which models an activity is totally different from the above-mentioned one used in simulation: this mechanism will generate a pending activity for the person which is specified in the construct itself either directly or indirectly by means of a rule, and support this activity with the necessary documents.

4 Enterprise Integration: operational models of business processes and workflow systems. 4 The mechanism that characterizes the operational behavior of a modeling construct is an IT component; it can be thought of as an object providing the services (or methods) which implement the required behavior (e.g. acquiring and releasing resources for performance evaluation purposes or assigning work to people for prototyping purposes). Modeling constructs are then mapped onto classes so we can exploit the modeling and abstraction features of the object-oriented paradigm Comparison with related work A recent paper[4] by Vernadat surveys a number of enterprise modeling languages and concludes by recommending that a unified language for enterprise modeling should be developed. According to his analysis most of current modeling languages are descriptive and cover only some views (usually the functional and information ones). In the field of software engineering a unification effort has been made resulting in a unified modeling language (UML)[1]. Unification here concerns the techniques for software analysis and design, therefore UML consists of a number of formalisms some of which are general while others are devoted to software development. Further, the organization view is not taken into account to the extent which is required in enterprise modeling. In a previous work[2] the authors have focused attention on making CIMOSA functional constructs operational by representing them as interacting objects; these objects contain high-level Petri nets and their interaction is based on token passing. Recently the authors have developed a new modeling language, Opj[3], which is fully object-oriented and provides a number of execution mechanisms for simulation and prototyping purposes. Opj supports the notions of building block and of schema of classes. A building block is a component which can be used to build more complex components. A schema of classes groups a number of related classes and shows the relationships existing between them. The information view of CIMOSA can be expressed by a schema grouping the classes that represent the information entities. The functional view can be described by a schema showing the classes of the business processes. Schemata can be organized hierarchically. If we take a business process and look inside it, we see a number of interrelated business activities. Such activities are objects whose classes appear in the schema of business activities: this schema determines which components can make up the business process Modeling business processes Usually business processes are depicted as flowcharts made up of business blocks which represent business activities or decision points. A process operates on a collection of information entities that will be referred to as a process folder. The term process folder is generic nevertheless it gives the idea that a process operates on a number of interrelated entities, which appear as a logical unit. In our case study a process folder collects a mission entity only. Instead, the process folder of a sales process would collect a number of entities, such as an offer, the related order and payment data. A process folder has a life cycle: it is generated, it is acted on by the business blocks and it is finally closed. Until it is closed a process folder is active. Since there are usually many folders concurrently active this question arises: should a business process operate on all the process folders or on just one? We can manage both cases. If the process is to operate on one folder, then when a folder is generated a new instance of the business process will be generated as well and this instance will be connected to the folder. In this case the items which flow through the business blocks are simple control signals; in fact a block knows which folder it has to act on from the beginning. If, instead, there is one instance of the business process and it has to manage all the process folders, the items which flow through the business blocks must be the folders themselves. A block operates on the folder that it has received from the preceding block An example In order to illustrate the proposed modeling technique and the Opj modeling language we discuss the case study concerning a travel approval process whose requirements are shown below.

5 Enterprise Integration: operational models of business processes and workflow systems. 5 Fill_in,OR_Act P Test_if_Mgr,IfBB Approve,Mgr_Act N P Test_if_Approved,IfBB Y Y Make_Reservations,TO_Act Perform_Mission,OR_Act P Make_Payment,TO_Act P Figure 3: The travel approval business process in Opj Corporate policy states that any employee who needs to travel should fill in a standard mission form which has to be signed by the manager of the employee's department. The form contains information about the mission, such as the purpose, the departure and return dates, the itinerary and travel preferences. After the form has been signed, it is sent to the Travel Bureau which makes travel reservations. Then it is the task of the mission s originator to perform the mission and to fill in a report field in the mission form. As the last step of the process, the Travel Bureau will make the final payments and reimbursements. The travel approval process is shown in figure 3. It operates on all travel folders. The travel approval business process is made up of the business blocks which define the above-mentioned activities (Fill_in, Approve, Make_Reservations, Perform_Mission and Make_Payment) and of two decision points (Test_if_Mgr and Test_if_Approved). The first decision point skips the approval step if the originator is a manager, the second one check if the approval has been granted. The process is a sequential one as activities are performed one at a time for a given folder. We can have more complex flowcharts as well in which there are constructs (branch blocks) for starting parallel flows and constructs (synchronize blocks) for waiting for the ending of parallel flows. In the next section we map business blocks onto objects within an object-oriented framework Integrating business constructs and IT components One of the major tenets of the object-oriented paradigm is the ability of building a complex component out of simpler (library) components. This means that a business process can be made up of objects which represent business blocks. In the travel approval process there are three classes of activities: those pertaining to the mission s originator (filling in the request and performing the mission), those in charge of the travel office (making reservations and payments), those carried out by the manager of the originator's department (approving the request). A business block becomes an object and has two identifiers associated with: the first is the block name, the second is the name of the class the block belongs to. A complex component such as a business process is made up of simpler elements: since there might be a large number of classes of components, such classes can be grouped into catalogs of related classes. We can then make a complex component depend on a catalog: this way, when we are introducing a new element into a complex component, we have a reduced number of choices for the class of the new element, since only the classes listed in the catalog can be used. A component is not an island: it will be using other components and, in its turn, will be used by other components; however, a component is such because neither it has the exact knowledge of whom it will be using nor it has of whom it will be used by. Nevertheless some rules are needed in order to make components properly interact with each other. Such rules are usually defined in a schema, which is a catalog of classes plus a set of relationships between classes.

6 Enterprise Integration: operational models of business processes and workflow systems. 6 Abstract_Act N(n,1) Y(n,1) P(n,1) IfBB Act If_Mgr OR_Act If_Approved Mgr_Act TO_Act Figure 4: The business schema for the travel approval process in Opj A business schema is a schema showing classes related to business blocks along with their relationships. The business schema shown in figure 4 is the one the travel approval process depends on. This schema shows a number of inheritance relationships and three associative relationships, i.e. P, Y and N. The base class Abstract_Act serves the purpose of establishing that a business activity can precede (by means of relationship P) any business block (either a business activity or a decision point) and that a decision point can be followed by two business blocks through relationships Y and N. The meaning of a decision point is as follows: when it receives a folder it evaluates a condition related to the mission in the folder, then if the result is true the downstream block connected to the decision point through relationship Y will be executed, otherwise the block reached through relationship N will be executed. There are two subclasses of the abstract class IfBB: class If_Mgr checks whether the mission s originator is a department manager since in that case the approval will not be needed and the flow will be shorter; class If_Approved checks whether the mission has been approved or not. The major difference between decision points and business activities is that the former are automatically managed by the underlying workflow system (no human intervention is required) while the latter generate pending activities which will be performed and then delivered by the users of the system. Business blocks operate on the members of the organization and on information entities, the organization schema and the information schema, the former describing the structure of the enterprise organization and the latter illustrating the structure of the information system. Since the case study being considered is simple we merge such schemata into the one shown in figure 5. Classes Employee and Department logically belong to the organization schema. Works_in(n,1) Department Mission Originated_by(n,1) Is_in_Folder_of(n,1) Travel_Folder Employee Manages(1,1) Refers_to(n,1) Keeps_Track_of(1,n) Activity Performed_by(n,1) Act Figure 5: The information/organization schema in Opj When an instance of the Travel_Folder class is generated an instance of the Mission class is generated as well. A folder not only groups all the related information entities (in this case the Mission entity only) but also

7 Enterprise Integration: operational models of business processes and workflow systems. 7 the actual activities that have been performed so far and those which are pending. Class Activity represents a performed or pending activity. It has a state that shows if the activity has been completed or not (if not it is pending). Relationship Performed_by links an actual activity to the employee who has been assigned to it. The business schema and the organization/information schema, are not independent of each other: for example, given a pending activity, i.e. an instance of class Activity, we have to know which business process step it corresponds to, hence a relationship Refers_to is needed between class Activity and class Act. Class Act is the same as the one appearing in the business schema The operational model We have already stated that there is no single operational model [7], but we can build different operational models depending on the purpose we bear in mind. As far as the case study is concerned, the operational model will be used as a prototype of the intended system thus it has to provide the user with a graphical user interface (GUI) which allows him or her to interact with the model. User interaction takes place as follows: first the user logs in, then he/she will be presented with a work area (Figure 6) showing two lists, one listing the missions he/she has originated and the other showing the pending activities. Figure 6: The work area. The work area allows the user to originate a new mission if he/she clicks the New button; after selecting a pending activity the user can act on it by clicking the Open button on the right. Opening a pending activity means opening an editing form for the mission that is related to the activity. The editing form is shown below. Figure 7: The mission form. The activity is terminated when the user clicks the Submit button; then the mission is passed to the next stage of the travel approval process. The architecture of the model is illustrated in Figure 8. GUI objects are interfaced with information entities; the solution we adopted is to connect each GUI object with a few information entities which are responsible for providing all the services needed by the GUI object. This approach facilitates the mapping of the model onto a client-server implementation: a GUI object lives in the client (possibly hosted by a browser) and interacts with a few remote objects.

8 Enterprise Integration: operational models of business processes and workflow systems. 8 GUI Objects Business Processes Object Information/Organization Model Figure 8: The architecture of the prototype. Opj is a graphical and textual language. The graphical features mainly concern the definition of schemata and of the contents of composite classes. The textual part mainly refers to the definition of the attributes and methods of classes. The textual part of a model can be written using a standard programming language, such as C++ or Java, or an interpreted language, which provides a simpler syntax and a number of support primitives. Opj supports the definition and activation of dialog boxes (or forms), such as the ones shown in previous figures. Further, it allows a button click in a dialog box to call a method of the associated GUI object. Opj can be thought of as a very high-level programming language; Opj models can be simulated and then turned into C++ or Java programs. 4. Conclusion What makes enterprise models different from other models is their complexity in terms of both a large number of classes needed to express the functional, information, organization and resource views and a complicated hierarchical architecture where subsystems perform many interactions with each other. Object orientation is necessary for managing complexity but additional mechanisms are needed to make it fully effective in enterprise modeling. This paper has presented some such mechanisms, which are embodied in the Opj modeling language, and has shown a case study concerning a travel approval business process. Opj supports operational models; a model can be made operational for simulation or prototyping purposes. As far as the case study is concerned the operational model yields a prototype of the workflow system needed to run the business process. Investigating a business process in terms of the workflow system that will run it is useful because the logical aspects of the process can be checked by the users in a natural setting and, what is more, the impact on the information system can be properly analyzed. Opj is supported by a Windows-based development environment, PrimeObjects, which has been used in several industrial projects. References [1] Rational Software Corporation, "UML v 1.0, Notation Guide", January [2] G.Bruno, R.Agarwal, "Modeling the Enterprise Engineering Environment", in IEEE Transactions on Engineering Management, 44(1), February [3] G.Bruno, R.Agarwal, M.Torchiano, "Static, dynamic and run-time modeling of compound classes", in ACM SIGPLAN Notices, November [4] Francois Vernadat, "Enterprise Modeling Languages", ICEIMT'97 Workshop 4, Brussels, June ( [5] Consortium AMICE, CIMOSA: Open System Architecture for CIM, Springer-Verlag, Berlin, [6] David Hollingsworth, The Workflow Reference Model, The Workflow Management Coalition document TC , Brussels, November [7] Pamela Zave, "The Operational Versus the Conventional Approach to Software Development", in Communications of the ACM, 27(2), February 1984.