BPM/SA Course Overview - Introduce Team, Participants, Facilities, OH&S Issues

1. Chief Information Officer Group BRANCH Division BPM Course – Block01 Welcome and Overview

2. Overview • Introduce the Team • Introduce the Participants • Location of facilities • OH & S Issues • The nature of the course • Resources • Course Plan • EA, the DAF and the DIE • Where BPM fits in

3. Introducing the Team • James Sheridan – the original creator and presenter of the course. • Don Munro – revised the course following James’ death and created the PowerPoint Lessons and the Lab Exercises. • Robert Giles – provided the technical support and advice for the Systems Architect specific components. • Hamish Smith – coordinated and directed the effort, and is responsible for the evolution of the training resources.

4. Mr James Sheridan; died 27 May 2006 • Employment - PSP working for Defence from SMS Management and Technology: developed the BPM/SA course and delivered it 6 times 2005/06 • Background – BA, DBA, Service Management, Systems Admin, Modelling and EA tools • Industry Experience – Defence (Ex Army 22 years), HR and Finance Systems, Aircraft Maintenance, Engineering Services • Interests – Horses, EA, Astronomy

5. Mr Don Munro • PSP working for Defence • BA (ANU Computer Science), M.Inf.Sc (UNSW Information Science) • 10 years in Industry; 28 years in Universities (CSU Wagga and UNSW@ADFA) • Active in consultancies • Active in Course design & review committees both at University and CIT (TAFE) • Designed and delivers the Enterprise Architecture course as part of the Doctorate in Business Informatics for DPU University in Bangkok, Thailand

6. Location of Facilities • Course Location • Toilets • Fire / Evacuation points • Canteen • Lunch room • Morning and Afternoon tea facilities

7. OH & S Issues • Fire & Evacuation plan • Any Training room hazards • Trainers all current OH & S • Mobile phones OFF or SILENT (Please go outside if you have to speak) • Feel free to stand up and stretch if you start to cramp or fall asleep

8. Introduce Participants • Who you are • Where you are currently working • The extent of your immersion in BPM/SA • What you hope to get from the course • How you hope to use the skills from the course

9. Diploma of Government (Enterprise Architecture) Course Location

10. Points to note • The BPM Course is an entry level course • Understand the nature and history of BPM • Exposure to the notation used • Experience reading BPM diagrams • Experience creating BPM diagrams • The 2-day Systems Architect course (which normally follows this one) gives instruction and experience in using that tool to create BPM and DAF products.

11. Delivery Method • One day face-to-face training: • Lecture presentations • Question and answer sessions • Reading and Understanding • Group work discussion and activities • Review and evaluation

12. Successful Completion of Training • There is no final exam or test • You will know the course has been successful if you can • Communicate the reasons for undertaking the BPM activity • Know how to approach the creation of BPM products • Know where to get help and assistance when you find you don’t know something; ask questions along the way

13. Resources • CDROM • All presentations • Copies of manuals and reference documents • Workbook • Notes • Written material • Exercises

14. Course Plan

15. Overview EA, the DAF and the DIE • Review the reasons why Defence wants to use the approach of Enterprise Architecture • Review the DIE and the DAF • Review DAF products • See where BPM products fit in

16. Group DiscussionReasons for Using Enterprise Architecture • Size • Scope • Complexity • Interoperability • Agility • Effectiveness • Efficiency

17. Chief of the Defence Force • “We are living in very uncertain times. Our Defence Organization, and the Defence Force in particular, must be agile enough to adjust to the ever-increasing and diverse demands of the future.” (page iii) P.J. Cosgrove AC, MC, (2004), Enabling Future Warfighting: Network Centric Warfare Concept, ADDP-D.3.1

18. Benefits • A means of ensuring that force and platform integration, which is at the heart of joint and combined operations, remains a focal outcome; • A common language underpinned by standards that are applicable to the whole force; • A structured, disciplined and consistent framework that supports capability development and capability management decision-making; • A visual representation of capability issues and connectivity requirements across the whole networked force regardless of owner or usage; and • A description of the relationship between operational need and system/technology solutions and options. (page 28)

