Introduction
A structured framework for accurate, compliant, multi-system asset operations
When I stepped into the Tool lead role for ABB’s global BarScan asset management infrastructure. Ever wonder what happens behind the scenes when a laptop’s warranty is extended, an asset is marked as missing, or a user is reassigned a device? It’s not magic—it’s a series of precise, documented procedures handled by Asset Management teams. As an IT professional, much of our critical work is governed by internal Knowledge Base (KB) articles that ensure consistency, accuracy, and auditability.
Today, I’m pulling back the curtain on a suite of core asset management processes. These summaries aren’t just a checklist; they represent the essential plumbing of IT Asset Lifecycle Management, ensuring data integrity across multiple systems like HPAM (our asset repository), Barscan (our operational tracking tool), and our central CMDB in ServiceNow (SNOW).
Here’s a breakdown of the key procedures that keep our asset data accurate and reliable created by me.
- Updating Warranty Dates in HPAM
The Purpose: To accurately reflect the Warranty Start Date (WSD) and Warranty End Dates (WED) for hardware assets, which is crucial for support eligibility and financial forecasting.
The Process: The request typically arrives via a ticket with a spreadsheet. Our first job is data validation—ensuring the sheet contains only the asset tag and the two dates. This cleaned data is converted to a text file and imported into HPAM using a dedicated import utility. Action: we always click ‘No’ when asked to save the import script to prevent incorrect future use. Success is confirmed with an import success message before we resolve the ticket.
- Generating Asset Log Reports from Barscan
The Purpose: To provide audit trails or activity logs for specific assets upon request, often for troubleshooting or compliance.
The Process: This is a manual, hands-on task. After validating the asset and location, we remote into the specific regional Barscan server. We navigate to the reporting module, select the precise log report, and carefully choose the required output columns as per the request. The report is run with a broad date range, saved to a file, and then sent to the requester. The key here is attention to detail in column selection, as the interface requires manual configuration each time.
- Assigning an Asset to a User in Barscan
The Purpose: To officially assign ownership of a device to an end-user in our operational system, linking a person to a physical asset.
The Process: We confirm the asset exists and the request is valid. Logging into the correct Barscan server, we search for the asset record and update the ‘Assigned User’ field. Crucially, we also add a history comment noting the service request ticket number. This change isn’t instant in the central CMDB; we place the ticket in pending status and wait for the next scheduled sync job to complete before closing it out.
- Updating Device Status to MNR or LOST in Barscan
The Purpose: To flag an asset as “Missing Not Returned” or “Lost” in the system, triggering offboarding and accounting processes.
The Process: Beyond simply changing the status field in Barscan, there’s a vital second step: we must also remove the user association from the same asset in HPAM. The two systems have different purposes, and both need to be consistent. The username field must be blank for an MNR/LOST asset. As always, we add a comment, reference the ticket, and wait for the sync to SNOW to verify the change.
- Retiring/Disposing an Asset in HPAM
The Purpose: To formally end the lifecycle of an asset in our primary repository, marking it as “Retired_Disposed.”
The Process: This is a status change performed directly in HPAM, separate from the operational status in Barscan. We locate the asset, change its status, and log the ticket reference. This action is about financial and lifecycle tracking, and again, we verify the update has propagated to SNOW before considering the work done.
- Bulk Asset Updates
The Purpose: To execute widespread changes (like mass reassignments or status updates) efficiently and consistently.
The Process: Bulk operations follow the same logic as individual ones but require meticulous spreadsheet management. The core principle remains: validate the list, perform the action in the appropriate system (often Barscan), add a standardized comment template to each asset referencing the master ticket, and monitor the bulk sync. Accuracy in the source data is paramount to avoid creating a larger problem.
- Updating the Scheduled Retirement Date (SRD) in HPAM
The Purpose: To maintain an accurate forecast of when assets are planned for replacement, which is essential for budgeting and procurement cycles.
The Process: The SRD (or Planned Removal Date) is a financial field managed in HPAM. We update it in the asset’s Acquisitions tab. It’s a simple change but one with long-term planning implications. The process underscores that asset management isn’t just about where a device is today, but also about planning for its end-of-life.
- Removing a Previous User Assignment in HPAM
The Purpose: To clean up data integrity by clearing out outdated user associations, often a prerequisite for marking an asset MNR or before reassignment.
The Process: This is a straightforward field update in HPAM. We find the asset, clear the username field, and save it with a comment. It’s a classic example of a necessary “data hygiene” task that supports larger processes like reissuing hardware or accurate loss reporting.
Why This All Matters
Individually, these tasks might seem like simple data entry. Collectively, they form the backbone of reliable IT asset management. Accurate data in HPAM feeds financial depreciation and contract management. Correct statuses in Barscan drive operational logistics. Synchronized data in SNOW gives the entire organization a single source of truth for every asset.
The real skill is support isn’t just knowing which button to click. It’s understanding which system is the source of truth for which piece of data, how they interconnect, and what the downstream impact of any change will be. It’s about methodical validation, clear audit trails in comments, and respecting the synchronization cycles between systems.
These KB articles ensure that whether it’s my colleague or me handling the ticket, the outcome is consistent, compliant, and correct. That’s how we maintain trust in the data that the business relies on to make decisions, from purchasing to security to support. It’s not the most glamorous part of IT, but it’s absolutely foundational.