Системное «куда»Давление всей этой груды факторов привело к тому, что в последние годы корпоративные инновационные экосистемы заметно эволюционировали, пытаясь худо-бедно соответствовать структуре момента. И, конечно, ожиданию № 1 от технологической политики и технологий — заметному улучшению продуктов/сервисов, как существующих, так и новых.
Именно поэтому многие изменения в корпоративных экосистемах лежат в русле продуктового перехода — перенастройки бизнес-процессов с тем, чтобы радикально оптимизировать процесс продуктовых разработок, начиная с генерации идей и заканчивая управлением жизненным циклом продуктов.
Все это имеет несколько последствий.
Первое — изменение процесса принятия решений о приобретении/разработке технологии (в любом виде: IP, стартап, продукт, внутренняя разработка и пр.): решение — в рамках имеющихся бюджетов — принимают разработчики продуктов / продакт-девелоперы, а не СЕО, не профильные директора и не инженеры. И разработчики же оценивают, насколько технология готова для интеграции в конечный продукт — в тех случаях, когда речь идет о сверхсложных и сверхтехнологичных продуктах, класса ракетного двигателя, например.
Под этим внешне простым подходом, как в LLM, лежит много слоев организационных особенностей и/или практик продуктовых разработок:
1. Системная интеграция продукта (и технологий внутри этого продукта), или, формально выражаясь, инженерная интеграция систем и тестирование (systems engineering integration and test, SEI&T) как базовый процесс продуктовых разработок:
- на уровне команд: в крупных высокотехнологичных компаниях в продуктовые команды включены специальные «инженеры-интеграторы» или работают отдельные команды, отвечающие за системную адекватность всего, что инженеры, дизайнеры, исследователи и венчуристы пытаются протащить в продукт. Вплоть до того, что на SEI&T приходится до трети всего «продуктового бюджета» (как, например, в Boeing и Lockheed Martin);
- на уровне программного обеспечения: включение требований к SEI&T и контролю уровня готовности технологий в CAD/CAE, буквально на уровне мануалов/теймплейтов для инженеров. Последствий у CAD/CAE-интеграции много (нормальное кросс-функциональное взаимодействие разработчиков, возможность виртуального тестирования, интеграция онтологий и таксономий), но основное — это возможность оценивать адекватность технологии для получения нужных ТТХ продукта на выходе.
2. Система управления «продуктовыми» данными как технологическая база для продуктовых разработок:
- массивы неструктурированных данных об использовании продуктов и их поведении/характеристиках (CRM; обращения пользователей в техподдержку; данные дилеров; данные встроенных датчиков/IoT; данные белой разведки о продуктах конкурентов; парсинг социальных сетей в части отзывов и пр.) + автоматизированные системы анализа (в том числе в рамках подхода Agile Manufacturing Value and Control Management, как это делается, например, в Haier);
- производственные данные (промышленный Интернет вещей, автоматизированное производство + CAD/CAE, ERP, BIM и пр.), в том числе для анализа/моделирования потенциально необходимых производственных процессов, расчетов себестоимости и пр.;
- система управления требованиями к продуктам, получающая «входные» данные от пользователей и производства; как правило, трехступенчатая: дизайн/интерфейс (market pull); технические решения/возможности (tech push); фулфиллмент (экономика, управление потребителями и пр.).
Второе последствие адаптации инновационных экосистем к «продуктовому переходу» — это своеобразное «разделение труда» в части того, в каких околопродуктовых сферах компании обязательно должны иметь компетенции и технологии ин-хаус, а что можно заимствовать извне и/или отдавать на условный аутсорсинг (стартапам нравится, пусть летают).
Как правило, все, что связано с разработкой новых продуктов (R&D, инжиниринг, дизайн, системная интеграция, технологическое/IP-ядро и пр.), компании делают ин-хаус. Причин этому много, но основные — это: а) вопрос конкуренции, коммерческой тайны и уникальных проприетарных данных, используемых в продуктовых разработках (в том числе данные о потребителях), б) низкое качество того, что предлагает условный рынок (вендоры, стартапы, партнеры из академии и пр.), причем низкое настолько, что компаниям проще и эффективнее разработать технологию/продукт самостоятельно, чем допиливать чужие решения.
Основной мотив использования внешних технологий в разных организационных вариациях — дороговизна внутренней разработки. Самый показательный пример в этом плане — это все, что связано с цифровыми компонентами и аспектами продуктов: как показывают опросы, две трети компаний в условно-развитых странах в ближайшие годы планируют отдавать на аутсорсинг технологические модули в части кибербезопасности, промышленного Интернета вещей (сенсоры, датчики, системы обработки данных и пр.), использования облачных инфраструктур, а также ИИ.
Третье последствие продуктового перехода для корпоративных инновационных экосистем — изменение форматов работы компаний со стартапами:
1. Заметный дрейф от классических корпоративных венчурных фондов к строительству стартапов с нуля (venture building, в том числе в формате стартап-студий).
(Справедливости ради: стартапостроительством компании начали заниматься не столько из-за продуктового перехода, сколько из-за ухудшения экономической/финансовой ситуации и понятного желания повысить качество стартапов и отдачу от инвестиций.
Кроме того, корпоративные венчурные фонды, при прочих равных, проигрывают в привлекательности обычному венчуру: приличные стартапы имеют возможность выбирать, у кого брать деньги. И корпорации как инвесторы зачастую интересны стартапам не столько как источники финансирования, сколько как способ получить доступ к рынку, потребителям и/или бренду).
2. Дрейф корпоративных венчурных инвестиций в сторону (до)посевной стадии, по двум мало связанным между собой причинам. Первая — чем дальше, тем у корпоративных фондов хуже с ресурсами (бюджеты не резиновые) и с требованиями к стартапам, а посевные инвестиции во многих смыслах безопаснее более поздних раундов — денежные и репутационные потери, в случае чего, будут не такими большими.