The LEADing Practice. extended BPMN Standard. Relating Objects

Transcription

1 The LEADing Practice extended BPMN Standard Relating Objects

2 Table of Contents The LEADing Practice... 1 Introduction... 3 Intended Audience... 6 The Global University Alliance Research... 7 A New Way of Thinking... 9 The 16 LEAD Process Decomposition and Composition objects Implications of Applying the Sixteen Process Decomposition and Composition Objects. 12 The Development of extended BPMN A New Way of Working BPMN, what is it, what is it not extended BPMN Shapes A New Way of Modelling Applying extended BPMN The link between Process Modelling and Architecture Using the extended BPMN Standard for Architectural work Conclusion Copyright note on Intellectual Capital: All rights reserved Guidelines for LEAD community members using the IPR material Guidelines for non-lead community members using the IPR material General guidelines that apply for all LEAD IPR material w w w.leadingpractice.com 2

3 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. w w w.leadingpractice.com 3

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 w w w.leadingpractice.com 4

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). w w w.leadingpractice.com 5

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. w w w.leadingpractice.com 6

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 wideranging 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 w w w.leadingpractice.com 7

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. w w w.leadingpractice.com 8

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. w w w.leadingpractice.com 9

10 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 w w w.leadingpractice.com 10

11 create value within the organization and for its customers via its processes, events, and decisions, or gateways. 2. Business strategies 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 process compliance 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. w w w.leadingpractice.com 11

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. w w w.leadingpractice.com 12

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. w w w.leadingpractice.com 13

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: , Published by: SAP Press, ISBN: , Page(s): : 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): , Issue Date: : 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 w w w.leadingpractice.com 14

15 : 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 : 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 : IBM builds the LEADing Practice process modelling and architecture concepts into therational suite software,enabling advanced System Architecture modelling : 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. w w w.leadingpractice.com 15

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 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. w w w.leadingpractice.com 16

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). w w w.leadingpractice.com 17

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) 10. Measurements (KPIs, PPIs & SPIs) and link to reporting (added in May 2012) w w w.leadingpractice.com 18

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 No special Task Type is indicated. None None 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. User Task User Task A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or application. w w w.leadingpractice.com 19

20 BPMN 2.0 Manual Task extended BPMN Manual Task Description (and description source) 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. A manual service is when the service is performed by a human. Manual Service An automated service could be ether an application service, data service, platform service, infrastructure service, or a Web Service. Automated Service A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Receive Task Receive Task w w w.leadingpractice.com 20

21 BPMN 2.0 extended BPMN Description (and description source) A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Send Send 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 permitted 1 : 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. 1 w w w.leadingpractice.com 21

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 shapes 2 The description of the shapes and who uses them (and how): 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. Ruleset 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 2 these are not available in BPMN 2.0 w w w.leadingpractice.com 22

23 extended BPMN shapes 2 The description of the shapes and who uses them (and how): 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 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. Decision Table 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 w w w.leadingpractice.com 23

24 extended BPMN shapes 2 The description of the shapes and who uses them (and how): 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 w w w.leadingpractice.com 24

25 extended BPMN shapes 2 The description of the shapes and who uses them (and how): 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. ElseActions: Gets a collection of RuleAction classes to perform in w w w.leadingpractice.com 25

26 extended BPMN shapes 2 The description of the shapes and who uses them (and how): 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 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. w w w.leadingpractice.com 26

27 extended BPMN shapes 2 The description of the shapes and who uses them (and how): 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. w w w.leadingpractice.com 27

28 extended BPMN shapes 2 Business Input The description of the shapes and who uses them (and how): 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 Output Business Store 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 realworld 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 An Information Object is used to specify information about realworld 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 Output Information Information Object - Represents a container of information within the flow of the process and/ or service, such as business documents, s, or letters. Collection of Information Objects - Represents a collection of information, e.g. a list of order items. Information Input - Is an external information input for the w w w.leadingpractice.com 28

29 extended BPMN shapes 2 Store The description of the shapes and who uses them (and how): 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 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 Input Data Output Data Store 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. w w w.leadingpractice.com 29

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. w w w.leadingpractice.com 30

31 Figure 3: Example of relating Competencies to Performance Drivers in igrafx. 2. Business strategies 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 Strengthen Innovation Improve Customer Interaction Improve Partner Collaboration Improve Brand Awareness Business Development Product management Sales & Service Business Assets Sales & Service w w w.leadingpractice.com 31

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 w w w.leadingpractice.com 32

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. w w w.leadingpractice.com 33

34 Related topics: In order to do this the process tool needs to be able to model and handle the Business Objects, Information objects and Data Objects as hierarchy. This enables the ability to synchronize with the modeling client and the process repository, the order of the Workproducts offered by synchronization will be as follows: Step 1) Define the Business Objects, Information objects and Data Objects as hierarchy Figure 6: Example of business, information, and data objects in a hierarchy. Step 2) make sure that the hierarchy of the Business Objects, Information Objects and Data Objects also exist in your process hierarchy Figure 7: Example of business, information, and data objects in a process hierarchy. w w w.leadingpractice.com 34

35 Step 3) Check the hierarchy of the Business Objects, Information Objects and Data Objects in your process diagrams: Figure 8: Example of business, information, and data objects in the BPMN/process diagrams. 4. Different owners can be allocated within a business process; however, broader aspects of ownership within and around a process need to be considered and related, for example: Owners with responsibilities for the strategy and objectives Owners with responsibilities for measurements Owners with responsibilities for business functions Owners with responsibilities for business processes Owners with responsibilities for services Information owners in terms of being responsible for the reports, scorecards, dashboards and/ or cockpits etc. All owners have responsibilities for their specific area in terms of meeting different performance and/ or value demands/outcomes. What output should this business function, process or service produce? What impact should the output have on the organization? The various owners are for the most part measured through performance dimensions. These performance dimensions also serve as the basis for assessing employee performance of the roles involved in different owner s areas. The ability to link the multiple areas together, from strategy to execution and to identify where the possible gaps are, enable an entirely new approach for strategy execution and tracking. w w w.leadingpractice.com 35

36 While Figure 4 earlier showed the linkage of a role to a performance measure, Figure 6 portrays a map showing how specific SBOs, CFSs, and KPI are each allocated to a responsible role. It is this role, or owner, who is responsible for the performance of the specific processes and is the one who is measured on the total performance each process they are responsible for. The latter figure shows that the CFO and Call Center Manager are jointly responsible for the cost per minute of handle time. Figure 6: Example of Ownership relations, including Strategy, CSF, KPI and RACI relations. 5. One of the challenges in working with process flows is that many organizations and practitioners do not recognize their unique characteristics; they mistakenly believe that a process flow is the same as an information and/or data flow. While the process flow interacts with several different flows, it is vital to understand that it has its own identity and is not the same as the business workflow, the information flow, or the data flow. A business workflow, is a sequence of business functions, which usually involve multiple tasks and resources that deliver a specific set of outcomes. Simply put, the business workflow consists of a sequence of connected tasks where the outcomes/output of one serves as input, without delay or gap, to the next task in the workflow. In a general sense, information is the digital representation of an existing real-world object (people, employees, products, or a sales order, etc.). The information flow therefore represents the sequence of input and output of information objects and the specific tasks that need them to execute. Information objects represent business objects and can be mapped to underlying data objects housed within information systems. w w w.leadingpractice.com 36

37 The data flow is related to the flow of data objects, either in terms of either the logical relations or the clusters containing data related to the same entity. As shown in figure 7, the extended BPMN notation is used to depict business, information and data flows within the processes and sub-processes. Figure 7: Example of capturing multiple flows within a process. Each of the flows capture a different perspective of the object and therefore is subject to the application of different modelling principles and skills. It is essential to be able to sort the specific business, information and data objects by roles, tasks, services or rules. This not only enables the identification of duplication, but enables modelling of the business, its information and systems; see Figure 8 for an example. w w w.leadingpractice.com 37

38 Figure 8: Example of sorting of business, information and data objects by roles, tasks, services or rules. 6. The process roles assigned to process steps and activities have to be supported by the business roles of the respective business functions and tasks. In the context of LEAD Modelling, a process role refers to the usual or expected function of an actor, or the participation of somebody or something playing a part in a business process context, e.g. a process owner has a business role that has specific business functions and tasks. An actor may have a number of business process roles and at times constraints are imposed on a role performing some aspect of the process or activity. These constraints are defined by a law, regulation, directive, instruction, or parameter that is imposed via an assertion. The extended BPMN notation allows for the identification of duplication of roles within business functions, processes, services, information systems, etc. Figure 9 illustrates how roles can be leveraged within a process model and that the design can even be evaluated in a simulation environment to perform what-if analysis and to assess design alternatives. Here, changes to resource utilizations in simulated scenarios generate results that can be compared side by side. w w w.leadingpractice.com 38

39 Figure 9: Example of resource duplication and Cost Cutting scenarios for Resource As Is and What If To Be Changes, using igrafx simulation. 7. Several business process rules, which apply to processes, but may as well also apply to services, applications, data, and security, must be adhered to and embedded in the different phases of the business process lifecycle: planning, creation, realization, and governance. The reality today is that organizations have many rules that must be properly and consistently applied to different business areas, services, and applications across the business. The extended BPMN standard allows for advanced rules modelling in all the aforementioned areas, including modelling rule flow, ruleset, rule script, etc. When dealing with various rules, managing where they need to be applied and in which order the rules are evaluated can become quite complex. Figure 10 illustrates how a Business Rule Flow allows one to specify the order in which rule sets are to be evaluated. Another feature of this approach is that it supports re the reuse of rules components and their natural relations. This allows for rule modelling consistency between the different rule artifacts: rule flows, rule scripts, rule sets, flow rule sets, rules, and decision tables. w w w.leadingpractice.com 39

40 Figure 10: Example of extended BPMN: Business Rule Flow. 8. When designing, building, implementing, updating, working with and terminating Business Process tasks, events, and services issue of process compliance need to be taken into account. Compliance guidance is often found in several places, for example: policies, guidelines, standards, and regulations, but is instantiated within the roles, processes, data, and information objects. Issues of governance controls, risk management, audits, evaluation, security, and monitoring must also be taken into account in order to be compliant. Compliance reports, as shown in Figure 11, that are built upon relationships in the enterprise model can be leveraged to assess compliance. w w w.leadingpractice.com 40

41 Figure 11: Example of a Compliance Report. 9. An application is specialised software used to automate a set of business processes, steps, activities, events, and flows. Applications are also used to automate process reporting through the use of system measurements and system reporting. Being able to leverage process notations for application/system implementation requires both the capturing of the detailed information needed for full process automation and thereby application blueprint and software development, and the details of where and in which ways is the organization is unique in creating value. w w w.leadingpractice.com 41

42 Figure 12: Example of SAP Solution Manager which relates process, objects and application aspects together (picture of Solution Manager 7.2, using ASAP 7.2 and the LEAD meta models and principles within Business Blueprint, Application Design & Build, Application implementation/go live and maintenance). a) A good deal of additional information is needed in order to use extended BPMN notation for application blueprinting and software development. In Figure 12 an example of the detailed information needed for an SAP ERP implementation is presented. Without the ability to capture all of the required information within the notation it is not possible to complete the solution design in a manner that is properly and fully connected to the business and the context of execution and its configuration, nor upload via SAP Solution Manager an application design that is fully integrated to the business. Examples of this required information are, among others: The business model in terms of how the organizational units are constructed, which is both input to the solution construct and solution license, The To-Be business process, steps, and activities, Automated process details, in terms of tasks, events, gateways, measurements, decision points, reports, and rules, Automated service details, in terms of tasks, events, gateways, measurements, decision points, reports, and rules. This enables advanced service modelling and automation, The ability to specify SAP roles within the automated processes and services The business objects involved e.g. real world objects: people, material, physical goods, etc., The information objects involved and their linkage to measurements, reporting, decision making and information rules, The data objects involved and the specification of data types (meta and/or master and/or transactional), data input/output, data storage, link to measurements, reporting, decision making and data rules, The business scenarios, including the goals/requirements, the processes, the flows in terms of business workflow, information, and data. This includes the Objects input and output for the flows and the interfaces. b) To complete a business blueprint and make appropriate application design choices, it is essential to identify and specify the core critical (competitive and differentiated) and non-core competencies across the different business areas and groups. These core critical competencies along with the interaction of the business, information and data objects and their respective flows should, whether performed using purely manual processes or when automated and supported with an IT system, be treated as industry best practice when the organization s own leading practices actually are capable of providing the basis for differentiation in the market due to existing differentiating competencies. Far too often organizations critical differentiating competencies are automated with an IT vendor s Best Practices, and therefore effectively destroying the w w w.leadingpractice.com 42

