Services - From a Local Government and Small Business Perspective
By Andy Atencio Defining Services can be tricky. In our organization, Services are defined based on the needs of our users and customers who in turn use these Services to provide Services to their customers to achieve their organizational goals of providing a safer, cleaner, more accessible, more attractive and fun community. We must align our Service Catalog to support our customer's business objectives.Once Services are defined, the next step is to determine the Service Levels. Again, it is the organizational objectives that will establish the importance of those Services and when they need it. Because our goals include operational excellence, we set our metrics higher than those agreed upon with our customers. To achieve this we had to make sure it was part of our definition of Services. The process of understanding the Levels of Services is the same for a small organization as it is for a large one. Services provided by IT are based on the Level of Service needed for the business purpose. These documents are called Specsheets . Once you have a Specsheet you can negotiate and reach agreements for the Level of Service your customers and users can live with, and that you can provide. Once negotiated, you now have a Service Level Agreement (SLA). Throughout the process of defining Services, remember that the success of a Service is the perception of the customer or user, not the arbitrary assessment of the IT organization. The only way to determine what the customer needs in a Service is to ask the customer, in their terms. The only way to verify if the Service as defined will work in "the real world" is to ask the users. Since these are the measures of success or failure, ensure you have the ability to capture and report on the actual delivery of the Services. For example if you are promising 99% availability for Electronic Messaging and Calendaring, you need to measure the Service in its entirety. Reporting the up time on the e-mail server is not an indication of how well this Service is performing. You need to measure the up time on the messaging Service, which would include the client-side application, network connectivity, server based application availability, Internet connectivity (for incoming and outgoing messages) and several other components. Server uptime becomes a piece of the overall measurement for the Service. In our organization, if you report measures that do not directly tie to business goals it is said to be reporting "sand". The analogy is if you are reporting on the safety of streets during winter snowplow operations you need to report things that support the goal of safer streets. Is it a valid measurement that says last year, we used one million cubic yards of sand, but this year we used two million so the roads are safer? Are the roads safer? Or did you just get more snow? Did you get the same amount of snow, but wasted a bunch of the sand? How does the extra sand help show and define safer roads. This is the same thing that you can say about server up time. If the server was up, but Internet was down was messaging really working? To this end, when you are defining your Service Levels and how to measure them, you have to use quantifiable metrics. You must also measure the level of your customer expectations and the true customer and user need. If you are measuring for a two second message delivery, but your customer is expecting one second, your measurement has no value. Take the time to define your Services and metrics well. Remember, in the end you will be held accountable for the Services as they are defined, the way they are measured, and your ability to prove successful business achievements. J. Andrew "Andy" Atencio is the Manager of Information and Technology for the City of Greenwood Village, a suburb of Denver, Colo. Andy has been in the IT industry for more than 16 years. Want to discuss this article and/or Service Catalog further? Visit our IT Service Management Forum .