Managing Process Portfolios and Change Using Organisational Models Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of Wollongong (with George Koliadis and Moshiur Bhuiyan) Decision Systems Laboratory University of Wollongong

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 2 The thing with bold ideas…

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 3 Current DSL research on process governance Business process lifecycle management Business process lifecycle management Enterprise process architectures Enterprise process architectures Compliance management Compliance management Process optimization Process optimization

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 4 Outline Two problems: Two problems: Process Lifecycle Management Process Lifecycle Management Change Management Change Management Process Portfolio Management Process Portfolio Management Three (closely related) solutions: Three (closely related) solutions: The Enterprise Process Governance (EPG) methodology The Enterprise Process Governance (EPG) methodology The Process and Enterprise Model Relationship (PEMR) methodology The Process and Enterprise Model Relationship (PEMR) methodology The Enterprise Process Lifecycle Manager (EPLM) tool The Enterprise Process Lifecycle Manager (EPLM) tool

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 5 Business Process Lifecycle Discovery Design Deployment Enactment Monitoring Analysis Completion Adapt / Control Re-Deploy Re-Design Re-Discover Phase Change

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 6 Business Process Change (1/2) Change drivers: Operational: Operational: Process improvement/optimisation Process improvement/optimisation Dynamic operational contexts Dynamic operational contexts Organisational: Organisational: Altered organisational structures Altered organisational structures Dynamic inter-relationships between organisational actors Dynamic inter-relationships between organisational actors

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 7 Business Process Change (2/2) Should we implement change? Should we implement change? What will the impact of change be (impact analysis)? What will the impact of change be (impact analysis)? How should we implement change? How should we implement change? What alternative ways of implementing change do we have available? What alternative ways of implementing change do we have available? Which of these should we choose (trade-off analysis)? Which of these should we choose (trade-off analysis)? How should we monitor the implementation of change? How should we monitor the implementation of change? What lessons do we take away from the change implementation process? What lessons do we take away from the change implementation process? Pain Point: We do not have a process for process change

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 8 Impact analysis (1/2) Operational changes can make: Operational changes can make: The changed process infeasible The changed process infeasible The changed process inconsistent (more on this later!) with other processes The changed process inconsistent (more on this later!) with other processes Degrade quality of service (QoS) Degrade quality of service (QoS) Modifications to organisational structures necessary Modifications to organisational structures necessary Gaps in inter-relationships/inter-dependencies between organisational actors Gaps in inter-relationships/inter-dependencies between organisational actors

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 9 Impact analysis (2/2) Organisational changes can make: Organisational changes can make: Existing process infeasible Existing process infeasible Existing processes inconsistent with other processes and with the current organisational context Existing processes inconsistent with other processes and with the current organisational context Degrade quality of service Degrade quality of service Impact analysis helps answer the question: Impact analysis helps answer the question: Should we implement the change request? Should we implement the change request? The answer is yes if: The impact of change is manageable/acceptable The impact of change is manageable/acceptable

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 10 Trade-off analysis A given change request can be implemented in multiple, alternative ways A given change request can be implemented in multiple, alternative ways These alternative may perform differently under QoS metrics These alternative may perform differently under QoS metrics The impact of these alternatives may vary The impact of these alternatives may vary Both impact and QoS performance assessments must form the basis for decisions on which alternative to adopt Both impact and QoS performance assessments must form the basis for decisions on which alternative to adopt

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 11 Enterprise process architectures Definition of Business Process Architecture from the BPTrends Glossary: A process architecture is a written or diagrammatic summary of the value chains and business processes supported by a given organization. A good process architecture shows how value chains and business processes are related to each other and to the strategic goals of the organization. Some companies use the term process architecture to refer to the process diagram for a single process. We refer to that as a process model or process diagram. We often add business or enterprise to process architecture to suggest that it's a high-level architecture of all of the processes in the organization. A process architecture is a written or diagrammatic summary of the value chains and business processes supported by a given organization. A good process architecture shows how value chains and business processes are related to each other and to the strategic goals of the organization. Some companies use the term process architecture to refer to the process diagram for a single process. We refer to that as a process model or process diagram. We often add business or enterprise to process architecture to suggest that it's a high-level architecture of all of the processes in the organization.

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 12 The enterprise process portfolio management problem (1/2) What are the processes in an enterprise? What are the processes in an enterprise? At what level of granularity should they be represented? At what level of granularity should they be represented? How does the process portfolio relate to the enterprise value chain (i.e., which processes services each component of the value chain)? How does the process portfolio relate to the enterprise value chain (i.e., which processes services each component of the value chain)? What is the relationship between the process portfolio and a (more fine-grained) functionality map? What is the relationship between the process portfolio and a (more fine-grained) functionality map?

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 13 The enterprise process portfolio management problem (2/2) What is the process ownership structure (i.e., which enterprise actor/role owns which process)? Sometimes these would involve cross- ownership. What is the process ownership structure (i.e., which enterprise actor/role owns which process)? Sometimes these would involve cross- ownership. How does the process portfolio relate to inter- actor dependencies? How does the process portfolio relate to inter- actor dependencies? How can metrics (both functional and non- functional) be extracted from the EPA? How can metrics (both functional and non- functional) be extracted from the EPA? How can EPA be designed backwards from enterprise-level KPIs? How can EPA be designed backwards from enterprise-level KPIs?

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 14 Mapping the enterprise Common to both lifecycle and process portfolio managements problems is a requirement for detailed enterprise maps Common to both lifecycle and process portfolio managements problems is a requirement for detailed enterprise maps An enterprise map must include: An enterprise map must include: Value chains Value chains A structure map A structure map A goal/objective map A goal/objective map A capability map A capability map A relationship map A relationship map A risk map A risk map

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 15 Enterprise structure maps Who are the key enterprise actors? Who are the key enterprise actors? These could be: divisions, business units, departments, roles These could be: divisions, business units, departments, roles What are their structural relationships? What are their structural relationships? These could be: These could be: “Part-of” relationships, e.g., “ business unit X is part of division Y” “Part-of” relationships, e.g., “ business unit X is part of division Y” “Member-of” relationships, e.g., “role X is a member of department Y” “Member-of” relationships, e.g., “role X is a member of department Y” “Is-a” relationships (i.e., specialization/generalization relationships), e.g. “a department head is a contract signatory authority” “Is-a” relationships (i.e., specialization/generalization relationships), e.g. “a department head is a contract signatory authority”

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 16 Enterprise goal/objective maps What are the enterprise-level goals/objectives? What are the enterprise-level goals/objectives? How are these decomposed into sub-goals etc.? How are these decomposed into sub-goals etc.? What are the actor/role/unit-level goals/objectives? What are the actor/role/unit-level goals/objectives? How do these support enterprise-level objectives? How do these support enterprise-level objectives? What are the softgoals (or optimisation objectives), (e.g., minimize lead time for priority customers)? What are the softgoals (or optimisation objectives), (e.g., minimize lead time for priority customers)?

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 17 Enterprise capability maps What functionalities does the enterprise support, i.e., what can the business do? What tasks is it capable of executing? What functionalities does the enterprise support, i.e., what can the business do? What tasks is it capable of executing? What functionalities do enterprise actors/sub- units support? What functionalities do enterprise actors/sub- units support? What are the hierarchical relationships between these functionalities? What are the hierarchical relationships between these functionalities?

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 18 Enterprise relationship maps How do enterprise actors relate to each other at a functional (as opposed to structural) level? How do enterprise actors relate to each other at a functional (as opposed to structural) level? What are the inter-dependencies between enterprise actors? What are the inter-dependencies between enterprise actors? How critical are these dependencies? Does an actor depend entirely or partially on another actor to support certain functionalities? Is the dependence only to improve QoS? How critical are these dependencies? Does an actor depend entirely or partially on another actor to support certain functionalities? Is the dependence only to improve QoS?

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 19 Enterprise risk maps What are the critical actors? What are the critical actors? What are the critical inter-relationships/dependencies? What are the critical inter-relationships/dependencies? What are the vulnerable actors? What are the vulnerable actors? What are the vulnerable inter- relationships/dependencies? What are the vulnerable inter- relationships/dependencies? What cumulative risk assessments can one make from an enterprise map? What cumulative risk assessments can one make from an enterprise map?

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 20 The Enterprise Process Governance (EPG) methodology Document enterprise processes Document enterprise processes Define enterprise maps Define enterprise maps Relate processes to capabilities/functionalities in the capability map via process-capability links Relate processes to capabilities/functionalities in the capability map via process-capability links For operationally-driven changes: For operationally-driven changes: Identify scope of change on existing processes Identify scope of change on existing processes Identify scope of change on enterprise maps by following process- capability links Identify scope of change on enterprise maps by following process- capability links For changes driven by the organisational context: For changes driven by the organisational context: Identify scope of change on enterprise map Identify scope of change on enterprise map Identify scope of change on enterprise processes using process- capability links Identify scope of change on enterprise processes using process- capability links Perform impact and trade-off analysis Perform impact and trade-off analysis Implement change Implement change Monitor change Monitor change

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 21 Outline Two problems: Two problems: Process Lifecycle Management Process Lifecycle Management Change Management Change Management Process Portfolio Management Process Portfolio Management Three (closely related) solutions: Three (closely related) solutions: The Enterprise Process Governance (EPG) methodology The Enterprise Process Governance (EPG) methodology The Process and Enterprise Model Relationship (PEMR) methodology The Process and Enterprise Model Relationship (PEMR) methodology The Enterprise Process Lifecycle Manager (EPLM) tool The Enterprise Process Lifecycle Manager (EPLM) tool

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 22 Enterprise Modelling Aim: Capture knowledge critical to the management and operation of enterprises. Aim: Capture knowledge critical to the management and operation of enterprises. 3 Views: Teleological, Social, Technical. 3 Views: Teleological, Social, Technical. Informal Methods: (Graphical) Informal Methods: (Graphical) Formal Methods: (Formal Semantics) Formal Methods: (Formal Semantics) Provide the ability to “prove formally that responsibilities assigned to roles are maintained as a result of [business] process execution.” Provide the ability to “prove formally that responsibilities assigned to roles are maintained as a result of [business] process execution.” Meta-Objects: Goals, Roles, Actors, Processes, Resources. Meta-Objects: Goals, Roles, Actors, Processes, Resources.

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 23 i* - Organisational Modelling Developed: 1995 UoT – Eric Yu. Developed: 1995 UoT – Eric Yu. Purpose: Process Reengineering. Purpose: Process Reengineering. Classification: Strategic / Social / Intentional. Classification: Strategic / Social / Intentional. Concepts: Actors: Agents, Roles, Positions. Resources, Tasks, [Soft]Goals. Abilities and Dependencies. Concepts: Actors: Agents, Roles, Positions. Resources, Tasks, [Soft]Goals. Abilities and Dependencies.

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 24 i* - Organisational Modelling Strategic Dependency (SD) Model, consists of a set of nodes and links. Each node represents an ‘actor’, and each link between the two actors indicates that a ‘depender’ actor depends on a ‘dependee’ for a ‘dependum’. Strategic Dependency (SD) Model, consists of a set of nodes and links. Each node represents an ‘actor’, and each link between the two actors indicates that a ‘depender’ actor depends on a ‘dependee’ for a ‘dependum’. Strategic Rationale (SR) Models, provides a more detailed level of modeling by looking “inside” actors to model internal intentions / capabilities. Strategic Rationale (SR) Models, provides a more detailed level of modeling by looking “inside” actors to model internal intentions / capabilities.

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 25

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 26

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 27 BPMN Business Process Modelling Notation. (BPMI) Business Process Modelling Notation. (BPMI) Constructs: Events, Activities, Gates, Lanes. Constructs: Events, Activities, Gates, Lanes. Business Process Types (interoperability): Business Process Types (interoperability): Private (internal): Only internal participants. Private (internal): Only internal participants. Abstract (public): External with implicit processes. Abstract (public): External with implicit processes. Collaboration (global): External with explicit processes. Collaboration (global): External with explicit processes.

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 28 BPMN Example

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 29 The Process and Enterprise Model Relationship (PEMR) methodology Extends the EPG methodology by replacing informal process documentation and enterprise maps with explicit: Extends the EPG methodology by replacing informal process documentation and enterprise maps with explicit: Enterprise models (in the i* notation) Enterprise models (in the i* notation) Process models (in the BPMN notation) Process models (in the BPMN notation) Requires minimal semantic enhancements to process and enterprise models Requires minimal semantic enhancements to process and enterprise models Uses normative realization links instead of process- capability links Uses normative realization links instead of process- capability links Defines detailed process of analysing these links to determine varying degrees of opportunities for realization of enterprise capabilities via processes Defines detailed process of analysing these links to determine varying degrees of opportunities for realization of enterprise capabilities via processes

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 30 PEMR: Combined Framework

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 31 Change Management Given: Given: process and enterprise models process and enterprise models change request. change request. We seek to identify… We seek to identify… Whether to implement the change; Whether to implement the change; Alternative means of implementing change Alternative means of implementing change Suggestions on minimally modified process / enterprise model. Suggestions on minimally modified process / enterprise model.

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 32 Semantic annotations to enterprise models FormalTROPOS framework permits annotation of dependencies in an i* model (except softgoal dependencies) with: FormalTROPOS framework permits annotation of dependencies in an i* model (except softgoal dependencies) with: Creation conditions Creation conditions Invariant conditions Invariant conditions Fulfillment conditions Fulfillment conditions We use fulfillment conditions to obtain a semantic description of what tasks in an i* SD model seek to achieve We use fulfillment conditions to obtain a semantic description of what tasks in an i* SD model seek to achieve

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 33 A parsimonious extension to BPMN We extend BPMN with effect annotations We extend BPMN with effect annotations Effects: Result or Outcome of activity. Effects: Result or Outcome of activity. Effect Annotation: Specific Statement (or assertion) relating to the result of an activity, associated to a state altering construct on a process model. Effect Annotation: Specific Statement (or assertion) relating to the result of an activity, associated to a state altering construct on a process model. We expect an analyst to annotate BPMN tasks or sub-processes with their immediate effects We expect an analyst to annotate BPMN tasks or sub-processes with their immediate effects

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 34 Effect annotations Effect annotations can be: Effect annotations can be: Informal (e.g. plain English) Informal (e.g. plain English) Formal (e.g., FOL, LTL, CTL etc.) Formal (e.g., FOL, LTL, CTL etc.) Controlled Natural Language: This involves specifying effects using a limited repertoire of strictly formatted natural language sentence patterns, which can be directly mapped to underlying formal assertions Controlled Natural Language: This involves specifying effects using a limited repertoire of strictly formatted natural language sentence patterns, which can be directly mapped to underlying formal assertions

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 35 Cumulative effect annotations Effect annotations are accumulated (after the initial pass through the process model to provide the immediate effect annotations) Effect annotations are accumulated (after the initial pass through the process model to provide the immediate effect annotations) A cumulative effect annotation of a task or sub-process is a statement of accumulated effects of the entire process up to that point A cumulative effect annotation of a task or sub-process is a statement of accumulated effects of the entire process up to that point In the accumulation process, the effects of more recent tasks may over-ride (undo) the effects of prior tasks In the accumulation process, the effects of more recent tasks may over-ride (undo) the effects of prior tasks Accumulation may automated for formal annotation, but is manual for informal annotation Accumulation may automated for formal annotation, but is manual for informal annotation Cumulative effects specifications may be non-unique… Cumulative effects specifications may be non-unique…

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 36 Effect scenarios Splits and joins in a process model lead to alternative sets of cumulative effects – these are referred to as effect scenarios Splits and joins in a process model lead to alternative sets of cumulative effects – these are referred to as effect scenarios We maintain effect scenarios through a process model… We maintain effect scenarios through a process model…

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 37 Linking process and enterprise models A process realizes a task in an i* model A process realizes a task in an i* model We initially identify normative realization links between processes and tasks We initially identify normative realization links between processes and tasks These links are then analyzed and labeled as either: These links are then analyzed and labeled as either: Weakly inconsistent Weakly inconsistent Strongly inconsistent Strongly inconsistent Consistent but unrealized Consistent but unrealized Weakly Realized Weakly Realized Strongly Realized Strongly Realized

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 38 Normative links A weakly inconsistent link relates a task in an i* model to a process with at least one final effect scenario that is inconsistent with the task fulfillment condition A weakly inconsistent link relates a task in an i* model to a process with at least one final effect scenario that is inconsistent with the task fulfillment condition A strongly inconsistent link relates a task in an i* model to a process for which all final effect scenarios are inconsistent with the task fulfillment condition A strongly inconsistent link relates a task in an i* model to a process for which all final effect scenarios are inconsistent with the task fulfillment condition A consistent but unrealized link relates a task in an i* model to a process for which all final effect scenarios are consistent with the task fulfillment condition (but the realization condition, below, is not met) A consistent but unrealized link relates a task in an i* model to a process for which all final effect scenarios are consistent with the task fulfillment condition (but the realization condition, below, is not met) A (weakly/strongly) realized link relates a task in an i* model to a process for which at least one/all final effect scenarios entail the task fulfillment condition A (weakly/strongly) realized link relates a task in an i* model to a process for which at least one/all final effect scenarios entail the task fulfillment condition

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 39 Tool Demo We will now see a tool demo We will now see a tool demo The following screenshots have been provided in lieu of the actual demo for those who did not attend this presention. The following screenshots have been provided in lieu of the actual demo for those who did not attend this presention.

Constrained Development Methodology Tool Demo

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 41 Annotating Effects of Tasks in BPMN Model Annotated Effects

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 42 Accumulation of Effects Over Trajectories Accumulated Effects

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 43 Accumulation of Effects Over Trajectories Unload Containers Task has Two Effect Scenarios as this task can be accomplished over two alternatives trajectories. Effect Scenarios

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 44 Accumulation of Effects Over Trajectories Demonstration of an alternative trajectory Accumulated effects over one trajectory

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 45 Annotating Fulfillment Conditions to Tasks/Goals/Dependencies of i* Model Annotating fulfillment condition of task

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 46 Creating Realization Links Between Models

Decision Systems Laboratory University of Wollongong Decision Systems Laboratory University of Wollongong 47 Sample Report of Consistency Evaluation