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 - Change Management and Workflow
Posted: Tue Apr 24, 2007 3:04 am Post subject: Change Management and Workflow
Hi,
First we just started using ITIL in Service Desk area. We don't have CMDB nor Service Catalog. I have question about Workflow in general. Does workflow only exist in Change according to ITIL in response to Problem management only?
Since it is so useful, I feel it should be part of request, problem, and/or configuration process too.
But our Service Desk software only has workflow in Change Management. For example, someone requests a new email account. Workflow will help us check the steps need to be done to get the request done. Is it a Change?
I feel we have to to use Change just because there is workflow function but not sure if it is correct. For example, we don't have CMDB since we are an educational organization and, users may bring in their own PC that is never going to be static. We do help them resolve their PC issues. So, should I issue a Change order if we need to modify their PC config since we need to troubleshoot their PC? Also, if a department requests a mobile device, should it be a Change order? We want to use it just because it has workflow to check the porcess but I am not sure if it is ITIL way. I am a bit confused. Thanks.
I mean steps to finish an action or task. For example, if I need to have an account created for a new user. The steps may be 1. verify HR record, 2. adding into Active Directory 3. Create mail account 4. notify the user
My concept of Change is tied to a Problem affecting the organization. Not sure if adding an account be a Change? Part of M.A.C?
And if we need to repair a computer with a virus issue, is it an Incident, Change or Problem?
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Wed Apr 25, 2007 8:15 pm Post subject:
Quote:
I mean steps to finish an action or task. For example, if I need to have an account created for a new user. The steps may be 1. verify HR record, 2. adding into Active Directory 3. Create mail account 4. notify the user
You have already defined your most of your workflow. If you condense the change process to:
Request->Assess->Authorise->Implement
you're pretty much there already. Change management can be very simple; often people think they need to make it complicated so that it is 'professional'. The opposite is true - it should be as simple as your own needs require.
Unfortunately most organisations try and create a process that captures every single possible eventuality. It takes a long time to put into action, and they end up with an unwieldy and slow process. Worse, it is hardly ever fully used because most routine changes do not need all of the possible steps in the process.
Start with the simplest process you can get away with, and build upon it as and when you see deficiencies.
Quote:
My concept of Change is tied to a Problem affecting the organization. Not sure if adding an account be a Change? Part of M.A.C?
In theory it depends what's in your CMDB - if you don't perform configuration management for something, how can you have a change for it? Of course in practice that doesn't really make much sense.
Common sense suggests if you change something in your organisation, i.e. allowing laptops onto your infrastructure, and that by doing so you expose yourself to viruses, you'll probably want to track those changes and have some process to allow them onto the network.
So I'd say yes, adding an account is a change, and you should have a change process to deal with it. Even if that process is only 'come to me so I can check your PC first'.
Quote:
And if we need to repair a computer with a virus issue, is it an Incident, Change or Problem?
This can be confusing in ITIL. An incident is something that causes an unplanned loss in service - such as a virus. Fixing the immediate problem, i.e. the virus, is part of your response to the incident and not part of change management as such.
Problem management is geared towards addressing the root cause of incidents - e.g. you have lots of virus incidents, so you then go to problem management to solve the virus issue. This might mean changing a firewall, adding software to your pc's, or scanning any pc before it is allowed on your network etc.
Finally the outcome of problem management may result in change requests to implement the fixes to the services, and might also change the change process itself relating to authorising changes.
Generally a single incident will not create a problem record, but lots of incidents of the same type should do so.
Thanks Dave for helping me understand part of my confusion. I understand fixing a virus computer is an incident but since we need to modify/change the computer configuration from the original state it came in, I feel it could be a Change for the CI. Also, the workflow processes in our helpdesk software only exists in our Change Order. I need to have it to remind staff the steps to follow when working on such computer.
Don't you think it will be a good practice if I have an incident ticket first, then attach a Change Order to it?
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Thu May 03, 2007 7:51 pm Post subject:
Quote:
Also, the workflow processes in our helpdesk software only exists in our Change Order. I need to have it to remind staff the steps to follow when working on such computer.
Ulitmately ITIL is there to give you a framework to manage your IT, and in the end how an organisation implement ITIL is driven to a large extent by the tooling they have. So if your tooling only allows you to define workflow prcesses in a change order, then that's how you'll have to do it. It is not 'best practice' according to ITIL, but it is the best practice you have in your environment, and that's what counts.
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
