Admin at 14:26, 12 January 2017

2017-01-12T14:26:54Z

Admin: Created page with "{{DISPLAYTITLE: The BPM Ontology}} == Introduction to the BPM Ontology == Many business process management (BPM) and/or process frameworks, methods, or approaches (e.g., Lean,..."

2017-01-12T14:17:09Z

Created page with "{{DISPLAYTITLE: The BPM Ontology}} == Introduction to the BPM Ontology == Many business process management (BPM) and/or process frameworks, methods, or approaches (e.g., Lean,..."

New page

{{DISPLAYTITLE: The BPM Ontology}}
== Introduction to the BPM Ontology ==
Many business process management (BPM) and/or process frameworks, methods, or approaches (e.g., Lean, Six Sigma, Business Process Reengineering (BPR), Total Quality Management (TQM), Zero Defect, Business Process Modeling Notation (BPMN), Business Process Execution Language (BPEL) have their own vocabulary. Each of these vocabularies has its own definition of terms, such as business process, process step, process activity, events, process role, process owner, process measure, and process rule.

This chapter introduces a BPM ontology that can be applied within the area of process modeling, process engineering, and process architecture. It provides fundamental process concepts that can be used to document corporate knowledge and structure process knowledge by defining relation process concepts (e.g., the order of process steps). The BPM ontology is presented as a shared vocabulary (i.e., folksonomy) that structures knowledge in two ways.

First, it allows practitioners to structure their business knowledge by adding meaningful relationships between the vocabulary terms. Second, it organizes concepts in hierarchic “is-a” relationships that allow a polymorphic inheritance of properties. The BPM ontology presented in this chapter should help to remedy the inconsistent use of these terms by providing benchmark terms and definitions and mapping those terms and definitions to the terms in the vocabularies of other existing frameworks. As these mappings demonstrate the shared use of terms in the BPM ontology and several business standards and reference frameworks, we could argue that the BPM ontology documents (i.e., externalizes) a tacit business folksonomy that was mainly shared through socialization before. Part of the BPM ontology presented here is an explicit business folksonomy that is supported by a wide community of practitioners and academics.

=== The BPM Ontology as a Folksonomy: Sharing Fundamental Process Concepts ===
All ontologies have a controlled vocabulary as a foundation. Because the BPM ontology is an extensive ontology that has the ambition to cover all aspects of business (as opposed to academic ontologies), its terms are organized in a top-level domain and multiple intersecting subdomains. The top-level ontology is kept relatively simple, consisting of four main terms: object, meta-object, object group, and object meta-model. Objects refer to something that is within the grasp of the senses and that which a subject relates to. They represent a piece of reality in a model or a document.

Meta-objects create, describe, or equip objects. A meta-object defines an object’s type, relation attributes, functions, control structures, etc. Object groups serve to group objects with a common purpose, goal, aim, target, objective, and sets. In the BPM ontology, object groups collect meta-objects related to a subdomain. Object meta-models are precise definitions of meta-objects, the semantics of the relationships they are involved in, and the rules that apply to them. BPM ontology terms are assembled into two groups: composition and decomposition (meta-objects). The decomposition meta-objects are presented in Table 1 and allow modelers to structure processes.

{| class="wikitable" style="text-align: left; width: 100%;"
|-
| style="width: 20%; background: #1f992d; color: #ffffff;" | '''Process Object'''
| style="width: 80%; background: #1f992d; color: #ffffff;" | '''Description'''
|-
| style="background: #f0f0f0;" | Process area (categorization)
| The highest level of an abstract categorization of processes.
|-
| style="background: #f0f0f0;" | Process group (categorization)
| A categorization and collection of processes into common groups.
|-
| style="background: #f0f0f0;" | Business process
| A set of structured activities or tasks with logical behaviors that produce a specific service or product.
|-
| style="background: #f0f0f0;" | Process step
| A conceptual set of behaviors bound by the scope of a process that, each time it is executed, leads to a single change of inputs (form or state) into a single specified output. Each process step is a unit of work normally performed within the constraints of a set of rules by one or more actors in a role, which are engaged in changing the state of one or more resources or enterprise objects to create a single desired output.
|-
| style="background: #f0f0f0;" | Process activity
| A part of the actual physical work system that specifies how to complete the change in the form or state of an input, oversee, or even achieve the completion of an interaction with others actors and which results in the making of a complex decision based on knowledge, judgment, experience, and instinct.
|-
| style="background: #f0f0f0;" | Event
| A state change that recognizes the triggering or termination of processing.
|-
| style="background: #f0f0f0;" | Gateway
| Determines the forking and merging of paths, depending on the conditions expressed.
|-
| style="background: #f0f0f0;" | Process rule
| A statement that defines or constrains some aspect of work and always resolves to either true or false.
|-
| style="background: #f0f0f0;" | Process measurement (process performance indicator)
| The basis by which the enterprise evaluates or estimates the nature, quality, ability, and extent as to whether a process or activity is performing as desired.
|-
| style="background: #f0f0f0;" | Process owner
| A role performed by an actor with the fitting rights, competencies, and capabilities to take decisions to ensure work is performed.
|-
| style="background: #f0f0f0;" | Process flow (including input/output)
| A stream, sequence, course, succession, series, or progression, all based on the process input/output states, where each process input/output defines the process flow that together executes a behavior.
|-
| style="background: #f0f0f0;" | Process role
| A specific and prescribed set of expected behavior and rights (authority to act) that is meant to enable its holder to successfully carry out his or her responsibilities in the performance of work. Each role represents a set of allowable actions within the organization in terms of the rights that are required for the enterprise to operate.
|}

Table 1: Decomposed process meta-objects.

Categorizations assemble heterogeneous groups, whereas classifications assemble objects into order (e.g., through the use of strict part-whole or sequencing semantics). For example, a process area can cluster otherwise independent processes; process steps need to follow each other. The decomposed process meta-objects listed in Table 1 can be used in process architecture and process engineering, as they allow for process decomposition.

These fundamental concepts can be combined with auxiliary concepts to produce the semantic richness needed by practitioners. These auxiliary concepts are called process composition meta-objects and represent various process aspects such as strategy, goals, critical success factors, performance indicators, reporting, services, applications, and/or data. Together, process composition and decomposition meta-objects provide a structuring mechanism that facilitates the developments of corporate ontologies (e.g., combining the decomposition metaobject
process step with the decomposition meta-object risk invites practitioners to think about the risks of each process step they identify).

The composition meta-objects, which are shown in Table 2, intersect with several subdomains of business (e.g., process, strategy). Consequently, they can be reused for the elicitation of risks, costs, and other aspects of business in several subdomains of business next to processes. In addition to the decomposed process meta-objects, other meta-objects relate to the concept of process modeling. The related meta-objects are called composed process meta-objects and are considered an essential part for any practitioner working with and around innovation and transformation across various relevant subjects (vs siloed process modeling, engineering and architecture view). The additional related meta-objects fundamental to the various process concepts shown in Table 2.

{| class="wikitable" style="text-align: left; width: 100%;"
|-
| style="width: 20%; background: #1f992d; color: #ffffff;" | '''Meta-Object'''
| style="width: 80%; background: #1f992d; color: #ffffff;" | '''Composed Process Meta-Object Description'''
|-
| style="background: #f0f0f0;" | Goal (e.g., business, application, technology)
| A desired result considered a part of the organizational direction, aims, targets, and aspirations.
|-
| style="background: #f0f0f0;" | Objective (critical success factor)
| Time-bounded milestones to measure and gauge the progress towards a strategy or goal.
|-
| style="background: #f0f0f0;" | Value indicator (critical success factor)
| Any of a series of metrics used by an enterprise, to indicate its overall ability to achieve its mission.
|-
| style="background: #f0f0f0;" | Performance indicator
| Any of a series of metrics used by an enterprise, to indicate its overall success or the success of a particular area in which it is engaged.
|-
| style="background: #f0f0f0;" | Performance expectation
| The manner in which, or the efficiency with which, something reacts or fulfills its intended purpose as anticipated by a specific stakeholder.
|-
| style="background: #f0f0f0;" | Performance driver
| Those variables that are critical to develop the means and overall performance of an enterprise.
|-
| style="background: #f0f0f0;" | Quality
| A state of excellence or worth, specifying the essential and distinguishing individual nature and the attributes based on the intended use.
|-
| style="background: #f0f0f0;" | Risk
| The combined impact of any condition or event, including those caused by uncertainty, change, hazards, or other factors that can affect the potential for achieving these objectives.
|-
| style="background: #f0f0f0;" | Security
| The objects or tools that secure, make safe, and protect through measures that prevent exposure to danger or risk.
|-
| style="background: #f0f0f0;" | Business measure
| Any type of measurement used to gauge some quantifiable component of an enterprise’s performance.
|-
| style="background: #f0f0f0;" | Report
| The exposure, description, and portrayal of information, about the status, direction, or execution of work within the functions, services, processes, and resources of the enterprise.
|-
| style="background: #f0f0f0;" | Timing
| A plan, schedule, or arrangement when something should happen or be done or to take place.
|-
| style="background: #f0f0f0;" | Business area
| The highest level meaningful grouping of the activities of the enterprise.
|-
| style="background: #f0f0f0;" | Business group
| An aggregation within an enterprise, which is within an enterprise area.
|-
| style="background: #f0f0f0;" | Business competency
| An integrated and holistic set of related knowledge, skills, and abilities, related to a specific set of resources (including persons and organizations) that combined enable the enterprise to act in a particular situation.
|-
| style="background: #f0f0f0;" | Business resource/actor
| A specific person, system, or organization that initiates or interacts with the defined functions and activities. Actors may be internal or external to an organization.
|-
| style="background: #f0f0f0;" | Business role
| A part that someone or something has in a particular defined function, activity, or situation. A resource/actor may have a number of roles.
|-
| style="background: #f0f0f0;" | Business function
| A cluster of tasks creating a specific class of jobs.
|-
| style="background: #f0f0f0;" | Business owner
| A role performed by an actor with the rights, rules, competencies, and capabilities to take decisions for the part of enterprise for which stewardship responsibilities have been assigned.
|-
| style="background: #f0f0f0;" | Cost
| An amount that has to be paid or given up to obtain the use or access to something.
|-
| style="background: #f0f0f0;" | Revenue
| The realized income of an enterprise or part thereof.
|-
| style="background: #f0f0f0;" | Object (business and information)
| A real-world thing of use by or which exists within the enterprise and information objects reveal only their interface, which consists of a set of clearly defined relations. In the context of the business competency, the relevant objects are only those which relate to the enterprise’s means to act.
|-
| style="background: #f0f0f0;" | Product
| A result and output generated by the enterprise. It has a combination of tangible and intangible attributes (features, functions, usage).
|-
| style="background: #f0f0f0;" | Contract
| An agreement between two or more parties that establishes conditions for interaction.
|-
| style="background: #f0f0f0;" | Business rule
| A statement that defines or constrains some aspect of behavior within the enterprise and always resolves to either true or false.
|-
| style="background: #f0f0f0;" | Business compliance
| The process or tools for verifying adherence to rules and decisions.
|-
| style="background: #f0f0f0;" | Location
| A facility, place, or geographic position.
|-
| style="background: #f0f0f0;" | Business channel
| A means of access or otherwise interacting within an enterprise or between an enterprise and its external partners (customers, vendors, suppliers, etc.).
|-
| style="background: #f0f0f0;" | Business workflow
| A stream, sequence, course, succession, series, and progression as well as order for the movement of information or material from one enterprise function, enterprise service, or enterprise activity (worksite) to another.
|-
| style="background: #f0f0f0;" | Business service
| The externally visible (“logical”) deed or effort performed to satisfy a need or to fulfill a demand, meaningful to the environment.
|-
| style="background: #f0f0f0;" | Service flow (including output/input)
| A set of one or more service input output states, where each service state defines a step in the service flow that, when entered, executes a behavior.
|-
| style="background: #f0f0f0;" | Service measurement (Service Performance Indicator (SPI) and Service Level Agreement (SLA))
| The basis by which the enterprise evaluates or estimates the nature, quality, ability, or extent of the services. The commitments of a business service are assessed.
|-
| style="background: #f0f0f0;" | Logical application component
| An encapsulation of application functionality that is independent of a particular implementation.
|-
| style="background: #f0f0f0;" | Physical application component
| A deployable part of a software product, providing identifiable functions and existing within a specific version of the product.
|-
| style="background: #f0f0f0;" | Application function
| The specification of a significant aspect of the internal behavior of the application, which acts as a broader description of a set of application features.
|-
| style="background: #f0f0f0;" | Application task
| The automated behavior of a process activity performed by an application.
|-
| style="background: #f0f0f0;" | Application service
| An externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment.
|-
| style="background: #f0f0f0;" | Application/system flow
| The specification of the sequence in which two application tasks processes (or an application task and an application event or gateway) are executed, one of which provides an output, which is an input to the other.
|-
| style="background: #f0f0f0;" | System measurement
| Measures that are defined and implementable within an application.
|-
| style="background: #f0f0f0;" | Application/system report
| Reports that are defined and implementable or implemented within or by an application.
|-
| style="background: #f0f0f0;" | Application roles
| A role performed by an actor with the rights, competencies, and capabilities to take decisions about an application, its behavior, and properties.
|-
| style="background: #f0f0f0;" | Application rule
| A business rule implemented within and able to be executed by an application.
|-
| style="background: #f0f0f0;" | Data object
| A logical cluster of all sets of related data representing an object view of a business object.
|-
| style="background: #f0f0f0;" | Data table
| A physical specification of the means of arranging data in rows and columns while being stored in physically persistence structures.
|-
| style="background: #f0f0f0;" | Data flow
| The specification of the sequence in which data moves from one state to another.
|-
| style="background: #f0f0f0;" | Data owner
| A role performed by an actor with the rights, competencies, and capabilities to take decisions about the aspects of data for which stewardship responsibilities have been assigned.
|-
| style="background: #f0f0f0;" | Data rule
| Criteria used in the process of determining or verifying values of data or generalizing certain features of data.
|-
| style="background: #f0f0f0;" | Platform device
| A set of platform components configured to act as a modular part of a platform.
|}

Table 2: Process composition meta-objects.

'''Document''': [[Media:The Value of Ontology.pdf|Download the Value of Ontology document]]

[[Category: Business Ontology]]

LEAD Reference Content:The Value of Ontology - Revision history

Admin at 14:26, 12 January 2017

Admin: Created page with "{{DISPLAYTITLE: The BPM Ontology}} == Introduction to the BPM Ontology == Many business process management (BPM) and/or process frameworks, methods, or approaches (e.g., Lean,..."