Modos de unión de los ligandos

Organizational perspective represents by whom (roles and organizational units) activities are performed. We depict it in Fig. 3.2 by a grouping under the label of stakeholders, encompassing organizational units, roles and process owners.

Resource perspective describes applications and resources that should be spent when carrying out certain process activities (e.g. objects, IT systems, or media needed in order to accomplish the activity) or that may be results of certain activities (see Fig. 3.2).

Compliance perspective represents compliance requirements within process models. The source of these requirements may be external (laws and regulations) or internal company policies and guidelines. In either case, this is a process aspect which can and should be modeled separately.

Behavioral perspective captures process control flow. It represents the logical ordering of process activities and their causal interrelationships. This perspective could be seen as the core of a process representation and acts as a connection point [Wes07] for the other perspectives (see Fig. 3.2).

We can think of the business process model knowledge depicted in Fig. 3.1 as being present on each business process level introduced in Section 2.1 in smaller or greater detail. In the next section we will investigate the mapping of this knowledge to individual process abstraction levels.

3.2.3 Abstraction Levels in Process Modeling

The analysis of process models from the SAP business process repository has shown that the abstraction levels in Fig. 2.2 are not investigated in sufficient detail. Based on this analysis, we now illustrate the types of artifacts usually created on each abstraction level and discuss how different modeling abstraction levels relate to the process knowledge in Fig. 3.1.

The modeling artifacts from the BPR created on different process modeling ab-straction levels can be visualized using a pyramid-like structure, as shown in Fig.

3.3. Business motivation forms the top most layer of the pyramid. It models the various driving forces (i.e. goals, strategies, metrics, etc.) of the enterprise and the relationships between them (cf. top left of Fig. 3.3). The business motivation model is then structured along the industry-specific value chain. The value chain is composed of a sequence of value-creating functional areas - so called value chain elements. The top right of Fig. 3.3 shows the telecommunication industry value chain with its value chain elements. Business scenario group is a collection of busi-ness scenarios with the same busibusi-ness goals. A busibusi-ness scenario group can span across several functional areas (cf. center of Fig. 3.3) and sometimes even integrated with consumers and suppliers delimitating a value chain. Business scenario is a set of logically related business processes performed to achieve defined and measurable business objectives. Each business scenario is associated with a set of metrics (key

3.2 Understanding Conceptual Process Models 37

Figure 3.2: Process perspectives

performance indicators) which serve as efficiency benchmarks. Example KPIs are shown for the Lead and Opportunity Management scenario in the center right of Fig. 3.3.

Business process is a set of operations within a business scenario. All business processes follow a well defined flow in order to achieve the business objectives of its scenario. Business process activity represents an operation of a business process that performs a defined function. The bottom right part of Fig. 3.3 shows the pro-cess activities of the Lead Propro-cessing propro-cess. All business propro-cess activities are connected in a business logical flow in order to fulfill the purpose of the business process.

Business Process Frameworks³, which are becoming popular in companies, also contain similar types of modeling artifacts. They provide a common language, set of high level processes and its associated metrics which one can use as a template to quickly and easily define new processes or evaluate and improve existing pro-cesses based on the provided metrics. Some of the best known examples are Supply Chain Council’s SCOR (Supply Chain Operation Reference model)⁴, TeleManage-ment Forum’s eTOM framework⁵and the Value Chain Group’s VRM (Value Refer-ence Model)⁶.

Based on the aforementioned types of modeling artifacts, we revisit the defini-tion of process modeling abstracdefini-tion levels and seek to establish their reladefini-tion to process knowledge in Fig. 3.1. We define three modeling abstraction levels as fol-lows:

Executive (strategic) level. Here the enterprise goals and the general strategic direction are set. Key performance indicators are determined for measuring the progress in achieving goals. Business policies are defined in order to govern the enterprise courses of action. Typical artifacts on this level may include goal specifi-cations, strategy documents and policy guidelines (cf. Fig. 3.4, left). Artifacts on this level of abstraction provide the motivation (“why”) for the processes within the or-ganization, which are defined on further levels. The modeling techniques are rather informal or ad-hoc (plain text, flip chart techniques or mind maps).

Line of business manager level. Based on the artifacts produced at the executive level, line of business managers need to provide quick and intuitive overview of the business processes of an organization. The aim is to depict processes from a high-level perspective with a focus on understanding key points of the process. These high-level processes are called business scenarios and each of them represents a set of logically related processes performed to achieve defined and measurable business goals. Models such as Value Added Chain Diagrams [Por85] and SAP Business Scenarios⁷are used for this purpose.

Business analyst level. Unlike the other two perspectives, the business analyst faces a variety of purposes in modeling. This includes business process documenta-tion, process improvement, system requirements specificadocumenta-tion, etc. Process models created at this level detail each of the business scenarios specified and serve as a

3http://www.bptrends.com/publicationfiles/spotlight_052008.pdf

4http://www.supply-chain.org/cs/root/scor_tools_resources/scor_model/

scor_model

5http://www.tmforum.org/BusinessProcessFramework/1647/home.html

6http://www.value-chain.org/en/cms/1960/

7SAP Business Scenarios are delivered with the SAP Solution Composer, a modeling tool provided by SAP. http://www.sap.com/solutions/businessmaps/composer/index.epx

3.2 Understanding Conceptual Process Models 39

Figure 3.3: Processes at different levels of abstraction

starting point for the underlying information system implementation (cf. Fig. 3.4, right). There are numerous modeling techniques (EPC [KNS92], BPMN⁸, UML Ac-tivity Diagrams [Obj07]) used in this space.

We can think of the process knowledge depicted in Fig. 3.1 as being present on each level of abstraction in smaller or greater detail. Parts of this knowledge tend to grow stronger as we move down the abstraction levels, e.g. process flow.

Of course, high level knowledge such as strategic goals and core strategy plans do not vanish as we reach a level of higher detail. Rather, they get refined and super-imposed by a more concrete view. Strategic goals grow to measurable and timed operational goals, strategic directions to detailed plans, etc. For example, the ex-ecutive abstraction level strongly encompasses concepts related to the motivational perspective (goals, strategy, KPIs, etc.), while it is not interested in detailed process flow, information systems supporting the process or business objects (cf. Fig. 3.4, left).

In order to enable semantic analysis, querying and verification of business pro-cess models, there is a need for a comprehensive formal propro-cess description captur-ing all relevant process knowledge. In the next section, we show how we fulfill this need.