OCEB2BI

From Training Material
Jump to navigation Jump to search


<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="false" font="Trebuchet MS" >

title
OMG Certified Expert in BPM 2 - Business Intermediate Exam Preparation
author

Filip Stachecki (Filip@NobleProg.pl) and Bernard Szlachta bs@nobleprog.pl

</slideshow>

Table of contents⌘

Module 0. Introduction 3
Module 1. Intermediate Business Motivational Modeling 13
Module 2. Business Process Modeling with BPMN 48
Module 3. Decision Management and Modeling with DMN 111
Module 4. Business Rules Approach and Shared Business-Wide Vocabulary 152
Module 5. Business Process Management Knowledge and Skills 180
Module 6. Process Quality and Governance Frameworks 233

Module 0. Introduction⌘

Object Management Group⌘

The Object Management Group (OMG) is an international, open membership, not-for-profit computer industry standards consortium.

The most important OMG standards:

  • UML (Unified Modeling Language)
  • BPMN (Business Process Model and Notation)
  • SysML (Systems Modeling Language)

OMG Certified Expert in BPM 2 (OCEB2)⌘

  • Certification program based on BPM
  • The OCEB 2 examinations cover much more than BPMN
  • To obtain a higher certificate you have to pass the lower test level

OMG Content Developer⌘

NobleProg has official OMG OCEB 2 and OCUP 2 Content Developer status, which means that our course outlines and training materials were developed by the same experts who prepared questions for both certifications.

Two people from NobleProg team take an active part in the work of OMG, which deals with determining the subjects of OCEB 2 and OCUP 2 examinations and creating test questions.

OCEB 2 Tracks and Levels⌘

OCEB2Paths.png

  • Above the Fundamental level, the OCEB2 program splits into a Business Track and a Technical Track with an Intermediate and Advanced level in each.

OCEB 2 Business Intermediate⌘

  • Covers basic elements of Business Essentials and Business Modeling, Business Process, Business Process Management, Business Process Modeling, and essential and widely-used industry frameworks.
Examination Number: OMG-OCEB2-BUSINT200
Duration:  105 minutes for residents of English-speaking countries; 135 minutes for all others
Number of Questions: 90
Minimum Passing Score: 59
Exam Fee: US $210 (or equivalent in local currency)
Prerequisite: Passing score on OCEB-2 Fundamental Exam

OCEB2 Business Intermediate - Coverage Table⌘

Intermediate Business Motivational Modeling10%
Business Process Modeling with BPMN35%
Decision Management and Modeling with DMN10%
Business Rules Approach and Shared Business-Wide Vocabulary10%
Business Process Management Knowledge and Skills20%
Process Quality and Governance Frameworks15%

OCEB 2 Business Intermediate - Reference List⌘

http://www.omg.org/oceb-2/coveragemap-bus-inter.htm

OMG Certified Professionals Directory⌘

http://www.omg.org/cgi-bin/searchcert.cgi

Pearson VUE⌘

  • The OCEB2 examinations are offered worldwide in English at Pearson VUE testing centers.
  • You need to show two valid forms of personal ID, both must have your signature, and one of the two must have your photo.
  • The test room is monitored electronically by video, or personally by a test assistant.
  • At the end of the test, the candidates can see their results on their screens.
  • Candidates will be given a printout of their test results by the test center.
  • Successful candidates will receive a colored official certificate by mail several weeks later.

Module 1. Intermediate
Business Motivational Modeling⌘

References⌘

  • Business Motivation Model Specification, V 1.1
  • John Hall, Overview of OMG Business Motivation Model: Core Concepts.

Business Motivational Model⌘

  • The Business Motivation Model is neutral with respect to methodology.
  • Organized business plans should be a fundamental deliverable.
  • The Ends, Means, and Influencers are related to each other in order to answer the following two fundamental questions:
  1. What is needed to achieve what the enterprise wishes to achieve?
    This question is answered by laying out the particular elements of the business plans — in other words, the Means necessary to achieve the desired Ends.
  2. Why does each element of the business plan exist?
    This question is answered by identifying the particular Ends that each of the Means serves, and the Influencers that underlie the choices made in this regard. This is what is meant by motivation.

BMM elements⌘

John Hall, Overview of OMG Business Motivation Model: Core Concepts

Ends⌘

Ends define what an enterprise wants to be – the states it desires to be in. There are three levels:

  • Vision (optional): an easily-understood summary of what the enterprise considers itself to be, or aspires to be. All objectives and goals should support (or, at least, not contradict) the vision.
  • Desired Results:
    • Goal: an enterprise state or condition to be maintained or approached in the medium to long term, e.g. “To be one of the top three suppliers (by turnover) in our market”.
    • Objective: a measurable, time-targeted step towards one or more goals, e.g. “To increase year-on-year turnover by 2% in the current financial year”. Required or expected values of key performance indicators are recorded as objectives.

Means⌘

Means define what an enterprise has decided to do to achieve its ends. There are three kinds:

  • Mission (optional): the enterprise’s primary activity. How it is carried out is defined in its courses of action.
  • Course of Action: defines what the enterprise will do in support of one or more of its goals. There are two kinds:
    • Strategy: a major part of the plan to accomplish the mission, usually long-term and with a significant impact on how the business operates
    • Tactic: a course of action that supports one or more strategies - narrower in scope than a strategy and may be short-term.
  • Directive: governs what courses of action can and should be adopted, and how they must or may be realized:
    • Business policy: a broad directive that needs further interpretation (in business rules) in order to be put into practice
    • Business rule: reference to a rule in the operational business. Business rules make business policies practicable, and guide business processes.

Directives⌘

  • Represent encoded (i.e., written down) knowledge that ensures the highest possible chances of success for the Courses of Action
  • A Directive always has to do with governance or guidance
  • A CoA, in contrast, identifies an active approach in moving toward the Ends
  • A CoA is always action-dominated (action-oriented)
BMM Directive⌘
  • Directives indicate how the Course of Action should, or should not be carried out – in other words, they govern Course of Action.
  • Specifically, a Directive defines or constrains or liberates some aspect of an enterprise.
  • It is intended to assert business structure or to control or influence the behaviour of the business, and is stated in declarative form.
Directive Diagram⌘

“Governs” relationship⌘
  • Directives govern Courses of Action
    • e.g. the Business Rule "Pizzas may not be delivered beyond a radius of 30 miles" governs the Strategy "Deliver pizzas to the location of the customer's choice."
  • This governance applies to Tactics as well
    • e.g. the Tactic "Encourage rental extensions" is governed by the Business Policy "Allow extension of rentals by phone."
Business Policy vs. Business Rule⌘
  • Business Rule is highly structured and is carefully expressed in terms of standard vocabulary
  • Business Rule should be discrete and atomic — that is, represent only a single aspect of governance or guidance
  • Business Rule is a single Directive that does not require additional interpretation.
  • Business Policy tends to be less structured, less discrete, and usually not atomic — that is, not focused on a single aspect of governance or guidance
  • Business Policy tends to be less compliant with standard business vocabulary, and less formally articulated
Business Policy vs. Business Rule⌘
  • Business Rule is derived from business policy, Business Policy is basis for business rule.
  • Business Policies provide broader governance or guidance that is not directly practicable.
  • Business Rules provide specific, practicable governance or guidance to implement Business Policies
  • 'Practicable' means that a person who understands a Business Rule could observe a relevant situation (including his or her own behaviour) and decide directly whether or not the business was complying with the rule
Business Rule Enforcement Level⌘
  • A Business Rule has an enforcement level.
  • Enforcement levels represent alternatives in a graded or ordered scale, each of which indicates the severity of action imposed to put or keep a rule in force
  • Deciding what enforcement level is to be applied to a Business Rule is often a Tactic within business plans
  • In the Model, Tactic effects enforcement level of Business Rule
Enforcement Levels⌘

Enforcement Levels Examples⌘


Directive as Regulation⌘
  • Regulation is an official rule prescribed by an authority such as government body or the management of an enterprise.
  • A Directive may act as some other Organization Unit's Regulation
  • The Business Rules and Business Policies determined at one level in an organization may be effectively the law (Regulation) for lower-level organizations.
Directive as Regulation Example⌘
  • Production and sales divisions both have to comply with company policy on safety at work
  • These units in turn have to determine their own local policies and rules for their particular compliance with the 'law' (company policy) imposed from above.
  • Furthermore, the rules and policies they come up with will most likely be unique; rules for safety within the production division are different from those in sales.

Influencers on the Ends and Means⌘

  • An Influencer can be anything that has the capability to ‘produce an effect without apparent exertion of tangible force or direct exercise of command, and often without deliberate effort or intent.’
  • Influencers are always neutral
  • Influencers must be assessed to determine implications for business plans

Categories of Influencers⌘

BMM categorizes influencers for analysis of the kinds of changes and resulting assessments and decisions

It provides:

  • Two broad Influencer Categories: External and Internal
  • A set of general categories

It suggests that each Influencer is categorized as (at least) one of the general categories and as either internal or external

Influencers Categories⌘

Internal/External

external influencer

internal influencer

competitor

customer

environment

partner

regulation

supplier

technology

assumption

corporate value

habit

infrastructure

issue

management prerogative

resource

External Influencers⌘


Internal Influencers⌘


Assessments⌘

  • When an influencer causes a significant change, the enterprise makes an assessment of its impact, identifying risks and potential rewards.
  • There may be multiple assessments, perhaps from different stakeholders.
  • Assessments are supported by whatever business intelligence and risk analysis systems the enterprise has.

Assessments⌘

Concepts for Assessments of Influencers on Ends and/or Means

Externally-referenced Business Model Elements⌘

Externally-referenced Business Model Elements⌘

  • Four concepts: Asset, Organization Unit, Business Process, and Business Rule have roles in the structure of the Business Motivation Model but actually belong in other standards where they are defined

Organization Unit⌘

Organization Unit has two roles:

  • As a concept in the Business Motivation Model it:
    • defines Ends,
    • establishes Means,
    • makes Assessments,
    • recognizes Influencers,
    • may be defined by a Strategy,
    • may be responsible for Business Processes.
  • It is usually the basis for defining the boundaries of the enterprise being modeled.
    The decomposition of Business Policies, Courses of Action, and Desired Results and assignment of responsibilities within the enterprise is often guided by the definition of units within the organization structure.
Organization Unit diagram⌘

Business Process⌘

Business Process

  • realizes Courses of Action (provide processing steps, sequences, structure, and connection to events that trigger the processes)
  • is governed by Business Policies (like CoA),
  • may be guided by Business Rules,
  • is the responsibility of one or more Organization Units.

How BP relate to Goal and Objective⌘

Asset and Liability⌘

Asset⌘

  • “Asset” in BMM is NOT used in the sense of accounting (economic value owned by a company that may be converted into cash)
  • Assets are ‘things’ that are used in operating the enterprise
  • In BMM they have an operational perspective i.e. refer to the real things in the business - the actual equipment, buildings, and stocks of materials rather monetary values in accounting
  • They are represented in the Model as Assets, of two kinds:
    • Fixed Assets: things that are kept long-term, maintained, reused (tangible - equipment and buildings, or intangible - patents and licenses)
    • Resources: things that are consumed and replenished, such as raw materials, parts, finished goods, and cash.

Asset and Offering⌘

  • Asset, Resource, and Fixed Asset are only placeholders – defined outside its BMM
  • Only those that are relevant to governance decisions need be included.
  • There is no requirement for a coherent, complete structure of Assets within a BMM
  • Asset that is often explicitly referenced is the enterprise’s products and services, called “Offering” in the Model.
  • An Offering is a specification of a product or service - an intangible Fixed Asset.
  • Instances of Offering, such as quantities of finished goods, would be a Resource.

