Когда обычная IT-компания становится технологической компанией

Компания разрабатывает программное обеспечение. Значит ли это, что она технологическая? Не обязательно.

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

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

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

Разберемся, где искать эту границу и какие вопросы стоит задать себе перед следующим этапом развития проекта.

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

Почему IT и технологическая компания — не одно и то же

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

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

Представим компанию, которая внедряет существующую CRM, настраивает ее под процессы заказчика и интегрирует с другими сервисами. Для выполнения проекта нужны программисты, архитекторы и другие IT-специалисты. Однако основой решения остается уже существующая технология.

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

Различие можно выразить просто: использовать технологию ≠ разрабатывать технологию.

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

Итог: принадлежность бизнеса к IT-сектору сама по себе еще не объясняет, где находится собственная технология компании.

Какую роль играет собственная разработка

Собственная разработка — один из центральных элементов анализа, но и здесь есть ловушка. 

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

Поэтому вопрос лучше сформулировать иначе: Какую техническую проблему компании пришлось решить собственным способом, потому что существующие подходы ее не решали или имели значимые для проекта ограничения?

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

Именно ее затем необходимо анализировать подробнее.

Что стоит отделить друг от друга

У цифрового продукта условно можно выделить несколько слоев:

Что меняется, если компания создает новую технологию

Сам характер работы

Обычная разработка продукта в значительной степени отвечает на вопрос: «Как реализовать необходимую функциональность?» Создание новой технологии добавляет еще один: «Как решить техническую задачу, для которой существующего подхода недостаточно?»

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

Меняется и документация

Когда продукт строится вокруг собственной технологии, постепенно возникает потребность фиксировать:

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

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

Меняется логика развития

У обычного программного продукта развитие может быть преимущественно продуктовым: новая функция → тестирование → выпуск.

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

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

Где проходит граница между интеграцией и разработкой

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

Это нормальная инженерная практика. Поэтому использование сторонних технологий не исключает собственной разработки.

Вопрос заключается в другом: что компания делает поверх них?

Пример логики интеграции

Компания берет несколько готовых сервисов: сервис A + API B + платформа C → единый интерфейс для пользователя.

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

Пример логики разработки

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

В этом случае предмет анализа уже другой.

Пять вопросов для проверки

1. Что останется от продукта, если мысленно убрать все сторонние сервисы и библиотеки?

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

3. Какие технические решения разработала команда?

4. Почему понадобилась эта разработка?

5. Какой результат она дает?

Если на эти вопросы есть конкретные ответы, технологическую составляющую становится значительно проще выделить.

А если компания использует искусственный интеллект?

Это особенно актуальный пример.

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

Нужно выяснить:

• какую задачу решает AI-компонент;
• используется готовое решение или собственная разработка;
• как оно встроено в архитектуру продукта;
• какие собственные методы применяются;
• есть ли технические отличия от известных подходов;
• за счет чего достигается необходимый результат.

Сравним: «Мы используем искусственный интеллект для анализа документов» и «Компания разработала метод X для решения задачи Y; он выполняет операции A, B и C, после чего формируется результат Z».

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

Как оценить технологическую составляющую продукта

Для предварительного анализа необязательно сразу готовить большой документ. Можно провести внутренний технологический аудит.

Шаг 1. Опишите продукт одним абзацем. Что он делает и для кого? Без слов «инновационный», «уникальный», «передовой» и «революционный». Если без этих характеристик ценность продукта становится непонятной, описание нужно уточнить.

Шаг 2. Нарисуйте архитектуру. Необязательно создавать сложную инженерную схему. Достаточно показать основные компоненты: входные данные → обработка → собственные модули → внешние компоненты → результат.

Шаг 3. Отметьте сторонние компоненты. Какие части компания: покупает, лицензирует, получает через API, использует как open-source, берет в виде стандартных библиотек или платформ?

Шаг 4. Выделите собственную разработку. Теперь на схеме останутся элементы, созданные самой командой. Для каждого задайте вопрос: Что здесь технически отличается от уже существующих способов решения задачи?

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

Шаг 6. Опишите причинно-следственную связь. Для каждого существенного отличия: что изменили → как работает → какой технический результат получили → чем подтверждаем. Так формируется основа для более глубокой оценки инновационного проекта.

Какие признаки характеризуют технологический бизнес

Не существует одного признака, после появления которого обычная IT компания мгновенно превращается в технологическую.