43 company s uniqueness and differentiation. This is not to say that IT vendor Best Practices are bad, to the contrary, they are vital to cost cutting. For example, direct use of a vendor-provided product allows for fast implementation, fewer mistakes, increased standardization, and less risk. That said, Best Practice should never be applied to core differentiating and competitive competencies, but rather only to the non-core areas. To keep costs low, a company should make efforts to standardize and apply Best Practices to its non-core competencies (NNCs) and with them the supporting business functions. Many organizations are not identifying and categorizing their competencies in their process notations and therefore they fail to have use the right implementation approach innovation and transformation initiatives. Figure 13 illustrates the relationship between competency classification and the implementation approach. Figure 13: Example of the link between competency classification and the related technology approach. 10 Business process and measurements have various interaction points. The most common measurements are the output and results of the processes. Process Measures or Process Output Measures measure whether a process or activity is achieving its performance goals. At every level, processes have outputs and those outputs should be measured to assure that the process is functioning as it should. Most organizations evaluate the process output by defined Key Performance Indicators (KPIs) for the specific business area and thereby the associated processes. The challenge with this approach is that it is costly and can cripple an organization by forcing it to be reactive, working in response to something that has already happened. This type of process analysis generally occurs with operational outputs and is therefore not ideal for strategic decision making. In an ideal organization, the organization s strategic business objectives (SBOs) would be linked with the tactical critical success factors (CSFs) relevant to the specific business groups and operational performance measures, e.g. KPIs and/or the real time measures of PPIs. 10. w w w.leadingpractice.com 43

44 Figure 14: An example of linking strategic business objectives (SBOs) with the tactical critical success factors (CSFs) and operational performance measures (KPIs & PPIs). Having the correct linkage between the SBOs, CSFs, the relevant KPIs, and the PPIs, as well as having linked them for reporting purposes to the relevant organizational competencies, with the resources responsible and business functions involved, not only enables strategy execution, but enables decision making to the right value and performance aspects. Figure 14 illustrates the linkage between measurements and reporting. The specification of measurement and reporting aspects are therefore essential for most organizations today. In Figure 15, an example is presented that illustrates how the measurements and reporting aspects are specified using the extended BPMN notation. w w w.leadingpractice.com 44

45 Figure 15: Example of measurements and reports specified within notations. In this case, at the strategic, tactical, and operational levels, the decision makers are able to make appropriate assessments and conclusions, based upon the information that is related through scorecards (strategic), dashboards (tactical), and cockpits (operational) to the ultimate goals and measures of the organization. If the vertical alignment of measurements across levels is ignored, it is possible that activities or processes will be measured in ways that do not contribute to the overall success of the organization. The danger to an organization might even be that the different performance drivers/indicators could lead to conflicts in both strategy execution as well as value creation. Figure 16 provides an example of how it is possible to break down, or to roll up, the relevant information impacting the specified business area, competency and service, via real time measurements that enable value creating decisions. w w w.leadingpractice.com 45

46 Figure 16: Example of scorecards breakdown or roll up in igrafx. 11. The value delivery to employees and/or to customers often occurs through different business process automation and technology channels. Examples of frequently used channels are: Marketing and sales channel, e.g. Business 2 Consumer (B2C) or Business 2 Business (B2B) e-commerce Service channel, e.g. call center, customer interaction service center, or customer, and/or employee self-service channels Business collaboration and/or distribution channels Technology channels, e.g. digital image/screen channels, programming channels, network and I/O channels The extended BPMN notations allow the specification at process and sub-process levels the specific objects relevant to a channel. This could be a digital information channel like a portal. In this case, the portal s contents would be specified within the information objects as well as aspects in the business and data objects. Another example of a channel would be a physical customer interaction service center. See Figure 17 for an illustrative example. w w w.leadingpractice.com 46

47 Figure 17: Example of business, information and data objects used in notations and the ability to specify information relevant to channels. 12. Most aspects of process execution and thereby value creation incorporate the usage, consumption and/or creation of data. To the outside, business objects represent the real world objects. To applications, the information objects reveal only their interface, which consists of a set of clearly defined relations. Users often work with business objects, which are represented in applications through information objects. Information objects, representing a business entity are in turn related to data objects. 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, which in turn represent business objects. While data objects could be presented by the specific data aspects, e.g. data entities and/ or data services, these data aspects should rather be related to specific information objects. In this way, mapping and categorizing data objects can be achieved more quickly and easily then attempting to map all columns in a data set. This approach allows the work of discovery to be more focused and allows a subject matter expert or architect to review the data mappings within a smaller context, without being overwhelmed by the large number of details contained in a large mapping that might be required for information objects. For example if one application table contained business information about employees and their benefits, this detail would be captured and represented in separate data objects. The diagram in figure 18 illustrates how data objects are captured in the context of a layered architecture. w w w.leadingpractice.com 47

