Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ACrofts
New Today: 21
New Yesterday: 54
Overall: 146234

People Online:
Visitors: 54
Members: 1
Total: 55 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Changing Service Desk tools....
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Changing Service Desk tools....

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
sbullough
Newbie
Newbie


Joined: Aug 10, 2007
Posts: 2

PostPosted: Fri Aug 10, 2007 6:42 pm    Post subject: Changing Service Desk tools.... Reply with quote

Hi,

Not too sure whther I've put this in the right forum, but here goes...

I am involved in a project to replace an existing Service Desk tool, for which we have 2 options for implementation:

    To run the 2 tools in tandem for a while, running down the open calls in the old tool whilst logging new incidents in the new tool

    Migrating all open incidents from the old tool into the new.


It's worth bearing in mind that the new tool is not an upgrade from the old tool, but a completely different tool. I mention this as the file structures would be completely different.

There are pros and cons for both, but wondered if anyone has gone through this 'pain' and what your recommendations would be.

Thanks in advance,
Simon
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3313
Location: London, UK

PostPosted: Fri Aug 10, 2007 6:45 pm    Post subject: Reply with quote

Do the first.

Have a dead day when all the new calls are raised on the new system.

Then have a dedicated team clear all the old system tickets

Hint: have them start now !!!

Try to get all the open Incidents and problems closed on the old system.

If there are any that cant be closed, you need to look whether you transfer
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Sat Aug 11, 2007 12:18 am    Post subject: Reply with quote

I have done the second option and don't recommend it. It would have been far easier to do a complete switch over and have the old tool available as an archive for reference purposes only.

You will have to do a lot of work to close any tickets in the old system and migrate the few ones that can't be closed into the new, but it is nothing compared to the effort required to migrate the entire history from the old to the new.
Back to top
View user's profile
gramsay
Newbie
Newbie


Joined: Jan 05, 2007
Posts: 16

PostPosted: Mon Aug 13, 2007 10:01 pm    Post subject: Reply with quote

We've just changed our software.
We logged all new calls on the new system and kept the old system live for closing off old calls and orders (we use our system for ordering also).
After a month we re-keyed any calls that were still being worked on and closed down the rest.
Back to top
View user's profile
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Wed Aug 15, 2007 12:09 am    Post subject: Reply with quote

by experience, I would advise to proceed as follows:

* 1)start using the new system for new calls, and carry on using the old one for existing incidents up to their closure.
* 2)at a certain date, convert all open tickets from old system to new one
* plan and arrange in advance for transfering reporting and statistical data from old system to new one on date 2) , so you don't lose visibility on your quality indicators.

br
JP
_________________
JP Gilles
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Aug 27, 2007 5:21 am    Post subject: Reply with quote

Hello Simon,

We help enterprises go through this pain all the time.

My recommendation is that if you're plan is to decommission the old tool, you're almost always better off migrating all your data into the new took, quickly, and instantly shut down the old tool and start using the new tool.

Why?...

1: There is nothing about such a tool that is business critical. In other words, even if the new tool hiccups, it won't shut down your business.
2: It's expensive and time consuming to run two system, simultaneously
3: Time is critical. Getting it all done and moving on will add more value in the short term and the long term.

The key is to simply make sure that all old data is discernible in the new system, so that you can quickly recall it, when needed, and can identify it as being from the old system, very quickly and obviously.

We find that most enterprises that perform parallel runs usually regret having done so, as they usually realize with hindsight that it's not that hard to just do it right and shut down the old system, immediately.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Hedge
Newbie
Newbie


Joined: Aug 27, 2007
Posts: 2

PostPosted: Tue Aug 28, 2007 12:29 am    Post subject: Reply with quote

I used to work for a company that offered a web based incident management tool, more often than not providing helpdesk services as well. With most cases client companies had to deal with their existing tool being decomissioned and data being imported, somewhat the same situation you find yourself in now. (Offering an oursourced helpdesk meant we often couldn't use the client's old tool so we had to do a fast changeover - - lots of pain was always involved.)

