Introduction to MRO

MRO means Maintenance, Repair and Overhaul. It works differently from manufacturing. You are not producing to a plan. You are reacting to equipment that arrives when it breaks.

The app exists to make that reactive work manageable.

The app answers these by keeping everything in one place: what each service order needs, what is missing, when capacity runs out, and what to do first.

💡 The key MRO insight is that you often do not need more stock. You need the right orders served first. If several service orders need the same scarce part, and some are missing one component while others are missing many, serving the nearly finished ones closes more orders with the same stock. See Simulations for how to test this before you commit.

The app has four views. Each one answers a different question.

This view lists all your maintenance work, ongoing and scheduled. You use it to check status, follow progress, and confirm that orders will finish on time. Each order carries its context with it: who is assigned, which parts it needs, and its planned timeline.

Every service order appears as a row. Each row is a piece of equipment, with its service order number and serial number. Orders are sorted by date, oldest first.

<aside>
💡

Revised Due and Customer Req. Date are not the same date. Customer Req. Date is what the customer asked for on their own. Revised Due is what you and the customer agreed after discussing it. When the original request could be met as-is, the two match. When it could not, Revised Due is the commitment that replaced it.

This matters because on-time delivery is measured against Revised Due, not against what the customer first asked for.

</aside>

The heatmap sits next to the table view. Here the columns are the parts your MRO operations need, and the rows are your service orders. It is the fastest way to see which part is blocking which order.

Reading a column header. Each header is the name of a part, and it is clickable — selecting it opens further actions on that part.

Reading a cell. Stock appears as XX / YY:

Colour code for stock levels

The colour answers one question: does current stock cover what the service orders need?

<aside>
💡

Some views express this as a shortfall figure rather than a stock figure. Where you see a number described in terms of used parts, read it as demand minus available stock: a positive value is the quantity still missing, so it turns the cell red. Zero or below means stock covers the demand. The number measures the gap, not what is on the shelf — which is why a positive value is bad news.

</aside>

<aside>
💡

The heatmap is the starting point for most MRO work: allocating a scarce part, unblocking an order after kitting, escalating a shortage. See MRO Usage Scenarios.

</aside>

This view shows the parts holding up your service orders, on a timeline. Each line gives you enough context to act on the part instead of just noting it.

Colour coding

<aside>
💡

Days Until Missing is the column to sort on. Blocking Date tells you when a part becomes a problem; Days Until Missing tells you how long you have left to do something about it.

</aside>

This is the only place in Pelico where work centre capacity is modelled. Capacity is set as hours per week, per work centre.

What it gives you

💡 This view has no equivalent in Production Control. The Suggested Start Date in the Work Order Book ignores capacity on purpose. It tells you when material and upstream work allow a start, not whether you can take it. If capacity is your constraint, this is the view that tells you.

This extends the Capacity view by adding forecast demand, so your capacity analysis reaches beyond firm orders.

💡 The blockage indicator is worth understanding. It is a capacity problem, not a material one. A service order can have every part it needs and still be flagged, because the work centre it needs is overloaded that week. That is a different problem with a different fix: move capacity, or move the work.

⚠️ Pelico uses the word "heatmap" for two different views. The heatmap view in the Service Order Book shows service orders against blocking parts. The work centre heatmap here shows work centres against weeks. They are not the same.

Coverage works the same way in MRO as everywhere else in Pelico. A service order gets the worst coverage status among the parts it needs, and the statuses mean the same thing: covered from stock, conditionally covered while supply is expected, or blocked with no solution.

How is MRO different from Production Control?

Production Control manages work orders against a production plan. MRO manages service orders against repair demand that arrives without warning. The coverage logic is the same. The views, the priority questions and the capacity model are different.

Why is my service order blocked when all its parts are available?

Check whether it is a capacity blockage rather than a material one. A service order that needs a work centre with too little capacity in a given week gets its own status, separate from material coverage.

Where do I see work centre capacity?

In the MRO Capacity view. It is set in hours per week per work centre, and it is the only capacity model in Pelico.

Do sales forecasts change my MRO plan?

Yes, where they are switched on. They feed the workload used for long-term load and capacity analysis, and Pelico shows what they mean for material.

Do coverage statuses mean the same thing in MRO as in Production Control?

Yes. Covered, conditionally covered and blocked are calculated the same way. See Pelico's Algorithms.

This article has a specific problem: two of its sections have no content, so their visuals cannot be produced yet. The list below separates what can be done now from what has to wait.

💡 That last one deserves attention. A diagram of the service order lifecycle through its gates, including the kitting gate, would probably be the single most valuable visual in the whole MRO section. Gates appear throughout the documentation and are never explained. Right now we cannot draw it, because nobody has written down what the gates are.

Before publishing. Replace the table of contents marker with a native /table of contents block. Convert the 💡 blocks to blue callouts and the ⚠️ blocks to yellow callouts. Add Notion links to #8 Pelico's Algorithms, #4 Simulation and #7 Production Control.

This article is publishable as it stands. It is more complete than the source. But the two most used views in the app still have no column reference, and readers will notice. See the MRO questions in #0 Pilotage.