Facility jobs live or die in the handovers. A single request travels through sales, C&P, contract administration, project, engineering, vendors, claims, and finance, and every transfer is a place where files go missing, engineers get dispatched without context, and invoices stall behind unsigned chits. Teams understand their own slice well. The space between them is where margin leaks. Workflow design has to start with that gap, not with a screen list.
- Map the job lifecycle end-to-end before selecting or configuring any module.
- Replace vague status labels with handover checklists the next team can rely on.
- Treat every document as evidence that answers a specific business question.
- Assign explicit ownership for who creates, reviews, updates, and corrects each record.
A consulting team has to look at the whole operating chain, not only the department that asked for the software. The work is to identify what each team needs from the one before it, what evidence has to be present before the next stage can start, and which information must survive from the first request through to final payment and DLP follow-up.
Map the Job Before Mapping the System
The first layer of consulting is the job lifecycle. A facility job may enter as a client request, a maintenance ticket, a planned service, an urgent repair, or a tender. Each entry point carries different pressure: some need scheduling first, some need costing, some need procurement, some need engineering documents before site work can begin.
Interview by Role, Validate Cross-Functionally
Each role sees a different priority, and the workflow only works when those priorities are reconciled in one session:
- Sales focus on quotation speed and conversion.
- C&P focus on purchase order accuracy and vendor terms.
- Project teams focus on schedule and site readiness.
- Engineers focus on method statements, drawings, material submissions, and vendor documents.
- Finance focus on claim, invoice, and payment evidence.
The Questions That Define the Workflow
Discovery surfaces the questions the ERP has to answer:
- What information is required before costing can begin?
- When does a quotation become a confirmed job?
- Which incoming PO details are mandatory before work starts?
- Which department owns contract, project, and engineering records?
- How are vendor POs, service chits, claims, invoices, and receipts linked back to the original job?
Design Handover Rules, Not Just Status Labels
Status labels are easy to create. Handover rules are harder and far more valuable. A label like "Ready for Project" only works if every team agrees what it means: client PO uploaded, quotation approved, contract complete, engineering cleared to start. Those definitions belong in the workshop, not in the configuration screen.
In practice, we turn each handover into a short checklist. It has to be brief enough to follow under pressure, and strict enough to protect the next team from inheriting incomplete work. If project keeps chasing C&P for a PO file, or engineering keeps asking for vendor details, the rule is not tight enough yet.
Put Document Standards Around Each Step
Facility work is physical, but the proof of work is documentary. Quotations, incoming POs, work orders, purchase requisitions, vendor POs, method statements, shop drawings, material submissions, work programmes, service chits, progress claims, invoices, and receipts each serve a specific purpose.
Every Document Should Answer One Question
Treat documents as evidence, not as generic uploads. Each file should answer a single question:
- Did the client accept the job?
- Is procurement authorized?
- Was site work completed?
- Does this support the claim?
- Can the payment follow-up be closed?
Once each purpose is defined, the ERP can organize files around the workflow rather than dumping them in a shared folder.
Clarify Department Ownership
Facility ERP projects fail when ownership is vague. A file uploaded by one team is needed by another. A vendor record created by procurement is consumed by engineering. A payment record entered by finance feeds management reporting.
Consulting has to name, for every record, who creates, who reviews, who updates, who only views, and who is accountable when something is missing. Without that, the ERP becomes a shared space where everyone can see the problem and nobody owns the fix.
How the ERP Supports the Agreed Workflow
Once the operating model is settled, the ERP can mirror it with modules and file flows that follow the job, not the department.
Client request files, site visit notes, costing, quotation versions, work order preparation, and incoming PO details all sit on one record.
Award documents, contract details, progress claims, invoicing, payment receipts, insurance, DLP, and vendor POs travel with the job.
Method statements, shop drawings, material submissions, work programmes, service chits, and subcontractor POs are kept in the right context.
One view shows what was requested, quoted, accepted, scheduled, delivered, claimed, invoiced, received, and still pending.
The Result: A Job That Carries Its Own Context
A well-designed facility workflow lets the job carry its own context. No one has to ask where the quotation sits, whether the PO arrived, whether engineering uploaded the latest method statement, or whether the progress claim has supporting evidence. The record shows the current state at a glance.
That is the point of consulting. The ERP is only useful once the human workflow is clear: who is responsible, what they need, what they hand over, and what proof must be in place before the next team picks the job up.