Asset Refresh - Servers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
We're currently deploying ServiceNow in a large organization. It seems as if the asset refresh process works very well for laptops and PCs, but there's very little information about refreshing a server or network equipment. Our mandate is "out of the box" for the first release. Specifically, we need the ability to engage different teams to assign tasks to for the replacement of an asset. For example, we have a server with 20 different applications managed by 15 different teams. I've been looking on YouTube for examples of how to manage this scenario but not luck so far. Anybody know of a good resource I can review?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
Hi DCARLIN1,
Hate to answer a question with a question, but let me explain before asking it.
Servers and Network Infrastructure for the most part is ordered in 3 ways, and mostly not by users/requests through the Incident /RMA/refresh processes that Desktop and end-user devices usually are set up and workflowed.
Servers and Network Infrastructure (that are Physical HW Assets), as I mentioned, are sourced and acquired through 3 main mechanisms:
1) Projects that have capitalized assets (they depreciate vs. being expensed) and usually span more than a year or have a high number of fixed costs for that equipment.
2) Refresh/Upgrade NOT on emergency production replacement/HA/DMZ equipment. This is similar to the above 1); however, it may not be tied to a specific use case/project/Business Service, and it is considered a capital asset.
3a) It is leased equipment under contract direct from the manufacturer (ie, BIGIP-F5 or Cisco UCS,..) OR
3b) it is a replacement not under warranty supporting non-critical applications or other environments (Dev, Test,..), and this is the most relevant to your ask in that scope.
My recommendation is to take advantage of the following fields and their appropriateness to your specific organization: Managed By, Managed Group By, Supported By, Support Group By, Product Owner, Application Owner, Business Owner, and obviously the Data Center as an ssignment Group can be named for equipment (asset types) like Firewalls, WWAN Controllers, and the like that would possibly reside in the Data Center itself.
I recommend you have at least a SOP (Standard Operating Procedure) if a fully-baked policy with Governance is not yet in place. It will help you define how the workflow should happen and flesh out any issues that would be raised from this.
Good luck, and please reach back to us at SN or to our wonderful community if you want further assistance or great ideas.
Regards,
Phil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
38m ago - last edited 7m ago
HI @DCARLIN1,
The big difference between EUC equipment and DC infrastructure is that it most of the time runs critical services for the enterprise, and you can't replace them in isolation, like a laptop. It's a team effort, and often involves multiple and cross functional teams.
The Asset Mgmt. application as well as HAMP can help you link your DC equipment to one or multiple contracts for maintenance, warranty, lease, etc. The contract management overview helps you identify contracts that need a renewal.
Manage your expiring contracts for leased hardware assets
Hardware models give you the possibility to set a 'Useful life (months)' e.g. 60 months for servers, which will flag assets to be 'Eligible for refresh', which can also be used to drive refresh projects and change the individual hardware by change request to ensure adequate risk management and authority.
Hardware Asset Refresh - how to determine if an asset is eligible for refresh
Worth mentioning the product life-cycle data that you receive from the content service. It also will help to identify hardware where you need to plan remediation before EoS or EoL.
Most important is that you identify the starting point of your process for refreshing DC hardware. From there, you can build your solution based on existing OOTB functionality and reporting.
Hope this helps!
