Move beyond ERP & Excel: how it works and what to require
This is for manufacturers whose ERP handles the transaction while people still coordinate the work around it in Excel and email. Proconomy adds a governed execution layer: agents perform authorised work inside your policies, people decide what matters, and approved outcomes are written back. The ERP stays exactly where it is.
Every spreadsheet is load-bearing. None of them has an owner.
The specific places a file on someone’s laptop is holding your procurement process together.
Sourcing
- A comparison sheet rebuilt for every event
- Supplier lists maintained by individual buyers
- Quotes arriving as five different attachments
- Award decisions justified in an email thread
- Event history lost when someone changes role
- Categories skipped because setup takes too long
Suppliers
- Certificates tracked in a plant spreadsheet
- Onboarding chased across three teams
- Approved-supplier lists that disagree by site
- Scorecards built by hand each quarter
- Risk assessed once, at onboarding
- Supplier data re-entered into each system
Contracts and purchasing
- Agreements stored where the signer filed them
- Renewal dates in a personal calendar
- Contracted prices not applied at order
- Approvals chased individually by email
- Purchase orders retyped from an approval
- Status answered by asking a person
The group view
- Consolidated spend built for each board meeting
- Entity comparisons assembled manually
- Policy adherence checked by sampling
- Exceptions counted only after they matter
- Audit evidence reconstructed from mailboxes
- Every answer waiting on one analyst
Six replacements. None of them another spreadsheet.
What takes over each job the file was doing, and where the ERP stays untouched.
| Mechanism | What it has to do |
|---|---|
| Governed intake instead of email | One entry point that classifies the need, checks it is complete and applies your buying policy before a buyer sees it. |
| Reusable event templates instead of rebuilt sheets | Question sets, scoring and approvals configured per category once. Responses normalised automatically rather than by hand. |
| One supplier record instead of several lists | Qualification, documents, risk, performance and spend on the same record, scoped by entity and enforced at the point of purchase. |
| Connected contracts instead of a filing location | Obligations and renewal dates carry owners and surface before the date; contracted price applies when the order is raised. |
| ERP write-back instead of retyping | Approved outcomes are written to your system of record, with success and failure both monitored. |
| Live position instead of an assembled report | The group view is a query, not a project, and a plant sees its own slice of it. |
A description of what the practice requires, not a feature list.
Same problem. Different file by sector.
Which spreadsheet is load-bearing in your industry.
Automotive
The APQP milestone tracker and the PPAP submission log — both on a laptop, both load-bearing for a launch date.
Medical devices
The supplier qualification file, assembled from three mailboxes when an auditor asks.
Building materials
The delivered-cost comparison across plants, rebuilt whenever someone asks whether consolidation is worth it.
Industrial equipment
The project sourcing pipeline, which is invisible to anyone not on the email thread.
Five questions. Answered before you shortlist.
Naming the three files is the fastest way to scope this.
- Name the three spreadsheets your procurement function could not operate without this week. Those are the scope.
- Ask who maintains each one, and what happens when that person is on leave.
- Ask any vendor to run one of those three workflows in the session, on your policy.
- Confirm the ERP stays the system of record and get the written objects list before signature.
- Decide which single workflow goes first. A programme that starts everywhere starts nowhere.
Definitions. Asked and answered.
No. The ERP remains the system of record. Proconomy changes how procurement work gets done around it and writes approved outcomes back. Replacing the ERP is neither necessary nor what this solution proposes.
Adoption usually fails when a tool asks employees to do more work in a new place. Guided intake asks a requester to describe a business need in their own words, and the platform handles classification, routing and follow-up. The behaviour change is smaller.
Less than most teams expect. The configuration expresses your existing policy — thresholds, approvers, buying routes — as executable rules. Redesigning the policy is a separate decision you can take later.
Perfect data is not a precondition for governed execution. Intake, approval and supplier workflows improve data quality as they run, because required fields are collected at the point of work rather than reconstructed afterwards.
Bring one real workflow that frustrates the team and see it run end to end. The internal argument is usually settled by watching a request become an approved ERP outcome with the audit trail visible.
Because it is the only tool flexible enough to hold work the ERP was never designed for: comparing inconsistent quotes, tracking a qualification, chasing an approval. The ERP records the transaction; the coordination that produces it has no home, so it ends up in a spreadsheet.
Three main risks: the process depends on individuals rather than rules, so it varies and breaks when people move; there is no reliable evidence trail, which surfaces during audit; and capacity is capped by how much coordination people can personally carry.
No, and replacement usually solves the wrong problem. The ERP records transactions accurately. What is missing is a governed layer that executes the procurement work around it and writes approved outcomes back.