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: RTaormina
New Today: 8
New Yesterday: 43
Overall: 146517

People Online:
Visitors: 48
Members: 5
Total: 53 .

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 1, 2  Next
 
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: Fri Jun 02, 2006 11:47 am    Post subject: Virtual Incident Management Reply with quote

Consider Incident Management, where the users have a virtual gateway for incident creation and incident owners are assigned incidents automatically once the user requests are created. I can see benefits such as:

1. Automatic Incident Ticketing and Ownership
2. No time wasted opening new incidents (Users record all necesery information)
3. Avoids Misinterpretation of user Incident Description
4. Incident Creation Available online from any point in the world at any time
5. Standartisation of Incident Management (Same Incident Management Template Accross the board)

Any Feedback will be appreciated Smile
Back to top
View user's profile
LizGallacher
Senior Itiler


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

PostPosted: Fri Jun 02, 2006 5:19 pm    Post subject: Reply with quote

I definitely think that there is a place forautoamtion, automatic assignment on-line etc., I do not think it will ever handle more than a small proportion of incidents/requests. It is fine for straightforward password-rests or reuests for standard items which can be picked from a drop-down list. Hwever the skill of a Service dsk Agent (and a good Service desk agent IS skilled, even if not an expert in any one technical area), is to deal with your other points.
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.
_________________
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
Ed
Senior Itiler


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

PostPosted: Fri Jun 02, 2006 5:39 pm    Post subject: Reply with quote

Spot on Liz.

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.

Regards

Ed
Back to top
View user's profile
smichaeld
Newbie
Newbie


Joined: May 26, 2006
Posts: 7

PostPosted: Sat Jun 03, 2006 1:55 am    Post subject: Reply with quote

Many studies have been done around how much Incident volume can be captured and managed via automated means. I would include tools like chat, self-service, etc. These initiatives have never consistently shown that they significantly reduce Incident Management cost. If done well, they can provide ROI, but not much.

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...
Back to top
View user's profile
itilimp
Senior Itiler


Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Sat Jun 03, 2006 2:53 am    Post subject: Reply with quote

Yep, I'm with Liz on this one. My viewpoint is that there is a place for self-service, but not as a replacement for the service desk; only a supplementary channel that users can use.

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.

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.
Back to top
View user's profile Visit poster's website
rjp
Senior Itiler


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

PostPosted: Sat Jun 03, 2006 3:42 pm    Post subject: Reply with quote

I am in agreement with what has been said on this thread so far.

There is a term for cost-driven automation of service - it's called 'transfer of effort'. At the simplest level this is what an automated phone menu system is. It transfers some of the effort of routing calls, and therefore the cost, to the customer.

We have all experienced it, just about everyone knows what it smells like, and most of us don't like it at all.

On the other hand the internet for example is like one giant self-service portal. I remember the days when new drivers had to be shipped. Now I can get software updates on demand. This is where being able to quickly use technology to meet my need without involving another person adds value to my day.

And that's the differentiator between good and bad self-service initiatives.

Bad ones start with your needs (usually to reduce cost) and meet them by transferring effort to the customer.

Good ones look very carefully at what customers want - gosh! some even start by asking them what they want - and assess every function and deliverable in terms of the value created for the customer.

Query, when I look at your list of returns I would have to say it does not look like an initiative that is focused on delivering value to the customers - whose real needs are quite well reflected in the experiences other posters here are drawing on. It does rather look like a cost driven transfer of effort.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Mon Jun 05, 2006 12:44 am    Post subject: Reply with quote

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
_________________
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
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Jun 05, 2006 2:42 am    Post subject: Reply with quote

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,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Jun 05, 2006 4:05 am    Post subject: Reply with quote

Hi Liz,

I figured I'd throw in some information. I hope it helps.

