Synthetic demo. A proposed approach for a fictional deployment.
Implementation brief
Request to order. Assumptions and rules need validation with real process owners before use.
Pilot objective
Find out whether occasional and frequent requesters can complete the same controlled purchase-request process, and whether reviewers receive enough information to decide without repeated follow-up.
Start with one bounded indirect category, such as an IT or facilities service, one representative catalogue and non-catalogue path, and both requester types. Choose pilot scope and success targets with the sponsor after mapping actual volumes, markets/entities, systems, and baseline performance. A short discovery/pilot phase does not promise completion of a larger transformation.
Ownership
| Role | Owns |
|---|---|
| Sponsor | Scope, funding, unresolved priorities, and stage decisions |
| Procurement process owner | Common policy, approval controls, and exception definition |
| Local finance or budget owner | Cost-centre validity, approval responsibilities, and financial measures |
| IT and integration owner | System boundaries, identities, data transfer, failures, and reconciliation |
| Supplier-data owner | Supplier record quality, onboarding, and lifecycle |
| Project manager | Requirements, dependencies, decisions, pilot coordination, and communication |
| Key users | Real-task feedback, local training, and adoption issues |
Questions to resolve first
- Who owns the supplier record and who can approve a new supplier?
- Which system owns requisition IDs, PO numbers, and approval history?
- Which fields and controls are global, and which variations are permitted by market, entity, category, or channel?
- Which catalogue and non-catalogue buying channels exist, and how do requesters know which one applies?
- What creates a financial commitment, and how are urgent or retrospective cases recorded?
- How is receipt confirmed for goods versus services?
- What happens when an ERP rejects a handoff or cannot be reached?
- How do rejected or changed requests return to the requester?
- Which purchases are eligible for the pilot, and which need another process?
Proposed stages
| Stage | Work | Evidence required to advance |
|---|---|---|
| Days 1 to 30: understand | Map stakeholders, actual tasks, current systems, data ownership, variations, and baseline | Owners agree scope, controls, exception handling, and definitions |
| Days 31 to 60: design and pilot | Configure one route, rehearse failure cases, train key users, collect feedback | Pilot users complete representative tasks; owners review failures |
| Days 61 to 90: assess | Compare with baseline, review exceptions and friction, resolve dependencies | Sponsor decides whether to expand, revise, or stop |
Train before, during, and after introduction: explain why the process changes, practise real tasks at launch, then review actual friction. Support fifty requesters through local key users and consistent guidance.
Measures
| Measure | Definition | Interpretation |
|---|---|---|
| First-pass completeness | Submitted requests meeting required data rules, divided by all submitted requests | Intake clarity and data quality |
| Approval cycle time | Time from valid submission to final required approval | Report median and slower cases; separate exception cases |
| Retrospective request rate | Requests reporting commitment before approval, divided by all submitted requests | Timing and control issue; acknowledgment does not remove the exception |
| Task completion | Users completing an assigned request task, divided by users starting that task | Usability for guided and quick modes |
| Rework rate | Requests returned for missing or incorrect information, divided by submitted requests | Review burden and clarity |
Every metric needs an agreed denominator, observation window, owner, and exclusions. The prototype can record session interactions, but these do not establish real operational improvement or adoption. There are no invented before and after figures.
Mock system boundary
The demonstration ends at a simulated PO or a reviewed exception. Production would require identity, a system of record, supplier data, approval authority, ERP integration, receipt, invoice processing, and durable audit storage. Actual markets, entities, ERP routing, approval delegations, catalogue rules, and integration patterns must be discovered rather than inferred from this mock-up. These dependencies need named owners and tested failure behaviour before rollout.
What I left out
Vendor selection, financial benefit forecasts, live integrations, tax and currency logic, invoice matching, and a full transformation schedule. This brief focuses on the decisions needed for a bounded pilot.