48 Figure 18: Correlation between Business, Object, Information Objects, Data Objects and Data Tables. The ability of the extended BPMN standard to map and specify data objects (data components, entities, tables, data services, as well as data types, e.g. master or meta data) to the information and business objects is both vital for: Business Blueprinting Software development Data Modelling Business Intelligence Data Architecture Reporting Knowledge Management projects Decision making System and data integration These notational elements enable a whole new perspective and increase the utility of process notations. w w w.leadingpractice.com 48

49 13. Media is a part of every process, since media is used within processes. There are many kinds of media involved within a process, for example, computers that are being used as a tool to create value through social media, or s as electronic media, or a brochure that is being used to create value through printed media. The following extended BPMN aspects can specify relevant Media components: The manual tasks and services with the associated business objects specifying advertising media, broadcast media (communications), print media, recording devices, and storage media, The automated tasks and services with the business, information, and data objects specifying relevant digital media, electronic media, hypermedia, social media, computing media, data storage, The rules relevant to media aspects, The media relevant measurements, decision points, and reports. 14. A platform is used to enable elements of process automation; for example, a platform component enables an application that automates the process tasks, and a platform service enables an application service and thereby a business service. Furthermore, a user can access needed information in multiple processes through different platform devices, such as laptops, smart phones, and tablets. The following extended BPMN aspects can specify relevant platform parts: The automated tasks could specify relevant platform components, The automated service could specify relevant platform services, The business objects can specify both the platform components and platform devices, The information objects can specify the platform service input/output and the platform devices consuming the information, The data objects can specify the platform devices consuming the data objects, The rules relevant to platform aspects, The platform relevant measurements, decision points, and reports. 15. From a process architecture point of view, processes can be automated with technology, and therefore require supporting infrastructure. For example, applications that automate the process and the service reside on infrastructure components. Infrastructure services furthermore support the platform services, application, and data services. The following extended BPMN aspects can specify relevant infrastructure parts: the automated tasks could specify relevant infrastructure components, w w w.leadingpractice.com 49

50 the automated service could specify relevant infrastructure services, the business objects can specify both the infrastructure components and the location of them, the information objects can specify the infrastructure service input/output, The rules relevant to infrastructure aspects, The infrastructure-relevant measurements, decision points, and reports. 16. Business services deliver value within the organization and to its customers. This value creation is subject to the relationship between business processes and their resources, tasks, events, and the services they deliver. In this regard, the manual and/or automated services, as shown in Figure 19, are captured within the process notations in order to relate and then automate them through the application services, data services, platform services and infrastructure services. Figure 19: Example of Manual and Automated Services within notations. For manual and automated services the different objects, e.g. business, information, and/or data, can be identified and classified. This includes relating them to the organization, roles, rules, and compliance aspects, as well as business and information flow. The set of service rules and modelling techniques associated with identifying, designing and relating business, information and data object types to fully represent a real object s behavior and representation is supported by the extended notations. Error! Reference source not found. hows the result of using the extended BPMN notation to slice and dice a model to yield information like the Service Object Flow. Other examples of information that can be obtained from a model are: Manual services w w w.leadingpractice.com 50

51 Automated services, e.g. web service, application service, data service, platform service and/or infrastructure service Objects related to the manual and automated services The service object flow (service object input/output) Service rules Service measurements Service reporting Service decision making Service roles involved Service tasks Applying the extended BPMN Standard. w w w.leadingpractice.com 51

52 Figure 20: Using extended BPMN for process modeling in igrafx. To create process models using extended BPMN notation, the extended activity task type indicators must be an integral part of the BPMN palette in the modeling tool. Figures 22a and 22b illustrate the level of information that can be visually communicated when using extended BPMN compared to standard BPMN 2.0. The addition of activity task types for manual and automated services and business rules, as well as business, data and information objects to designate relative flows, and finally measurement and reporting objects, all help establish more precise business-level communication as needed to effectively design and understand the process. 1 Customer Service Perform Initial Review Receive Issue 2 Discuss with Claimant Yes Questions? No Valid Claim? No Yes 3 Create "Loss Notice" 4 Prepare Rejection Notice Prepare Settlement Enter Reply Notice Yes No Settle? Claims Handling 7 Validate Customer No Yes 8 Validate Policy No Yes Valid? Valid? Operations Support 10 Perform Detailed Review 11 Create Claim 12 Assign Investigator and Adjuster 14 Cut Check and Close Claim End Insurance Company Risk Management 16 Perform Risk Assessment High Risk? No Yes 17 Investigate Claim Fraud? No Yes 18 Perform Fraud Protocal 20 Forward to State Fraud Division End (Fwd. to Fraud) Contract Maintenance 21 Assess Claim No Yes 22 Prepare Rejection 23 Prepare Settlement Accepted Settlement? No Yes 25 Finalize Claim Valid Claim? Customer Accounts 26 Update Customer Account Quotations & Underwriting Claims Management 28 Evaluate Settlement No Yes Change in Risk? 29 Update Premium & Exclusions 30 Notify Customer Service Figure 21a: Claims management process using standard BPMN 2.0. w w w.leadingpractice.com 52

53 Claimant Issue Rejection Notice Settlement Reply Customer Service 1 Perform Initial Review Receive Issue 115 Log Resubmit Status 2 Discuss with Claimant Yes Questions? No Valid Claim? No Yes 3 Create "Loss Notice" Policy Info 4 Prepare Rejection Notice Prepare Settlement Enter Reply Notice Yes No Settle? Check Claims Database Claims Handling Loss Notice 7 Validate Customer No Yes 8 Validate Policy No Yes 9 Log Status Valid? Valid? Operations Support 10 Perform Detailed Review 11 Create Claim 12 Assign Investigator and Adjuster 13 Log Status Claims Database 14 Cut Check and Close Claim Claims Database 15 Log Payment End Insurance Company Risk Management 16 Perform Risk Assessment Risk Report High Risk? No Yes Claim Info 17 Investigate Claim Fraud? No Yes 18 Perform Fraud Protocal Forward to Update State Fraud Litigated Division End (Fwd. to Fraud) Claims Database Contract Maintenance 21 Assess Claim No Yes Valid Claim? 22 Prepare Rejection 23 Prepare Settlement 24 Update Pending Claims Claims Database Accepted Settlement? No Yes 25 Finalize Claim Claims Database Resolution Customer Accounts 26 Update Customer Account 27 Log Status Quotations & Underwriting Settlement 28 Evaluate Settlement No Yes Change in Risk? 29 Update Premium & Exclusions 30 Notify Customer Service Customer Database Claims Database Figure 22b: Claims management process using extended BPMN. w w w.leadingpractice.com 53

54 The link between Process Modelling and Architecture Global University Research has demonstrated very conclusively the strong link that exists between process modelling and Enterprise Architecture. For further reading and more information on the subject of process oriented architecture, process architecture and what BPM can learn from Enterprise Architecture concepts do we refer to the first and second volume of The Complete Business Process Handbook 3 The main point of why process architecture is relevant is that it adds a different view and modelling perspective. For example,in process design there is a tendency to treat all processes as though they are of equal value. By way of example, Lean looks to identify value from the standpoint of the end customer and to then focus on optimizing from that perspective, while Hammer sought to create workflows and processes to improve customer service, reduce costs, and therefore to improve competitive position. Neither these nor any other models of process improvement recognize that some processes are of significant strategic value and therefore of great importance to the organization, whereas other processes, while they must be done, offer nothing of particular significance to the business, and therefore have little or no value. Some process experts think that sorting the process according to main and supporting processes solves this challenge. This is not the case. Sorting the process according to main and supporting processes categorizes the processes according to the aspect if the one is a part of the main flow and the other a part of the supporting processes. In both of them there can be value creating aspects. So that is a terrible misunderstanding in process modelling. At the same time, some processes are simple, highly repeatable, and involve the same transactional and transformational work which can be done over and over again; others are more complex or dynamic, involved in cases where the rules either are not clear, are chaotic, or subject to dynamic change. Understanding the nature and relationship of processes and it s context is therefore central to effective process management and the basis to develop a process architecture. Because of this, there has been no recognition that a one size fits all approach is not appropriate and that attempting to improve processes based on a single model can actually place the organization at risk. In the following we will therefore see as illustrated in figure 23 focus on processes and its context to architectural concepts. 3 von Rosing, M., Scheer, A.W., von Scheel, H., The Complete Business Process Handbook, Volume I and Volume II, Elsevier-Morgan Kaufmann, 2014 and 2015 w w w.leadingpractice.com 54

