ENTERPRISE MODELING:MODELING VIEWS AND METHODS

MODELING VIEWS AND METHODS

Process-Oriented Enterprise Modeling

Generally speaking, a business process is a continuous series of enterprise activities, undertaken for the purpose of creating output. The starting point and final product of the business process are the output requested and utilized by corporate or external customers. Business processes often enable the value chain of the enterprise as well as focusing on the customer when the output is created.

In the following, we explain the key issues in modeling business processes with a simple example from customer order processing. First, let us outline the scenario:

A customer wants to order several items that need to be manufactured. Based on customer and item infor- mation, the feasibility of manufacturing this item is studied. Once the order has arrived, the necessary materials are obtained from a supplier. After arrival of the material and subsequent order planning, the items are manufactured according to a work schedule and shipped to the customer along with the appropriate documentation.

This scenario will be discussed from various points of view. As we have already seen, in system theory we can distinguish between system structures and system behavior. We will begin by describ- ing the responsible entities and relationships involved in the business process. Then, by means of function flow, we will describe the dynamic behavior. Output flows describe the results of executing the process, and information flows illustrate the interchange of documents involved in the process.

Functions, output producers (organizational units), output, and information objects are illustrated by various symbols. Flows are depicted by arrows.

Organization Views

Figure 4 depicts the responsible entities (organizational units) involved in the business process, along with their output and communication relationships, illustrated as context or interaction diagrams. The

sequence in which processes are carried out is not apparent. Nevertheless, this provides an initial view of the business process structure. In complex processes, the myriad interchanges among the various business partners can become somewhat confusing. In addition to the various interactions, it is also possible to enter the activities of the responsible entities. This has been done in only a few places.

The class of organization views also includes the hierarchical organization structure (org charts). Org charts are created in order to group responsible entities or devices that are executing the same work object. This is why the responsible entities, responsible devices, financial resources, and com- puter hardware are all assigned together to the organization views.

Function Views

Figure 5 describes the same business process by depicting the activities (functions) to be executed, as well as their sequence. The main issue is not responsible entities, as with the interaction diagram, but rather the dynamic sequence of activities. For illustration purposes, the organizational units are also depicted in Figure 5. Due to redundancies, their interrelationship with the interaction diagram is not as obvious. As function sequences for creating output, function flows characterize the business process. The output flows themselves will be displayed individually.

The class of function views also includes the hierarchical structure of business activities trans- forming input into output. According to the level of detail, they are labeled ‘‘business processes,’’ ‘‘processes,’’ ‘‘functions,’’ and ‘‘elementary functions.’’

Because functions support goals, yet are controlled by them as well, goals are also allocated to function views—because of the close linkage. In application software, computer-aided processing rules of a function are defined. Thus, application software is closely aligned with ‘‘functions’’ and is also allocated to function views.

Output Views

The designation ‘‘output’’ is very heterogeneous. Business output is the result of a production process, in the most general sense of the word. Output can be physical (material output) or nonphysical (services). Whereas material output is easily defined, such as by the delivery of material, manufac- tured parts, or even the finished product, the term services is more difficult to define because it comprises heterogeneous services, such as insurance services, financial services, and information brokering services. Figure 6 illustrates this simplified classification of ‘‘output’’—that is, also ‘‘in- put’’—as a hierarchical diagram.

Concerning our business process example, the result of the function ‘‘manufacture item’’ in Figure 7 is the material output, defined by the manufactured item. Likewise, quality checks are carried out and documented during the manufacturing process. All data pertinent to the customer are captured in ‘‘order documents,’’ themselves a service by means of the information they provide. After every intercompany function, output describing the deliverable is defined, which in turn is entering the next

mation services. For example, when orders are checked, the customer’s credit is checked and inven- tory is checked for availability.

Because data flow is triggered by the functions that are linked to the information objects, it is more or less possible to read the function flow in Figure 8. However, if multiple functions are applied to an information object or multiple data flows are requested by a function, the function process cannot be uniquely deduced.

Besides information flow modeling, the (static) description of data structures is a very important modeling task. Static enterprise data models are used to develop proper data structures in order to implement a logically integrated database. Chen’s entity relationship model (ERM) is the most wide- spread method for the conceptual modeling of data structures.

Process View

Building various views serves the purpose of structuring and streamlining business process modeling. Splitting up views has the added advantage of avoiding and controlling redundancies that can occur when objects in a process model are used more than once. For example, the same environmental data, events, or organizational units might be applied to several functions. View-specific modeling methods that have proven to be successful can also be used. Particularly in this light, view procedures differ from the more theoretical modeling concepts, where systems are divided into subsystems for the purpose of reducing complexity. In principle, however, every subsystem is depicted in the same way as the original system. This is why it is not possible to use various modeling methods in the same system.

