As I was preparing chicken piccata last night, I had one of those flashes.
In the IT industry, why don't we care about process information the same way we care about configuration information?
We've had a 15-year conversation about CMDBs. It's a well known idea that all configuration data should be put in a repository, or short of that, should be seen as part of an federated system. Applications, servers, databases, files, queues, executables, services, racks, switches, etc, etc, etc should all be seen as Configuration Items, or "CIs."
But, if you ask ITSM advocates about processes, they will talk specifically about Incidents, Problems, Changes, Releases, etc as if they all are fundamentally different.
I think we need the concept of a Process Item - just as a specific Server and an Application can both be CIs, so can a specific Incident and a Change both be PIs. They could inhabit the same PMDB, or be federated in a common PMS. [Yes, I recognize the unfortunate acronym :-) Let's figure out better naming later.]
This in fact is how many actual implementations of IT management tools work. But at a framework level, it is NOT how people are educated in IT management - the education and mental model continues to be that Incidents, Changes and Problems are very distinct and at best cross-reference each other.
In the world of Process, we have a series of related terms that indicate a
"potentially recurring series of events with various complexity (parallelism, sequentially related or not, and so on)"
as the Oracle Communications Model states. Under this general heading we have
- Service Request
- Problem (and other Improvement Opportunity)
But (as I have pointed out elsewhere) the way these are currently implemented is too often as distinct queues of work with no coordination and understanding of aggregate demand. There is no awareness or concern when people who are critical to a Project also wind up handling high criticality Incidents.
I think there is much justification for promoting the ideas of Process Item and a unified PMDB as industry guidance.
- First, it aligns well with the growing interest in Kanban and limiting work in process. All these Process types compete for resources. If all are seen as fundamentally similar then it is possible to understand the aggregate demand.
- My coverage as an analyst of the Professional Services Automation tool sector (e.g. Tigerpaw) suggests that this class of tooling is already moving in this direction.
- There are complex dependencies between PIs just as with CIs - larger grained PIs such as Project may contain any number of smaller grained PI types such as Release, Change, and Request.
- The above-mentioned Oracle Communications Model (which is now conformant with eTOM) requires that the PROCESS entity be used as the overarching parent for all process activity.
- During one large program I was part of, all Releases, Project milesones, and Changes were consolidated into a single timeline view which was praised by senior executives as one of the best orienting mechanisms they had seen.
I have seen various attempts and interest along these lines, but always company or vendor specific. I wonder if the lack of a PI/PMDB concept in fact may be why the concept of CMDB has had such struggles.
People have often said to me, "Isn't the CMDB the basis of ERP for IT"?
My view is no, no more than the Bill of Materials is the basis for manufacturing ERP. The core of ERP systems is more about process and execution, and that is what we are missing in large scale IT management. We've spent years struggling with the data-centric orientation the CMDB discussion gave us, while shortchanging the process and execution side of the work.
I realize the red flags that come up with any suggestion of a centralized system, which is why I am more in favor of seeing the PI concept as a logical interface. If all Process Items had some degree of overarching consistency, they could be exchanged and federated as part of execution activities, without requiring a monolithic centralized data store.