The LEADing Practice. extended BPMN Standard. Relating Objects

(1)

The LEADing Practice

eXtended BPMN Standard

(2)

w w w . L E A D i n g P r a c t i c e . c o m 2

Table of

Introduction

This paper describes the results of research that was conducted by of the Global University Alliance as they worked toward the formulation of a set of Enterprise Modelling and

Enterprise Architecture principles. This work has led to the development of a new breed of process modelling capabilities that are collectively known as eXtended Business Process Model and Notation (X-BPMN). The notational extensions defined by X-BPMN X-BPMN has been developed into a LEADing Practice standard. To truly understand the significance and need for this work, a brief historical perspective follows.

Business Process Modelling Notation (BPMN) grew out of a standardization of early

techniques for visually representing ideas, insights and descriptions of the chain of processes within an organization. BPMN 1.0 was introduced in 2004 and focused on the ability to model processes. It was followed in succession with evolutionary refinement in the form of BPMN 1.1 and 1,2, and then in 2009, with BPMN 2.0. This standard added the ability to describe behaviour between two or more business participants (a choreography), behaviour involving collections of participants (collaborations), and message exchanges (conversations). With each new wave of descriptive ability, the application of BPMN has enabled rapid advancement in composition-based software development practice. BPMN with its ready transformation into the Business Process Execution Language (BPEL, aka WS-BPEL) has breathed life into model-driven process execution. In essence, the equation Application = Computation + Coordination has become reality with network-addressable computation being provided by Web Services and BPMN graphically depicting the coordination logic. Although incredibly useful, a fundamental question remains – “What is the nature of these applications?” Clearly the applications built with pure BPMN-to-BPEL (Business Process Execution Language, or more correctly, the Web Services Business Process Execution Language (WS-BPEL)) transformation are NOT business applications. The reason for this is quite simple: BPEL is a systems integration language, not a business development language or business application development language. Stand-alone business execution and business applications are a “work system” in which humans, or humans in concert with applications, have

behaviour. To describe this behaviour and therefore accomplish telling the larger story, the WS-BPEL standard must be augmented with both “WS-Human Task” and “BPEL4People” standards. In short, the notion of leveraging BPMN as the graphical depiction of BPEL did not require it to completely address the scope of true business applications and meet new higher standards for our ability to describe behaviour in a business context. Further richness of expression must be added to BPMN.

Generally, architecture models exist in two forms; Models of Execution and Models of Understanding. Models of understanding are used to perform both quantitative and

qualitative analysis of business processes, while models for execution can be executed directly by software that is compliant to and can interpret the behaviour captured in the model. These goals are quite different from each other. Notions of direct execution, occur in a Business Process Management System (BPMS). This exploration of the X-BPMN notational symbol set is done with the explicit goal of enabling a meaningful connection of BPMN 2.0-based models more completely to the business, continuing to support the goals of software mediated

execution of business behaviour whilst facilitating the ability to increase our understanding of additional aspects of that behaviour.

(4)

When BPMN 2.0 became available in 2009, it was a much more enriched language and provided the benefit of a serialization format that can be executed directly by BPMN 2.0 compliant orchestration environments. Although greatly improved, many of BPMN 2.0’s improvements target tooling interoperability, as well as greater support for modelling necessary executable behavior; for example, signals, events, etc. Although BPMN 2.0 is a step in the right direction, its development was somewhat constrained by the desire to create models of execution with greater fidelity.

To achieve our goal to facilitate the creation of models of understanding for capturing

organizational business processes, it became clear to us that BPMN 2.0 need to be augmented with additional notational elements to have the expressiveness needed for this larger

consideration.

In order to further motivate the discussion of the potential role and value of X-BPMN, a couple of practical examples follow:

 Models created in X-BPMN facilitate the specification of business concepts like Manual Services and Automated Tasks, which are necessary for conducting meaningful process simulation and break point analysis.

 X-BPMN provides constructs that allow the modelling of system, service, and information flows.

 Without the X-BPMN notation, process analysts are constrained by the assumption that information flow is the same as the process flow.

As can be readily seen, this assumption makes it difficult to rationalize an approach to Master Data Management (MDM). The X-BPMN Business Objects are particularly useful for mapping the interaction of a process with real-world, tangible artifacts. This of course is necessary for the depiction of the real-world effects of a process as it executes.

Other examples of the benefits of using of X-BPMN include:

1. The ability to model advanced process measurement in terms of Key Performance Indicators (KPIs), Process Performance Indicators (PPIs), and Service Performance Indicators (SPIs)

2. The linking of Business Strategies, Business Competencies, resources, and measurements to processes, and their activities

3. The monitoring of results in Scorecards, Dashboards, and/or Cockpits

4. The identification of the duplication of business functions, processes, services, information/data, measurements, and reporting

5. The ability to run Ownership Gap Analysis (to process, service, rule, measurements) 6. The support for Business Rules Modelling and decision making support

In short, the X-BPMN enhanced process modelling capabilities enable an entirely new way of working with processes. They provide the ability to relate process models to other vital

(5)

aspects of enterprise modelling (e.g. Business Modelling, Strategy Modelling, Value, and Performance Management) and enterprise architecture (e.g. Business Architecture, Information Systems Architecture, and Technology Architecture).

(6)

Intended Audience

Individuals working in a variety of roles will be interested in applying in information presented in this LEADing Practice Standard.

