3.2.4. Organization Modeling Concepts

The activities of a business process are typically performed by human resources holding certain organizational positions and playing certain organizational roles within an organization or organizational unit. It should, therefore, not come as a surprise that Activity-Based DES modeling requires to consider a number of organization modeling concepts. In particular, the concept of resource roles and the related concepts of organizational roles and organizational positions are paramount to Activity-Based DES modeling.

Many resource management concepts, such as resource roles, including performer roles, and resource pools, can be captured in information models in the form of categorized ("stereotyped") UML class modeling elements such as «rr» for resource role association ends, «pr» for performer role association ends, and «rp» for resource pool association ends, leading to an extension of UML Class Diagrams, called OE Class Diagrams, such as the following one:


This conceptual OE class model describes two activity types, "walks to rooms" and "examinations", each one associated with

  1. the object type "medical departments", providing the (business) process owner;
  2. a performer object type ("nurses" or "doctors") via a performer role («pr») association end, providing the activity performer (as a special type of resource);
  3. another resource object type via a resource role («rr») association end, providing another resource of each activity (a "room").

In addition, the model describes three types of resource pools by means of «rp» association ends, such that each resource pool is associated with a process owner maintaining the pool and providing the resources corresponding to one of the three resource roles.

Notice that in a conceptual OE class model, each activity type should have a performer role («pr») association, while in an OE class design model (being part of a simulation design model), it is an option to abstract away from the distinction of performers among the resources of an activity and simply consider all its resources (including its performer) as plain resources. This is common in management science and Operations Research, where the main interest is in obtaining general performance statistics for resources, such as their utilization, no matter if they are human resources (performers) or not.

We show how further organization modeling concepts can be introduced to OEM&S.

Refining Object Types to Resource (Role) Types and Performer (Role) Types

While a resource role denotes an association end, corresponding to a reference property, a resource (or performer) role type denotes an object type that is the range of a resource (or performer) role. For simplicity, we say "resource type" (or "performer type") instead of "resource role type" (or "performer role type").

For all «object type» classes of an OE class model that are the range of a performer role or a resource role, it may be an option to replace their «object type» category with a «performer type» or «resource type» category, as shown for the object types "nurses", "doctors" and "rooms" in the following refined model:


Notice that typically each resource type is the range of one resource role and represents a resource pool for it. A resource type may be the target class of more than one resource role association end and its population may be partitioned into several resource pools such that at least one pool is assigned to each resource role.

However, the replacement of the «object type» category of a class with a (performer or resource) role type category is only an option, if all instances of the class are playing that role. In the above example, if there are doctors who do not perform examinations (but only surgical operations), then the object type "doctors" cannot be turned into a performer type "doctors" for examinations, but would have to be partitioned into two subtypes, "surgeons" and "examination doctors", such that the latter would be a performer type for examinations.

In OEM&S, a (human) performer type is implicitly a subtype of the pre-defined object type Person. This makes it possible that a doctor, as a person that performs examinations, may also be a patient in an examination (of course, with the constraint that the person cannot be the same examination's doctor and patient).

Refining Performer Types to Organizational Positions

An organizational position is defined by a name and a set of (human) performer types representing the roles (or responsibilities) of the position holders. For instance, in a medical department, the organizational position Nurse may be defined by the set of performer types Guide and ExaminationAssistant, where a Guide is required for guiding a patient to an examination room and an ExaminationAssistant is required for assisting a doctor in a medical examination.

Computationally, an organizational position is an object type that is partitioned into (one or more) performer types, implying that its instances (position holders) are human resources that can be allocated for performing any activity associated with any of these performer types.

For instance, the organizational position Nurse is partitioned into the performer types Guide and ExaminationAssistant, with the meaning that nurses may play the role of guides or the role of examination assistants.

In simple cases, an organizational position is defined by just one performer type for one performer role.

In an Activity-Based DES model, for each organizational position (like Clerk) consisting of the performer roles p1,...,pn, there is a default resource pool, or better: performer pool, (like clerks) that includes all employees holding that position. This pool will be used for allocating the performers of activities with a performer role pi.

These considerations lead to the following refined version of the medical department model shown in the diagram above:


Notice that in this refined model, we have also categorized the object type "patients" as «person role type» and the object type "medical departments" as «organizational unit type». In OEM&S, a person role type is implicitly a subtype of the pre-defined object type Person, while the instances of an organizational unit type may be process owners.