Use Case -  Productivity and the Work-Order Release Decision

[A dry-dock example of how causal operating design connects ERP control to measurable productivity]

Productivity is often discussed at a distance from the operating decisions that create it. At the national level, the conversation is framed through labour productivity, capital deepening and multifactor productivity. Inside the enterprise, the discussion moves quickly to revenue, margin, labour cost, utilisation and the P&L.

 Those measures matter, but they are mainly evidence of what the operating system has already produced. They tell us whether performance changed. They are much less useful at explaining which operating behaviour changed, why it changed, and whether that change caused the productivity improvement.

A complex dry-dock maintenance environment makes the problem visible because the physical system is unforgiving.

A vessel enters a constrained dock window carrying a large body of planned maintenance. Hundreds or thousands of activities may compete for labour, materials, specialist tooling, permits, cranes, access, certifications and engineering support.

The work is interdependent. Strip-and-assess activities expose conditions that were not fully knowable beforehand. Emergent work enters the plan. Some resources are highly constrained. Delays do not remain local for long. They propagate.

In that setting, one apparently simple ERP or EAM decision becomes strategically important. When should a work order be released for execution? In the application, release may be represented by a status change. Planned becomes released. Released becomes started. Started becomes completed. Technically, the transaction is ordinary. Operationally, it is a decision about whether more demand should be admitted into an already complex system.

A work order is not the same thing as executable work

A work order can exist, be approved and even be scheduled without being genuinely ready to execute. Material may not be at point of use. A permit may still be outstanding. The work package may be incomplete. A required inspection or engineering clarification may not have been completed. A crane may be unavailable. A predecessor task may still be open. The necessary trade may be certified but committed elsewhere. The vessel area may be physically inaccessible. Yet a conventional system can still make the work look available.

Once that work is released, it competes for attention. Supervisors allocate people to it. Stores issue material. Planners move dates. Teams begin and stop. Scarce specialists are redirected. Work fronts multiply. The work order may be visible as active work, but the system has not necessarily created productive flow. It may have created work-in-process that is waiting, blocked or partially complete.

This distinction is central to productivity. People can be busy while the system becomes less productive. Labour utilisation can look healthy while vessel completion moves further away. More open work can create more coordination, more queues, more switching, more expediting and more schedule churn. Local activity rises, yet whole-system throughput deteriorates.

The productivity question starts before labour becomes idle

A conventional performance review will often begin with symptoms. Why are trades waiting, why is overtime rising, why are planned completion dates slipping, why is dock duration extending? Those are legitimate questions, but they arrive relatively late in the causal chain. A more powerful question is upstream. Why was work admitted into execution before the system was ready to execute it?

That changes the intervention. Instead of treating work-order release as an administrative step, release becomes a control decision governed by readiness. The organisation establishes explicit conditions that must be satisfied before work can normally enter execution. Materials available, work package sufficiently complete, permits and access resolved, required labour and certifications available, necessary equipment accessible, and critical predecessor conditions met.

The intervention appears modest, but the causal hypothesis is substantial. Better readiness control should reduce premature release. Fewer prematurely released work orders should reduce blocked work and unnecessary WIP. Lower WIP should reduce congestion, resource switching, queuing and replanning. More stable execution should shorten work-order duration. Across the dock event, that should contribute to shorter and more reliable dock duration. If dock capacity is the economic constraint, shorter and more reliable dock occupation can translate into greater effective throughput and better delivery performance.

What is behind the arrow?™

The chain sounds plausible. Readiness control leads to lower dock duration. But nearly the entire productivity argument sits inside that causal arrow. A readiness gate does not automatically shorten a dock event. Several causal assumptions have to hold. Premature release must actually be a material source of blocked work. Blocked work must contribute materially to WIP and queues. Those queues must interfere with constrained resources and execution stability. Improved stability must be significant enough to affect work-order duration and ultimately dock duration.

This is why a small collection of high-level KPIs cannot establish the mechanism. Suppose dock duration improves after a new release discipline is introduced. Was the readiness intervention responsible? Or did the vessel arrive with a smaller work package? Was more labour added? Did the organisation rely on more overtime? Was the mix of work easier? Was there less emergent work? Did weather, access or supplier performance change? A correlation between the new rule and an improved outcome is evidence, but it is not yet a causal explanation.

The productivity design needs a deeper measurement architecture. At the operational edge are signals. Work orders waiting for material, permits, engineering clarification or access. Released work subsequently blocked, constrained resources reassigned, emergent work inserted and planned tasks displaced. These are not board-level measures. They are evidence about what the operating system is doing.

Above them sit diagnostic measures such as premature-release rate, average blocked time, WIP by execution area, queue time for constrained resources, schedule churn, resource switching and readiness-induced delay. These measures test whether the proposed mechanism is behaving as expected.

Above those sit the benefit drivers. Execution stability, reduced waiting, lower congestion, improved schedule adherence, better use of productive capacity, and reduced rework and replanning. Only then do we reach the higher-order operating outcomes such as work-order duration, dock duration, on-time completion and dock throughput. Financial effects follow later through labour cost, overtime, margin, revenue opportunity and asset utilisation.

The P&L records the consequence, not the mechanism

This is an important distinction in any productivity discussion. The P&L is essential, but it is a periodic financial representation of the outcome. It does not explain the operating mechanism that generated that outcome. If the dock finishes earlier, the economic result may appear through lower cost, avoided penalties, increased capacity or an additional docking opportunity. But by the time that evidence appears, the operating decisions that caused it may have occurred weeks earlier.

The same problem exists with conventional productivity measures. They are necessary for judging whether output improved relative to inputs, but they do not necessarily tell the organisation which rules, behaviours and constraints produced the improvement. Without the causal chain, management can observe the result while remaining uncertain about what to repeat, what to scale and what to correct.