55 class Process Oriented Architecture Business Process +protected by +measures/measured by +influenced by +design influenced by +owns and controls +monitored through +produced by +incurs +enables +occurs at +influences +monitored through +protects Strategy +informs (Strategic +motivated by Business Objectiv e) +threatens +realized by +enabled +motivates by +owned by +threatens interests of Process Owner +monitors +attempts to realize +influences +interests +threatened the design threated by of by Value Risk Proposition +threatened +threatens by +uses to control +set by +monitors +threatens +monitored through Business Compliance +monitored +monitors through +informed +incurred by by +threatened by Cost +protected by +specialisation +enabled +selection by +selection +protects of and design influenced influenced +threatened by+mitigated by +influenced by +monitored through +sets +mitigates +protected by +protected +protects +protects by Security +protects +protects +monitors +produces +motivates +influences +threatens Quality +generalization of +influenced by +protected +occurance by of +influences the selection and design of +motivation for Location +measured by/ measures Process Measurement (PPI) +controlled through +enabled +protected by +influences by +influences the selection of +enables +enables Enterprise Capability Figure 22 The Process Oriented Architecture Meta Model - Relationships and Key Cross Relations. Figure 22 shows the main concepts within the process oriented architecture meta model, the nature of the structural properties needed to fully describe our knowledge of process and therefore to provide tools to both design and evaluate process designs. The figure also very importantly shows the key cross connections or relationship between each of the related concepts. In figure 22, we see: Enterprise Capability o enables Value Proposition w w w.leadingpractice.com 55

56 o influences Quality o enables Strategy (Strategic Business Objective) o protected by Security o selection influenced by Risk o consumed by Business Process Business Compliance o monitors Quality o monitors Strategy (Strategic Business Objective) o monitors Security o monitors Risk o monitors Business Process Business Process o protected by Security o design influenced by Risk o occurs at Location o consumes Enterprise Capability o incurs Cost o influenced by Strategy (Strategic Business Objective) o monitored through Business Compliance o measured by Process Measurement (PPI) o owned and controlled by Process Owner Cost o influenced by Quality o informed by Strategy (Strategic Business Objective) o protected by Security o threatened by Risk o incurred by Business Process w w w.leadingpractice.com 56

57 Location o Motivated by Strategy (Strategic Business Objective) o selection and design influenced by Risk o occurrence of Business Process Process Measurement (PPI) o measures Business Process o used by control Process Owner Process Owner o sets Security o interests threated by Risk o uses Process Measurement (PPI) o owns Business Process Quality o specialization of Value Proposition o monitored through Business Compliance o influenced by Enterprise Capability o influences Cost o influences the selection and design of Location o motivated by Strategy (Strategic Business Objective) o threatened by Risk Risk o threatens Strategy (Strategic Business Objective) o influences the selection of Enterprise Capability o mitigated by Security o threatens Cost o threatens Quality w w w.leadingpractice.com 57

58 o influences the selection and design of Location o threatens interests of Process Owner o threatens Value Proposition o monitored through Business Compliance o influences the design of Business Process Security o protects Strategy (Strategic Business Objective) o protects Cost o protects Enterprise Capability o monitored through Business Compliance o protects Value Proposition o protects Location o set by Process Owner o mitigates Risk o protects Business Process Strategy (Strategic Business Objective) o informs Cost o motivation for Location o enabled by Enterprise Capability o attempts to realize Value Proposition o monitored through Business Compliance o motivates Quality o protected by Security o threatened by Risk o influenced by Business Process Value Proposition o enabled by Enterprise Capability w w w.leadingpractice.com 58

