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

Burning man

Короткий пример негативной подкрепляющей связи системной динамики в области управления ИТ-услугами.

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

Ветра перемен не щадят никого, и, после серии штормов, компания обнаружила себя в ситуации, характеризующейся следующими наблюдениями:

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

Disaster locomotion

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

    1. Наша компания, как и положено каждой уважающей себя цифровой компании, изменялась. В частности, однажды сильно изменилась система управления производством услуг, которые компания предоставляет клиентам. Это был масштабный проект, осуществленный с привлечением сторонних профильных компаний. Несмотря на то, что в рамках проекта были предусмотрены мероприятия по передаче системы в эксплуатацию, способности и знания собственных специалистов в области поддержки центральной информационной системы, управляющей производством, были точкой напряжения и узким местом. Это нормально.
    2. Вслед (на самом деле, параллельно) за изменениями производственной системы изменялось и приложение, через которое компания общалась со своими клиентами. Это приложение управлялось собственной командой развития и поддержки, имело собственный роадмап развития, в связи с развитием спектра услуг, предлагаемых клиентам.
    3. Поскольку приложение и системы управления производством интегриованы довольно плотно, то в какой-то момент трудности поддержки производственной системы стали отражаться инцидентами клиентского приложения. Сложности порожденные этим не просто добавились друг к другу, а умножились, поскольку ресурсы команд, априори, ограничены, а количество ежедневно поступающих инцидентов подскочило экспоненциально. Мы же помним, компания работает с розничным рынком.
    4. Нагрузка на подразделения, занимающиеся развитием и сопровождением в двух основных областях компании (сбыт и производство) быстро стала драматической. Эти команды потеряли возможность остановиться и взглянуть на засасывающий их водоворот сверху, потеряли возможность инвестировать собственные (отсутствующие) ресурсы в структурные меры по изменению этого состояния. Так как эти команды, продукты и ресурсы связывают многие другие области управления, вспомогательные системы, то негативный эффект отразился и на поддержке и развитии этих областей. 
    5. Приоритеты бизнес-руководства компании, не обладающего полным пониманием происходящих негативных процессов и их системной синергии, в силу низкоуровневости этих трендов и кажущейся локальности узких мест, ориентированы в первую очередь на развитие . Что может быть совершенно корректно с точки зрения процветания бизнеса компании на рынке в целом, но может стать той нагрузкой, которую имеющиеся ресурсы «run the business» в их текущей архитектуре не смогут обеспечить.

Root cause

Что помешало компании не сползти в эту бездну, увидеть тренд и остановиться на осыпающемся краю?

Внутренние границы
  • Границы между командами развития приложения и системы затруднили коммуникации, синхронизацию планов, и возможностей с учетом произошедших изменений.
  • Планы развития приложения не были синхронизированы с возможностями команды развития производственной системы.
  • Затруднения поддержки производственной системы не были надлежащим образом оценены командой развития клиентского приложения, как внешние негативные факторы.
  • Разная скорость, принципы работы, разделение развития и сопровождения приложений добавляли в коктейль пены «мы и они».
Граница между ИТ и бизнесом
  • Бизнес подразделения производством и бизнес продаж были дружно ориентированы на развитие и дальнейшие изменений, при этом они значительное время оставались в неведении о текущих эксплуатационных трудностях. Т.к. страдающие ИТ-подразделения, каждое по отдельности, думали, что эти негативные эффекты временные, и с ними удастся справится без эскалации и стратегических вмешательств, удастся соблюсти обязательства.
Недооценка системного эффекта мультипликации дефектов 
  • Узкие места в ключевых областях породили веерные эффекты почти по всем остальным областям, при решении любых нелокальных вопросов.
  • Взрывной характер клиентского отклика всегда является вызовом, и этот раз не стал исключением.

Выводы

Мыслите системно, разрушайте мешающие барьеры и берегите людей.

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

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

Ваш адрес 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