First thing to say is Approvals, as always KACE engineering seems to think that the only time you will need an approval is as any ticket is logged, I can remember back to 5.3 when you could add in an approval step at any time in the ticket lifecycle. Guys, if you are listening, this would be easier if allow an approval to be set when a ticket reaches a user defined status and when approved it then sets the ticket to another user defined status? So using the approval loop within KACE will really not help you unless you have a process and child tickets, one of which is the CAB approval.

Second thing to say is that if you are looking to KACE to perform a voting style of CAB, whereby the majority of CAB members vote yes and the change is approved then KACE is probably not mature enough for you. Although I will point out, as in previous discussions, the CAB may approve but actually it is just down top one resource, the Change Manager to actually approve the change and set any implementation steps you may have in process.

We always start with the Change process itself. I always ask customers looking for Change Management if they have a process, and if the answer is yes then I ask them to produce a printed copy of that process. In the majority of cases customers then admit that a Change Process is a desirable and as such not yet formally documented or implemented. In which case we look at a standard process, much like the following diagram.

In this simple flow we can see that there are a number of paths depending on the urgency and the type of change, but there are also steps in the process that are common to any type of change, that of build, approval and implementation.

The key to managing Change within a KACE queue is the status of the Request for Change (RFC). As the ticket within the queue moves through the process flow, it will change status. This illustrates where the request is, it makes Change reporting much easier and also it helps us to configure the queue.

With a standard ticket queue the status is usually open to be changed by any analyst with the correct rights to the field. After all it is essential when wanting to resolve or close the ticket to be able to set the status appropriately. 

However, within the Change Queue we make the Status a read only field and the status only changes when we update the ticket with appropriate data.

An example of how the status will flow within this process is shown in the following diagram

So an RFC Ticket will start life with a status of New RFC, then will change to RFC Build, RFC Pending approval etc as the ticket is updated within the queue.

Ticket rules are created to deal with every stage of the process, in each case looking for data to be added, when it is, updating the status and also using the email function within the ticket rule to send alerts or to ask the next person in the process to contribute.

We use the following fields, those marked * are custom fields added::

Change Title – Should contain the title of the change, this should be descriptive and unique where possible.

Change Summary Details – Provide basic details of the change in the Comment box.

Status – This field is read only and indicates at what stage the Change process is for the ticket.

Category – Enter a category and subcategory to describe the type of change that is being logged.

Business Impact* – Select a value that reflects the impact that the change may have on the business from the following:

·         Enterprise

·         Department

·         User Group

·         Single User

·         Zero user Impact

Next Action* – The Next Action drop down is used to carry out specific tasks at various stages in the change process.

Change Type* – Select a value shows the type of change that is being logged from the following:

·         Urgent

·         Standard

·         Non Standard

Asset/Device – if the affected Asset or Device is known it can be selected from the Asset or Device list.

Note: To log the change, and obtain a reference number only the Change Title is required, once saved the Change data can be added at the build stage of the process

To save the Change Request, press the Save or Apply Changes button.

To build the RFC, the analyst must open the RFC and complete the following fields.

Category – If not already selected, enter a category and subcategory to describe the type of change that is being logged.

Business Impact* – If not already selected, select a value that reflects the impact that the change may have on the business from the following:

·         Enterprise

·         Department

·         User Group

·         Single User

·         Zero user Impact

Change Type – Select a value shows the type of change that is being logged from the following:

·         Urgent

·         Standard

·         Non Standard

Implementation Plan* – Replace the default text, “Add Implementation Plan Here….” by entering the steps that will need to be followed to implement the change.

Test Plan* – Replace the default text, “Add Test Plan Here….” by entering the steps that will need to be followed to test and prove that the implementation plan was followed and that the change was successful.

Back Out Plan* – Replacing the default text, “Add Back-out Plan Here….” enter the steps that will need to Roll Back the change if to the change is not successful.

Due Date – If known a Due date may be entered to show when the change should be scheduled for completion

Once these fields have been completed the RFC build is complete. Save the Change Request by pressing the Save or Apply Changes button. The RFC must now be forwarded to an approver for the Change to be assessed and approved.

As we navigate through the stages of the change the read only Status field updates and the Ticket Logging information field updates with instructions as to how to move the change to the next status.

With approvals, we have a defined approver, the change manager, they will get an email to approve and they can either respond "Approved", we can setup action buttons  in their Outlook mail client or they can edit the RFC directly in KACE.

We also have custom rules running to ensure that only the Change Manager can approve the change ( i.e. change the value in a certain field at a certain stage of the process) Otherwise the value is reset and an email sent to the Change manager to let them know someone has tried to edit the change without rights.

Finally we also have custom rules that reset the data values appropriately if an RFC is cancelled or rejected, placing the ticket in a state that is correct to place it back in the process flow at the appropriate place.

Once we have a tested the queue, we then build reports so that we can get stats, for example

• ·         Current Changes By Status – New RFC
  
• ·         Current Changes By Status – RFC Build
  
• ·         Current Changes By Status – RFC Pending Approval
  
• ·         Current Changes By Status – RFC Pending Implementation
  
• ·         Change Completed this Month
  
• ·         Changes Completed this Week
  
• ·         New Changes Logged this Month
  
• ·         New Changes logged this Week
  
• ·         Cancelled RFC report
  

We can even set up our DASHboard product to show you Change Management stats in real time, check it out here

All of this usually takes us about 5 days to setup, which includes consulting with the customer, editing the process flow before build and training and documentation at the end.

All of which adds up to yes, I think we can do Change Management within KACE and there are customers out there today managing Change in this way.

For more information feel free to contact us at TheIndigoTeam@IndigoMountain.co.uk or visit us at www.indigomountain.co.uk