LizGallacher wrote:
I definitely think that there is a place forautoamtion, automatic assignment on-line etc., I do not think it will ever handle more than a small proportion of incidents/requests. It is fine for straightforward password-rests or reuests for standard items which can be picked from a drop-down list. Hwever the skill of a Service dsk Agent (and a good Service desk agent IS skilled, even if not an expert in any one technical area), is to deal with your other points.


As you're well aware, there are two forms of Incident capture: Manual and Automated. Manual come from humans (obvious). Automated come from: Systems Management & Monitoring tools that generate alarms, from Testing Tools that generate alarms, from Deployment Tools that generate alarms, etc.

Quote:
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.


The best anyone can do, for automated "ownership" of Incidents is to assign them to a "bucket", typically in the form of an Organization or their queue OR in the form of the primary Product and/or Service that the Incident is associated with. Once in this bucket or queue, it is assumed that the team responsible for it will ensure that the Incident is addressed. The owner of such a bucket, will make decisions as to who in their organization will get the Incident. This will typically be based on workload, skill assessment, and other factors.

In assigning to this "bucket" it is important that the Incident must be correlated to the Product or Service for which it is associated with. This ensures a number of things: 1) That the team responsible for addressing the Incident always knows where to pick them up from. 2) That all stakeholders that care about those specific Incidents can find them in the same place, including the Business Units that entered them. And, 3) That Products and/or Services instantly start to organically and naturally collect and create metrics and statistics around themselves. The requirement for this is that both the Product Catalog and the Service Catalog are instantly available to the Incident Management platform, so that the process is that the stakeholder looks up the Product or Service they care about and quickly create and associate an Incident to it.

Quote:
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".


Actually, our experience is that the Service Desk can only ensure a small subset of the overall information since, in a large organization, they cannot possibly be the experts in every Product and/or Service. In large organizations, it is typically Level 2 Incident management (or the dedicated Support Teams) that are responsible for ensuring "all" of the information associated with Incidents. It is my personal opinion, based on my experiences (right or wrong), that making the Service Desk the experts and critical owners for such information is a flaw in ITIL.

Quote:
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.


This is not always true. It is our experience that there are many extremely complicated systems in a large enterprise, many of which require the Help Desk to do no more than simply forward the Incidents to the more experienced experts, immediately. In this case, the Service Desk is an extra step that wastes time and energy. In large enterprises, many of the Product Owners for such systems understand the need of quick and expert responses. As a result, they want the Incidents to go directly to the experts so as not to waste time, energy, and resources.

Assuming that the Service Desk should be the funnel for all Incidents achieves a number of negative things: 1) It makes the Service Desk a single point of failure. 2) It limits the flexibility of the organizition to address issues in a number of different ways that may make more sense. 3) It creates Service Desk "kingdoms" where the Service Desk tries to grow and maintain job security for itself. Put yourself in the seat of a "C" level executive who has to think of the bigger picture. While the Service Desk is important, it is not the most critical function in the enterprise. Revenue generation is. If you can't make money, there will be no jobs, at all. Therefore, Service Desk should be low cost, low expertise resources, that take the brunt of the Incidents (but not necessarilly all of them).

Quote:
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.


This is the job of any group that first encounters the Incident. Because the Service Desk employees are not the experts in the Products and/or Services they represent, there is always a huge probability of error in their interpretation. We see this in every medium and large enterprise that we go into.

The Service Desk's job is the ugliest. In an army, they are the infantry. They are "intended" to be the lowest cost soldier, with the least amount of fighting expertise, the least amount of experience, who are going to take the greatest assault, while engaging the largest volume of attackers, and who will "ultimately" take the greatest number of casualties. To a "C" level executive, this is EXACTLY what their job is. They are not the Cavalry. They are not the Special Forces. They are not the Command and Control. They are especially not the only soldiers in the war. To a "C" level executive, they are the lowest cost, lowest expertise, and most highly expendable soldier... the foot soldier.

