Automating MRO Contractor Requests: Process Model

Why automate MRO contractor requests

Manual handling of MRO contractor requests almost always becomes a race against time. Emails, spreadsheets and scanned acts live in different places, and important details surface after the contractor has left site.

The main cause of conflicts is plan vs actual on volumes and deadlines. The request said one thing, the specification clarified another, the estimate assumed a third, and in reality a fourth was done. If this isn’t recorded in a single system, the dispute quickly becomes personal: who promised, who approved, who allowed, who accepted.

Most often it’s not the documents that get lost but their history. There might be three versions of the specification, two versions of the estimate and correspondence with comments, but no simple answer which version was the basis for the permit and acceptance. As a result, act generation and KS-2/KS-3 calculations are delayed, and withholdings for quality or time turn into bargaining.

Automating MRO contractor requests provides several things that prevent the process from “drifting”: unified statuses across the chain (spec, estimate, approval, permit, acceptance, acts), linking decisions to their grounds (who and why approved changes), control of planned volumes, actuals and deviations with clear reasons, tracking of permits and site constraints (dates, responsible persons, conditions), and calculation of withholdings by transparent rules.

Real-life example: a contractor replaces a section of piping. During opening it turns out more work is needed. If the change isn’t recorded in the spec and estimate, acceptance becomes a dispute: the customer sees an overrun, the contractor sees necessary work. In an automated process, additional work is issued as a change with approval. At the end you can see what was planned, what was done, and which withholdings applied for quality and delays.

For large organizations with distributed sites, a unified data discipline is especially important: when all requests and evidence are in one place, resolving disputes takes hours, not weeks.

Terms and scope: what MRO covers and what it doesn’t

To prevent automation from becoming an accounting of all contracting “chaos,” first agree the boundaries. MRO (maintenance, repair and operations) answers a simple question: what needs to be done to make the asset work safely and to standard, and who confirms it.

Basic terms in plain language

Request — an official demand to perform work with a clear reason, object and responsible parties. Work — a specific action (for example, replace a pump, restore a cable, perform diagnostics). Stage — part of the work that is practical to plan and accept separately (preparation, installation, testing). Repair object — the thing tied to deadlines, permits and acceptance: an equipment unit, room, network section, server rack.

It’s useful to separate three types of tasks from the start:

• Emergency work — for rapid restoration. Often follows an expedited procedure, but the fact and reasons must be recorded.
• Planned work — scheduled (maintenance cycle, periodic replacement, seasonal activities).
• Project work — changes and upgrades (new lines, relocations, capacity expansions).

Project tasks normally follow capital-project rules. If you mix them into the MRO flow, budget and schedule control is quickly lost.

Key documents and what they mean

Specification (spec) describes the required result and the acceptance criteria. The estimate shows how much it costs and what the price is composed of. A permit is the authorization to start work on the object (safety, access, permit-to-work, briefing). Acceptance is the on-site check of the result: does it work, does it meet requirements, are there remarks. Acting (issuing the act) formalizes completed work with documents (often KS-2/KS-3 or internal acts) so payments and closures can proceed.

A minimal set almost always needed for a controlled process:

• a request with description, object, priority and responsible parties;
• a specification or defect list (what and why);
• an estimate or contractual price tied to stages;
• a permit document (permit-to-work/authorization/log);
• an acceptance act and an act of completed works (for payment and closure).

Other documents depend on company and industry rules: photo evidence, test checklists, material certificates, measurement protocols, warranty letters. Separately, record rules for withholdings for quality and deadlines: when to withhold, for what, and how to lift the withholding after issues are fixed.

Process model step-by-step: from request to withholdings

For MRO contractor request automation to work, break the process into clear stages and define which data is the “truth” at each stage. That reduces arguments about why deadlines shifted, volumes suddenly grew, or acts don’t match the estimate.

Process logic: 5 stages

In practice it’s convenient to group the flow into large blocks while storing details inside (spec and estimate versions, protocols, files).

• Initiation: request from an initiator with object, reason, priority and desired dates.
• Development: spec with volumes, material requirements and quality criteria, plus photos, measurements and drawings.
• Finance and decisions: estimate with items, units, rates, materials and taxes; then approvals along routes and limits with recorded disagreements and versions.
• Permit and execution: permit-to-work, safety briefing, work area, permit window and time restrictions.
• Acceptance and settlement: record actual volumes, remarks, act generation (KS-2, KS-3), withholdings for quality and deadlines.

The key moment after a request is the transition from “we want to do this” to “we agreed what exactly and for how much.” Therefore spec and estimate must be versioned: every edit has an author, date and reason, and approval refers to a specific version.

Acceptance, acts and withholdings: what to record

Imagine: the contractor replaced 12 meters of cable but the estimate said 10. Without a clear acceptance procedure a dispute is almost guaranteed: where is the measurement, who approved the excess, why wasn’t a change issued.

It’s useful to separate the "execution fact" from the "financial fact." Acceptance confirms the actual volume and quality, while the act sets the payable amount taking withholdings into account.

To make withholdings transparent, systems usually record:

• basis: contract clause, type of withholding (quality or time), related remark or delay;
• calculation: rate or formula, base (amount/item/stage), accrual period;
• documents: act, order, photo evidence, dispute protocol;
• status: accrued, disputed, confirmed, withheld, released.

If rules are set in advance, acceptance becomes a calm checklist rather than a verbal argument after work is closed.

Roles, responsibilities and decision points

To prevent automation becoming just another file-exchange, define roles and the decisions the system must record. Then you can see for each request who made a step, who decided and on what grounds.

Key roles typically are: customer (asset owner or initiating unit), MRO service (technical process lead), procurement (purchasing and contract terms), finance (budget and payments), HSE (permits and safety), contractor (execution and volume confirmation).

A RACI matrix is handy by stage:

• Request and spec: customer is responsible for need and initial data (R), MRO service composes the technical part (R), customer manager approves priority and necessity (A), HSE consults on risks (C), finance is informed about planned costs (I).
• Estimate and contractor selection: contractor prepares calculation (R), procurement handles procurement (R), finance approves limit and payment terms (A), MRO advises on norms and volumes (C), customer is informed on deadlines (I).
• Permits, acceptance, acts: contractor executes and provides evidence (R), MRO accepts volumes and quality (R), customer approves acceptance (A), HSE confirms safety requirements (C), finance obtains data for payment (I).

The system must store decisions in clear statuses without ambiguity: “approved” (who, when, what exactly — spec, estimate, permit, act), “needs rework” (reason and deadline), “rejected” (reason and who rejected), “closed” (what is closed: works, documents, withholdings).

Access rights are better set by actions: view (within one’s perimeter), edit (owners of the stage: spec, estimate, acts), sign/approve (only approvers, with a journal), close request (customer or MRO by regulation), record withholdings (finance based on acceptance and reasons).

Example: for a pump replacement a contractor can “finish the works,” but only after MRO acceptance and HSE confirmation of permits can the request be closed and payment started. This makes decision points transparent and auditable.

Required data: a minimal entity and relationship schema

To avoid turning automation into a "scan repository," start with a minimal data model. Its purpose is simple: link a request to a specific object, the agreed work volume (plan) and what was actually accepted and paid (actual).

Usually five key entities are enough; add more later:

• Request: number, initiator, contractor, object/site, priority, planned dates, status.
• Object/Equipment: inventory number, location, unit/aggregate, criticality, link to requests.
• Spec and estimate (with versions): version, date, author, reason for change, total cost, VAT, attachments.
• Work plan (items): item code, work type, unit, planned quantity, price, estimate item, link to spec/estimate version.
• Actuals, acceptance and acting: actual quantity per item, completion date, acceptance results, defects, documents (KS-2/KS-3 or equivalents), withholdings.

Build links so plan and actual align on a single anchor — the work item code. Then plan vs actual comparison does not require manual matching. It’s important to store the version of spec/estimate the plan belongs to: if the estimate is re-approved, old items should not silently move to a new version.

Also consider immutability and history. Two common mechanisms suffice: a change log (who, when, what changed, why) and locking key fields after approval (for example, scope of work and prices).

Attachments should not be hidden in comments. For each file record its type (photo, drawing, protocol, signed scan), date, author and link to a specific entity: to a spec version, to a permit, to acceptance or to an act. Then investigations take minutes, not days.

Data set for comparing planned and actual volumes

For honest plan vs actual you should manage data by work items, not only by contract sum. This shows where there’s overrun, underperformance and what was accepted.

A minimal dataset can fit in five tables. It works for Excel at the start and for later automation:

Work_Plan(
  request_id, work_item_code, uom,
  qty_plan, price_plan,
  date_start_plan, date_end_plan
)

Work_Actual(
  request_id, work_item_code, uom,
  qty_fact,
  date_start_fact, date_end_fact,
  crew, comment
)

Acceptance(
  request_id, work_item_code,
  qty_accepted, qty_rejected,
  defect_type, rework_required, remarks
)

Acts(
  request_id, act_id, act_type,
  amount_plan, amount_fact,
  sign_date_contractor, sign_date_customer,
  status
)

Withholdings(
  request_id, withholding_id,
  reason, method,
  base, amount,
  release_rule
)

The separation logic is simple: Work_Plan sets expectations for volume and price, Work_Actual records the execution fact, Acceptance shows what was accepted and rejected, Acts links work to acting (KS-2, KS-3 or internal act), Withholdings stores withholdings and release rules.

How to compare plan and actual without disputes

To keep reports consistent establish rules in advance:

• Units of measure (uom) must match. If the contractor reports m2 and the plan used linear meters, keep a conversion table and the basis for conversion.
• Rounding: for example, to 0.01 for volumes and two decimals for amounts. Use one rule for all reports.
• Partial acceptance: compare plan vs actual using qty_accepted (accepted) rather than qty_fact (performed). Rejected amounts should remain in qty_rejected.
• Closing an item: a work_item_code is closed when accepted quantity reached the plan or when a change to the volume is approved (supplementary agreement/change request).

Small example

Plan: work_item_code = "RPL-001", uom = "pcs", qty_plan = 10, price_plan = 50,000. Actual: contractor reports qty_fact = 10, but acceptance rejected 2 due to defects, qty_accepted = 8, qty_rejected = 2, rework_required = "yes". The act covers the amount for the accepted volume (8). A quality withholding can be calculated as a percent of the base (for example, of the accepted amount) and released only after re-acceptance of the remedial work.

How to implement automation: a simple step-by-step plan

Start not with system selection, but by answering two questions: what decisions must be made in the process and where money and time most often get lost. Usually it’s enough to define the rules first and then move them into forms and approval routes.

Preparation: agree first, configure later

First describe request statuses and transition conditions. Example: draft -> under review -> permitted -> executed -> under acceptance -> closed. Immediately define who can move a status and which fields must be filled.

Then create 3–5 spec and estimate templates by work type (electrical, instrumentation and control, mechanical, construction). A template should suggest the work composition, units and the minimal set of documents.

Then introduce unified work codes and reference data: work types, objects, equipment, units of measure, repair reasons, contractors. Without unified codes plan vs actual will speak different languages.

Next configure approvals. The more exceptions, the more manual work. Predefine routes and limits by amount: up to X — one approver, above — another, critical works — separate. Add budget control (limit, account, cost center).

Launch: collect the actual during execution

Organize fact collection during execution: work log, measurements, photos, downtime notes, signatures of responsible people. Fact entries must link to the work item code and estimate position.

Then configure acceptance and acting: acceptance committee or responsible person, record remarks, enable partial acceptance if needed. Next — calculate withholdings for quality/time based on predefined rules and close the request.

Example: pump repair request. The spec has a standard list of operations and the estimate has coded positions. The contractor marks performed volume daily and attaches photos. Acceptance found an unfinished item: the system withheld part of the payment until remediation and left the request open at the "fix remarks" stage.

Common mistakes and pitfalls in MRO contracting

Even a good regulation fails on small details. In MRO contracting these details are usually that people keep some data in emails, some in Excel and some in their heads.

The most frequent problems:

• Plan and actual described in different words. The plan has one item ("pump repair"), while the actual lists others ("dismantling", "inspection", "seal replacement"). Thus plan vs actual doesn’t match and the dispute centers on terms, not volumes.
• No versions of spec and estimate. After approval something was changed and the old version wasn’t preserved — you can’t prove what was approved and at what price.
• No rules for partial acceptance. For long jobs (a week or a month), without clear stages everything stalls: the contractor asks for an act, the customer waits for completion, disputed volumes accumulate.
• Permits handled outside the system. Permit-to-work, briefings, hot-work permissions or access permits live separately. Risk: work actually started without authorizations and later it’s hard to assign responsibility.
• Withholdings calculated manually. Spreadsheets easily introduce errors in percentages, bases and dates, and a conflict with the contractor is almost guaranteed.

Another story is deadlines set “for the record.” If a request contains an unrealistic deadline, later it’s impossible to fairly assess delay: the contractor will point to the impossible initial plan, the customer to actual delays.

Practical example: request specified “replace 10 m of piping,” but in reality 8 m were replaced and two fittings were added. Without versioning and partial acceptance rules act generation becomes a negotiation. Automation only helps when these rules are encoded in the process and data fields beforehand.

Quick checks before closing a request

Before closing a contractor request it’s useful to do a short verification so you don’t return later to fix acts, payments and withholdings. Spend five minutes now instead of a week on emails and internal approvals.

First ensure the request can be unambiguously found and its context restored. There should be a request number and link to a specific object: site, workshop, line, equipment unit (with inventory number or asset code). If the object is listed vaguely, plan vs actual reports will diverge.

Then check the supporting documents. Spec and estimate must be approved, versioned (for example, v2 from 12.03) and show who approved them and when. If volumes or scope changed, changes must be recorded as separate versions, not edits made after the fact.

Next review plan vs actual by items. Comparison only works when actuals are recorded against the same items as the plan: same work code, same unit and dates. If the contractor delivered "in general" but the plan was itemized, acting becomes disputable.

Short checklist:

• the object and equipment are specified precisely;
• spec and estimate are approved with versions and responsible persons recorded;
• each item has a work code and unit of measure;
• actuals are entered for the same items, with dates and supporting evidence;
• acceptance reflects accepted/not accepted and reasons for rejection.

Finally check withholdings. They should be calculated by rules (quality, time), linked to a specific act and, when needed, to an item. If painting is accepted at 80% due to defects, the withholding must reference that item, not "the whole act."

Example: one MRO request from spec to acts and withholdings

A pump unit H-17 stopped: increased vibration, seal leak. The shift supervisor creates an MRO request for contractor work and marks it critical: downtime affects the line.

The spec is formed from the defect and measurable scope. The request records what exactly is faulty, which works are needed, which materials the customer supplies, and how acceptance will be performed. Acceptance criteria are measurable: vibration below a threshold, no leaks, pump running 8 hours under load. Deadline: 3 calendar days from contractor permit.

The contractor submits an estimate which is reviewed and edited. Example items (version 1, then final after clarifications):

• Dismantling and inspection of the unit (1 set)
• Replacement of mechanical seal (1 pc)
• Replacement of bearings (2 pcs)
• Alignment of the unit (1 set)
• Commissioning and testing (8 man-hours)

After approval a permit is issued: working dates, responsibles, stop window, HSE requirements. Execution fact is recorded in the log: shifts, people on site, volumes done, downtimes. Photos and measurement results are attached to the request card.

Plan vs actual can be checked by key volumes:

Acceptance is two-step. First partial: mechanical work accepted but the load test shows overheating. A remark is created, the contractor reworks (additional alignment), then final acceptance closes the remarks.

Then acts are issued: KS-2/KS-3 for the accepted volume. The deadline was missed by 1 day, so a 5% withholding applies per contract terms. The release condition is recorded: the withholding is returned if no repeat leak occurs and vibration stays within limits during a control measurement within 30 days.

Reporting and next steps: how to scale to production

Good MRO automation is visible not through pretty screens but through reports that help decision-making. If spec, estimate, approvals, permits and acts are collected uniformly, it’s easy to see where time and money leak.

The most useful reports are usually simple. Plan vs actual by volume and cost per request and contractor shows overruns immediately, not at month-end. A delay report by stages (approval, permit, execution, acceptance, acting) helps distinguish real on-site delay from delay “in the office.” A quality report logs repeat rework, acceptance remarks and withholdings.

To make reports work, agree on a handful of metrics and keep them consistently:

• share of requests with overruns (by amount and by key items);
• average time to approve spec and estimate (by role and unit);
• number of repeat site visits or reworks per request;
• share of acts with withholdings for quality and for time;
• variance between planned and actual labor or volumes for typical works.

Then use reports to change the process. If one-third of specs return for rework for the same reason, create a template and mandatory fields. If plan vs actual drifts on the same work types, update norms, units and rounding rules and tie positions to estimate items.

A typical scaling path: pilot on one site or work type (for example, pump equipment), short role-based training, then approve regulations and control points. Assign an owner for reference data and an owner for reporting; otherwise data will fragment.

Also check infrastructure. The request system must be reliable, especially when acting is done at month-end. Provide stable workplaces for technicians and engineers, database servers and support for failures.

If you are in Kazakhstan and want to build this into a working solution for your process, GSE.kz (gse.kz) as a system integrator and manufacturer can help with selecting PCs and servers, implementation and infrastructure support so the MRO process doesn’t depend on manual routines.