Центры компетенции: создавать или не создавать?

Когда проект по внедрению ИТ-системы завершен, перед компанией стоит выбор: как поддерживать и развивать систему в дальнейшем, самостоятельно или с помощью внешних консультантов (представителей вендора или интегратора)? Многие – из соображений экономии, автономности и др. выбирают первый путь – создают внутренние Центры компетенции (ЦК). Всегда ли оправдано подобное решение? В каких случаях создание ЦК целесообразно, а в каких нет, − рассуждает Глеб Давыдов, директор по развитию бизнеса, Jume.

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

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

Но технологии идут вперед, современные решения используют алгоритмы машинного обучения, математические оптимайзеры и другие передовые интеллектуальные технологии, и при этом далеко не все современные платформы выбирают принцип low-code. Поэтому вопрос быть или не быть Центру компетенций снова выходит на первый план. Так в каких случаях ЦК необходим, а в каких нет?

Помогите, система не "тянет"!

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

Очевидно, что прежде, чем заниматься архитектурой, нужно разобраться в причине проблем и выяснить, почему платформа не работает так, как нужно.

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

Ситуация №2: Платформа тормозит, поскольку до отказа забита неиспользуемыми отчетами. Вся команда ЦК занимается исключительно отчетностью и составлением разнообразных графиков, для производства которых должна использоваться BI-система. Возможности платформы, на которую затрачены десятки миллионов рублей (не считая затрат на сотрудников ЦК), по факту, используются не более, чем на 30%. Ни одного нового бизнес-модуля, как изначально планировалось, ЦК не запустил.

Ситуация№3: Специалисты ЦК все-таки рискнули сделать новый модуль самостоятельно, но его архитектура не "дружит" с исходной и не позволяет масштабировать решение на новые филиалы, производственные площадки и т. д.

Как ситуация выглядит глазами руководителя?

С одной стороны, у него есть команда экспертов, которые:

1. прошли обучение у вендора,
2. получают немалые деньги,
3. отвечают за работу системы и ее развитие.

С другой стороны, жалобы от пользователей на то, что они не могут нормально работать в системе и вынуждены оставаться на ночную смену, чтобы сделать часть своих задач, пока все дома и платформа "отдыхает". Никакого развития платформы при этом не происходит. Руководителю сложно понять, кто виноват и в чем причина проблем, – в плохой работе ЦК или в несовершенстве технологий. В итоге он зовет внешних консультантов, чтобы все починить.

ЦК: иллюзии и реальность

Иллюзия №1: запускать новые кейсы и развивать решение можно малыми силами.

2–3 архитектора, которые прошли обучение у вендора, − фактор необходимый, но не достаточный для полноценного развития системы. Умение работать с системой – как изучение иностранного языка: можно закончить курсы, сдать экзамены, но, чтобы говорить как носитель, теории недостаточно. Нужно пожить в иноязычной среде, погрузиться в язык, постоянно обновлять его новыми фразеологизмами и т. д. Чтобы быть хорошим системным архитектором, нужно быть в сообществе вендора, изучать способы решения тех или иных задач, советоваться с известными экспертами, изучать реализованные проекты, то есть заниматься саморазвитием и регулярным пополнением знаний.

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

В итоге компания развивается, ЦК масштабирует модель на новые филиалы, система тормозит из-за неправильной конфигурации.

Иллюзия №2: сотрудники могут совмещать свои ежедневные обязанности с работой в ЦК

Логика руководства выглядит примерно так: "У специалистов центра компетенций не так много ежедневных задач, а стоят они дорого, поэтому пусть в свободное от основной работы время занимаются развитием платформы". В большинстве случаев у сотрудников ЦК есть и другие задачи. Или, наоборот: функции поддержки и развития платформы передают профильным специалистам в "нагрузку". "Чем там у нас специалисты по планированию занимаются? Планированием спроса? Отлично, пусть заодно и платформу поддерживают и развивают". И вот этот подход совершенно не работает.

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

Для эффективной работы ЦК его сотрудники должны работать на платформу 100% своего времени, а руководители − воспринимать вложения в ЦК не как дополнительные затраты, в как инвестиции в будущее организации.

Иллюзия №3: ЦК позволяет экономить бюджет на развитие платформы

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

Чтобы оправдывать собственное существование, центры компетенции часто сами придумывают себе задачи. Они превращаются в конвейер и производят все новые и новые графики, засоряя систему, вместо того чтобы анализировать и фильтровать запросы, объясняя пользователям нецелесообразность тех или иных действий.

Бывает ли так, что Центры Компетенции на 100% оправдывают свое существование?

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

Наличие ЦК оправдано также в крупных технологических корпорациях, где есть внутренняя высокоуровневая ИТ экспертиза. Эти компании очень хорошо понимают важность инвестиций в развитие ИТ-решений и умеют поддерживать и развивать их своими руками.

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

А как быть остальным?

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

Разумный вариант – использовать платформу интегрированного планирования по назначению для построения и согласования прогнозов, бюджетов, ресурсов, решения оптимизационных задач производства, логистики, промо планирования и др., а более простые задачи, как, например, отчетность с углублением в данные (drill down), можно решать с помощью недорогих или даже бесплатных инструментов (как MS Power BI, Qlik Sense). Отчетность часто меняется, и переделывание сложных систем под эти изменения не оправдывают себя. При таком подходе администрирование системы и выполнение каких-то несложных функций остаются на стороне клиента, а запуском новых кейсов занимается внешний консультант.

Центры компетенции и искусственный интеллект

По мере развития нового поколения платформ, в основе которых лежит искусственный интеллект (AL/ML), вопрос о целесообразности создания ЦК приобретает особую остроту. Чтобы поддерживать сложные технологические решения и работать автономно, внутренний специалист должен знать не только саму платформу, но и смежные дисциплины, такие как языки программирования для машинного обучения и оптимизаторов, как минимум, Pyton. Это довольно сложно. Если, например, на производстве добавилась новая линия и нужно настроить дополнительный дашборд для ввода данных в модуле "производство", то с этой задачей специалист ЦК, скорее всего, справится самостоятельно, но внести коррективы в математический оптимайзер, без внедрения которого нет смысла запускать платформу, уже не сможет. А значит ему все равно придется обращаться к внешним экспертам, и 100%-й автономии все равно не получится.