Dans la lignée de notre précédent article sur le point de vue de Jeff Liker, voici le point de vue de Michael Ballé, Chercheur Associé à l’Ecole Nationale Supérieure des Télécommunications, sur le Lean Management et les Systèmes d’Informations.
Voici sa réponse à la question « Is there a ‘Lean Way’ to look at one firm’s IT? Can IT be made to change towards lean? What would be the first steps in such a journey? »
Son analyse concerne surtout les travers que peut induire un SI trop rigide dans un processus de production industriel :
I recently visited an aeronautics factory (low volumes, high diversity), trying to demonstrate what we mean by a “gemba walk”. I didn’t have much success because as I walked the plant with the CEO, I’d point at piles of parts asking “why is this here?” He’d shrug and ask someone who would answer: “it’s in the computer.” “Why are we working on these parts now? Is this something the customer needs right now or are we filling up a stock?” “It’s in the computer.” “What is today’s on-time-in-full delivery rate?” “I don’t right know, but I’m sure it has to be somewhere in the computer – someone will pull out that figure, surely.” It was fun at first, but then it got to be ridiculous.
After a while, I asked: “how do we explain to the computer that some of its decisions create the waste we see?” – of course, they looked at me strangely. But that is the fundamental question. If it’s all in the computer, how do we get the computer to learn? IT systems have spread through companies to the point that we can hardly do anything without a computer. Not a bad thing in itself, except when we delegate all our thinking to the software itself.
On this shop, nobody had any idea of why they did this or that – they followed the orders in the system. Why would they want to kaizen? Why would they even challenge what they were told? Software is great when it’s liberating – when it handles repetitive, boring tasks that you can now do yourself without having anyone do for you, whether spellchecking letters, running your diary or making complex calculations. On the other hand, if the computer is used as a soviet central planning tool, then the system becomes a powerful rigidifying force.
There’s just as much call and need for IT systems in lean as in anything else, but my experience tends to a different kind of system: not a central integrated does-it-all tool, but discreet systems to handled very specific functions, and systems which can be adapted locally. This is of course problematic from an IT point of view because it often poses many interface problems, as IT systems would not be necessarily upgraded systematically across the board (on need-to-upgrade basis) or compatible.
As long as we’re doing clever things with an excel spreadsheet, this is not so much of an issue, but the development of more complex software, such as, say, a leveling system for production planning across a supply chain, one hits upon the big box bias of most developers (and systems sellers).
My experience is that, in practice, we do what we can without involving the IT department, and way down the lean journey, at some point, we have unnecessary unpleasant conversations about what we’d really like – due to the fact no one has tried to involve them upfront. On the other hand trying to explain what a lean IT system should look like (in particular amenable to kaizen) is rather difficult without being able to demonstrate how the physical lean systems work.
As far as I’ve seen, this is stiff a vast, unexplored territory. Some lean thinkers have tried to reconcile the lean approach with existing IT, but rarely convincingly – especially on the kaizen front. Hopefully, as lean implementations grow more numerous, system designers will come up with innovative ways of looking at IT and offer a different sort of system – one where people and system are clearly independent of one another, and where the system supports what people try to do, not enslave or limit them.
source : http://theleanedge.org/?p=1514
