{"id":6652,"date":"2016-10-25T16:35:36","date_gmt":"2016-10-25T16:35:36","guid":{"rendered":"https:\/\/multiacademstg.wpengine.com\/20000academy\/?p=6652"},"modified":"2025-03-07T09:27:29","modified_gmt":"2025-03-07T09:27:29","slug":"iso-20000-incident-and-service-request-management-increasing-efficiency-with-information-flow","status":"publish","type":"post","link":"https:\/\/advisera.com\/20000academy\/blog\/2016\/10\/25\/iso-20000-incident-and-service-request-management-increasing-efficiency-with-information-flow\/","title":{"rendered":"ISO 20000 Incident and Service Request Management \u2013 Increasing efficiency with information flow"},"content":{"rendered":"

Once your service is in the live environment, the Incident and Service Request Management process<\/a> will count for the majority of your daily activities. This means, from a practical point of view, that your customers will judge you (as an IT service provider) based mostly (because there are a few more processes in this stage of the service lifecycle) on the efficiency of this process \u2013 this is because it is the most visible process in your user\u2019s or customer\u2019s eyes.<\/p>\n

ISO 20000<\/a>, like ITIL<\/a>, has a very clear and quite extensive description of the requirements. ISO 20000 is different from ITIL in that it sets requirements for incident and service request handling in one process. Nevertheless, ITIL recommendations can be used in ISO 20000 implementation. What needs to be done is a filtering out of those ITIL recommendations that are not required by the standard, and adapting the rest to the company\u2019s requirements.<\/p>\n

One set of ISO 20000 requirements emphasizes the relationship of the Incident and Service Request Management process<\/a> with some other processes in the scope of the SMS (Service Management System). I think that this is good, because it provides strong foundations for the efficiency of the process. Let\u2019s see some more details.<\/p>\n

The reasoning<\/h2>\n

It may sound simple \u2013 there is an incident, and you have to resolve it. It\u2019s the same, or even easier, for service requests. But, the real world is more complex than that. Take, for example, an ongoing change. Another team (i.e., different from the people working on incident resolution) is deploying a change. Let\u2019s say \u2013 an imperfect change implementation. A lot of new incidents are created based on the fact that the change that was recently implemented, or is still in implementation, contained errors. If the team who works on incident resolution knows what\u2019s going on, they could immediately involve the people who implemented that change in order to react and prevent future incidents, and find resolution for existing ones.<\/p>\n

Simply explained, Incident and Service Request Management<\/a> has an important effect on live services, and it\u2019s essential that people involved in the process can see the \u201cbig picture.\u201d This means including all relevant information that can affect their work. Usually, that involves the inclusion of more information than that which is strictly incident, or service request, related.
\n

<\/div>