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: ZellaPedl
New Today: 67
New Yesterday: 97
Overall: 141319

People Online:
Visitors: 63
Members: 0
Total: 63

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

Virtual Incident Management
Goto page Previous  1, 2
 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Tue Jun 06, 2006 11:58 am    Post subject: Reply with quote

Wow, Thanks guys. So much to read through. I wasn't expecting so much information. I will start from the top and slowly work my way to the bottom

LizGallacher wrote:
1. Automatic Ownership of tickets - is this the assignee, because in ITIL terms they do not own the incident - the Service Desk does. Without the Service Desk, who is progress-chasing the ticket, updating the customer, ensuring that they were happy with the technicalresponse etc.
2.If users knew what information was necessary, they still would not provide it. The Service Desk is there to ask the right questions, to weed out irrelevant facts etc. Most self-logging systems that i have seen (if not restricted to standard pre-defined incidents) either result in huge amounts of information being given, most of which is irrelevant, or 1 line "Got a problem, please call me".
In addition, automatic assignment of incidents to technical areas means that there is no First Line Fix at the Service Desk which is the fastest and cheapest way of overcoming incidents.
3. The Service Desk's job is to correctly interpret the Incident description. They have the skill to describe it accurately, which the user does not.


1. I meant Automatic Ownership because the tickets are automatically assigned to the available Service Desk Operators. I.e. a user creates a ticket that gets auotmatically assigned (Automatic Owndership by Service Desk Operator who owns the incident until the end of its lifecycle)
2. If the user does not know what information is neccessery they will not provide it regardless if it's a call, email or a virtual incident ticket. The Viritual Incident Management's job here is to ask the right questions (Same as Service Desk Operator's), user is to provide as much information as posible. If more is required then the Service Desk Operator who owns the ticket will contact the user for clarification (The difference is = not as much time would is wasted + the Operator has a chance to understand the ticket before dealing with user so Operator can ask to-the-point questions if at all required.
3. The Service Desk Operator can still interpret the information accurately after recieving the Incident Request, if not they can contact the user for further clarification. Ultimately a functional Virtual Incident Management System would ask all the right questions from the user (The same kinds that Service Desk Operator would ask at the time of the call).

I hope this clarifies it a little bit. I will work my way down the list once I get a chance Smile
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Tue Jun 06, 2006 12:20 pm    Post subject: Reply with quote

Ed wrote:
I think query's basic problem is being exposed to Service Desk Agents who are NOT as skilled as we all would like. Web enabled software will give pan world access, but you still need the SDA to sort out the problems.

Sorry query, but in my humble opinion this cannot possibly work as you could not pre-define all scenarios.


Think of it as having both SD and Virtual Platform that:

1. Automates the incident logging proccess
2. Records the time of the incident raised regardless of the SD status (For SLA Purposes)
3. Frees up the SD time that would otherwise be spent on logging the incident to actualy resolving the incidents
4. Increases SD productivity and the amount of incidents SD can resolve

I honestly don't understand how this will not possibly work Smile
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Tue Jun 06, 2006 12:26 pm    Post subject: Reply with quote

smichaeld wrote:
The only self-service initiative I have encountered which is truly time saving, delivers good ROI and actually welcomed by both your customer community and SD management is self-service password reset.

Remember too that in the final view, we are servicing our customer communities. Just because it costs less does not mean the customer actually wants to interface with IT that way. In my personal experience as a customer of IT or other service supported by automated systems is that nothing aggravates me more than an automated self-service interface which forces me to step through some innane trouble shooting tree before allowing me access to a person who can answer the question in two minutes. In a best case these systems do not account for a customer who may actually have some knowledge. When your customer interface operates with the assumption that your customer is stupid, you lose before you start...


I think the misunderstanding following LizGallacher's post is that the proposed Virtual Incident Management is a type of a self-service. It is not. It is a service where a user can raise incidents and be assigned automatically a ticket, which then is owned by a Service Desk Operator, that manages the incident lifecycle.
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Tue Jun 06, 2006 12:35 pm    Post subject: Reply with quote

itilimp wrote:
On our site we do have the facility for users to log and monitor their own incidents through a web interface. However, the take up of it has been rather on the slim side. Some who use it love it, others hate it and want to talk to someone.


I think, my idea revolves somewhere around here itilimp. I guess a combination of regular contact methods and the virtual logging methods is the better practice. One of the main benefits I can see with the virtual method is that it can be logged at any time from anywhere in the world and be managed centrally. You can not do the same with on call (The costs for on call staff will go through the roof) and you can't achieve the same with email (Since the centrally managed component would be missing + the information would still need to be re-entered into the Incident Tracking system)

itilimp wrote:
As has already been said, one of the functions of a good Service Desk Analyst is to ask the right questions to find out what the user is actually trying to do as well as ascertain the actual symptoms and to document them well if they cannot resolve the issue then and there.

The value of a customer service desk analyst who has the ability to ask the right questions should not be underestimated.


I agree completely!!! Amen
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Tue Jun 06, 2006 2:23 pm    Post subject: Reply with quote

Quote:
I think the misunderstanding following LizGallacher's post is that the proposed Virtual Incident Management is a type of a self-service. It is not. It is a service where a user can raise incidents and be assigned automatically a ticket, which then is owned by a Service Desk Operator, that manages the incident lifecycle.


Yes I made the same mistake - sorry Query. I actually think alternative automatic chanels to access the Service Desk are a very good idea.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Wed Jun 07, 2006 10:12 am    Post subject: Reply with quote

rjp wrote:
Yes I made the same mistake - sorry Query. I actually think alternative automatic chanels to access the Service Desk are a very good idea.


That's Okay rjp, I should have clarified myself a little bit more.

In regards to your earlier comment "It does rather look like a cost driven transfer of effort." I would say that it's not primarily cost driven, but driven by benefit to organization / business. I think it's a very effective way of centralizing Incident Management and making it more available to business outside of working hours (And specific locations). I think also this would make incidents a lot easier to track and SLA easier to manage.

What do you think about the proccess outlined itself? Smile
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Thu Jun 08, 2006 5:50 pm    Post subject: Reply with quote

Query

My concern was that without the SD agents your virtual process cannot work. Yes we have web access for initial logging of incidents, in common with most other people, but as I said you still need the Service Desk agents to pick the bones out of what users fill in on these pages.

With both there will be a benefit

Regards

Ed

[/quote]
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Fri Jun 09, 2006 9:07 am    Post subject: Reply with quote

Ed wrote:
Query

My concern was that without the SD agents your virtual process cannot work. Yes we have web access for initial logging of incidents, in common with most other people, but as I said you still need the Service Desk agents to pick the bones out of what users fill in on these pages.

With both there will be a benefit

Regards

Ed

[/quote]

Hi Ed.

Yes.

The Virtual Incident Management Tool I propose will have both. Web access for intial recording of incidents and auotomatic assignment to SD agents and SD agents who will track the incident and monitor its lifecycle.
Back to top
View user's profile
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Fri Jun 09, 2006 9:23 am    Post subject: Reply with quote

Fabien wrote:
And all of that.... To me the key is customer satisfaction though. If it does the job for the users and it's all they want, fine.... but I have never seen this and, I bet, never will. When a user has a problem and it's urgent, he/she wants to place his/her problem in the hands of someone he/she trusts.

There is a trust dimension to support that automated systems will always fail to provide users. Most users are not comfortable with technology to begin with, and even as the overall worldwide workforce gets used to it, the tools we develop/provide are always more sophisticated and we always keep it out-of-reach for some reason...

Did you say job security? Smile


I Completely Agree Fabien. And the customer still deals with the SD person they trust, they just don't initialy log the incident with that person (As they wouldn't lodge an incident straight with a 2nd level / 3rd level tech in a big organization). All this system does is eliminates the middle man that records information on the incident into the system, the automated process captures all of that, so the ticket can go straight to SD for further follow up.

You mentioned that "When a user has a problem and it's urgent, he/she wants to place his/her problem in the hands of someone he/she trusts." I have actually found that to be an issue because the users tend to find ways to by pass the centralised controls of the Service desk and make calls straight to the person they wish to speak to (E.g. Straight to Level 3 Support to log a call and then follow up on the issue). This creates an environment where 3rd Level Support is not as efficient at resolving incidents or issues since they spent some of their time on recording of the incidents and it creates a culture where users tend to bypass the SD controls all together. So I understand what you are saying, on the one hand there is user satisfaction, but on the other there are proccesses which focus on eficiency, it's a very careful balance and in my opinion both need to be maintained.
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sat Jun 10, 2006 4:02 am    Post subject: Reply with quote

I agree with that. We actually actively work on that. I think that's a global problem. We put in place processes and systems to "invite users away from specialists". In the end, it is the high availability and the competence of the SD that invites users in. If specialists have places that cannot be reached by users (physically), they become more difficult to deal with than the SD. Then we market the SD team. After a while, the traffic naturally goes to the Service Desk. Not 100% of it though. I don't think it's realistic to think you can achieve that.

We also have a mail-in DB so users report incidents and request services by e-mail.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Thu Jun 15, 2006 2:26 pm    Post subject: Reply with quote

