Start your FREE Trial of NetHelpDesk!
Print

Change Management

As an ITIL aligned product, NHD is always developed keeping in mind the ITIL framework, and the many different aspects it covers. From Incident Management and beyond, we have great features to help make ITIL alignment easier. With Change Management, there are some great features that are already available that you can use independently, or as part of a larger overall process. These include:

    Change Management Ticket Types

    Change Management Tab (reveals for ITIL Change Management Tickets).

    Workflows and Action Buttons.

    Approval Processes.

    Custom Fields and Objects

These are detailed below on how to use them separately, and also how they may be pulled together in an overall process. If you have any questions, speak with our Support Team who are happy to help.

Our product and company has developed over many years based on Customer feedback and requirements, so if there is another way you feel would help you in this area, feel free to speak with us about your ideas. We can usually add in new features quickly, and usually free of charge.


Ticket Types

Think back to a time when technology didn’t exist, and your team used pieces of paper as forms with boxes of information to complete, based on what type of information was being recorded.

Each form would capture information specifically tailored to its form type, so a support ticket would maybe include the piece of equipment affected, or a complaints ticket could capture the person complaining’s availability, or a sales enquiry would capture when an item needs to be implemented by, and so on.


What does NetHelpDesk offer?

NetHelpDesk gives you “Ticket Types”, and each one represents that paper “form”, and you can tailor what is captured in each one. There is no limit to the number of Ticket Types that can be specified, and controls available to make certain forms available only to Agents internally, and not end-users via the web portal, or if they are available, what fields appear within that form to the end-user.

Each Ticket Type comes with the ability to be called whatever you like, and have a set of pre-defined defaults for that type of Ticket.

These can then be specified in other features such as Auto Tickets. We offer an introduction to the ITIL framework within NetHelpDesk, the standard setup required for an IT service desk. These are only suggestions, and NetHelpDesk will use whatever you specify. All pre-existing Ticket Types can be edited and new ones added and deleted, as necessary.


ITIL Change Management

We go one step further with ITIL as well, where you can specify multiple Ticket Types as one ITIL Ticket Type, and still be ITIL compliant. So an Asset Change, Process Change or Responsibility Change could be 3 separate forms or “Ticket Type”, and all marked with an ITIL Ticket Type of “Change Ticket”.

This ITIL Ticket Type ‘category’ will link these three forms together under the ITIL Change Management banner, and will be the starting point of your Change Management processes in NetHelpDesk.

NetHelpDesk offer an ITIL consultancy as part of the suite of services. Speak with your Account Manager for more information.


Ticket Type Preferences, Defaults and Restrictions

The purpose of Ticket Types essentially, is to set default values for a ticket, and to control which fields are visible in a new ticket (including Custom Fields).

To setup Ticket Types, click N > Setup > Main Configuration > Tickets > Ticket Types.

In each Ticket Type, a set of details and preferences can be specified within it, such as:

    a) Sequence it appears in the list.

    b) Individual Ticket Type description.

    c) ITIL Ticket Type category (if being used).

    d) Whether it is visible in lists to your Agent Users.

    e) If it is visible to your end-users via their web interface.

    f) Keep the Account Manager informed if that Ticket Type is created.

    g) Whether the form is available from the smartphone apps.

    h) Start an Approval process automatically when the ticket is raised.

    i) Override all charge rates on actions added to those tickets of this type.

    j) Specify a Calendar colour, to separate easily in the Calendar view.

    k) Set the status after an end-user adds an update to those types of tickets.

    l) Set the status after an end-user reopens a closed ticket of this type.

    m) Choose whether this ticket type can be reopened or not after closure.

    n) Have a separate report layout for this type of ticket.

    o) Automatically BCC specified e-mail address(es).

    p) Override the e-mail sent to Customer at the Client/Area level.

In each Ticket Type, a set of defaults can be specified within it, such as:

    a) Initial Status

    b) Priority

    c) Section and Agent

    d) Category from Category Group 1

    e) Category from Category Group 2

    f) Category from Category Group 3

    g) Category from Category Group 4

    h) An overriding Mailbox

    i) An overriding SLA group

    j) An overriding Workflow procedure.

    k) An overriding Script to use

    l) Quote Layout

    m) Default Send Acknowledgment Override.

In each Ticket Type, a set of restrictions can also be added. For example, it is possible to specify users in your database who will receive closure e-mails when calls of this Ticket Type are closed. This can be useful if you wish to include people in your company who are not Agents, but are still involved with supporting your external end-users.

You can design the Ticket Type to capture data in fields of your choosing. They can be system fields, or custom fields you choose yourselves.

Specify values that are restricted to this Ticket Type for:

    a) Status

    b) Action Buttons

    c) Category 1/2/3/4

These restrictions are particularly useful when using a Ticket Type or Types for a Change Management process, separate from every day tickets.


Ticket Type Field List and Custom Fields

Each Ticket Type also has its own fields that can also be configured, by clicking Field List and Custom Fields button in the main menu, or the Ticket Type defaults page itself.

    1) By default, any fields that are dragged and dropped from the Available Fields list to the Fields That Show list are visible to all users.

    2) This can be changed by double clicking on the field when in the Fields That Show list.

    3) Some fields are specifically for certain functionality, such as Project Time and Money, which should be quite self-explanatory from their descriptions. If they don’t apply to your change processes, then there is no need to add them to the Fields That Show list.

    4) Ticket Types can be also be restricted to Agents, and/or to Customers/Areas.

Here is a list of available predefined fields that would be useful in Change Management:


Field Name

Description

Summary

Main description of the Ticket (Subject of e-mail)

Details

Further information about the Ticket (Body of e-mail)

Category

Drop down to select choice from Category Group 1

Priority

Number order based on SLA Response and Resolution timing.

Section

Which Team of Agents to choose from.

Agent

Which specific member of team to assign it to.

Send E-mail

Send acknowledgement e-mail to end-user.

Asset

Which device is associated with this Ticket.

Category 2

Drop down to select choice from Category Group 2

Category 3

Drop down to select choice from Category Group 3

Category 4

Drop down to select choice from Category Group 4

SLA

Choose Service Level Agreement group of priorities applies.

Date/Time Occurred

Adjust the data of when call is raised (backdating)

Planned Date

Specify a date when something next needs to be done by.

Reported By

Who reported Ticket, if different from user it’s assigned to.

Estimated Time

What is the approximate length of time to complete Ticket.

Show on Web

Will end user be able to see this Ticket via the web interface.

Exclude from SLA

Opt out of tracking response and resolution times for Ticket.

User Contacted

If raised for someone else, are they aware of the Ticket?

Resolution Date

Adjust the standard resolution date on the priority.

Fault Code/Class of Fault

Specify a list of fault codes to choose from in Lookup Codes.

Site

Which site is affected if different from user’s normal site.

Impact

Specify the amount of effect the Ticket has.

Urgency

Specify how fast this Ticket is needed.

E-mail To List

Who is to be included in communications.

E-mail CC List

Who is to be included in communications.

Source

How was this call raised? By phone, E-mail etc.


There are other fields available in these lists, but these are the most useful for the Change Management Process. Add your own custom fields in the Custom Objects area of Main Configuration setup area. Another guide is available to assist with using this area in NetHelpDesk, and we offer professional services that cover all aspects of the main configuration area.

You can also toggle Advanced Field Visibility in this area. NetHelpDesk is one of few applications in Help Desk Software that allows this to be done. This means that further fields become available depending on what was selected before. This will apply to all users that can see this field.


Change Management Tab

Tickets that have an ITIL Ticket Type of Change Ticket, will be the only ticket types where a unique Change Management tab will appear on those tickets.

Change Management 1

The tab, or its fields, won’t be available on the new ticket screen, as that is the area for creating a change ticket, and how the change came about. The Summary and Details fields are excellent for this.

The Change Management tab reveals the items you need for a Managed Change process:


Justification

What are the reasons for this change within your business, and why is it so important? Provide an overview of the requirements, background beyond the ticket’s details filed, and any relevant information that would enable the approvers of change to assess and progress the ticket for change.

Impact Category

What is the overall impact of the change to the business? High Impact, Medium Impact, Low Impact and Unknown are the defaults, but this list can be added to, edited or options deleted, as you require.

Impact Description

What areas of your business will be impacted by the change? Provide an overview of what areas are affected, and consultation notes with those teams or areas. Have senior members been advised of the potential impact to their area? Would they need to be included in your planning and testing of the change.

Risk Category

What is the overall risk of the change to the business? High Risk, Medium Risk, Low Risk and Unknown are the defaults, but this list can be added to, edited or options deleted, as you require.

Risk Description

What are the risks of this change? Think about the higher risks, the medium risks and the low risks despite the risk category. Advise your approvers if there are any negative issues or causes that could arise from this change, that would have an adverse effect on operations. Are there any risks in not implementing the change?

Back out Plan

What is the plan to back out the changes, should anything go wrong? If the change has an adverse effect that is only identified after the change is made (unforeseen circumstances) then, a plan to restore back, as if the change had never been implemented in the first place. Are there any changes that need to be made if the change is successful, that is not covered in the current back out plan? Are your Disaster Recovery (DR) processes affected?

Communication Plan

