User journeys

This section narrates seven main user journeys observed during the audit’s Phase-2 walkthroughs. Each journey is presented as a step-by-step description grounded in [OBS], followed by a flow summary and notes on observed friction or risk.

The seven journeys cover the system’s full operating envelope. They are presented in the order a working day surfaces them.

5.1 Journey A — Operator receives a production order and reports completion

Actor: shop-floor operator (role_shopfloor). Frequency: ~120 events per working day across 30 terminals. Observed: 14 times across 4 operators on Days 4–7.

1. Operator logs in to terminal at start of shift (06:00 or 14:00).
2. The “open work” screen lists production orders assigned to the operator’s work centre, sorted by planned start.
3. Operator selects the next order. The screen displays: item code, quantity, routing operation, work instructions (free-text), and any prior-operation results.
4. Operator confirms physical receipt of the prior-operation pallet by scanning a barcode label. The system writes a production_event row with event_type = 'pickup'.
5. Operator works the operation. On completion, operator enters: quantity good, quantity scrap, scrap reason code (from dropdown of 14 codes), elapsed time (auto-captured but editable).
6. Operator submits. System writes a production_event row with event_type = 'completion' and updates production_order_lines.quantity_completed.
7. If quantity good < quantity ordered and this is the final operation, the system prompts: “partial complete — release remaining quantity to next shift?” Operator answers yes/no.
8. Operator either returns to step 2 (next order) or, at shift end, logs out.

Friction observed: scrap reason code dropdown contains four codes that operators report they have never used and three codes that overlap semantically. Operators consistently use one of two codes (“material defect” or “process error”) regardless of true cause. The quality manager has lobbied for a dropdown cleanup since 2022; the request is in the customer’s own backlog. [INT]

Risk surfaced: the editable elapsed-time field is sometimes overwritten when an operator forgets to clock out at break. Standard cost variance reports inherit this noise.

5.2 Journey B — Planner releases the daily production schedule

Actor: production planner (role_planning). Frequency: daily, ~07:30. Observed: 3 times.

1. Planner opens the “production schedule” form. Yesterday’s run of MRP (overnight, see §7) has populated planned_orders with suggested release dates.
2. Planner reviews exceptions: orders flagged by MRP as past-due-start, material-short, or capacity-overloaded. Exceptions are colour-coded.
3. For each exception, planner makes a judgement call: bring forward, push back, split, or override. Override writes a free-text note to planned_orders.notes.
4. Planner selects orders to release. “Release” transitions planned_orders → production_orders and decrements material availability.
5. Released orders are written to the work-centre queues.
6. Planner prints the day’s release summary (a Crystal Report, two pages typically) for the production-floor noticeboard.

Friction observed: the MRP exception logic is opaque to the planner; the rules date from the 2008 deployment and have not been documented. The planner trusts the exception flags but cannot explain why a specific order was flagged when challenged.

Risk surfaced: if MRP runs incorrectly overnight (see §7.3 and §11 risk R-11), the planner’s morning review does not catch it. The exception report appears normal because MRP itself reports “no errors.”

5.3 Journey C — Procurement raises a purchase order

Actor: procurement (role_procurement). Frequency: ~25 POs per week. Observed: 8 PO creation events, 2 PO approval events.

1. Procurement opens the “purchase requisitions” screen. Requisitions originate from two sources: MRP-suggested (overnight) and manual (entered by procurement during the day in response to non-MRP triggers such as consumables).
2. For each requisition, procurement selects a supplier. The system suggests preferred suppliers based on prior PO history and supplier-item linkage. Procurement may override.
3. Procurement reviews price. The system shows the most recent PO price and the contract price (where one is on file). Procurement may negotiate by phone or email and enter a new price.
4. Procurement enters expected delivery date and any line-level notes.
5. Submit. If value ≤ €5 000, the PO is in status released. If > €5 000, status is pending_approval and procurement notifies the period-close lead.
6. The period-close lead, when reviewing, has three actions: approve (→ released), query (→ adds a note, status unchanged), reject (→ rejected).
7. Released POs are emailed to the supplier by the integration broker (PDF attachment, generated by Crystal Reports, SMTP via the customer’s mail server).

Friction observed: the supplier-item linkage table is incomplete. Of approximately 14 000 items, ~2 800 have at least one preferred supplier; the rest fall back to “last supplier used,” which is reconstructed at PO time from a query that takes 3–5 seconds. Procurement experiences this as the screen “thinking.”

Risk surfaced: POs over €25 000 require the managing director’s signature on a printed copy, scanned back into a notes field. The audit trail of MD approval lives in the scanned PDF; there is no structured field. [Sev-3, R-08]

5.4 Journey D — Goods receipt at the warehouse dock

Actor: shop-floor operator (warehouse subset, 3 named users) with role_shopfloor. Frequency: ~30 receipts per working day. Observed: 6 receipts.

1. Carrier arrives. Driver presents delivery note. Warehouse operator opens “goods receipt” screen.
2. Operator enters or scans PO number. System displays expected lines.
3. For each line: operator confirms quantity (or enters actual), scans batch/serial barcode if applicable, optionally enters supplier batch reference from delivery note.
4. If quantity received < quantity ordered: system prompts “back-order?” Operator answers based on driver indication.
5. If item is quality-flagged (held for inspection): system writes status received_held rather than received_available. Stock is in inventory but is not visible to MRP availability.
6. Submit. System writes goods-receipt rows and updates inventory; if all PO lines are complete and quantities match, the three-way match for invoice processing is pre-flagged as clean.
7. Operator prints the receipt confirmation (one-page Crystal Report) and physically attaches it to the goods.

