Когда внутренние ИТ-решения становятся драйвером роста корпорации

Что считать внутренними ИТ-решениями

К внутренним ИТ-решениям относится весь софт, который обеспечивает операционную деятельность компании и поддерживает ключевые функции: финансы, HR, юридический блок, производство, риски, логистику и другие направления. Это может быть как бухгалтерский учет и документооборот, так и инструменты для рекрутеров, руководителей, операционных и продуктовых команд. Если обобщить, внутренние ИТ-решения — это всё, что позволяет компании «нормально функционировать» и выполнять свою операционную деятельность.

На практике такие системы появляются двумя путями. Первый — внедрение готовых продуктов: ERP, CRM, систем электронного документооборота, корпоративных мессенджеров и других платформ. Второй — разработка собственного решения под конкретные процессы бизнеса.

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

Экономика внутренних ИТ-решений: когда затраты работают на результат

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

В классической финансовой логике такой продукт выглядит как cost center. Но в корпоративной среде этого объяснения недостаточно. Внутренние платформы и сервисы могут давать измеримый экономический эффект даже без прямых продаж на внешний рынок. Он проявляется в трех плоскостях:

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

Все это — так называемые «вторичные эффекты». Они не формируют выручку напрямую, но влияют на экономику компании через снижение затрат, рисков и ускорение процессов.

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

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

Как внутренний софт превращается в инструмент роста

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

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

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

Мировые примеры вроде Amazon Web Services или алгоритмов рекомендаций Netflix хорошо иллюстрируют общий тренд: внутренний софт может становиться основой новых бизнесов. Однако аналогичные модели активно развиваются и в России.

Читайте также

Узбекистан как операционный хаб для ИТ-бизнеса. Чем он привлекателен

Перенос операционного офиса в другую страну - всегда стресс. Незнакомые правила, государственная и налоговая политики, страх потери контроля над командой и процессами. Релокация в Узбекистан снимает большую часть этих проблем. Что за этим стоит, и почему его уже выбрали порядка 1 тыс. ИТ-компаний?

Сбер: внутренняя платформа как продукт

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

Дополнительный пример — HR-платформа Pulse, изначально созданная для внутренних процессов найма. Со временем она стала полноценным продуктом, который используют и другие компании. 

Яндекс: инфраструктура, выросшая в облако

В Яндексе внутренняя инфраструктура для собственных сервисов — поиска, карт, рекламы, такси — постепенно трансформировалась в облачную платформу Yandex Cloud, доступную внешним клиентам.

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

Ozon: логистика как основа масштабирования

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

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

Как управлять внутренними ИТ-решениями и оценивать их вклад

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

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

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

Оценка таких решений строится не через прямую выручку, а через влияние на процессы, скорость разработки и затраты. На практике используются метрики, которые отражают, насколько внутренние инструменты влияют на работу команд и стоимость разработки. В первую очередь это скорость вывода изменений в прод (time-to-market), уровень использования решений командами (adoption), а также снижение стоимости разработки и стабильность работы систем.

Дополнительно может учитываться показатель cost-to-income ratio (CIR), который отражает соотношение расходов и доходов на уровне бизнеса. Если продукт выходит на внешний рынок, применяются стандартные финансовые показатели — выручка, расходы и прибыль.

Типичные ошибки и роль ИТ-лидера

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

На практике для оценки необходимости собственной разработки достаточно ответить на три вопроса:

Закрывает ли потребность внешнее решение? Важно провести полноценный анализ рынка, а не формальную проверку «на всякий случай»;

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

Читайте также

Цифровому сотруднику нужен начальник и кнопка выключения

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

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

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

Характерный пример — кейс EMEX. При работе с бухгалтерским учетом в ОАЭ от идеи переписывать свою устаревшую систему с нуля отказались. Вместо этого начали внедрение внешнего решения с кастомизацией и интеграцией. Это позволило снизить риски и получить масштабируемую модель без дополнительных затрат на разработку.

Еще один риск — переоценка собственной экспертизы, когда компания берется за разработку в непрофильной области, несмотря на наличие зрелых продуктов на рынке. Другая ошибка — попытка «во что бы то ни стало» сделать внутренний продукт внешним, хотя у него нет рыночного потенциала.

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

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

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