- Application service lifecyle
- Infrastructure service lifecycle
- Technology Product Lifecycle
- IT Asset Lifecycle
I believe that these are at an appropriate level of granularity to apply Lean value stream mapping, in such a way that constraints can be identified and elevated.
But any value stream needs metrics, and they are not easily come by. We have myriads of ITSM "activity" metrics (e.g. # changes performed) but these are emphatically not "value" metrics. (Show me any relationship between # of changes performed - even # of successful changes - and the bottom line.)
The application & infrastructure service value metrics in particular will take some thought. For applications, I think that the transactional concept of Logical Unit of Work will be primary (and this concept itself needs careful consideration.) The best discussion of this I ever read was a multi-part series by the distinguished David McGoveran in EAI Journal (later BI Journal). For infrastructure, some measure of platform availability may suffice.
Technology product and asset value metrics, however, take a different turn because they are not, by definition, "services."
There is often much overhead associated with the onboarding of a new technology product; real value is be the availability of that product for use (as opposed to being hung up in contracts, architecture, or security concerns).
Similarly, there is overhead associated with the asset supply chain. Forecasting, approving, requesting quotes, ordering, receiving - none of these add value from the shareholder's perspective. Only when the asset is actively in service is value being delivered from the investment.
This leads to a metric idea: Asset Hours in Service, or AHIS. (I Googled it; I'm apparently coining the term.) For the IT asset lifecycle, divide AHIS by the total asset cost, including staffing the capability.
The metric needs to be adjusted somehow to not incent for leaving fully depreciated assets on the floor indefinitely. Perhaps AHIS needs to be multiplied by residual asset value.
A similar approach might work for Technology Products, but I have not thought it through yet.
Thoughts?
