Hi !
This is my first post.
One of my Client has "Incidence management" as an customer outsourced service. SLA has been signed and it talks mostly about how and in what timeline the tickets should be handled.
Ticket is for registered by customer as "incidence" and "Change" . Client is supposed to handle only "Incidence". They remotely log-in to device(s) and diagnose. Few tickets are closed remotely. Other cases are escallated to a person seating "Near" customer place with all instructions to execute at customer site locally. This is breaf about the "service" offered.
Tickets not closed within given time directly violet SLA.
What Incidence management Process can be established in theis scenario.
Regards,

Thanks for the reply. Question here is do we have to develope any Inceidence Management process for our own "servivce". One of the third paty consultants has suggested that we may not have any IM process for our self (Our own service) and we should stick to the process defined by the Customer. Your reply is in agreement with the consultant. Thanks again for the reply
Regards,

The process control should always stay by the customer. Better, the customer should even define the process. Of course, the supplier should and could help the customer in that matter. That actually depends of the maturity of the customer. All this does not remove the responsibilities of the supplier of managing their own services properly... but making sure that they are inline with the ones of the customer.

And this applies to all Service Management processes. It is even a requirement for being BS 15000 certified.

Now if the customer understands its service management processes very well, they will be able to build good underpinning contracts with their suppliers. Contracts that would warranty not only time to start working, time to solve, but also % of tickets solved for example..._________________Better have remorse than regrets

I have this feeling I read that the Service Level Manager should define the process in cooperation with the customer. The idea that the customer would know the process better sorts of defeats the purpose of having a service provider in the first place in my opinion. But I'm willing to listen.....

xitil wrote:

Now if the customer understands its service management processes very well, they will be able to build good underpinning contracts with their suppliers.

I have small issues with this statement.

First of all, Underpinning Contracts are contracts between the service provider and external partners. I don't really understand what the customer's role is. Can you explain?

Also, the customer does not need to understand the service management processes. The whole idea is to bring the service provider closer to the business, not the other way around.

Your entire post makes it sound like the customer is the one with all the knowledge of service management. Did I miss something?_________________BR,
Fabien Papleux

Sorry Fabien, I understand why you were confused by my post. I was actually putting myself in the shoes of the company to which the services have been outsourced.

In mredekar situation I think we have this:

ITIL customer
|
V
Company that has outsourced some service [the one I called Customer]
|
V
Company to which the service has been outsourced

So let me rephrase my post in a good ITIL compliant way:

<<
The process control should always stay by the company outsourcing the service. Better, they should even define the process. Of course, the supplier should and could help the company outsourcing the service in that matter. That actually depends of the maturity of the company outsourcing the service . All this does not remove the responsibilities of the supplier of managing their own services properly... but making sure that they are inline with the ones of the company outsourcing the service.

And this applies to all Service Management processes. It is even a requirement for being BS 15000 certified.

Now if the company outsourcing the service understands its service management processes very well, they will be able to build good underpinning contracts with their suppliers. Contracts that would warranty not only time to start working, time to solve, but also % of tickets solved for example...
>>