Управление инцидентами в бизнес-процессах компании

В редакцию портала поступил вопрос:

Коллеги, всех приветствую.

Хотел поднять тему внедрения управления услугами на уровне предприятия (Enterprise Service Management). На тему натолкнула статья Стюарта Рейнса Incident Management Isn’t Just For IT (оригинал optimalservicemanagement...isnt-just-for-it, перевод habrahabr.ru/post/347488/).

Кому-нибудь приходилось участвовать в таком преобразовании процессов? С какими трудностями сталкивались? Известны случаи, когда инициатором таких проектов был именно ИТ и ИТ оставалось рулить процессами? На сколько успешно это было?

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Сергей

    ИМХО большой ошибкой является попытка управлять клиентским опытом АБСОЛЮТНО так же, как инцидентами в ITSM, что пытаются делать некоторые поставщики Service Desk. Если только задачей является НЕ повышение качества клиентского сервиса, а только возврат недовольных клиентов (service recovery). Но даже в этом случае есть множество нюансов, которые к сожалению не понимают поставщики Service Desk. Главный нюанс — Необходим комплексный подход. Пример реализации такого подхода см. www.cxm-online.ru

      1. Сергей

        Коротко — сложно )). Нужно сначала определить, что такое качество клиентского сервиса (соответствие ожиданий и восприятия), понимать, чем отличается обратная связь (аналог инцидентов) от репрезентативного опроса (NPS, CES, CSI, ...), понимать разницу между соблюдением корпоративного стандарта обслуживания, воспринимаемым качеством обслуживания, удовлетворенностью и эмоциональной лояльностью. Если всё это понимать, тогда относительно непросто пояснить, что управление инцидентами —

        это очень небольшая часть Enterprise Service Management, нацеленная на решение небольшой частной задачи, которая без всего остального большого смысла не имеет. Если эта тема представляет интерес, можно как-нибудь об этом поговорить ))

  2. Владимир Невский

    ИМХО самая главная трудность — убедить принимающих решения лиц о следующем:

    1. Каждое бизнес-подразделение компании хочет иметь своё ПО и хочет единолично им управлять, но целесообразно внедрять решения на одной/единой платформе (легче и дешевле их развивать, сопровождать и интегрировать друг с другом).

    2. Не нужно изобретать велосипед и наступать на грабли — есть методология ITSM, которой не один десяток лет, и на которую их бизнес-процессы стройно ложатся. Статья с примерами выше (от коллег) и, например, тут: www.cio.ru/articles/223.

    +Исполнитель, как правило, может реализовать всё, что хочет Заказчик. Заказчик часто сам не знает, что ему нужно или потребуется в будущем. Сертифицированное ПО на соответствие методологии ITSM, как правило, содержит необходимый и избыточный функционал, который будет востребован в будущем или появится в новых версиях. Т.е. функционал решения, не подкрепленного методологией — в руках Заказчика и опыта Исполнителя; функционал решения ITSM — в руках мирового сообщества (вот не надо говорить про нюансы и особый путь, проблемы, с которыми сталкиваются — везде одинаковые).

    3. Есть мнения, что каждая компания должна самостоятельно пройти период взросления и/или общее для всех решение внедрять долго: либо осознанно внедряем отдельное решение для конкретной задачи по инициативе бизнеса (в будущем — переделываем), либо на первом этапе внедряем общее решение ITSM от ИТ по частям бизнес охвата и на один, максимум, два процесса.

    1. Сергей

      Вы абсолютно правы. Искать под фонарем (где светло) действительно очень удобно, особенно если платят не за находку (читай — эффективность управления), а за процесс :-). Давайте делать, как умеем. Тем более, что 99% клиентов все равно не понимает )).

  3. Андрей другой

    Я думаю, стоит опять вспомнить с чего все (ITIL) началось. Группу ученых (не из ИТ) попросили разобраться в том, чем занимаются ИТ. Результат оказался следующий — деятельность ИТ очень похожа на бизнес-процесс предоставления услуг. Этот результат попытались изобразить в виде моделей бизнес процессов, но на достаточно дилетантском уровне — без применения уже известных на тот момент методик и нотаций.(Это, к стати, продолжается и по сей день). Так вот, даже на достаточно низком уровне абстракции бизнес процессы предоставления услуг (не только ИТ , но и вообще любых услуг) очень похожи и именно поэтому процессы из ITIL и поддерживающий их инструментарий можно успешно использовать для управления предоставлением любых услуг. Стоит ли объединять инциденты из «бизнеса» с инцидентами из ИТ, как это предлагает автор? Я лично очень сомневаюсь. Мне больше нравится модель, принятая в аутсорсинге — регистрируется инцидент в основном бизнесе, выясняется (или нет) что он связан с обеспечивающей услугой (может ИТ, может еще какой) — и он траслируется по принадлежности, Когда поставщик решает свою часть, в основном бизнесе решают остальное и закрывают инцидент целиком — и у себя и у поставщика.

    1. Владимир Невский

      Да, описанную Вами модель, я тоже часто привожу в качестве примера: в случае если у каждого бизнес подразделения будут свои уникальные трекинговые системы, то одно и тоже событие будет порождать несколько сущностей (со своими уникальными номерами) в разных системах учета, которые должны будут как-то синхронизироваться друг с другом. Удобно ли это — нет конечно. Это не будет эффективно работать, как с технической, так и с организационной точек зрения. Представьте: у каждого бизнес подразделения — своя первая линия; Вы — клиент или сотрудник компании; Вам всё равно, кто именно будет решать Вас вопрос, а Вас «перекидывают» с одной линии на другую и присылают на почту разные номера тикетов. Удобно клиенту? Где единая точка входа? Удобно проводить расследования инцидентов?

      Стоит ли объединять инциденты из «бизнеса» с инцидентами из ИТ — да, конечно!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27
ОКТ
1