{"id":6884,"date":"2017-03-21T17:26:11","date_gmt":"2017-03-21T17:26:11","guid":{"rendered":"https:\/\/multiacademstg.wpengine.com\/20000academy\/?p=6884"},"modified":"2024-12-12T16:40:17","modified_gmt":"2024-12-12T16:40:17","slug":"itiliso-20000-service-level-requirements-ensure-you-deliver-what-the-customer-asked-for","status":"publish","type":"post","link":"https:\/\/advisera.com\/20000academy\/blog\/2017\/03\/21\/itiliso-20000-service-level-requirements-ensure-you-deliver-what-the-customer-asked-for\/","title":{"rendered":"ITIL\/ISO 20000 Service Level Requirements \u2013 Ensure you deliver what the customer asked for"},"content":{"rendered":"<p>It\u2019s probably happened more than once: an IT service achieves Go-Live maturity, only for you to figure out that it\u2019s not what the customer asked for. That\u2019s bad news. The good news is that it could have been the customer who discovered that, instead of you. Whatever the case is \u2013 it\u2019s wrong, and it shouldn\u2019t happen.<\/p>\n<p>IT Service Management (ITSM) based on either <a href=\"https:\/\/advisera.com\/20000academy\/what-is-itil\/\" target=\"_blank\" rel=\"noopener noreferrer\">ITIL<\/a>\u00a0or <a href=\"https:\/\/advisera.com\/20000academy\/what-is-iso-20000\/\" target=\"_blank\" rel=\"noopener noreferrer\">ISO 20000<\/a>\u00a0encompasses (of course, if you have adopted it) the whole lifecycle of the IT service. And, one of the first steps is to talk to the customer or the business and see what they are looking for. These requirements, at this stage, are still business-related. Once you know what your customer is looking for, it shouldn\u2019t be hard to continue and quantify those requirements. And, there you go \u2013 you can describe those requirements from a service point of view. These are your <a href=\"https:\/\/advisera.com\/20000academy\/documentation\/service-level-requirements-iso-20000\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Level Requirements (SLRs)<\/a>.<\/p>\n<h2>What are the SLRs?<\/h2>\n<p>The ITIL and ISO 20000 definitions of SLRs are not that clear, and hardly emphasize the importance SLRs have in an IT service lifecycle. The point is, if business requirements (which are prerequisites in order to define SLRs) are not clear and well defined, it\u2019s difficult to expect that the service will fulfill customer expectations. So, to be sure that the service delivers what the customer requires, you need to set up the requirements right from the beginning.<\/p>\n<p>So, as you can see \u2013 SLRs are pretty important. Therefore, the logical question is \u2013 who is responsible? SLRs should be coming from, and are agreed on with, the customer. There are two processes whose jobs are, primarily, related to customers: Business Relationship Management (BRM) and Service Level Management (SLM).<br \/>\n<div id=\"middle-banner\" class=\"banner-shortcode\"><\/div><script>loadMiddleBanner();<\/script><br \/>\n<div id=\"side-banner-trigger\" class=\"banner-shortcode\"><\/div><br \/>\nWhen we are talking about the process of defining SLRs for a new service \u2013 they will be defined during the service strategy phase of the service lifecycle. Usually, the people who are managing the service portfolio or someone from Business Relationship Management will define high-level SLRs, which are needed (and, usually, enough) to make a decision \u2013 go or no-go with the service. Later, SLM will take over and refine the definition, including, as much as possible, measurable SLRs.<\/p>\n<p>If we have an existing service, then the <a href=\"https:\/\/advisera.com\/20000academy\/documentation\/service-level-management-process-iso-20000\/\" target=\"_blank\" rel=\"noopener noreferrer\">Service Level Manager<\/a>\u00a0(who is permanently in contact with the customer) will be actively involved in SLR definition.<\/p>\n<p>While defining SLRs, Service Level Management is responsible for ensuring that they are defined and agreed on with the customer, in detail. Further on, SLM is responsible for management of the SLRs until the service reaches the operational stage. The SLRs could change with time (i.e., until the service reaches the live environment); therefore, SLM is responsible for managing the SLRs. SLRs are related not only to new services, but also to changes to an existing service.<\/p>\n<h2>What\u2019s the use of SLRs?<\/h2>\n<p>SLRs make clear what the \u201crules of the game\u201d are. If you start developing, e.g., a new service based on a few conversations with the customer \u2013 that\u2019s a road to disaster. Sooner or later, your point of view and that of your customer will differ. And, it\u2019s really hard to get out of such a situation. Therefore, SLRs are used for:<\/p>\n<ul>\n<li>Foundations \u2013 define SLRs as a foundation for design of the service.<\/li>\n<li>Don\u2019t wait for the customer. Be proactive and suggest \u2013 what could be expected, i.e., what is realistic, what does best practice say, which performance is achievable . . . but, don\u2019t over-promise.<\/li>\n<li>Match SLR to delivered service.<\/li>\n<li>Be exact \u2013 avoid explaining what the SLR is, but try to define a measurable parameter. In such a way, you\u2019ll help yourself \u2013 but also make your customer\u2019s life easier (although they may not see it at the moment when SLRs are negotiated).<\/li>\n<\/ul>\n<p>Although it seems that the definition of SLRs is a complex job \u2013 it really doesn\u2019t have to be. To make it easier, the people involved in SLR definition should not do it by themselves. There are experts in the IT organization who should support them, like people from Capacity Management, Technical Management, Application Management, etc. This offers two benefits:<\/p>\n<ul>\n<li>Increase in competency while defining SLRs \u2013 the customer will appreciate that as well.<\/li>\n<li>Future phases of the service lifecycle \u2013 once you define the service and related SLRs, design will take over. Those same experts are sitting somewhere in design and they will take over. The better the SLRs are defined right from the start, the better and easier design will be.<\/li>\n<\/ul>\n<h2>What\u2019s the importance?<\/h2>\n<p>SLRs are the foundation for the <a href=\"https:\/\/advisera.com\/20000academy\/documentation\/sla\/\" target=\"_blank\" rel=\"noopener noreferrer\">SLA (Service Level Agreement)<\/a>. That means that, while developing the service, SLRs will be refined and once you get to the deployment phase \u2013 SLRs will help you describe the service in measurable value. That makes perfect content for the SLA. Since the SLA is used while the service is operational, this means that SLRs are the controlling factor on whether the delivered service fits the customer requirements.<\/p>\n<p>Although some may not like it, investing significant effort right at the setup of the service (or change to an existing one) will be rewarded throughout the service lifecycle. Poorly defined SLRs are a source of failed implementations and arguments with customers. Firstly, let\u2019s say that the customer is always right. Fine, but document what \u201cright\u201d means (SLRs, in this case). And secondly, correcting something that was wrongly implemented creates additional cost. Costs are increasing as a service progresses throughout the lifecycle. So, it\u2019s hard to decide which argument is better (or worse), isn\u2019t it?<\/p>\n<p><em>To implement ISO 20000 easily and efficiently, use our<\/em> <a href=\"https:\/\/advisera.com\/20000academy\/iso-20000-documentation-toolkit\/\" target=\"_blank\" rel=\"noopener\">ISO 20000 Documentation Toolkit<\/a> <em>that provides step-by-step guidance for full ISO 20000 compliance.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>It\u2019s probably happened more than once: an IT service achieves Go-Live maturity, only for you to figure out that it\u2019s not what the customer asked for. That\u2019s bad news. The good news is that it could have been the customer who discovered that, instead of you. Whatever the case is \u2013 it\u2019s wrong, and it &#8230;<\/p>\n","protected":false},"author":32,"featured_media":6886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[404,366,344,204,577,141,578,576],"class_list":["post-6884","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-customer","tag-iso-20000","tag-itil","tag-service","tag-service-level-requirements","tag-sla","tag-slm","tag-slr"],"acf":[],"_links":{"self":[{"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/6884","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/comments?post=6884"}],"version-history":[{"count":2,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/6884\/revisions"}],"predecessor-version":[{"id":17952,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/posts\/6884\/revisions\/17952"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/media\/6886"}],"wp:attachment":[{"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/media?parent=6884"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/categories?post=6884"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/advisera.com\/20000academy\/wp-json\/wp\/v2\/tags?post=6884"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}