Alert readers may have have noticed in my overall process architecture the idea of a generic process "Improve Service," and corresponding concepts of Improvement Opportunity in the data architecture and Continuous Improvement System in the systems architecture.
This is the outcome of a long standing conundrum in considering ITIL as a process architecture: I can count Changes and Incidents, but I cannot count Capacities or Availabilities. And if I have initiatives to improve capacity or availability, those initiatives compete for the same resources answering service requests and resolving incidents, and prioritization across these activities is typically ad-hoc and local. Service improvements (under which I also include process improvements) can take many forms, and be driven from many uncoordinated directions in the enterprise.
These are important themes in the new edition, which goes into the problem of cross-queue prioritization in the large IT shop from a few different angles.
Dee and I absolutely share the same concern:
A piecemeal and fragmented approach to Quality, Compliance and Process improvement causes contention for scarce resources, creates new silos and in some cases parallel management systems. This limits the scale and scope of the benefits to be derived from these programs and equally importantly, the sustainability of initial benefits.
I have noted in the 2nd edition that this idea was perhaps novel, at least at this level of specfic realization. Certainly continuous improvement as a general concept is not new. But what about routing it into demand management and an overall governing BPM capability? Controlling and leveling the demand of continuous improvement itself?
And now, completely independently, I have found a kindred spirit. An emerging trend? Or is this an old idea I'm just re-discovering?
Thoughts?