19. Benefits • A common approach to business throughout the organization based on shared knowledge and aligned processes • Better information flows through clearly defined structures supported by relevant systems • More efficient use of existing resources • Improved interoperability between system and networks (technical and cognitive) • Better understanding and management of global issues such as security • Replacement of functional stovepipes and disparate applications by modular, integrated, process oriented systems • Alignment of IT infrastructure with business requirements • Higher application portability and strategically driven software development and maintenance • Rationalization of legacy applications against whole of organization functional requirements

20. Scope of the DIE Single entity, encompassing: • Intelligence • Surveillance • Reconnaissance • Communications • Information Warfare • Electronic Warfare • Command and Headquarters Systems • Management (Logistics and Business)

21. DIE

22. DIE

23. Business Enterprise Architecture Information Defines Systems Security Standards Influences Infrastructure Determines DEFENCE ARCHITECTURE FRAMEWORK Governance, Compliance & Coordination Specific Operational and Business Descriptions Operational View Represented By Systems View Common View Data View Technical View Operational & Business Context Fundamental Inputs to Capability Populated By Defence Enterprise Architecture Library Defence Architecture Information Model Supported By Repository Tools Research and Technology Influences

24. Typical Sequence OV-1 Architecture Purpose High Level Concept Graphic (ie context diagram) CV-1 Overview & Summary (ie textual Description) Users & Decision Needs Products Required & Scope CV-2 IntegratedDictionary OV-4 Command Rel Chart (ie Org’s & Roles) OV-6 Op Rules Model (ie process flow) Common & Operational Views OV-7 Logical Data Model (ie ID logical data objects) OV-5’s OV-3 Activity Models (ie op activities and input/outputs) Op Information Exchange Matrix OV-2 Op Node Connectivity(ie Grouped Op Activities and Info Exchanges) You need to know these things before you start Do these things first Go to System & Technical Views

25. Common & Operational Views OV-2 Op Nodes (ie op activity Groupings) CV-2 SV-1 System Interface Descr SV-6 IntegratedDictionary System Data Exchanges Matrix SV-2 System Comms Descr TV-1 Technical Arch Profile (ie standards, policy, doctrine etc) SV-7 SV-5 Sys Performance Parameters TV-2 Op Activities to System Function traceability Matrix) SV-9 Standards Technology Forecast SV-3 System Technology Forecast System To System Matrix OV-7 SV-10(s) Logical Data Model (ie ID logical data objects) SV-8 OV-5’s System Rules, Sequences Sys Evolution Descr (ie roadmap) OV-3 Activity Models (ie op activities and input/outputs) Op Information Exchange Matrix SV-4 Systems Functionality Descr SV-11 Physical Data Model TypicalSequence Cont) Purpose, Decision Needs, Scope Do these things next. OV-6(s) System & Technical Views

26. Overview Where BPM fits in • See where BPM products fit in • See what BPM products contribute • Introduce the Notation

27. BPM? Why Focus on Process? • Because that’s the way organizations get things done • Recording process is the first step towards Business Process Re-engineering (BPR) • Recording process identifies best practice • ISO9000 certification requires process mapping and documentation to define standard ways of doing things • The Military use Standard Operating Procedures (SOPs) to inform training and quality control

28. What are Enterprise Processes? • Very high level processes that set the tone and nature of the enterprise • These processes are directly related to the enterprise achieving its objectives in support of its mission (Vision) statement What are the Defence Enterprise Processes?

29. Defence Enterprise Processes (EP) Lexicon Hierarchy The Defence Enterprise Processes (EP) agreed to by the Defence Committee see DC 39/04. i.e. Operations, Strategic Planning, Finance etc. These are the high level activities carried out by Defence to achieve its mission/vision. Note: OV2 diagram(s) could be drawn at any of these levels but should be derived from the detail contained in the OV5 ie function/activity based. Defence EP Components are optional and can be used as an intermediate grouping or categorisation to help deal with complex EP’s, e.g. the Defence Finance EP could be broke down into EP components of Governance, Financial Processes and Enablers. Note: Simple EP’s may not need these. Enterprise Processes (EP) 3 Star level ie Finance, logistics, Capability Development An Enterprise Process Model could be drawn to represent the business process structure at these two levels. Eg see the ‘Defence Finance Model’. Note: For simple EP’s there may not be a need to create an EP Model or use Functional Groups. EP Models are not currently part of the DAF. EP Components ie Finance Governance, Financial Processes and Financial Enablers These are optional and represent the grouping of functions that define the EP’s or EP Components. For simple EP’s there may not be a need to use Functional Groups. Functional Groups ie Planning & Budgeting, Operations, Reporting, Policy & Control, represented by OV5 Node Trees and level 0 OV5 Activity Model diagrams Functions , 2 Star level ie Portfolio Budget, Treasury Management, and represented by Functional and Process Map diagrams (OV5 and OV6) drawn and modelled in tools such as System Architect. OV5 Node Trees and a hierarchy of OV5 Activity Models These are functional decomposition with inputs and outputs, not sequence Process Models ie OV6 Diagrams, sequence diagrams

30. Enterprise Business Process Relationship Roles/Competencies IT and Comms Technology Organisational Structures Business Enterprise judged by BusinessPerformance Human Resources Processes Policy, Doctrine, Rules etc Facilities/Infrastructure/Assets By James Sheridan based on Process Management hexagon by Roger Burlton, Business Process Management, SAMS Publishing 2001.

31. IDEF0 Review • Boxes • Have a Name (Function or Activity name [verb phrase]), and • a Number (indicating parent/child relationships) • Arrows • Have a Name (Data or Influence name [Noun or Noun phrase]) and • a single Arrowhead indicating direction of flow • Good names aid understanding! • “If in doubt, leave it out!”

32. OV5 or IDEF0 Diagram and its relationship with an EP Model This box represents an EP Model such as the ‘Defence Finance Model’ Control are typically things like policy documents or guidelines Governance Controls IDEF0 or OV5 Activity Model Financial Processes Inputs Outputs Mechanisms Mechanisms are typically things like computer applications. Enablers Note: Inputs and Outputs are made into Information Exchanges (OV3) and they should relate directly to start and end events in the OV6 Business Process Maps

33. Other IDEF0 Concepts • Context Diagram - Top Level; Single Box; A-0 • Level Zero Diagram – explodes the context diagram • Parent Diagram – contains boxes that are exploded into Child Diagrams • Child Diagram – contains a set of boxes that represent a single box on a Parent Diagram • Tunnelled Arrows – arrows that are shown on a Parent Diagram but NOT on each level of Child Diagrams until the Child Diagram that actually processes/produces them

34. OV5 Activity Model Diagrams OV5 Node Tree Diagram Context or Level 0 Functional Hierarchy IDEF0/Activity Model – Functional Decomposition Standard Level 1, sub functions of level 0

35. Example of a BPMN Diagram Standard

36. Relationship of BPM to DAF • The OV-5 Activity Diagrams and Node Tree representations are used to define the Operational Activity hierarchy, but they are not intended to show flow or sequence, only decomposition. • The OV-6a Process Flowchart or Map can be represented by BPMN diagrams and are used to show flow or sequence. • OV-6 BPMN diagrams should only be attached to “leaf nodes” of the OV-5 Activity diagrams

37. This group of nodes is at Level 3 and comes from node 4 from the level above. This node is represented by an OV5 Activity Model diagram shown on the left hand side below. Note Naming conventions between OV5 and OV6 can be used to help support this type of relationship. This OV5 Activity Model diagram represents the group of nodes from the node tree. One or more Operational Activity(s) (the rectangular symbols) can be described or defined using an OV6 BPMN diagram. The steps involved in carrying out this activity can be represented by an OV6 BPMN Process Flow diagram. The OV6 diagram is therefore a child diagram of the OV5 node. NB: The OV6 diagram is labelled with the same name as the Operations Activity symbols it represents, this is the recommended naming convention to use.