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 - Merging ITIL functions and processes
Posted: Thu Jan 21, 2010 2:01 am Post subject: Merging ITIL functions and processes
Hello guys,
For historical reasons, our organization is divided into two different divisions, each one with its own IT support teams and processes.
That means two service desks, two IM processes, two CFG processes with different databases and so forth.
Now there is a project to merge these separate IT teams and processes into one single IT support division, which will be responsible for the whole organization’s IT support.
That means one service desk with one IM process, one CFG process with a single database, etc…
All processes are documented and executed following ITIL standards, but with different maturity levels. One division is clearly ahead of the other in terms of documentation and maturity.
I would be interested in hearing any suggestions, opinions, observations from those who had this experience of merging IT divisions.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Jan 21, 2010 2:27 am Post subject: Re: Merging ITIL functions and processes
ChasingSleep wrote:
All processes are documented and executed following ITIL standards
Oh no the are not!!!
You really need better control of your fingers in the keyboard. How could you type "standards" when you mean to type "guidance"?
My advice?
Step one - make sure everyone realizes the distinction I made above.
Step 1b - put away the ITIL books for a moment.
Step two - derive from the two systems and from a broader look at the services to be provided (including the customer(s) perspective) what is required of your management system.
Step three - (it gets tricky now) look at what you've got with an eye to what bits fit what you want. Trouble is you might want to start from scratch (but keeping all your data and operational processes that work).
Step four - design your knew processes based on what you want. You can sneak some looks at your ITIL books here to help you think through the design.
Step five - build your new processes, "pasting" in bits from the old ones that fit.
No. I'm rambling. This needs more thought.
What I can say is that it is not a good idea to get into a debate about "mine's better than yours" between the groups. and its not a good thing to say "which one shall we use for this bit?"
You have to consider what the implications of scale are. Even if you get staff reductions you are likely to have more people than either system had by itself. does that mean you can better resource, say, problem management or (at last) do some real capacity management?
Retraining is going to be an issue and this will also be easier if it happens to everyone and they all see it as a new system, however similar it may be.
Managing customer/user expectations and reactions might be fun also.
Bit of a brain dump. hope some of it is relevant and helps. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
You really need better control of your fingers in the keyboard. How could you type "standards" when you mean to type "guidance"?
Com'on man, that's why I'm chasing sleep...
Thanks for the advices. Indeed, I think the main issues here is the risk of "my process is better then your process, so I win. You change, not me" kind of thing.
I am looking for ways to avoid this, or at least to mitigate this risk. I think focusing on the requirements rather than which piece to use at each time is a good practice for this situation.
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Fri Jan 22, 2010 1:04 pm Post subject:
Hi fellas,
I made up the following words for this case:
"It is easier inventing the wheel than re-inventing it".
CS, I can't give you better idea than what Diarmid's given.
I only want to say that the processes has their respective owner(s) right?
A simple suggestion: lay it back to the owners. Let them decide whether there will be one or many processes.
If they don't know what to decide, the suggestion is what I use to do, probably it could fit your situation.
If you said that there is a project to merge the two "processes" then you must have a kind of PMO (Project Management Office) where you can discuss any obstructions, highlights, etc. You can use such forum to find the way out.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Fri Jan 22, 2010 7:30 pm Post subject:
ChasingSleep wrote:
The problem is that there is only one requirement: « Let's merge it! »
There is only one requirement, but it is to do good service management!
Presumably the requirement to merge has been identified without the analysis of the costs and benefits (... and possible problems ). That would be real world.
Nevertheless it is likely that merging is beneficial (sometimes common sense works).
How you go about merging will determine the effectiveness and efficiency for some time to come.
Just selecting one or the other process is guaranteed cheaper, probably for the first eight weeks.
Analysing and specifying requirements and then building a system, using whatever bits you have that already meet the specs, is almost guaranteed to be cheaper after a year (it will be if you get the specs right).
There are two possible situations: ehther the two systems are well geared to their respective services (irrespective of their maturity level) or they are not. In the first case, simply imposing one system on the other's services will be reduce the quality. In the second case why would you want to use a system for a set of services when it isn't even very good at what it does now? _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
My first thought would be to ask myself why the two processes are different. Are there different service levels? If so why? Are incidents categorised/assigned differently? If so why? Etc. etc.
By asking yourself these questions you can better understand the differences, the reasons for the differences and if there is still a need for differences when you are finished.
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
). That would be real world.
