Workflow demonstration
Multi-entity governance
In short
The same category requirement arises at two plants in different legal entities. Group policy applies identically in both. Entity thresholds, approvers and supplier requirements differ, so the workflows take different governed paths — and both are visible in one central view.
Trigger
Two plants raise a similar requirement for the same material category.
Relevant audience
Group CPO, plant procurement heads, internal audit
Stage by stage. With the control that applies.
-
Stage 1 — TriggerTriggerTwo similar requests are raisedPlant A1 and Plant B2, in different legal entities, need the same material category.
- What stays in control
- Both enter the same governed intake.
- Outcome
- Comparable work becomes visible as comparable.
-
Stage 2 — PolicyRule appliedGroup policy applies to bothCompetitive sourcing rules, supplier qualification standards and audit retention apply identically.
- What stays in control
- Group rules cannot be disabled locally.
- Outcome
- Consistent enterprise control.
-
Stage 3 — PolicyRule appliedEntity rules produce different pathsEntity A requires two approvers above a lower threshold; Entity B permits a single approver at a higher one.
- What stays in control
- Local configuration operates inside the group framework.
- Outcome
- Local authority is respected rather than overridden.
-
Stage 4 — Agent actionAgent actionEach workflow executes under its own rulesOne request opens a competitive event; the other proceeds under an existing agreement.
- What stays in control
- The applied rules are recorded on each transaction.
- Outcome
- Standardisation and local fit at the same time.
-
Stage 5 — Human decisionHuman decisionDifferent approvers decideEach entity’s named approvers act within the authority delegated to them.
- What stays in control
- Approver identity and authority are explicit per entity.
- Outcome
- Accountability stays local where it belongs.
-
Stage 6 — System updateSystem updatedBoth appear in the central viewGroup procurement sees both workflows, their status and their policy paths.
- What stays in control
- The view respects role- and entity-based access.
- Outcome
- Group visibility without a consolidation cycle.
-
Stage 7 — Audit historyRecordedPolicy variance is visible and evidencedThe difference between the two paths is explained by configuration, not by inconsistency.
- What stays in control
- Exception patterns can be reviewed and the rules refined.
- Outcome
- Fewer shadow processes and less reporting effort.
Six questions. Answered the same way every time.
Every Proconomy workflow demonstration answers the same six questions, so you can set one workflow against another and against how it runs today.
| Question | Answer |
|---|---|
| What triggered the workflow? | Two similar requirements raised at plants in different legal entities. |
| What did the agent do? | Applied the correct combination of group, entity and plant rules to each, then executed the resulting paths. |
| What rule permitted it? | Group policy for what must be common; entity thresholds and approver structures for what may differ. |
| What returned to a person? | Different named approvers in each entity, acting within their delegated authority. |
| What system was updated? | Each entity’s ERP transaction, plus the shared group operating view. |
| What outcome changed? | Standardisation with local flexibility, better group visibility and fewer shadow processes. |
What changes as a result. Named, not implied.
- Standardisation with genuine local flexibility.
- Better group visibility.
- Fewer shadow processes.
- Evidenced policy variance rather than unexplained inconsistency.
Request interpreted and classified
Missing equipment reference requested
Requester supplied reference GB-4417
Buying policy selected contracted purchase
Approved within delegated authority
Purchase order written back to ERP
How this runs today. Mostly coordination, not judgement.
What happens between the need and the outcome, in most groups.
- The policy exists centrally
- And is applied locally by memory, training and habit.
- Thresholds vary without anyone deciding they should
- Because each entity interpreted the same document differently.
- Supplier approval crosses entities silently
- Cleared once, used everywhere, with nobody enforcing scope.
- The group view is assembled per request
- By one analyst, for one meeting, and then out of date.
- Variance is discovered by audit
- Rather than measured continuously.
- Plants build workarounds
- Because a single global process did not fit how they actually operate.
Six things to watch for.|In any vendor session.
- Configure two entities with genuinely different approval matrices, in the session.
- Try to buy in entity B from a supplier approved only in entity A.
- Ask what a group rule marked mandatory prevents a local administrator from doing.
- Confirm a plant user cannot see another plant's data from the same model.
- Ask how policy variance is measured, not just how policy is set.
- Ask what a plant keeps control of after this.
Four things to bring.|Yours, not ours.
- Two entities whose approval matrices genuinely differ, with both matrices.
- A category bought by several plants at different prices.
- Your group policy document, and the reality it describes imperfectly.
- A plant procurement lead who will say what will not work.
Bring one real workflow. We will run it, exceptions included.
These sequences describe the operating model. A live demonstration on your own process shows it, including the point where the software stops and asks a person.
Someone from client success replies, not a sales sequence. If we are not a fit we will say so on the first call.
Not ready to talk to anyone?
Fair enough. Both of these work without giving us your email.