Specimen: warehouse receiving to dispatch. As-is, as written. Exported 2026-10-08. Handoff Register BPMN 1.0. Task types: userTask = keep, serviceTask = a hand-over candidate (a marker, no implementation), task = unclear. The process is a model, not executable. Specimen: warehouse receiving to dispatch. As-is, as written. Exported 2026-10-08. Handoff Register BPMN 1.0. Task types: userTask = keep, serviceTask = a hand-over candidate (a marker, no implementation), task = unclear. The process is a model, not executable. Steps: 32. Lanes: 12 (Inbound clerk 2, Receiver 3, Finance manager 1, Finance 1, Customer service 1, Warehouse lead 1, Picker 1, Packer 1, Dispatch 1, Logistics manager 1, Dispatch lead 1, Owner not named 18). Re-keying steps: 8. Hand over: 20. Keep: 10. Unclear: 2. Systems touched: WMS, Email, Shared drive, Paper or clipboard, SAP, PDF or document, Phone, Spreadsheet, Printer, Scanner, Scale, DHL, StarTrack or AusPost, Salesforce, Carrier portal. Gateways: 6. StartEvent_1 Task_s1 Task_s7 Task_s2 Task_s4 Task_s5 Task_s9 Task_s13 Gateway_s13 Gateway_s13_merge Task_s14 Task_s18 Task_s20 Task_s22 Task_s24 Task_s27 Task_s32 EndEvent_1 Task_s3 Gateway_s3 Gateway_s3_merge Task_s6 Task_s8 Task_s10 Task_s11 Task_s12 Task_s15 Task_s16 Gateway_s16 Gateway_s16_merge Task_s17 Gateway_s17 Gateway_s17_merge Task_s19 Task_s21 Gateway_s21 Gateway_s21_merge Task_s23 Task_s25 Task_s26 Task_s28 Task_s29 Task_s30 Gateway_s30 Gateway_s30_merge Task_s31 Flow_1 Step 1, as written: Every morning at 8 the inbound clerk downloads the supplier ASNs from the email inbox and keys them into the WMS as expected receipts. Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: inbound clerk. Systems: WMS, Email. Re-keyed data: yes. What you lose sight of if it is handed over: The receiver comparing what the supplier says is coming against what was ordered, before the truck arrives. Mismatches are seen here, on the way in. First move: Log every expected receipt created from a notice with its PO and line quantities, and flag a notice whose quantities exceed the open PO. Register findings: none on this step.the step is a person acting as a cable between two systems; nothing in it is judgementThe receiver comparing what the supplier says is coming against what was ordered, before the truck arrives. Mismatches are seen here, on the way in.Log every expected receipt created from a notice with its PO and line quantities, and flag a notice whose quantities exceed the open PO.Flow_1Flow_2 Step 2, as written: When a truck arrives, the receiver counts the pallets and checks the quantity against the delivery note. Kind: decision. Verdict: hand over (the comparison is a rule; the count on the dock stays with the receiver until a scan replaces it). Owner: receiver. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The pause when a count is close but not exact. The receiver decides whether 99 of 100 is a short delivery or a miscount. First move: Log every quantity checked against its document with the variance, and route only variances outside the tolerance to a person. Register findings: none on this step.the comparison is a rule; the count on the dock stays with the receiver until a scan replaces itThe pause when a count is close but not exact. The receiver decides whether 99 of 100 is a short delivery or a miscount.Log every quantity checked against its document with the variance, and route only variances outside the tolerance to a person.Flow_2Flow_3 Step 3, as written: If the quantity does not match the delivery note, raise a discrepancy with the supplier by email and hold the pallets. Kind: exception. Verdict: keep (an exception that reaches a supplier). Owner: not named. Systems: Email. Re-keyed data: no. What a person keeps: The judgement about who is at fault and what to do about it. A discrepancy is the start of a supplier conversation. First move: Log every discrepancy with the document, the variance and the disposition decided, and let the layer raise the claim draft for a person to send. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Exceptions with no owner (ISO 9001:2015 5.3, ISO 9001:2015 8.7, ISO 9001:2015 10.2, ISO/IEC 42001:2023 A.3.3, ISO/IEC 42001:2023 A.8.4).an exception that reaches a supplierThe judgement about who is at fault and what to do about it. A discrepancy is the start of a supplier conversation.Log every discrepancy with the document, the variance and the disposition decided, and let the layer raise the claim draft for a person to send.Flow_4Flow_5 Stated in step 3: if the quantity does not match the delivery noteFlow_3Flow_4Flow_6 Flow_5Flow_6Flow_7 Step 4, as written: photographs any damaged pallets and quarantines them Kind: exception. Verdict: keep (an exception that ends with a supplier). Owner: Receiver. Systems: WMS, Shared drive. Re-keyed data: no. What a person keeps: The photograph and the refusal. Damage is dealt with at the dock by the person who sees it. First move: Log every damage event with photographs, the carrier and the disposition, and let the layer raise the claim from the log. Register findings: none on this step.an exception that ends with a supplierThe photograph and the refusal. Damage is dealt with at the dock by the person who sees it.Log every damage event with photographs, the carrier and the disposition, and let the layer raise the claim from the log.Flow_7Flow_8 Step 5, as written: signs the driver's delivery note and files the paper copy Kind: approval. Verdict: keep (a sign-off, a person puts their name to it). Owner: Receiver. Systems: Paper or clipboard. Re-keyed data: no. What a person keeps: A signature on a delivery note is the customer's acceptance. It is a legal record, and a person gives it. First move: Capture the signature on a device with the time and location, and log any delivery signed with a note or exception for follow-up. Register findings: none on this step.a sign-off, a person puts their name to itCapture the signature on a device with the time and location, and log any delivery signed with a note or exception for follow-up.Flow_8Flow_9 Step 6, as written: Once the WMS shows the receipt, post the goods receipt in SAP by hand. Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: not named. Systems: SAP, WMS. Re-keyed data: yes. What you lose sight of if it is handed over: The comparison between the received quantity and the ordered quantity at the moment of posting. The person posting a receipt of 96 against a PO for 100 asks why; a feed posts it. First move: Log every receipt posted with the WMS reference and hold any receipt where the quantity differs from the PO line by more than the tolerance. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Re-keying into a system of record with no check after it (ISO 9001:2015 8.5.1, ISO 9001:2015 8.5.2, ISO 9001:2015 8.6, ISO 9001:2015 9.1.1, ISO/IEC 42001:2023 A.7.4).the step is a person acting as a cable between two systems; nothing in it is judgementThe comparison between the received quantity and the ordered quantity at the moment of posting. The person posting a receipt of 96 against a PO for 100 asks why; a feed posts it.Log every receipt posted with the WMS reference and hold any receipt where the quantity differs from the PO line by more than the tolerance.Flow_9Flow_10 Step 7, as written: checks the expiry dates and puts the oldest batch first Kind: decision. Verdict: hand over (a rule a system already holds). Owner: Inbound clerk. Systems: WMS. Re-keyed data: no. What you lose sight of if it is handed over: The eye that notices a short-dated pallet on its way to a customer who will refuse it. FEFO picks the oldest batch; it does not know the customer's minimum remaining life unless that is recorded. First move: Log every pick with the batch date and remaining life, and route any pick under the customer's minimum remaining life to a person. Register findings: none on this step.a rule a system already holdsThe eye that notices a short-dated pallet on its way to a customer who will refuse it. FEFO picks the oldest batch; it does not know the customer's minimum remaining life unless that is recorded.Log every pick with the batch date and remaining life, and route any pick under the customer's minimum remaining life to a person.Flow_10Flow_11 Step 8, as written: Match the supplier invoice to the PO and the goods receipt before it is paid. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The habit on top of the tolerance. The system holds a tolerance; the person matching still waves through a 2 percent freight variance and stops a 20 percent one, and that habit is a control nobody wrote down. First move: Log every match with the three quantities and the price variance, and route only the failures to a person with the reason attached. Register findings: none on this step.a rule a system already holdsThe habit on top of the tolerance. The system holds a tolerance; the person matching still waves through a 2 percent freight variance and stops a 20 percent one, and that habit is a control nobody wrote down.Log every match with the three quantities and the price variance, and route only the failures to a person with the reason attached.Flow_11Flow_12 Step 9, as written: Any invoice over 10,000 has to be approved by the finance manager before payment. Kind: approval. Verdict: keep (a sign-off, a person puts their name to it). Owner: finance manager. Systems: none named. Re-keyed data: no. What a person keeps: Approving payment is the last control before money leaves. Where the invoice matched the PO and receipt, the match is the approval; where it did not, a person decides. First move: Let matched invoices under the threshold approve on the match, and log every manual approval with the mismatch reason and the approver. Register findings: none on this step.a sign-off, a person puts their name to itLet matched invoices under the threshold approve on the match, and log every manual approval with the mismatch reason and the approver.Flow_12Flow_13 Step 10, as written: Type the orders from the shared inbox into SAP (most customers still email a PDF). Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: not named. Systems: SAP, Email, PDF or document. Re-keyed data: yes. What you lose sight of if it is handed over: The person who notices the customer has ordered the wrong part number for the machine they bought last year. That knowledge is in their head and it is applied while they type. First move: Log the source message id against every order created and hold any order whose line items do not match a product the customer has bought before. Register findings: none on this step.the step is a person acting as a cable between two systems; nothing in it is judgementThe person who notices the customer has ordered the wrong part number for the machine they bought last year. That knowledge is in their head and it is applied while they type.Log the source message id against every order created and hold any order whose line items do not match a product the customer has bought before.Flow_13Flow_14 Step 11, as written: check the customer PO number is on the order before processing it. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: Little. A reference is present or absent, and it matches a known format or it does not. First move: Log every order with the reference check result, and route orders with no reference to the exception step rather than holding them silently. Register findings: none on this step.a rule a system already holdsLittle. A reference is present or absent, and it matches a known format or it does not.Log every order with the reference check result, and route orders with no reference to the exception step rather than holding them silently.Flow_14Flow_15 Step 12, as written: Check the customer is within their credit limit before releasing the order. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The phone call to the customer that clears the hold. Credit control is a rule with a relationship attached; keep the relationship, hand over the rule. First move: Log every credit decision with the balance, limit and order value, and route only orders over the limit to a person. Register findings: none on this step.a rule a system already holdsThe phone call to the customer that clears the hold. Credit control is a rule with a relationship attached; keep the relationship, hand over the rule.Log every credit decision with the balance, limit and order value, and route only orders over the limit to a person.Flow_15Flow_16 Step 13, as written: If the order is on credit hold, finance releases it or calls the customer. Kind: approval. Verdict: keep (a sign-off, a person puts their name to it). Owner: finance. Systems: Phone. Re-keyed data: no. What a person keeps: Releasing an order on credit hold is a decision to extend credit. Somebody with authority for that risk signs it. First move: Name who can release and up to what exposure, and log every release with the balance, the order value and the reason. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Approvals with no threshold named (ISO 9001:2015 5.3, ISO 9001:2015 8.1, ISO 9001:2015 8.2.3, ISO 9001:2015 8.6, ISO/IEC 42001:2023 A.3.2); Steps that reach a customer or supplier with no system named (ISO 9001:2015 8.2.1, ISO 9001:2015 8.4.1, ISO 9001:2015 8.4.3, ISO 9001:2015 8.5.2, ISO 9001:2015 7.4, ISO/IEC 42001:2023 A.10.3, ISO/IEC 42001:2023 A.10.4).a sign-off, a person puts their name to itName who can release and up to what exposure, and log every release with the balance, the order value and the reason.Flow_17Flow_18 Stated in step 13: if the order is on credit holdFlow_16Flow_17Flow_19 Flow_18Flow_19Flow_20 Step 14, as written: applies the customer's contract pricing to the order lines Kind: decision. Verdict: hand over (a rule a system already holds). Owner: Customer service. Systems: SAP, Spreadsheet. Re-keyed data: no. What you lose sight of if it is handed over: The goodwill. A person applying a discount sometimes applies the one the customer thinks they were promised. First move: Log every price applied with the contract or rule that set it, and record any manual price with who set it and why. Register findings: none on this step.a rule a system already holdsThe goodwill. A person applying a discount sometimes applies the one the customer thinks they were promised.Log every price applied with the contract or rule that set it, and record any manual price with who set it and why.Flow_20Flow_21 Step 15, as written: Confirm we have the stock before confirming the order to the customer. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The knowledge that the stock on the screen is in a damaged pallet at the back. The person checking availability knows what the system does not. First move: Log every availability check with the quantity seen and the decision made, and flag any location whose physical count has disagreed with the system in the last cycle. Register findings: none on this step.a rule a system already holdsThe knowledge that the stock on the screen is in a damaged pallet at the back. The person checking availability knows what the system does not.Log every availability check with the quantity seen and the decision made, and flag any location whose physical count has disagreed with the system in the last cycle.Flow_21Flow_22 Step 16, as written: Decide whether to part-ship the order or wait if a line is on backorder. Kind: decision. Verdict: keep (judgement with no written rule). Owner: not named. Systems: none named. Re-keyed data: no. What a person keeps: The customer preference the CRM never captured. Some customers would rather wait; the person deciding remembers which. First move: Record the split preference on the customer account and log every split decision against it, so the judgement shrinks to the customers with no preference recorded. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Decisions with no written rule (ISO 9001:2015 7.1.6, ISO 9001:2015 7.5.1, ISO 9001:2015 8.1, ISO 9001:2015 8.5.1, ISO/IEC 42001:2023 A.9.4, ISO/IEC 42001:2023 A.6.2.2).judgement with no written ruleThe customer preference the CRM never captured. Some customers would rather wait; the person deciding remembers which.Record the split preference on the customer account and log every split decision against it, so the judgement shrinks to the customers with no preference recorded.Flow_23Flow_24 Stated in step 16: if a line is on backorderFlow_22Flow_23Flow_25 Flow_24Flow_25Flow_26 Step 17, as written: Let the customer know by email if their order is going on backorder. Kind: exception. Verdict: keep (an exception that reaches a customer). Owner: not named. Systems: Email. Re-keyed data: no. What a person keeps: The wording and the offer. Telling a customer about a delay is where an alternative is offered. First move: Log every delay notification with the order, the new date and the customer's response, and let the layer draft the message for a person to approve. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Exceptions with no owner (ISO 9001:2015 5.3, ISO 9001:2015 8.7, ISO 9001:2015 10.2, ISO/IEC 42001:2023 A.3.3, ISO/IEC 42001:2023 A.8.4).an exception that reaches a customerThe wording and the offer. Telling a customer about a delay is where an alternative is offered.Log every delay notification with the order, the new date and the customer's response, and let the layer draft the message for a person to approve.Flow_27Flow_28 Stated in step 17: if their order is going on backorderFlow_26Flow_27Flow_29 Flow_28Flow_29Flow_30 Step 18, as written: decides which orders get picked first each morning Kind: decision. Verdict: keep (judgement with no written rule). Owner: Warehouse lead. Systems: Printer. Re-keyed data: no. What a person keeps: The trade-off. A person sequencing the day weighs the promised dates against who shouted loudest and which truck is leaving first. First move: Write the priority rule in order of precedence and log every reordering against it, so the exceptions become visible and the rule improves. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Decisions with no written rule (ISO 9001:2015 7.1.6, ISO 9001:2015 7.5.1, ISO 9001:2015 8.1, ISO 9001:2015 8.5.1, ISO/IEC 42001:2023 A.9.4, ISO/IEC 42001:2023 A.6.2.2).judgement with no written ruleThe trade-off. A person sequencing the day weighs the promised dates against who shouted loudest and which truck is leaving first.Write the priority rule in order of precedence and log every reordering against it, so the exceptions become visible and the rule improves.Flow_30Flow_31 Step 19, as written: Assign the morning's picks to the pickers based on who is in. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The supervisor's knowledge of who is having a bad day. Work assignment is a balancing rule with a human factor. First move: Log every assignment with the rule and the load per person, and record overrides so the rule learns skills and zones. Register findings: none on this step.a rule a system already holdsThe supervisor's knowledge of who is having a bad day. Work assignment is a balancing rule with a human factor.Log every assignment with the rule and the load per person, and record overrides so the rule learns skills and zones.Flow_31Flow_32 Step 20, as written: scans each item and checks the barcode matches the pick line Kind: decision. Verdict: hand over (a rule a system already holds). Owner: Picker. Systems: Scanner. Re-keyed data: no. What you lose sight of if it is handed over: The eye that notices the part number matches but the revision does not. First move: Log every verification with the scanned value and the expected value, and stop the step on any mismatch rather than warning. Register findings: none on this step.a rule a system already holdsThe eye that notices the part number matches but the revision does not.Log every verification with the scanned value and the expected value, and stop the step on any mismatch rather than warning.Flow_32Flow_33 Step 21, as written: If the packer finds a wrong pick, send it back and re-pick the line. Kind: exception. Verdict: hand over (an internal retry or correction with a fixed remedy). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The packer noticing the picker's mistake. That check is where most wrong picks are caught, and it is a comparison. First move: Log every wrong pick with the picker, the location and the product pair, and use the log to fix slotting where the same pair keeps colliding. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Exceptions with no owner (ISO 9001:2015 5.3, ISO 9001:2015 8.7, ISO 9001:2015 10.2, ISO/IEC 42001:2023 A.3.3, ISO/IEC 42001:2023 A.8.4).an internal retry or correction with a fixed remedyThe packer noticing the picker's mistake. That check is where most wrong picks are caught, and it is a comparison.Log every wrong pick with the picker, the location and the product pair, and use the log to fix slotting where the same pair keeps colliding.Flow_34Flow_35 Stated in step 21: if the packer finds a wrong pickFlow_33Flow_34Flow_36 Flow_35Flow_36Flow_37 Step 22, as written: weighs each carton and types the weight into the WMS Kind: re-keying. Verdict: hand over (the reading can come off the scale directly; lifting the carton onto it stays physical). Owner: Packer. Systems: WMS, Scale. Re-keyed data: yes. What you lose sight of if it is handed over: Not much, but the person reads the scale and the carton at the same time and spots a carton that is wrong for its weight. First move: Log every weight and dimension captured from the scale with the carton id, and flag any carton whose weight is outside the range for its contents. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Re-keying into a system of record with no check after it (ISO 9001:2015 8.5.1, ISO 9001:2015 8.5.2, ISO 9001:2015 8.6, ISO 9001:2015 9.1.1, ISO/IEC 42001:2023 A.7.4).the reading can come off the scale directly; lifting the carton onto it stays physicalNot much, but the person reads the scale and the carton at the same time and spots a carton that is wrong for its weight.Log every weight and dimension captured from the scale with the carton id, and flag any carton whose weight is outside the range for its contents.Flow_37Flow_38 Step 23, as written: Choose the carton size for each order from the size chart. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The packer's feel for a fragile item. Cartonisation is a rule; the extra bubble wrap is not. First move: Log every carton chosen with the cube rule and the products inside, and record fragility on the product so the packer's judgement becomes data. Register findings: none on this step.a rule a system already holdsThe packer's feel for a fragile item. Cartonisation is a rule; the extra bubble wrap is not.Log every carton chosen with the cube rule and the products inside, and record fragility on the product so the packer's judgement becomes data.Flow_38Flow_39 Step 24, as written: Dispatch re-keys every order into the DHL and StarTrack portals to book the delivery. Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: Dispatch. Systems: DHL, StarTrack or AusPost. Re-keyed data: yes. What you lose sight of if it is handed over: The moment a person looks at the address, weight and service level together before the label exists. A mistyped postcode and a wrong service both get caught here today, by eye. First move: Log every consignment the layer creates with the order number, the address it used and the service chosen, and flag any address the carrier could not validate before the label prints. Register findings: none on this step.the step is a person acting as a cable between two systems; nothing in it is judgementThe moment a person looks at the address, weight and service level together before the label exists. A mistyped postcode and a wrong service both get caught here today, by eye.Log every consignment the layer creates with the order number, the address it used and the service chosen, and flag any address the carrier could not validate before the label prints.Flow_39Flow_40 Step 25, as written: Copy the tracking number from the carrier portal back into Salesforce for the customer. Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: not named. Systems: Salesforce, Carrier portal. Re-keyed data: yes. What you lose sight of if it is handed over: Nothing worth keeping. The tracking number is generated by the carrier and copied verbatim; no judgement is applied. First move: Log each tracking number written back with the order it was attached to and the time, so a customer query can be answered from the log. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Re-keying into a system of record with no check after it (ISO 9001:2015 8.5.1, ISO 9001:2015 8.5.2, ISO 9001:2015 8.6, ISO 9001:2015 9.1.1, ISO/IEC 42001:2023 A.7.4).the step is a person acting as a cable between two systems; nothing in it is judgementNothing worth keeping. The tracking number is generated by the carrier and copied verbatim; no judgement is applied.Log each tracking number written back with the order it was attached to and the time, so a customer query can be answered from the log.Flow_40Flow_41 Step 26, as written: Decide whether the order goes express or standard from the promised date. Kind: decision. Verdict: hand over (a rule a system already holds). Owner: not named. Systems: none named. Re-keyed data: no. What you lose sight of if it is handed over: The bending of the rule for a good customer. "Send it express, it is for the account we are trying to win." That is a decision worth keeping visible, not one worth keeping manual. First move: Log every service chosen with the rule that chose it, and record any override with who made it and why. Register findings: none on this step.a rule a system already holdsThe bending of the rule for a good customer. "Send it express, it is for the account we are trying to win." That is a decision worth keeping visible, not one worth keeping manual.Log every service chosen with the rule that chose it, and record any override with who made it and why.Flow_41Flow_42 Step 27, as written: Logistics manager approves any air freight over 2,000. Kind: approval. Verdict: keep (a sign-off, a person puts their name to it). Owner: Logistics manager. Systems: none named. Re-keyed data: no. What a person keeps: Premium freight is money spent on a promise. The approval attaches a name to the cost. First move: Name the threshold and approver, and log every expedite with the cost, the order and the reason, so the reasons can be counted. Register findings: none on this step.a sign-off, a person puts their name to itName the threshold and approver, and log every expedite with the cost, the order and the reason, so the reasons can be counted.Flow_42Flow_43 Step 28, as written: Sort out the Friday stuff for the big account. Kind: unclear. Verdict: unclear. Owner: not named. Systems: none named. Re-keyed data: no. Unclear: What triggers this step? What rule decides it? Which system holds the result? Who is accountable for it? Register findings (the clauses each finding points to as evidence, not a statement of conformity): Steps nobody could classify from what was written (ISO 9001:2015 4.4, ISO 9001:2015 7.5.1, ISO 9001:2015 7.5.2, ISO 9001:2015 7.1.6, ISO/IEC 42001:2023 A.6.2.2).Flow_43Flow_44 Step 29, as written: Every afternoon, check the DHL portal for each consignment and copy the status into the tracking spreadsheet. Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: not named. Systems: Spreadsheet, DHL. Re-keyed data: yes. What you lose sight of if it is handed over: The reading of the exception text on the portal. The status code is copied; the note that says "customer refused" is read. First move: Log every status pulled with the source and time, and route any status with an exception note to a person. Register findings: none on this step.the step is a person acting as a cable between two systems; nothing in it is judgementThe reading of the exception text on the portal. The status code is copied; the note that says "customer refused" is read.Log every status pulled with the source and time, and route any status with an exception note to a person.Flow_44Flow_45 Step 30, as written: If a delivery fails, contact the customer and rebook it with the carrier. Kind: exception. Verdict: keep (an exception that reaches a customer). Owner: not named. Systems: none named. Re-keyed data: no. What a person keeps: The customer conversation about when they will be in. First move: Log every failed delivery with the carrier reason and the rebooking outcome, and let the layer send the standard rebooking message for the customer to choose a slot. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Exceptions with no owner (ISO 9001:2015 5.3, ISO 9001:2015 8.7, ISO 9001:2015 10.2, ISO/IEC 42001:2023 A.3.3, ISO/IEC 42001:2023 A.8.4); Steps that reach a customer or supplier with no system named (ISO 9001:2015 8.2.1, ISO 9001:2015 8.4.1, ISO 9001:2015 8.4.3, ISO 9001:2015 8.5.2, ISO 9001:2015 7.4, ISO/IEC 42001:2023 A.10.3, ISO/IEC 42001:2023 A.10.4).an exception that reaches a customerThe customer conversation about when they will be in.Log every failed delivery with the carrier reason and the rebooking outcome, and let the layer send the standard rebooking message for the customer to choose a slot.Flow_46Flow_47 Stated in step 30: if a delivery failsFlow_45Flow_46Flow_48 Flow_47Flow_48Flow_49 Step 31, as written: Keep an eye on things in the yard when it gets busy. Kind: unclear. Verdict: unclear. Owner: not named. Systems: none named. Re-keyed data: no. Unclear: What triggers this step? What rule decides it? Which system holds the result? Who is accountable for it? Register findings (the clauses each finding points to as evidence, not a statement of conformity): Steps nobody could classify from what was written (ISO 9001:2015 4.4, ISO 9001:2015 7.5.1, ISO 9001:2015 7.5.2, ISO 9001:2015 7.1.6, ISO/IEC 42001:2023 A.6.2.2).Flow_49Flow_50 Step 32, as written: At 5 pm the dispatch lead attaches the daily dispatch report to an email and sends it to the ops managers. Kind: re-keying. Verdict: hand over (the step is a person acting as a cable between two systems; nothing in it is judgement). Owner: dispatch lead. Systems: Email. Re-keyed data: yes. What you lose sight of if it is handed over: The sentence at the top of the email. The person attaching the report writes "note the drop in line 3", and that sentence is the only analysis anyone reads. First move: Log every distribution with the report version and recipients, and replace the attachment with a link to the live view where the reader can see when it last refreshed. Register findings (the clauses each finding points to as evidence, not a statement of conformity): Hand-overs at the end of the process with nothing after them (ISO/IEC 42001:2023 A.9.2, ISO/IEC 42001:2023 A.9.3, ISO/IEC 42001:2023 A.6.2.5, ISO/IEC 42001:2023 A.6.2.6, ISO/IEC 42001:2023 A.6.2.8, ISO/IEC 42001:2023 A.5.4, ISO 9001:2015 8.5.1).the step is a person acting as a cable between two systems; nothing in it is judgementThe sentence at the top of the email. The person attaching the report writes "note the drop in line 3", and that sentence is the only analysis anyone reads.Log every distribution with the report version and recipients, and replace the attachment with a link to the live view where the reader can see when it last refreshed.Flow_50Flow_51 Flow_51 the quantity does not match the delivery note the order is on credit hold a line is on backorder their order is going on backorder the packer finds a wrong pick a delivery fails