A commercial company is not a democracy. There is nothing up for vote. You are either profitable or you're not. And, how you get that way is based on the strategy of the people running it. This may sound harsh but it is reality. Everyone has their role. In the case of the Service Desk, it is to take the brunt of the attack (and, of course, be happy doing it!).

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Jun 05, 2006 4:32 am    Post subject: Re: Virtual Incident Management Reply with quote

Query,

I wanted to address and express how we handle each of these:

Quote:
1. Automatic Incident Ticketing and Ownership


Handled by assigning the Incident directly against the Product or Service for which the Incident has come in against. Must be re-assignable to other Products or Services, as the initial assignment is often wrong (due to treating the first symptom that shows up). In order for this to work, the Incident Management platform must have access to the Product Inventory Catalog and the Service Inventory Catalog. The workflow is that the person creating the Incident looks up the Product or Service they care about and quickly log an Incident against it. Support is "Product or Service Centric".

Quote:
2. No time wasted opening new incidents (Users record all necesery information)


We handle this by 1) Ensuring that a root Product or Service must be selected in order for the Incident to successfully be submitted. We also have a number of mandatory fields on the form. If these fields, at a minimum, are not filled in appropriately the user cannot submit the Incident.

Quote:
3. Avoids Misinterpretation of user Incident Description


There really is no way to ensure that this doesn't happen. Sometimes, an Incident is created to a address a symptom. This means that it can throw teams off into a wild goose chase, until the right information is uncovered and addressed. At very least, once the mandatory data is filled in, it gives the person interpreting the Incident a base set of information to work off of.

Quote:
4. Incident Creation Available online from any point in the world at any time


This is accomplished through the use of a web-based portal that allows access to the Incident Management platform by any stakeholder from any region in the world. No Thick-Client package installations. This, by the way, interprets into less work to manage the IM platform, since there are no packages to engineer, retest, redeploy, keep in sync, etc.

Quote:
5. Standartisation of Incident Management (Same Incident Management Template Accross the board)


The web-based platform ensures this. Everyone sees the same form, with the same fields/attributes, with the same prepopulated selectable data, with the same standard data representations, with the same Products and Services, with the same Resources that can create, manage, be assigned to, etc.

Your vision is easily achievable and has been implemented. More so, we've embedded Problem Management, Change Management, Risk Management, Product Management, Service Management, Project Management, and much, much more in the same platform. This means all stakeholders, from all parts of othe enterprise, located in any part of the world, all work from the same operational platform, that is already completely pre-integrated and interdependent, in a natural form. You don't leave one platform to go work in another. You don't have to move data from one system to another. You can create one-to-many, many-to-one, and many-to-many relationships of any one thing to any other thing. As a result, the majority of the ITIL tool platform is now "turn-key" and can be rolled out in 30 to 60 days, rather than over many years, as is typically the case. And, everyone sees and works with the same fresh and live data, regardless of where they are.

Have a great day.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


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

PostPosted: Mon Jun 05, 2006 10:32 am    Post subject: Reply with quote

Frank,

WRT...

Quote:
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.


Ensuring all reports go through level 1 is a core principle of the ITIL framework. (Not correcting you - you were quite clear that you understand and disagree with the framework on this point).

It is of course not surprising that this in not the practice in many companies. ITIL is the result of collecting and structuring identified 'best' practice in the industry, not 'standard' practice.

This Single Point of Contact principle is driven by very simple objectives: quality, consistency, control. SPOC is the most cost effective way to ensure the acheive these. Personally I find the complexity of the processes you outlined in your posts quite unecessary, and would expect to spend a lot of money handling things that way, and generate a lot of operational conflict on a day to day basis between the various players.

You seem to be making one critical assumption, for which I have never seen evidence: that shared data will automatically align activity. What does align activity in compex human organisations is shared values and objectives. It is the common interest that created aligned team effort in business units, not the shared information ontology - 'post hoc ergo propter hoc'. Shared, consistently interpreted information is a necessary but insufficient condition of alignment. ITIL devotes a good deal of space to 'entities', but does not stop there.

