§14 · Appendices — Sample audit

Appendix A — Journey flow diagrams

The seven user journeys in §5 are summarised here as compact flow diagrams. The narrative descriptions in §5 are the canonical source; these are reading aids.

A.1 — Operator completion (journey A)

  Login → Open work → Select PO → Scan pickup → Work
    → Enter qty good / scrap / reason → Submit
    → if partial: prompt release-remaining? → next order

A.2 — Planner release (journey B)

  Open schedule → Review MRP exceptions (colour-coded)
    → Bring-forward / push-back / split / override
    → Select to release → Release → Print summary

A.3 — Procurement PO (journey C)

  Open requisitions → Select supplier (or override) → Review price
    → Enter delivery date → Submit
    → if ≤ €5k: released; if > €5k: pending_approval → close-lead review
    → if > €25k: scan MD-signed PDF into notes field
    → Released PO emailed by broker

A.4 — Goods receipt (journey D)

  Carrier arrives → Open GR screen → Scan PO → Confirm quantities
    → Scan batch refs → if quality-flagged: status received_held
    → Submit → Print receipt slip → Attach to goods

A.5 — Supplier invoice (journey E)

  Invoice arrives PDF → Open SI screen → Enter header + total
    → Link to PO(s) → System runs 3-way match
    → if clean: approve + post GL
    → if variance: enter resolution OR escalate to close-lead
    → close-lead approves or rejects → Pay run Fri 14:00

A.6 — Period close (journey F)

  D0: cut-off announced
  D+1: inventory revaluation + cost rollup + sub-ledger recon (batch)
  D+2: variance review + journal corrections + accruals (manual)
  D+3: statutory reports + MD review
  D+4: period.status = closed; archive job; lock

A.7 — Integration failure (journey G)

  Broker fails → log + email IT
    → IT reads broker.log (grep)
    → Identify failure → Remediate (config / coord with partner)
    → Restart broker service → Confirm delivery
    → Log incident in SharePoint

Appendix B — Audit method, in detail

Phase-by-phase log of the audit’s own activity, for reproducibility.

B.1 Phase 1 — Inventory (3 days on-site)

Day 1:

Tour of the server room with IT
Catalogue of physical hosts: APP01, DB01, DB02 (configurations, age, support status)
Initial database connection with read-only credentials, baseline catalogue queries

Day 2:

Schema dump and table-by-table notes
SSIS package enumeration
Crystal Reports .rpt file inventory from network share
Scheduled-job inventory (SQL Server Agent + Windows Task Scheduler on APP01)

Day 3:

Integration broker source code review (in customer’s internal git)
Configuration file capture (broker.config.xml, MES-Plus .ini files, SSIS connection managers)
Named-user catalogue from AD + application screens

B.2 Phase 2 — Observation (5 days on-site)

Day 4: shadowed shop-floor operator across one shift (06:00–14:00); shadowed production planner during morning release.

Day 5: shadowed procurement; shadowed goods receipt at warehouse dock.

Day 6: shadowed accounting through supplier invoice batch; shadowed Crystal Reports daily-use patterns.

Day 7: full normal-day observation; period-close cycle Day 1 (D+1 of audit month-end).

Day 8: period-close cycle Day 2 (D+2 manual journal entries); recorded one integration failure event (EDI partner #2 SFTP auth).

B.3 Phase 3 — Targeted inspection (6 days on-site + 4 days off-site)

Days 9–14 on-site:

Trace data flows end-to-end for the four canonical processes (§7)
Inspect integration broker behaviour: deliberately trigger one retry, observe logging
Inspect backup state on NAS and review last-tape provenance
Run integrity queries from §6.5
Interview the broker maintainer for 4 hours (recorded with permission)

Days 15–18 off-site:

Analyse the integrity-query results
Cross-reference observed behaviour with the customer’s incident log
Draft the risk register (§11)

B.4 Phase 4 — Synthesis and write-up (2 days off-site)

Days 19–20: assemble document, produce diagrams, draft modernisation tiering, review with the customer.

B.5 Total elapsed time

18 working days including 14 on-site, 6 off-site. The on-site days were spread across three weeks to allow the period-close observation to land naturally.

Appendix C — Customer-specific database objects

Inventory of database objects authored by the customer (not vendor-shipped). This is the highest-attention area for any future modernisation; vendor objects can be inferred from product documentation, customer objects cannot.

C.1 Customer-authored tables (40)

Grouped by purpose:

Integration / broker support (8): broker_queue, broker_log, broker_config, edi_envelope_in, edi_envelope_out, customs_declaration, bank_payment_batch, bank_statement_unmatched
Reporting cache (5): rpt_inventory_aging_cache, rpt_oee_cache, rpt_ar_aging_cache, rpt_supplier_summary_cache, rpt_md_weekly_cache
Process extension (12): tables added to support customer-specific process variations — quality holds, hold-release approvals, scrap-reason customisation, PO-approval audit trail, etc.
Master-data extension (8): additional attribute tables for items, customers, suppliers
Audit and logging (4): supplemental audit tables beyond the vendor’s user_activity_log
Historical / archive (3): the 2018 schema-version copy plus archive holdovers

C.2 Customer-authored stored procedures (~120)

Approximate distribution:

~30 around integration broker behaviour (queue management, retry logic, format conversion)
~25 for nightly batches the vendor’s batch did not cover (BI export staging, EDI envelope assembly)
~20 for reporting (the rpt_*_cache table populators)
~15 for period-close support (sp_mrp_rollback included)
~15 for master-data integrity (the queries in §6.5 are partial; the customer maintains its own equivalents)
~15 ad-hoc utilities, one-off corrections that survived in the database

C.3 Customer-authored SSIS packages

Catalogued in §8.3.

C.4 Customer-authored Crystal Reports

Approximately 110 of the ~180 total reports are customer-authored. The remaining ~70 are vendor originals (60+ of which are unused in current operations — see §9.2).

C.5 What is not in this appendix

Database objects authored by the unidentified consultant during 2012–2019 — some of which are now indistinguishable from customer-authored objects without git blame-equivalent tooling
Customisations to the vendor binary itself, which are presumed absent but cannot be confirmed without source-access

Appendix D — Document conventions

Tagged claims: every factual claim in §3–§11 carries one or more evidence tags from §2.4. Untagged statements are interpretive or organisational, not factual assertions.
Numbers: rounded to two significant figures unless precision is material. “~120 production orders” means 100–140; “exactly 280 tables” means a counted census.
Section references: §N.M refers to a numbered section; R-NN refers to a risk-register row in §11.
Severity: Sev-1 / Sev-2 / Sev-3 as defined in §11.1.
Modernisation tier: Patch / Mend / Retrofit / Restructure as defined in §12.1.

This document is set in proportional serif body (Source Serif) and sans-serif headings (Inter), to mirror the visual register of the audit’s intended reading context — operations leadership, not engineering. Tables are presented in monospace-aligned columns where alignment carries meaning.

Appendix E — Acknowledgements

Twenty-eight named individuals at the customer cooperated with this audit. They are not listed here. The audit’s authors thank them for their candour, particularly in the interview portions, where the unflinching answer was often more useful than the polished one.