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
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....
Posted: Fri Aug 10, 2007 6:42 pm Post subject: Changing Service Desk tools....
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.
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Sat Aug 11, 2007 12:18 am Post subject:
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.
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.
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Aug 27, 2007 5:21 am Post subject:
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.
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.
Joined: Aug 31, 2004 Posts: 28 Location: South East Asia (Singapore, Malaysia, Thailand, Indonesia, Philippines)
Posted: Tue Aug 28, 2007 2:10 am Post subject:
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 ! ...
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Aug 28, 2007 12:23 pm Post subject:
Hello ITIL_Asia,
Please find my comments embedded, below...
itil_asia wrote:
It's not business critical but it is time critical ! ...
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.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
