9.4. Organization Modeling Concepts

The activities of a business process are typically performed by human resources holding certain organizational positions that authorize them to play certain organizational roles within an organization or organizational unit. It is, therefore, natural that Activity-Based DES modeling includes 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 modeling 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

the object type "medical departments", providing the (business) process owner; implying that each specific walk-to-room or examination activity is performed by human resources of, and within a business process owned by, that department;
a performer object type ("nurses" or "doctors") via a performer role («pr») association end, providing the activity performer (as a special type of resource);
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 active 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 of an activity type denotes an association end, corresponding to a reference property of the class implementing the activity type, 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 segmented 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 a 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 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 co-extensional with all of its 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. This implies that any instance (or "holder") of an organizational position is a person and that any organizational position is a subtype of the kind Person.

For instance, the organizational position Nurse is co-extensional with the performer types Guide and ExaminationAssistant, with the meaning that nurses may play the role of guides or the role of examination assistants, and any guide, as well as any examination assistant, is a nurse.

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

In OEM&S, for each organizational position (like Clerk) consisting of the performer roles p₁,...,p_n, 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 p_i.

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, like Patient, is implicitly a subtype of the pre-defined object type Person, allowing a doctor to be a patient. An organizational unit, as an instance of an organizational unit type, may own one or more business processes.

Assigning business process types and business goals to organizational agents

An organizational agent, which is either an organization, an organizational unit or an organizational role player, can own business process types and can have business goals, which allow improving business processes by refactoring business process models, including resource allocation policies, and by changing the populations of resource pools, in such a way that the goals of the process owner (and those of its super-agents) are satisfied.

Consider the following example:

Example 9-1. Example from Modeling Business Goals with ArchiMate.

A business company has a Marketing department owning a Lead Generation process, a Business Development unit owning a Lead Qualification process, a Sales department owning a Sales process and a Customer Success department owning a Customer Success process. The company has the overall top-level goals "increase profit", "increase customer satisfaction", and "increase employee motivation".

Without the overall company goals in mind, each organizational unit is prone to optimize their subprocess without keeping an eye on the long-term implications:

Marketing maximizes lead output and ignores that most leads it generates won’t be qualifiable.
In its struggle to identify high-quality leads in a mass of low-quality lead data, Business development is overly eager to interpret leads as ‘qualified’, even if it is clear that many leads they forward to Sales can’t be turned into long-term customers.
Sales tries to close as many deals as possible, without considering churn and missed up-sell opportunities if the product can’t deliver on the promises made.
Customer success can’t do more than fight the fires of customer dissatisfaction.

This behavior is often encouraged by middle management that sets simple and easily quantifiable short-term performance goals for the team that reports to them, without keeping the big picture in mind.

There are different ways of expressing business goals. In simulation modeling, we need operational forms of business goals, that is, expressions in a formal language. We consider three forms of business goals:

Definite goals (like "raise the overall revenue by at least 25%") are defined by a logical condition (like relativeRevenueRise >= 0.25) that can be checked by a simulator.
Variable change goals are defined by a combination of one of the verbs "increase" or "decrease" with the name of a variable (like "profit", "customer satisfaction" or "costs").
Optimization goals are (more ambitious) special variable change goals defined by a combination of one of the verbs "maximize" or "minimize" with the name of a variable (like "profit", "customer satisfaction" or "costs").