Just going by ITIL, you first need to define all of your services in a "Catalog of Services". This is good since you need to sit down and access just what you can provide (and at what cost). These services are "flow through" IOW there are SLAs between internal groups (called OLAs). Whenever a SLA is not met, you can drill down and find out exactly which OLA was at fault and do Problem Management on the issue.
This isn't a case where SLAs confine you into "not doing more" for your customers. The costs are built into the SLA, and if your customer wants more - it will cost more - pretty simple. You can always give more service than is paid for - which makes you look like a "miracle worker" (in Scotty's parlance), but it always bites you in the end. Exp. The SAN goes down and 100 servers are wiped out. Which one do you bring up first, second, etc.? If you go strictly by SLA, then that "super service" customer may need to wait - which is NOT what he expects from you. Hey, it happened at Ford - and some servers were out for 3 days (they had to restore the entire SAN from backup - we're talking over 100 Tb).
After that, every customer wanted to know EXACTLY where "in line" they were when things went south. We looked at ranking everyone by business impact - but I had a better idea. He who pays the most, gets the fastest service! It makes a ton of sense since critical apps SHOULD be paying more for support (use eBay-style bidding!).
In the end, no one backed me up and the ranking was relagated to "future study" i.e. nothing was done.
Discussion on:
Message 4 of 1
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
