Як створювати підривні інновації

1. скромні, але доступні ресурси;
2. можливість незалежно розвивати і перевіряти свої ідеї;
3. особиста зацікавленість у результаті.

У підрозділах великих стабільних компаній таких умов зазвичай немає. Пам’ятайте, що структура — це просто передумова, вона не гарантує успіху. Але неправильна структура майже напевно призведе до невдачі.

Скромні, але доступні ресурси

У великих, стабільних організаціях керівники підрозділів, щоб збільшити свій бюджет, зазвичай використовують політичні ігри. Але вони знають, що цей бюджет може бути скорочено. Тому часто вони намагаються збільшити його якомога більше і готові будь-якими способами захищати його від зазіхань інших підрозділів. У цих політичних іграх менеджер іноді виграє, а іноді програє: якщо в організації трапляється криза, бюджет може бути раптово скорочено. Це не катастрофа: команді просто доведеться працювати більше з меншими ресурсами. Але саме тому, щоб врахувати таку ймовірність, бюджет часто від самого початку завищують.

У стартапа все по-іншому: надто великий бюджет для нього так само шкідливий, як і надто маленький — це підтвердили невдачі незліченних доткомів, — і стартапи дуже чутливі до змін бюджету в процесі роботи. Дуже рідко стартап може дозволити собі несподівано скоротити бюджет на 10%. Такий удар може виявитися для нього фатальним. У незалежних стартапів дуже невисока частка прибутку і тому майже немає права на помилку. Тож стартапом керувати і легше, і складніше, ніж підрозділом великої компанії: йому потрібно набагато менше капіталу, але цей капітал має бути захищеним від будь-яких зазіхань.

Можливість розвиватися незалежно

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

Я рекомендую створювати крос-функціональні команди, щоб у них постійно працювали люди з усіх підрозділів компанії, які беруть участь у створенні або продажі перших продуктів. Завдання таких команд — розробляти і представляти споживачам реальні функціонуючі продукти, а не просто дослідні зразки. Дискусії з керівництвом і необхідність отримувати його схвалення уповільнюють цикл зворотного зв’язку «створити — оцінити — навчитися», заважають навчанню і знімають із команди стартапу відповідальність. Тому будь-які затримки, пов’язані зі схваленням начальства, мають бути зведені в стартапі нанівець.

Звісно, такий рівень незалежності часто лякає головну організацію. Але розвіяти її страхи допоможе метод, описаний нижче.

Особиста зацікавленість у результаті

Підприємець має бути особисто зацікавлений у результаті своїх творчих зусиль. Незалежні нові підприємства зазвичай пропонують своїм співробітникам будь-які форми володіння акціями. Якщо ж замість них використовується система бонусів, то співробітники мають отримувати премії та заохочення у разі довгострокового успіху інновацій, які вони створюють.

Але я не думаю, що особиста зацікавленість має бути лише фінансовою. Наприклад, є некомерційні та державні організації, де інновації не пов’язані із фінансовими цілями. Але й у таких випадках особиста зацікавленість може бути присутньою. Від головної організації потрібно точно визначити, хто несе відповідальність за розробку інновацій, і ця людина має отримувати визнання, якщо вона створила новий продукт та цей продукт успішний. Як сказав один підприємець, керівник підрозділу у великій медіакомпанії:

Ця формула ефективна й у комерційних організацій. У компанії Toyota менеджера, який відповідає за розробку нової моделі від початку до кінця, називають головним інженером або суса.

І навпаки, я знаю надзвичайно успішну і відому технологічну компанію, що заслужила на особливу репутацію своєю інноваційною культурою, але її досвід розробки нових продуктів дуже невтішний. Компанія пишається своєю системою стимулювання, заснованої на великих преміях і статусних бонусах для членів команд, які досягли якихось визначних успіхів, але премії присуджує вище керівництво невідомо на яких підставах. Немає жодних об’єктивних критеріїв, за якими команда може зрозуміти, чи виграє вона у цій лотереї. Команда не впевнена, що їй доручать подальшу розробку інновацій, які вона створила. Тому люди не мотивовані йти на реальний ризик і натомість вважають за краще займатися лише тими проєктами, які майже напевно отримають схвалення вищого керівництва.

Створення платформи для експериментів

Далі важливо встановити основні правила, за якими діятиме незалежна команда стартапу. Ці правила мають регулювати наступне:

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

Згадайте «острів свободи», який дозволив команді SnapTax створити внутрішній стартап у компанії Intuit. Це і є те, що створює платформу для експериментів.

Захист головної компанії

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

Давайте почнемо з опису доволі типової зустрічі, яка проходила в офісі одного з моїх клієнтів, великої компанії. Метою зустрічі було визначити, які опції потрібно включити в наступну версію продукту. Згідно з новим підходом, заснованим на зборі суворих даних, було проведено експеримент із ціноутворенням. Перша частина зустрічі була присвячена даним, отриманим під час цього експерименту.

Тут виникла одна проблема: ніхто не міг зрозуміти, що ці дані означають. Для цієї зустрічі було підготовлено багато звітів про користувачів; команда розробки баз даних була також присутня на ній. І чим наполегливіше її просили пояснити зміст кожного рядка в електронній таблиці, тим ясніше ставало, що ніхто не розуміє, як було отримано ці цифри. Всі просто сиділи і дивилися на цифри валового обороту за різними пунктами, ціни, розбиті по кварталах і сегментах споживачів.

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

Думаю, ви самі уявляєте, які проблеми виникають у такій ситуації: «показники марнославства» замість дієвих показників, надто тривалий цикл, робота великими партіями, незрозуміла гіпотеза зростання, непродуманий план експериментів, відсутність особистої відповідальності і як наслідок — жодного навчання, жодних нових знань.

Слухаючи доповідачів, я думав, що зустріч на цьому й закінчиться. Якщо ніхто не може дійти згоди, просто немає сенсу наводити докази на користь того чи іншого рішення. Але я помилився. Кожен підрозділ просто інтерпретував дані так, як було вигідніше для його позиції, і захищав її. Інші підрозділи погоджувалися з альтернативними інтерпретаціями, які підтримували їхню позицію, і т. д. Зрештою, рішення були прийняті, не ґрунтуючись на даних. Натомість керівник, який вів зустріч, був змушений керуватися параметрами, які здавалися йому найдостовірнішими.

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

Подібні ситуації таки створюють погану репутацію експериментам і рішенням, заснованим на даних. А вся справа була в тому, що команда баз даних писала звіти, яких ніхто не читав чи не розумів. Проєктні групи вважали, що експерименти — марнування часу, бо для них доведеться створювати сирі та «недороблені» опції. Слова «провести експеримент» здавалися просто виправданням у тому, щоб відкласти важке рішення. І навіть вище керівництво компанії вважало такі зустрічі хронічним головним болем. Звичні зустрічі, присвячені розстановці пріоритетів, були просто боротьбою думок, але хоча б було зрозуміло, що у них відбувається. Тепер же їм доводилося проводити ритуал, пов’язаний зі складними математичними розрахунками, який не приносив жодних результатів, — і він все одно закінчувався боротьбою думок.

Зрозумілі страхи

Однак у основі цієї ворожнечі підрозділів лежав цілком зрозумілий страх. Компанія обслуговувала два сегменти споживачів: корпоративних клієнтів і приватних. В одному сегменті у компанії були продавці, які пропонували складні системи іншим компаніям, а в іншому відбувалися здебільшого одноразові покупки. Основна частина поточних доходів компанії надходила від B2B-продажу, але зростання у цьому сегменті сповільнилося. Усі вважали, що у сегменті приватних клієнтів є величезний потенціал зростання, але його не вдавалося реалізувати.