Quote:
Therefore, Service Desk should be low cost, low expertise resources, that take the brunt of the Incidents (but not necessarilly all of them)


I couldn't dissagree more with you on the role of the service desk...

The military metaphor is really appalling, no one is going to build a high value service desk starting out with that point of view. It seems that the customers and end-users are the 'enemy' in your view, and the Service Desk is the 'Cannon fodder' designed to be expendable grunts soaking up enemy 'fire'.

How do you like dealing with the poor sods in cattle fodder call centres who are not empowered or trained to deal with your requests?

I hate it! And I frequently feel sorry for the person on the other end, whom I know is working to a personal KPI that is virtually forcing them to give me the worst possible service. And the real point is that I have changed companies because of this, and will stay with a company that knows how to provide quality service.

Undervaluing human 'capital' in a service industry is like a mining company questioning the utility of their trucks.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Jun 05, 2006 1:18 pm    Post subject: Reply with quote

Hello RJP,

Responses embedded, below...

rjp wrote:
Ensuring all reports go through level 1 is a core principle of the ITIL framework. (Not correcting you - you were quite clear that you understand and disagree with the framework on this point).


I like ITIL and what it stands for. However, there are two things I do not believe: 1) That ITIL is perfect and has no errors in it, and 2) That there are absolutes. No one thing fits or solves all things perfectly. Assuming so is usually a critical mistake.

Quote:
It is of course not surprising that this in not the practice in many companies. ITIL is the result of collecting and structuring identified 'best' practice in the industry, not 'standard' practice.


Again, there are multiple best practices. It is limiting to assume that there is only one. Remember, while ITIL represents best practices, there is no standard way to implement it. This means that no one follows it to the letter. Flexibility is something that we all benefit from.

Quote:
This Single Point of Contact principle is driven by very simple objectives: quality, consistency, control. SPOC is the most cost effective way to ensure the acheive these.


As far as I'm aware, there is no supporting evidence for this. If there is, please point me to it. As a matter of fact, all references that highlight a single point of contact do so as a convenience to the customer, not as a cost savings or quality assurance means. Many customers are comfortable dealing with issues in different ways. Therefore, flexibility in doing so is more customer focused than forcing all of them to always go to one SPOC that handles everything the same way. Where I do agree that the SPOC works is for ensuring that there is one person that is watching over all customer issues. What this means is that this SPOC acts as a relationship manager or a liaison between the customer and the company. I've seen evidence that this giving the customer the "option" of the SPOC as the fallback, as well as the person to get all relevant reports from, is a very good thing. Forcing them to deal with the SPOC for all issues, especially for large enterprises with huge customer bases, doesn't scale well. I know this because I've managed these large organizations, being on both the customer side, as well as on the side that provided the service to them. I've had the luxury of having implemented pieces of ITIL multiple times for multiple organizations. In each case, I've learned that flexibility is the key. I've also learned that ITIL has flaws in it that conflict with other best practices in the industry, such as MSF, MOF, RUP, and SDLC.

Quote:
Personally I find the complexity of the processes you outlined in your posts quite unecessary, and would expect to spend a lot of money handling things that way, and generate a lot of operational conflict on a day to day basis between the various players.


It's interesting that you should say this. Not only our clients but also other companies that we spoke to, for benchmark information, have all found this to significantly simplify their processes and ultimately reduce their costs. Giving their customers (both their external customers and their internal customers such as business units) multiple ways to log and track incidents ultimately increased customer satisfaction, significantly reduced the time to resolve incidents, and ultimately raised the level of transparency into the organization. We have hard evidence to show this. If how we implemented these solutions does not follow ITIL, to the letter, then I'd have to say that ITIL is not necessarilly the only way to skin the cat.

Quote:
You seem to be making one critical assumption, for which I have never seen evidence: that shared data will automatically align activity.


If you haven't seen such evidence, then please let me politely point you in the direction where you can find it...

