Портал №1 по управлению цифровыми
и информационными технологиями

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

Опубликовано 26 января 2018
Рубрики: ITSM, Вопрос из зала, Обо всём на свете, Общие вопросы менеджмента, Процессы, Управление инцидентами
Комментарии

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

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

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

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

Также по теме:

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 10

  • Дмитрий Мельников

    Добрый день!
    Последние лет 5 именно этим и занимаемся.
    Если интересно, можно почитать тут (из последнего):
    https://habrahabr.ru/post/347338/
    https://www.naumen.ru/events/webinars/vnedrenie-servisnogo-podkhoda-za-ramkami-it/

  • Сергей

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

    • Олег Скрынник

      Сергей, можете более подробно пояснить Вашу мысль?

      • Сергей

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

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

    ИМХО самая главная трудность – убедить принимающих решения лиц о следующем:
    1. Каждое бизнес-подразделение компании хочет иметь своё ПО и хочет единолично им управлять, но целесообразно внедрять решения на одной/единой платформе (легче и дешевле их развивать, сопровождать и интегрировать друг с другом).
    2. Не нужно изобретать велосипед и наступать на грабли – есть методология ITSM, которой не один десяток лет, и на которую их бизнес-процессы стройно ложатся. Статья с примерами выше (от коллег) и, например, тут: https://www.cio.ru/articles/223.
    +Исполнитель, как правило, может реализовать всё, что хочет Заказчик. Заказчик часто сам не знает, что ему нужно или потребуется в будущем. Сертифицированное ПО на соответствие методологии ITSM, как правило, содержит необходимый и избыточный функционал, который будет востребован в будущем или появится в новых версиях. Т.е. функционал решения, не подкрепленного методологией – в руках Заказчика и опыта Исполнителя; функционал решения ITSM – в руках мирового сообщества (вот не надо говорить про нюансы и особый путь, проблемы, с которыми сталкиваются – везде одинаковые).
    3. Есть мнения, что каждая компания должна самостоятельно пройти период взросления и/или общее для всех решение внедрять долго: либо осознанно внедряем отдельное решение для конкретной задачи по инициативе бизнеса (в будущем – переделываем), либо на первом этапе внедряем общее решение ITSM от ИТ по частям бизнес охвата и на один, максимум, два процесса.

    • Сергей

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

  • Андрей другой

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

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

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

Добавить комментарий для Владимир НевскийОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.
;