by the QRonos product team
This is part two of our ongoing series on BTRS (Business Timing and Release Schedule) tools and their impact on complex engineering programmes. Part one can be found here and explores three common forms of BTRS and the ‘hockey stick’ release curves prevalent in many programmes. This time we want to focus on impact BTRS can have – both good and bad – and touch on some reasons why otherwise good tools may not have the impact expected.
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 the below graph showing the planed ramp:
The green is the plan, the red what they actually achieved in a plant where every minute you stop the line costs tens of thousands of dollars. We wanted to investigate what was causing all these lost units, and digging into the data found the principle cause was late parts; 35 percent 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 eighty percent of lost units. The lesson? It’s not good enough to plan your programmes at a macro level; you need part-by-part level planning to find the critical path.
View CTO Nick Solly outline the impact of BTRS as part of his QRonos digital tool launch at PI PLMx.
The animation in the video above is pulled together from 200 different Excel spreadsheets tracking part data. The red dashed line is the original plan for releasing the parts, the red solid line is the updated plan as time goes by, and the green line is the actual curve achieved releasing the parts. You’ll see that classic hockey stick in the green compared to original concave plan. You may also notice the total number of parts released is actually about ten percent higher than the original plan, and again it comes back to early visibility and making sure your BoM quality is really good.
There was another problem when examining the steps needed to a get a part – a wishbone assembly in the above example – from concept to delivery; the BTRS being used only tracked the middle 14% of development tasks. Resultantly, slippages and issues happening up earlier didn’t become visible until you turned the BTRS on later, by which point the original slippage was causing lateness downstream.
This leads us to today’s conclusion: to provide maximum utility, BTRS needs to cover as wide a section of the part life cycle as possible and requires a whole organisation, not narrowly engineering approach to design, implement and maintain.