Specifically:

 Business Analysts and Process eXperts, who analyze, design, implement and work with the continuous improvement of processes. This includes the examination of the

business processes to determine where potential problems and opportunities lie

 Service eXperts, who examine business services to determine where potential problems and opportunities lie for service flow and service model improvements.

 Transformation and Change Management eXperts, who work with stakeholders to design and implement large-scale organizational adjustments across the enterprise so as to implement transformational or innovative change, thus seeking to improve the alignment of the organization to its strategy and to the wants and needs of these stakeholders

 Value eXperts, who identify value expectations, drivers, wants, and needs to find and eliminate value bottlenecks within an organization so as to increase its ability to perform and to thereby better achieve its strategic outcomes

 Project Managers, who need to understand how to connect project results to organizational wants and needs

 Business Architects, which enables the standardization and integration of the process architecture with the business model e.g. the core competitive and core differentiating business competencies, the service model as well as the information and reporting aspects.

 Information eXperts and Information Architects, who need to identify and categorization information components and their relationships into a coherent

structure, so as to determine how to provide the tools for the business to control work, make decisions and verify compliance of the organization as it executes to address its wants and needs

 Enterprise Architects, who needs to identify, categorize and classify manual and automated process and their relationships into a coherent business and information system structure.

(7)

The Global University Alliance Research

Since 2004, the Global University Alliance members have researched, compared, analyzed, and developed Best and LEADing Practices in areas related to process modelling and process architecture concepts. This work included areas connected to process mapping, process relations, process rules, process measurements, process monitoring, process scorecards, process notations, linking business models to process models, and process governance, as well as other aspects such as process sustainability and information management.

Figure 1: The Global University Alliance research, comparing Enterprise Modelling, Engineering, and Architecture Frameworks, methods, and approaches.

It was in this context that the Global University Alliance conducted extensive and wide-ranging research comparing existing modelling, engineering, and architecture concepts in areas which include Business Modelling, Engineering Standards, and Process concepts, as well as Project Management, and Implementation Standards.

One of our key findings coming from this work has been that that while representing very distinct different disciplines, Enterprise Modelling, Engineering and Enterprise Architecture all contain and apply a common set of concepts, e.g. process, service, measure, reporting, etc. From this we found that, without realizing it, the biggest challenge most organizations appear to have is actually based on the fact that there is no common understanding of the true and ubiquitous nature and relationships of these objects. We found that the inability to make, understand, and exploit all aspects of the connections among these common concepts and the objects which represent them unfortunately creates the basis for double work, duplication, mismatch, confusion, siloed thinking, low standards, lots of discussions, bottlenecks, and

(8)

ultimately, high cost. On the upside, the benefits of understanding the interaction points and having common standards across these objects do not only enable performance and value creation, but also transformation and innovation.

(9)

A New Way of Thinking

Using the Global University Alliance research as a basis, a fundamental shift in the approach to totally rethink the way process modelling and process architecture has been created. The foundation for this reconceptualization was to understand which objects link and relate to aspects of process.

Using ontology and semantic concepts and principles, we identified that a process is related to sixteen main objects, as depicted in Figure 2.

This figure graphically shows the main objects within the LEAD way of thinking and how these objects relate to one another. The intent of this figure describing the high level objects is to provide a tool to capture the essential aspects of the nature of, and relations within, a business, exposing the full set of properties need to fully express well-formed connections, enabling the identification of both gaps and duplications in a process design, as well as leading to the ability to represent and model not just the business, its information and systems, but to build the necessary connections for a coherent and aligned design encompassing all aspects of the modern enterprise.

(10)

w w w . L E A D i n g P r a c t i c e . c o m 1 0

Figure 2: The 16 LEAD Process Decomposition and Composition objects.

The 16 LEAD Process Decomposition and Composition objects

An examination of the objects and connections within Figure 2 shows that within any

complete model of an organization, one would find (starting at the top of the circle a and going clockwise):

1. The business calls upon its business competencies, or organizational skills and knowledge, which are within its business model and the organisation structure, to

(11)

create value within the organization and for its customers via its processes, events, and decisions, or gateways.

2. Businessstrategies will dictate the purpose and goals which provides direction for the Process Objects. This includes business process objectives, performance

expectations, and performance indicators which can be measured and linked back to the strategy through the process performance indicators.

3. (Parts of) business, information, and data objects give substance to business Process tasks and services. A Business Process uses, modifies, and/or produces business information and data objects on several hierarchical levels; data objects with data components, Business Processes with information objects, and Business Process tasks with data services.

4. Multiple owners can have the authority to steward or manage Business Processes. All owners have specific responsibilities that result in different desires, demands, and various performance and value expectations. In the context of business process the Business Process Owners have the responsibilities connected to business tasks, process flow, service, to create value, achieve performance goals set by the strategy adhere to security, and compliance standards within the “work system”.

5. The business processes call and provide output to the Business Process flow which interacts with several different flows within the business. These flows include the business workflow, information flow, and the data flow.

6. The enacted business process roles input and call the processes through the process steps and activities so as to be supported by the roles of the respective business functions and tasks.

7. Business Process rules regulate the processes which are then instantiated in services and implemented within applications which enable these processes, data which they consume or produce, and security behaviour which must also both be adhered to and embedded within the different parts of the planning, creation, realization, and

governance processes of the Business Processes.

8. When designing, building, implementing, updating, working with, or terminating Business Process tasks, events, and services, it is essential to demonstrate the level of

control necessary to demonstrate processcompliance with respect to applicable

policies, guidelines, standards, and regulations through the use of governance controls, risk management, audits, evaluation, security, and monitoring.

9. An application is a mechanism used to automate a Business Process, and/ or its steps,

activities, events, and flows. Applications are also used to automate process reporting through the use of system measurements and system reporting.

10. The measurement indicators are the basis by which we evaluate the business

processes; their outputs, and results can all be measured. Process measurements or their automated equivalent, the system measurements, linked to business reporting (at the strategic, tactical, and operational levels) through scorecards, dashboards, and cockpits all aide in this assessment.

(12)

11. The value delivery to those that benefit from the output of a process occurs through business, and technology channels. The business channels stages can range from marketing, sales, distribution, business service and so on, While the business channels may be which the process may Input and call include offices, stores, store in store, kiosks, print media (newspapers, magazines, or fliers/ brochures), television, trade shows, social media, or other models for the delivery of value, while the technology channels, which can be consumed or used by each business channel at any channel stage may draw upon communication channels, digital image/screen, programming, broadcasting, I/O, or audio channels.

12. Process execution is the mechanism by which data are created, used, or consumed

13. Media is the mechanism which is part of any process by which inputs or outputs of a

process are held. There are many kinds of media involved within a process, for

example, paper, visual, or auditory for manual processes; screens, or even memory or disks, may act as media for automated processes.

14. A platform is a mechanism used to enable process automation; for example, a platform

component enables an application component, and a platform service enables an application service and thereby a business service. Platforms such as laptops, smart phones, or tablets are used to access processes.

15. From a Process Architecture perspective, processes are automated with dedicated technology, which use a mechanism to draw on infrastructure for their ability to execute; e.g. a process rule engine resides on infrastructure components, and infrastructure services support the platform services.

16. Business services are what actually deliver value within the organization and to its customers. They do this when they call upon and provide output to the processes necessary to instantiate them. This is because value creation is subject to the

relationships between business processes and their resources, tasks, events, and the services they deliver. While there is a distinction between manual and automated services, the division is captured within the process notations which relate the automated service to the relevant web services, application services, data services, platform services and infrastructure services and the business services to their manual counterparts.

Implications of Applying the Sixteen Process Decomposition and

Composition Objects

As demonstrated, the described sixteen process decomposition and composition objects not only have relationships to the central concept of a Business Process, they have associations and correlations with one another, leading to multiple interaction points. These objects therefore provide an important tool to assess any aspect of the description of operations of a business. Basically, when examining any process, whether it is actually executing or part of a design, each and every one of these sixteen aspects are necessary for a complete specification. To the extent the process is missing one or more of these essential objects in its relationships, it will be malformed and incomplete.

(13)

It should be possible to see that this approach provides a power tool to assist in the

identification and capture of each relevant aspect of a process correctly, therefore rethinking the nature and value in process modelling as it has existed.

Recognizing the importance and the uniqueness drawn from the use of this approach and driven by passion and love for both Enterprise Modelling and Enterprise Architecture, we started to develop the missing process modelling gaps and aspects: in essence, defining a new Way of Working.

(14)

The Development of eXtended BPMN

The insight into the process decomposition and composition objects becomes the basis of a new Way of Working with the elements of work, providing the tools to enable business process modelling practice and therefore eventually to understand issues around BPMN and why the results flowing from its use were so often disappointing both for practitioners and for businesses attempting to gain insight from its implementation.

The work on developing a version of BPMN that would address the shortfalls and opportunities in the findings from the research started in 2004, with the first version of LEADing Practice (LEAD 1.0) process reference framework which was based on university research, analysis, comparison as well as practical experience gained in working with many organizations being challenged with the way work was being executed. Continuing work through the University Alliance on Enterprise Modelling and Enterprise Architecture

research, analysis and comparison yielded a more standardized release of LEAD 2.0 (2009). The work included the packaging of the academic research into both:

1. A Business Process Management University curriculum at both the Bachelor’s and Master’s level. This has been adopted by hundreds of universities around the world and incorporated into the program of the Global SAP® University Alliance - read more

here.

2. A Process Reference framework of methods and approaches to be used across the private and public sector alike. - read more here.

The process modelling principles captured significant interest from software vendors such as SAP® AG, IBM®, Software AG® (IDS Scheer’s ARIS®), and iGrafx® , who have each

investigated and incorporated, in varying degrees, our modelling insights into their methods and/ or meta models. Some of these vendors have used the entire process reference

framework, while others have adopted only limited portions, such as the LEAD process meta model or the eXtended BPMN concepts. Below is a short overview of the fast industry

adoption to date:

 2010: LEAD process principles are presented at the IDS Scheer, ARIS Process World

 2010: an SAP book is published, using LEAD principles: Taylor, J, von Rosing, M., von Scheel, H., Rosenberg, A., Applying Real-World BPM in an SAP Environment, Issue Date: 2011-01, Published by: SAP Press, ISBN: 978-1-59229-343-8, Page(s): 694

 2011: The Institute of Electrical and Electronics Engineers publishes a paper based on the research and findings around combining BPM and Enterprise Architecture principles: Presten, T., Hove, M., von Rosing, M., Academic paper on Combining BPM and EA in Complex IT Projects, Published by: IEEE Commerce and Enterprise Computing Page(s): 271 - 278, Issue Date: 2011-05

 2010-2012: the Global University Alliance collaborates with TOGAF (The Open Group Architecture Framework) to develop the profession of a Business Architect; this included the process modelling and architecture principles

