Почему большинство программ вовлечения для получения идей проваливаются — и что объединяет те, которые работают
Как выглядит провальный запуск программы по сбору идей:
Кто-то загорается идеей «вовлечь участников в инновационное развитие». Находится бюджет, выбирается платформа, и объявляется открытый (и неструктурированный) сбор идей. Идеи просто льются потоком. Но внутри компании никто не обладает ни полномочиями, ни ресурсами, чтобы что-то с ними сделать. Участники, вместо обратной связи, получают тишину. Активность падает. Программа постепенно теряет приоритет. В итоге кто-то просто записывает кейс «чему мы научились», который почти никто не читает.
Одна из главных проблем — участников рассматривают как источник бесплатного труда. И компании не хотят инвестировать в отношения и инфраструктуру, которые делают продуктивное сотрудничество возможным.
В этой статье предлагаем фреймворк, который позволяет либо создавать результативные программы, либо диагностировать, почему существующие программы не работают.
Небольшое уточнение по терминологии. В этом тексте будет использован термин «инфраструктура совместных инноваций» (collaborative innovation infrastructure) вместо слова «сообщество». Не потому, что слово «сообщество» плохое, а потому что оно стало слишком размытым из-за отсутствия контекста и общего смысла*.
Открытый портал идей — это не то же самое, что ядро клиентов. Ядро клиентов — не то же самое, что экосистема разработчиков. Экосистема разработчиков — не то же самое, что шестинедельная стратегическая программа для топ-менеджеров, которые изучают водородную энергетику. Когда все это называют «сообщество», люди начинают воспринимать это всего лишь в качестве «дополнительной активности для вовлечения клиентов».**
*примечание от Лаборатории: тут заметно, что форма остается одним — сообщество как группа людей со связями между собой, в то время содержание меняется. Автор описывает ее ниже. Подробнее про форму и содержание сообщества в статье.
**примечание от Лаборатории: не видим ничего плохого использовании сообщества как дополнительно активности для вовлечения клиентов. Всё зависит от контекста. Сообщество может быть как и основным инструментом работы, так и дополнительной ценностью. Возможно, тут автор предлагает не замыкаться на сообществе как на просто «какой-то штуке, которая повышает вовлеченность клиентов», а предлагает смотреть шире.
Переход от извлечения ценности к инфраструктуре
Модель «извлечения ценности» рассматривает отношения с клиентами как в формате торгового автомата: всуньте проблему — получите идеи. Такие «отношения» (а это, все же, они) транзакционны, эпизодичны и — в эпоху генеративного ИИ — все чаще просто бессмысленны.
Инфраструктура — это другое. Это инвестиция в способность выстраивать отношения, которая со временем накапливает ценность. Связи между участниками и организаторами укрепляются. Институциональная память углубляется. Вопрос меняется с «какие идеи мы можем получить?» на «какая инновации, которые мы не смогли бы внедрить в одиночку, становится реальными благодаря этим отношениям?»
Пять уровней инфраструктуры сотрудничества
Организации, которые делают это правильно, обычно работают сразу с пятью уровнями. Если пропустить хотя бы один, проблемы появятся позже — чаще всего под видом «низкой вовлеченности» или впечатления, что «сообщество не приносит ценности».
Fit — стоит ли вообще это делать?
Большинство программ полностью пропускают этот уровень. У кого-то возникает идея, находится бюджет — и начинается запуск. Стратегическое обоснование появляется потом, если вообще появляется.
Fit отвечает на два вопроса: «Должна ли эта инициатива входить в наш портфель инноваций?», «Способна ли организация действительно использовать то, что получит?».
Другие ключевые вопросы: «Кто владеет результатами?», «Какие ресурсы доступны заранее?», «Кто имеет полномочия принимать решения?». Программы проваливаются не только из-за нехватки идей. А еще потому, что внутри организации никто не готов с ними работать.
Frame — что именно мы строим?
Frame отвечает на структурные вопросы программы: «Что мы просим людей делать?», «Кто участвует?», «Как происходит взаимодействие?» «Какие правила?».
Главное здесь — конкретика. Размытые формулировки – размытая реализация. В итоге внутренние команды тратят больше времени на интерпретацию идей, чем на решение проблемы. Также важны границы ответственности. Например, LEGO Ideas работают, потому что граница ясна: фанаты создают идеи – компания производит продукт.
Проект Quirky провалился, потому что границы размылись. Формат участия тоже должен соответствовать задаче:
- Постоянные платформы — для непрерывного сбора идей;
- Ограниченные по времени задачи — для фокусированного решения проблем;
- Когортные программы — для совместной разработки;
- Офлайн-встречи — для укрепления отношений;
Типичная ошибка — использовать один формат для всего.
Exchange — зачем нужным нам людям приходить?
Если Fit и Frame — организационный дизайн, то Exchange — про людей.
При работе с каждой программой нужно ответить: что такого получают участники здесь, чего не могут получить в другом месте? Как варианты:
- Доступ к уникальному кругу экспертов
- Влияние на развитие продукта
- Ранний доступ к стратегической информации
- Признание
- Финансовое вознаграждение
При этом «быть частью сообщества» — не ценностное предложение. Другая распространенная ошибка — переоценка генерации идей. Тестирование, критика, документация, синтез знаний… Если концентрироваться исключительно на создании идей для бизнеса или себя — это будет всё, что даст сообщество.
Ops — как все это работает на практике?
Ops — самый неприметный, но самый важный уровень. Здесь, условно, отвечаем на вопросы о том, куда попадают предложения и что с ними происходит дальше.
Например, в Salesforce IdeaExchange каждая категория закреплена за конкретными продакт-менеджерами. Идеи не попадают в абстрактную очередь. Они оказываются у людей, которые могут принять решение.
Adobe заменил постоянную платформу двумя циклами фокусирования в год. Ограничения создают фокус.
Самое важное операционное обязательство — обратная связь. Не: «Спасибо за идею», а «Вот то, что мы сделали с ней» или «Вот причина, почему ничего сделали». Я видел, как тишина разрушает больше программ, чем любой другой фактор.
Также, в эпоху ИИ нужно четко определить для сообществ: что делают люди (оценка, контекст, новая постановка проблем), что делает ИИ (синтез, фильтрация, выявление схожестей). Если вы не можете объяснить, зачем в конкретном процессе вам нужны люди, а не ИИ, то вы либо тратите время участников, либо подрываете их доверие.
Yield — работает ли это вообще?
Yield — это уровень подотчетности. После всей архитектуры и операций нужно спросить: «Какой результат мы получили?»
Один из ключевых показателей — доля внедренных предложений. Например, система предложений внутри Toyota реализует около 70% идей, поэтому она существует десятилетиями.
Если предложения не реализуются, участники это быстро замечают. И уходят. Кроме внедрения, важно связывать вклад участников с реальными бизнес-результатами: рост выручки, снижение затрат, снижение рисков, экономия времени. Это сложнее, чем просто считать количество идей — поэтому большинство программ этого не делает.
Есть и еще один важный актив: институциональная память. Что остается в организации, если владелец программы уходит? Что знают постоянные участники, чего не знают новые? Если каждый цикл начинается с нуля, значит вы не строите инфраструктуру — вы просто создаете движуху.
Как использовать фреймворк
При проектировании новой программы, работайте последовательно: Fit → Frame → Exchange → Ops → Yield. Помните, что каждый следующий уровень зависит от предыдущего.
Для диагностики существующих программ, проведите аудит по слоям. Чаще всего проблемы возникают из-за пропуска конкретных этапов: Fit — отсутствует стратегическая ясность и Exchange — не совпадают стимулы. То, что выглядит как проблема вовлеченности, на деле часто — проблема на этапе Fit.
Этот перевод оригинальной статьи подготовлен Лабораторией комьюнити-менеджмента.
Переводчик: Александра Бутылина
Редактор: Илья Пономарев