From Spreadsheet to Delivery Control

How AI helped a growing manufacturer strengthen production scheduling without waiting for ERP

The company was a growing garment manufacturer in Asia, exporting small-batch, higher-quality apparel to customers in Australia and Europe. Delivery reliability mattered. Customers expected the right garments, in the right quantity, on the agreed date, and to the required standard.

The earlier DIFOT-Q review had shown that the business was working hard but not always delivering reliably. Customers were chasing. Some shipments were late. Some were short. Production plans were moving constantly. Orders were being pushed back, but others were being pulled forward to fill production gaps.

That finding changed the management question.

The issue was no longer simply how to report delivery performance. The more urgent question was how to create practical control around customer commitments, production priorities, schedule changes, accountability and escalation.

A full ERP/MRP? system was the obvious theoretical answer. It could have provided an integrated order book, workflow, audit trails, planning visibility and reporting. But theory and timing are not the same thing.

The company was already stretched. Volume was increasing. Overtime had become normal. Merchandisers, planners and production managers were dealing with live pressure every day. The same people needed to stabilise the operation would also have been needed to specify, test, train and implement any new system.

A large system project would have competed for scarce management attention at exactly the wrong moment.

The more practical first move was to improve the tool the business already used.

That tool was Excel.

Excel was not the problem

Production planning was already being run through a spreadsheet. Staff understood it. Managers recognised it. It was part of the daily operating language of the factory.

The weakness was that Excel was being used without the right controls.

The workbook held important information, but it did not properly govern how that information was created, changed or protected. Dates could be overwritten. Production targets could be revised. Different sheets could be edited independently, creating inconsistency between the order book, the production plan and the reported position.

A change in one place did not necessarily create a reliable change everywhere else.

That made the workbook useful, but dangerous. It contained the operating plan, but it did not yet behave like a management control system.

The irregularity that changed the design

One weakness became visible only when two planning files were compared several months apart.

Production targets had been revised in line with actual delivery. On paper, performance could appear to have been achieved because the target had moved toward the result.

That was a serious control issue.

An initial delivery target should be a commitment. It should tell the business what the customer expects and what the factory has agreed to achieve. If that target can be changed after the event, the company loses the ability to distinguish real performance from retrospective adjustment.

The problem became more serious because production performance bonuses were linked to those measures. That made the control weakness more than a planning issue. It affected the integrity of performance reporting and reward.

This did not require speculation about motive. The control problem was visible from the evidence. The target had moved. The actual result had not. Once a target can be adjusted to fit the result, the scoreboard is no longer independent of the game.

That discovery shaped the design of the new system.

The purpose was not to make the spreadsheet look better. The purpose was to make the spreadsheet governable.

Turning the workbook into a control system

The solution started with a simple principle: one source of truth.

The Order Register became the master record. Other views were fed from it. The Dashboard, cashflow forecast, production plan and rephase logic all drew from the same controlled data.

That changed the nature of the workbook. It was no longer a collection of linked sheets maintained by memory and discipline. It became an operating tool.

The Dashboard gave management a live view of the order book, late delivery risk, unscheduled work, capacity and financial exposure.

From spreadsheet to management dashboard

 

The production dashboard turned the workbook into a management view, showing active orders, late delivery risk, unscheduled work, capacity and financial exposure in one place

The second principle was controlled entry.

Users could no longer type freely into critical cells. A new order would be added through a form. An existing order would be edited through a form. Quantity changes would require a reason. Production dates would be protected from casual editing. Schedule changes would be made through a dedicated Rephase Engine.

This was important because the earlier review had shown the plan was moving too much. The new workbook did not try to prevent all movement, that would have been unrealistic. Garment manufacturing always changes, materials arrive late, customers revise priorities, quality problems appear, and production capacity shifts.

The point was not to stop change, it was to make change visible, controlled and accountable.

Where AI changed the economics

In a conventional project, adding proper buttons, forms, validations, audit logs, dashboard refreshes and schedule-control logic to Excel would usually require specialist VBA development, a detailed specification and repeated technical testing.

Here, AI changed the economics of the solution.

AI was used to develop the VBA code behind the buttons, user forms, rephase process, disruption log, audit trail and dashboard refresh routines. The project used Excel because the business already understood it. AI made it practical to put governance inside Excel quickly and at minimal cost.

That distinction is important.

AI was not used to replace management judgement. It was used to make management rules enforceable inside a familiar tool.

The system could require a reason for a quantity change. It could keep production dates read-only in the normal edit formand could force schedule changes through the Rephase Engine. It could record who changed what and when. It could flag late delivery risk automatically. It could escalate high-value disruptions without relying on someone to decide whether the issue was important enough to report.

The value was better management control inside the tool people were already using every day.

The Rephase Engine

The Rephase Engine became the heart of schedule control.

Previously, a planner could change dates manually across different parts of the workbook. That created risk. One sheet might change while another did not. The Dashboard might not update correctly. The reason for movement might be lost. A target could shift without leaving a clear trail.

The new process was different.

The planner entered the new production start date and daily output target in one place. The system recalculated finish dates, updated the Order Register, rebuilt the production plan and refreshed the Dashboard.

One controlled action replaced multiple manual edits.

The Rephase Engine – controlling schedule change

Schedule changes were moved out of free-typing cells and into a controlled process. The planner entered the revised production date and output assumptions once, the system updated the plan, dashboard and audit trail.

The system also introduced freeze zones. Orders close to production required higher approval before they could be moved. This gave management a practical way to protect near-term customer promises. The closer an order was to production, the more discipline required before the plan could change.

Schedule flexibility remained available, but it became governed.

Making disruption visible

The Disruption Log addressed another weakness from the earlier DIFOT review.

Previously, the reason for plan movement could disappear into email, memory or conversation. A merchandiser might know why an order had moved. A planner might know which style had replaced it. Production might only see the revised sequence. Senior management might see the issue only when the customer complained.

The new system required disruption events to be recorded in a structured way.

The log captured the date, customer, style, root cause, supplier where relevant, days slipped, revenue impact, action taken and status. High-value events could be escalated automatically. The person logging the event was captured from the Windows username, creating accountability without relying on manual self-reporting.

A missed shipment was no longer just something to explain after the fact. Late delivery risk could appear on the Dashboard while action was still possible. Unscheduled confirmed orders could be seen. Schedule changes could be traced. Disruptions could be reviewed by cause and value.

Management could begin to see whether the problem was supplier delay, fabric quality, line stoppage, sample failure, capacity conflict, customer change or internal execution.

The spreadsheet had begun to show not only what was happening, but why it was happening.

A practical bridge to ERP

The result was a practical bridge between spreadsheet chaos and full enterprise systems.

The company did not have to wait for ERP to begin improving control. It could start by governing the spreadsheet that already sat at the centre of daily work.

That is an important lesson for growing manufacturers.

A spreadsheet that allows free typing into critical cells is a data container. A spreadsheet with controlled forms, locked structures, audit trails, rephase logic, automatic escalation and live management reporting becomes something different.

It becomes a management control system and the difference lies in governance.

The new workbook had rules. It had workflow. It had accountability. It had protected fields. It had escalation logic. It had a single source of truth. Most importantly, it had an opinion  about how production planning should be managed.

It did not solve every production problem. No spreadsheet can do that. But it gave management a working control mechanism at the point where one was urgently needed.

Project takeaways

The project showed that Excel was not the problem. Uncontrolled Excel was. The workbook already carried the operating rhythm of the factory, but it did not provide enough protection around customer promises, production dates, schedule changes and management reporting.

A delivery target must be a commitment, not a number that moves after the event. When targets can be revised toward actual results, performance measurement loses credibility. If bonuses depend on those measures, the control weakness becomes much more serious.

The first step did not need to be ERP. A full system may have been the right long-term direction, but the immediate need was stronger control inside the tool the business already used and understood.

AI changed the economics of improvement. It made it practical to add forms, workflow, audit trails, rephase logic, escalation and dashboard reporting to an existing spreadsheet without waiting for a large software project implementation.

The spreadsheet became a management control system when it gained rules. Critical dates were protected, schedule changes were governed, disruption causes were captured, and late delivery risk became visible before failure reached the customer.

The central takeaway was that digital transformation does not always begin by replacing the tools people use. Sometimes it begins by controlling them properly.