Working with Business Processes Masterclass

Het programma start om 09.30 uur en duurt tot 17.00 uur. Registratie is mogelijk vanaf 08.30 uur.

[Indien Online format] U ontvangt van ons ruim vooraf de documentatie, online meeting instructies en uiteraard ook de uitnodiging met hyperlink voor toegang tot de virtuele sessie. Het programma start om 13:30 uur en duurt tot 17:00 uur. Log tijdig in en controleer vooraf uw geluid- en video instellingen.

1. Communicating the fundamentals of Business Processes

• Introduction – instructor and course background, themes and overview, participant introductions
• Building a presentation on “Business Process” – for executives and everyone else
• Why you should never assume everyone agrees “what is a process?” or that “process is good”
• Why you should never preach or oversell Business Process Management
• Why people fear “process,” and how to overcome this fear
• Five key points you must convey in a briefing on Business Process
• Confusion on what is meant by “business process,” and the impact on process improvement
• Michael Hammer’s legacy – “functions,” “processes,” and the terminology we all use today
• The most common source of confusion – “process” vs. “procedure”
• Levels of detail and perspectives – process domains, individual processes, activities, procedures
• Hammer’s legacy – understanding functional (who) and process (what) perspectives
• Case study: real-world (and expensive!) impacts of incorrectly identifying business processes
• A critical concept in all business process analysis – separating the “what” from the “who and how”
• The “TRAC” framework for clarifying “what” the process is – Trigger, Results, Activities, Cases
• The “Process Scope Model” and “Process Summary Chart” – “what” first, “who & how” later
• Types of Triggering Events and types of Final Results
• Why “input-process-output” is often a terrible framework for process work
• Real-life examples – clarifying “what” vs. “who & how” helping people embrace change
• How Process Scope Models and Process Summary Charts organize more detailed analysis
• The many benefits of using Scope Models and Summary Charts to avoid premature detail
• Simple process naming standards make all the difference
• Case study – how the naming standards helped a university identify real business processes
• Case study – how a Scope Model and Summary Chart helped execs see the need for change
• The good and the bad: why functionally based organisations are a good thing, and why functionally based organisations introduce process difficulties
• Why functionally based performance measures and reward systems may be the biggest obstacle
• The critical role of Business Process in purchased or bespoke system implementation
• Common factors in successful and unsuccessful system implementation
• Understanding the six enablers of a business process
• Using as-is process mapping to support an enabler-based assessment of the as-is
• The strategic differentiator – why your process can’t be great at everything
• Case studies – process change failures from not considering the differentiator
• A five-tier framework for relating goals & objectives, business processes, applications, and data
• Recognising three levels of detail – working through scope, concept, and specification levels
• How these levels of detail relate to Agile development – “Concept” is everything!
• A proven and unique methodology for completing a process-oriented project
• How the methodology helps everyone recognise and embrace the need for change

2. Identifying true, end-to-end, cross-functional Business Processes

• Review of the taxonomy – “Business on a Page” – “Process Area” – “Business Process”
• Depicting Process Areas with a Process Landscape
• Case study – using a structured method to identify “true” business processes
• A bottom-up approach beginning with familiar/recognisable activities
• Applying naming conventions to ensure everyone understands “what” the activities achieve
• Linking activities into chains of activities
• Using TRAC framework – triggers and results – to identify process boundaries within the chains
• Confirming the processes by understanding the flow of tokens through the activity connections
• Summary – six objective guidelines for business processes, and why businesspeople love them
• The connection between Concept Modelling and process discovery
• What next? Simplify “up” and refine “down”
• An important pattern – the “Arc of Modelling & Analysis.” Bottom-up – big picture – top-down

3. Developing a Process Architecture

• Case study introduction – Process Architecture within tight budget and time constraints
• Two core themes – “use available resources” and “non-invasively” (minimal disruption)
• A multi-pronged approach to discovering Business Processes at enterprise scale
• Why top-down process identification can lead to incorrect results
• Why bottom-up process identification can be more effective
• When and why a blended “meet-in-the-middle” approach can be superior
• Recap: Line of Business (“Core,”) Supporting (“Enabling,”) and Governance processes
• Recap: a proven taxonomy for Business Process Architecture
• “Off-the-shelf” process frameworks and reference models – what they are and are not good for
• Applying Michael Porter’s “Value Chain” – what worked and what did not work
• Identifying Line of Business process areas starting with a generic process model
• Using the Asset Management Life Cycle in identifying Supporting process areas
• Service Maps – a great way to discover the more granular services of each functional area
• Using “Role Profiles” from Human Resources to identify granular activities of each role
• “Meet in the middle” – map granular activities / services to process areas to ID processes
• Case study success! – a four-level process architecture within weeks, not months or years
• Samples from the Line of Business, Supporting, and Governance process categories
• The executive’s favourite – the “Business on a Page” graphic
• Statistics, metrics, observations, and executive reaction to the process architecture
• A less formal approach – developing a process architecture with expert people and a whiteboard
• Using the Process Architecture in a structured approach to planning process work
• Case Study – Using the Process Architecture to assess and support a new service offering
• Using the Process Architecture to determine the impact of “a simple change”
• Using the 6 process enablers to determine what would be needed for the “simple change” to work
• An interlude on the role of Concept Modelling in business process work
• What actually is a Concept Model? – essential components, core principles, sources of confusion
• Clarifying core terminology and building a Concept Model for the new service offering
• Cutting through the confusion and establishing the Business Rules through “assertions”
• Using the Concept Model as a starting point for discovering core application requirements
• An Agile approach to expressing system requirements as Business Services and Use Cases
• Using the Services, Use Cases/User Stories, and Rules to refine the Process Architecture
• Case study outcome – a to-be process workflow used to evaluate the proposed service offering
• More case studies of Concept Models clarifying and supporting process work
• Case study – the role of process modelling and concept modelling in a Big Data initiative
• Case study – using concept modelling to determine if a new process concept is viable

