{"id":295,"date":"2014-06-02T15:08:34","date_gmt":"2014-06-02T19:08:34","guid":{"rendered":"http:\/\/sites.miamioh.edu\/itservices\/?p=295"},"modified":"2014-06-02T15:08:34","modified_gmt":"2014-06-02T19:08:34","slug":"slas-are-not-the-enemy","status":"publish","type":"post","link":"https:\/\/sites.miamioh.edu\/itservices\/?p=295","title":{"rendered":"SLAs are not the enemy"},"content":{"rendered":"

No reason to arm yourself against the zombie apocalypse – the shared responsibility for logging incidents should not be a scary event. However, there is some information you will need to be armed with, to be successful!<\/p>\n

One major deliberate change in our new Incident Management process is that all incidents will no longer have the same priority.<\/span><\/p>\n

In the old process, solvers are left to decide which incidents should be addressed in which order: first-in, first-out; cherry-picking; favorite-client first; etc. The new process puts the incident priority into the drivers seat. The priority of the ticket, calculated by impact and urgency, determines the resolution timeline.<\/span><\/p>\n

At ticket logging time, the logger selects impact and urgency based on the following rubric. The project team is still refining this as we test it in practical settings.<\/span><\/p>\n

\"\"<\/p>\n

The combination of impact and urgency result in a priority designation (1 – 5) with two time-frames attached:<\/p>\n

    \n
  1. time-to-act: a commitment to have human eyes on the ticket by the Support Desk<\/li>\n
  2. time-to-complete: \u00a0the time the client is back in business; this is not necessarily the same as repairing the service!<\/li>\n<\/ol>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    <\/td>\n\n

    P1<\/p>\n<\/td>\n

    		\n

    P2<\/p>\n<\/td>\n

    		\n

    P3<\/p>\n<\/td>\n

    		\n

    P4<\/p>\n<\/td>\n

    		\n

    P5<\/p>\n<\/td>\n<\/tr>\n

    \n

    \u201cSLA\u201d<\/p>\n<\/td>\n

    		\n

    24×7<\/p>\n<\/td>\n

    		\n

    24×7<\/p>\n<\/td>\n

    		\n

    24×7<\/p>\n<\/td>\n

    		\n

    business hours<\/p>\n<\/td>\n

    		\n

    business hours<\/p>\n<\/td>\n<\/tr>\n

    \n

    time-to-act (hours)<\/p>\n<\/td>\n

    		\n

    .5<\/p>\n<\/td>\n

    		\n

    1<\/p>\n<\/td>\n

    		\n

    1<\/p>\n<\/td>\n

    		\n

    1<\/p>\n<\/td>\n

    		\n

    1<\/p>\n<\/td>\n<\/tr>\n

    \n

    time-to-complete (hours)<\/p>\n<\/td>\n

    		\n

    2<\/p>\n<\/td>\n

    		\n

    4<\/p>\n<\/td>\n

    		\n

    24<\/p>\n<\/td>\n

    		\n

    16 (2 bus. days)<\/p>\n<\/td>\n

    		\n

    56 (7 bus. days)<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    In the new process, all incidents will be reported against these targets, which has several implications for you!<\/span><\/p>\n

      \n
    • \n

      Solvers (those to whom unsolved incidents are escalated) will use the priority and SLA deadline to drive the order in which you address incidents. We anticipate that checking your incident queue twice daily should be sufficient to stay on top of them<\/p>\n<\/li>\n

    • \n

      Priority 1 incidents trigger a special major incident process to bring immediate attention to the incident<\/p>\n<\/li>\n

    • \n

      Priority 2 incidents trigger the major incident process once the 4 hour window has been breached — again to bring immediate attention to the situation.<\/p>\n<\/li>\n

    • There will be times when we fall short and fail to complete an incident before the target is breached. These instances will provide an opportunity to investigate the cause and make incremental improvements to the process, training, tools, or documentation at the heart of the breach.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

      No reason to arm yourself against the zombie apocalypse – the shared responsibility for logging incidents should not be a scary event. However, there is […]<\/p>\n","protected":false},"author":64,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"_s2mail":"yes","footnotes":""},"categories":[6],"tags":[7],"class_list":["post-295","post","type-post","status-publish","format-standard","hentry","category-how-we-work","tag-service-excellence"],"_links":{"self":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/posts\/295","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/users\/64"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=295"}],"version-history":[{"count":0,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/posts\/295\/revisions"}],"wp:attachment":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=295"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=295"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}