It is important to note that none of the flows (organization, function, output, and information flow, respectively) illustrated above is capable of completely modeling the entire business process. We must therefore combine all these perspectives. To this end, one of the views should be selected as a foundation and then be integrated into the others. The function view is closest to the definition of a business process and is therefore typically used as a starting point. However, in the context of object- oriented enterprise modeling information, flows can serve as a starting point as well.

Figure 9 provides a detailed excerpt of our business process example, focusing the function ‘‘manufacture item’’ with all flows described above.

The method used to describe the process in Figure 9 is called event-driven process chain (EPC). The EPC method was developed at the Institute for Information Systems (IWi) of the Saarland

University, Germany, in collaboration with SAP AG. It is the key component of SAP R / 3’s modeling concepts for business engineering and customizing. It is based on the concepts of stochastic networks and Petri nets. Simple versions exclude conditions and messages and include only E(vent) / A(ction) illustrations.

Multiple functions can result from an event. On the other hand, multiple functions sometimes need to be concluded before an event can be triggered. Logical relationships are illustrated by ‘‘and’’ (/\), ‘‘inclusive-or’’ (V) and ‘‘exclusive-or’’ (XOR) symbols. Figure 10 gives some typical examples of event relationships. When there are more complex relationships between completed functions and functions that have just been launched (such as different logical relationships between groups of functions), decision tables for incoming and outgoing functions, respectively, can be stored in an event.

3.2. Object-Oriented Enterprise Modeling

Object-oriented enterprise modeling starts with analyzing the entities of the real world. In the object- oriented model, these entities will be described through objects. The object data (attributes) represent characteristics of the real system and are accessible only by means of object methods. By their definition, attributes and methods objects are entirely determined. Objects that share the same char- acteristics are instances of the respective object class. Classes can be specialized to subclasses as well as generated to superclasses. This is called inheritance—each subclass will inherit the attributes and methods from its superclass.

We can equate the term method used in object-oriented analysis with the term function. Due to the fact that classes are frequently data classes (such as ‘‘customers,’’ ‘‘suppliers,’’ ‘‘orders,’’ etc.), they represent the link between data and function view. We have already experienced object-oriented class design when we discussed the levels of abstraction and the examples of the modeling views (see Section 1.2 as well as Section 3.1), so we can skim the properties of creating object-oriented classes.

Object-oriented modeling is not based on a standardized method. Rather, a number of authors have developed similar or complementary approaches. The various graphical symbols they use for their approaches make comparisons difficult. The Unified Modeling Language (UML), introduced by

Rumbaugh, Booch, and Jacobsen aims to streamline and integrate various object-oriented approaches, which is why we will use these symbols.

Objects, each with its own identity and indicated by an ID number, are described by properties (attributes). The functions (methods) that can be applied to the object define their behavior. Objects represent instances and are illustrated by rectangles. Objects with identical attributes, functionality, and semantics are grouped into object classes or regular classes. The quantity of customers thus forms the class ‘‘customer’’ (see Figure 11).

By naming attributes and methods, classes define the properties and the behavior of their instances, that is, objects. Because attributes and methods form a unit, classes realize the principle of encap- sulation. In addition to attribute and method definitions for objects, we can also use class attributes and class methods that are valid only for the classes themselves, not for the objects. An example would be ‘‘number of customers’’ and ‘‘creating a new customer.’’

One significant property of the object-oriented approach is inheritance, giving classes access to the properties (attributes) and the behavior (methods) of other classes. Inherited attributes and methods can be overwritten and redefined by the inheriting class. Inheritance takes place within a class hier- archy with two types of classes, namely overriding classes and subordinate classes, as is shown by generalizing and specializing operations in data modeling. A class can also inherit properties from several overriding classes (multiple inheritance), with the resulting class diagram forming a network. Figure 12 gives an example of inheritance among object classes.

In addition to the generalizing relationships between classes, there are also relationships (i.e. associations) between objects of equal class ranking or between objects of the same class. These associations equate to relationships in entity relationship models, although here they are illustrated by only one line. These illustrations should be read from left to right. Cardinalities are allocated to an association. At each end of the association, role names can be allocated to the associations. If associations contain attributes, they are depicted as classes (see the class ‘‘purchasing process’’ in Figure 13).

Aggregations are a special kind of association describing the ‘‘part of’’ relationships between objects of two different classes. Role names can be applied to aggregations as well. If attributes are allocated to an aggregation, this leads to a class, as shown by the class ‘‘structure,’’ in an aggregation relation for a bill of materials (see Figure 14).

Class definition, inheritance, associations, and aggregations make up the key structural properties of object-oriented modeling. Overall, the UML provides seven methods for describing the various static and dynamic aspects of enterprises. Nevertheless, even with methods such as use case diagrams and interaction diagrams, it is difficult to depict process branching, organizational aspects, and output flows. Therefore, one of the main disadvantages of the object-oriented approach is it does not illustrate business process in a very detailed manner.