59 o generalization of Quality o realized by Strategy (Strategic Business Objective) o protected by Security o threatened by Risk These objects, their relationship both to process and to each other situate process, not within and with respect to each but act as part of a larger story that provides a standard form to the entire enterprise relations (from the context of a process), providing connections across the layers of the enterprise i.e. business, application, and technology layer. Using the extended BPMN Standard for Architectural work We have elaborated how the extended BPM Notation enable the use modelling of services, measurements, rules, reporting, information management, software development/implementation as well as performance and value management. We also identified that fact that the different subjects have a lot of things in common, especially that they all are based on processes and their execution. Therefore a siloed approach/method can not only lead to a high degree of complexity and high cost of modelling/architecture work, it is actually the source for low maturity within an organization across the different modelling or domain subjects. It would not matter of how much money an organization spends developing that one area/domain, it can only benefit the entire organization to a maturity level 2- standardized or 3 documented. It doesn't matter how much the organization would invest in higher maturity, the overall maturity cannot benefit from a siloed approach. Especially since the siloed approach leads one back to maturity level 1-2. From this we believe that many modelling and architecture principles that organizations use today actually are the root cause for high cost, complex modelling, and architecture need. What we did not specify is that the reason we could do these connections that many organizations have struggled on figuring out and developing is that we realized that these concepts did not only have multiple touch points, but they were connected through the layers of their domain. Our LEAD (Layered Enterprise Architecture Development) concept is actually build on the model that we realize that the different layers have a high degree of coupling between them. We furthermore realized that the enterprise architecture domains e.g. business architecture, process architecture, data architecture, etc. are in revertible interlinked and coupled together and should not be modelled separately. From our discussions in chapter 2, 4, and 6 we see that the relations between the layers are built on the connections between the multiple areas related within the layer and across. However, not all the components/objects can be related to each other. We therefore have addressed the sequence and relations based on the nature of the objects e.g. concepts, design, functions, tasks, in looking at it from an enterprise ontology perspective and then from a semantic aspects to have the right relations and sequence in place. The ability to capture and apply the information from extended BPM Notations across the layers is therefore a vital aspect to both use the standard for Enterprise Modelling and Enterprise Architecture. In figure 23 is an example which of the BPMN and extended BPMN shapes can be used and applied across the layers: w w w.leadingpractice.com 59

60 Figure 23: Example of how to use the extended BPMN shapes across the Layers. For the way of modelling within the layers it is vital to consider it in the whole connection of tasks, activities, events and gateways throughout all the layers. The main principles for working with the extended BPMN shapes across the Layers are: 1. Identity shapes involved in which layer they relate 2. Specify the objects: business, information and/or data objects involved and relevant for that layer 3. As the different business, application and technology layer, not only have one, but multiple interaction points between the objects, most using different modelling principles, one of the difficulties is to identify the object and then relate it to the subject relevant. 4. Relate the relevant measures, reports, decision making points and rules across the layers w w w.leadingpractice.com 60

61 5. Relationship: describes the way and means in which the objects have relationships with the other objects and layers One of the most common challenges is to identify and capture all of these objects and their relations correctly within the Layers. Our basic recommendation for the practitioners is to use decomposition and composition principles, where the different entities and objects within the area they are connected to are related (e.g. competency, function, process, service, role, flow, application, media, channel, etc.). As illustrated in figure 24, each layer s task and services are defined by its needed task and objects (that are requested) n th layer protocol (1st layer, 2nd layer, etc.). The functions that a layer provides can be seen as the layer s services since a layer provides a set of functions and tasks and thereby services to its upper layer. In turn, the upper layer uses the lower layer s services (functionality and tasks) to achieve its own functions (services). A higher layer can therefore be seen as a service user since it uses the services provided by its lower layer. A lower layer can therefore in the layered architecture approach be seen as a service provider. Figure 23: Basic example of how Decomposition of the objects are applied throughout the layers. To achieve the right alignment between layers such as business and IT, one would have to decompose the business relevant objects and compose into the applicable application and technology layers. This enables the practitioner to use the x-bpmnotations, related to the meta objects throughout all the architectural layers (business, application and technology). Not only are the objects governed by its connection modelling rules, but how and where the can be applied is defined and standardized. Using such an integrated and standardized approach ensures interlink between Enterprise Architecture and Enterprise Modelling and guarantees a build in Governance as well as the Continuous Improvement concepts. In Figure 25 is an example of how Composition principles of the objects are applied throughout the layers w w w.leadingpractice.com 61

62 Figure 24: Basic example of how Decomposition of the objects are applied throughout the layers. w w w.leadingpractice.com 62