Evidence at every gate

Video transcript

1. 0:00–0:06

   Define a complete process • A module name does not define the job. • “Purchasing module” · scope still unclear • Request + required inputs • Approval + authority • Receipt + handover • Business owner names boundaries and receiving team

   A broad purchasing-module label expands into a complete process: request and required inputs, approval authority, and receipt with handover. The business owner specifies the release boundaries and receiving team. The four article gates are a planning worksheet, not a vendor certification or fixed implementation schedule.

2. 0:06–0:12

   Inspect real behavior • Use the intended roles and exceptions. • Request • Approval rule • Missing reference • Required supplier reference missing → correction route • Requester approval: test the agreed permission rule • Proposed tasks; no passed result or universal control

   A hypothetical purchasing request branches to the missing supplier-reference case and its correction route. A separate approval-rule crop accompanies the question of whether the requester may approve. Test the behaviour specified by the authority owner; the film presents proposed acceptance tasks, not successful results or universal purchasing controls.

3. 0:12–0:18

   Let users perform the work • Record tasks against the reviewed configuration. • Receipt exception • Receiving user · intended role • P17 · task + observed result + issue owner • CFG2 · configuration • Configuration changes? Repeat affected tasks

   A nominated receiving user exercises the receipt exception with intended permissions and representative data, including required Arabic and English documents. Illustrative task P17 records its observed result and issue owner, and the CFG2 configuration marker attaches to that evidence. Configuration changes require affected tasks to be repeated. Separate a defect from additional scope; no completed acceptance result is invented.

4. 0:18–0:24

   Make conditions visible • Ready with conditions requires an explicit decision. • Conditions • Decision owner • Unresolved approval permission: decision still required • Defer report? Owner decides • Condition + consequence + owner + revisit

   An optional-report deferral and an unresolved approval permission have different consequences. An authorised decision owner reviews evidence at the still-closed gate. The condition, consequence, approver and revisit requirement stay visible. Ready with conditions requires an explicit business decision and is never silently converted into a green or completed status.

5. 0:24–0:30

   Operate after cutover • Rehearse support and recovery responsibilities. • Support staff · representative incident • Named record + process owner • I17 · affected process + record • Restore application state • Already-sent external record remains • Recovery needs technical + business ownership

   In a support rehearsal, incident I17 moves from support staff to the named process and record owner. The team must exercise administrator access, configuration notes, known issues and the division between supplier, vendor and internal administrator. Restoring an application state does not automatically reverse a record already sent externally or work already completed by a person. Recovery therefore needs technical and business ownership; no actual go-live is claimed.