Suzy, you pose some interesting questions here. Different interpretations of "value" lead us down different paths where asset management intersects with other IT management processes.
Some people say "value" and perhaps mean "replacement value", which, like an insurance company saying your family photos are basically only worth the cost of chemicals, paper and labor, really misses the actual "value" of the asset. The labor cost of replacing a co-processor would be part of TCO which would better reflect true replacement value, but I suspect this is not what you are asking.
As part of a governance process, IT may need to establish the expected value of a particular business service addition or enhancement to cost-justify prior to development and rollout. The cost of all assets required to operationalize this service, along with other hardware and labor to configure and maintain the service) would contribute to the cost portion the business case. Again, I don't think this is what you mean.
If by "value" you mean what is the asset (in your example, a co-processor) contributing to the business, it would rarely be helpful or practical to view a single asset this way, at least not in isolation. And asset management would not be the discipline to determine operational value. An IT asset is ultimately just playing some role in a business service, e.g. "order processing", which is what the business is truly consuming and where IT is adding value. As part of an operational business service, we're now really talking about an asset in terms of its role as a CI (Configuration Item). As a CI, we want to understand its potential impact on the overall business service.
Once a service is operational, you could consider the service "value" to be the cost of lower performance or availability. An order processing service may cost the business $1,000 for every minute of downtime, or $1,000 for every 10% degredation in transaction performance. It's conceivable a co-processor could be a critical and measurable part of the performance equation. Now we're into a hybrid of capacity and impact management, e.g. what capacity is required for what level of business performance, and/or what is the potential service impact on the outage/absence of a particular CI (in your example, a particular co-processor). Using asset cost data you can understand the "value" in terms of the asset's cost relative to the increased performance or availability of the service. But in this case it's capacity or impact management that determines "value", while asset could contribute TCO or replacement cost into some capacity, incident, problem or change decision process.
You also mentioned disposal and security risks. If we're talking about a hard disk that may contain sensitive data (HR or financial data, for example) there is an operational risk of having this data corrupted, or a business risk of the data falling into the wrong hands. This really isn't about the value or cost of the hard "asset" (the disk) but is more about the data. There may be a compliance risk of not documenting changes (a change management issue), access control (an identity management issue) or proper maintenance and disposal (ahhh, finally, an asset management issue!)
Tracking the lifecycles of assets that contain sensitive data is indeed critical and makes a good case for why inter-related IT processes need to have some level of integration. An identity management solution may identify which users are accessing which sensitive applications, and a CMDB could further tell you which assets/CIs support sensitive applications. You may want to apply asset lifecycle controls to ensure proper maintenance or disposal of such assets, even if their replacement or book value is insignificant.
The question of whether the cost of controls is worth the benefit is one of the many reasons people correcly point out that asset management is 80% process and 20% tools and technology. You need a firm understanding of what problems you are trying to solve, what processes are required to solve them, and then, how to use tools like BMC's to support and enforce those processes. You don't want to "spend a dollar to chase a dime", i.e. overkill your processes to where they are too expensive for the value you get, or collapse under their own weight and become ineffective. Identifying "sensitive assets" (really, assets that have sensitive data) or critical CIs (knowing which service components have the capability to significant degrade performance of critical services) is useful in ITAM as these are assets for which you may want to enforce routine maintenance and retirement schedules.
Forgot your password?
New user?
Some people say "value" and perhaps mean "replacement value", which, like an insurance company saying your family photos are basically only worth the cost of chemicals, paper and labor, really misses the actual "value" of the asset. The labor cost of replacing a co-processor would be part of TCO which would better reflect true replacement value, but I suspect this is not what you are asking.
As part of a governance process, IT may need to establish the expected value of a particular business service addition or enhancement to cost-justify prior to development and rollout. The cost of all assets required to operationalize this service, along with other hardware and labor to configure and maintain the service) would contribute to the cost portion the business case. Again, I don't think this is what you mean.
If by "value" you mean what is the asset (in your example, a co-processor) contributing to the business, it would rarely be helpful or practical to view a single asset this way, at least not in isolation. And asset management would not be the discipline to determine operational value. An IT asset is ultimately just playing some role in a business service, e.g. "order processing", which is what the business is truly consuming and where IT is adding value. As part of an operational business service, we're now really talking about an asset in terms of its role as a CI (Configuration Item). As a CI, we want to understand its potential impact on the overall business service.
Once a service is operational, you could consider the service "value" to be the cost of lower performance or availability. An order processing service may cost the business $1,000 for every minute of downtime, or $1,000 for every 10% degredation in transaction performance. It's conceivable a co-processor could be a critical and measurable part of the performance equation. Now we're into a hybrid of capacity and impact management, e.g. what capacity is required for what level of business performance, and/or what is the potential service impact on the outage/absence of a particular CI (in your example, a particular co-processor). Using asset cost data you can understand the "value" in terms of the asset's cost relative to the increased performance or availability of the service. But in this case it's capacity or impact management that determines "value", while asset could contribute TCO or replacement cost into some capacity, incident, problem or change decision process.
You also mentioned disposal and security risks. If we're talking about a hard disk that may contain sensitive data (HR or financial data, for example) there is an operational risk of having this data corrupted, or a business risk of the data falling into the wrong hands. This really isn't about the value or cost of the hard "asset" (the disk) but is more about the data. There may be a compliance risk of not documenting changes (a change management issue), access control (an identity management issue) or proper maintenance and disposal (ahhh, finally, an asset management issue!)
Tracking the lifecycles of assets that contain sensitive data is indeed critical and makes a good case for why inter-related IT processes need to have some level of integration. An identity management solution may identify which users are accessing which sensitive applications, and a CMDB could further tell you which assets/CIs support sensitive applications. You may want to apply asset lifecycle controls to ensure proper maintenance or disposal of such assets, even if their replacement or book value is insignificant.
The question of whether the cost of controls is worth the benefit is one of the many reasons people correcly point out that asset management is 80% process and 20% tools and technology. You need a firm understanding of what problems you are trying to solve, what processes are required to solve them, and then, how to use tools like BMC's to support and enforce those processes. You don't want to "spend a dollar to chase a dime", i.e. overkill your processes to where they are too expensive for the value you get, or collapse under their own weight and become ineffective. Identifying "sensitive assets" (really, assets that have sensitive data) or critical CIs (knowing which service components have the capability to significant degrade performance of critical services) is useful in ITAM as these are assets for which you may want to enforce routine maintenance and retirement schedules.
I hope this helps.
Dave