(15)

 2010-2011: SAP adopts LEAD process modelling principles into their SAP ASAP Method, thereby SAP customers apply the LEADing Practice process modelling and architecture concepts within their blueprint, implementation, maintenance and upgrade methods and approaches

 2011-2012: Software AG /IDS Scheer enhaces their ARIS process modelling meta model, based on the LEADing Practice process modelling and architecture concepts

 2012: the Government of Canada, uses the LEADing Practice process modelling and

architecture concepts to transform their organization as well as blueprint/implement SAP and Oracle® ERP systems

 2012-2013: IBM builds the LEADing Practice process modelling and architecture concepts into theRational® suite software,enabling advanced System Architecture modelling

 2012-2013: iGrafx builds the entire LEADing Practice process modelling and architecture concepts into their, process modelling, performance management, and enterprise

modelling software

 2013: LEGO Group wins the Gartner Group‘s BPM award: Best BPM Transformation by leveraging the LEADing Practice principles

Overwhelmed by the speed of adoption, and surprised by recognition as a Process Modelling and Process Architecture paradigm shift by leading companies and the IT community at large, we realized we had something unique. The development of the eXtended Business Process Modelling standard was added to enhance the existing way of working with process as captured by BPMN.

(16)

A New Way of Working

The LEADing Practice Way of Working is the critical discipline of translating the identified requirements into a form that will allow further work to be carried out on them. It structures the arrangement of effort and work, by translating the “Way of Thinking” into a structural approach of acting.

The Way of Working organizes, classifies, aligns, arranges, quantifies, recommends, and selects the relevant and related aspects of objects and / or artifacts in the systemized and categorized way they need to be de-composed or composed together. One of the big

challenges with fully describing business processes is to understand the multiple flows which are connected to process and how they are connected. These flows, which include information flows, service flows, reporting flows, and rule flows are all separate and distinct from the sequencing of work captured within the process flow.

Although the additional flows exist in their own right and are features of modern businesses using automation (.i.e. an ERP can detect a process, or conditions of a process which triggers and information or reporting flow and carry out the necessary action), the opportunity to capture and exploit this is lost because of limitations within our ability to describe the desired behaviour.

Our leading practice analysis shows that requirements related to core competitive or differentiated aspects of the enterprise will constitute about 5% of the total set of

requirements. The non-core conceptual aspects are critical, particularly for organizations that to expose where it would be prudent to standardize, optimize and focus on cost cutting.

BPMN, what is it, what is it not

Business process modelling is the discipline of graphically representing a process in a readable diagram. The Business Process Modelling Notation (BPMN) is a graphical notation that depicts the steps of business processes in an end-to-end flow. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. Created by the Business

Process Management Institute (BPMI), in March, 2001, BPMI members began discussing

the idea of creating a notation that aligned to executable BPML.

In August 2004, the BPMN 1.0 specification was released to the public and it is now

maintained by the Object Management Group (OMG). This followed with the release of the BPMN 2.0 specification to the public in January 2011. BPMN 2.0 is a standard for business process modelling that provides a graphical notation for expressing and specifying business processes in a Business Process Diagram (BPD), based on a flowcharting technique, a manner very similar to activity diagrams from Unified Modelling Language (UML). The objective of BPMN is to support business process management, for both technical users and business users, by providing a notation that is intuitive to business users, yet able to represent complex process semantics.

(17)

The BPMN specification also provides a mapping between the graphics of the notation and the underlying constructs of execution languages, particularly Business Process Execution

Language (BPEL). The primary goal of BPMN is to provide a standard notation readily

understandable by all business stakeholders. These include the business analysts who create and refine the processes, the technical developers responsible for implementing them, and the business managers who monitor and manage them. Consequently, BPMN serves as a common language, bridging the communication gap that frequently occurs between business process design and implementation. While the Global University Alliance members realized that while BPMN is the standard in the market, we were forced to acknowledge that the BPMN standard itself had critical gaps and lacked the ability to express key concepts which we saw as

essential in the context of Enterprise Modelling and Enterprise Architecture. These deficiencies meant that with BPMN 2.0, a modeller could not:

 Specify the difference between manual and automated Tasks

 Specify the difference between manual and automated Services

 Link processes to Strategies

 Define Relationship between Business Competencies and Processes

 Specify Measurements and reporting aspects

 Define Rulesets (business, application, etc.)

 Define decisions based on the number of given conditions/actions

 Classify Business Objects of any kind

 Specify Information Objects

eXtended BPMN Shapes

The notational deficiencies described above limited the utility of BPMN or practical process mapping and modelling for much of how business process notations should or could be used, e.g.business process modelling, process transformation, software blueprint, etc. As a matter of fact, we believe that the BPMN 2.0 standard actually makes siloed thinking worse in that it tends to cause analysts to only consider processes (and therefore the process models) within a very narrow perspective and to not consider other aspects of work and the business which relate to the process. To fill this gap, the Global University Alliance, together with the LEADing Practice community, developed the eXtended BPMN standard to enhance the expressiveness of the existing BPMN 2.0 specification. While the eXtended BPMN icons build upon the existing BPMN 2.0 specification, they include linkage to aspects such as:

1. Business Competencies (added in January 2011). 2. Service Mapping (added in January 2011). 3. Interaction models (added in March 2011).

(18)

4. RACI Mapping (added in May 2011).