Частково зростання уповільнювала структура ціноутворення. Подібно до багатьох постачальників, які працюють із великими замовниками, ця компанія спочатку встановила високі ціни, а потім пропонувала великі знижки «привілейованим» корпоративним клієнтам. Звичайно, кожен продавець переконував своїх клієнтів у тому, що йому запропоновані виняткові умови. Але приватним покупцям ціни у прайс-листі здавалися просто захмарними.

Команда, яка відповідала за зростання сегмента В2С, хотіла провести експеримент: знизити ціни та подивитися, що буде. Команда, яка відповідала за сегмент В2В, побоювалася, що це відлякає корпоративних клієнтів. Що буде, якщо вони побачать, що звичайні люди купують продукт за нижчими цінами, ніж вони?

Будь-хто, хто працював у компанії, орієнтованій на кілька сегментів, погодиться, що ця проблема має безліч можливих рішень. Наприклад, можна створити окремі набори опцій, щоб різні клієнти могли купувати продукт різного рівня (як різні класи у авіакомпаній), або навіть продавати продукти під різними брендами. Проте компанія не могла ухвалити жодного з таких рішень. Чому? Зі страху поставити під удар поточний бізнес кожен запропонований експеримент відкладався, саботувався та ускладнювався.

Важливо наголосити, що страхи компанії були цілком обґрунтовані. Саботаж є адекватною реакцією менеджера, якщо хтось вторгається на його територію. Ця компанія — не скромний маленький стартап, який ще нічого не має. Великій компанії завжди є що втрачати. Якщо прибуток від основного бізнесу почне знижуватися, полетять голови. І до цього неможливо поставитися легковажно.

Чому так небезпечно приховувати інновації у «чорній скриньці»

Але якби ця компанія не стала активно експериментувати, її в результаті спіткала б сумна доля: рік за роком високі прибутки, а потім раптова смерть.

Створюючи внутрішні команди інновацій, ми часто питаємо: як захистити внутрішній стартап від головної організації? Але я хочу поставити протилежне питання: як захистити головну організацію від стартапу? Люди починають захищатись, коли відчувають, що їм загрожують, і в такій ситуації ніякі інновації неможливі. Тому великим компаніям часто рекомендують «заховати» команду інновацій. Але це помилка. Такий підхід іноді буває успішним, як ситуація, коли команда інновацій працює на стороні. Наприклад, перша модель ПК IBM була створена в Бока-Ратоні, штат Флорида, незалежно від інших підрозділів IBM. Але така стратегія рідко призводить до життєздатних інновацій. У перспективі секрети від головної організації загрожують серйозними проблемами.

Розглянемо цю ситуацію з погляду менеджерів, яким доручили розробку інновацій. Швидше за все, вони вважатимуть, що їх зрадили, і почнуть перетворюватися на параноїків. Зрештою, якщо щось настільки важливе можна успішно приховувати, що ще чекає їх у темряві? Згодом це призводить до політичних ігор, оскільки менеджери починають у всьому шукати загрозу своїй владі, впливу та кар’єрі. І успіх інновацій — не виправдання для такої нечесної поведінки. З погляду досвідченого менеджера, ситуація виглядає так: якщо ви не володієте інформацією, всі ці секрети призведуть до того, що вам завдадуть удару в спину.

Несправедливо критикувати цих менеджерів — відповідальність тут лежить на вищому керівництві, яке не змогло створити систему підтримки, котра б дозволяла відкрито діяти та створювати інновації, не намагаючись «ховати» їх. Я вважаю, що саме з цієї причини компанії, котрі діють за прикладом IBM, швидко втрачають лідерські позиції на нових ринках, які завоювали, створивши інновації в «чорній скриньці». Адже вони не можуть зміцнювати та підтримувати культуру, яка дозволила їм створити ці інновації.

«Пісочниця» інновацій

