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

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

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

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

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

Поэтому инновационное направление бизнеса в определенный момент полезно выделить хотя бы на уровне управления — даже если для этого не создается отдельная организация.

Разберем, как провести такую границу без искусственной бюрократии и не оторвать разработку от ресурсов основного бизнеса.

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

Когда инновационное направление начинает мешать основной операционной деятельности

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

Какую задачу он выберет? Чаще всего операционную. У нее есть конкретный заказчик, обязательства и понятный срок. Инновационная задача может подождать. Завтра ситуация повторяется. Затем еще раз. В результате проект формально существует, но фактически развивается только тогда, когда у основной команды появляется свободное время.

Конфликт возникает не из-за сотрудников

Причина глубже: у двух направлений разные горизонты планирования.

Операционный бизнес отвечает на вопрос: «Что необходимо выполнить сейчас, чтобы действующая модель продолжала работать?»

Инновационный проект: «Что необходимо разработать и проверить, чтобы появилась новая модель в будущем?»

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

Признаки, что границу уже пора обозначить

Стоит обратить внимание, если:

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

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

Нужно ли создавать отдельную проектную команду

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

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

Когда выделенная команда особенно полезна

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

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

Три возможные модели

Универсально лучшей модели нет. Организационная структура должна соответствовать реальной стадии проекта.

Как распределить ответственность

Одна из самых опасных конструкций выглядит так: «За инновации отвечает вся компания». На практике это нередко означает, что персонально не отвечает никто.

У проекта должен быть человек, который видит его целиком и способен ответить:

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

При этом ответственность полезно распределить и внутри проекта.

Например:

Один человек может отвечать сразу за несколько зон. Для небольшой команды это нормально. Проблема возникает, когда ответственного нельзя назвать вообще.

Кто должен разрешать конфликт двух направлений

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

Для нормального управления инновациями правила эскалации таких ситуаций не менее важны, чем сама структура команды.

Как организовать бюджетирование проекта

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

Разработка может использовать:

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

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

Речь прежде всего о возможности ответить на вопросы:

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

Бюджет лучше связывать с этапами

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

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

Какие процессы можно оставить общими

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

Например, в зависимости от устройства бизнеса общими могут оставаться:

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

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

Используйте простой критерий

Для каждого общего процесса задайте два вопроса.

Первый: дает ли использование существующей корпоративной функции проекту экономию ресурсов или необходимые компетенции?

Второй: создает ли эта функция задержки, которые мешают разработке?

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

Что точно не нужно копировать автоматически

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

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

Как разделить операционные и инновационные KPI

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

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

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

Что оценивать вместо абстрактной инновационности

На ранних стадиях полезно смотреть на достижение конкретных результатов этапа.

Например:

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

Здесь принципиально важен последний пункт.

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

KPI должны меняться вместе со стадией

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

Как сохранить связь инновационного проекта с основным бизнесом

Полная изоляция тоже опасна.

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

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

Инновационной команде могут быть нужны:

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

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

Какие ошибки возникают при создании внутреннего технологического направления

Ошибка №1. Разработка «в свободное время»

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

Ошибка №2. Назначить руководителя без полномочий

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

Ошибка №3. Сразу построить отдельную бюрократию

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

Ошибка №4. Оценивать проект только по продажам

На ранней стадии это может стимулировать преждевременный выход на рынок.

Ошибка №5. Вообще не требовать измеримых результатов

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

Ошибка №6. Полностью изолировать команду

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

Ошибка №7. Не разделять бюджеты

Руководство не понимает реальную стоимость проекта и не может объективно оценить потребность в дальнейших ресурсах.

Ошибка №8. Переносить операционную культуру без изменений

Если эксперимент должен пройти пять уровней согласования, скорость проверки гипотез резко снижается.

Когда проекту действительно нужна организационная самостоятельность

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

Признак 1. Другая команда

Разработке нужны компетенции, которых практически нет в основном бизнесе.

Признак 2. Другой цикл работы

Основной бизнес планирует понятные операции, а проект работает короткими циклами проверки гипотез.

Признак 3. Другие критерии результата

Для основного направления важен текущий финансовый результат, для проекта — достижение определенной стадии технологической или продуктовой готовности.

Признак 4. Возникают постоянные конфликты ресурсов

Общая структура уже не позволяет эффективно распределять специалистов и бюджет.

Признак 5. Формируется самостоятельный продукт

У проекта появляется собственная целевая аудитория, продуктовая стратегия и план развития.

Признак 6. Масштаб управления вырос

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

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

При этом степень самостоятельности может быть разной: отдельный проект → проектный офис/команда → бизнес-направление → более самостоятельная организационная модель. Необязательно перепрыгивать сразу на последний уровень.

Чек-лист: пора ли выделять инновационное направление

Ответьте «да» или «нет».

Команда

• У проекта сформировалось постоянное ядро специалистов?
• Разработка занимает существенную часть их рабочего времени?
• Операционные задачи регулярно мешают проекту?

Управление

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

Бюджет

• Можно определить фактические расходы проекта?
• Понятна потребность в ресурсах на следующий этап?
• Бюджет связан с задачами разработки?

Результаты

• Определены цели текущего этапа?
• Они отличаются от KPI основного бизнеса?
• Результаты можно проверить?
• После каждого этапа принимается решение о дальнейшем движении?

Взаимодействие

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

Нужна ли отдельная компания

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

Проект может иметь:

• отдельную команду;
• руководителя;
• бюджет;
• KPI;
• план разработки;
• собственный продуктовый контур;

и при этом оставаться внутри существующей компании.

Решение о юридической структуре зависит от значительно большего числа факторов и требует анализа конкретной ситуации. Автоматического правила «появилась технология — создавайте новую компанию» нет.

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

Как выстроить разделение поэтапно

Резкая реорганизация обычно не нужна.

Можно двигаться постепенно.

Так организационная самостоятельность растет вместе с самим проектом.

Как это связано с дальнейшим развитием технологического проекта

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

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

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

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

Не отделяйте инновации от бизнеса — отделите правила управления

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

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

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

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

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