One source-to-contract workflow across a diversified group
About the company
A diversified group operating businesses across infrastructure and other sectors. Central category teams and a shared services centre support the business units, which run on SAP, Ariba and a set of custom applications.
- Industry
- Industrial equipment
- Scale
- Multiple business units, central category procurement and a shared services centre
- Scope
- Sourcing, auctions, awards, contracts and policy checkpoints
At a glance
Before Proconomy
- Local processes
- Sourcing handoffs
- Team coordination
- Late policy checks
- Manual controls
After Proconomy
- Consistent buying, local authority
- Teams reuse what they already have
- Ownership is clear
- Exceptions are handled in sequence
- Capacity goes back to sourcing
Key products
- Sourcing & RFx
- eAuctions
- Contract lifecycle management
- Multi-entity management
The challenge
The group did not have a sourcing problem. It had made a deliberate decision to centralise, standing up central category teams and a shared services centre alongside the business units. What it did not have was a system that carried work between them. Records moved by hand, and the group needed a common workflow with the controls built into it rather than applied afterwards.
The group had already decided how it wanted to buy. What it needed was a workflow that behaved that way without someone carrying the policy from step to step.
Local processes
Different sourcing and contract practices across the business units made standardisation difficult.
Sourcing handoffs
RFx, auction and award details moved manually between steps.
Team coordination
Buyers and the shared services centre used emails and tickets to move work between them.
Late policy checks
Many governance issues surfaced only after the transaction had finished.
Manual controls
People checked and chased each transaction, and the load grew with the volume.
What the group actually asked for
Five specific things, each one a place where work was stopping or being checked too late.
- A common process the business units could follow while keeping local approval authority.
- Awarded terms and bid records that carry into contracting instead of being re-entered.
- Work that reaches its next owner without an email or a ticket to move it.
- Policy exceptions held for review before the next step, not found after the transaction.
- Follow-up that happens without a person chasing each transaction.
What we built
Multi-entity rules, sourcing and auctions carried through to contracting, routed work, and policy checkpoints standing between the steps.
Multi-entity rules
Group policy runs with local approvers and the documents each entity requires, so one rule set does not mean one way of working.
RFx and eAuctions carried into contracting
Awarded terms and bid records travel with the award rather than being re-keyed at the next stage.
Workflow routing
Tasks and reminders reach the next owner with the supporting records attached.
Policy checkpoints
Rules hold an exception for review before the work proceeds.
Automated follow-up and an audit trail
Reminders run on their own schedule and the actions taken stay recorded.
The result
The handoffs the group created by centralising are now the part the system does.
Consistent buying, local authority
Teams follow one process and keep their own approval authority.
Teams reuse what they already have
Awarded terms and the evidence behind them are available at the next step.
Ownership is clear
Pending work resolves with less chasing because it is obvious whose turn it is.
Exceptions are handled in sequence
Teams address a policy exception before the next step rather than after the fact.
Capacity goes back to sourcing
Time spent chasing returns to sourcing work and exception handling.
See this running on your own numbers — fifteen minutes, no slides.
Request a workflow demonstrationThis will sound familiar. If any of these are you.
- You centralised procurement and discovered the handoffs were the hard part.
- Sourcing records get re-entered on the way into a contract.
- Work moves between buyers and shared services by email and ticket.
- Policy problems are found after the transaction, when they are expensive to fix.
Where this connects
The questions we get asked.
No. The business units continue to run on SAP, Ariba and their own custom applications. Proconomy carries the source-to-contract workflow across them and applies the policy checks, rather than becoming a new system of record.
No. Group policy is written once and applied centrally, while each entity keeps its own approvers and its own required documents. Standardising the rule does not mean standardising how each business operates.
It holds an exception for review before the work moves to the next step. The point is sequence: the exception is seen while it can still change the outcome, rather than being reported after the transaction has completed.
Awards and approvals stay with people. The workflow carries the records, routes the task and holds the exception, but the decisions that commit the group are taken by a named person at a named step.
The same problem, at your scale
Every group that runs more than one operating company arrives at the same place: policy that exists on paper, applied differently in every plant, evidenced by whoever happens to remember. Bring us the workflow where that costs you the most, and we will run it against your rules.
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.