BlackRock's Aladdin is dominating its industry because of this principle.
SalesForce.com is dominating its industry because of this principle.
Business Engine (BEN) is dominating its industry because of this principle.
CollabNet is too.

We can go on and on. The world is moving towards this principle. It has to. It is the only way to connect a global organization. Shared data "always" aligns activities. The reason for this is that in order for it to be shared, it must be consistent, common, reusable, live, fresh, and operational. In order for it to be shared, the creators and users of the data must move past the bickering of how to represent it, how to integrate it, etc. This may be hard for many people to understand, but so was the internet, before it became commonplace. The internet is all about shared data. And, guess what... It has aligned everyone that uses it. People in China use it the same way and for the same reasons that people in Australia, India, and every other country use it. The internet is your, and my, definitive proof that shared data aligns activity. It is not about values and it's not about objectives, as you point out, below. It is all about shared data.

Quote:
What does align activity in compex human organisations is shared values and objectives. It is the common interest that created aligned team effort in business units, not the shared information ontology - 'post hoc ergo propter hoc'. Shared, consistently interpreted information is a necessary but insufficient condition of alignment. ITIL devotes a good deal of space to 'entities', but does not stop there.


I believe you've contradicted yourself. If you go back and read many of your posts, you speak of the standard representations for ITIL constructs, such as Incidents, Problems, Changes, Configurations, etc. You cannot, under any circumstance, implement ITIL, without standard representations that are shared, throughout the enterprise. I will simply have to disagree with you and state that my belief is that the standardization and sharing of data is a "prerequisite" for alignment. Alignment, in my experience, can not, and will not happen without it.

Quote:
Quote:
Therefore, Service Desk should be low cost, low expertise resources, that take the brunt of the Incidents (but not necessarilly all of them)


I couldn't dissagree more with you on the role of the service desk...


Your perspective is very interesting. Evidence seems to weigh against you, as enterprises, world-wide, are outsourcing their Service Desks to low cost labor countries, on the assumption that Service Desk is nothing more than a commodity. This seems to not only have happened a great deal, over the last 6 years, but it is picking up speed. Garnter and Forrester, both, have posted significant research and evidence on this. You will have to take your position up with them.

Quote:
The military metaphor is really appalling, no one is going to build a high value service desk starting out with that point of view. It seems that the customers and end-users are the 'enemy' in your view, and the Service Desk is the 'Cannon fodder' designed to be expendable grunts soaking up enemy 'fire'.

How do you like dealing with the poor sods in cattle fodder call centres who are not empowered or trained to deal with your requests?

I hate it! And I frequently feel sorry for the person on the other end, whom I know is working to a personal KPI that is virtually forcing them to give me the worst possible service. And the real point is that I have changed companies because of this, and will stay with a company that knows how to provide quality service.

Undervaluing human 'capital' in a service industry is like a mining company questioning the utility of their trucks.


You may want to analyze your own statements. The reason why these "poor sods"... "who are not empowered or trained to deal with your requests" is very simple. It is because in any commercial organization, they are not the most critical function. I did not say they weren't important. I simply stated what is common in "every" commercial enterprise, exept one, which is the company whose core competency is to provide call center services. In this latter case, call center is a revenue generating function. In all other cases, the Service Desk is, at best, a tertiary priority. The typical order of priority is Sales & Marketing, Engineering and Product Development, and finally Support. This may bother you but if you query the leaders of most commercial enterprises you will find that this is the order in which they distribute their funds. I apologize if this hurts your feelings but I did not make this up.

Anyhow, as always, it is a pleasure exchanging knowledge with you.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


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

PostPosted: Mon Jun 05, 2006 4:33 pm    Post subject: Reply with quote

Yes Frank ditto -

I do believe that ITIL has to be used along side other things - CMM, PRINCE2, etc... and that it isn't a panacea for every single management issue. But basically I don't think there is anything in it that is fundamentally flawed.

