SLAs in non-IT situationgreenspun.com : LUSENET : Service Level Management : One Thread
Can anyone help. I've read the related article and large part of the book but am looking for some practical examples.
I'm currently looking to implement SLAs for part of a large global bank, most of the work being not easily measurable and quantifiable. Has anyone else been in a similar situation?
It appears to me that much of what I will have to implement is a series of checkpoints, using these to drive work monitoring and measurement of the many services provided.
These checkpoints will take the form of (all in agreed timeframes) - acknowledgement of work - estimates - commencement - regular updates - QA - sign-off - implementation - etc.
as well as measurements and tolerance within agreed %s of original estimates, costs and timescales.
I do realise that we should be trying to drill down further into the services provided but initial short timescales will not allow this. So an interim set of measurements would be deemed better before moving on to a lower-level discipline.
Does anyone have any views or esperiences?
Thanks for any help or info anyone can provide.
-- Kenny Reid (email@example.com), October 28, 2002
It sounds like you are more interested in measuring process efficiency than in developing service level agreements. There are similarities between service level agreements (internal or external) and process checkpoints. If I were to extend the analogy the service level objectives in an SLA are akin to key performance indicators in process measurements. Your described approach indicates process. Is that what you are seeking, or are you seeking to craft an actual service provider/consumer agreement?
-- Mike Tarrani (firstname.lastname@example.org), October 28, 2002.
Thanks for your answer, interesting. I'm not sure if I'm confused now, your point does make sense. I think where I'm coming from is that we are focusing on proceess, as, although we are not starting from scratch, formal workflow processes need to be put in place to support the work being done - add to this the fact that my dept. provides services (not software, systems availability etc.) and I feel that in the first instance we are using process measures to monitor the services that we provide.
Does that make sense? Have you had experience of this? I think we need to make services processes measurable. As I think I intimated in my initial post, drilling further down into, or extrapolating, data later may follow. Currently deadlines are tight!
Anyway, thanks for your advice.
-- Kenny Reid (email@example.com), October 29, 2002.
Here is how I would approach it (bear in mind this is high level)
I would define
(1) entry criteria for each process (what either triggers the process or what must be in place before the process starts; i.e., for a loan application a completed and validated application and qualified borrower) (2) tasks (3) validation (what quality checks are performed to ensure that the tasks have been properly accomplished) (4) exit criteria (a function of validation as well as entry criteria for the next step in the process chain)
Once you have a defined view of the process(es), then you can insert measurement. Among the most common metrics are: * cycle time (how long should the process take end-to-end, and perhaps for each task - performance standards) * response (what is the maximum allowable elapsed time between an event that either triggers the process or constitutes entry criteria; what are the goals for initiating an action based on such an event) * maximum allowable rework (redoing a step, rejecting something that does not meet entry criteria, validation faliure rate, etc.) * throughput (using loan applications as an example, how many should be processed in a workday, or per hour, etc.) * defect rate (related to maximum allowable rework - how many errors per x number of units [loan applications for example] are allowed * loss thresholds (again, using the loan application example, what is the ceiling on loss from bad loans that resulted in streamling the process and trading a certain amount of risk to achieve higher throughput by eliminating due diligence steps)
The above examples are not inclusive, but just to get you thinking about can be measured. What should be measured is another question. I approach it by tracing goals and objectives for service processes to business strategies and tactics. For example, to achieve high customer acquisition in the case of loan applications you would want to process a loan before the customer goes elsewhere (without imposing a risk of loss by writing bad loans, of course). Customer retention is a function of how speedy and accurate the customer's queries are met and other level of service factors.
Once you set service targets that meet business requirements, the next step is to see if you can actually meet them. The difference between what is needed and what can be delivered needs to be subjected to a gap analysis that takes into account not only what needs to be done in order to meet service targets, but to also determine if it's cost effective to do so. Spending $200 to acquire a customer when it's only cost effective to spend $100, for example, is a clear indication that a service goal needs to be adjusted - that is where the providers of the service and the consumers of that service need to negotiate a 'sweetspot' and then agree on the service levels.
I'm tempted to expand on process improvement strategies, etc., but will cut this short for fear that I've innundated you with too much information already.
Best regards, Mike http://www.tarrani.net
-- Mike Tarrani (firstname.lastname@example.org), October 30, 2002.