Incident management with OLA

[Toshi]

I'm evaluating a ITSM tools based on itil.
However I don't find good tools for me, I want to manage the internal process to fix an incident.

For example.
We have four and more support levels and some different groups in each levels.
We need to know how many incidents to meet the defined period to fix the incident in OLA as each support group.

Does anybody manage the OLA and know a tool ?

In our company, there is a need to track and monitor their support to improve service quality.

[mcardinal]

Toshi,

I do not knwo if this will help but here is my suggestion. Treat your OLA just like you treat an SLA. However, the both the receivers and the providers are internal. Define the services, negotiate between the two groups and activate the OLA. Just make sure that it aligns with the SLA that it ultimately supports.

The only real difference between an SLA, and OLA and an Underpinning Contract is whether the receivers and providers are internal or external to the organization.

Good Luck!

Michael

[Harvey]

I have just been asked to help define the SLA for the applications and systems in our offsite data center.

I have just started working on Service Desk, to include Incident and Problem Management, and have also been looking at Availabily Management, so I guess the timing is right... We will need solid SLA's anyway in order to understand what type of service the customers are demanding...

Anyhow though... I'm not sure how to proceed in creating the SLA.

I have another question as well, which comes first, the SLA or the OLA?

Is there a recommended method in defining and implementing them?

I saw mcardnial posted these in another thread.

[Harvey]

bmc.com/products/proddocview/0,2832,19052_19429_10101852_9987,00.html

This doc has a good explaination of the three, UC, OLA and SLA.

Implementing Service Level Management (pdf)

[Guest]

Harvey and Toshi

The mantra I take with all of Service Management is:

Design from the top down, build from the bottom up.

This means you should begin with an initial draft of the SLA, build OLAs to support it, then go back and readjust the SLA based on any findings from doing the OLAs (cannot meet requirements, technology not currently available, too costly, etc.).

As far as definition, start by identifying your customer (revenue generating person willing to pay for the service). Gather their requirements for service. Then determine if capabilites currently match those requirements. Most likely you will have a gap between requirements and capabilities. Get both parties together to negotiate the gap down as small as possible (price, availability %, support hours, etc). Document the outcome of the negotiation as the SLA. The SLA then becomes the requirements for OLAs and UCs. Go through the same process with those.

Document any gaps or anything not included in the final agreements in a Service Improvement Plan (SIP). This can be used for future planning for improvements in the quality or capabilities needed to deliver the service as desired by the service receiver.

Once you have the documented agreements work with the tech people to make sure the infrastructure is designed and built to meet the terms of the agreements. Developing Service Level Objectives as part of your agreements gives them a target.

Example: Email service is needed 24x7 (requirement). Infrastructure only currently supports 18x7 (capability). During negotiations IT agrees to put in extra servers to bring availability up to 22x7. The gap (3 hours daily) is documented in an SIP for next year's budgeting and planning to put redundant servers in place to fully achieve 24x7.

I hope this clarifies and answers some of your questions.

Michael

[Harvey]

Good points!

One question, when you are having the meeting to determine SLA requirements with internal customers, who is usually recommended to attend the meeting?

For example in a large organization, would it be the managers of various departments who would use the services? Like the manager of Infra the manager of Finance the manager of Ops and what not? Or would it be some type of focus group, with key people from each department?

In the documents I read, it recommended to get IT together within themselves first to determine their capability and to turn this into the OLA. Then, after the OLA is determined, talk to the customers to get their requirements and fill in the gap.

(I am imagining IT support services here, like PC installs, Software installs, hardware replacements, etc... I imagine it would be the same for any service that IT provides though)

Anyway, I think that is what I read anyway.

Thanks for the good advice.

I have read in many places that there are no templates for SLA's available anywhere... But is there some type of format that is recommended, at all?

Currently our organizations SLA's were determined by IT, for IT, and are not enforced or protected in anyway. Not much to work from!

Thanks all~

[Toshi]

Thank you for many suggestions.
Sorry, I didn't look at this as my organization has some change. And then I got to be in charge of SLM and back again.
I think to reconsider the current SLA and so I need to communicate with every relavamt parties and to make a practical plan based on CSIP.

Thank you so much.