A handover problem may need a clearer flow, an explicit decision or a different arrangement between teams. Choose the description that helps people resolve that problem.
Contributions
The Object Management Group (OMG) publishes the process, case and decision notations below. Each addresses a different part of the work.
| Approach or reference | What it contributes | Use in the cancellation example |
|---|---|---|
| Business Process Model and Notation (BPMN) | A common notation for process flow and interactions. | Show the request, response and waiting points in a handover. OMG overview. |
| Case Management Model and Notation (CMMN) | Describes work that develops around a case and its changing circumstances. | Examine a cancellation whose next action depends on the learner’s response or an unresolved exception. OMG overview. |
| Decision Model and Notation (DMN) | Describes decisions and the information and rules they use. | Separate eligibility for an alternative from the work of contacting the learner. OMG overview. |
| Team Topologies | Examines team responsibilities and interaction through collaboration, service provision and facilitation. | Review how a delivery team obtains platform support, and whether repeated coordination is slowing changes. Team interaction modelling. |
| Google Cloud operational guidance | Describes incident roles, communication and escalation. | Name who restores service, coordinates supplier help and communicates with affected users. Incident guidance. |
These are selected contributions. The first three describe work and decisions; team and operational guidance helps examine how people organise and support them. The examples here use ordinary tables and diagrams. Formal model conformance and tool selection would require further work.
Choices to examine
| Choice | Potential advantage | Cost or consequence to examine |
|---|---|---|
| A continuing case owner | Context survives across activities and contacts. | Cover, capacity and access need attention when that person is unavailable. |
| A shared work queue | Work can be distributed among available staff. | Each active item still needs clear responsibility, and the next person needs enough context. |
| Local decision authority | Routine cases can progress with fewer referrals. | Staff need rules, skills and a route for exceptions. |
| Specialist or central decisions | Expertise and consistency can be concentrated. | Queues and repeated handovers may delay the outcome. |
| Automated routine actions | Repeated work can be delegated. | Rules, monitoring, exception handling and recovery must be maintained. |
These are just illustrative choices. A service may combine them. A responsibility matrix is useful when it clarifies who acts and decides; acceptance, timing and exception behaviour need a process description too.
Delegation and acceptance
Delegating work requires a clear scope of action, acceptance and recovery. A team member, a supplier and an automated service may have different decision rights. Describe those rights along with the work being delegated.
For example, an AI assistant might draft a learner message or suggest the next action. Decide what it may execute, what requires a person’s acceptance and who handles an uncertain result. Retain the input, proposed action, permission and result needed to review or recover the work.
Google’s Agent Development Kit documents an experimental action-confirmation mechanism that can pause a tool for a response. To use such a mechanism in a service, name who can respond, what they are accepting and how outstanding work is covered.
Methodology configuration
A role matrix, swimlane model, service agreement or team interaction map may already hold parts of this information. Match each record to the question it answers. The same meeting may settle a process change and the responsibilities needed to support it.
See configuration guidance and the cycles. Use the handover record where acceptance or waiting work needs clearer treatment.