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

Burning man

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

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

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

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

Disaster locomotion

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

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

Root cause

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

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

Выводы

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

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

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

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

  • Рубрики

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

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT