Infra Service Provider asked to investigate a Service Prblm

[OftenConfused]

Hi,

Due to changes in organisation and the breaking up of a larger company into smaller parts, our organisation will become an infrastructure managed service provider and I am getting lost with when a Problem within the company we provide INF services to exists and support is needed from us - do they log an incident with us, a request for support or a problem with us? all very confusing.

As a general rule, I would normally say that the consuming organisation would engage the supplier (underpinning in this instance) and register an Incident for investigation - this will work for when something has been identified as a fault and so this bit I am happy with.

Its when the Consuming organisation has a Problem with a Service they provide (that is not in a failed state at the time), which the underpinning Infrastructure Service Provider supports components of. In this instance, where a requirement for a resource to support a joint technical 'Problem Solving Group' within the 'Consumer' organisation has been requested - How should these engagements from the Consumer, be registered into the Supplier's Service Management tool and/or Processes;

A Request (for a Resource)
An Incident
A Problem

I am looking for a general steer or an example of the processes used within other organisations.

Where possible, if you could clarify the links and touch points in terms of ITIL processes and/or governing bodies (Problem Management Team, Major Incident Management Team, Servicedesk, etc.) it would be of great help.

[Timo]

So do you have processes in place to handle SRs, Incidents and especially problems? If you do, then it should be determined by the process what gets logged as what. If you (as I suspect) don't, then your starting point is to look at what processes you need to implement first.

Most commonly, companies start with Incident Management. From your customer's stand point they have a place to report the issues/faults to and have certain degree of confidence that these issues will be dealt with. To get proper value from managing problems you need to have a relatively mature incident mngt process along with well established service desk - the reason is that you need solid basis in terms of information and data to support your problem management activities, such as trends, incident details, possible workarounds, and from SD coordination and communication of information between support parties and customer.


Read ITIL Service Support (v2) or ITIL Service Operations (v3) books for the information on processes you've mentioned.

[OftenConfused]

Hi Timo,

Yes we do have process, the majority of IT Service Delivery/Support as it used to be called. We have Request Fulfilment, Incident (And Major IM), Problem, Change and so on - the only difference between now and the near future is, rather than Problem being an internal to IT function, our organisation will become a Managed Service Provider to another organisation and therefore I am looking to see if anyone has any knowledge or experience of this field, especially when dealing with requests to investigate a Problem affecting a service, when the Service is not fully managed by our own organisation.

We currently provide a fully managed IT service for this aspect of the business and the Incident and Request Fulfilment processes are customer facing with Service Level Management in place to report on the effectiveness of the IT function as a whole and on a per customer basis -with this being fully internal, I as Problem Manager prioritise and schedule technical resources to investigate problems. Going forwards, there will be two IT Service Delivery organisations, both with Problem Management functions, one looking at a subset of Problems unique to the organisation being seporated - I am trying to see if people could give me a pointer as to how to handle inbound requests from the new Problem Management team to investigate possible areas of concern and if these engagements should be Request Fulfilment activities (personally I doubt it), Incidents as they are something that has been noticed by a customer, or a direct link into our Problem Management process, which would therefore need to be revised to be externally facing or accept direct engagements, rather than the existing routes of via Incident or SLM.

Cheers for the feedback so far though.

[Timo]

I am dense and I misunderstood your question. Apologies.

Ok, but do you provide Problem Management as a service to the supporting organization as part of you being a managed service provider?

Anyway, I am sure I am still not getting it so I will stop offering an advice.

In the case of our company, we have a client to whom we are a managed service provider and we do problem management for the services that they (client) owns. The problems are typically originated as the ITIL book describes - either as a result of a major incident, a string of repeated incidents or some additional investigation of the top 10 incidents for whatever reporting cycle they use.

Usually something gets designated as a problem (i.e. requiring allocation of specific resources and skills to investigate) when a service delivery manager gives his ok after specific info about major incidents or recurring incidents have been brought up to his attention during weekly meetings. This is when a Problem Manager gets involved from the perspective of managing Problem Control and Error Control activities. In our case it works ok although this is primarily a reactive mode of operating since really additional resources (meaning client's $$$) being thrown mostly when $hit hits the fan (major incidents). I am not hugely involved but don't know of any major issues with this approach.

Hope this helps somewhat.

[Diarmid]

[OftenConfused]

Denise,

Thankyou for your support.

[Diarmid]

Now I'm confused.
_________________
"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

[OftenConfused]

Diarmid,

I felt thanking commentors in sequence would be better, hence the response to Denise.

Thankyou for your review, I understand and agree - we are acting as resources within a different Problem Management process.

A complication has been brought into this, by the fact the service being delivered during the transition of IT Services from our organisation to the seporated company's IT Service Management organisation, which is 'We will offer the same level of service as current' which means there are no formal SLAs in place for Problem Management nor resource allocation to the seporated company's Problem Management function.

This complication means, to offer the same level of service, I believe I need to review the Problems within the seporated company's organisation, as though they are still part of our company - therefore following our Prioritisation matrix and criteria. This in it's own right is not that hard - I am just curious how, in this scenerio, with the seporated company existing for about 18 months during the transition, they engage our company to request resources to support their Problem Management process, and how we classify their enagagement for resource, e.g. a Request for resources, an Incident, A new type of problem etc.

[OftenConfused]

OftenConfused has done it again, read 'Dense' as 'Denise' - this might explain a lot.

[Diarmid]

I'm sure it's not the first time that things like problem management have fallen through a hole when setting up your kind of arrangement and it goes without saying that this needs to be formally remedied with a clear definition of what is required and what is offered.

Having said that, it should be fairly straightforward to establish a protocol for reactively managing problems, but the service will suffer (with pain for both service provider and customer) if you do not also establish effective proactive problem management somewhere in the equation, and this could be more of a problem.

There is a tendency for people in business, and in IT, to see IT service as a simplified, easily compartmentalized and somewhat mechanical thing, missing the degree of interrelatedness, if not real integration, that actually exists between an internal service provider and the business as a whole.
_________________
"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

[OftenConfused]

Hi All,

Thankyou all for your support, it has helped clarify some of the questions in my mind and has led me to create new services that are offered to the seporating company and on this basis, the two Problem Management functions can operate independently, with requests for resources being placed against the newly created business services we are offering.

Cheers again for all of your support, views and comments, they have been very helpful.

Regards
Often Confused.

[Timo]

Wait... So I am Denise?

[UKVIKING]

no timo

you are dense

diarmid is confuased
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Diarmid]