Managing Endpoint Life Cycle in Incident tickets

[Jason DaSilva]

We are starting to move further into Hardware Asset Management (implementing HAM Pro), but we have always struggled with the process of computer endpoint life cycle management. 

<The long story>

In the past (before I was part of the team) the 'hands on' techs would go into the alm_hardware table and change the asset status there.  This was a bit of a pain for the techs to go in and manipulate, and was often a forgotten step leading to inaccuracies of hardware status.

Soon after that the team implemented an "endpoint deployment request form" that techs were required to open to fill out the lifecycle changes to the CI(s) affected by the work that was done.  Still a 3rd party ticket, which in my opinion still leaves the ability for techs to be 'too busy' to create and process.  In the latter case, at least the time spend was tracked as a ticket being processed, but seems that it was a padding numbers process that I want to steer clear of if possible.

<the short story>

We are looking for a way that ties in with when the tech closes out the incident, making it mandatory if they change out hardware to set the status of the old equipment if it was replaced.  I see that the related list Affected CIs is available, and has an option to select SWAP and set a new CI that it is swapped out for.  This works for the new CI, but does not seem to give any avenue to set the status for the old CI.  This old CI could be in stock for maintenance, available, or pending disposal.  Right now it sets the Hardware Status to In Disposition, but now still requires the tech to navigate somewhere else to finish the job they started leaving the possibility for it not to be completed.  Yes we can do reports to track who's not doing what, but I would much prefer to have a process that prevents them from casually ignoring the process.  Any ideas out there?

[Rahul Priyadars · Accepted solution]

Since  I do not have detailed Insight in ur e2e process. But from last Para technically i can see something.

tech closes out the incident---> If you have enough data points in INC record then you can write a Script which will cover all your possible Operations which should be done by Tech Team.

Script should Run on Closure of Incident. This triggers needs Input from INC data point what are the possible Branches which will be covered by SCRIPT.

Regards

RP 

[Jason DaSilva]

Ok, so we need to be sure that the data on the ticket includes the actual CI, which we are working towards (going away from the improper use of CIs we did in the past).  Before I approach our Dev team (does the scripting) I am trying to figure out if there is a way to have the actual CI appear in the ticket (like a related link).  If that was there, it might be easier on the tech not having to navigate away from the current ticket and still be able to select the status for the CI. 

With what you are stating, there would have to be some precise wording in say the Work Notes for the script to pick up on.  This leaves the possibility for mistyped information on the ticket.  I don't know how flexible the INC view is, but I also don't what to change things to the point where it may confuse other non-lifecycle related activities.  The more I go over this, the more I think a separate ticket may be needed in this case.  A lot of what I want to do to prepare for this could be done in the catalog item, but in the case of a break fix, we cannot leave it up to the customer creating the ticket to make that decision, or  every ticket would lead to equipment replacement...

[Rahul Priyadars]

In Automation Use Cases- Data Points should be Pre-Defined Values/Drop Down etc .Open Text tying by Tech Team and then triggering some automated script may fail some where as u said above also.

Regards

RP