Корректнее оценивать совокупность характеристик.

1. Компания решает собственные технические задачи

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

2. Есть собственная технологическая составляющая

Можно конкретно показать, что разработано компанией.

Не «платформа целиком», а определенные методы, алгоритмы, архитектурные или иные технические решения.

3. Проводится проверка гипотез

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

4. Характеристики измеряются

Технологический результат желательно уметь выразить через релевантные показатели.

Какие именно — зависит от проекта.

5. Изучаются аналоги

Компания понимает, какие технические решения уже существуют и чем собственный подход от них отличается.

6. Накапливается техническая документация

Знания о технологии существуют не только в головах основателей и ведущих разработчиков.

7. Технология влияет на конкурентоспособность

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

IT-компания и технологическая компания: сравнение

Упрощенная таблица помогает увидеть разницу, но ее нельзя воспринимать как юридическую классификацию.

Здесь принципиально важно не обесценивать первый столбец. Компания может построить крупный, прибыльный и востребованный инновационный бизнес, используя преимущественно существующие технологии. Наличие собственной технологии — не оценка качества бизнеса. Это характеристика природы проекта.

Когда SaaS-проект можно рассматривать как технологический

Для SaaS эта граница особенно размыта. Почти любой облачный сервис содержит большой объем собственной разработки. Но большая кодовая база сама по себе еще не отвечает на вопрос о технологической составляющей.

Полезно разделить три уровня.

Уровень 1 — интерфейс и бизнес-логика. Система позволяет пользователю выполнять необходимые операции.

Уровень 2 — собственная программная архитектура. Компания самостоятельно организует взаимодействие компонентов и обработку информации.

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

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

Что технологический статус меняет для самой компании

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

По мере развития технологической компании возрастает значение:

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

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

Что проверить перед дальнейшим развитием проекта

Руководителю полезно провести короткую диагностику.

О продукте

• Понятно, какую проблему решает продукт?
• Есть конкретная целевая аудитория?
• Можно объяснить ценность без общих маркетинговых фраз?

О технологии

• Можно выделить собственную разработку?
• Понятен принцип ее работы?
• Известно, зачем она понадобилась?
• Можно объяснить технический результат?

Об аналогах

• Известны альтернативные способы решения задачи?
• Компания изучала не только коммерческих конкурентов?
• Технические отличия сформулированы конкретно?
• Для сравнений используются проверяемые данные?

О доказательствах

• Есть результаты испытаний или иных проверок, если они проводились?
• Сохраняются исходные данные?
• Заявленные характеристики можно подтвердить?
• Достигнутые показатели отделены от планируемых?

О команде

• Технологию понимает не один разработчик?
• Ключевые знания документируются?
• Ответственность за развитие основных компонентов определена?

О стратегии

• Понятно, какую роль технология играет в бизнес-модели?
• Есть план дальнейшего развития?
• Компания понимает, какие технические задачи предстоит решить следующими?

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

Когда стоит задуматься о статусе участника «Сколково»

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

Если компания рассматривает резидентство Сколково, не стоит начинать с попытки переписать обычное описание IT-продукта более «инновационным» языком. Сильнее работает обратный подход: найти реальную технологическую сущность проекта и описать ее без преувеличений.

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

Так компания оценивает не красивую формулировку, а фактическую готовность проекта.

Частые ошибки при оценке своего проекта

• «Мы IT-компания, значит, мы технологическая компания» Слишком широкое обобщение. Нужно анализировать конкретный продукт и характер собственной разработки.
• «У нас весь код собственный» Это важная характеристика проекта, но она не доказывает технологическую новизну автоматически.
• «Мы используем AI, поэтому продукт инновационный» Использование современной технологии и ее создание — разные вещи.
• «Мы интегрировали пять систем — это новая технология» Интеграция может требовать серьезной инженерной работы. Но необходимо отдельно показать собственное техническое решение, если компания заявляет его наличие.
• «Наш продукт быстрее конкурентов» Нужно определить критерий, метод сравнения и техническую причину результата.
• «Аналогов не существует» Такое утверждение требует особенно тщательной проверки. Часто прямого конкурента действительно нет, но существуют альтернативные технологии, решающие ту же задачу.

Главное различие — не в названии компании

Между обычной IT-разработкой и технологическим бизнесом нет условной кнопки, после нажатия которой компания переходит в новую категорию. Граница проходит внутри самого проекта.

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

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

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