In this chapter
2.1 Begin with a decision, not an application inventory
The institution needs to authorize operational work, execute the approved action and explain its reporting. An application is one possible means. The capability model describes what must be possible even when offices, software or suppliers change. It should be stable enough to guide ownership without becoming a permanent organizational chart. For the worked example, discovery follows one request from submission to departmental review, finance approval, fulfilment and reconciliation. Rejected, withdrawn and amended requests are part of the journey. Describing only the successful path hides the decisions that often create operational risk.
2.2 Stakeholders and authority
| Stakeholder | Decision or need | Evidence to collect |
|---|---|---|
| Requester | Submit the correct version and learn its status | Representative request and failed submission |
| Department reviewer | Confirm purpose and completeness | Delegation rules and rejection reasons |
| Finance owner | Authorize amounts and define the reporting cut-off | Policy, approval sample and reconciled period |
| Operator | Act only on an authorized request | Fulfilment record and exception handling |
| Auditor or reviewer | Explain the sequence without changing it | Authorized access and traceability requirement |
A role name does not establish its legal or organizational authority. Interviews must distinguish policy, delegated authority and actual system permissions. A supplier must not invent a delegation rule because it simplifies the workflow.
2.3 Capability and responsibility map
| Capability | Accountable owner | First observable result |
|---|---|---|
| Request management | Business owner | Versioned request and explicit state |
| Approval control | Delegated approval owner | Authorized decision on a known version |
| Fulfilment | Operations owner | Execution linked to approval |
| Reconciliation | Finance owner | Explained differences and assigned exceptions |
| Platform support | System owner | Repeatable deployment and demonstrated recovery |
2.4 Local operating constraints
Connectivity, power, language, device sharing and maintenance access must be investigated at each selected office. “Low bandwidth” is too vague to design against. Capture representative conditions, the longest tolerable interruption and which tasks remain possible during it. For the scenario, disconnected drafting is proposed while final approvals remain online. This is a continuity policy with a cost: an office may have to wait. The business owner must compare that delay with the consequences of conflicting approvals. Offline finalization is a separate decision requiring conflict resolution and delegation rules.
2.5 Deliverables and acceptance
The context chapter produces a stakeholder register, one end-to-end journey, a capability map and a constraint register. Validate them in a joint walkthrough with the people who request, approve, fulfil and reconcile work. Record disagreements as open decisions with an owner and a due point. Acceptance means the map describes the agreed responsibilities; it does not mean a production system has been proven.