People talking about "Lean" principles can mislead their audience, because often "Lean" to the speaker means something very different (e.g. that "Lean" means holding kaizen improvement sessions, and that's it). So, take what I'm going to say with a bit of salt, because I have no Lean credentials. In reading about Lean manufacturing (through "Lean Thinking," "Getting the Right Things Done," and now "Learning to See"), I have been working through how Lean concepts might apply to an Information Technology environment. One of Lean manufacturing's focuses is to create pull-based processes that minimize inventory on-hand, for example. By minimizing inventory you free up cash for new things and can respond more quickly to changing demand. So--how does this relate to IT? Inventory, in a value-stream mapping, is the stuff waiting between groups. The two ITIL processes that seem to relate the best to the inventory concept are incident management and request fulfillment. Here's my thoughts: Incident management: Request originates from an end user. This request hits the Service Desk. The request may then be "pulled" upstream if the Service Desk needs to escalate the issue. Eventually the request gets resolved and the end user can work again. Request fulfillment: Essentially the same as incident management's process, just with a different trigger--the end user wants something, so they contact the Service Desk. The request is "pulled" upstream if escalated. Eventually resolved and the end user has whatever they requested. What might a "Lean" interpretation of these processes tell us? Incident management could focus on minimizing the backlog of tickets. This backlog if put on a value stream map looks A LOT like inventory--the "supplier" is just the support analyst's brain (and/or manuals, upstream vendor support, maybe problem management ??, etc). The same thing goes for request fulfillment--the backlog should be minimized, not batched, and the "supplier" could be the service catalog and/or service transition. Lean also has a strong bias against tools that are too complicated to use, especially shop-floor tools that require large batches. Maybe there's a mapping there to Service Desk tools that create unnecessary "waste" work. At the least, Lean might recommend changing your process if your organization had an account creation tool that only kicked off once a day. I'm actually wondering if it would be worth creating a Lean value-stream map for each broad type of incident that an IT shop receives. This could show where typical back-logs sit and help with reducing the delays when requests are reassigned. Why could this Lean interpretation be valuable? The fewer tickets in the backlog, the faster new requests can be handled. If you've got a big backlog, the stuff already in the queue is (if you're lucky) going to be handled first. The fewer tickets in the backlog, the more quickly you can respond to changing demand. For example if you've got 200 open service requests for listserves, and now Service Strategy has identified a new/more useful kind of group collaboration, you've got to re-analyze and/or handle all those listserv requests that are on back order. Other opportunities for a "Lean" interpretation of IT I would like to learn more about Lean manufacturing's approach to product development (e.g. how Toyota designs new cars). Their take there could map well to IT project management and/or change management. Additionally, Lean concepts like "poka-yoke" (error-proofing process steps) could improve the quality of incident and service request resolution. Lean also recommends looking at "takt time", or the amount of time each step in a process should take for a given number of units to be produced in a day. For example, if you plan to handle 800 tickets per day, and you work 8 hours, the takt time (for one group handling all those tickets) would be 100 seconds. This concept IMHO doesn't map as well, but maybe from looking at the research already done on Lean at hospitals I could better understand how to apply takt time. Individual site contributors are solely responsible for the content of this web site.
|
|||
Great thoughts
Wow, for a "not lean" guy you are off to a great start! May I recommend "The Toyota Product Development System" to you if you are interested in seeing how lean applies to product development. Very fascinating, although a good background in lean is suggested as the book lost me the first time I read it.
As far as lean IT goes, in my experience, lean fits in very well with IT. IT systems are really just automations of processes. If the processes are not customer-focused and efficient in design, then automation simply speeds up the pace at which errors are created.
Thus, the model I use is first simplify (using lean) then automate (using IT). The big gain here is, rather than automate a step, why not eliminate it, especially if it requires human interaction? This, in my opinion, is the big glaring flaw in the bulk of the electronic medical records systems in place today.
Error-proofing is critical. Takt time not so much because rarely is your computer processing power anywhere close to maxed out.