5. Value Mapping and thereby links to strategy, critical success factors, and objectives (added in November 2011).

6. Advanced Rules modelling (added in December 2011). 7. Decision making aspects (added in December 2011). 8. SAP Netweaver® connection (added in January 2012)

9. ERP connection, in terms of which objects can be reused for ERP implementation, e.g. SAP Solution Manager® (added in February 2012)

(19)

Below are the shape types of BPMN and eXtended BPMN:

BPMN 2.0 eXtended

BPMN Description (and description source)

Icon Company (and product) or Organization

LEADing Practice, eXtended BPMN Specification

Object Management Group, BPMN 2.0 Specification

SAP Netweaver Rules Composer Oracle Business Rules

IBM® WebSphere Decision Center V8.0 Microsoft®.NET Framework

None None

No special Task Type is indicated.

User Task User Task

A User Task is a typical “workflow” Task where a human performer performs the Task with the

assistance of a software application and is scheduled through a task list manager of some sort.

A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or application.

(20)

Manual Task Manual Task

Automated Task

An automated task is an activity that is automated either through a business process execution engine or any application, e.g. using application features and functions to perform the application task.

Service Task

A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application.

Manual Service

A manual service is when the service is performed by a human.

Automated Service

An automated service could be ether an application service, data service, platform service, infrastructure service, or a Web Service.

Receive Task _{Receive Task}

A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external

(21)

Send Send

A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process).

Script Script

A Script Task is executed by a business process engine. The modeller or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.

Business Rule Business Rule

A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide. The input/output

specification of the Task will allow the Process to send data to and receive data from the Business Rules Engine.

The following table shows the additional shapes incorporated into eXtended BPMN, at the same time showing how the concepts which these shapes represent are included in the logic, language, and practice of modern business, while not being addressed or supported within BPMN 2.0.

NOTE: As specified by the OMG BPMN 2.02 standard is there a flexibility in the size, color, line

style, and text positions of the defined graphical elements. The following extensions to a

BPMN Diagram are permitted1_:

 New markers or indicators MAY be added to the specified graphical elements. These markers or indicators could be used to highlight a specific attribute of a BPMN element or to represent a new subtype of the corresponding concept.

(22)

 A new shape representing a kind of Artifact MAY be added to a Diagram, but the new

Artifact shape SHALL NOT conflict with the shape specified for any other BPMN

element or marker.

 Graphical elements MAY be colored, and the coloring MAY have specified semantics that extend the information conveyed by the element as specified in this International Standard.

 The line style of a graphical element MAY be changed, but that change SHALL NOT conflict with any other line style REQUIRED by this International Standard.

 An extension SHALL NOT change the specified shape of a defined graphical element or marker (e.g., changing a square into a triangle, or changing rounded corners into squared corners, etc.).

For each shape the use of the object within the eXtended BPMN is identified and the current alternative interpretation of what the symbol means by major vendors. The fact that major vendors see each of these objects to be part of what is needed to express some aspect of a process shows in effect that our research is correct and reinforces the necessity that the objects be recognized as part of a complete process standard.

eXtended

BPMN shapes2

The description of the shapes and who uses them (and how):

Ruleset

A Ruleset is a collection and therefore a grouping of rules. These groupings may be based on common related rules, decisions tables, or the need to govern a specific set or behavior of tasks. Grouping rulesets allows for sharing of rules and execution by for example a rule engine.

A Ruleset is a logical collection of rules. A ruleset helps you group

business rules that govern a specific function. A ruleset consists of: If-Then Rules, Decision Tables.

A Ruleset is a container that includes definitions for a group of related rules and decision tables. A ruleset provides a unit of execution for rules and for Decision Tables. In addition, rulesets provide a unit of sharing for rules; rules belong to a ruleset.

A ruleset is a set of rules and rule artifacts that can be executed by

(23)

w w w . L E A D i n g P r a c t i c e . c o m 2 3 eXtended

BPMN shapes2

the engine.

Contains a collection of Rule classes along with the semantics for forward-chaining execution of those rules. A RuleSet can be executed directly in code or using the PolicyActivity activity.

Decision Table

Decision tables identify a set of decisions based a series of given conditions and possible actions. Decision tables allow to work from the same information and are therefore a precise way to model complicated logic and associate.

A decision table can either be a tabular representation of related rules or a precise yet compact way to map complicated logic. Decision tables, like flowcharts and if-then-else and switch-case statements,

associate conditions with actions to perform, but in many cases do so in a more elegant way.

An example of using a Decision table is an activity to evaluate based

on the region and the total amount of the order, whether or not the approval of a supervisor is required. Would be good to have this as a reusable Task instead of embedded in the Gateway. The Gateway can then just do the branching. Could include a link to a spreadsheet for example.

Decision tables provide an alternative way of viewing and managing large sets of symmetric business rules. A decision table contains

condition columns and actions columns Reference to Business Rules

here.

Decision tables are a simple and clean method of representing large sets of business rules

Rule Flow

Rule flows are comprised of linked tasks that contain the instructions as to which rule of a set of rules is to be executed and in what order. The rules are organized into tasks. The ruleflow specifies how tasks are chained together: how, when, and under what conditions they are executed.

When you are dealing with many large rule sets, managing the order in which rules are evaluated can become complex. The use of a Rule Flow allows you to specify the order in which rule sets are to be evaluated. It does so by providing you with a flow chart. You will be able to use this chart to define which rule sets should be evaluated in sequence and

