OPINION Most SLAs are too detailed and complicated, with dozens or hundreds of metrics, mostly technical measures taken at the IT provisioning end. But these are meaningless to the business user
The result is anything but desirable. The user views IT as failing to deliver the value promised and not caring about the business or cleaning up their act. Rebuffed by IT, the business user will pursue her concerns through other channels: the CFO, CEO, the annual budget planning cycle. IT views the client as an unreasonable complainer; nothing will make them happy, so why try?
The incident is a composite but highlights the difficulty in developing and maintaining a good working relationship between the business user and IT that has the trust and give-and-take needed to maintain open communications through the inevitable mistakes and problems that will happen. That’s what an SLA should be, defining the services and the expectations for how those services are to be delivered and setting out the process to be used when something isn’t working or there is a disagreement on what “working” means. Both parties have to be confident that the SLA is measuring the things that matter to the business in its terms and in the processes to deal with disagreements and problems.
And what and how to measure? The accounts payable application is only needed during business hours, but the corporate Web store is needed 24/7. If accounts payable fails for 15 minutes, it’s an inconvenience, but probably can be managed through normal processes in AP. If IT is using a charge-back system, that service level will be reflected in the cost of the services. However, if the Web store is unavailable for an hour, especially at peak times, it is lost sales opportunity with the risk that both existing and new customers may move on, never to be seen again. SLA measures have to be sensitive to the need, business risk, reputational risk, and costs to manage the service.
Another SLA “feature” that erodes business user trust is carving out maintenance times from the SLA measurements. If an application must be unavailable for four hours each week, then the SLA should be transparent and include it. Hence the 99.9 per cent becomes 97.5 per cent per week. Looks terrible when 24/7 is the expected norm, but clearly shows the business unit owner the limits of the infrastructure she’s willing to pay for.
The hard part for many of us is that SLAs are already in place, they’re complex and technical, and difficult to relate to the actual business processes. Where to start the change? With that cranky client that you know you can’t satisfy. You can find solutions to the technology problems that are hurting his business. It’s only a question of time, money, and/or focus. The business user needs to be reassured that IT is being responsive within its resource constraints and understands that the fix needed may require him to change expectations based on cost. While not a panacea, re-building the SLA offers the opportunity to establish a framework to work together in both good and bad times, starting by resolving long standing frustrations and moving on to work together to make the business run as well as it can.
Sponsor: IBM Canada
The software edge
Five key trends were identified as critical to competitiveness, each underscoring the role of effective software development in a global CEO survey undertaken to determine how organizations view top technology trends and their role in market strategy.