Discovery Workshop Plan and Record: [Engagement or programme name]
Plan and record for a series of facilitated discovery workshops that
establish how the business works today, what it needs, and how well a
candidate solution fits. One file covers the whole series: objectives,
participants, pre-reading and data requests, the session schedule and
agendas, the capture conventions, and the results (pain points,
requirements, fit-gap items, decisions, parking lot and actions), ending
with a playback that the business confirms. The structure follows the
Elicitation and Collaboration knowledge area and the Workshops technique
of the IIBA BABOK Guide v3, and the fit-to-standard workshop practice of
the Explore phase in SAP Activate, written vendor-neutrally so that it
serves custom builds, SaaS and ERP implementations alike. Replace every
[bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [DWP-001] |
| Engagement or programme | [Name] |
| Workshop series | [Series name, for example Order to cash discovery] |
| Version | [0.1] |
| Status | [Draft plan / Plan approved / In progress / Record confirmed] |
| Owner (lead facilitator) | [@lead-facilitator] |
| Solution architect | [@solution-architect] |
| Business sponsor | [@business-sponsor] |
| Approvers/reviewers | [@business-sponsor], [@process-owner], [@programme-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [Project charter], [Current-state assessment], [Stakeholder register] |
Approvals
| Role | Name | Approves | Date |
|---|
| Business sponsor | [@name] | Plan (sections 1 to 7) and confirmed record (section 14) | YYYY-MM-DD |
| Process owners | [@names] | Findings and requirements for their processes | YYYY-MM-DD |
| Solution architect | [@name] | Fit-gap results and design decisions | YYYY-MM-DD |
| Programme manager | [@name] | Schedule, actions and resourcing | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Draft plan |
| 0.2 | YYYY-MM-DD | [@name] | Example: Plan approved; fit-to-standard sessions extended to 6 hours |
| 0.5 | YYYY-MM-DD | [@name] | Example: Records of WS-01 to WS-04 added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Playback held; record confirmed by sponsor |
Contents
1. Objectives and outcomes
1.1 Context
[Two or three sentences: the initiative, why discovery is needed now, and
which decision or deliverable is waiting for its results. Example: The
programme is replacing the regional order management systems with one
cloud platform. The solution design cannot start until the order to cash
processes are understood across the three regions and compared with the
standard product processes.]
1.2 Objectives
| Objective ID | Objective | Output that proves it | Needed by |
|---|
| OBJ-01 (Example) | Document the current order to cash process in the three regions, including exceptions | Agreed process maps at level 3 with pain points | Solution design start, YYYY-MM-DD |
| OBJ-02 (Example) | Capture business requirements for the target process | Prioritised requirement list with owners | Same |
| OBJ-03 (Example) | Compare the standard product process with the business needs | Fit-gap register with a resolution option per gap | Design authority, YYYY-MM-DD |
| OBJ-04 (Example) | Agree the design principles that will decide future disputes | Signed principles list | Same |
| [OBJ-NN] | [Objective] | [Output] | YYYY-MM-DD |
1.3 Exit criteria
The series is complete when:
- every objective in section 1.2 has its output, reviewed by the named
process owner;
- every requirement has a priority, an owner and a source session;
- every gap has a proposed resolution option and an owner for the
decision;
- open questions that block design are either answered or have an owner
and a due date;
- the business sponsor has confirmed the record at the playback session
(section 14).
2. Scope and approach
2.1 Scope
| In scope | Out of scope |
|---|
| Example: Order capture, pricing, credit check, fulfilment, invoicing, cash application | Procurement and supplier payments |
| Example: Regions North, Central and South | Joint ventures |
| Example: Integrations with warehouse and payment systems | Data warehouse redesign |
| [Item] | [Item] |
2.2 Workshop style
Choose one style per session and state it on the agenda, because each
style needs different preparation and produces different outputs.
| Style | Use when | Main output | Preparation |
|---|
| Current-state discovery | The current process is poorly documented or varies by site | Current process map, pain points, volumes | Data requests, existing procedures |
| Needs and future-state | The business must agree what it wants before options are compared | Requirements, design principles, success measures | Current-state results, drivers |
| Fit-to-standard (product baseline) | A product or reference process exists and the question is how well it fits | Fit-gap register, configuration values, delta requirements | Configured demonstration environment, scripted scenarios |
| Design | A gap or decision needs a worked solution | Design options and a recommended choice | Fit-gap items, constraints, architecture principles |
| Playback and confirmation | Results of earlier sessions are ready for confirmation | Confirmed record and list of corrections | Consolidated findings, requirements, fit-gap register and decisions |
2.3 Series structure
Run the styles in order: discovery first, then fit-to-standard, then
design, with one-to-one interviews filling gaps between sessions. Adjust
the diagram to your series.
2.4 Approach principles
| ID | Principle | Consequence |
|---|
| WSP-01 (Example) | Start from the standard process; justify every deviation by a business reason | Each gap records the reason and the value at stake |
| WSP-02 (Example) | The people who do the work attend, not only their managers | Each session includes at least one practitioner per region |
| WSP-03 (Example) | Decisions are made by the named process owner in the room or within five working days | Section 11 lists the decision owner and due date |
| WSP-04 (Example) | Nothing is designed in discovery sessions | Design ideas go to the parking lot until WS-07 |
| [WSP-NN] | [Principle] | [Consequence] |
3. Participants and roles
3.1 Workshop roles
| Role | Responsibility in the series | Name |
|---|
| Business sponsor | Sets objectives, resolves escalations, confirms the record | [@name] |
| Lead facilitator | Plans sessions, runs the room, keeps time, protects the agenda | [@name] |
| Scribe | Captures findings, requirements and decisions live, using the ID scheme | [@name] |
| Solution architect | Explains the solution baseline, tests feasibility, owns fit-gap and design decisions | [@name] |
| Business analyst | Models processes, writes requirements, maintains traceability | [@name] |
| Process owner | Decides for their process; approves findings and requirements | [@names] |
| Practitioners and subject matter experts | Describe the work as it is done, with examples and volumes | [@names] |
| IT operations and integration owners | Explain current systems, interfaces and data | [@names] |
| Security, privacy and compliance | Flag regulatory and control requirements early | [@names] |
| Product or vendor expert (fit-to-standard) | Demonstrates the standard process and explains configuration options | [@names] |
3.2 Attendance by session
| Participant | WS-00 | WS-01 | WS-02 | WS-03 | WS-04 | WS-05 | WS-06 | WS-07 | WS-08 |
|---|
| Example: Head of Sales Operations (process owner) | R | R | R | O | R | R | O | R | R |
| Example: Order desk lead, North | O | R | R | R | R | R | R | O | O |
| Example: Credit controller | | | R | | | R | | O | O |
| Example: Integration architect | O | | | R | | | R | R | O |
| [Name or role] | [R / O] | | | | | | | | |
R means required (the session does not run without them or a named
delegate with authority); O means optional.
4. Pre-reading and data requests
4.1 Pre-reading for participants
| Item | Purpose | Sent on | Sessions |
|---|
| Workshop plan (sections 1 to 7 of this document) (Example) | Shared objectives, ground rules and schedule | YYYY-MM-DD | All |
| Standard process overview of the candidate product (Example) | Participants arrive knowing the baseline | YYYY-MM-DD | WS-04 to WS-06 |
| Draft design principles (Example) | Comments collected before WS-00 | YYYY-MM-DD | WS-00 |
| [Item] | [Purpose] | YYYY-MM-DD | [Sessions] |
4.2 Data requests
| Request ID | Item requested | From | Due | Received | Used in |
|---|
| DR-001 (Example) | Order volumes per month and per channel for the last 12 months | Sales operations | YYYY-MM-DD | [Yes / No / Partial] | WS-01 |
| DR-002 (Example) | Current procedures, work instructions and process maps | Process owners | YYYY-MM-DD | [Status] | WS-01 to WS-03 |
| DR-003 (Example) | Ten real orders with exceptions (anonymised) | Order desk leads | YYYY-MM-DD | [Status] | WS-02, WS-05 |
| DR-004 (Example) | Interface list with volumes and frequencies | Integration owner | YYYY-MM-DD | [Status] | WS-03, WS-06 |
| DR-005 (Example) | Report catalogue and the ten most used reports | Business intelligence team | YYYY-MM-DD | [Status] | WS-06 |
| DR-006 (Example) | Organisation structure: legal entities, sales organisations, plants | Finance | YYYY-MM-DD | [Status] | WS-00, WS-04 |
| [DR-NNN] | [Item] | [Owner] | YYYY-MM-DD | [Status] | [Session] |
Treat data received as confidential, remove personal data unless it is
needed, and store it only in the engagement workspace. If personal data is
processed, check whether a Data Protection Impact Assessment
(compliance/dpia) is needed.
5. Session schedule
| Session ID | Title | Style | Date and time | Duration | Location or link | Facilitator | Depends on |
|---|
| WS-00 (Example) | Kick-off, objectives and design principles | Needs and future-state | YYYY-MM-DD 09:00 | 3 h | [Room / link] | @lead-facilitator | Plan approved |
| WS-01 (Example) | Order capture and pricing: current state | Current-state discovery | YYYY-MM-DD 09:00 | 4 h | [Room / link] | @lead-facilitator | DR-001, DR-002 |
| WS-02 (Example) | Credit, exceptions and returns: current state | Current-state discovery | YYYY-MM-DD 09:00 | 4 h | [Room / link] | @lead-facilitator | DR-003 |
| WS-03 (Example) | Systems, interfaces and data | Current-state discovery | YYYY-MM-DD 13:00 | 3 h | [Room / link] | @solution-architect | DR-004 |
| WS-04 (Example) | Order capture: fit-to-standard | Fit-to-standard | YYYY-MM-DD 09:00 | 6 h | [Room / link] | @product-expert | WS-01, environment ready |
| WS-05 (Example) | Credit and exceptions: fit-to-standard | Fit-to-standard | YYYY-MM-DD 09:00 | 6 h | [Room / link] | @product-expert | WS-02 |
| WS-06 (Example) | Invoicing, reporting and integrations: fit-to-standard | Fit-to-standard | YYYY-MM-DD 09:00 | 6 h | [Room / link] | @product-expert | WS-03 |
| WS-07 (Example) | Design of priority gaps | Design | YYYY-MM-DD 09:00 | 4 h | [Room / link] | @solution-architect | WS-04 to WS-06 |
| WS-08 (Example) | Playback and confirmation | Playback | YYYY-MM-DD 14:00 | 2 h | [Room / link] | @lead-facilitator | All |
| [WS-NN] | [Title] | [Style] | YYYY-MM-DD hh:mm | [h] | [Location] | [@name] | [Dependency] |
Leave at least half a day between sessions for write-up and review, and
keep one buffer session in reserve for topics that overrun.
6. Session agendas
6.1 Agenda example: WS-04 Order capture, fit-to-standard
| Time | Block | Lead | Output |
|---|
| 09:00 (Example) | Welcome, objectives, ground rules, recap of WS-01 findings | Lead facilitator | Shared starting point |
| 09:20 (Example) | Walk-through of the standard order capture scenario in the demonstration environment | Product expert | Participants see the baseline end to end |
| 10:30 (Example) | Scenario variants: rush orders, split deliveries, consignment | Product expert, practitioners | Fit or gap noted per variant |
| 11:30 (Example) | Break | | |
| 11:45 (Example) | Configuration values: order types, pricing conditions, output forms | Product expert, business analyst | Values captured or requested |
| 12:45 (Example) | Lunch | | |
| 13:30 (Example) | Gap review: business reason, value at stake, resolution option | Solution architect | Draft fit-gap rows |
| 14:30 (Example) | Decisions and parking lot review | Process owner | Decisions recorded, owners for the rest |
| 14:50 (Example) | Actions, next session, feedback | Lead facilitator | Action list, feedback scores |
| 15:00 (Example) | Close | | |
This agenda is written for an in-person session. For a remote or hybrid
session, add a 10-minute break between the 09:20 and 10:30 blocks so
that no stretch runs longer than 90 minutes (section 7.4).
6.2 Agenda pattern for other sessions
Use the same pattern for every session: a short recap and objectives
block; one or two content blocks, each ending in a named output; a gap or
issue review block; a decisions block led by the process owner; and a
closing block that reads back actions and owners. Copy the table in 6.1
for each session and keep the agenda in this file so that the plan and
the record stay together.
| Session | Agenda status | Agenda link or section |
|---|
| WS-00 | [Draft / Final] | [New subsection 6.3, added per session] |
| WS-01 | [Draft / Final] | [New subsection 6.4, added per session] |
| [WS-NN] | [Status] | [Section] |
7. Facilitation and capture method
7.1 Ground rules
| Rule | Why |
|---|
| Describe the work as it is actually done, with real examples | Written procedures often differ from practice |
| One conversation at a time; the facilitator manages the queue | Remote and quieter participants get heard |
| Design ideas go to the parking lot during discovery | Keeps sessions on their objective |
| Decisions are made by the named owner, or given an owner and a date | Prevents silent assumptions |
| Disagreement is recorded, not smoothed over | Unresolved conflicts surface early |
| Cameras on for remote participants where possible; chat is monitored | Improves engagement and capture |
7.2 Capture conventions
| Item | ID prefix | Where captured | Minimum fields |
|---|
| Pain point or finding | PP- | Section 8 | Description, process step, frequency or volume, impact, source session |
| Requirement | REQ- | Section 9 | Statement, type, priority, owner, source session, acceptance hint |
| Fit-gap item | FG- | Section 10 | Scenario, fit status, business reason, resolution option |
| Decision | DEC- | Section 11 | Decision, rationale, decision owner, date |
| Assumption | ASM- | Section 12 | Assumption, owner, validate by |
| Open question | Q- | Section 12 | Question, owner, due |
| Parking lot item | PL- | Section 12 | Topic, raised by, destination |
| Action | ACT- | Section 13 | Action, owner, due, status |
Number items in one sequence per type across the whole series and never
reuse a number. When an item is merged or withdrawn, keep the row and
mark its status.
7.3 Tools and environment
| Need | Choice |
|---|
| Process modelling notation | Example: BPMN 2.0 with swim lanes per role, level 3 for discovery |
| Live capture | Example: This document on a shared screen, plus a whiteboard for maps |
| Remote collaboration | [Video tool, shared whiteboard, chat channel] |
| Demonstration environment (fit-to-standard) | [Environment name, data set, user IDs] |
| Recording | [Not recorded / Audio for scribe use only, deleted after write-up], with consent stated at the start |
| Feedback | [Short survey at the end of each session] |
7.4 Remote and hybrid sessions
Keep remote sessions to blocks of 90 minutes or less with breaks between
them, name a co-facilitator to watch the chat and the hand-raise queue,
share the capture screen continuously, and ask remote participants by
name at each decision point. In hybrid sessions, give remote participants
the first turn on each topic so that the room does not dominate.
8. Process and pain-point findings
8.1 Process overview
[Insert or link the agreed current-state process map per process. Note
regional variants explicitly.]
8.2 Pain points
| ID | Process step | Finding | Frequency or volume | Impact | Region | Source |
|---|
| PP-001 (Example) | Order keyed | Email orders are re-keyed manually; about 30 % need a call back for missing data | Example: 1,800 email orders per month | Delay of 1 day on average; keying errors | All | WS-01 |
| PP-002 (Example) | Credit check | Credit holds are reviewed in a spreadsheet outside the system | Example: 220 holds per month | No audit trail; orders wait up to 3 days | North, Central | WS-02 |
| PP-003 (Example) | Pricing | Customer-specific prices are kept in three different places | Not measured | Price disputes and credit notes | All | WS-01 |
| PP-004 (Example) | Invoice | Invoice corrections are made by cancelling and re-issuing | Example: 4 % of invoices | Rework, customer complaints | South | WS-02 |
| [PP-NNN] | [Step] | [Finding] | [Volume] | [Impact] | [Region] | [WS-NN] |
9. Requirements captured
| ID | Requirement | Type | Priority | Owner | Source | Related | Acceptance hint |
|---|
| REQ-001 (Example) | Orders received by email shall be captured without re-keying the order lines | Business | Must | @head-sales-ops | WS-01 | PP-001 | 90 % of email orders created without manual line entry |
| REQ-002 (Example) | Every credit hold release shall record who released it, when and why | Business, compliance | Must | @credit-manager | WS-02 | PP-002 | Audit report shows user, timestamp and reason for each release |
| REQ-003 (Example) | Customer-specific prices shall be maintained in one place and applied automatically | Business | Must | @pricing-manager | WS-01 | PP-003 | No price maintained outside the pricing master |
| REQ-004 (Example) | Order status shall be visible to customers on the portal within 15 minutes of a change | Functional, quality | Should | @head-sales-ops | WS-01 | | Status lag measured below 15 minutes in test |
| REQ-005 (Example) | Invoice corrections shall be made by credit and re-bill with a reference to the original | Business | Should | @billing-lead | WS-02 | PP-004 | Correction document references original invoice |
| [REQ-NNN] | [Requirement] | [Business / Functional / Quality / Data / Compliance / Transition] | [Must / Should / Could / Won't] | [@owner] | [WS-NN] | [PP- / FG-] | [Acceptance hint] |
Quality requirements (performance, availability, security, usability)
raised in workshops are recorded here and then refined as measurable
scenarios in Quality Attributes (requirements/quality-attributes) or the
NFR Catalogue (requirements/nfr-catalogue).
10. Fit-gap results
10.1 Fit status definitions
| Status | Meaning |
|---|
| Fit | The baseline meets the need as demonstrated, with configuration only |
| Fit with change | The baseline meets the need if the business changes its process |
| Gap | The need cannot be met by configuration or process change |
| Not applicable | The baseline scenario is not used by this business |
10.2 Register
| ID | Scenario | Status | Business reason for difference | Value at stake | Resolution option | Decision owner | Related |
|---|
| FG-001 (Example) | Standard order entry with automatic pricing | Fit | | | Configure order types and pricing conditions | @head-sales-ops | REQ-003 |
| FG-002 (Example) | Email order capture | Gap | High email volume (PP-001) | 1 FTE per region in keying effort | Document capture service integrated through the standard order interface | @solution-architect | REQ-001 |
| FG-003 (Example) | Credit hold release with reason codes | Fit | | | Configure reason codes and approval roles | @credit-manager | REQ-002 |
| FG-004 (Example) | Regional invoice layout | Fit with change | Regions use three layouts out of habit | Low | Adopt one layout with regional legal text | @billing-lead | REQ-005 |
| FG-005 (Example) | Consignment stock billing | Gap | Contracts with two key customers | Example: USD 6 million annual revenue | Extension on the platform's extension layer; design in WS-07 | @solution-architect | |
| [FG-NNN] | [Scenario] | [Status] | [Reason] | [Value] | [Configure / Process change / Extension / Integration / Report / Reject] | [@owner] | [REQ-] |
Summary (Example): 46 scenarios reviewed; 31 fit, 8 fit with change,
5 gaps, 2 not applicable. Record the full analysis and effort per gap in
the Fit-Gap Analysis (architecture/fit-gap-analysis) when the series
feeds a package implementation.
11. Decisions
| ID | Decision | Rationale | Alternatives considered | Decision owner | Date | Session |
|---|
| DEC-001 (Example) | Adopt the standard order types; no region-specific order types | Simplifies reporting and training; no regulatory reason found for differences | Keep regional order types | @head-sales-ops | YYYY-MM-DD | WS-04 |
| DEC-002 (Example) | Credit decisions remain with regional controllers, using one shared workflow | Local knowledge of customers matters; audit trail achieved by the workflow | Central credit team | @cfo-delegate | YYYY-MM-DD | WS-05 |
| DEC-003 (Example) | Design principle: no custom code where a process change meets the need | Lowers upgrade cost | Allow custom code with board approval | @business-sponsor | YYYY-MM-DD | WS-00 |
| [DEC-NNN] | [Decision] | [Rationale] | [Alternatives] | [@owner] | YYYY-MM-DD | [WS-NN] |
Decisions with architectural impact are also recorded in the Architecture
Decision Log (architecture/architecture-decision-log).
12. Assumptions, open questions and parking lot
12.1 Assumptions
| ID | Assumption | Impact if false | Owner | Validate by |
|---|
| ASM-001 (Example) | Warehouse system interfaces will remain unchanged during the programme | Interface redesign needed | @integration-owner | YYYY-MM-DD |
| [ASM-NNN] | [Assumption] | [Impact] | [@owner] | YYYY-MM-DD |
12.2 Open questions
| ID | Question | Raised in | Owner | Due | Answer |
|---|
| Q-001 (Example) | Does the South region need e-invoicing under local tax rules from next year? | WS-02 | @tax-lead | YYYY-MM-DD | [Answer] |
| [Q-NNN] | [Question] | [WS-NN] | [@owner] | YYYY-MM-DD | [Answer] |
12.3 Parking lot
| ID | Topic | Raised by | Destination | Status |
|---|
| PL-001 (Example) | Customer self-service returns portal | Order desk lead, South | Phase 2 backlog | Agreed out of scope for phase 1 |
| PL-002 (Example) | Design of consignment billing extension | Solution architect | WS-07 | Scheduled |
| [PL-NNN] | [Topic] | [Name] | [Session / Backlog / Out of scope] | [Status] |
13. Actions
| ID | Action | Owner | Due | Status | Raised in |
|---|
| ACT-001 (Example) | Provide anonymised examples of consignment contracts | @key-account-manager | YYYY-MM-DD | Open | WS-05 |
| ACT-002 (Example) | Confirm monthly email order volume by region | @order-desk-leads | YYYY-MM-DD | Done | WS-01 |
| ACT-003 (Example) | Prepare two design options for FG-005 | @solution-architect | YYYY-MM-DD | Open | WS-05 |
| [ACT-NNN] | [Action] | [@owner] | YYYY-MM-DD | [Open / Done / Cancelled] | [WS-NN] |
14. Playback and confirmation
14.1 Playback session
| Field | Value |
|---|
| Session | [WS-08] |
| Date | YYYY-MM-DD |
| Attendees | [Names] |
| Content played back | Example: Process maps, top 10 pain points, Must requirements, all gaps, all decisions, open questions |
| Corrections raised | [Number and summary] |
| Items added | [Number and summary] |
14.2 Confirmation
| Confirmation | Confirmed by | Date | Conditions |
|---|
| Current-state findings are accurate | [@process-owners] | YYYY-MM-DD | [None / Listed] |
| Requirements and priorities are accepted as the basis for design | [@business-sponsor] | YYYY-MM-DD | [Conditions] |
| Fit-gap results and resolution options are accepted for estimation | [@business-sponsor], [@solution-architect] | YYYY-MM-DD | [Conditions] |
| Remaining open questions have owners and dates | [@programme-manager] | YYYY-MM-DD | [Conditions] |
After confirmation, freeze this version of the record. Later changes go
through Change Control (project/change-control) and add a revision row.
15. Traceability
| Objective | Sessions | Findings | Requirements | Fit-gap items | Decisions | Status |
|---|
| OBJ-01 (Example) | WS-01, WS-02, WS-03 | PP-001 to PP-004 | | | | Complete |
| OBJ-02 (Example) | WS-00 to WS-06 | | REQ-001 to REQ-005 | | DEC-003 | Complete |
| OBJ-03 (Example) | WS-04 to WS-07 | | | FG-001 to FG-005 | DEC-001, DEC-002 | Gap FG-005 design pending |
| OBJ-04 (Example) | WS-00 | | | | DEC-003 | Complete |
| [OBJ-NN] | [Sessions] | [PP-] | [REQ-] | [FG-] | [DEC-] | [Status] |
Carry requirement-level traceability forward into the Traceability Matrix
(requirements/traceability-matrix).
16. Series review
| Measure | Target (Example) | Actual |
|---|
| Sessions held as planned | 9 of 9 | [Value] |
| Required attendees present (average per session) | 90 % | [Value] |
| Data requests received by due date | 80 % | [Value] |
| Session records issued within 2 working days | 100 % | [Value] |
| Corrections raised at playback (lower is better) | Fewer than 10 | [Value] |
| Open questions without an owner at close | 0 | [Value] |
| Participant feedback (1 to 5) | 4 or more | [Value] |
| What worked | What to change next time |
|---|
| [Observation] | [Change] |
17. Glossary and references
17.1 Glossary
| Term | Meaning |
|---|
| Baseline (product) | The standard processes and configuration of the candidate product as delivered |
| Delta requirement | A need that the baseline does not meet and that requires additional work |
| Elicitation | Drawing out information from stakeholders and other sources |
| Fit-to-standard | A workshop style that demonstrates the baseline and records how well it meets the need |
| Parking lot | A visible list of topics deferred so that the session keeps to its objective |
| Playback | A session that presents the results back to the contributors for confirmation |
| Process owner | The person accountable for a process and entitled to decide how it works |
17.2 References
| ID | Reference | Version or date | Use |
|---|
| REF-01 | A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis | Version 3, 2015 | Elicitation and Collaboration knowledge area; Workshops, Interviews and Document Analysis techniques (structure only) |
| REF-02 | SAP Activate methodology, SAP (learning.sap.com and sap.com) | Checked 2026-10-23 | Explore phase fit-to-standard practice, phase names |
| REF-03 | Business Process Model and Notation (BPMN), Object Management Group | 2.0.2 (January 2014) | Process maps |
| REF-04 | Stakeholder Register (project/stakeholder-register) | [Version] | Participant selection |
| REF-05 | Current-State Assessment (architecture/current-state-assessment) | [Version] | Systems and data context |
| REF-06 | [Internal methodology] | [Version] | [Use] |
Standard and licence note
Structure aligned with the Elicitation and Collaboration knowledge area
and the Workshops technique of A Guide to the Business Analysis Body of
Knowledge (BABOK Guide) Version 3, published by the International
Institute of Business Analysis, and with the fit-to-standard workshop
practice of the Explore phase of SAP Activate. Only knowledge area,
technique and phase names are used; no text, task description, table or
diagram from BABOK or SAP material is reproduced, and all guidance and
examples are original. Obtain the BABOK Guide from IIBA for its full
guidance and check the current SAP Activate content at learning.sap.com.
BABOK and IIBA are registered trademarks of the International Institute of
Business Analysis; SAP and SAP Activate are trademarks of SAP SE; this
template is not affiliated with or endorsed by them. Template licence: MIT.