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

Коллективное бессознательное – инструмент или осадок опыта

Погружаясь в пучину эксплуатации услуг, первое с чем обычно сталкиваются участники такого погружения – это непредвиденные ситуации в виде сбоев, поломок, а в крайних случаях, и с более значительными последствиями (когда что-то пошло не так или вышло из-под контроля). Эта жизненная ситуация, знакомая каждому, и решаем мы ее по-разному: самостоятельно или обращаясь к специалистам.

Люди, не работающие в ИТ, назовут эти ситуации проблемами, трудностями, обстоятельствами, поломками или катастрофами. ITIL предлагает использовать понятие “инцидент” – как незапланированное прерывание услуги или снижение ее качества. В зависимости от степени тяжести и последствий таких инцидентов выделяется особый вид инцидентов – “значительные инциденты”. В любом случае, главная цель в управлении инцидентами – минимизировать негативное влияние инцидентов путем быстрого восстановления нормальной работы услуги или конфигурационной единицы.  

Инциденты с высоким уровнем влияния требуют немедленного и скоординированного разрешения. В качестве одной из задач управления инцидентами, ITIL определяет обеспечение использования стандартизированных методов для эффективного реагирования, анализа, документирования, текущего управления и отчетности об инцидентах.

Под стандартизированными методами понимается наличие и использование баз типовых решений, баз известных ошибок, моделей под разные типы инцидентов. Создавая модели инцидентов, мы ускоряем процесс обработки, не тратя время на определение необходимых шагов для разрешения инцидента.

Большинство организаций имеет несколько линий поддержки (уровней) для обработки инцидентов:

  • 1-я линия — это Сервис деск;
  • 2-я линия — специалисты по программным, аппаратным, или инфраструктурным системам;
  • 3-я линия — это, как правило, системные эксперты и разработчики.

Если инцидент не может быть решен быстро силами Сервис деска, он может быть эскалирован.

Функциональная эскалация передает инцидент соответствующей команде технической поддержки с соответствующей квалификацией (2-я или 3-я линии), а также может быть эскалирован иерархически, уведомляя соответствующие уровни управления. Любая эскалация увеличивает время обработки инцидента, что критично для разрешения значительных инцидентов. Именно поэтому значительные инциденты должны иметь совершенно иную модель и подход для обработки инцидентов с высоким уровнем влияния, а значит, более короткие сроки.

Руководство по практике управления инцидентами описывает детали, которые должны быть включены в модели для обработки значительных инцидентов:

  • критерии отличающие значительные инциденты от катастроф и других инцидентов;
  • координатора (MIM), ответственного за выполнение работ по восстановлению;
  • специальные команды для расследования и восстановления значительных инцидентов;
  • специальные методы исследования, порядок выделения дополнительных ресурсов, модели коммуникаций с заинтересованными сторонами;

Существует еще одна концепция решения инцидентов без эскалаций – это Роение (sworming). Концепция не нова, т.к. еще в 2008 г. компания Cisco написала об этом в своем официальном документе “Цифровое роение”.

Идея роения заключается в том, что вместо эскалации привлекаются и собираются вместе множество людей, имеющих знания и опыт в разных областях, подобно рою пчел или колонии муравьев, чтобы, предоставить свои коллективные знания для разрешения инцидента, пока не станет ясно, какие компетенции будут наиболее востребованными и необходимыми. В Роении проводят мозговые штурмы и обмениваются идеями друг с другом, и в целом используют групповую динамику, чтобы находить свежие и инновационные решения. В результате работы такого “улья”, дело передается лицу, или лицам, способным его решить.  Swarming стал новым термином для Управления инцидентами в ITIL 4.

А ведь этот подход применяется в Agile- и DevOps командах. Растет сложность и взаимное влияние между системами, и разрушение бункеров между теми, кто разрабатывает и теми, кто поддерживает продукты и услуги на этапе эксплуатации, требует изменения подходов к решению инцидентов.

Совместное усилие группы, направленное на достижение цели, требует сотрудничества и коммуникаций. Традиционный подход с линиями поддержки и эскалациями препятствует сотрудничеству, выстраивая иерархии, бункеры, зачастую поощряя конкуренцию между командами или поиск виноватого в ошибках и промахах.

Применение роения требует изменения культуры. В среде конкурентности или изолированности трудно сотрудничать или делиться своими знаниями. Культура сотрудничества подразумевает доверие и открытость, она сосредотачивается на поиске решения проблем и возможностей, но никак не на обвинении или “назначении” виновных.

Мне кажется, что будь то разработка, внедрение или эксплуатация, требуется создания среды новых подходов не только к работе, но и к изменению мышления, формированию нового мировоззрения и коллективного бессознательного.

А как в ваших компаниях реализуются данные подходы и какие инновационные идеи испытываются на жизнеспособность?

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

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

  • Евгений

    «А как в ваших компаниях реализуются данные подходы?»- Все очень просто. Портал самообслуживания вместо сервис деска. Деление на линии технической поддержки. Классическая эскалация.

    «Какие инновационные идеи испытываются на жизнеспособность?» — Что бы испытать инновационные идеи на практике нужно пройти почетный круг: согласований, встреч, бюрократии и т.д. стоит ли говорить, что к концу прохождения такого круга у всех причастных пропадает стимул и желание испытать (внедрить) инновационную идею?

    Полностью согласен с мыслю, что все любые нововведения в перовую очередь требуют «изменений в мышлении, формированию нового мировоззрения и коллективного бессознательного.», но, к сожалению, создать новую культуру и мировоззрение невозможно без изменения свой личной культуры и без подбора новых руководителей/сотрудников.

    На мой взгляд, самое важное это сделать так, чтобы культура в принципе менялась на постоянной основе. Сейчас многие, а может быть и все стремиться поменять культуру смотрят в сторону Agile, DevOps, ITIL и других страшных слов и все сталкиваются с типичной проблемой «Нам так не надо. Мы привыкли по-другому», но в итоге где-то культура меняется и это хорошо, но смотреть надо дальше в завтрашний день, будет новая культура будет новая методология и весь порочный круг изменения мировоззрения и взаимодействия запустится с начала и только непрерывность изменений в культуре на всех уровнях позволит этого избежать.


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

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

  • Рубрики

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

    • Как обучать команду удаленно
      Обучение — это важный обряд посвящения, который проходит каждый новый сотрудник, чтобы узнать о своей новой роли и обязанностях, встретиться со своими товарищами по команде и …
    • Книга Cleverics про метрики и KPI рекомендована слушателям MBA по направлению ИТ
      Вышедшая в начале года книга Дмитрия Исайченко и Павла Демина «Управление услугами на основе измерений» получила рекомендацию от Высшей школы бизнес-информатики НИУ ВШЭ в качестве …
    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Как бизнес-аналитику встроиться в гибкую среду?
      Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики  зачастую считают, что они должны …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT