University ITSM

I've discussed before how "Lean" principles could be applied to IT services. Lean.org has some texts about Lean as applied to services, and there is a LOT of material about Lean in Healthcare--but I haven't seen any material so far about Lean in IT specifically.

Recently I've been reading "Seeing the Whole," a book about getting upstream and downstream companies in your value stream to work together, which has gotten me thinking again about Lean. I've got three things on the mind:

1. request fulfillment seems like IT's "engine," the process by which IT provides much of its value.
2. defects are problems, and ITIL's service lifecycle could learn from Lean's "stopping the production line" when defects are found
3. you must have accountability for all your services

Request Fulfillment as IT's "engine"

Most Lean texts (that I've read) talk in terms of the products that a manufacturing company creates. I think the best equivalent to that for IT is request fulfillment. (There is certainly a lot of value in IT continuing to provide the service once it has been given to a user. Request fulfillment's creation of "new" value--services new to a particular user--seems the closest to Lean's concept of a production line.)

Request fulfillment is the process of users requesting and receiving services. For example a user might want a new listserv, or an account on a system. Depending on how the service was designed, the request might also go through access management too for access approval, but request fulfillment is the ITIL process that's providing "new" value.

In the past I have played down in my mind the complexity of request fulfillment: I think, "oh, it's just giving out a service--no big deal!" ITIL only calls for a couple of process steps--it sounds really easy. However, request fulfillment can be as complex as the production of a car. You could request a red car or a white car, same as you can request a public listserv or a private listserv. Some of the variations in an IT service might be complex, too, such as the various options available when allocating services to a new employee.

Assembly-line defects are problems

Lean says that the whole assembly line should stop when a defect is found or occurs. For example, if a staff member sees that the car door they are supposed to put on a car is scratched, they are supposed to pull a cord and stop everything. The purpose of stopping everything, in my limited understanding, is to ensure that no more car doors are produced with that defect.

There is no exact equivalent in IT, I don't think, except for maybe release management's testing process. I say that partly because it is unusual for IT staff to run into any incidents when deploying a service. However, there are some useful correlations between defects and (ITIL) problems. When testing does find a problem, work on the service should stop until it is clear where the problem came from. These problems might later cause dozens of incidents. Perhaps what I'm thinking here is that IT needs more proactive problem management occurring when new services are being developed.

Accountability

"Seeing the Whole" recommends against re-organizing staff around services, partly because there is not much payout for the investment. Whenever possible it also recommends that line managers own process improvement--when you have a disinterested third party performing the improvements they are much less likely to "stick." However, when spanning multiple organizations, "Seeing the Whole" recommends creating "product managers" at each company who can then work together to improve the process. Toyota has "product managers" who do not have staff reporting to them, but these people are respected as the people who make decisions about products. There is a Toyota Prius Product Manager, for example, who everyone acknowledges is the owner of decisions regarding the Toyota Prius product line.

I think the closest equivalent in ITIL's guidance is the "service owner." There has to be someone who is accountable for service quality who is pushing for improvements. This person has to be empowered to make decisions about the service and they need to be respected the same way that Toyota product managers are.