Цифровая трансформация компаний
Создаем эффективное крупное ИT-подразделение и правильно фокусируемся на процессах
Сегодня многие крупные компании, напрямую не связанные с производством цифровых продуктов, перенимают опыт технологических гигантов для модернизации собственных ИТ-структур. Но всегда ли это верное решение? Анализ сложных процессов начинается с правильных вопросов, которые задает себе и своей команде руководитель. Помочь их сформулировать и ответить на часть из них для читателей RSpectr решил эксперт по ИТ в банковском секторе, экс вице-президент и технический директор «Ренессанс Банка» Андрей Саломатин.
КАК СТРОИЛИ ИТ-СТРУКТУРЫ РАНЬШЕ
Может ли нефтяной, производственный, финансовый или строительный бизнес успешно использовать опыт технологических компаний при создании собственных ИТ-подразделений и департаментов? Это вопрос не праздный, поскольку повальная мода на все «айтишное» уже привела к тому, что «цифровизацией» у нас не занимаются, пожалуй, только самые ленивые. Что само по себе, наверное, и не плохо. Но только при растущей экономике и избытке ресурсов. В этом случае выброшенные в трубу деньги можно списать на инвестиции в развитие, неудачные эксперименты и так далее. Но в условиях экономии ресурсов – финансовых, технологических, кадровых – к любой модернизации, особенно такой чувствительной и достаточно капиталоемкой, стоит подходить предельно аккуратно, используя чужой опыт и знания. Поскольку цена собственной ошибки может оказаться слишком высокой для бизнеса.
Первоначально в России все не ИТ-компании работали по функциональной модели – то есть имелась функция поддержки ИТ-систем и под нее создавался ИТ-департамент. По мере роста задач функциональная структура усложнялась, и внутри уже ИТ-блока появлялись, например, департаменты развития и сопровождения ИТ, отвечающие за разработку новых и поддержку текущих систем и процессов.
В то же время многие ИТ-компании строились в рамках функционально-матричной структуры, когда есть департаменты разработки, аналитики, тестирования, которые занимались подбором, онбордингом, стандартизацией и частично развитием сотрудников. А под конкретную задачу/проект создавалась отдельная команда путем выделения специалистов различных департаментов. У этой команды появлялся свой персональный руководитель.
Другие ИТ-компании изначально строились по продуктовой модели, то есть структурные единицы возникали вокруг неких продуктов (АБС, хранилище и т. п.), но внутри этих продуктовых направлений обычно воспроизводилась функционально-матричная структура при наличии отдельных общих служб (продаж, архитектуры и т. д.). Затем наступил век agile (гибкая разработка ПО), и ИТ-компании частично трансформировались под использование новых фреймворков – используя где-то SAFE (набор шаблонов организаций и рабочих процессов для реализации agile-методик), где-то модель spotify (набор организационных методик для разработки ПО) и прочее.
ЗАЧЕМ МЕНЯТЬ IT-СТРУКТУРУ
Я категорический противник «карго-культов» и вариантов типа «раз у них получилось, давайте сделаем также», либо «давайте сделаем как “спотифай”». У каждой крупной организации своя культура, свой ИТ-ландшафт и свои особенности. И люди там работают не из «спотифая», а конкретные Вася и Петя из Пензы или Саратова. Поэтому структура должна быть заточена под потребности и, что важно, возможности организации, а также под тех людей, которые есть в наличии.
Например, в футболе хороший тренер выбирает схему расстановки не ту, что используют все остальные, а ту, что максимально раскрывает возможности (или минимизирует недостатки) конкретных игроков. Тут должен главенствовать тот же принцип. В какой-то компании вы никогда не сможете собрать самостоятельную, реализующую продукт команду из трех-девяти человек просто потому, что систем, в которых нужно делать доработки, чтобы продукт вышел на рынок, тоже девять. И тогда будет нужен собственный дизайн команды, который учтет особенности вашего ландшафта, пока вы его не поменяли в лучшую сторону.
Изменения ИТ-структуры – не самоцель, она должна меняться, если меняется организация
Следовательно, нужно перестроить структуру под организацию, либо, если меняется окружение (какие-то функции становятся избыточными), под окружение. Правда, возможна третья ситуация, когда ИТ повысило свои компетенции настолько, что избыточными становятся какие-то уровни управленческой иерархии, – в этом случае тоже желательна коррекция.
Как проектировать ИТ-структуру, зависит от компании, ее основного направления деятельности и от того, что для вас ИТ. Это просто сервис? Значимая часть ваших продуктов? Вообще основа всего бизнеса? Странно будет внедрять уже упомянутую модель «спотифай», если все, что вы хотите от ИТ, – это чтобы ваша 1С функционировала нормально.
Поэтому перед тем, как начинать трансформацию ИТ-структуры, ответьте себе: зачем она вообще нужна? Каких целей бизнес с ее помощью сможет вообще добиться? Если четкого ответа нет, то, возможно, стоит от трансформации вообще отказаться или перейти к следующему вопросу.
КАК ПРОВЕСТИ АУДИТ ИТ-СТРУКТУРЫ
Если изменения кажутся все-таки необходимыми, то стоит хотя бы проверить гипотезу и провести аудит ИТ-структуры. Редко в какой организации есть детальные схемы, описывающие реальную оргструктуру (с учетом, например, команд аутсорсинга/аутстаффинга). Поэтому метод стандартный – берется текущая «штатка», данные по аутсорсингу, а дальше на основе опросов разрисовывается реальная текущая оргструктура ИТ. К этому прикладывается схема ИТ-ландшафта. На основе интервью собирается видение текущей проблематики, связанной с имеющейся структурой ИТ и бизнеса. Поскольку структура живет не в вакууме, то на показатели накладывается производственный план, KPI и данные по загрузке подразделений.
Далее все это анализируется и ищутся аномалии (нехватка или наоборот избыток управленческого персонала или специалистов), отсутствие покрытия каких-либо важных функций, например DevOps, или наоборот, какие-то лишние оргструктурные единицы, которые непонятно чем занимаются.
Стоит отметить, что модель управления ИТ не может сильно отличаться от модели, принятой в организации в целом
Если у вас нет разделения на продукты с самостоятельными владельцами продуктов (PO), которые отвечают за P&L, в том числе в части ИТ-расходов, то странно будет пытаться внедрить продуктовую модель в ИТ.
ЧТО ТАКОЕ ГИБРИДНЫЙ ПОХОД И КАКИЕ У НЕГО ПЛЮСЫ
Для компаний, у которых ИТ – это значимая часть их товаров/услуг, но сами продукты/сервисы не являются полностью продуктами ИТ-сферы, наиболее интересны будут гибридные варианты. То есть, с одной стороны, вы организуете самостоятельные продуктовые команды в части не только разработки, но и поддержки этих продуктов по линии как ИТ, так и бизнес-персонала.
И эти команды занимаются развитием и обслуживанием перспективных, полностью цифровых продуктов либо решают определенные задачи, например, повышают уровень удовлетворенности клиентским сервисом. Но при этом, с другой стороны, значимая часть компании (операционка, бэк-офис, бухгалтерия и т. д.) сохраняет возможность работы с ИТ как с «коробкой»/сервисной функцией. Это позволяет максимизировать эффекты от гибких подходов и совместной работы бизнеса и ИТ там, где это реально необходимо.
При этом не придется раздувать бюджеты там, где такой потребности нет. Децентрализация увеличивает стоимость, централизация, наоборот, ее уменьшает, так как повышается процент полезного использования ресурсов в целом, плюс выше возможности прогнозирования/контроля/маневра ресурсами.
КАК УПРАВЛЯТЬ ИТ-СТРУКТУРОЙ ИЗ 800 ЧЕЛОВЕК
Для крупных структур важно, чтобы в ИТ сохранялись центры компетенций по системам и направлениям. В противном случае велик риск потери контроля и, что самое плохое, возможности ИТ-директора вмешаться и помочь продуктовой команде, если у той что-то идет сильно не так.
Эффект масштаба структуры может не только исчезнуть, но и сработать в минус, когда полностью независимые и неконтролируемые продуктовые команды будут создавать и наращивать проблемы как снежный ком. Особенно важно держать руку на пульсе при разработке собственных систем и внедрении open-source-решений.
При управлении крупным ИТ-подразделением в 100–700 человек важно понимать, что оно должно управляться, в первую очередь, правильно выстроенными процессами, системой контроля объективных метрик. Соответственно, задача руководителя – создать эти процессы и систему метрик. И, безусловно, подобрать людей, которые будут не только проводниками воли и исполнителями «генеральной линии партии», но и самостоятельными фигурами, способными привносить идеи и решения, о которых топ-менеджмент, возможно, и не догадается.
Но поскольку мы имеем дело с людьми, а не роботами, руководителю важно выстроить личные коммуникации и отношения не только с непосредственными подчиненными, но и с сотрудниками, находящимися значительно ниже по иерархии. Для этого обязательно следует проводить регулярные общие мероприятия, сессии обратной связи, замеры настроений.
В заключение хочется отметить, что измерить эффективность самой модели управления достаточно сложно. Это делается на основе той же метрики производительности (мы улучшили структуру, и через некоторое время наши показатели производительности поползли вверх) плюс косвенных признаков, например, опроса удовлетворенности руководителей и сотрудников не из ИТ.
Цифровая трансформация в не ИТ-компании будет тем более успешной, чем лучше спроектирована ИТ-структура, являющаяся основным инструментом такой трансформации, что, в свою очередь, требует от CEO и большинства руководителей компании четких и продуманных ответов, зачем на самом деле им этот инструмент.
