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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

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

    Добрый день!

    Последние лет 5 именно этим и занимаемся.

    Если интересно, можно почитать тут (из последнего):

    habrahabr.ru/post/347338/

    www.naumen.ru/events/webi...a-za-ramkami-it/

  • Сергей

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

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

      • Сергей

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

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

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

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

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

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

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

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

    • Сергей

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT