» » next post - Art Smalley: Sample Toyota Kanban Flow to Supplier
« « previous post - Lean Summit 2010 – 2nd & 3rd November
Jeff Liker

Dan Jones: Optimising end-to-end flows rather than keeping separately managed assets busy means overturning many of the assumptions on which today’s MRP and ERP systems are built

By Jeff Liker, - Last updated: jeudi, septembre 23, 2010 - Save & Share - Leave a comment

There are many ways to answer this question. IT systems reflect three things. First the way management thinks about setting priorities, controlling operations, problem solving etc. Second the way at least the bigger systems are sold – like construction, you bid low and promise novel features to get the contract and then make money on the changes, so they are over budget and late. Third, the belief that the only way to control complex systems is to model and simulate them in order to control every action and make sure every asset is fully utilized from the centre.

Lean thinkers approach each of these from a different perspective. As management recognises the potential for optimising the end-to-end flows of value creation rather than keeping individual activities busy and as they see how essential it is to engage front line management to respond immediately to the many interruptions to this flow as steps become more interdependent they realise that their IT systems, designed for a different purpose, are actually the hardest, slowest and most expensive things to change!

Moving from batch ordering to continuous replenishment at Tesco more than a decade ago took years after all the operational pieces were ready and by building their system based on large batch reorder quantities WalMart could not follow Tesco in using their systems to supply smaller convenience stores at little extra cost (although they are now doing so a decade later).

Today many CEOs biggest concerns are how to improve the productivity and responsiveness of the huge legacy of several thousand support staff round the world (more than in many of their key operations combined) to keep their big central systems running. It is shocking to discover that making a simple change to their systems can take up to a year; operations staff spends huge amounts of their time feeding the system with data and complain that it is the biggest obstacle to responding quickly to their competitors.

Lean thinkers and Agile software folk, whose perspectives are very similar, have a lot of experience in mapping the work flows to design new software, upgrades and system maintenance to eliminate delays and co-locate steps. They also know how to improve the flow of work through shared resources by for instance spending more time firming up the specification and only then working on the project in a tight, synchronised sequence with minimum changeovers and handoffs.  Pushing more work through this shared resource simply delays everything else, unless such action is taken. Ironically they also know that managing this flow of projects visually, rather than hidden on computers, is the most effective way of changing behaviour and gaining agreement on what needs to be done as well as responding quickly to glitches and delays rather than waiting until the next gate review meeting.

The good news is that many IT and service delivery organisations like Banks, Utilities and telecoms are beginning to rethink their customer and technical support activities back from the problem solving dialogue with the customer and around the escalation process to those who can solve them. The boldest of these are in fact building new internal operating systems, designing all the management and technical roles around the support needed to enable the front-line work to flow smoothly. In doing so they are turning these big expensive assets into really customer focused problem solving support activities. (Some of these stories will be told at our next Lean Summit).

I sometimes hear IT folks say they lead all the changes in an organisation. Lean operations folks would beg to differ – and would first do a lot of work simplifying and streamlining the main value creating work flows before automating them. They would go further in showing that optimising end-to-end flows rather than keeping separately managed assets busy also means overturning many of the assumptions on which today’s MRP and ERP systems are built. Ian Glenday in Breaking Through to Flow shows how even in process industries bigger batches are not better and trying to continually adjust both the inventories and production schedules simply causes chaos. Indeed lean thinkers would use these systems for planning capacity, but not for scheduling every batch or shipment. High volume product flows with little variation require much simpler and different planning than the long tail of slower moving products. Actually it turns out that some of these principles also apply to organising the flows of work to upgrade and manage IT systems.

Post to Twitter

Share this post...Tweet about this on Twitter
Share on LinkedIn
Buffer this page
Share on Facebook
Email this to someone
Pin on Pinterest
Share on Tumblr
Posted in Uncategorized • Tags: , , , , , , , , , , , , , , , , , Top Of Page

Write a comment