Managing Process Portfolios and Change Using Organisational Models

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

2. The thing with bold ideas…

3. Current DSL research on process governance • Business process lifecycle management • Enterprise process architectures • Compliance management • Process optimization

4. Outline • Two problems: • Process Lifecycle Management • Change Management • Process Portfolio Management • Three (closely related) solutions: • The Enterprise Process Governance (EPG) methodology • The Process and Enterprise Model Relationship (PEMR) methodology • The Enterprise Process Lifecycle Manager (EPLM) tool

5. Business Process Lifecycle Re-Discover Discovery Re-Design Design Re-Deploy Deployment Phase Change Adapt / Control Enactment Monitoring Analysis Completion

6. Business Process Change (1/2) Change drivers: • Operational: • Process improvement/optimisation • Dynamic operational contexts • Organisational: • Altered organisational structures • Dynamic inter-relationships between organisational actors

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

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

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

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

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.

12. The enterprise process portfolio management problem (1/2) • What are the processes in an enterprise? • 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)? • What is the relationship between the process portfolio and a (more fine-grained) functionality map?

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. • 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 EPA be designed backwards from enterprise-level KPIs?

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

15. Enterprise structure maps • Who are the key enterprise actors? • These could be: divisions, business units, departments, roles • What are their structural relationships? • These could be: • “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” • “Is-a” relationships (i.e., specialization/generalization relationships), e.g. “a department head is a contract signatory authority”

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

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 do enterprise actors/sub-units support? • What are the hierarchical relationships between these functionalities?

18. Enterprise relationship maps • How do enterprise actors relate to each other at a functional (as opposed to structural) level? • 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?

19. Enterprise risk maps • What are the critical actors? • What are the critical inter-relationships/dependencies? • What are the vulnerable actors? • What are the vulnerable inter-relationships/dependencies? • What cumulative risk assessments can one make from an enterprise map?

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

21. Outline • Two problems: • Process Lifecycle Management • Change Management • Process Portfolio Management • Three (closely related) solutions: • The Enterprise Process Governance (EPG) methodology • The Process and Enterprise Model Relationship (PEMR) methodology • The Enterprise Process Lifecycle Manager (EPLM) tool

22. Enterprise Modelling • Aim: Capture knowledge critical to the management and operation of enterprises. • 3 Views: Teleological, Social, Technical. • Informal Methods: (Graphical) • Formal Methods: (Formal Semantics) • 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.

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

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 Rationale (SR) Models, provides a more detailed level of modeling by looking “inside” actors to model internal intentions / capabilities.

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

28. BPMN Example

29. The Process and Enterprise Model Relationship (PEMR) methodology • Extends the EPG methodology by replacing informal process documentation and enterprise maps with explicit: • Enterprise models (in the i* notation) • Process models (in the BPMN notation) • Requires minimal semantic enhancements to process and enterprise models • 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

30. PEMR: Combined Framework

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

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

33. A parsimonious extension to BPMN • We extend BPMN with effect annotations • 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. • We expect an analyst to annotate BPMN tasks or sub-processes with their immediate effects

34. Effect annotations • Effect annotations can be: • Informal (e.g. plain English) • 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

35. Cumulative 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 • 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 • Cumulative effects specifications may be non-unique…

36. 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…

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

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 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 (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

39. 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.

40. Constrained Development Methodology Tool Demo

41. Annotating Effects of Tasks in BPMN Model Annotated Effects

42. Accumulation of EffectsOver Trajectories Accumulated Effects

43. Accumulation of EffectsOver Trajectories Unload Containers Task has Two Effect Scenarios as this task can be accomplished over two alternatives trajectories. Effect Scenarios

44. Accumulation of EffectsOver TrajectoriesDemonstration of an alternative trajectory Accumulated effects over one trajectory

45. Annotating Fulfillment Conditions to Tasks/Goals/Dependencies of i* Model Annotating fulfillment condition of task

46. Creating Realization Links Between Models

47. Sample Report of Consistency Evaluation