Lastly I basically blank out 'arguments from the herd' - just because lots of organisations are doing something isn't actually an argument for the practice. Even if they are make a profit or gaining market - there is a huge ammount of surplus productivity in many organisations obscuring costly bad practices.

Hence my reference to 'Post hoc ergo procter hoc' - "Common logical fallacy where the assumption that A causes B is based on B occurring shortly after, or along side A" Butler Group: "During the IT boom of the ninties productivity in the USA rose by 2.5% per year, with this being largely attributed to the increasing use of comupter systems. However, when the bubble burst in 2000 and IT investment was essentially put on hold, year-on-year productivity gains over the next few years increased to over 4%"

In this country at least, hundreds of millions of dollars were spent outsourcing various IT capabilities (mostly by Govt depts), after ten years of decaying returns and increasing (indirect) costs, hundreds of millions of dollars are now being spent by organisations reacquiring their internal IT capabilities.

Bottom line for me: Service Desks should produce value, not be relegated as the necessary cost of remediating failure in other processes. If your clients want to overlook that potential it's their own buisness, and their own dime - so to speak - but that they do isn't a reason for me to consider doing the same.

Another interesting phenomenon - when you move a service desk away from the approach you are advocating to a more 'ITIL' approach as I have done you find something very interesting - most of the cost of IT to the business has little to do with the skills those tech-providers have at their disposal. And even less to do with availability SLAs. In one situation I found that disruptions IT was able to resolve through its infrastructure management groups was approximately 5% of all IT service issues. One white paper I have from Tech-Info research indicates that typically 75% of all service desk calls are non-technical in nature. Precisely the kind of thing business focused staff with a solid knowledge of IT and excellent soft skills are going to be best at resolving.

So perhaps we should just agree to disagree.

Cheers.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
taiger
Newbie
Newbie


Joined: Dec 28, 2005
Posts: 8
Location: The netherlands

PostPosted: Tue Jun 06, 2006 1:27 am    Post subject: Reply with quote

just may be, it's all about perspective..

if you're used to being helped by a call center, you're more likely to wanting a self-service tool with a way to report incidents yourself and direct access to a knowledge base.

if you're used to being helped by a service-desk ( organised the way Itil wants it to be ), i'll think you don't want a self service tool. I'll think you're quite happy the way a service desk works.

two different views...

and sadly, many organisations don't see the benefit of a service-desk, but implement a call-center or a helpdesk.

Frank
_________________
"if you aim at nothing, that's what you're likely going to hit"
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

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

Hello RJP,

I believe we're both in agreement that ITIL is important and adds values.

I believe we're both in agreement that the Service Desk is important and adds value.

I think where we're in a bit of disagreement is in "how much value" each provides.

ITIL addresses helping your IT organization act more like a business, where it takes on a more "Customer Service-Centric" approach. I ask, that for the sake of discussion, you take on a bigger picture perspective. Put yourself in the seat of the CEO of any company whose business is "NOT" Information Technology. Let's say he/she sells "widgets".

This company's primary purpose, unless the company is a Non-Profit or Not-For-Profit, is solely to generate more "money" than it consumes. It's purpose IS NOT to sell "widgets". "Widgets" are a means to an end, and that end is cash. This is fundamental. Without revenue, there are no jobs. Without revenue, there is no job security. Without revenue, there is no training and advancement. Without revenue, there is no survival in the global economic market. Again, a company's sole purpose is to generate more "money" than it consumes.

Now, given this "fact", there are prioritized functions within any commercial entity and there is a delicate balance of how to fund and support such functions.

rjp wrote:
Bottom line for me: Service Desks should produce value, not be relegated as the necessary cost of remediating failure in other processes. If your clients want to overlook that potential it's their own buisness, and their own dime - so to speak - but that they do isn't a reason for me to consider doing the same.