What communications should be provided, to whom and when? Are communications required before the change, after the change, or both. Who is to be notified as a minimum? Who will send these communications? How will they be structured? Is there anything that shouldn’t be communicated?

Testing Plan

What testing is required to confirm that the change has been successfully implemented? What happens if there is a failure in testing? Who assesses testing success or failure? Are there any preconditions of the change, that need to be done before testing can commence? Is there a key, core list of things that are fundamental to the change implementation’s success?

User Defined Fields

These five fields allow for the capture of data that is specific to your organisation, and allows you to customise the form how you would like it. Who are the key stakeholders involved in this change? Which departments must be informed of the change as a matter of courtesy? Whatever you wish to capture here, feel free to do so. The labels can be customised in the change management setup in the main configuration area of NetHelpDesk.


Approval Processing

With most change management processes, approvals are usually needed by key members of organisations to sign off on the changes before they are implemented. It is usually something that comes after the change management tab has been completed, but prior to the work beginning.

The Approval processes in NetHelpDesk allow for multiple step, multiple sequencing approval methods, which can be started in one of three ways:

Change Management 2

NetHelpDesk can create approval processing for tickets. In your organisation, you may need different types of approval for different types of call. A ticket can be approved in multiple ways in NetHelpDesk:

Option e) allows for someone to approve a process for multiple sites, whereas option c) allows for someone to approve a process at just that one site.


Create an Approval Process


Approval by Change Advice Board (CAB)

If an approval process is to notify a group of Agents, instead of just one Agent, the CAB option is available.


Approval by Defined End User

At each Site level, End Users can be defined under each Site that can approve as part of an approval process.


Approval by “Department” Head

A “Department” can be created that allows one End-User to be nominated as the “Head of Department”. This feature doesn’t necessarily refer to a Department within your organisation, or your Customer’s organisation. It merely allows one person to be nominated as the “Head Approver” for users over multiple sites.


Approval Process Rules

NetHelpDesk allows you to set option rules that can be used in an approval process. The first rule in the sequence that matched the values that you choose is used.


Workflows

Integrating work flow procedures with change management and approval processing, is an excellent way to improve efficiency and streamline your internal processes. NetHelpDesk offers a multitude of options to help your teams with their workload, and ensure a higher quality of work, especially when being audited.

Integrating your work flows and processes that you and your team follow is important, so we make NHD incredibly flexible, to work around how you currently work.


What are Workflows in NHD?

Workflows in NHD control the action buttons, so using that guide alongside this one is very useful. Whilst we ship NHD with sensible action buttons, the functionality can be edited and adapted as needed. Here are some standard action buttons we ship:

Change Management 3

Most action buttons will produce action screens, where you can add notes, and capture internal information easily. Some don’t have to, but we will come to that later. Here is an example of an action screen:

Change Management 4

All action screens, if set to appear, will display:


When can Action Buttons be made available?

These action buttons can then be made available:


What Default Values for Actions Are Available?

You can also set a host of options of default values at the action button level:

You don’t have to set these defaults. As you see, there are lots of choice available for you. You can keep these simple, or make them complex as you need to. The other setting is whether the action button is available to “all workflows” or if deselected, only available on the workflows you specify them in.


High Level Overview of Workflow Setup

A high level overview of the workflow steps are as follows:

PLEASE NOTE: These three steps must be completed before moving on to creating a workflow process. Otherwise, there will be no actions to specify in the workflow sequences.

If you don’t, the template’s ticket type will override the ticket’s default value when selected, and remove any workflows associated with the previous ticket type.

So, to create the action buttons you need, and set their defaults (steps 1 and 2) using the Action Button Guide. Once they are ready, the workflow can be configured (step 3).


Create a Workflow

To define a workflow, specifying steps and which action buttons will appear:

Change Management 5
Change Management 6
Change Management 7

Unless you have specified “Do Not Show Screen” option on the action defaults, the action screen will appear when you click it. When clicking Save, the workflow assumes that the action is completed, and moves onto the next step in the sequence. If an action button is available, whether the workflow is active or not, you can use this as many times as you like, without moving the sequence steps forward. It is only action buttons specified in the workflow sequential steps that move the workflow forward.

Should you have any questions regarding any steps in this guide, please speak with the NetHelpDesk Support Team.

Our software is available on multiple platforms...

NetHelpDesk is available on a range of devices with industry-leading functionality available throughout.

  • Windows Phone

    Windows Phone

  • Android

    Android

  • iPhone

    iPhone

  • BlackBerry

    BlackBerry

  • Tablets

    Tablets

  • Windows

    Windows

Close

Cookie Policy

We use cookies to enhance your experience on our web site. By using our website or closing this message, you are agreeing to our Cookie Policy.