Friction observed: the quality-flag rules are stored in the item master but only ~600 items are flagged, last reviewed in 2019. The quality manager believes some items currently moving through receipt-available should be receipt-held; a review is in the customer’s backlog.

Risk surfaced: if the carrier arrives during the 22:30–02:00 batch window (rare, but happens for some night deliveries), the goods-receipt screen is slow and occasionally times out. Operators have learned to delay GR entry until 03:00 in these cases, leaving stock physically present but not yet system-visible.

5.5 Journey E — Accounting receives and processes a supplier invoice

Actor: accounting (role_accounting). Frequency: ~80 invoices per week, batched. Observed: 12 invoices processed across 2 sessions.

1. Invoice arrives as PDF in shared mailbox. Accounting routes to “supplier invoices to process” folder.
2. Accounting opens “supplier invoice” screen. Selects supplier, enters invoice number, date, total, VAT.
3. Accounting links invoice to PO (one or many). System runs three-way match against PO and GR.
4. If match is clean (within tolerance): invoice is approved by accounting, posted to GL.
5. If match is not clean: system displays variance. Accounting must enter a resolution: accept variance with note, query supplier, escalate to period-close lead.
6. Period-close lead, when escalated, reviews and either approves or rejects.
7. Approved invoices are paid in the weekly payment run (Friday afternoon batch — see §7.4).

Friction observed: the matching tolerance is hard-coded at €50 / 2 % at the database level. There is no UI to adjust it. Accounting believes €100 / 3 % would reduce escalation noise by ~40 % but cannot adjust without IT involvement. [INT]

Risk surfaced: invoices without a PO (“direct expense” invoices) bypass the three-way match entirely and are approved by accounting alone. ~12 % of invoice volume falls into this category. [Sev-2, R-05]

5.6 Journey F — Period-end close

Actor: period-close lead (head of accounting), with sub-roles for accounting team. Frequency: monthly, last working day + 4 working days. Observed: 1 full cycle (month-end of audit week 1).

The close is a 5-day cycle that interleaves human review steps with batch jobs. Summarised:

Day	Activity	Owner	System action
D0 (last working day)	Final invoice entry, GL cut-off announced	Accounting	None
D+1	Inventory revaluation; cost rollup; sub-ledger reconciliation reports	Period-close lead	Batch jobs in nightly window run their extended month-end variant — typically 04:30 close
D+2	Variance review, journal corrections, accruals entry	Accounting + close lead	Manual journal screen; gl_journals_pending table
D+3	Statutory report generation (VAT, intrastat); MD review	Close lead	Crystal Reports; output exported to accountant
D+4	Period flag transition; archive job; lock	Close lead	periods.status = 'closed'

Friction observed: the D+1 month-end batch overrun (02:00 → 04:30) is normalised; nobody notices unless it goes past 06:00. In the audit month, it ran 03:15 — within normal envelope. The close-cycle log shows three months in 2024 when it ran past 06:00, twice triggering an emergency call to the customer’s database consultant. [DOC]

Risk surfaced: if the D+1 month-end batch fails outright (versus overruns), recovery requires a database restore of intermediate tables. The customer’s documented procedure for this scenario is incomplete; the last drill was 2019. [Sev-1, R-01]

5.7 Journey G — Sysadmin handles an integration failure

Actor: internal IT (role_sysadmin), 1 named person. Frequency: ~2–4 events per month. Observed: 1 event (an EDI partner #2 SFTP failure on Day 9).

1. Integration broker fails to deliver the nightly EDI batch. Failure is logged to a file (broker.log) and an email is sent to it@customer.
2. Sysadmin sees email at 06:30 morning check.
3. Sysadmin opens the broker log, identifies the failure cause (SFTP authentication, partner-side IP change, schema validation failure, etc.).
4. Sysadmin remediates: typically, this means rerunning the batch with a corrected configuration after coordinating with the EDI partner.
5. Sysadmin restarts the broker service. Confirms delivery success.
6. Sysadmin logs the event in the customer’s own incident log (a SharePoint list).

Friction observed: the broker log is verbose (~80 MB per day, retained 14 days), uses three different log formats from the three third-party libraries it imports, and is not searchable beyond grep. Sysadmin has memorised about a dozen grep patterns. [OBS]

Risk surfaced: the broker has one person who understands its internals. That person retires in 2027. Documentation of the broker’s failure modes lives in his head. [Sev-1, R-02]

5.8 Diagram summary

A flow-diagram set for each of the seven journeys is held in Appendix A (see §14). The narrative descriptions in this section are the canonical source; the diagrams are reading aids.

Two cross-journey patterns are visible:

• The 06:00 morning check is load-bearing. Sysadmin (journey G), production planner (journey B), and accounting (journey E) all start their day with a system-state inspection. If any of these inspections is skipped or rushed, downstream consequences propagate through the day.
• Crystal Reports is the system’s “print layer”. All seven journeys produce a paper artifact at least once. Replacing the Crystal Reports infrastructure (mentioned in §12 as a modernisation candidate) touches every journey.