A "C" level executive "does" understand the function of customer support and the value that a Service Desk provides. If he/she didn't, there wouldn't be a Service Desk. And, "yes", it is believed that a Service Desk should produce value, as you stated in the above quote. However, supporting existing customers is done for only two reasons: 1) To keep them renewing your Product(s) and/or Service(s) and 2) For Sales staff to get warm referrals from them, for future new sales (happy customers help generate new sales). In theory, if you could build a flawless Product or Service that required no support, you would need no Service Desk, at all. Sales people could go directly to the customers for the warm referrals. Therefore, a Service Desk is a necessary function, that any executive would happily do without, assuming he or she could offer the perfect Product or Service.

Now, since the priority is to generate more cash than is consumed, the highest level of focus is virtually always on Sales & Marketing and what it takes to make it successful. Product Development is an "enabler" for sales and marketing. If your development staff is adding more features than can be successfully taken advantage of by the market, they've oversaturated the product and you reduce Development staff and increase Sales & Marketing staff. If Sales & Marketing are suffering because of lack of features or quality in the product, then you attempt to fund product development only enough to get you passed the hurdle of jump starting sales.

In all of this, Service Desk is not a primary function, for any organization that sells widgets.

rjp wrote:
In this country at least, hundreds of millions of dollars were spent outsourcing various IT capabilities (mostly by Govt depts), after ten years of decaying returns and increasing (indirect) costs, hundreds of millions of dollars are now being spent by organisations reacquiring their internal IT capabilities.


Market research consistently shows that outsourcing is picking up steam. Sure, there are organizations that are in-sourcing. But that is such a small percentage of what is truly going on in the world that it doesn't compare to the increase in outsourcing momentum. (BTW, this doesn't mean that I like it! It personally bothers me that we're losing jobs to other countries because we can't compete properly.)

So, in summary, I do agree with you that ITIL is good. I do agree with you that Service Desk is important.

I simply don't agree, based on professional experiences managing large organizations and implementing ITIL for many clients, that ITIL is as flawless as people make it out to be.

I also do not agree with your views on how important Service Desk is to an organization. Again, I do agree that it "IS IMPORTANT". Just not as important as you've made it out to be.

Here is a fundamental fact. You can take it or leave it. Talk to any "C" level executive of any company whose purpose "IS NOT" IT. They will always tell you that funding IT is a large pain point, for them. Why? The answer is simple... "IT is not their core business and they want to reduce that expense and all functions associated with it so that they can redirect funds to alternate areas of their core business." Why? "To generate more cash and maximize profits."


rjp wrote:
Another interesting phenomenon - when you move a service desk away from the approach you are advocating to a more 'ITIL' approach as I have done you find something very interesting - most of the cost of IT to the business has little to do with the skills those tech-providers have at their disposal. And even less to do with availability SLAs. In one situation I found that disruptions IT was able to resolve through its infrastructure management groups was approximately 5% of all IT service issues. One white paper I have from Tech-Info research indicates that typically 75% of all service desk calls are non-technical in nature. Precisely the kind of thing business focused staff with a solid knowledge of IT and excellent soft skills are going to be best at resolving.

So perhaps we should just agree to disagree.


You're misquoting me (and I'm sure it's unintentional). I'm not advocating a non-ITIL approach. I believe, very much, in ITIL and how it adds value. A large part of my business is predicated on it. I simply believe that there is a level of prudence that must always be interjected. ITIL was written by human beings. Human beings are not perfect. To expect ITIL and its views and recommendations to be perfect is setting oneself up for failure.

Very simply I believe that the equation reads:

"ITIL" + "Common Sense" + "Capable & Motivated People" = "SUCCESS"

It's the "Common Sense" variable that I ask people to be aware of.

(PS: Your getting first hand information from the leader of an organization, not a developer. I come to these forums to learn from the people in my industry base as well as to hopefully contribute valuable information to others. I give you my views based on, both, my experiences in IT, my own and my customers, as well as from what it takes to manage a successful commercial enterprise. You can take all of it for what you believe it to be worth.)

Have a great day and thanks for the opportunity.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 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.