Ability to change an Incident to a Change Request

Open discussion about our Alloy Navigator 5 application

Ability to change an Incident to a Change Request

Postby VTBanker on Sat Jun 23, 2007 8:50 am

Since end users only have the ability to submit an incident from the web portal I would like the ability to change an Incident to a Change Request when the end user is requestion a software upgrade, hardware upgrade or install.
User avatar
VTBanker
Senior
 
Posts: 43
Joined: Mon May 17, 2004 3:46 pm
Location: Morrisville, Vermont

Postby pille on Mon Jun 25, 2007 3:35 pm

It's a common misconception that change requests are meant to be for items like that. In actuality, change requests were meant to be used for infrastructure type changes.

Take a look at this knowledge base article for reference. It goes over the different ticket types, their purposes as well as the inspiration.

Alloy Navigator 5 Ticket Type Explanation
http://support.alloy-software.com/?mode ... d=KB001065

==================================

Alloy Navigator 5 Ticket Type Explanation
Tickets in A5 are broken up into 4 different types of tickets and those ticket types are based on the ITIL framework. You can get more information about ITIL from the following sources:

ITIL - http://www.itil.co.uk/
ITIL (Wikipedia) - http://en.wikipedia.org/wiki/ITIL


The following descriptions are designed to be a very casual explanation of practical use geared towards someone who may not be familiar with ITIL.

Incidents were designed to be used as the ticket type customers use to report issues and they are the only ticket that customers will see in the Self Service Web Portal. All other ticket types are considered to be internal IT related ticket types. A typical incident would be, "I can't access the internet", "I can't login to the network" or "I have an issue with Microsoft Word". These would be one time occurences not affecting anyone else. Incidents can also be requests such as "I need Adobe Acrobat installed" or "I need a new computer".

When you have an issue that affects multiple customers you may want to create a problem ticket. Problem tickets are used by IT to manage outages or large groups of related incidents. You can relate incidents to problems and then manage them all from the problem ticket instead of trying to manage each one individually. For instance, if 100 cusotmers call and say they can't access the internet, chances are you have a much larger issue than you would have if it was only one customer. In this case you would create a problem ticket and relate all the related incidents to it. Being able to do this provides you with great benefits such as being able to see the incidents all in once place, determine how far reaching the issue is and use business logic to automate communication to everyone effected.

Work Orders can be thought of as tasks and can be used for greater efficiency in situations such as new user requests. You may need to have several tasks handled when a new user request comes in such as desktop setup, network account setup, etc. Instead of opening several incidents or passing the single incident from group to group, you can create work orders for each of the tasks required to complete the request. This way, all parties can work on their tasks independantly at the same time with their own deadlines, etc. You can also monitor all work orders from their parent ticket similar to monitoring related incidents from problem tickets.

Change Requests are typically used for IT related infrastructure changes where the potential of affecting multiple customers exists. Typically companies will have an approval system for these where IT managers and sometimes department managers sign off on changes, but it's not needed. For instance, you may be upgrading your mail server. If the upgrade doesn't go as planned, many people could be without email if the upgrade doesn't go as planned. Because of that you may want to monitor the process with a change request so that everyone involved in providing service to customers knows about the change.

Now, given all I've said here, it doesn't mean this is the only way to use the ticket types. ITIL is a framework and not law so you could do what you'd like with each ticket type. Just keep in mind that this is what was in mind when the application was designed.
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA

Postby pille on Mon Jun 25, 2007 3:37 pm

Additionally, an Incident can of course be the source for a Change Request. Maybe someone from Finance suggests a change to the Production system.

In that case, instead of changing the Incident into a Change Request, it would be best to create a Change Request and link it back to the Incident. This way you maintain the ability to communicate with the customer through the Incident and keep the origin of the request intact.
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA

Postby VTBanker on Thu Jun 28, 2007 12:38 pm

Paul,
I agree with what you are saying here and that is pretty much how we are using the system. The difference is that our regulators are considering a request such as "I need adobe reader installed" on a PC a change and we need to report on that, or when the finance dept requests an update to thier finance software that would also be considered a change. The way we are doing it now is when an Incident comes in with a request we do create a Change Request and relate the ticket to it. I guess I was looking for more of a lazy man's way of just changing that Incident into a Change Request without have to create a new one. Either way will work and I guess it's not a big deal.
User avatar
VTBanker
Senior
 
Posts: 43
Joined: Mon May 17, 2004 3:46 pm
Location: Morrisville, Vermont

Postby pille on Thu Jun 28, 2007 1:54 pm

Ok, I see. If you've already got a process and it works, nevermind me! :)

But, typically in your case, the best practice is usually to use the type field in incidents to make the distinction.

For instance, you would have values for Type, Issue and Request. A customer asking for software would be a request while an issue would be an issue. This allows you to track and report on Requests/Changes while still keeping the integrity of a Change Request.
Contact Technical Services directly:
support@alloy-software.com
http://support.alloy-software.com

Paul Ille
Alloy Software
Maximize your IT Universe
Follow us on Twitter: http://twitter.com/alloysoftware
Image
User avatar
pille
Alloy Software
 
Posts: 473
Joined: Thu Aug 11, 2005 3:11 pm
Location: New Jersey, USA


Return to Alloy Navigator 5 Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron