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

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

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

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

Disaster locomotion

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

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

Root cause

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

Внутренние границы

• Границы между командами развития приложения и системы затруднили коммуникации, синхронизацию планов, и возможностей с учетом произошедших изменений.
• Планы развития приложения не были синхронизированы с возможностями команды развития производственной системы.
• Затруднения поддержки производственной системы не были надлежащим образом оценены командой развития клиентского приложения, как внешние негативные факторы.
• Разная скорость, принципы работы, разделение развития и сопровождения приложений добавляли в коктейль пены “мы и они”.

Граница между ИТ и бизнесом

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

Недооценка системного эффекта мультипликации дефектов 

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

Выводы

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