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 - Service Desk Application Policy Document
Posted: Tue Oct 21, 2008 5:22 am Post subject: Service Desk Application Policy Document
Hello,
We have an application that automates most of the activities involved with SD, IM and PM. I would like to create a policy document for the application which clearly states rules surrounding its development and maintenance.
To give you some examples; we do not wish people to be granted access to the app without completing the appropriate training. We don't want new incident areas/types being created without the appropriate level of approval etc.
I'm beginning to write a set of rules/policies along those lines but wondered if anyone had gone through a similar exercise and is willing to share their experience?
Joined: Mar 04, 2008 Posts: 1277 Location: Newcastle-under-Lyme
Posted: Tue Oct 21, 2008 6:42 pm Post subject:
Matt,
is there not a danger that you are allowing the application (tool) to drive your service? you make it sound like everyone will dive in to this app. and just try to use it (albeit after training them).
But, in truth, people will arrive at the app. through following a process and they will be logged in for a purpose within that process. If people's roles and responsibilities are already delineated, then they know what to do appropriately.
If this is a new tool, then would it not be better to modify service management policies and procedures already in place than to design specific tool use policies? This keeps control of strategy where it belongs?
On the matter of policing the use of the app., does it not allow security at various functional levels such that only authorised personnel can perform specific actions?
Things like adding an incident type must go through change management and you would expect that only the incident manager could approve it. but that is dependent on your policies around incident management, not around your app.
The other difficulty with drawing up detailed rules about how to use the app. is that you have to cover everything imaginable. Whereas, the other way you can simply say "don't mess; just do what you are supposed to do." _________________ "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
Thanks for the response. I've attempted to answer some of your questions.
Quote:
is there not a danger that you are allowing the application (tool) to drive your service? you make it sound like everyone will dive in to this app. and just try to use it (albeit after training them)."
People aren't allowed access to the app without going through the appropriate channels, so this is all in hand. However, we need somewhere to document our policies in this area to which people can be directed if there are any questions.
Quote:
If this is a new tool, then would it not be better to modify service management policies and procedures already in place than to design specific tool use policies? This keeps control of strategy where it belongs?"
This is the crux of it actually. We don't have any service management policies as such. Rather we have processes which outline the way we should work to support and deliver our services. Those processes are well documented with Sub Processes, Activities, Procedures and Work Instructions.
Quote:
On the matter of policing the use of the app., does it not allow security at various functional levels such that only authorised personnel can perform specific actions?
Yes it does but it's not documented what those roles are and the corresponding actions permitted. But your theme is understood. What we should probably look at is policies for the process rather than the application itself. This sounds like good advice given that more than one process uses the application.
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