(24)

BPMN shapes2

which in parallel, and to specify conditions under which rule sets should be evaluated. The reuse of rules components and their natural relations, like activity association, are an important aspect of rule modelling. This approach allows for consistency when expressing rules through

modelling between the different rule artifacts from the rule flows, rule scripts, rule sets, flow rule sets, rules, and decision tables. To do

advanced rule modelling it might be necessary to categorize some of the rules into main and sub rules.

A business may contain many rule flows, one of which must be identified as the main rule flow of the project or area. Additional rule flows could then be added and modelled from the main rule flow. Other rule flows are then included through sub flow tasks.

A Rule Flow is a sequence of activities for evaluating business rules.

The order of the execution of the rules is diagrammatically represented in the form of a flow chart. It is a reusable entity within a flow ruleset, and is based on activities associated with artifacts such as rule scripts, rule flows, rulesets, flow rulesets, rules, and decision tables.

Multiple rulesets can be executed in order. This is called rule flow. The ruleset stack determines the order. The order can be manipulated by rule actions that push and pop rulesets on the stack. In rulesets, the priority of rules applies to specify the order in which the rules in the ruleset are applied or “fired”. Rulesets also provide an effective data specification that identifies that the ruleset is always active, or that the ruleset is restricted based on a time and date range, or a starting or ending time and date.

A ruleflow defines the flow of execution of the rules. The rules are organized into tasks and the ruleflow specifies how tasks are chained together: how, when, and under what conditions they are executed.

Rule Script

A Rule Script allows you to generate a rule in a scripting

environment. This is done through the connection of other activities and the rules that govern these relations and the actions between them. Rule Scripts can furthermore be used with script types and automated test rules, e.g. configurable, programmed, query and event-based network alerts. The link between rule scripts and the mentioned script type could be used as template–based query that can be run against backend tables or database views.

A Rule Script is a reusable artifact within a flow ruleset and is a

sequence of actions. It is associated with other activities in a flow ruleset, and is triggered when the conditions listed in the preceding activities are

(25)

BPMN shapes2

satisfied. A rule script can contain any of the following action types: Assign Action, Assert Action, Evaluate Decision, Table Action, Execute Action, Execute Ruleset Action, Execute Rule Action, For Each Action, If Else, If Action, While Action, Retract Action, Break and Continue Actions.

The RuleScript allows to generate a rule from a scripting environment.

Rule

Rules are statements describing a business policy or decision procedure. Some programming languages run business rules together into very complex algorithms. In business process analysis, each rule is usually stated independently, in the general format: If A and B, Then C. Workflow tools and detailed process diagrams both depend on business rules to specify how decisions are made. We generally associate business rules with activities. A decision table is adequate to show what happens if “A” or “B” happens, but dozens or even hundreds of business rules may need to be defined to clarify if “A” or “B” should occur. Training

programs, job aids, software systems and knowledge management systems aim to document business rules either to automate the decision process or to and make the rules available to other decision makers.

A Rule is a set of conditions and associated actions that are

performed when the conditions are satisfied. Rules can be written in two forms: If and then statements, and Decision Tables.

Business rules are statements that describe business policies or describe key business decisions.

An action rule is made of a condition part and of an action part. The first part of the rule defines the condition in which the rule applies. The second part of the rule defines the action to take if the condition of the rule is true

Defines a condition with an associated set of actions to perform. Rules can be related to:

 Active: Gets or sets a value that indicates whether the Rule should be evaluated.

 Condition: Gets or sets a RuleCondition for the Rule to evaluate.

 Description: Gets or sets a description of the Rule.

(26)

BPMN shapes2

the ELSE case.

 Name: Gets or sets the name of the Rule.

 Priority: Gets or sets a value that indicates the order in which a Rule should be run.

 Re-evaluation: Behavior Gets or sets a value indicating whether a Rule can be re-evaluated.

 ThenActions: Gets a collection of RuleAction classes to perform in the THEN case.

Flow Ruleset

A flow ruleset is a collection or grouping of rules that apply to a common flow. These flow rulesets are ether grouped based on common related rules in the flow, decisions tables or the need to govern a specific set or behavior of tasks in the flow. Grouping such flow rulesets allows for sharing of rules and execution, by a rule engine throughout the entire flow. As well as the relation to the reuse of such rulesets in other flows, starting from the main flow where the ruleset are applied.

Flow Ruleset is a ruleset that allows you to group business rules that

need to be executed as in a flow chart. It always has one flow, designated as main flow, besides possibly many other rule flows. The execution of the Flow Ruleset starts with the main flow. A Flow Ruleset consists of: Aliases, Definition, Rule Flow, Rule Scripts, If-Then Rules, Decision Tables

Notification

An instance of a message delivered to one or more recipients. A notification activity sends a message to a user, both the recipients and the content need to be specified. Notification Activities furthermore allow flow rulesets to be applied in order to notify users of events that occur during the workflow.

A notification provides often through technology a means of delivering a message to a set of recipients. To deploy a notification it is necessary to specify the recipients and then parameterize the subject and message that are to be sent. For example: A notification is to be used to send e-mail notifications from the process. To do this you would specify the recipients, the subject, and message texts that are to be sent through the use of parameters.

The notification task allows you to send different types of notifications to the users of the application.

(27)

BPMN shapes2

Mapping

Mapping activities includes identifying, defining, and plotting the business, information, and data objects involved in an activity. This allows the identification of possible grouping of common business, information, and data objects and their associated rules, e.g. ruleset. Enabling the change of complex objects and views into more simple views.

A mapping activity can be used to transform complex objects into more simple views, e.g. map data from data objects in the specific process context making it more simple data. Rules set can be used as a transform in a mapping activity. To make the mapping activity work, the mappings between the business, information, and data objects in the process context need to be defined.

Reporting

Reporting is the exposure, description and portrayal of specific tasks, services and their associated information/ data. The information and data objects source can bind with the reporting activity the process components to the specific cockpits, dashboards, or scorecards.

To illustrate and express what is happening or what has happened and could include timely collection, analysis, and then reporting of the information within the process. Depending on whether the reporting is real time reporting or after the fact reporting, the input mapping of the information to the reports needs to be specified.

A reporting activity is used to collect data and information so as to perform analytics on this data. The reporting activity references a

reporting data source and indicates where in the process data is gathered for reporting. An input mapping needs to be defined for the reporting activity to specify which data from the process context is collected by the reporting activity. Business Objects Collection of Business Objects

A Business Object is a real-world thing having business

significance that is used to maintain a persistent source of information or the state of a business process examples include “ people”, “employee”, “products”, or instances of these objects such as a sales order, or a customer and (amount of ) revenue (in a context).

Business Objects may be used for example in business, process, or service mapping and/ or in application implementations, where they are used as a semantic layer that shields users from the complexities of information table names and data relationships.

(28)

BPMN shapes2

Business Input

Business Output

Business Store

Below are the graphical depictions of Business Objects used in business modelling, process mapping, or service mapping as well as in application and architectural mapping, e.g. business architecture, application

architecture, and solution architecture:

 Business Object - Represents real-world objects like people,

employee, products or a sales order, customer, and (amount of) revenue (in a context).

 Collection of Business Objects - Represents a collection of

real-world objects, e.g. an employee roles.

 Business Input - Is an external input for the real-world objects. A

kind of input parameter.

 Business Output - Is the real-world result of the entire process

and/ or service flow. A kind of output parameter.

 Business Store - The place the business objects are stored

Information Object Collection of Information Objects Information Input Information Output Information

An Information Object is used to specify information about real-world objects (people, employee, products, or a sales order, etc.) and therefore it is the digital representation of an existing entity in an Information System, e.g. Oracle ERP or SAP.

It encompasses both the business information (in the form of functions and methods) and the application information (in the form of attributes) of this entity. Information Objects can be found and therefore modelled in business functions, business service, or in processes.

Below are the graphical depictions of Information Objects used in business modelling, process mapping, service mapping as well as in application, and architectural mapping, e.g. business architecture, information architecture, application architecture, and solution architecture:

 Information Object - Represents a container of information

within the flow of the process and/ or service, such as business documents, e-mails, or letters.

 Collection of Information Objects - Represents a collection of

information, e.g. a list of order items.

(29)

BPMN shapes2

Store entire process. A kind of input parameter.

 Information Output - Is the information output/result of the

entire process. A kind of output parameter.

 Information Store - Is a place where the information can be read

or written, e.g. knowledge management or a filing cabinet. It persists beyond the lifetime of the process instance.

Data Object Collection of Data Objects Data Input Data Output Data Store

A Data Object is a logical cluster of all tables in the data set that have one or more columns containing data related to the same business entity. Data objects are not maps, but instead represent an object view of related Information Objects that represent Business Objects.

Below are the graphical depictions of Data Objects used in process mapping, service mapping as well as in application and architectural mapping, e.g. information architecture, application architecture, solution architecture, and data architecture:

 Data Object - Represents a container/logical cluster of all tables

in the data set that have one or more columns containing data related to the same data entity, such as business documents, e-mails, or letters.

 Collection of Data Objects - Represents a collection of data

tables/columns containing data related to the same data entity, e.g. a list of order items.

 Data Input - Is an external data input for the entire process. A

kind of input parameter.

 Data Output - Is the data result of the entire process. A kind of

output parameter.

 Data Store - Is a place where the process can read or write data,

e.g. a database or a filing cabinet. It persists beyond the lifetime of the process instance.

(30)

A New Way of Modelling

As we have seen, the creation of the extended BPMN notation was motivated by a need to enable the more complete expression of business processes through more complete models and architectural descriptions. For this reason, the notational elements were designed to be intuitive for business users, yet expressive enough for technical users to represent complex process semantics and relationships in well-formed and repeatable complete representations of the process.

Applying eXtended BPMN

In this section, each of the 16 decomposition and composition objects identified in the Chapter on A New Way of Thinking are examined from the perspective of how they are supported with eXtended BPMN Notation. Examples are illustrated using the iGrafx process and enterprise modeling applications in a call center example.

1. Within the business model of any organization, one will find the relevant business competencies being identified and calling upon their respective processes.

By exercising its business competencies, the business delivers value internally and externally, e.g. value is delivered through business tasks, business functions, and services within a competency to those that benefit from the value created.

Competencies may be essential to compete, in which case they are described as “core competitive”; or they may differentiate the business for its customers, in which case they are “core differentiating”; or they may simply be necessary for the functioning of the business. The ability to categorize competencies as either “core differentiated”, “core competitive”, or “non-core” is missing within contemporary process modelling and process architecture practice. The inability to categorize competencies is the very reason why process experts and process architects have no insight as to which