Але вихід є. Можна створити механізм, який дасть команді необхідні повноваження та дозволить відкрито створювати інновації. Це шлях до життєздатної культури інновацій, яка дозволить компанії вижити, коли вона знову і знову стикатиметься із загрозами своєму існуванню. Я пропоную таке рішення: створити «пісочницю» інновацій, у якій можна перевіряти нові ідеї будь-якими методами, без жодних обмежень. Це можна зробити таким чином: будь-яка команда може розробити експеримент зі спліт-тестування, що стосується тих елементів товару або послуги (якщо вони складаються з декількох елементів), які поміщені в «пісочницю», або призначений тільки для певних сегментів споживачів чи територій (для нових продуктів). При цьому:

1. Одна й та сама команда має проводити експеримент повністю — від початку до кінця;
2. Експеримент має займати чітко визначений час (зазвичай це кілька тижнів для простих експериментів з опціями, а якщо йдеться про підривні інновації – то довше);
3. Експеримент може поширюватися тільки на певну кількість клієнтів (зазвичай вона визначається як відсоток від загальної бази основних клієнтів компанії);
4. Кожен експеримент слід оцінювати на основі єдиного стандартного звіту, що містить 5-10 (не більше) дієвих показників;
5. Кожна команда, що працює в «пісочниці», і кожен продукт, який вона створює, повинні використовувати ті ж самі показники для оцінки успіху;
6. Під час проведення експерименту команда, яка його розробила, має відслідковувати показники та реакцію споживачів (дзвінки до служби підтримки, реакції у соціальних мережах, теми на форумах тощо). Якщо реакція різко негативна, експеримент слід перервати.

Спочатку «пісочниця» має бути невеликою. У компанії, описаній вище, до «пісочниці» спочатку входив лише прайс-лист. Залежно від типу продуктів, які створює компанія, розмір пісочниці може бути визначений по-різному. Наприклад, онлайн-сервіс може обмежити її певними сторінками сайту чи потоками користувачів. Роздрібна компанія може обмежитися кількома магазинами чи географічними областями. Якщо компанія намагається вивести на ринок зовсім новий продукт, обмеження можуть стосуватися певних сегментів споживачів.

Клієнти, які беруть участь в експериментах, що проводяться в «пісочниці», можуть бути реальними, і у команди інновацій має бути можливість встановити з ними довготривалі стосунки. Зрештою, вона може експериментувати з цими ранніми послідовниками протягом тривалого часу до того, як буде досягнуто результатів у навчанні.

За будь-якої можливості команди інновацій мають бути крос-функціональними, і їхній керівник має володіти тими самими повноваженнями, що й суса в компанії Toyota. Він повинен мати можливість керувати створенням, виведенням на ринок і просуванням продуктів або опцій у «пісочниці» без попереднього схвалення вищого керівництва. Його звіти про успіхи чи невдачі проєкту мають ґрунтуватися на стандартних дієвих показниках та обліку інновацій.

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

Успіх чи невдачу експерименту оцінити легко, бо від самого початку встановлено точні критерії та показники. Так чи інакше, команда може дуже швидко з’ясувати, чи правильні її припущення про поведінку клієнтів. Використовуючи систему обліку інновацій, описану в другій частині, команда може повідомляти про своє просування. І всі, хто читатиме її звіти, теж побачать, наскільки ефективні дієві показники. Такий підхід дуже продуктивний. Навіть якщо хтось захоче саботувати зусилля команди інновацій, для цього йому доведеться щонайменше зрозуміти, що таке дієві показники та етапи навчання.

«Пісочниця» також сприяє швидким ітераціям. Коли люди можуть виконати проєкт від початку до кінця, коли команда працює за принципом невеликих партій і швидко ухвалює чіткі рішення — вона отримує всі переваги зворотного зв’язку. Якщо їй не вдається поліпшити показники, вона може тут же щось зробити на підставі отриманих результатів. Тому такі команди схильні швидко приймати оптимальні рішення, навіть якщо вони починали не з найкращих ідей.

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

¹ Engineered in Japan: Japanese Technology-Management Practices. — New York: Oxford University Press, 1995.