Lean is about creating a performance mindset, being aware of problems, and having problems solved locally as a way to develop people through problem-solving and fostering a “kaizen spirit”.
If one frames Lean that way, it seems hardly possible to practice it in any modern firm without getting across information technology questions: most of the work load nowadays is achieved using information systems (from emails to forms-filling); we use IT to report data, calculate indicators and analyze performance; alerts are often generated by sensors, sent through networks and treated by computers; amounts of data that can be used to analyze problems are stored in servers.
Nevertheless, the “IT pledge of productivity” is about standardizing activity through interface and global rules; global and instant deployment of improvements; light-fast circulation of information; availability of scores of data… And all this is very different from the “Lean pledge of productivity”.
Therefore, and empirical data support that, it seems that IT and Lean often ignore one another — Lean Sensei treat IT as a “Black Box”; IT Gurus look upon Lean as a soft management technique which they don’t have to bother with. Sometimes, IT and Lean collide and things get ugly. Rarely, Lean and IT people try and talk, as seems to be more and more the case with “Agile Development”. But this remains scarce and tentative.
How could this change ? Is there a “Lean Way” to look at one firm’s IT, and to make it change? What would be the first steps in such a journey?
Art Smalley Response:
It is indeed a shame that there is such a gulf between the Lean world and information technology (IT) systems. On one side (the lean group) a vocal segment has implied that the only answer is to unplug computers and do things entirely manually. Manual kanban cards, manual movement of material and information, and other extreme measures.
On the other side (big ERP) the players have often shot themselves in the foot by viewing IT departments as the end customer and delivering “solutions” that did not solve fundamental problems and cost a fortune and were often inflexible to boot. (Yes I am engaging in vicious stereotypes for the sake of discussion.)
From an ex-Toyota point of view I can only shake my head get a little frustrated by the whole situation. Here is a series of images from a video made over 20 years ago…it shows part of a typical Toyota final assembly to supplier information flow (the rest I’ll provide in a link to for interested viewers). I’ll try and highlight how Toyota integrated IT into their supplier pull system over 20 years ago for consideration.
1. On a visit to final assembly you’d see employees pulling a kanban card upon usage of first item from a container. IT was involved in the creation of this card though and it contains bar coded information.
2. After some time the kanban cards would be collected on a time basis. IT was in the background as an automated information signal from the Andon board signaled that it was time to collect these cards.
3. The collected kanban cards were fed into an automatic sorting machine that read the card information relieved it from inventory (at least in some cases). Other times the car exiting the line “backflushed” inventory at that final transaction point…
4. The scanned information also was used to trigger payment to the correct supplier. Scanning was evidence of usage.
5. The information for consumed parts was tabulated by the computer system and evaluated by Production Control.
6. The information for consumed parts triggered confirmation of demand and transfer of information to a supplier. This printer is located in a supplier facility and is printing out the supplier kanban i.e. authorization to make another set of parts.
7. The new kanban was put into a Heijunka box for scheduling purposes at the supplier and replenishment of the material commenced for shipment to Toyota.
There is more to the loop both before and after that you can view by clicking here. The interesting part of this flow is that many observers only focus on the initial paper kanban and the manual heijunka board. The interesting stuff in the middle is often skipped or assumed to be manual. This is Toyota’s process from over 20 years ago…today it is even more automated and advanced in terms of integration with IT.
I have no answers or great insights to the question posed, only frustrations. Why indeed is the Lean world so IT phobic in general? Why is the world of big ERP so slow to “go to genba” and “get the facts”? The order of logic in TPS has always been to 1) eliminate unnecessary steps or details that do not add value to the customer, 2) combine steps or operations when step one can not be achieved, 3) rearrange things for improvement when one and two are not feasible, and 4) simplify the process if and when items one through three can not be accomplished. Standardization and synchronization are thrown in for good measure some times. There is no reason why IT can not be part of the solution and play a role in this improvement process.