processes are a part of an organization’s competitive aspects and which are not. This is also why they are not able to take into consideration the design target of a process and therefore ensure the process performs to its requirements.

As it is necessary to relate processes to the value and performance drivers of the organization and therefore shape the design of the process with these considerations in mind, this insight is critical.

The link between the organisation’s competencies and process execution provides the means of identifying ways to appropriately reduce cost, improve the effectiveness and efficiency of operations, or conversely to support revenue growth. Without this context there is no means to judge the “goodness” of a particular process or process design. It is for example not possible to detect that a process does not contribute value, thus is best done is the cheapest way possible, or that it produces great value to business, therefore warranting features to maximize value to the organization. With the eXtended BPMN standard an organization can not only capture the business

competencies, but relate them to the organization’s specific Value and Performance Drivers; providing significant context to process owners, designer, and to the organization as a whole.

In Figure 3: Example of relating Competencies to Performance Drivers; we see how the Service Call Center (group) is identified as requiring a Communications competency, and the Communications competency is fulfilling 2 KPIs: Average direct cost and average employee cost per incoming phone call.

(31)

Figure 3: Example of relating Competencies to Performance Drivers in iGrafx®.

2. Businessstrategies will dictate the purpose and goals that set the direction for an organization’s processes. Business Process objectives, performance expectations, and performance indicators, and therefore the extent to which the desired direction is achieved, is measured and linked to strategy through Process Performance Indicators (PPIs).

In the context of LEADing Practice Modelling principles, a strategy is a defined goal that an organization wants to achieve to make its strategic execution succeed. These goals guide and shape the application of Strategic Business Objectives (SBOs) and Critical Success Factors (CSFs) to the relevant business competencies. Contrary to older approaches to strategic thinking, in this model it is understood that an

organization can simultaneously pursue multiple strategies and goals. For example an organization can pursue both high growth and profits by defining unique critical success factors that break the conventional value-cost trade off by simultaneously pursuing both differentiation in the market and low cost in its operations.

An example of how strategic business objective, critical success factors and the organizational competencies they are related to might be something like this.

Business SBOs CSFs Business Competencies

Improve Competitiveness

Improve Responsiveness Business Assets

Shorten Time-to-Market Business Development Strengthen Innovation Product management Improve Customer Interaction Sales & Service Improve Partner

Collaboration Business Assets

(32)

In this example the strategic business objective, Improve Competitiveness, is an

organizational objective. The factors that the organization has identified as critical to the success of this strategy are its CSFs, which are allocated to specific business competencies within the organization; the competency “Business Assets” will focus on “improved

responsiveness”, and need to develop processes that improve its responsiveness, while simultaneously finding ways to cut the cost of processes that cannot add to its improved responsiveness. A similar model and decision choices can be made by each other competency within the business. The result is, where processes make a difference to the competencies’ ability to perform in a manner that differentiates enterprise performance, its processes will focus on doing things well. Where no such contribution is possible, but the process must be done, the goal will then be to execute for as little cost as possible.

As there is always an element of uncertainty about the future, strategies, goals, and objectives in essence create a set of "strategic choices" that need to be related from the strategic level to the relevant business competencies, which are then responsible to align their execution in order to realize the planned value.

In Figure 4: Example of relating the Strategic Business Objectives and Critical Success Factors to the responsible owner (RACI),who will be measured by the degree to which he / she achieves two goals, the average direct costs per incoming phone call, and the average employee costs per incoming phone call.

Assuming these were the performance measures of the Service Call Center, a process analyst now has a meaningful context for any process design and could look for ways within the Service Call Center Design to achieve those goals. For example, in our scenario, with only these measures, the process would not consider customer satisfaction, etc.

Figure 4: Example of relating the Strategic Business Objectives and Critical Success Factors to the responsible owner (RACI), in iGrafx®.

3. Business Process tasks and services create, use, and/or deliver (parts of) business, information, and data objects, thus giving substance to the process. Within LEAD, the way of working with objects requires that the expert or architect identify if the item of interest is a business, information, and/ or a data object. Identifying and classifying the

(33)

different objects is very relevant as it provides the means to use process notations for the realization of executable applications and software solutions. This includes relating the objects to the organization, roles, rules, and compliance aspects, as well as,

business and information flow. The set of rules and modelling techniques associated with identifying, designing, and relating business, information, and data object types allows one to fully describe the different relevant object’s behavior and representation. Understanding this behavior might include an analysis of the business function, roles and services it delivers. Additionally, its interaction with the business process and activities (input and output and the associated flow), information (objects, flow), applications (function, task, service and flow) and data (objects, entities, data services, and data flow) is needed to produce accurate and useful process and service models. Figure 5 presents an example of such an eXtended BPMN diagram. This example contains business, information, and data objects; identifying “issue”, “caller info”, and “survey”, respectively.

Figure 5: Example of business, information, and data objects.

The ability of having a link between the models of understanding e.g. the process models and thereby the BPMN diagrams and the models of executions e.g. in software development it would be UML and if an ERP system exist it would for example be SAP. Such a link between the BPMN diagrams and SAP solution manager include linking/redocumenting information / data flow in SAP SolMan, includes mapping the business/data/information object artifacts to bindings in interface scenarios in SolMan. In order to drill down the various topics that may arise, the main aspect is to identify the matching fields in SAP Solution Manager. It must be clear, research and development starts whether SAP Solution Manager and the SAP Gateway supports addressing the data.

(34)