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: NicolaMcKi
New Today: 37
New Yesterday: 97
Overall: 149985

People Online:
Visitors: 40
Members: 2
Total: 42 .

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 - Functional notification
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Functional notification

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
Toursiveux
Newbie
Newbie


Joined: Dec 13, 2011
Posts: 3

PostPosted: Wed Dec 14, 2011 6:09 am    Post subject: Functional notification Reply with quote

Good evening,

I'm trying to convince the team who is in charge of maintenance and development of our IM tool (OASIS) , that functional notification is absolutely necessary.
I mean, when an update is performed within a SR we're not the owner of (user callback, information update,...), the owner should be notified somewhere, preferably with an automatic notification (Email, ...)
But, in their opinion, this is better to create a new SR and to assign it to the relevant team to warn them, no matter how much call is placed by the requester, we have to open a new SR for each call...

Am I alone to consider this stupid and unproductive???

PS : Sorry for my poor english, i hope my ideas are clear Smile

Thanks
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Dec 14, 2011 8:22 pm    Post subject: Reply with quote

This sounds like a management issue being clouded by a focus on the tool rather than the objective. I would need a lot more information to be able to comment usefully.
_________________
"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
Back to top
View user's profile Send e-mail
Toursiveux
Newbie
Newbie


Joined: Dec 13, 2011
Posts: 3

PostPosted: Wed Dec 14, 2011 11:33 pm    Post subject: Reply with quote

Good morning Diarmid,

I'm working as team leader in an IT environment, my team and i are acting as the SPOC for all IT request.

Our objective is to avoid delay in incident management, mainly avoid that a SR remain untouched by 2nd or 3rd level support teams, especially when a requester has called back, or providing with more information or requesting for a status update.

I'm also convinced this is a management issue but i would like to have your opinion...

Do you need more informations?

Best regards
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Dec 15, 2011 4:25 am    Post subject: Reply with quote

Are you calling everything a service request? That is not helpful in a discussion here and is unlikely to be helpful in your organization.

What are the steps you follow for an incident?

Do you have a documented procedure to follow?

How do you (or how do you propose to) pass an incident to second line?

How do you record incident status changes? If you are the single point of contact, then all other teams/functions, must maintain status on the system so that you can advise users and customers without excessively interrupting the technicians.

The approach is not to argue over any specific aspect, but to establish policy, define objectives and derive procedural steps to meet these objectives and conform to policy.

Design a step-through of what you believe should happen and get input from all sections including quality management to determine if it meets your requirements in the best way possible.
_________________
"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
Back to top
View user's profile Send e-mail
Toursiveux
Newbie
Newbie


Joined: Dec 13, 2011
Posts: 3

PostPosted: Thu Dec 15, 2011 7:11 am    Post subject: Reply with quote

Ok then, let's talk about incident instead of service request Smile

We mainly deal with IT incident, we register any of them in our ticketing system, we try to recover the functionality first hand, or we escalate it through the same tool to the second line.

My concern is that our ticketing system does not notify the actual owner of the ticket in case the status of the incident was modified (by owner i mean the second line in this case) The only notification occurs when the ticket get assigned (or assigned back to the first line), but not in case of any change in the status of the incident...

If needed, we still have the possibility to open the record, check for status update and inform the user, that's not the problem. But, in case we have to change the status of a ticket that is already assigned elsewhere, no one is informed about the update.

Is this more clear? Embarassed [/quote]
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Dec 15, 2011 8:04 am    Post subject: Reply with quote

This is not facetious.

Raise a problem for your ticketing system. It needs to be modified or replaced to meet your requirements. Meanwhile design a workaround that ensures people are informed as required. It will help your case if you can isdentify the ongoing costs and risks in the workaround - but no cheating; design it as good as you can.

If you cannot do it as an IT service problem (but you should - that's what the system is for), then raise it with your quality manager / quality auditor. Getting an audit black mark can help to focus minds.

To underpin it either way, you need clear documented procedures. Without these you are fighting in treacle for any improvements.

Which is the third approach: propose a service improvement program. Again you do it easier with procedures in place and reliable historical data to aid the analysis.

If you want to do it right (and why not!), establish a full functional requirement specification for your service management tool set. The lack of this is what led you to where you are.
_________________
"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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.