#deepitsm #management #otus
Слышали когда-нибудь термин "приоритеты запросов и инцидентов"?
В любой современной компании есть ИТ-отдел. В каждый ИТ-отдел поступают обращения пользователей – иногда им просто нужна помощь, иногда они сообщают, что что-то сломалось (случился инцидент). Поток обращений может быть довольно большим, а ИТ-специалистов, как всегда, не хватает. Очень важно правильно выстраивать поступающие заявки в очередь, чтобы сотрудники ИТ брали в работу сначала те из них, которые наиболее важны, а только затем следующие. При этом хотелось бы, чтобы задачи «не зависали», и даже не очень важные всё равно решались.
Чтобы выстраивать заявки в очередь, обычно используется понятие «приоритет». Чем он выше, тем скорее нужно браться за работу. Предполагается, что у каждого ИТ-специалиста есть очередь задач, и он берёт из этой очереди задачи в порядке убывания приоритета. Всё хорошо в этой схеме, осталось только понять, как определять приоритет для каждой новой пришедшей заявки.
Вариант подхода к решению – посмотреть умные книжки, например, библиотеку ITIL. Там нам сообщат, что при определении приоритета нужно учесть степень влияния (масштаб бедствия) и срочность (как быстро, по мнению пользователя, нужно выполнить данную задачу). Это очень разумная рекомендация. Вот только остаётся неясным как это всё увязать с крайним сроком, который должны быть виден и ИТ-специалисту, и заявителю, и как сделать так, чтобы до заявок низкого приоритета тоже доходили руки. Желательно до того, как расстроенный пользователь нажалуется своему начальнику, который настучит на ИТ-руководителя на очередном совещании при согласовании ИТ-бюджета. То есть – в самый неподходящий момент.
На практике многие компании поступают по такой схеме: степень влияния (определяется при регистрации заявки) + срочность (оценивается со слов заявителя) = приоритет (чем важнее и срочнее, тем выше). Далее смотрим на ИТ-услугу, которая затронута, а точнее – на SLA по этой услуге, откуда берём крайний срок для данного приоритета. Например: затронут только один сотрудник (влияние низкое низкое), срочность – не к спеху (низкая), приоритет получается низкий, для него крайний срок по SLA – 3 рабочих дня. Заявка встаёт в очередь, так как наверняка есть более срочные работы. Но через пару дней до окончания крайнего срока остаётся всего ничего – один рабочий день, несколько часов. В этот момент система автоматизации ИТ сама поднимает приоритет повыше, и заявка становится более важной. ИТ-специалист не забудет её сделать, при том до окончания крайнего срока, обещанного пользователю. Который никогда не меняется, ибо SLA – это наше всё.
Вот так текст хороших книг (ITIL) можно использовать на практике, чтобы сделать работу ИТ более эффективной.
Слышали когда-нибудь термин "приоритеты запросов и инцидентов"?
В любой современной компании есть ИТ-отдел. В каждый ИТ-отдел поступают обращения пользователей – иногда им просто нужна помощь, иногда они сообщают, что что-то сломалось (случился инцидент). Поток обращений может быть довольно большим, а ИТ-специалистов, как всегда, не хватает. Очень важно правильно выстраивать поступающие заявки в очередь, чтобы сотрудники ИТ брали в работу сначала те из них, которые наиболее важны, а только затем следующие. При этом хотелось бы, чтобы задачи «не зависали», и даже не очень важные всё равно решались.
Чтобы выстраивать заявки в очередь, обычно используется понятие «приоритет». Чем он выше, тем скорее нужно браться за работу. Предполагается, что у каждого ИТ-специалиста есть очередь задач, и он берёт из этой очереди задачи в порядке убывания приоритета. Всё хорошо в этой схеме, осталось только понять, как определять приоритет для каждой новой пришедшей заявки.
Вариант подхода к решению – посмотреть умные книжки, например, библиотеку ITIL. Там нам сообщат, что при определении приоритета нужно учесть степень влияния (масштаб бедствия) и срочность (как быстро, по мнению пользователя, нужно выполнить данную задачу). Это очень разумная рекомендация. Вот только остаётся неясным как это всё увязать с крайним сроком, который должны быть виден и ИТ-специалисту, и заявителю, и как сделать так, чтобы до заявок низкого приоритета тоже доходили руки. Желательно до того, как расстроенный пользователь нажалуется своему начальнику, который настучит на ИТ-руководителя на очередном совещании при согласовании ИТ-бюджета. То есть – в самый неподходящий момент.
На практике многие компании поступают по такой схеме: степень влияния (определяется при регистрации заявки) + срочность (оценивается со слов заявителя) = приоритет (чем важнее и срочнее, тем выше). Далее смотрим на ИТ-услугу, которая затронута, а точнее – на SLA по этой услуге, откуда берём крайний срок для данного приоритета. Например: затронут только один сотрудник (влияние низкое низкое), срочность – не к спеху (низкая), приоритет получается низкий, для него крайний срок по SLA – 3 рабочих дня. Заявка встаёт в очередь, так как наверняка есть более срочные работы. Но через пару дней до окончания крайнего срока остаётся всего ничего – один рабочий день, несколько часов. В этот момент система автоматизации ИТ сама поднимает приоритет повыше, и заявка становится более важной. ИТ-специалист не забудет её сделать, при том до окончания крайнего срока, обещанного пользователю. Который никогда не меняется, ибо SLA – это наше всё.
Вот так текст хороших книг (ITIL) можно использовать на практике, чтобы сделать работу ИТ более эффективной.