I'd recommend evaluating data and seeing how an import / immediate changeover scenario could be put in place. One of the difficulties we used to face was importing data from a system like Remedy to our activity-based system. While Remedy had assignments with timestamps, any updates tended to be mashed together.

If historical incidents can be imported, I don't see why open tickets cannot. Granted that while they may not be robust as incidents created from scratch in the new system, you still maintain historical data and no longer need a second live production environment.
Back to top
View user's profile
itil_asia
Itiler


Joined: Aug 31, 2004
Posts: 28
Location: South East Asia (Singapore, Malaysia, Thailand, Indonesia, Philippines)

PostPosted: Tue Aug 28, 2007 2:10 am    Post subject: Reply with quote

Guerino1 wrote:
Hello Simon,

1: There is nothing about such a tool that is business critical. In other words, even if the new tool hiccups, it won't shut down your business.
2: It's expensive and time consuming to run two system, simultaneously
3: Time is critical. Getting it all done and moving on will add more value in the short term and the long term.

The key is to simply make sure that all old data is discernible in the new system, so that you can quickly recall it, when needed, and can identify it as being from the old system, very quickly and obviously.

We find that most enterprises that perform parallel runs usually regret having done so, as they usually realize with hindsight that it's not that hard to just do it right and shut down the old system, immediately.


It's not business critical but it is time critical ! ... Rolling Eyes

A bit sarcastic I know, but there are a few contradictions in those lines.

1. If not being able to access the service desk has so little impact to the business, why even bother to migrate the old data.

2. Cost of migrating the data more than often higher than a short parallel run (a few days / weeks maybe). Data migration works well when you do an upgrade ... oh, except if you have done a few customizations.

3. As the service desk data migrated gets older, does it provide additional value? ... I'm afraid, it's not like wine.

There are cases when it is a MUST to migrate the data, but those are rare ... in the IT Service Desk space.

Always challenge the business needs to migrate the old data.
Back to top
View user's profile Send e-mail Yahoo Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Tue Aug 28, 2007 12:23 pm    Post subject: Reply with quote

Hello ITIL_Asia,

Please find my comments embedded, below...

itil_asia wrote:
It's not business critical but it is time critical ! ... Rolling Eyes

A bit sarcastic I know, but there are a few contradictions in those lines.

1. If not being able to access the service desk has so little impact to the business, why even bother to migrate the old data.


Who said that not being able to access the Service Desk had little or no impact on an enterprise? We're talking about the tool that the Service Desk uses, not the Service Desk, itself. In this case, all data would be migrated into the new system and instantly available. I also stipulated that it should be properly tagged so that it can be distinguished from all new data that's input into the system.

Quote:
2. Cost of migrating the data more than often higher than a short parallel run (a few days / weeks maybe). Data migration works well when you do an upgrade ... oh, except if you have done a few customizations.


The cost of migrating the data is definitely something to consider, as it requires development work to extract from the old, map to the new, and upload into the new (to oversimplify the process).

If it's ok for your enterprise to throw away old data, then go ahead and do it. However, that doesn't say much for the value of your data, does it? In most cases, enterprises will keep the older data so that they can use it as a knowledge history/base that they can look through to address future incidents that may have already been addressed in the past.

Quote:
3. As the service desk data migrated gets older, does it provide additional value? ... I'm afraid, it's not like wine.


Again, it depends on how you use it...

1: As a knowledge history
2: If you use it to drive historical trends and patterns that help manage your business(es) more effectively
3: As a way to profile your customer(s)
Etc.

Quote:
There are cases when it is a MUST to migrate the data, but those are rare ... in the IT Service Desk space.


Actually, they're not rare at all. We find that most mid-sized to larger enterprises almost always want to migrate their data. It's usually the smaller ones, the ones with little accumulated data, that will tend to walk away from the old repositories.

Quote:
Always challenge the business needs to migrate the old data.


I agree with this. However, there are definitely many times when it absolutely makes sense to do so.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.