We implemented Altiris Helpdesk in the last month or so. Besides using Altiris' versatile Helpdesk tool to automate and streamline as many processes as possible, one of my tasks was to setup a Change Management "module". I realize that a Change Management process is going to differ in many ways from place to place, but I hope this will help out someone looking to accomplish some of the same things I needed to.

Let's use "CM" for "Change Management" from here on, shall we?

Business Process

The requirements were fairly simple. Using the builtin forms and fields, provide a way for the IT department to track system and application changes as a best practice and to comply with auditor requirements.

The department's CM policy boils down to two elements:

1. CM Classification
2. CM Actions

CM Classification

For this one, I thought the Urgency field would work well enough. It's just a measure of risk or importance. We can choose from Low, Medium, High, or "My Hair is on Fire!" (I think I learned that last one from Bay Dynamics' Seamus Garvey in one of his training classes). Doubling-up on Urgency would save me having to create a new field and introduce any extra customization.

CM Actions

In my IT department, CM is so serious they made it a 13-step program! We could start a CM Anonymous club... Anyway, there's 13 "actions" that need to take place. If it's a low classification not all of the actions need to happen, but you don't have to care about that. Just don't blame me if you don't like it.

Action codes:

1. CM01 user request documented
2. CM02a change request approved
3. CM02b change request denied
4. CM03 test plan documented
5. CM04 test script documented
6. CM05 test result documented
7. CM06 user confirmation documented
8. CM07 backout/rollback plan documented
9. CM08 implementation plan documented
10. CM09a IS manager review & acknowledgement
11. CM09b IS manager review & denied to move to production
12. CM10 released to production
13. CM11 verified operational in production by user
14. CM12 management audit
15. CM13 CIO audit

Let's Make it Happpen

Categories

First, our category structure had to include categories for all of our applications and systems. The sub-category of the app/system would indicate this is related to some sort of request. For example: "Applications > Picis > Request". The Type will take care of letting us know the request is for Change.

Click to view.

Ticket Type

The easiest way to setup everything for Change Management is to use a unique Type. I picked "Change". With a unique Type reserved for only Change Management, it's very easy to point the right business rules at the right type and tickets.

Click to view.

Tasks

Our goal is to have all those CM Actions be clickable Tasks when we are viewing the ticket. The tasks will perform an action like putting in a standard comment showing the action was completed and attaching a support document.

To categorize the Tasks, I setup a Service Category for CM.

Click to view.

Next, I created a new Task. I used the default options on the first screen. I found that "logging to the incident" produced a duplicate comment record that I didn't need.

Click to view.

Using the first CM Action as an example, I set the following options.

Click to view.

The first interesting item is the HDQUERY under the "Task is available" section. This is an Advanced Condition that checks the ticket comment history to see if that CM Action has been run on that ticket before. If it hasn't been run, the Task will show up. If the Task has already run, the Task will not how up. It looks like this:

Click to view.

You can copy and paste from here, if you'd like:

HDQUERY[[SELECT TOP 1 workitem_comment 
FROM workitem_detail_view 
WHERE workitem_number = WORKITEM(workitem_number) 
AND workitem_comment LIKE '%CM01 %']]

The next significant item is the Comment under "Set these properties". It uses UBB code to make the Comment bold, underline, and a color--to make it stand out. This part is what makes the Action code become part of the ticket history once the Task is run.

Click to view.

In the same "Set these properties" section, I set "page" to "pvAttach" and "attachdesc" to the name of the specific Action code. This makes it so that when the Task is clicked, the attachment screen opens and lets the worker attach a CM document that is appropriately named.

I found it useful to set "When this task runs" to "Give the user a chance to edit the incident" so that workers could make extra notes in their comment, if need be.

The Finished Product

With all the pieces put together, we get a group of Change Management Tasks:

Click to view.

Once we run them, we get lots of pretty ticket history:

Click to view.

And, we get attachments full of "Juicy" Change Management document goodness:

Click to view.

To Make a Long Story Short

This was the way I put this process together for my company. I learned a bit while doing it and I am looking forward to the IT department buying into it. I hope it's useful to someone else out there too.

Best regards,

George