Технологическая новизна проекта: как компании оценить ее до подачи документов

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

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

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

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

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

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

Первое затруднение связано с самим словом «новизна».

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

Это разные значения.

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

Недостаточно утверждать:

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

Каждое такое утверждение вызывает следующий вопрос: за счет чего именно?

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

Новизна продукта и новизна технологии — не всегда одно и то же

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

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

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

Итог: фраза «мы сделали новый продукт» еще не отвечает на вопрос о технологической новизне.

Чем новая технология отличается от улучшения существующего решения

Граница не всегда очевидна.

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

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

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

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

Задайте разработчикам один вопрос

Полезный внутренний тест звучит так:

«Что именно пришлось разработать нам самим, чтобы получить этот результат?»

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

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

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

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

До подготовки документов полезно разобрать проект как техническую систему.

Начать можно с шести вопросов.

1. Какую проблему решает технология?

Не «что делает продукт», а какую техническую или прикладную проблему невозможно было удовлетворительно решить прежним способом.

2. Как работает решение?

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

3. Что разработано самой компанией?

Следует отделить собственную разработку от:

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

Использование сторонних компонентов нормально. Но описание должно позволять понять роль именно собственной разработки.

4. Какой результат дает технология?

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

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

5. Почему результат достигается?

Это один из центральных вопросов.

Необходимо связать:

техническое решение → изменение характеристики → практический результат.

Именно причинно-следственная связь делает описание убедительным и понятным.

6. С чем корректно сравнивать решение?

Без этого оценивать новизну практически невозможно.

Технология существует не в вакууме. Поэтому следующим этапом становится анализ аналогов.

Почему важно изучить существующие аналоги

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

На практике оно сразу вызывает вопросы.

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

Поэтому задача компании — не доказать отсутствие всего похожего, а провести содержательное сравнение.

Что искать

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

Полезно рассматривать:

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

В результате должна сформироваться карта существующих подходов.

Аналог — не обязательно конкурент

Это важное различие.

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

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

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

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

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

Например:

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

Это особенно важно для B2B-технологий, где значительная часть технических характеристик конкурентов может быть закрыта.

Как описывать отличия собственного решения

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

Инженеры понимают разработку, но в документах она превращается в формулировки вроде:

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

Информации здесь практически нет. Сильное описание строится иначе.

Используйте конструкцию «что — за счет чего — результат»

Например, логика может выглядеть следующим образом:

Что изменено: используется иной способ выполнения определенной операции.

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

Что это меняет: появляется конкретное техническое свойство.

Какой результат: свойство позволяет получить измеримый или функционально подтверждаемый эффект.

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

Избегайте оценочных прилагательных

Слова:

• уникальный;
• революционный;
• беспрецедентный;
• лучший;
• передовой;

не заменяют доказательств.

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

Итог: чем конкретнее техническое отличие, тем меньше текст нуждается в эпитетах.

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

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

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

Например:

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

Главный принцип простой: заявление и подтверждение не должны существовать отдельно друг от друга.

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

Сделайте матрицу доказательств

Еще до подготовки основного комплекта документов можно составить простую таблицу:

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

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

Почему техническое описание должны проверять не только разработчики

Есть две противоположные проблемы.

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

Вторую — документы, написанные только инженерами. Они могут быть технически точными, но настолько сложными, что человеку вне команды трудно увидеть главную логику проекта.

Поэтому хороший внутренний процесс предполагает несколько уровней проверки:

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

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

Типичные ошибки при описании технологической новизны

Ошибка №1. «У нас нет аналогов»

Без проведенного поиска такое утверждение уязвимо.

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

Ошибка №2. Описание преимуществ вместо технологии

«Удобнее», «быстрее», «дешевле», «эффективнее» — это результаты или оценочные характеристики.

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

Ошибка №3. Перегрузка профессиональной терминологией

Сложность текста не доказывает сложность технологии.

Термины нужны там, где без них теряется точность. В остальных случаях лучше использовать простое объяснение.

Ошибка №4. Подмена собственной разработки набором известных технологий

Перечень вроде «AI + Big Data + облачные технологии» не объясняет технологическую сущность проекта.

Нужно показать, что именно делает сама компания.

Ошибка №5. Сравнение только с одним удобным конкурентом

Так можно получить искаженную картину.

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

Ошибка №6. Неподтвержденные цифры

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

Иначе лучше не использовать цифру.

Ошибка №7. Противоречия между разделами

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

Такие расхождения затрудняют понимание проекта.

Чек-лист предварительной оценки инновационного проекта

Перед дальнейшей подготовкой проекта руководитель вместе с технической командой может пройти следующую проверку.

Технологическая сущность

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

Новизна

• Определено, что именно считается новым?
• Новизна описана техническими характеристиками, а не рекламными словами?
• Понятно, за счет какого решения возникают отличия?
• Не смешиваются новизна продукта и новизна технологии?

Аналоги

• Проведен поиск существующих решений?
• Рассмотрены не только прямые коммерческие конкуренты?
• Определены критерии сравнения?
• Источники информации можно проверить?
• В таблице нет предположений, представленных как факты?

Результаты

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

Документы

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

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

Как провести предварительную оценку проекта за четыре шага

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

Шаг 1. Зафиксировать технологическую сущность. Описать проблему, принцип работы и собственную разработку.

Шаг 2. Найти релевантные аналоги. Посмотреть не только продукты конкурентов, но и альтернативные технические подходы.

Шаг 3. Построить сравнение. Выбрать объективные характеристики и показать реальные отличия.

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

Получается простая цепочка:

технология → аналоги → отличия → доказательства.

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

Что в итоге должна увидеть сама компания

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

После такого анализа у руководителя должны появиться четкие ответы:

• Что разработано?
• Как это работает?
• Какие аналоги существуют?
• В чем конкретно отличие?
• За счет чего возникает это отличие?
• Какими материалами подтверждаются заявленные характеристики?

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

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

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