So, I am need of a recognizable icon representing Lean for my book rewrite, and of course I thought of the famous Toyota Production System “house.” (Some are now calling it the “Thinking Person’s System.) As far as I know the concept is not copyrighted, if I build my own representation from scratch.
This led to the question, has anyone ever attempted a mapping of IT onto that house? Google isn’t showing me anything.
Being a fool willing to rush in, I played with some concepts top of mind for me lately and came up with the above. Emphasize this is version 0.1, and would really like some feedback.
Some commentary on my choices:
Just In Time has a couple different connotations in light of my dual-axis lifecycle model. Applied to transactional service delivery, clearly the ongoing transition from batch processing to real time service interfaces is exemplary (and obvious). Along the service lifecycle, Agile methods clearly are the major driver to reduce cycle time on systems development at the functional application level. Recently I’ve been playing with a bit of a variation on the Agile theme, as I’ve been contemplating the impact on traditional project management. I’m wondering if we should consider that
- what once was a whole Project, should become a Release;
- what once was a Release, should become simply a Change;
- and what once was a Change, should become simply a Service Request.
The movement of processes and activities through this maturation should be measurable, and clearly (given the relative overheads involved) represents a move towards less waste and greater IT agility.
A major obstacle to this agility has been the provisioning of hardware and base computing services to functional application teams. Internal and external clouds are the just in time response, reducing the time involved in acquiring, installing and configuring base technical capabilities.
Along another dimension, as I thought about what was meant by “quick changeup” in the original Lean (being able to reconfigure a machine tool in minutes not days to produce a different kind of widget) the goals of SOA and even Web 2.0 mashups came to mind. Granular IT services available for arbitrary re-composition enable the same sort of quick change artistry, allowing IT organizations to rapidly recompose solutions to business demand, in days not weeks and months.
On the quality management pillar, one sees test-driven development — essentially the application of poka-yoke principles to software engineering. Contract-based development is a related architectural techique that “that software designers should define formal, precise and verifiable interface specifications for software components” (Wikipedia).
Problem management and root cause are relatively obvious, and attention to non functional requirements will always be a major quality concern.
The idea of data quality driven andon cord is one I am just playing with. Often, process breakage is seen first as a variance in data quality. It seems that there has not been enough said about the opportunities to drive process quality via data quality management. Certainly, if we are serious about process improvement, the accuracy of the data flowing through that process is one of the simplest indicators we have. Applying this to IT management is an area rich for exploration.
Applying “leveled production” to IT management immediately implies some form of demand management, to better pace the work placed on IT resources. Reducing Incidents is of course critical to that, from a waste elimination perspective, as incidents constitute by definition unplanned work. However in my experience another source of thrashing is in the relationship between service providers and customers, especially that relationship playing out along the hosting zone of contention. The dynamics seen in the arm wrestling over prioritizing provisioning requests are exactly analogous to a poorly managed shop floor with competing expeditors seeking to accelerate production jobs out the door. The concept of Critical Chain management is essential, as it clearly outlines both the costs of this dysfunction as well as a sensible approach (now generally accepted by the project management profession) for improvement.
The Scrum concept of fixing the schedule and adjusting requirements to match has clear Lean parallels (and may in fact have originated in the intersection of software engineering and Lean). It is a definitive statement on how to level production in the world of functional application development, and eliminate muri (overburden).
Finally, capacity planning needs to feed more directly into IT financial management; such linkage is not well recognized as an opportunity in much of the IT literature and would give a more stable, pro-active approach for acquisition as opposed to re-active management.
These are some very preliminary thoughts. This is far from a complete framework. I also realize that the canonical TPS representations include additional layers (e.g. process management, visual management, Toyota philosophy) but I still am thinking about those.