Guerino1 wrote:
Query,

Some interesting details based on an enterprise that has 60,000ish employees that we've implemented ITIL solutions for...

They were smart enough to realize that there is no such thing as a single channel for Incident collection and management. They highlighted that Incidents come from every direction...

NOTE: For the below examples...

Level 1 Incident Escalation & Management = The Help Desk and Network Operations Center (NOC)
Level 2 Incident Escalation & Management = The "dedicated" support staff for any applications and/or infrastructure
Level 3 Incident Escalation & Management = The "internal" Product Owners. This means either the Development Teams, themselves, or the Relationship Managers that represent "external" products.
Level 4 Incident Escalation & Management = The Vendor. In the case where something was designed and built, internally, the vendor is the Development Team.

Formal Escalation moves from Level 1 through to Level 4.

Now, going back to the statement that Incidents come from many different sources, here are some examples:

1 - Directly from calls to the Help Desk,
2 - From Developers tracking Incidents in the various environments they're working in,
3 - From the application and infrastructure Support Teams,
4 - From monitoring systems that generate alarms
5 - From testing systems that generate alarms
6 - From the business units, themselves, going directly to the Development Teams,
7 - From the business units, themselves, going directly to the Support Teams
8 - From the business units, themselves, going directly to the Self Service Incident Management platform.
Etc.

All are important but I want you to please give extra attention to 6, 7, & 8. In a large organization, the business units will call whomever they feel comfortable with and whomever they believe will help them the quickest and with the best results. YOU CANNOT STOP THEM. There are too many of them and they will do as they wish. As a result, this enterprise realized some very important things...

What "IS NOT IMPORTANT" is that the Help Desk enter and manage all Incidents.

However, what "IS IMPORTANT" is that all Incidents get logged, assigned to all appropriate Products and/or Services and that they are addressed as quickly and as efficiently as possible.

It was concluded that they needed a "self service" platform that was centralized, operational, and visible to everyone, world-wide. Therefore, what they had us do for them was to roll out our system as a Self-Service platform for them. From one platform, all Incidents were being entered by any and all stakeholders, throughout the firm.

In order to achieve this, it was critical to ensure that the Development, Engineering, Support, NOC, and Help Desk all understood what it meant to enter, track, and manage Incidents, Problems, Changes, etc.

Since, from one platform, everyone could see what everyone else was doing, and since it was now OK for anyone to enter Incidents, Problems, Changes, etc. from one common front end, there was only one other thing to ensure. They realized that some organization had to be responsible for overseeing and ensuring that all Incidents were, in fact, being managed and addressed. For this reason, they provided the responsibility for overseeing all Incident resolution (as well as the integrity of the content within the Incidents) to the Help Desk, NOC, and Direct Support teams. The Help Desk and NOC (Level 1) were responsible for all Incidents that came in and were managed via their channels and that were escalated to any level. The direct Support teams (Level 2) were given responsibility for overseeing "all" Incidents that were entered against any of the Products and/or Services that they were responsible for. It was their responsibility to ensure that "someone"/"anyone" was truly engaged in helping the customers. If an Incident was put on the back burner, it was their responsibility to ensure that such a decision was justified. If a workaround was logged, it was their responsibility to understand it and bless it, etc.

Now, there is one thing that needs to be understood. Who "OWNS" all Incidents? The "Product Owner", not the "Product Manager". The Product Owner, typically the head of Product Development for that product, was dubbed the responsible party for the quality of his/her Products and/or Service and would be held accountable for such quality.

In this way, they are able to leverage a single Incident Management platform that is shared by any and all Stakeholders, within the enterprise, regardless of their global location.

Because they all shared the same data, the quality of the data went way up. All eyes are on the same data and this causes everyone to be very careful and thorough when entering and managing the data. This acts as a "cross-check" between organizations. (THIS HANDLES THE "INTERSECTION" OF ALL RELEVANT DATA.)

Also, different organizations have different interests in the data and in different aspects of the Incidents. This means that Help Desk is thorough about entering and ensuring the quality of the data portions that meet their needs. The Support Teams are thorough about entering and ensuring the data that meets their needs. The Developers are thorough about entering and ensuring the data that meets their needs. And, so on... What this means is that any and all Incidents in the platform have a tremendous amount of data, embedded within them, that meet the needs of all organizations. (THIS HANDLES THE "NON-INTERSECTION" OF ALL RELEVANT DATA.)

Between the two areas of management, above, Incidents have a very through and complete set of data that meets 1) the common needs of any and all stakeholders, as well as 2) the unique needs of any and all stakeholders.

Trust me, nothing is perfect. However, this organization and many other clients have achieved a number of critical things: 1) All data is in one place. 2) The quality of the data is high. 3) The data is "live" and "fresh". 4) They have achieved a "SELF-SERVICE" platform, where any stakeholder can go in and log Incidents and be sure that the Incidents will be addressed in a timely, efficient, and high quality manner.

Because the platform is centralized and virtual to all stakeholders, the Business Units, themselves, can watch the progress of any and all Incidents that they're interested in. They can see who's working on them. They can see any and all data being logged against them. They can even collaborate, live, within the platform, with the people working on the Incidents, from each and every group. What this translated to is that the Customer Satisifaction Levels of the Business Units that acted as "Internal Customers" went way up. They felt "connect", "involved", and "empowered".

Anyhow, I hope this helps. Let me know what you think.

Regards,


Hi Guerino1

I think the system that you have summarised is great and very well thought out. It must have been a dinosaur to put in place. How many Service Level Managers does your organization have to monitor how the SLA levels are being met based on the information recorded? Also, who developed this logging system and how long did it take to implement?

In any case, our organization is way smaller than yours and needs are a lot simpler. In our case it wouldn't be a self-service system as such, the service desk would still own all the incidents and manage their lifecycles, however they need not be directly responsible for logging the incidents themselves or for the incident assignment. I guess, as far as control levels go, the structure will be hierarchial, since only one team is responsbile for the incident management. However, I definetly see the benefits of having a well thought out system such as yours.
Back to top
View user's profile
LizGallacher
Senior Itiler


Joined: Aug 31, 2005
Posts: 550
Location: UK

PostPosted: Fri Jun 16, 2006 12:05 am    Post subject: Reply with quote

I thought I made it clear that I saw nothing wrong withbeing able to log calls onto the system yourself, which were then managed by an SDA. In this situation however, you need to ensy=ure that the correct information is gatheres in a standard way - drop down lists etc. It depends on the user, but many would find filing in sy=uch a faorm tedious. there are always the situation where someone will log a call, filling in all sorts of information, instead of calling the SD to be told that they are aware of the issue, and do not need all the description as it is just another instance of an open incident.
_________________
Liz Gallacher,
ITIL EXPERT
Accredited ITIL and ISO/IEC20000 Trainer and Consultant - Freelance
Back to top
View user's profile Send e-mail Visit poster's website
query
Itiler


Joined: Feb 02, 2006
Posts: 41
Location: Sydney, Australia

PostPosted: Fri Jun 16, 2006 11:59 am    Post subject: Reply with quote

LizGallacher wrote:
In this situation however, you need to ensy=ure that the correct information is gatheres in a standard way - drop down lists etc.


Hi Liz, definetly. Down to an option that a user has a choice to bypass some of the forms if necessary and add aditional comments.

LizGallacher wrote:
It depends on the user, but many would find filing in sy=uch a faorm tedious. there are always the situation where someone will log a call, filling in all sorts of information, instead of calling the SD to be told that they are aware of the issue, and do not need all the description as it is just another instance of an open incident.


In our case this wouldn't be an issue, since we record all instance of an opened incident to know the incident's impact (And priority level). In which case all user self recorded Instances of an incident are welcome.

I guess, one of the other benefits of this system I can think of is it definetly is a better method of opening up an incident when SD is tied up with other calls or are unavailable. Imagine if all SD staff are on call and a user urgently needs to report an incident (Yet there's noone to take it), this option proposed to self record and recieve an instant ticket with time stamp becomes much more viable than just leaving a voicemail or email.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Goto page Previous  1, 2
Page 2 of 2

 
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.