The parallel-running trap

Two years in, and both processes are running

By the end of its second year Bezirhan had a working digital process. Blocks documented, fabrics characterised, a written agreement with one buyer, a trained technician and a second one coming. The slide that went to the owner said 83.8%, the share of the year's styles built in the 3D system: 119 of 142.

Here is the rest of that year. Virtual rounds made: 214. Physical sample rounds shipped: 468, against a baseline of 483.

Fifteen rounds came off in a year. That is 3.1%.

The cost, and why it is a run rate rather than a transition cost

That is USD 90.67 a style, every style, and the licence line sits on top of it and repeats too. But the number is not the point. The point is that it does not decay.

A transition cost is a hump. It is large, it is unpleasant, and it ends. What Bezirhan had built was not a hump. It was a second process running permanently alongside the first, at full cost, producing an output that nothing depended on. Year three would cost the same, and year four, until something changed. Nothing in the programme was designed to change it, because nobody had ever written down a date on which the first process would stop.

Nobody ever decided to run both

This is the part worth sitting with. It is not a failure of discipline, and it will happen to a well-run factory. Bezirhan did not decide to run two processes. It made 468 individual decisions, and every single one of them was correct.

Read that table as an argument rather than as data. Not one of those five is a bad reason. A merchandiser who wants a real garment on the table when a buyer visits is right. A line manager who wants to see a difficult jacket before committing a size set is right. And that is exactly the trap. A style always has a reason, so retirement can never be decided style by style. Decided one at a time, the answer is always "this one, physically, just to be safe". A year of individually correct answers adds up to a second process nobody chose.

The second cost, which is worse than the money

If a physical round follows anyway, the virtual verdict carries nothing. Nobody's decision rests on it, so nobody is accountable for it, so nobody argues with it, so it never gets better. And because it never gets better, stopping the physical round never feels safe.

Parallel running removes exactly the pressure that would end it. That is why it persists in factories with good people and good software, and why time alone does not cure it.

Bezirhan can show this with its own numbers. In year two, 214 virtual rounds produced 31 recorded comments that changed a pattern, which is 14.5%. In the six months after the physical proto was retired, 118 virtual rounds produced 96, which is 81.4%. Same technician, same software, same buyer. What changed is that somebody's decision now rested on the file, so people read it properly.

The rule that ended it, and what it bought

The rule fits in two sentences. For any style meeting the four eligibility conditions of lesson 4, with a buyer on the agreed list, the physical proto is not made. An exception requires the technical manager's signature and is counted in a monthly figure that goes to the owner.

The counting is the mechanism, not the signature. Exceptions ran at 41 in the first month and 12 in the sixth, and nobody was ever refused one. Physical rounds fell from 468 to 331 over those six months.

That is a swing of USD 25,444.25 between year two and year three, and not one hour of it came from the software. It came from a dated rule, and from a library that had grown big enough for most rounds to run on a block that already existed. Which is why lesson 2's pilot choice and this lesson's retirement date are the same decision seen twice.

Act as a finance-literate operations director who has seen a digital programme become a permanent second process. Price what I am running today and propose the rule that ends it. My baseline year before any of this: [STYLES DEVELOPED], [PHYSICAL SAMPLE ROUNDS SHIPPED], [COST OF ONE PHYSICAL ROUND, BUILT UP FROM PATTERN, CUTTING, SEWING, FABRIC, TRIMS, FINISHING, COURIER AND COORDINATION], [ELAPSED DAYS OF ONE ROUND AND HOW MANY OF THOSE DAYS OVERLAP WORK THAT CONTINUES ANYWAY]. This year: [STYLES DEVELOPED], [VIRTUAL ROUNDS MADE], [PHYSICAL ROUNDS SHIPPED], [HOURS PER VIRTUAL ROUND ON A CARRY-OVER BLOCK AND ON A NEW ONE], [LOADED HOURLY RATE], [SHARE OF STYLES BUILT IN THE 3D SYSTEM]. For every physical round still shipped, the reason: [BUYER NOT COVERED BY AN AGREEMENT / FABRIC NOT CHARACTERISED / BLOCK NEW OR UNDOCUMENTED / CUSTOMER VISIT / THE LINE WANTED TO SEE IT / OTHER, WITH COUNTS]. Do the following. First, compute the net cost of running both this year, as an annual run rate rather than a project cost. Say plainly that it repeats until a date is set. Second, express it per style. Third, take my reason table and tell me which reasons a dated rule can remove, and which are genuine blockers that belong on a worklist. Fourth, draft the retirement rule in two sentences: the conditions under which the physical round is not made, and the exception route, which must be granted freely and counted monthly. Fifth, project next year on that rule. Remember that rounds on carry-over blocks are cheaper than rounds on new ones. Sixth, tell me which of my current reports would go down if the rule worked, and warn me about any report that cannot go down at all.

What to take away

1. Adoption can be high while nothing has been retired. Bezirhan was at 83.8% adoption and 3.1% of rounds removed.
2. Running both is a run rate, not a transition cost. It repeats every year, at full cost, until a date ends it.
3. Nobody decides to run both. A year of individually correct exceptions adds up to it.
4. The trap keeps itself alive: an output nothing depends on is never improved, so retiring the old round never feels safe.
5. Retire by rule and by date, with an exception route that is counted. The count does the work, not the refusal.
6. Bezirhan's swing from year two to year three was USD 25,444.25, and none of it came from the software.