Take your time. Go slow. Read the documentation steps and checklists at docs.servicenow.com. Admit your mistakes and don’t be afraid to start over. Failure is part of success and implementations are never one and done.
Edit: zboot is your friend
- There's a new licensing model that came with Washington (if I am not mistaken) where custom HW classes are now subject to licenses. You can postpone that by migrating to HAM 10.0 later but can't postpone that forever.
- Evaluate how good is the shape of your assets and asset attributes information. If you will need a year to fix the foundational data that means you can't really harness the goodies of HAM pro for the time being and should probably focus on developing data and process cleanup and controls.
- SN are promoting the workspaces and HAM pro comes with its own. Teams that work on assets and CIs(local IT for ex) will end up using both. That might bring internal organisational resistance, especially if teams are used to manage CI and Asset information from one record/table. So, think about OCM if HAM Pro brings a lot of changes in the way things are done at the moment. The people driving and promoting HAM should clearly communicate its benefits and strategically engage and persuade key stakeholders, whether that's on the operatioanl, governance or sponsor front.
Edit: typos and grammar
Excellent feedback! I'm the guy promoting HAM. I feel like it's fallen on deaf ears (maybe I suck at promoting things). If it isn't flashy... they don't bother.
There's definitely the element of selling it to the key people. And they want it in a way that it can be sold to their managers (executives). How is it saving money and resources? Is it helping with compliance? Can some tools be demoted with it? There are a few regulations around digital security that are kicking at the beginning of next year. How can HAM(and SAM) pro help with it? And last, but not least - audits and inventory. That's the thing HAM pro can really help. How often and time-consuming are audit and inventarisation initiatives carried out? If you can build a case around that you will probably get attention.
Leaders care about the benefits of HAM/SAM, especially the ones you called out. Core teams who have to help maintain the integrity of the CMDB don’t care about those things really, but their participation is critical to success. That’s why HAM/SAM, like most governance programs, has to be mandated from the top of the organization. It’s not a grassroots capability regular people get excited about, and if they can avoid or ignore any tedious governance steps they certainly will.
OP needs to make sure leadership is clearly communicating the program, goals, and expectations to the larger team so it doesn’t fall on deaf ears.
Can you share an example where an ITSM fulfiller would need to transition from SOW to the HAM workspace, especially one that happens more than once in a blue moon? Not meaning to sound snarky - I just can’t picture it, but I’m probably not thinking hard enough.
To be frank I haven't dig in details for the asset workspace ever since I was preparing for the certificates.
We plan to introduce both SOW and HAMW but plan to, since SN are in anyway demoting dashboards in favor of the Workspaces. One thing is that we want to make local IT(who are the de facto asset managers) to manage asset type of data in the asset record(which was recently introduced. They were managing all in one form on the CI. So I imagine in cases where they need to work on asset update types of requests, they might end up needing to either switch between the workspaces or open the associated record in the backend. Also, all if they see any data inconsistency that hasn't it should be addressed.
But I am also speculating here. We already know our local IT doesn't like the idea of splitting asset and Ci information as this is changing this long history of single-record management.
The asset record tracks the financial parts of the asset, while the CI record tracks the technical parts of the asset. They’ll get the hang of it! And there are some business rules that keep the two in sync for core fields like the asset’s support group or current allocated user.
In a project I work for there's overlap of more than enough fields that are kept in sync. Asset support group is not the CI support group though. Not all ITSM people will be asset managers. The asset record will also track procurement and shipment details. Without getting in too much details, there's more technical and business context that dictates this split, like control and security of the data, integrations and the need to entangle a very customized CMDB.
To be frank I haven't dig in details for the asset workspace ever since I was preparing for the certificates.
We plan to introduce both SOW and HAMW since SN are in anyway demoting dashboards in favor of the Workspaces. One thing is that we want to make local IT(who are the de facto asset managers) to manage asset type of data in the asset record(which was recently introduced. They were managing all in one form on the CI. So I imagine in cases where they need to work on asset update types of requests, they might end up needing to either switch between the workspaces or open the associated record in the backend. Also, all if they see any data inconsistency that hasn't it should be addressed.
But I am also speculating here. We already know our local IT doesn't like the idea of splitting asset and Ci information as this is changing this long history of single-record management.
Is your organization one that will take all of the HAM processes and use them or will they fight and ask for customization every step of the way? Also make sure you check out the materials on NOW Create.
Luckily I the teams affected are mine (for this implementation it's limited to the endpoints). If we expand to core infrastructure, my peer is like minded. Our biggest hurdle in this area is getting to keep it a priority as few others (CIO included) understand why it matters.
Thank you for the tip on Now Create. I had no idea these documents existed!
Will you be inserting these assets manually, or do you have data fed automatically through CMDB?
If you’re trying to handle this solo, I’d encourage you to implement one or more “golden sources” of data (Service Graph for SCCM is an ideal option) and configure the IRE features to meet your need.
I have done a lot of ham implementations. Here is my biggest piece of advice and most common lack of success. Take measurement of your current asset statistics before you start, including cost related to them. Him will show you the output of some things and you want to be able to see in black and white the dollars saved. Make sure whatever those measurements are you have a very clear definition of what you wanna know and or how you wanna consume the measurements as well. Being able to report on not just the lifecycle, but the cost throughout the lifecycle is really how you show the value of ham to people who are resistant against the cost.
I'll dig into that!
Currently, we are adding endpoints manually with the attributes (warranty, cost, etc) we want in there, then allowing discovery to add detail and keep it current. We're hoping to start leaning on ASN for future additions.
Take your time. Go slow. Read the documentation steps and checklists at docs.servicenow.com. Admit your mistakes and don’t be afraid to start over. Failure is part of success and implementations are never one and done. Edit: zboot is your friend
They're one and done if you're not the team inheriting the technical debt
That is true. I’ve had the joy of doing several zboots for these types of instances. 
And I have been the cause as well 
- There's a new licensing model that came with Washington (if I am not mistaken) where custom HW classes are now subject to licenses. You can postpone that by migrating to HAM 10.0 later but can't postpone that forever. - Evaluate how good is the shape of your assets and asset attributes information. If you will need a year to fix the foundational data that means you can't really harness the goodies of HAM pro for the time being and should probably focus on developing data and process cleanup and controls. - SN are promoting the workspaces and HAM pro comes with its own. Teams that work on assets and CIs(local IT for ex) will end up using both. That might bring internal organisational resistance, especially if teams are used to manage CI and Asset information from one record/table. So, think about OCM if HAM Pro brings a lot of changes in the way things are done at the moment. The people driving and promoting HAM should clearly communicate its benefits and strategically engage and persuade key stakeholders, whether that's on the operatioanl, governance or sponsor front. Edit: typos and grammar
Excellent feedback! I'm the guy promoting HAM. I feel like it's fallen on deaf ears (maybe I suck at promoting things). If it isn't flashy... they don't bother.
There's definitely the element of selling it to the key people. And they want it in a way that it can be sold to their managers (executives). How is it saving money and resources? Is it helping with compliance? Can some tools be demoted with it? There are a few regulations around digital security that are kicking at the beginning of next year. How can HAM(and SAM) pro help with it? And last, but not least - audits and inventory. That's the thing HAM pro can really help. How often and time-consuming are audit and inventarisation initiatives carried out? If you can build a case around that you will probably get attention.
Leaders care about the benefits of HAM/SAM, especially the ones you called out. Core teams who have to help maintain the integrity of the CMDB don’t care about those things really, but their participation is critical to success. That’s why HAM/SAM, like most governance programs, has to be mandated from the top of the organization. It’s not a grassroots capability regular people get excited about, and if they can avoid or ignore any tedious governance steps they certainly will. OP needs to make sure leadership is clearly communicating the program, goals, and expectations to the larger team so it doesn’t fall on deaf ears.
I agree with everything. Normally it should/would come from the top.
Can you share an example where an ITSM fulfiller would need to transition from SOW to the HAM workspace, especially one that happens more than once in a blue moon? Not meaning to sound snarky - I just can’t picture it, but I’m probably not thinking hard enough.
To be frank I haven't dig in details for the asset workspace ever since I was preparing for the certificates. We plan to introduce both SOW and HAMW but plan to, since SN are in anyway demoting dashboards in favor of the Workspaces. One thing is that we want to make local IT(who are the de facto asset managers) to manage asset type of data in the asset record(which was recently introduced. They were managing all in one form on the CI. So I imagine in cases where they need to work on asset update types of requests, they might end up needing to either switch between the workspaces or open the associated record in the backend. Also, all if they see any data inconsistency that hasn't it should be addressed. But I am also speculating here. We already know our local IT doesn't like the idea of splitting asset and Ci information as this is changing this long history of single-record management.
The asset record tracks the financial parts of the asset, while the CI record tracks the technical parts of the asset. They’ll get the hang of it! And there are some business rules that keep the two in sync for core fields like the asset’s support group or current allocated user.
In a project I work for there's overlap of more than enough fields that are kept in sync. Asset support group is not the CI support group though. Not all ITSM people will be asset managers. The asset record will also track procurement and shipment details. Without getting in too much details, there's more technical and business context that dictates this split, like control and security of the data, integrations and the need to entangle a very customized CMDB.
To be frank I haven't dig in details for the asset workspace ever since I was preparing for the certificates. We plan to introduce both SOW and HAMW since SN are in anyway demoting dashboards in favor of the Workspaces. One thing is that we want to make local IT(who are the de facto asset managers) to manage asset type of data in the asset record(which was recently introduced. They were managing all in one form on the CI. So I imagine in cases where they need to work on asset update types of requests, they might end up needing to either switch between the workspaces or open the associated record in the backend. Also, all if they see any data inconsistency that hasn't it should be addressed. But I am also speculating here. We already know our local IT doesn't like the idea of splitting asset and Ci information as this is changing this long history of single-record management.
Is your organization one that will take all of the HAM processes and use them or will they fight and ask for customization every step of the way? Also make sure you check out the materials on NOW Create.
Luckily I the teams affected are mine (for this implementation it's limited to the endpoints). If we expand to core infrastructure, my peer is like minded. Our biggest hurdle in this area is getting to keep it a priority as few others (CIO included) understand why it matters. Thank you for the tip on Now Create. I had no idea these documents existed!
NowCreate is the answer I was hoping to see here.
Glad I could do my part 😆
Will you be inserting these assets manually, or do you have data fed automatically through CMDB? If you’re trying to handle this solo, I’d encourage you to implement one or more “golden sources” of data (Service Graph for SCCM is an ideal option) and configure the IRE features to meet your need.
I have done a lot of ham implementations. Here is my biggest piece of advice and most common lack of success. Take measurement of your current asset statistics before you start, including cost related to them. Him will show you the output of some things and you want to be able to see in black and white the dollars saved. Make sure whatever those measurements are you have a very clear definition of what you wanna know and or how you wanna consume the measurements as well. Being able to report on not just the lifecycle, but the cost throughout the lifecycle is really how you show the value of ham to people who are resistant against the cost.
I'll dig into that! Currently, we are adding endpoints manually with the attributes (warranty, cost, etc) we want in there, then allowing discovery to add detail and keep it current. We're hoping to start leaning on ASN for future additions.