Readiness alone is not sufficient

The dry-dock example also shows why a readiness gate cannot be treated as a complete solution. A perfectly ready work order should not necessarily be released. The operating system may already contain enough work. A critical resource may be fully loaded. Another activity may have higher priority because it protects the critical path or the dock-completion date. Emergent work may have consumed scarce capacity. A release decision has to answer two separate questions. Is this work executable, and should it enter the system now?

That brings other controls into the design. Constraint allocation matters because scarce resources must be directed toward the work that best protects system performance. A WIP cap matters because even ready work can create congestion if too much is admitted at once.

Transaction latency matters because a release decision made on stale information may be wrong before execution begins. Emergent-work insertion matters because unplanned work has to enter without destabilising the entire schedule. Finite scheduling matters because capacity is physically constrained even when the planning system assumes otherwise.

In practice, work-order release becomes one regulator in a wider control architecture. In the dry-dock example, five regulators become particularly important. Constraint allocation, the task-readiness gate, WIP control, transaction latency and emergent-work insertion. None is independent. Their combined effect is to regulate what work is allowed into execution, when it is allowed in, and how the system responds when reality diverges from the plan.

ERP moves from recording to regulating

Seen this way, the role of ERP or EAM changes. The application is no longer simply documenting transactions after decisions have been made. Planning information identifies dates, demand, shortages and reservations. Execution information reveals what has actually occurred. Readiness evidence determines whether work is executable. Scheduling information indicates what is realistic under finite capacity. The release decision joins those information flows to an operating rule.

That distinction also separates automation from control. Automation asks whether the system can release a work order automatically. Control asks under what conditions the work order should be permitted to enter execution and which system outcome that rule is intended to protect. The second question is the more important one.

An automated release rule that admits unready or poorly prioritises work can simply accelerate congestion. This becomes especially relevant as ERP vendors position AI and agents around planning, maintenance and operational decision-making. Before an agent is permitted to release work, reprioritise activities or allocate scarce resources, the organisation needs to know what conditions the decision is supposed to regulate.

The problem is not whether the technology can perform the transaction. The problem is whether the enterprise has established a defensible causal basis for the action.

Productivity evidence arrives on different clocks

Another feature of the dry-dock case is delayed feedback. If release discipline improves today, the first evidence may be a reduction in prematurely released work orders. A reduction in WIP may follow. Queue behaviour and schedule stability may take longer to become visible. Work-order duration must accumulate across sufficient activity. Dock-duration evidence arrives only after a substantial portion of the event has been completed. The financial consequence arrives later again.

This delay can distort management behaviour. A readiness rule may be relaxed because a supervisor wants to keep labour occupied. More work is released. Utilisation improves immediately. The cost of the decision appears later as congestion, overtime, resource switching or an extended dock period. By the time the financial evidence is visible, the original release decision may no longer be organisationally connected to its consequence.

A serious productivity measurement system has to preserve that connection across time. Early tactical signals, diagnostic measures, benefit-driver evidence, operational KPIs and eventual financial performance need to be understood as different observations of the same causal hypothesis. Otherwise, the organisation will naturally gravitate toward the measures that arrive fastest, even when those measures encourage behaviour that damages the whole system.

The design should be tested, not defended

The causal model should never be treated as proof simply because it has been designed. It is a hypothesis about how the operating system works. If readiness control is strengthened, premature release should fall. If premature release falls but WIP remains unchanged, part of the reasoning may be wrong. If WIP falls but constrained-resource queues do not improve, another cause may dominate. If queues improve but dock duration does not move, the organisation has learned that the bottleneck lies elsewhere.

This is precisely why deeper measurement matters. The purpose is not merely to demonstrate that a transformation initiative was successful. It is to identify where the causal chain holds, where it weakens and where the operating design needs to be adapted.

Counterfactual questions then become useful rather than academic. What would likely have happened had the additional work been released. W/hat would dock congestion have looked like without the readiness intervention. Which control would we stop using if it did not materially contribute to the intended outcome?

From productivity reporting to productivity design

The dry-dock example exposes a broader enterprise problem. Productivity is frequently treated as something to measure after implementation. But if the organisation cannot explain the causal chain between an operating intervention and the expected productivity outcome, the measurement problem began before implementation.

The chain needs to be designed explicitly. The strategic intent may be to improve the economic utilisation and delivery reliability of the dry-dock operation. The operational benefit is shorter and more reliable dock duration. The relevant benefit drivers include execution stability, reduced waiting and lower congestion.

The control system regulates when work is allowed into execution. The behavioural change sought is less premature release, lower unnecessary WIP, fewer queues, less switching and less replanning. Signals and diagnostic metrics test whether those behaviours are changing. Work-order duration, dock duration and throughput establish whether the operating change propagated into productivity. Only later does the P&L record the economic result.

This does not diminish financial measurement. It gives financial measurement an operating explanation. It allows the enterprise to distinguish between a result that happened and a result it understands.

The transaction is simple. The decision is not.

A work-order release can be represented by a single status field in an enterprise application. But in a complex dry dock, that status change can alter the amount of work competing for scarce resources, the stability of the schedule, the volume of queues and WIP, the amount of replanning, and ultimately the duration and economics of the dock event.

That is the deeper productivity lesson. Enterprise productivity is not created by reporting more measures or automating more transactions. It is created when the organisation understands which operating behaviours need to change, establishes the controls capable of changing them, and preserves enough causal evidence to determine whether the expected outcome actually followed.

The work order is the transaction. The productivity mechanism sits behind the decision to release it.

What's Behind the Arrow?™  The dry-dock case makes the question operational. The arrow from readiness control to lower dock duration contains the assumptions, controls and evidence that determine whether an ERP intervention actually creates productivity.