4. Seven ways to help people embrace Process Change

• Client thoughts on how a process perspective contributes to any organisational change
• Five approaches that work against encouraging change
• Reference – the leading approaches to organisational change
• Seven specific techniques to build support for process change
  1. The power of “venting” – let people “get it off their chest” – with a case study
  2. What first, who and how later – abstraction to the essence, and Essential Models
  3. How to build a compelling and blame-free Case for Change that answers why? and a Process Vision that answers where to? – with a case study
  4. Clarify what you need to be great at – the process’ strategic differentiator
  5. Understand enablers – the levers of change and the ones that matter most – with case study
  6. Applying frameworks for assessing culture and its impact on business process design
  7. A modular, feature-based approach to process design to be covered in Section 6
• Applying Force Field Analysis
• Understanding the belief systems of individuals and organisations
• Avoiding unanticipated consequences
• The lowly procedure and its impact on organisational culture

5. Human-oriented process modelling

• Basic principles for completing just enough as-is modelling
• Recap of the three basic components – actors, steps, and flow – and terminology variations
• Five reasons (often ignored) Swimlane Diagrams (“Workflow Models”) are so effective?
• Common errors – what not to do to ensure your models are as effective as possible
• Examples of what happens when the modeller doesn’t know the factors for successful swimlanes
• How and when to model the “what” (the essence) of a process vs. the “who and how”
• “Scope before flow” – how and why to build a “Process Scope Model” before mapping
• The “Augmented Scope Model” and why it’s often an effective alternative to flow modelling
• Two core principles – (1) “make the flow of work visible” and (2) “simple but not simplistic”
• The cognitive psychology of diagramming – what people first see on a diagram
• When and when not to use BPMN, UML, and other technically oriented approaches
• Guidelines on maximizing readability – stick to boxes and lines, and avoid graphic “widgets”
• “Flow first, detail later” – a fast approach to building a first-cut flow model and then refining it
• Using The Three Questions to achieve “flow first, detail later” and avoid common difficulties
• Two levels of detail in swimlane diagrams – Handoff and Service – with practical guidelines
• Case study – the surprising amount learned from a minimalist Handoff Diagram
• When to stop modelling workflow and switch to techniques that are better for detail
• Knowing if you’ve gone too far and aren’t modelling workflow anymore, and what to do about it
• Summary – 3 core principles, 5 reasons swimlane diagrams work, and 5 common errors

6. A feature-based Process Design method – transitioning from as-is to to-be

• What to do first when you’ve done enough as-is modelling
• The role of “leverage points”
• Two common redesign problems, two techniques to avoid them
• The pivot from as-is to to-be – the structured (and fast!) enabler-based final assessment
• Capturing more knowledge about the as-is process and generating ideas for the to-be process
• For each of the 6 enablers – assessment questions, a real-life example, and a client quote
• More enabler examples – conflict within/between enablers, a problem in one surfacing in another
• Using points in the Assessment by Enabler to generate potential to-be Features
• (Note a Feature is a significant process change or improvement, or major factor in to-be design)
• Using Group Brainwriting to collect, reduce, and select 5 to 10 key features of the to-be
• Avoiding unanticipated consequences – assessing each feature, enabler-by-enabler
• Examples – implementable, sustainable process via enabler-based assessment of each feature
• Creating the new process design – realising the to-be features in a workflow model
• Starting with an Augmented Scope Model to determine the essential to-be activities
• A critical sequence – what the activities are, and only then who, how, and when
• Building a dependency diagram for to-be activities, then a workflow model for the new process
• A real-life case study illustrating the methodology
• A checklist for ensuring the process is sustainable
• Client observations on the value of a structured approach
• The contribution of each of the steps in the three-phase methodology
• A reminder – “process change is a process – don’t skip steps”
• Job aids for you – a one-page summary of each of the three phases, and a one-page summary of the whole methodology
• Retrospective – each participant identifies “One Key Point”.