Finding the right spot to focus in a complex operation is harder than it sounds. Most organisations know their assets, and most have assessed criticality against a specific asset, most have an annual site-level review up and running.
Few are integrating criticality where big decisions are made: into their whole value chain.
Criticality is typically assessed at a site level, by a small team, once a year, in a spreadsheet that gets filed and then largely forgotten. It produces a ranking of assets. It tells you which pump or conveyor belt to worry about. If you run one, two, or three sites, that's often enough: it helps you prioritise where OPEX and CAPEX should go. But as you grow into a network of assets, it won't tell you where in the network your OPEX or CAPEX should be directed. That requires understanding criticality not at a site level, but across the network.
How do you compare assets with entirely different functions across entirely different parts of the operation? Without a common measure of criticality across the value chain, every decision defaults to the one that’s best understood, not the one that matters most.
The starting point depends on where you are. Sometimes it's a single production line modelled in a spreadsheet, just to prove the concept. Sometimes it's a full network model across multiple sites, simplified to the smallest number of metrics that still capture the critical variables. The form changes. The goal is always the same: make the constraint visible, make the comparison honest, and put the right decision in front of the right person.
Without a common measure of criticality, every project has a justification, but none can show its true impact on the target. The funding limit forces a decision.
output $3.2M available
The problem is not that organisations lack an understanding of the issues. The pain is real and usually well-documented. What is missing is an understanding of the relative impact of those issues across the system.
Problems surface in many ways: a year on year bow wave of rising CAPEX submissions, a maintenance cost that keeps climbing without a clear explanation, an operational target that keeps being missed. But it is often the surprises that reveal the real issues. The unplanned shutdown nobody expected. The throughput shortfall that appeared in a part of the operation nobody had been watching closely. These are the moments that expose how little the organisation actually understands about where its constraints sit across delivery.
Without a framework that goes beyond just asset by asset, site by site thinking, decisions about where to direct OPEX and CAPEX default to what is most known, most visible, or most loudly argued. That is not prioritisation. It is familiarity dressed up as judgement.
A new leader walking into this situation cannot make sense of it. They ask where the constraints are and receive three different answers from three different people. They ask what the OPEX and CAPEX priorities are and receive a ranked list, but no-one can fully understand how the different decisions impact one another. If you cannot explain your value chain, its critical points, and what is limiting performance to someone who just walked in the door, your organisation cannot make efficient decisions about where its effort and money should go.
The fix is not another site-level criticality workshop. It is building a view of criticality that works across the whole chain: comparable, simple, and connected to the decisions that actually matter.
A value chain view maps every site, every transport leg, every processing step against the same set of metrics. Not to create something complex: the opposite. The goal is the simplest possible set of measures that allows a meaningful comparison across every node in the chain. For example: performance as throughput against design capacity, risk as stoppages per period and unplanned downtime, and cost as production cost per unit and maintenance cost per unit, applied consistently, including to transport legs that are almost always invisible in a site-level view.
Generic bulk commodity value chain (site level)
The same metrics applied at every site, including transport, so nothing is invisible and the comparison is honest
One consistent metric set across every site makes the picture immediate. Site A is the critical constraint: lowest throughput, highest stoppage rate, elevated cost. Rail Freight is the second pressure point. Without this view, investment flows toward the sites that argue loudest, not the ones that limit the chain.
Asset network (criticality & status)
Node size reflects criticality. Colour reflects performance status. Multiple entry points, cross-connections, multiple customers.
Real asset networks are not a single chain. Supply enters from multiple points, some mid-network. Flow consolidates through hubs and distribution nodes before reaching multiple customers. The most critical nodes are not necessarily the largest facilities; they are the ones whose failure affects the most customers. Criticality assessed at site level in isolation misses this entirely.
When you look across a value chain this way, the constraint is often not where the organisation assumed it was. This is not always because one site is objectively underperforming; it can be that in comparison to the rest of the chain, the issues sit elsewhere. A site attracting significant investment and management attention may be underperforming in isolation. But place it alongside the node that is actually limiting throughput across the whole chain, and the relative picture changes immediately.
The closer a node sits to the customer, the more immediate the effect of a failure, not just on that site but on everything that flows through it. Often this is why the nodes closest to a customer have the most focus (time and money). When you can see which nodes are most critical to the chain, you can show the reason to reprioritise for a period of time and you can also start an honest conversation about business continuity. What happens if this node fails? Which nodes have redundancy? Which ones don't?
This is the level at which CAPEX and OPEX prioritisation across a large network of assets should be made. If you cannot show, in a single view, how the criticality of one site or one process compares to another, using the same metrics, you are not in a position to make those calls with confidence.
Same projects. Same budget. Different basis for deciding.
Criticality mapped against the value chain, not argued in isolation
The same projects. The same budget. The difference is the basis for the decision. The $2.4M conveyor upgrade at Site B had the best business case, and would have consumed most of the budget. The chain view shows Site B is not the constraint. Without it, that money would have been spent confidently, in the wrong place.
This is what changes when you have the framework.
Criticality assessment done well turns what is typically a table of competing priorities into a comparable view of relative impact. It does not solve for what is unknown; there will always be surprises. But it does allow the comparison of value chain metrics against proposed projects, so that investment can be directed toward the nodes where it will actually move the outcome.
A project that addresses a high-criticality node, one that is limiting throughput, driving unplanned downtime, or carrying an outsized cost relative to its position in the chain, can be evaluated against one that addresses a node that is performing well in context. The metrics make that comparison possible. Without them, both projects compete on the strength of their business cases, and the better writer wins.
The organisations that do this well do not necessarily have better assets. They have a clearer picture of where their assets sit in the chain, what the chain needs from each of them, and where the effort and investment should actually go.
That picture is not complicated to build. It is just rarely built.
At a production level, this can still fit the typical yearly review, with the same three measures applying, but at process granularity. Performance becomes units per minute against a designed rate. Risk becomes rejects per run and unplanned stoppages per asset. Cost becomes waste per run and maintenance cost per asset.
Production line (process level metrics)
The same performance, risk, and cost lens, applied at every asset, including side processes feeding the main line
Filling is the constraint, governing everything up to Cap Application at 29 u/min. The accumulation buffer decouples what's downstream, letting Labelling run at 58 u/min, which looks good but signals risk, not performance. Cap & Label Feed is under pressure; a stoppage there halts the whole line.
Two things become visible at this level that a purely technical or maintenance-focused view often misses. The first is what is typically front of mind: which asset is the constraint, and the second is that the cost of that constraint on the line can now be determined in real lost production terms, not just downtime. Every asset downstream of the constraint is governed by that rate, regardless of individual capability. An asset overperforming downstream (for example, see Labelling after the accumulation buffer) is not a success, but rather a diversion of time and funding to the wrong area.
A purely technical view of these assets produces a technical answer. What the operational view adds is the question of what the line actually needs to deliver, and whether the investment and effort going into each asset is aligned to that requirement, or just to what the engineering team knows best.
None of this replaces the site-level view. Often the site view is an easy starting point to get the team all aligned, or for a smaller organisation mapping a single site is the powerful thing to do. The same value chain approach just applies at that scale too.
We build this with clients rather than for them, starting wherever you are: sometimes a single production line modelled in a spreadsheet to prove the concept, sometimes a full network model across multiple sites. The form changes. The goal doesn't.
If you got this far, we should probably talk. No pitch, no obligation, just an honest discussion about whether there is a problem worth solving together. Request a meeting.