Правильно трансформировать ИТ-бизнес: реальный опыт

Автор: Раиль Фатхутдинов, коммерческий директор ГК «Умные решения»

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

Когда бизнес-модель перестает работать

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

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

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

Именно тогда мы начали перестраивать компанию из торговой модели, в компанию с фокусом на системную интеграцию.

Риски трансформации

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

На практике это довольно быстро приводит к нескольким проблемам.

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

• Во-вторых, появляется риск взять проект, к которому бизнес еще не готов. На старте трансформации особенно опасно переоценить собственные ресурсы. Сложный инфраструктурный проект требует не только сильных инженеров, но и зрелого проектного офиса, понятной методологии и слаженной работы всех подразделений.

• Третья проблема – сопротивление внутри команды. Любая трансформация ломает привычную модель работы, а люди почти всегда болезненно реагируют на изменения.

От коротких сделок к длинным проектам

Между тем, на практике сказать самим себе и объявить миру: «Мы больше не боксмуверы!» оказалось намного проще, чем реально стать интегратором. Снаружи мы уже говорили про комплексные проекты и экспертизу, а внутри компания во многом продолжала жить по логике торгового бизнеса. Это стало особенно заметно, когда начали появляться первые действительно сложные внедрения.

Главная проблема была в ресурсах и процессах. Мы увидели, что инженерная команда просто не успевает за тем объемом обязательств, который начинает брать на себя бизнес. Одновременно возникло сопротивление внутри коммерческого блока. Для многих менеджеров разница между «отгрузить лицензию» и несколько месяцев вести инфраструктурный проект оказалась намного более серьезной, чем казалась на старте трансформации.

Мы на практике ощутили, что старая внутренняя архитектура компании под новую модель уже не подходит. Вскрылись проблемы, которые в классической торговой модели долгое время оставались незаметными:

• выяснилось, что компании не хватает культуры проектного управления;

• техническая документация, без которой невозможно масштабировать внедрения, создавалась тяжело и медленно;

• старые бизнес-процессы резко потеряли актуальность, потому что были рассчитаны на короткие сделки, а не на длинные инфраструктурные проекты;

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

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

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

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

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

Команда провела аудит промышленной сети, тестирование инфраструктуры и внедрение решения одного из лидеров ИБ-отрасли. Проект потребовал не только интеграции ИБ-решения, но и глубокого понимания промышленной автоматизации, особенностей АСУ ТП и влияния изменений на стабильность производства. Дополнительно для специалистов предприятия были проведены профильные тренинги по промышленной кибербезопасности.

Похожую роль для нас сыграли и другие проекты – например, по аудиту сетевой инфраструктуры. На первый взгляд аудит выглядит менее «заметной» услугой, чем внедрение крупной системы ИБ. Но именно такие проекты во многом заставили компанию перейти от логики продаж к логике глубокой инженерной экспертизы. Чтобы проводить полноценный аудит, специалисту уже недостаточно знать характеристики оборудования или отдельного продукта. Необходимо понимать архитектуру сети, принципы сегментации, требования регуляторов, особенности интеграции разных решений и реальные эксплуатационные риски.

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

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

Почему продавать экспертизу выгоднее, чем оборудование

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

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

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

Для нас это стало важным внутренним переломом. Когда компания просто продает «коробки», она далеко не всегда понимает, как продукт встроится в ИТ-периметр.

Но когда появляется инженерная экспертиза и опыт внедрений, возникает возможность смотреть на работу иначе. Например, когда заказчик приходит за конкретным продуктом, а мы после аудита инфраструктуры говорим ему: «Мы вам это решение продавать не будем!». Для классической торговой модели это звучит почти абсурдно.

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

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

Что в итоге стало главным активом компании

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

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

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

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

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