The operating controls every product business needs before scale

Control should answer a simple question

At any point, leadership should be able to determine:

What should be happening?

What is actually happening?

Where is there a difference?

Who is responsible for doing something about it?

Most operating controls exist to answer one or more of those questions.

A production plan establishes what should be built.

Production reporting shows what actually happened.

A variance identifies the difference.

An owner resolves it.

The same principle applies to finance, hiring, quality, supply chain and product development.

Without that mechanism, management relies on anecdote.

Somebody says production is "roughly on plan."

Another person says a supplier is "a bit late."

A project is "nearly finished."

Costs are "about where we expected."

Those descriptions may be acceptable when five people sit around the same table.

They become dangerous when substantial capital and customer commitments are involved.

Start with ownership

The simplest operational control is clear accountability.

Every significant business process needs an owner.

Not everybody involved in the process.

The person accountable for its performance.

This is particularly important for activities that cross functional boundaries.

For example:

Who owns product cost?

Engineering influences it.

Procurement negotiates it.

Manufacturing adds conversion cost.

Quality affects scrap.

Logistics affects landed cost.

Finance reports the result.

But somebody still needs to be accountable for improving it.

The same applies to launch readiness, supplier performance, inventory, customer delivery and capacity.

When ownership is unclear, issues move horizontally around the organisation.

Everybody participates.

Nobody resolves them.

Build one version of the operating plan

Growing businesses often have multiple versions of reality.

Sales has a forecast.

Finance has another.

Manufacturing has a production plan.

Procurement has purchase orders based on something else.

Hiring assumptions sit in a board model.

Engineering has its own roadmap.

Each may be internally reasonable.

The problem is that the company is not operating from one plan.

A scalable organisation needs a mechanism that connects demand, resources and execution.

In many companies this becomes some form of Sales and Operations Planning, although the label matters less than the principle.

The business should regularly reconcile:

customer demand,

revenue,

production,

inventory,

material,

capacity,

people,

cash,

and major constraints.

The output should be an agreed operating plan rather than several departmental forecasts.

Control demand before it reaches the factory

One of the easiest ways to destabilise a product company is to allow commercial demand to flow directly into operational commitments.

A salesperson believes an order may arrive.

Procurement buys material.

The order slips.

Inventory increases.

Or the opposite happens.

Sales wins a major order.

Nobody has translated it into material demand.

Operations discovers that a critical component has a six-month lead time.

The customer has been promised delivery in twelve weeks.

The business therefore needs a controlled demand signal.

That does not mean refusing to act until every customer order is contractually guaranteed.

It means distinguishing between:

pipeline,

forecast,

committed demand,

customer orders,

and authorised production.

Those categories should trigger different levels of operational commitment.

Control purchasing authority

Growing companies can spend money surprisingly quickly.

A few engineers buying components.

Operations ordering equipment.

Marketing engaging agencies.

Managers hiring contractors.

Teams subscribing to software.

Individually, each decision may look insignificant.

Collectively, spending can move a long way from plan.

A basic purchasing control should establish:

who can commit company funds,

at what value,

against which budget,

under what approval,

and through what purchasing process.

The purpose is not to make people obtain three signatures for a £50 cable.

Controls should be proportionate.

The objective is to ensure that material financial commitments are visible before the company becomes legally or commercially committed to them.

Control the BOM

For a product company, the Bill of Materials is not merely an engineering list.

It connects engineering, supply chain, manufacturing, quality, service and finance.

If different functions are working from different versions, almost everything downstream can go wrong.

The company therefore needs a controlled BOM.

That means knowing:

what the current released version is,

who can change it,

when a change becomes effective,

which products contain which revision,

which supplier parts are approved,

and what happens to existing inventory when something changes.

This becomes increasingly important as production volumes rise.

Changing a £3 component may sound trivial.

If 50,000 of the previous component have already been purchased, the decision is no longer trivial.

Control engineering change

Engineering change is one of the areas where growing hardware businesses can lose significant amounts of money without realising it.

A component changes.

A drawing changes.

Firmware changes.

A supplier changes.

Packaging changes.

The engineering change itself may be correct.

The operational consequences may not have been considered.

What inventory becomes obsolete?

Does manufacturing know?

Does the test procedure change?

Does regulatory evidence remain valid?

Do field units need updating?

Does the customer documentation change?

Does the contract manufacturer have the new data?

When does the change take effect?

A proper change-control process forces those questions to be answered before implementation.

It should not prevent change.

It should make the consequences visible.

Control suppliers through performance, not relationships

Early-stage businesses often manage suppliers primarily through personal relationships.

That is useful.

It is not sufficient.

As spend and dependency increase, supplier performance needs to become visible.

A simple supplier scorecard might monitor:

delivery,

quality,

cost,

responsiveness,

capacity,

and corrective-action performance.

The exact metrics depend on the supplier.

What matters is that supplier decisions are based on evidence.

If a supplier is repeatedly late, leadership should know.

If quality is deteriorating, it should be visible.

If one supplier represents 70 percent of a critical category, the dependency should be understood.

Supplier management should move from:

"we have a good relationship with them"

to:

"we understand how well they perform and what risk they create."

Control inventory

Inventory is one of the largest hidden areas of operating risk in product companies.

Too little inventory creates shortages.

Too much consumes cash and creates obsolescence.

The organisation needs visibility of:

raw material,

work in progress,

finished goods,

quarantine stock,

obsolete stock,

consignment stock,

and material held by contract manufacturers where appropriate.

It should also understand why inventory exists.

Is it required to support lead time?

Protect against supply risk?

Support minimum order quantities?

Cover forecast demand?

Or has nobody challenged it?

Inventory should be an operational decision, not simply an accounting result.

Control quality at the process level

Quality problems become expensive when control depends entirely on final inspection.

The stronger approach is to control the processes that create the product.

That means identifying where defects can be introduced and deciding how those risks are controlled.

The mechanisms may include:

incoming inspection,

work instructions,

process checks,

fixture controls,

automated tests,

operator training,

traceability,

calibration,

first-article inspection,

sampling,

and final test.

The exact system depends on the product and risk.

The principle is universal:

prevent and detect problems as close as possible to the point where they are created.

Control non-conformance

Every manufacturing organisation produces something that does not conform eventually.

The important question is what happens next.

A basic non-conformance system should identify:

what failed,

where it failed,

what product is affected,

whether other units may be affected,

what immediate disposition is required,

who is investigating,

and whether corrective action is necessary.

Without this, companies repeatedly fix individual problems while allowing the underlying cause to remain.

The same defect appears again.

Then again.

Eventually it reaches a customer.

A controlled non-conformance process converts defects into organisational learning.

Control production through a small number of useful metrics

Operations teams can produce enormous dashboards.

Most are unnecessary.

The purpose of production metrics is to tell management whether the manufacturing system is healthy.

For many product businesses, a small number of indicators provide most of the value.

Examples include:

output versus plan,

first-pass yield,

schedule adherence,

cycle time,

supplier on-time delivery,

quality escapes,

scrap,

rework,

and inventory availability.

The most important metrics should have targets.

They should also have owners.

A KPI without an owner is simply an observation.

Control delivery promises

Customer delivery dates should not be created independently of operational capability.

This sounds obvious.

It happens constantly.

Commercial teams want to win the order.

Customers want certainty.

Operations is asked whether a date is possible.

"Probably" becomes "confirmed."

Then production discovers that material is late.

A mature business needs a clear mechanism for confirming delivery.

That may involve available-to-promise logic, capacity review, material checks or formal order acceptance depending on the business.

What matters is that the customer commitment represents something the organisation has actually assessed.

The cost of missing a delivery can be substantially greater than the revenue benefit of accepting an unrealistic date.

Control cash alongside profit

Growing companies often focus heavily on the P&L.

Product businesses need equal attention on cash.

A company can be profitable on paper and still consume substantial amounts of cash because it is buying inventory ahead of revenue.

Operating controls should therefore make cash consequences visible.

For example:

How much material is committed?

How much has been paid?

How much inventory is held?

When will finished product ship?

When will the customer pay?

What purchase commitments exist against forecast rather than orders?

These questions become critical during rapid growth.

Revenue growth can increase cash consumption rather than reduce it.

Control product release

There should be a defined point at which a product becomes authorised for production or customer release.

Before that point, the company should know what evidence is required.

Depending on the product, this could include:

design completion,

validation,

manufacturing readiness,

regulatory approval,

production test validation,

quality documentation,

supplier approval,

packaging validation,

service readiness,

and commercial documentation.

A release gate protects the organisation from allowing schedule pressure to quietly become product approval.

Dates are important.

Evidence is more important.

Control software and firmware configuration

Modern hardware businesses are increasingly software businesses as well.

A physical product may be perfectly manufactured but still fail because it contains the wrong firmware.

Configuration control therefore needs to include software.

The organisation should know:

which software version is approved,

which hardware versions it supports,

which version each shipped product contains,

how updates are released,

and how rollback is handled if something goes wrong.

This becomes particularly important when customers operate different generations of hardware.

Without configuration control, support teams can spend enormous amounts of time trying to understand what is actually installed.

Control risk before it becomes an issue

Risk registers are often criticised because many are badly used.

A long spreadsheet reviewed once per quarter has limited value.

The useful control is the management conversation around material risk.

What could prevent us delivering the plan?

How likely is it?

What would the impact be?

What are we doing about it?

Who owns it?

When do we need to make a decision?

The best risk management processes concentrate leadership attention on a relatively small number of risks that could genuinely change company outcomes.

Control meetings themselves

Meetings are part of the operating system.

Poorly designed meetings consume time without creating decisions.

A good operating cadence should distinguish between different purposes.

For example:

daily operational issues,

weekly execution review,

monthly operating performance,

quarterly strategic review.

Each should have a clear purpose.

The agenda should be driven by decisions, exceptions and actions rather than presentations.

Data should ideally be available before the meeting.

The meeting should concentrate on what management needs to do about it.

A useful test is simple:

What changes because this meeting exists?

If the answer is unclear, the meeting probably does not need to exist.

Escalation is an operating control

Companies often depend on escalation while simultaneously failing to define it.

Teams need to know when a problem should move upward.

For example:

a delivery is at risk,

a supplier slips beyond a threshold,

a quality problem may affect customers,

spending exceeds approval limits,

a project misses a critical milestone,

or inventory falls below a defined level.

Escalation should not mean failure.

It is a mechanism for bringing the right level of authority to a problem before it becomes larger.

The worst operating environments are often those where people hide bad news because they believe management does not want to hear it.

Controls should scale with risk

Not every process deserves the same level of control.

A £500 purchase does not need the same approval structure as a £500,000 tooling commitment.

A spelling correction in a user guide does not necessarily need the same review as a safety-critical design change.

Good operating systems apply control proportionate to risk.

That means understanding:

financial impact,

customer impact,

regulatory impact,

quality impact,

schedule impact,

and reversibility.

The higher the potential consequence, the stronger the control should generally be.

Avoid building bureaucracy

There is a legitimate risk of going too far.

Process can become self-perpetuating.

Forms appear because somebody once made a mistake.

Approvals accumulate.

Nobody remembers why a report exists.

The company begins measuring activity rather than performance.

The solution is not to avoid control.

It is to regularly challenge the control itself.

What risk does this process manage?

What decision does this information support?

What happens if we remove it?

Can the same control be automated?

Can approval be delegated?

Does the process still reflect the current scale of the business?

Operational maturity includes removing controls that no longer create value.

The minimum control system before serious scale

Before a product business begins scaling materially, leadership should at least have clear mechanisms for:

• Demand planning
• Budget and spending authority
• Purchasing
• BOM control
• Engineering change
• Supplier approval
• Supplier performance
• Inventory
• Production planning
• Quality
• Non-conformance
• Product release
• Configuration
• Customer delivery
• Cash commitments
• Risk
• Management reporting
• Escalation

They do not all need sophisticated software.

A well-designed spreadsheet can be more effective than an expensive system used badly.

The process comes first.

Systems become important as transaction volume and complexity increase.

Good control actually increases speed

It may seem counterintuitive, but well-designed controls make organisations faster.

People know who can decide.

They know which version is current.

They know what has been approved.

They know whether money is available.

They know when something needs escalation.

They know what information leadership requires.

Decisions stop being repeatedly reopened.

Problems become visible earlier.

The organisation spends less time reconciling conflicting information.

That is the real objective.

Operational control is not about preventing people from making decisions.

It is about allowing more decisions to be made confidently without the CEO needing to be involved in every one.

Scale exposes whatever is weak

At low volume, strong people can compensate for weak systems.

At high volume, the system wins.

An unclear process becomes hundreds of inconsistent transactions.

A weak supplier becomes repeated shortages.

Poor configuration control becomes products in the field that nobody can identify properly.

Loose purchasing creates millions of pounds of commitments.

An informal quality process creates customer failures.

Scale does not usually create these problems.

It exposes and multiplies problems that already existed.

The purpose of operating controls is to deal with them while they are still small.

Because a scalable business is not one with the most processes.

It is one where leadership has sufficient control to grow without needing to personally control everything.