Liability⌘

  • As well as Assets, enterprises also need to consider Liabilities - again, not in an accounting sense (company's obligations arising from its normal operations).
  • A Liability is a reservation of Resource(s) to meet commitments, such as materials needed to fulfill a contract, or cash to pay taxes.

Module 1. Questions⌘

  • What is the difference between Business Process and Course of Action?
  • According to BMM, what is the connection between Business Process and Goal?
  • List 3 internal and 3 external influencers categories.
  • What are three referenced elements of business model defined externally?

Module 2. Business Process Modeling with
BPMN⌘

References⌘

  • Business Process Model and Notation (BPMN), V2.0
  • Debevoise, Execution Semantics: Moving BPMN to Execution, White Paper.
  • Kurz, Menge, and Misiak, Diagram Interchangeability in BPMN 2, White Paper.

Language Elements⌘

Data Modeling⌘

  • Data modeling is used to describe physical or information items that are created, manipulated, and used during the execution of a Process.
  • Data can be modeled using: Data Objects, Data Inputs, Data Outputs, Data Stores, Data Associations, ....
Data Objects⌘

  • The primary construct for modeling data within the Process flow.
  • Data Associations are used to move data between Data Objects.
  • Tokens do not flow along a Data Association.
Data Object - collection⌘
Data Object - Lifecycle and Accessibility⌘
  • Lifecycle of a Data Object is tied to the lifecycle of its parent Process or Sub-Process.
  • When a Process or Sub-Process is instantiated, all Data Objects contained within it are also instantiated.
  • When a Process or Sub-Process instance is disposed, all Data Object instances contained within it are also disposed. At this point the data within these instances are no longer available.
  • Accessibility of a Data Object is driven by its lifecycle.
  • The data within a Data Object can only be accessed when there is guaranteed to be a live Data Object instance present.
  • Data Object can only be accessed by its immediate parent (Process or Sub-Process), or by its sibling Flow Elements and their children
Lifecycle and Accessibility Example 1⌘

Lifecycle and Accessibility Example 2⌘

Data Input, Data Output⌘

  • Activities and Processes often need data in order to execute.
  • In addition they can produce data during or as a result of execution.
  • Data requirements are captured as Data Inputs.
  • Data that is produced is captured using Data Outputs
Data Store⌘

  • A DataStore provides a mechanism for Activities to get or update stored information that will persist beyond the scope of the Process.
  • Represents a single unit of information (e.g. database record)

Global Task and Global Process⌘

  • A Global Task is a reusable, atomic Task definition that can be called from within any Process by a Call Activity.
  • A Global Task is not defined within a Process, but is callable element.
  • The types of Global Tasks are only a subset of standard Tasks types: GlobalUserTask, GlobalManualTask, GlobalScriptTask, and GlobalBusinessRuleTask
  • A Global Process can be called from another Process.
    • Question: Do you know any example of non-global process?
Call Activity⌘
  • A Call Activity is a type of Activity that identifies a point in the Process where a global Process or a Global Task is used.

Events: Escalation, Compensation⌘

Escalation⌘

  • An Escalation identifies a business situation that a Process might need to react to.
  • In contrast to an Error, an Escalation by default is assumed to not abort the Activity to which the boundary Event is attached.
Escalation Example⌘

Compensation⌘

  • Compensation is undoing steps that were already successfully completed, because their results and possibly side effects are no longer desired and need to be reversed.
  • If an Activity is still active, it cannot be compensated, but rather needs to be canceled.
  • Compensation is not an error handling
  • A compensation handler performs the steps necessary to reverse the effects of an Activity.
Compensation handler⌘

  • A compensation handler connected via a boundary Event can only perform “black-box” compensation of the original Activity.
  • Compensation Activity is connected to the boundary Event through an Association.
  • The Compensation Activity can be either a Task or a Sub-Process, has a marker to show that it is used for compensation only and is outside the normal flow of the Process.
Event Sub-Processes⌘

  • Event Sub-Processes allow to handle an Event within the context of a given Sub-Processes or Process.
  • An Event Sub-Process always begins with a Start Event, followed by Sequence Flows.
  • Event Sub-Processes are a special kind of Sub-Process: they create a scope and are instantiated like a Sub-Process, but they are not instantiated by normal control flow but only when the associated Start Event is triggered.
Event Sub-Processes⌘
  • Event Sub-Processes are self-contained and MUST not be connected to the rest of the Sequence Flows in the Sub-Processes; also they cannot have attached boundary Events.
  • They run in the context of the Sub-Process, and thus have access to its context.
  • An Event Sub-Process cancels execution of the enclosing Sub-Process, if the isInterrupting attribute of its Start Event is set. If the isInterrupting attribute is not set, execution of the enclosing Sub-Process continues in parallel to the Event Sub-Process.
Compensation Using Event Sub-Process⌘

A Compensation Event Sub-Process can: access data that is part of its parent, recursively trigger compensation for Activities contained in its parent, contain compensation start event.

Complex Gateway⌘

  • The Complex Gateway can be used to model complex synchronization behavior
  • For example, it could specify that tokens on three out of five incoming Sequence Flows are needed to activate the Gateway.

Complex Gateway Attributes⌘
  • activationCondition: Expression
    Determines which combination of incoming tokens will be synchronized for activation of the Gateway.
  • activationCount: integer
    Refers at runtime to the number of tokens that are present on an incoming Sequence Flow of the Complex Gateway.
  • waitingForStart: boolean = true
    Represents the internal state of the Complex Gateway. It is either waiting for start (=true) or waiting for reset (=false).
Complex Gateway Example⌘
Questions:

1. What kind of behavior is used for a complex gateway (AND, OR, XOR)?
2. What is the activation condition here?
3. When is waitingForStart value changed to false?
4. What happens if no outgoing condition evaluates to true?
5. What happens if the activation condition never becomes true?
6. What does the activation count describe?


Advanced BPMN Usage⌘

Different types of loops⌘

  • Activities may be repeated sequentially, behaving like a loop (Standard Loop Characteristics)
  • Desired number of Activity instances that may execute in parallel or may be sequential can be specified. (Multi-Instance Characteristics)
Standard Loop ⌘

  • The Activity will loop as long as the boolean loopCondition is true
  • The condition is evaluated for every loop iteration, and MAY be evaluated at the beginning or at the end of the iteration (testBefore = true lub testBefore = false)
  • In addition, a numeric cap can be optionally specified - loopMaximum
  • Loop activity instances are sequentially executed - one after another.
  • Loop Activity is similar to DO WHILE loop.

QUESTION: How many times can looping task be executed?

Multi-Instance Activity⌘

Multi-Instance parallel

Multi-Instance sequential

  • The instances MAY execute in parallel or MAY be sequential.
  • Multi-Instance Activites are used with collection of items
  • Multi-Instance Activity is similar to FOR EACH loop
Multi-Instance Activity Example⌘

Multi-Instance Loop core attributes⌘

isSequential: boolean = false

This attribute is a flag that controls whether the Activity instances will execute sequentially or in parallel.

completionCondition: Expression [0..1]

This attribute defines a boolean Expression that when evaluated to true, cancels the remaining Activity instances and produces a token.

loopCardinality: Expression [0..1]

A numeric Expression that controls the number of Activity instances that will be created

Basic error handling⌘

  • An Error is generated when there is a critical problem in the processing of an Activity or when the execution of an Operation failed
Error Example 1⌘

Error Example 2⌘

Error and Compensation⌘

When is "Restore delegate name" activity executed?

Conversations⌘

Conversations⌘

  • Conversation diagram it is a particular usage of a Collaboration diagram.
  • A Conversation is a logical grouping of Message exchanges that can share a Correlation (a business object of interest, e.g, “Order,” “Shipment and Delivery,” and “Invoice”)
  • Processes can appear within the Participants (Pools) of Conversation diagrams, to show how Conversation and Activities are related.
Conversation elements⌘

Conversation Example 1⌘

Conversation Example 2⌘

Choreography⌘

Choreography⌘

  • A Choreography defines the sequence of interactions between Participants (Pools).
  • Choreographies exist outside of or in between Pools.
  • Choreography does not exist in a single Pool. Each step in the Choreography involves two or more Participants.
  • A Choreography can't be directly executed.
  • A Choreography does not have a central control mechanism.
Choreography Example 1⌘

Choreography Task⌘

  • A Choreography Task is an atomic Activity in a Choreography Process.
  • It represents an Interaction, which is one or two Message exchanges between two Participants.
Choreography Task with a Message⌘

Two-way Choreography Task⌘

Sequence Flow⌘

Gateways⌘
  • Interactions between Participants can happen in sequence, in parallel, or through exclusive selection.
  • Exclusive, Inclusive, Parallel, Event-based and Complex Gateways can be used with some constraints (because the lack of a central mechanism to maintain data visibility, and no central evaluation)
Exclusive Gateway Example⌘

Choreography Example 2 from spec⌘

Business Process Model and Notation (BPMN), Version 2.0, pages 318-319

Choreography Example 2 from spec⌘

Execution Semantics⌘

  • BPMN Execution Semantics (BPMN 2.0 spec, Chapter 13) describes how BPMN elements should be executed on an engine.
  • Not all elements can be executed. Non-operational elements like Manual Task, Abstract Task, DataState, Ad-Hoc Process can be ignored.
Token⌘
  • A token is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed.
  • The behavior of Process elements can be defined by describing how they interact with a token as it “traverses” the structure of the Process.
  • However, modeling and execution tools that implement BPMN are NOT REQUIRED to implement any form of token.
Sequence Flow⌘
  • Multiple outgoing Sequence Flows with conditions behaves as an inclusive split.
  • A mix of multiple outgoing Sequence Flows with and without conditions is considered as a combination of a parallel and an inclusive split
Exclusive Gateway⌘

  • Each token arriving at any incoming Sequence Flows activates the gateway and is routed to exactly one of the outgoing Sequence Flows.
  • If and only if none of the conditions evaluates to true, the token is passed on the default Sequence Flow.
  • In case all conditions evaluate to false and a default flow has not been specified, an exception is thrown.
Parallel Gateway⌘

  • The Parallel Gateway is activated if there is at least one token on each incoming Sequence Flow.
  • The Parallel Gateway consumes exactly one token from each incoming Sequence Flow and produces exactly one token at each outgoing Sequence Flow.
  • If there are excess tokens at an incoming Sequence Flow, these tokens remain at this Sequence Flow after execution of the Gateway.
  • The Parallel Gateway cannot throw any exception.

Diagram Interchange⌘

  • In order to avoid recreating processes for tools from different vendors, it's important to have a standard format for exchanging BPMN processes.
  • In BPMN 2.0 processes can be described using two aspects:
    • processes models contain the semantics
    • processes diagrams store visual representation of the process models

Process model contains complete definition of processes, process diagram describes an incomplete or partial representation (view) of this model.

BPMN 2.0 XML⌘
  • BPMN 2.0 file is an executable XML representation of a business process

<?xml version="1.0" encoding="UTF-8"?> 
<definitions id="Definition" ... >

  <process processType="Private" isExecutable="true" id="com.sample.bpmn.hello" name="Hello World" >

    <!-- nodes -->
    <scriptTask id="_2" name="Hello" >
      <script>System.out.println("Hello World");</script>
    </scriptTask>
    <startEvent id="_1" />
    <endEvent id="_3" >
        <terminateEventDefinition/>
    </endEvent>

    <!-- connections -->
    <sequenceFlow id="_1-_2" sourceRef="_1" targetRef="_2" />
    <sequenceFlow id="_2-_3" sourceRef="_2" targetRef="_3" />

  </process>

BPMN 2.0 XML⌘

  <bpmndi:BPMNDiagram>
    <bpmndi:BPMNPlane bpmnElement="com.sample.bpmn.hello" >
      <bpmndi:BPMNShape bpmnElement="_2" >
        <dc:Bounds x="96" y="16" width="80" height="48" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="_1" >
        <dc:Bounds x="30" y="22" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape bpmnElement="_3" >
        <dc:Bounds x="210" y="22" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge bpmnElement="_1-_2" >
        <di:waypoint x="66" y="40" />
        <di:waypoint x="96" y="40" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge bpmnElement="_2-_3" >
        <di:waypoint x="176" y="40" />
        <di:waypoint x="210" y="40" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>

</definitions>

BPMN 2.0 XML⌘
  • BPMN 2.0 defines standarized formats for creating XML files which contains both aspects.
  • This allows exchanging BPMN processes between tools of different vendors.
  • XML BPMN files contain two parts:
    • one or more process models
    • one or more process diagrams
  • BPMN 2.0 processes can be stored using formats defined by XMI or XSD.
Interchange Capabilities⌘

From a user point of view, BPMN diagram interchange capable tools should allow:

  • exporting processes to XML file
  • importing processes from XML files

in such way that the model content and layout are preserved - there is no need to re-draw processes manually.

Interchange Limitations⌘

BPMN Diagram Interchange provides no mechanism for:

  • colors of shapes and text
  • decoration of shapes (shadows, gradients, backgrounds)
  • text fonts and size
  • text wrapping
  • thickness and style of lines
Interchanging Incomplete Models⌘
  • In practice, it is common for models to be interchanged before they are complete.
  • The importing tool is expected to be able to open exported incomplete diagrams.

Module 2. Questions⌘

  • What is complex gateway?
  • How many different types of loops are there in BPMN?
  • How can you trigger a compensation?
  • What is Conversation, Choreography?
  • What is an Execution Semantics?
  • What is the difference between process model and process diagram?

Module 3. Decision Management
and Modeling with DMN⌘

References⌘

  • Decision Model and Notation (DMN)
  • Decision Management Solutions, Decision Modeling with DMN, White Paper.

DMN⌘

  • Decision Model and Notation
  • OMG Specification (December 2014)
  • The purpose of DMN is to provide the constructs that are needed to model decisions, so that organizational decision-making can be readily depicted in diagrams, accurately defined by business analysts, and (optionally) automated.

Decision-making⌘

Existing modeling standards are using two different perspectives:


  • Business process models (e.g., BPMN) - decision-making within business processes by defining specific tasks or activities within which the decision-making takes place.

  • Decision logic - can define the specific logic used to make individual decisions, for example as business rules or decision tables.

DMN - the third perspective⌘

DMN will provide a third perspective (Decision Requirements Diagram):

  • Business process models will define tasks within business processes where decision-making is required to occur
  • Decision Requirements Diagrams will define the decisions to be made in those tasks, their interrelationships, and their requirements for decision logic
  • Decision logic will define the required decisions in sufficient detail to allow validation and/or automation.

Two levels of modeling decisions⌘

Decision Model and Notation Beta 1, Figure 1: Aspects of modeling

Decision requirements level⌘

  • The decision requirements level of a decision model in DMN consists of a Decision Requirements Graph (DRG) depicted in one or more Decision Requirements Diagrams (DRDs).
  • A DRG models a domain of decision-making, showing the most important elements involved in it and the dependencies between them.
  • The elements modeled are decisions, areas of business knowledge, sources of business knowledge, and input data

Decision⌘

  • A decision is the act of determining an output value (the chosen option), from a number of input values, using logic defining how the output is determined from the inputs.
  • This decision logic may include one or more business knowledge models.

Business Knowledge Model⌘

  • Business Knowledge Model denotes a function encapsulating business knowledge, e.g., as business rules, a decision table, or an analytic model.

Knowledge source⌘

  • A knowledge source denotes an authority for a business knowledge model or decision.
  • Examples: policies, regulations, best practices, human expertise and analytic insight, domain experts responsible for defining or maintaining them, or source documents from which business knowledge models are derived, or sets of test cases with which the decisions must be consistent

Input Data⌘

  • An input data element denotes information used as an input by one or more decisions.

Requirements⌘

  • A decision is said to “require” its inputs in order to determine its output.
  • The inputs may be input data, or the outputs of other decisions.
  • Decisions may be connected in a network called a Decision Requirements Graph (DRG), which may be drawn as a Decision Requirements Diagram (DRD).

Requirement Types⌘

Three types of requirements:

Information Requirement

Knowledge Requirement

Authority Requirement

Information Requirement⌘
  • Information Requirement may be drawn from Input Data elements to Decisions, and from Decisions to other Decisions.
  • They represent the dependency of a Decision on information from input data or the results of other Decisions.
  • Information Requirement may be interpreted as data flow.
  • The arrow is drawn in the direction of information flow, i.e., towards the Decision that requires the information.
Knowledge Requirement⌘
  • Knowledge Requirements may be drawn from Business Knowledge Models to Decisions, and from Business Knowledge Models to other Business Knowledge Models.
  • They represent the invocation of business knowledge when making a decision.
  • They may be interpreted as function calls.
  • The arrows are drawn in the direction of the information flow of the result of evaluating the function, i.e. toward the element that requires the business knowledge.
Authority Requirement⌘

Authority Requirements may be used in two ways:


from Knowledge Sources to Decisions, Business Knowledge Models and other Knowledge Sources, where they represent the dependence of the DRD element on the knowledge source.


from Input Data and Decisions to Knowledge Sources, where they represent the derivation of Business Knowledge Models from instances of Input Data and Decision results, using analytics.

Connection rules⌘

Decision logic level⌘

Decision logic level⌘

  • Decision requirements level is often sufficient for business analysis of a domain of decision-making.
  • Using decision logic, the same components may be specified in greater detail, to capture a complete set of business rules and calculations, and to allow the decision-making to be fully automated.
  • At the decision logic level, every decision in a DRG is defined using a value expression which specifies how the decision’s output is determined from its inputs.
  • The value expression may be notated using a boxed expression.

Decision Logic⌘

  • The logic used to make decisions, defined in DMN as the value expressions of decisions and business knowledge models and represented visually as boxed expressions.
  • Decision logic can be represented as:
    • a literal expression represents decision logic as text that describes how an output value is derived from its input values. The expression language may be formal or executable: a plain English description of the logic of a decision, a first order logic theory, a Java or a PMML document, an expression language: FEEL
    • a decision table is a tabular representation of decision logic.
    • an invocation is a tabular representation of how decision logic that is represented by a business knowledge model is invoked by a decision, or by another business knowledge model. An invocation may also be represented as a literal expression, but usually the tabular representation will be more understandable.
FEEL Expression Language⌘

FEEL stands for Friendly Enough Expression Language and it has the following features:

  • Side-effect free
  • Simple data model with numbers, dates, strings, lists, and contexts
  • Simple syntax designed for a wide audience
  • Three-valued logic (true, false, null) based on SQL and PMML
FEEL Example⌘

Boxed Expression⌘

  • Boxed Expression is a graphical notation for decision logic.
  • This notation serves to decompose the decision logic model into small pieces that can be associated with DRG artifacts.
  • Boxed expressions are defined recursively, i.e. boxed expressions can contain other boxed expressions.
  • The top-level boxed expression corresponds to the decision logic of a single DRG artifact.
Boxed literal expression⌘
  • In a boxed expression, a literal expression is represented by its text.
Boxed invocation⌘
  • An invocation is a container for the parameter bindings that provide the context for the evaluation of the body of a business knowledge model.

Decision Table⌘

  • A decision table is a tabular representation of a set of related input and output expressions, organized into rules indicating which output entry applies to a specific set of input entries.
IF input expression 1 matches x AND input expression 2 matches y THEN a result (a "hit") is z.
If Customer = “Business” and OrderSize < 10 then Discount = 0.10

Decision Table Orientation⌘

Depending on size, a decision table can be presented horizontally (rules as rows), vertically (rules as columns), or crosstab (rules composed from two input dimensions).

Rules as rows⌘

Rules as columns⌘

Rules as crosstab⌘

DRD Example⌘

To identify and document decisions we should identify a number of elements:

  • Input Data requirements
  • Knowledge about the Decision
  • Related Decisions

This example is based on Decision Management Solutions, Decision Modeling with DMN, White Paper

Input Data⌘

  • information sources that are required as Input Data should be identified
  • input data is information from outside the decision-making context about customers, parts, orders etc.
  • Input data is generally described at the level of business concepts or business objects (a customer record, or external data sources such as a credit report)
  • It is also useful to specify:
    • Is the information internal or external to the organization?
    • Is it structured, unstructured or semi-structured data?
    • How complex is the data and where can more information about it be found?

Knowledge About The Decision⌘

  • Knowledge sources act as authorities for decisions.
  • Decisions are driven by policies, regulations, best practices, human expertise and analytic insight.

Consider

  • What tells me what I must do?
  • What tells me what I should do?
  • What tells me what I can do?
  • What tells me what I will probably do?
  • What would help me do it better?

Decision Requirements Diagram⌘

Decisions, Input Data and Knowledge Sources should be combined into a Decision Requirements Diagram. Elements can now be linked in two distinct ways:

  • Information Requirements
    Any Decision can have Information Requirements. If a decision requires input data or if it is dependent on information produced by another decision, for example a pre-cursor or sub-decision, then it is said to have an Information Requirement to that Decision or Input Data. Use a solid line with an arrow head pointing from the Input Data or Decision to the Decision that has the requirement.
  • Authority Requirements
    Knowledge Sources represent authorities for decision-making. Each Decision should be linked to the Knowledge Sources that act as an authority for that Decision. If the knowledge explains how the decision should or must be made, for example a policy or regulation, or how it might be made more accurately or effectively, for example a best practice or analytic, then it is an authority for the decision. Use a dashed line with a round head to show Authority Requirements, with the round head at the Decision and the blunt end at the authority.

A High Level Decision Requirements Diagram⌘


In DMN all Information Requirements are equal—there is no way to show that some decisions are always required while others are only sometimes required.

BPMN Tasks and DMN Decisions⌘

BPMN Tasks and DMN Decisions⌘

  • Most BPMN diagrams contain some tasks which involve decision-making (produce decision outputs which are used later in the process) which can be modeled in DMN.
  • Decision outputs may be used in two principal ways:
    • They may be consumed in another process task
    • They may influence the choice of sequence flows out of a gateway.

Linking BPMN and DMN Models⌘

DMN offers two approaches to linking business process models in BPMN with decision models in DMN:

  • Associating Decisions with Tasks and Processes
    • Each decision may be associated with one or more business processes, and/or with one or more specific tasks.
    • The process context for an instance of Decision is defined by its association with any number of usingProcesses and any number of usingTasks, which are instances of Task
  • Decision Services
    • A decision service encapsulates a number of decisions and exposes them as a service, which might be consumed e.g. by a task in a BPMN process model.

DRD Notation⌘

Decision Model and Notation Beta 1, Table 1: DRD components


Module 3. Questions⌘

  • What is Decision according to DMN?
  • What is Input Data, Business Knowledge Model, Knowledge Source?
  • What is Requirement? What kinds of requirements are there?
  • What is boxed expression?
  • What is decision table? What types of decision tables are there?
  • What is FEEL?
  • How BPMN and DMN can be linked?
  • How decision outputs may be used in BPMN processes?

Module 4. Business Rules Approach
and Shared Business-Wide Vocabulary⌘

References⌘

  • Ronald Ross, Business Rule Concepts: Getting to the Point of Knowledge, 4th edition - BRS, 2013. [ISBN: 0-941049-14-0]
  • Semantics of Business Vocabulary and Rules (SBVR), v1.2
    • Annex E: Overview of the Approach
    • Annex F: The Business Rules Approach

Business Rules Approach⌘

by Ronald Ross, Business Rule Concepts: Getting to the Point of Knowledge, 4th edition

Noun Concepts and Business Rules vocabulary⌘

  • A term is a noun or noun phrase that workers recognize and use in business communications of all kinds (in agreements, deals, licenses, certifications, warranties, manuals, ...)
  • A term carries a particular meaning for the business, which should be unambiguous given a particular context of usage (e.g. customer, order, invoice, employee)
  • A term is a word or expression that has a precisely limited meaning in some uses or is peculiar to a science, art, profession, trade, or special subject
  • Every term requires a careful definition:
    • Customer: one that purchases some commodity or service; especially, one that purchases systematically or frequently

Terms⌘

Term should be:

  • Basic (should represent something fundamental to business, cannot be derived)
  • Countable (a thing whose instances can be counted - employee instead of staff)
  • Non-procedural (term is about knowledge, not about the actions)

The collection of all terms and definitions are the core part of a business vocabulary.

Such terms are crucial for expressing business rules effectively.

Connections Between Noun Concepts and
Wordings⌘


  • Connections between noun concepts are expressed using verbs and verb phrases - wordings.
  • Wording (verb concept) "customer places order" can be used in BR "A customer has always placed at least one order."
  • Wordings extend business vocabulary:
    • add standard verbs and verb phrases
    • by connecting terms they bring structure to the vocabulary
  • At least one term can be involved in connections:
    • person smokes (one term)
    • customer places order (two terms - a majority of connections)
    • person visits city on date (three terms)

Graphical Concept Models⌘

Ronald Ross, Business Rule Concepts: Getting to the Point of Knowledge, Figure 1-1, simple concept model in graphical form

Graphical Concept Models⌘

  • “What we can know” about the operational business can always be expressed on the basis of a structured business vocabulary.
  • The principal deliverable of concept (fact) modeling is a business vocabulary, not a diagram.
  • A concept model is a blueprint for basic business knowledge.

Business Vocabulary Summary⌘

  • A structured business vocabulary promotes consistency.
  • Each noun concept and verb concept of the operational business is represented in the business vocabulary, one and only one time.
  • All structural components should be unified and unique.

Fact Model⌘

by Ronald G. Ross , "What Are Fact Models and Why Do You Need Them (Part 1)," Business Rules Journal, Vol. 1, No. 5 (May 2000)

  • A Fact Model structures basic knowledge about business operations from a business perspective.
  • It is a crucial starting point for developing more advanced forms of business knowledge, including measures and rules.
  • It contains concepts represented by Terms, terms definitions, and logical connections (called "Facts") between core concepts.
  • A Fact Model focuses on "knowing" — that is, on how you organize your knowledge about the business process.
  • In contrast to a Fact Model, a Data Model focuses on describing the data and its proper format to support system-level requirements development.

Business Rules⌘

  • Rules are familiar to us all in real life.
  • We play games by rules, we live under a legal system based on rules, we set rules for our children, and so on.
  • Thinking about the control aspect of any organized activity in terms of rules is actually very natural (try explaining any game without explaining the rules the game is based).

Business Rule Independence⌘

Rule Independence means separating business rules from processes.

Article 2. Separate From Processes, Not Contained In Them
 2.1. Rules are explicit constraints on behavior and/or provide support to behavior.
 2.2. Rules are not process and not procedure.  They should not be contained in either of these.
 2.3. Rules apply across processes and procedures.  There should be one cohesive body of rules, 
      enforced consistently across all relevant areas of business activity.

source: The Business Rules Manifesto

Business Rules Summary⌘

  • Business rules put your company on the road to true agility.
  • Every business rule costs something.
    • The most significant cost of rules is not the direct cost of their implementation and maintenance in software systems.
    • The real cost is time to communicate the business rules and to change them.

A Quick 5-Item List of What Are Not
Business Rules⌘


by Ron Ross

  1. Assigning values to variables.
  2. Asserting mandatory GUI fields.
  3. Specifying which data can be viewed by which users.
  4. Expressing which documents are to be routed to which queues.
  5. Orchestrating tasks assignments in an execution environment.

Business rules are what you need to run the business, not what you use to set-up systems.

SBVR⌘

by Semantics of Business Vocabulary and Rules (SBVR), v1.2

Purpose of SBVR⌘

  • Semantics of Business Vocabulary and Business Rules, OMG Specification
  • The SBVR specification is applicable to the domain of business vocabularies and business rules of all kinds of business activities in all kinds of organizations.
  • It provides an unambiguous, meaning-centric, multilingual, and semantically rich capability for defining meanings of the language used by people in an industry, profession, discipline, field of study, or organization
  • It supports linguistic analysis of text for business vocabularies and business rules

What is a Business Vocabulary?⌘

A business vocabulary contains all the specialized terms, names, and verb concept wordings of concepts that a given organization or community uses in their talking and writing in the course of doing business.

What is a Business Rule?⌘

The SBVR follows a common-sense definition of ‘business rule’:

Business Rule: rule that is under business jurisdiction
  • ‘Under business jurisdiction’ means that the business can enact, revise, and discontinue their business rules as they see fit.
  • If a rule is not under business jurisdiction in that sense, then it is not a business rule.
  • For example, the ‘law’ of gravity is obviously not a business rule. Neither are the ‘rules’ of mathematics.

Two categories of Rules⌘

  • Structural Rule (aka Definitional): a business rule can be ill-conceived, misunderstood or misapplied, but it cannot be violated directly.
  • Necessity or impossibility
    • Associate Trainer is a trainer who signed Associate Trainer Agreement
    • Premium Customer is a customer who orders more than $1mln in a calendar year
  • Operative Rule (aka Behavioural): A business rule that can be violated directly.
  • Obligation or prohibition
    • e.g. Every employee must sign employment agreement

Rules, Verb Concepts and Terms⌘

  • A verb concept is an relationship between two or more concepts; for example “Rental Car is located at Branch.”
  • In SBVR, rules are always constructed by applying necessity or obligation to verb concepts.
    • For example, the rule “A Rental must not have more than three Additional Drivers” is based on the verb concept “Rental has Additional Driver.”
  • Business Rules Approach: “Business rules build on verb concepts, and verb concepts build on concepts as expressed by terms.”

Business Rule “Mantra”⌘

“Rules are based on facts, and facts are based on terms.”

Terms

  • Employee
  • Employee number
  • Car
  • Car registration number

Facts

  • Car has car registration number
  • Employee drives car

Rules

  • Each employee must be uniquely identifiable.
  • Each car always has exactly one car registration number.

What does 'Practicable' Mean⌘

  • All business rules need to be practicable.
  • A person who knows about it can decide directly whether it is being followed when that person observes relevant behavior, some relevant outcome from a decision or calculation.
  • In other words, a business rule is ready to deploy into business operations.

What does 'Directly Enforceable' Mean⌘

  • All operative business rules need to be directly enforceable.
  • To be enforceable, an operative business rule has to be defined in such a way that violations can be detected.
  • Being directly enforceable is what distinguishes business policies from operative business rules
  • Example: ‘trainer must deliver good training’ is not sufficiently precise to be enforced. It is a business policy and needs operative business rules through which it can be enforced:
    • The average of results in the trainer section of the TEF must be above 4.0.
    • The trainer must provide training course materials for each participant.

Meaning and Representation⌘

The primary subjects of the Meaning and Representation Vocabulary can be described by:

  • Expression – things used to communicate (e.g., sounds, text, diagrams, gestures), but apart from their meaning — one expression can have many meanings.
  • Representation – the connection between expression and a meaning. Each representation ties one expression to one meaning.
  • Meaning – what is meant by a word (a concept) or by a statement (a proposition) – how we think about things.
  • Extension – the things to which meanings refer, which can be anything (even expressions, representations, and meanings).

Meaning and Representation Example⌘

  • Meaning can be expressed by many different representations.

The Business Rules Manifesto⌘

Some principles:

  • Rules build on facts, and facts build on concepts as expressed by terms.
  • Rules are not process and not procedure. They should not be contained in either of these.
  • Rules should be expressed declaratively in natural-language sentences for the business audience.

SBVR Structured English⌘

  • The most common means of expressing definitions and business rules is through statements, not diagrams.
  • Diagrams are helpful for seeing how concepts are related, they are impractical as a primary means of defining vocabularies and expressing business rules.
  • Annex A - SBVR Structured English defines an English vocabulary for describing vocabularies and stating rules.
  • Annex A describes one way of using English that maps mechanically to SBVR concepts, it uses a small number of English structures and common words to provide a simple and straightforward mapping.
SBVR Structured English - example⌘

Module 4. Questions⌘

  • What is term, wording?
  • What are two categories of Rules?
  • What is Business Rule?
  • What is Business Rule “Mantra”?

Module 5. Business Process Management
Knowledge and Skills⌘

References⌘

References⌘

BPM Lifecycle⌘

Marlon Dumas, Fundamentals of Business Process Management

BPM Lifecycle⌘

  • The first question is "What business processes are we intending to improve?"
  • The initial phase is called process identification - start by at identifying the processes that are relevant to the problem, delimiting the scope of these processes, and identifying relations between these processes (e.g. one process being part of another process)
  • Process architecture takes the form of a collection of processes and links between these processes representing different types of relation.
  • You can’t control what you can’t measure”. Before starting to analyze any process in detail, it is important to clearly define the process performance measures (metrics) that will be used to determine whether a process is in “good shape” or in “bad shape”.

BPM Lifecycle⌘

  • Having understood the as-is process in detail, the next step is to identify and analyze the issues in the process.
  • Process Analysts collect information about the time spent in each task of the process: the amount of time that process participants spend actually doing work or waiting for something to happen.
  • Process redesign is to identify and analyze potential solutions for the issues.
  • Process implementation may involve organizational change management and process automation.
  • "Every good process eventually becomes a bad process" - the process needs to be monitored, managing a process requires a continuous effort.

Stakeholders in the BPM Lifecycle⌘

Management Team
CEO, COO, CIO, CFO, HR director
Chief Executive Officer (CEO) responsible for the overall business success of the company.
Process Owner Responsible for the efficient and effective operation of a given process.
Process Participants Human actors who perform the activities of a business process on a day-to-day basis.
Process Analysts Conduct process identification, discovery, analysis and redesign activities. They coordinate process implementation as well as process monitoring and controlling.
System Engineers Involved in process redesign and implementation. They interact with process analysts to capture system requirements.

Ownership of Processes⌘

  • Developing roles and responsibilities for process is often difficult.
  • It commonly begins with the question of ownership and responsibility as an organization begins to understand the value of process and implement actions to manage those processes.
  • Assignment of process ownership is one of the indicators of an increasing level of process maturity.

Process Owner Responsibilities⌘

The Process Owner is responsible for the governance of process performance and process change — and specifically:

  • Defines the process mission, vision, tactics, goals, objectives, KPIs (Key Performance Indicators), and the measures that are aligned with the organization strategies.
  • Monitors and reports process performance against KPIs and health versus plans.
  • Synchronizes process improvement plans with other process owners within the value chain and other interfacing processes.
  • Ensures appropriate process designs, including the correct business requirements.
  • Defines and sponsors business process change and capability investments, which continuously increase the maturity of the process and sustain each level of maturity.

Process Owner Skills & Capabilities⌘

Measurement and Optimization⌘

by Ed Walters, What are CSFs and KPIs?

CSF and KPI⌘

  • CSFs and KPIs are techniques used for defining and measuring business objectives.
  • CSF is an acronym for Critical Success Factor.
  • KPI is an acronym for Key Performance Indicator.
  • A CSF is some feature of the internal or external environment of an organization that has a major influence on achieving the organization's aims.
  • A KPI is a quantifiable criteria that an organization uses to measure its performance in terms of meeting its CSFs.
  • There can be more than 1 KPI per CSF.
  • A KPI can be financial or non-financial.
Organization aims⌘

3 levels can be distinguished:

  1. Vision/Mission
    An expression of the basic reason why the organization was established and continues to exist.
  2. Strategic Goals
    Faced with the internal and external circumstances that an organization must deal with in the next years: what should be the focus of the organization so that it can successfully pursue its Vision.
  3. Objectives
    Strategic Goals are by their very nature high level expressions, big ideas. These Goals must be broken down into something more concrete and specific, so that tactical plans can be devised (budgets), responsibilities assigned and measurements made.

When combined, the 3 levels form the basis of a Business Plan.

Origin of CSFs and KPIs⌘
  • The concept of "success factors" was originally developed by D. Ronald Daniel of McKinsey and Company in the sixties.
  • The idea was most famously refined and popularized by Jack F. Rockart of the Sloan School of Management at the end of the 80s.
  • The concept of CSF/KPI:
    • You can’t manage what you can’t measure.
    • Things that are measured get done.
    • You can’t improve what you can’t measure.
4 basic types of CSF⌘

AKA Rockart's CSF types

  • Industry – these factors result from specific industry characteristics. These are the things that the organization must do to remain competitive.
  • Environmental – these factors result from macro-environmental influences on an organization. Things like the business climate, the economy, competitors, and technological advancements are included in this category.
  • Strategic – these factors result from the specific competitive strategy chosen by the organization. The way in which the company chooses to position themselves, market themselves, whether they are high volume low cost or low volume high cost producers, etc.
  • Temporal – these factors result from the organization's internal forces. Specific barriers, challenges, directions, and influences will determine these CSFs.
How many CSFs and KPIs should there be?⌘
  • 3-5 strategic goals should be enough to focus the organization's efforts during a forthcoming 3-5 year period.
  • Balanced Scorecard technique suggests 3-5 goals per focus area. Each Goal should be broken down into 3-5 Factors, between 9 and 25 Factors that the organization should consider to be CSFs.
  • There should not be too many/too few factors.
  • For each CSF there must be at least one Measurement (KPI) and a Target for the current or forthcoming budget exercise.
  • Objective (tactical aim) = CSF + KPI + Target
  • The data that are associated with the KPIs needs to be captured and consolidated (through Business Intelligence software).
Steps in the CSFs and KPIs. Process⌘
  1. Establish the Vision.
  2. Determine Strategic Goals.
  3. Analyze each Goal - what Factors (CSF) influence the Goal.
  4. Assign at least 1 Measure for each Factor (KPI).
  5. Assign a Target.
Example of CSFs⌘

based on http://www.mindtools.com/pages/article/newLDR_80.htm

Consider a produce store, whose mission is:

"To become the number one produce store in Main Street by selling the highest quality, freshest farm produce, from farm to customer in under 24 hours on 75% of our range and with 98% customer satisfaction."

Business Activity Monitoring (BAM)⌘

  • BAM is the process of using computer software to electronically monitor business data based on user-defined business rules and the systematic electronic notification when those rules are triggered.
  • When an exception to the rule is identified, notification events typically occur in the form of an email, text message, social networking post, ...
  • The objective of BAM is to enable companies to make better informed decisions by giving them visibility across their organization in a real-time capacity.

BAM Components⌘

A BAM system is typically comprised of the following features:

  • Business Rules Engine — Allows users to set up business rules for the software to follow.
  • Notification Engine — Provides options to set up an email, text message or social networking post when an exception is identified.
  • Database connectivity - connection to data.
  • Logging — A BAM system provide some mechanism to track when an alert was sent or if any errors occurred during the processing.

Example Set of Control Services⌘

WebMethods, Business Activity Monitoring (BAM) The New Face of BPM

Process Simulation and Optimization⌘

by Denis Gagne, Modeling and Simulation in Business Process Management

Why simulating business models⌘

Advantages of simulation over testing on the real wold:

  • speed
  • low cost
  • no disturbance of current operations

Types of Simulation⌘

  • Visual Depiction - user is presented with an animated depiction of the business model
  • Scenario Simulation (Role Play) - user asked to take actions and make decisions within a simulated business environment
  • Numeric Simulation (Discreet Events) - user asked to provide values for input and decision parameters of a simulated business model
Visual Depiction⌘

Mostly used for teaching & learning, verification & validation.

Scenario Simulation⌘

Role play business simulation games mostly used for teaching & learning.

Numeric Simulation⌘

Examples: what-if analysis, risk assessment, revenue forecasting, ...

Mostly used for teaching & learning, persuasion & selling, analysis of a business situation, verification & validation.

Numeric Simulation Caveats (risks)⌘
  • Unrealistic user expectations
  • Business Model is not necessarily Simulation Model
    • Their goals may be misaligned.
  • Incorrect conclusions or predictions
  • Sub-optimization
    • Partial or sub-model optimization can lead you wrong way

Flow Analysis⌘

by Marlon Dumas, Fundamentals of Business Process Management

  • Flow analysis is a set of techniques that allow to estimate the overall performance (time, cost, error rate, ...) of a process given some knowledge about the performance of its activities.
  • Using this technique we can calculate the average cycle time of an entire process if we know the average cycle time of each activity.

Cycle Time Calculation⌘

  • (Average/Overall) cycle time of a process is the average time it takes between the moment the process starts and the moment it completes.
  • (Average) cycle time of an activity is the average time it takes between the moment the activity is ready to be executed and the moment it completes

Cycle Time with XOR gateway⌘

XOR gateway equation⌘

Cycle time of a fragment of a process model with XOR gateway:

CT=i=1npiTi

Cycle Time with AND gateway⌘

AND gateway equation⌘

Cycle time of a fragment of a process model with AND gateway:

CT=Max(T1,T2,...,Ti)

Overall vs. Theoretical Cycle Time⌘

  • Cycle time of an activity or of a process can be divided into waiting time and processing time.
    • Waiting time is the portion of the cycle time where no work is being done to advance the process (time spent in transferring information between process participants, waiting for synchronization, ...)
    • Processing time is the time that actors spend doing actual work.

Overall vs. Theoretical Cycle Time⌘

  • Overall cycle time of the process (CT) is the total amount of waiting time and processing time of each activity.
  • Theoretical cycle time (TCT) is the amount of time that an instance of the process would take if there was no waiting time at all

Cycle Time Efficiency⌘

  • Cycle time efficiency (CTE) is ratio of overall processing time relative to the overall cycle time.
CTE=TCTCT
  • A cycle time efficiency close to 1 indicates that there is little room for improving the cycle time.
  • A ratio close to zero indicates that there is a significant amount of room for improving cycle time by reducing the waiting time.

Balanced Scorecard⌘

by BPTrends, Paul Harmon: Balanced Scorecard

  • The Balanced Scorecard is an approach to align the goals and measures that are used to evaluate the work of managers.
  • Balanced Scorecard is a useful tool for identifying process performance measures across an entire organization.
  • Financial metrics (e.g. ROI) are not sufficient and in a long-term perspective using financial metrics only can have negative impact on customers and employees.
  • BSC can be used to counter the tendency to rely too heavily on financial accounting measures.
  • Balanced Scorecard considers four types of measures:
    • Financial Measures: How Do We Look to Shareholders?
    • Internal Business Measures: What Must We Excel At?
    • Innovation and Learning Measures: Can We Continue to Improve and Create Value?
    • Customer Measures: How Do Customers See Us?

Balanced Scorecard Example⌘

Creating a Good Model⌘

by David Bridgeland and Ron Zahavi, Business Modeling: A Practical Guide to Realizing Business Value

  • Not every model should be built.
  • Sometimes the costs of creating and using a model are greater than the benefits that are gained from its use (model value destruction).
  • Creating/using a model always takes time:
    • time interacting with the subject matter experts,
    • time spent constructing the model with modeling tools, and making the model simpler
    • time spent finding and fixing problems with the model,
    • and time spent verifying a model with subject matter experts.
    • time spent analyzing the model for business implications,
    • time spent explaining the model to others,
    • time spent maintaining the model when things change, and so on.

Creating a Good Model⌘

The decision about whether to create a model is ultimately an economic decision: Are we going to deliver more value using this model than we will spend creating/using/maintaining it?

Model Value Analysis⌘

  • For small models, that can be built in an hour or four, we typically make a quick informal analysis (Do we expect to realize enough benefits to offset the time and trouble of creating the model?)
  • More formal analysis - model value analysis - a summary of the expected costs and the expected benefits, and a comparison of the two.
  • Spend 1% of the total anticipated modeling time on the model value analysis, to decide whether the other 99% makes economic sense.

BPMS Tool fundamentals⌘

by Derek Miers and Paul Harmon, Introduction to Evaluating BPMS Suites

BPMS Key Drivers and Objectives 1⌘

  • Lower Business Costs and Increased Efficiency
    • BPM products support the automation of repetitive steps, integrating application systems as needed, and supporting complex decision-making. As a result, they provide a platform upon which firms can lower their fundamental operating costs while enhancing the value delivered.
  • Increased Adaptability, Flexibility, and Nimbleness (agility)
    • Effective BPM infrastructure will allow the firm to develop new products and services far more quickly than was previously possible.
  • Lower Cost of Systems Development and Support
    • Modern BPM products provide increased developer productivity, significantly lowering the cost of systems development.

BPMS Key Drivers and Objectives 2⌘

  • Lower Systems Implementation Risks
    • By modeling an entire process and then making incremental, evolutionary changes, managers are able to introduce change with lower risk.
  • Better Governance and Compliance
    • BPM technology can control the ways in which decisions are made and modifications to the process are introduced ensuring compliance and effective governance.
  • Better Customer Service
    • BPMS provides the glue to tie together disparate channels of customer interaction.

Processing Modeling⌘

  • This is the area where the effective capabilities of the product are most apparent – it is where the semantics of the vendor’s interpretation of process are made visible.
  • A key issue here is the degree of accessibility of the environment and the amount of IT specialist support required.

The BPM Technology Continuum⌘

Derek Miers and Paul Harmon, Introduction to Evaluating BPMS Suites, Figure 3

  • If you start with a language like Java, you can build any kind of BPM system you want. But it takes a lot of work, using only a language, to build a system.
  • As you move from left to right, the products become more structured and provide more ready-made components, making it easier and faster to develop finished applications.

The BPM Stack⌘

The BPM Stack⌘

Each layer sits on top of a lower level, using technologies defined at the lower level while adding additional utilities to integrate the levels below, to provide a more general functionality.

BPM Center of Excellence⌘

by Rich Seeley, Forrester Details “Secret Sauce” for BPM Success, and Lisa Dyer et al, Creating a BPM Center of Exellence (CoE)

  • A center of excellence may refer to a group of people, a department or a shared facility within an organization.
  • Setting up a center of excellence (COE) makes a major difference in the success of business process management (BPM).
  • Having a COE doesn't guarantee BPM success, but it "significantly increases the odds of BPM success"

Key focus areas of BPM CoE⌘

A BPM Center of Excellence (CoE) must address the following key focus areas of responsibility:

  • Defining a higher business goal or vision, driving BPM initiatives and aligning individual projects with that vision
    • strategy and long-term planning, tracking KPIs
  • Executing a scalable delivery resource model for discovering, implementing, deploying, managing, and supporting BPM initiatives
    • execution of BPM projects, creating, maintaining, and governing best practices
  • Administering a shared infrastructure for hosting and maintaining the solutions that are the outcomes of BPM initiatives
    • BPMS used for hosting, executing, and maintaining the process applications that are the outcomes of BPM

CoE key roles⌘

  • BPM Program Manager - a methodology coach who provides oversight in the area of driving iterations, playbacks, estimation, planning engagement methodology, and agile development in general.
  • BPM Analyst - focuses on discovering and modeling value-driven process requirements within the context of an individual project and with the intent of collaborating with the solution implementation team.
  • BPM Developer - a BPM implementation expert who is trained and experienced in using the BPM platform to develop solutions (team lead or solution architect).
  • BPM Integration Developer - a more technically focused version of the BPM Developer, focuses on building additional functionality outside the core product that is needed to complete the end-to-end solution.
  • Other roles:
    • Business users, SMEs, Process owners
    • Administrators, Enterprise Architects

Module 5. Questions⌘

  • What is the difference between Overall and Theoretical Cycle Time?
  • Assuming we know the average cost of each activity, how we can calculate the cost of a process?
  • What is Model Value Analysis?
  • What Types of Simulation are there?
  • What is the Process Owner responsible for?
  • What is CSF and KPI?
  • What is BAM?

Module 6. Process Quality
and Governance Frameworks⌘

References⌘

Regulatory & Governance Frameworks⌘

SOX⌘

by http://www.sox-online.com/sarbanes-oxley-basics/

  • SOX stands for Senator Paul Sarbanes and Representative Michael Oxley, who drafted the Sarbanes-Oxley Act of 2002.
  • To protect investors by improving the accuracy and reliability of corporate disclosures.
  • The Sarbanes-Oxley Act created new standards for corporate accountability as well as new penalties for acts of wrongdoing.
  • It changes how corporate boards and executives must interact with each other and with corporate auditors.
  • It removes the defense of "I wasn't aware of financial issues" from CEOs and CFOs
SOX Key Sections⌘
  • Section 201 outlines Prohibited Auditor Activities.
  • Section 302 describes the CEO's and CFO's new responsibilities regarding corporate reports.
  • Section 404 addresses the Management Assessment of Internal Controls.
  • Section 409 outlines Real Time Disclosure.
  • Section 802 describes criminal penalties for altering documents.
  • Section 806 describes whistle blower protection.
  • Section 807 describes criminal penalties for fraud.

COBIT⌘

based on http://www.isaca.org/COBIT/Documents/COBIT5-Introduction.ppt © 2012 ISACA

  • Control Objectives for Information and Related Technology
  • COBIT 5 helps enterprises create optimal value from IT by maintaining a balance between realising benefits and optimising risk levels and resource use.
  • COBIT 5 enables information and related technology to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and functional areas of responsibility, considering the IT-related interests of internal and external stakeholders.
  • COBIT 5 provides a comprehensive framework that assists enterprises to achieve their goals and deliver value through effective governance and management of enterprise IT.
COBIT 5 Principles⌘

Source:  COBIT® 5, figure 2. © 2012 ISACA® All rights reserved.
Principle 1. Enterprises exist to create value for their stakeholders.
Principle 2. COBIT 5 does not focus only on the ‘IT function’, addresses the governance and management of information from an enterprise wide, end-to-end perspective
Principle 3. COBIT 5 aligns with the latest relevant other standards and frameworks used by enterprises.
Principle 4. Systemic governance and management through interconnected enablers: Processes, Organisational structures, Principles, Policies and Frameworks, ...
Principle 5. The COBIT 5 framework makes a clear distinction between governance and management.
  • Enterprises of all sizes, whether commercial, not-for-profit or in the public sector, can benefit from COBIT 5.
COBIT 5 Enablers⌘

ITIL⌘

based on An Introductory Overview of ITIL® 2011

  • ITIL (IT Infrastructure Library) provides a framework of Best Practice guidance for IT Service Management.
  • It provides a framework for the governance of IT, the ‘service wrap’, and focuses on the continual measurement and improvement of the quality of IT service delivered, from both a business and a customer perspective.
ITIL Service⌘
  • A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.
  • Service management: A set of specialized organizational capabilities for providing value to customers in the form of services.
ITIL service lifecycle⌘
ITIL Key General Roles⌘
  • Process owner
    Accountable for ensuring that a process is fit for purpose, i.e. that it is capable of meeting its objectives; that it is performed according to the agreed and documented standard; and that it meets the aims of the process definition
  • Process manager
    Accountable for operational management of a process. There may be several process managers for one process and the process manager role is often assigned to the same person carrying out the process owner role
  • Process practitioner
    Responsible for carrying out one or more process activities. The process practitioner role may be combined with the process manager role, if appropriate
  • Service owner
    Responsible to the customer for the initiation, transition, and ongoing maintenance and support of a particular service; and accountable to the IT director or service management director for the delivery of a specific IT service.
Service Strategy⌘
  • Strategic thinking aims to define a plan that, using a clear set of principles, will provide a solution to a business problem in a particular situation.
  • It is focused on the value to the customer and identifies strategic assets that will be used for competitive advantage.
  • IT strategy manager formulates and communicates the IT strategy and ensures elements are in place for successful execution.
The 4 P's of ITIL Service Strategy⌘
  • Perspective The distinctive vision and direction
  • Position The basis on which the provider will compete
  • Plan How the provider will achieve its vision
  • Pattern The fundamental way of doing things – distinctive patterns in decisions and actions over time.
Service value⌘

This is defined in terms of the customers’ perceived business outcomes and described in terms of the combination of two components:

  • Service utility
    What the customer gets in terms of outcomes supported and/or constraints removed
  • Service warranty
    How the service is delivered and its fitness for use, in terms of availability, capacity, continuity and security.

Service value also includes the associated concepts of services as assets, value networks, value creation and value capture.

Quality Frameworks⌘

BPMM⌘

based on Business Process Maturity Model Specification, V1.0

  • BPMM is divided into five maturity levels that represent different states through which an organization is transformed as its processes and capability are improved.
Process Areas⌘
  • Maturity levels 2-5 are composed of process areas that collectively enable the capability to be achieved at that level.
  • Each process area is designed to achieve specific goals in creating, supporting, or sustaining the organizational state characteristic of the level.
BPMM Maturity Levels 1-2⌘

BPMM Maturity Levels 3-4⌘

BPMM Maturity Level 5⌘

Maturity Level 2 Process Areas⌘

Maturity Level 2 Process Areas Descriptions⌘
  • Organizational Process Leadership deals with establishing the executive sponsorship and the management accountability for the performance of the organization’s process improvement activities.
  • Organizational Business Governance deals with establishing executive accountability for the management and performance of the organization’s work and results.
  • Work Unit Requirements Management deals with establishing and maintaining the documented and agreed-to requirements for the work that a work unit performs.
  • Work Unit Planning and Commitment deals with establishing and maintaining the plans and commitments for performing and managing the work required of a work unit.
  • Work Unit Monitoring and Control deals with regularly monitoring and adjusting the work assignments, resources, and other work factors.
Maturity Level 2 Process Areas Descriptions⌘
  • Work Unit Performance deals with having the individuals and workgroups within the work unit perform their assigned activities and produce the agreed-to results.
  • Work Unit Change Management deals with managing and controlling the content and changes to product releases that are deployed.
  • Sourcing Management deals with managing the acquisition of products and services from suppliers external to the organization.
  • Process and Product Assurance deals with providing appropriate conformance guidance and objectively reviewing the activities and work products.
Conformance with the BPMM Specification⌘
  • Maturity Levels from 2 to 5 are defined
  • Conformance Points: an organization may conform to this specification at a Maturity Level of 2 or higher
  • Conformance defined cumulatively by reference to Goals realized: A compliant organization at a given Maturity Level shall realize all Goals specified for Maturity Levels up to and including the given Level
  • Goal realization: an organization realizes a Goal if and only if the organization has implemented practices which, in combined effect, achieve that Goal

Six Sigma⌘

What Is Six Sigma?⌘

Six Sigma is a problem-solving methodology that helps improve business and organizational operations.

The Six Sigma Scale⌘

The Six Sigma scale shows how well a vital feature performs compared to its requirements. The higher the sigma score, the more efficient the feature is.

Sigma Level Defects per Million
Opportunities (DPMO)
Percent Defects (%) Percent Success
1 691,462 69 31
2 308,538 31 69
3 66,807 6.7 93.3
4 6,210 0.62 99.38
5 233 0.023 99.977
6 3.4 0.00034 99.99966
Six Sigma Principles⌘

Six Sigma is based on a handful of basic principles, and these principles create the entire Six Sigma arrangement. Here are Six Sigma’s fundamental principles:

  • All outcomes and results are determined by inputs with some degree of uncertainty.
  • To change or improve results, you have to focus on the inputs, modify them, and control them.
  • Variation is everywhere, and it degrades consistent, good performance. Your job is to find it and minimize it!
  • Valid measurements and data are required foundations for consistent, breakthrough improvement.
  • Only a critical few inputs have significant effect on the output. Concentrate on the critical few.
  • Every decision and conclusion has risk, which must be weighed against the context of the decision.
The DMAIC Method of Six Sigma⌘
  • The DMAIC (Define-Measure-Analyze-Improve-Control) project method is a formalized problem-solving process of Six Sigma.
  • It’s made-up of five steps to apply to any procedure of a business to improve effectiveness.
  1. Define: Set the context and objectives for your improvement project.
  2. Measure: Determine the baseline performance and capability of the process or system you’re improving.
  3. Analyze: Use data and tools to understand the cause-and-effect relationships in your process or system.
  4. Improve: Develop the modifications that lead to a validated improvement in your process or system.
  5. Control: Establish plans and procedures to ensure that your improvements are sustained.
Poka-Yoke⌘
  • Poka-yoke (ポカヨケ) [poka yoke] is a Japanese term that means "mistake-proofing"
  • A poka-yoke is any mechanism in manufacturing process that helps an equipment operator avoid mistakes.
  • Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur

Lean⌘

Lean - what it is and how it works⌘

  • Lean thinking focuses on value for the customer by eliminating waste in an end-to-end process.
  • It establishes flow and implements a "one-piece" pull system.
  • It strives to achieve perfection through continuous improvement.
TIMWOOD - the 7 Wastes⌘

Philipp Schume, BPM Voices: BPM and Lean -- a powerful combination for process improvement

Key challenges⌘
  • Lean provides excellent methods for process improvement, it is unable to easily provide visibility into a process and quantify the extent of the improvement.
  • The lack of adequate measurements, missing targets, and key performance indicators (KPIs) are some of the biggest challenges during the Future State (To-Be) testing and implementation in many process improvement projects.
Value-added / Non-value-added activity⌘
  • When a business process is analyzed using the Lean methodology, all process activities are classified into value-adding (VA) and non-value adding (NVA) activities.
  • Typically, more than 50% of activities are non-value adding, or activities the customer is unwilling to pay for.
  • These NVAs are further analyzed and summarized into the seven waste categories to assist the project team in finding a Lean solution for the future process.

Module 6. Questions⌘

  • What is SOX?
  • What is COBIT?
  • What is ITIL?
  • What is BMM Maturity Level?
  • What is Six Sigma?
  • What is Poka Yoke?
  • What does TIMWOOD stand for?