Трансформация ИТ-подразделения: когда изменения необходимы

Трансформация ИТ-подразделения – это серьезный вызов бизнесу. Но сегодня она является необходимостью практически для любой компании, желающей сохранить свои позиции на рынке. Директор по разработке ПО компании IT_One Петр Левин рассказывает, кто должен участвовать в этом процессе, и из каких основных этапов он состоит.

Каждая из компаний по-своему ИТ

Современные подходы к цифровизации и автоматизации компаний существенно изменили требования к ИТ – как в инфраструктурном, так и в кадровом направлении. Повсеместно внедряются всё более сложные технологии, растут запросы к ИТ-подразделениям от внешних и внутренних заказчиков – например по скорости вывода того или иного продукта на рынок (показатель time to market). Методология DevSecOps приходит на смену DevOps. Эти и многие другие факторы говорят о том, что ИТ-подразделение компании не просто может – а обязано гибко реагировать на новые вызовы, меняться вслед за ними.

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

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

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

Когда нужна трансформация ИТ-структуры

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

Но это общие тезисы, за которыми кроется множество частных случаев. Например, у компании-разработчика программного обеспечения для госсектора есть ряд заказчиков, каждый из которых приходит со своими запросами на изменения и своей "дорожной картой" по выпуску релизов продукта. Бывает, что новые потребности появляются с пометкой "срочно", и такие внеплановые задачи могут составлять от 10 до 40% всего объема. Команда начинает работать в режиме аврала, и это – реальная причина, когда трансформация необходима. Если компания не может повлиять на хаотичный поток задач, она должна отрабатывать его с наименьшими потерями: обеспечить правильное планирование, наладить приоритезацию задач, искать резервные ресурсы.

Другой пример связан с внутренней разработкой программного продукта, когда для его поддержки и расширения функциональности требуются постоянное увеличение штата специалистов, а следовательно – и бюджета. По разным источникам, индексация бюджетов на ИТ в разных компаниях составляет до 15-20% ежегодно. Чтобы бизнес не начал работать только на ИТ, тоже нужна трансформация: более эффективная организация подразделений, исключение дублирующих процессов и бюрократии, выстраивание коммуникационной среды, экономия, внедрение Agile-методологий.

Как правило, один и тот же фактор, говорящий о необходимости изменений, проявляется как внутри команды (например, она перестает справляться со своими обязанностями, требованиями заказчика, происходит текучка кадров), так и в бизнес-показателях (снижение прибыли, срыв контрактов, повышение времени time to market и т. д.). Сигнализировать о предпосылках к трансформации могут и руководители, и рядовые сотрудники.

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

Алгоритм проведения трансформации

Если запросы на изменения в ИТ-департаменте могут поступать как "сверху", так и "снизу", то инициировать трансформацию однозначно необходимо "сверху вниз", то есть со стороны высшего руководства. Собственник бизнеса или топ-менеджер, отвечающий за развитие ИТ, – CEO, CIO, технический директор – наиболее объективно понимает, что существующая модель стратегически неэффективна и требуются изменения в подходах. Он формирует общие представления о том, что именно необходимо поменять и с какой целью, а также мотивирует сотрудников. Таким образом складываются условия для проведения изменений.

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

Второй шаг – правильная организация коммуникаций и мониторинга на уровне среднего менеджмента. Менеджеры среднего звена – те специалисты, которые и "тянут" проходящую трансформацию, обеспечивают ее выполнение и способны минимизировать сопротивление изменениям. Они видят ситуацию изнутри, понимая все нюансы, в том числе влияние на команду и бизнес-процессы "человеческого фактора", отдельных сотрудников. Возможно, уже в этот момент придется столкнуться с людьми, которые категорически против изменений, – и так или иначе решать эту проблему. Уже на этом шаге я бы порекомендовал привлечь стороннего коуча или консультанта, специалиста по изменениям. В самом ИТ-подразделении также стоит ввести временную должность – менеджера по трансформации (Transformation Manager), который управляет всей цепочкой изменений и взаимодействием между отделами и группами.

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

Четвертый шаг – оценка рисков, последствий трансформации, ее воздействия на текущий бизнес. Важно понимать, что когда процессы уже перестроены, "откатить" их до прежнего состояния очень тяжело или даже невозможно – особенно когда речь идет о крупных организациях с ИТ-штатом в несколько сотен человек. Необходимо оценить все возможные риски и подготовить план смягчения к каждому из них. Здесь опять же рекомендуется помощь сторонних экспертов, которые провели бы независимый аудит рисков.

Пятый шаг – собственно осуществление трансформации. Как и любой бизнес-процесс, она может проходить разными способами – начиная от популярных методологий Agile или SCRUM, заканчивая старыми проверенными методами управления. Главное, чтобы каждый этап изменений соответствовал целям и задачам, поставленным перед компанией.

Результат трансформации. Лайфхаки

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

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

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