By the QRonos product team.
This is part of our ongoing series on BTRS (Business Timing and Release Schedule) tools and their impact on complex engineering programmes. Part one explored three common forms of BTRS and the hockey-stick release curves prevalent in many programmes. This time we focus on the impact BTRS can have — good and bad — and touch on some reasons otherwise-good tools don't deliver the impact expected.
35 percent of lost units
QR_ did a project last year with a global vehicle manufacturer, looking at one of their plants in the United States. They were ramping up some new vehicle programmes — with a significant gap between the planned ramp and what was actually being achieved, in a plant where every minute the line stops costs tens of thousands of dollars.
We investigated what was causing the lost units. The principal cause was late parts: 35% of lost units could be attributed to late parts. And even that doesn't tell the whole story — digging deeper, on one of those programmes the top seven late parts accounted for 80% of lost units.
The lesson? It's not good enough to plan your programmes at a macro level. You need part-by-part planning to find the critical path.
200 spreadsheets and a wishbone assembly
In a QRonos launch at PI PLMx, QR_ CTO Nick Solly outlined the impact of BTRS using an animation pulled together from 200 different Excel spreadsheets tracking part data. A red dashed line showed the original plan for releasing parts; a red solid line showed the plan as updated over time; a green line showed the actual curve achieved. Classic hockey stick in the green, compared to the original release plan.
You may also notice that the number of parts released is actually about 10% higher than the original plan — which comes back to early visibility and making sure your BoM quality is really good.
There was another problem when examining the steps needed to get a part — a wishbone assembly in that example — from concept to delivery: the BTRS being used only tracked the middle 14% of development tasks. As a result, slippages and issues happening earlier weren't becoming visible until BTRS turned on later, at which point the original slippage was causing downstream disruption.
Today's conclusion: to provide maximum utility, BTRS needs to cover as much of the part lifecycle as possible — and requires a whole-organisation approach to design, implement, and maintain. Not a narrowly engineering one.