Розробка нового продукту: нові правила гри (New new product development game)

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

Це змінило акценти, які ставились на нові продукти як на джерело продажів і прибутку. До прикладу, в компанії 3М 25% продажів — продукти віком менше ніж 5 років. У 1981 році огляд 700 компаній зі США показав, що нові продукти складають третину всіх доходів у 1980-х (тоді як у 70-х нові продукти складали лише одну п’яту).

Фокусування на швидкості й гнучкості вимагало знайти свіжий підхід до керування розробкою інноваційних продуктів. Традиційний послідовний (естафетний, каскадний) підхід — як, наприклад, в NASA, — може обмежувати швидкість та гнучкість у досягненні цілей. І навпаки, цілісний, або ж “регбі”-підхід, у якому команда намагається пройти дистанцію як єдине ціле, перепасовуючись м’ячем, в умовах жорсткої конкуренції працює краще.

Класичний процес розробки продукту нагадує естафету, де одна група вузькопрофільних фахівців передає роботу наступній. Таким чином, продукт послідовно розвивається від етапу до етапу: спершу концептуальний розвиток, тоді техніко-економічне обґрунтування, дизайн, розробка, дослідне виробництво і запуск. З цим підходом команди звужуються і сегментуються: маркетологи займаються потребами клієнтів і аналізують концепції розробки продукту, дизайнери й R&D інженери готують дизайн, інженери-технологи матеріалізують концепції й так далі.

При підході “регбі” розробку продукту в постійній взаємодії виконує мультидисциплінарна, відібрана вручну команда, члени якої співпрацюють від старту до фінішу. Замість рухатися за визначеними, структурованими етапами, процес народжується із взаємодії членів команди (див. Рисунок 1). Група інженерів, наприклад, може почати розробляти дизайн продукту (етап 3), ще не отримавши результати техніко-економічних тестів (етап 2). Або ж команда отримає нову інформацію і перегляне рішення. В кожному разі, робота не стане, а перейде в стан ітеративного (циклічного) експериментування. Часом таке трапляється навіть на останніх етапах розробки.

Рисунок 1 ілюструє відмінності між традиційним, послідовним підходом до розробки продукту, і підходом “регбі”. Послідовний підхід, відмічений як тип А, характерний для систем поетапного планування програм по типу NASA. Підхід взаємного перекриття представлено типом B, де воно можливе лише на межі сусідніх етапів, і типом С, де може розповсюджуватися на кілька етапів. Ми спостерігали взаємне перекриття по типу B в Fuji-Xerox, а по типу С — в Honda і Canon.

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

У цій статті ми описуємо компанії в Японії та США, що втілили новий підхід до керування процесом розробки продукту. Наше дослідження торкнулося таких мультифункціональних компаній, як Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox і Hewlett-Packard.

Ми проаналізували процес розробки шести конкретних продуктів:

• ксерокс середнього розміру FX-3500 (випущений Fuji-Xerox у 1978 році);
• персональний ксерокс PC-10 (Canon, 1982);
• міський автомобіль із двигуном на 1200 кубів (Honda, 1981);
• персональний комп’ютер PC 8000 (NEC, 1979);
• однооб’єктивний дзеркальний фотоапарат AE-1 (Canon, 1976);
• плівковий фотоапарат Auto Boy, відомий у США як Sure Shot (Canon, 1979).

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

Moving the scrum downfield

Спілкуючись з різними членами організацій, від СЕО до молодих інженерів, ми виявили, що у ведучих компаній є шість характеристик в управлінні процесом розробки нових продуктів:

1. Заморожена нестабільність
2. Самоорганізовані команди проєктів
3. Перехресні етапи розробки
4. “Мультинавчання”
5. Слабкий контроль
6. Організаційна передача навчання

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

Заморожена нестабільність

Вище керівництво починає процес розробки, повідомляючи про широку мету чи загальний стратегічний напрямок. Воно рідко пропонує чітку концепцію нового продукту або ж конкретний план роботи. Зате дає команді розробки більше свободи, а також встановлює їй складні задачі. Наприклад, топменеджери Fuji-Xerox дали проєктній команді FX-3500 два роки на розробку машини, що працювала б на рівні з ксероксами елітної лінії, а коштувала у виробництві удвічі дешевше.

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

Самоорганізовані проєктні команди

Проєктна команда набуває самоорганізованості, коли входить у стан “нульової інформації” — тобто, коли базові знання не застосовуються. У цьому стані існує безліч коливань і невизначеності. Закипаючи на повільному вогні, команда починає створювати власний динамічний порядок. Вона діє як стартап — виявляє ініціативу, приймає ризики, розвиває власну незалежну справу. Якоїсь миті група починає створювати власні концепції.

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

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

Такий вид автономії проявився, наприклад, коли в IBM розробили персональний комп’ютер. Маленька група інженерів стала працювати над машиною на переобладнаному складі в далекому Бока Ратон, штат Флорида. Штаб-квартира компанії в Армонку, Нью-Йорк, дозволила групі з Бока Ратон працювати на власний розгляд, беручи участь хіба що у квартальних зустрічах. І група змогла вийти вперед, приймаючи неординарні рішення, як, наприклад, використання мікропроцесорів і програмного забезпечення від зовнішніх постачальників.

Ми спостерігали й інші приклади автономії.

• Проєктна команда Honda City, середній вік якої складав 27 років, отримала завдання розробити машину, “про яку мріятиме молодь”. Інженер відгукується:

• Маленька група інженерів із відділу продажів, які раніше просто продавали мікропроцесори, повністю розробили PC 8000 для NEC. І почали вони, не маючи жодних знань про персональні комп’ютери. Ось слова голови проєкту:

Самоперевершення. Проєктні команди втягуються в нескінченний пошук кордонів. Вони починають з директив керівництва, а потім встановлюють власні цілі й продовжують “підвищувати планку” протягом усього процесу розробки. Проштовхуючи те, що на перший погляд здається суперечливими цілями, вони винаходять шляхи подолання статусу кво і роблять відкриття.

Ми спостерігали безліч таких прикладів. Проєктна команда Canon AE-1 генерувала цілком нові ідеї, щоб справитися зі складними задачами, поставленими керівництвом. Їм дали завдання розробити висококласну камеру з автоматичною витримкою, компактну, легку, просту у використанні та на 30% дешевшу за інші однооб’єктивні дзеркалки. Для досягнення цієї амбітної мети проєктна команда зробила кілька відкриттів у дизайні й розробці фотоапаратів: електронний мозок з інтегрованих схем, розроблених Texas Instruments на індивідуальне замовлення; модульне виробництво, що дозволило втілити автоматизацію і добитися масовості; зменшення кількості запчастин на 30-40%.

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

Проєктна команда Honda City також вирвалась за межі статусу кво. Їм запропонували розробити автомобіль для молодіжного сегменту з двома конкурентоздатними характеристиками: економність пального й ресурсів і безкомпромісна якість за низькою ціною. Природним інстинктом у цьому випадку було б розробити здешевлену версію бестселеру Honda Civic. Утім, після багатьох обговорень команда прийняла рішення створити цілком нову концепцію автомобіля. Популярну думку про те, що авто має бути низьким і довгим, вони трансформували в концепцію високої й короткої машини. Переконана, що еволюція рухається в напрямку “мінімум машинного, максимум людського”, команда вирішила ризикнути й піти проти загальноприйнятих норм автомобільної індустрії.

Взаємне запліднення. Розробку нового продукту виконує проєктна команда, члени якої мають різні функціональні спеціалізації, тип мислення і шаблони поведінки. До прикладу, команда Honda складалась із відібраних вручну членів відділів R&D, продажів і виробництва. Компанія навіть спеціально відібрала в команду особистостей з цілковито різними якостями. Це дозволило створити безліч нових ідей і концепцій.

Відібрати різнобічну команду — надзвичайно важливо. Однак взаємне запліднення почнеться тільки тоді, коли її члени почнуть взаємодіяти одне з одним. Fuji-Xerox розташували всю багатофункціональну команду, що розробляла FX-3500, в одній великій кімнаті. А це — члени відділів планування, дизайну, виробництва, продажів, розповсюдження й оцінки. Ось як цей крок оцінили учасники проєкту:

Перехрещення етапів розробки

Самоорганізований характер команд забезпечує їхню унікальну динаміку, ритм роботи. На початку проєкту члени команд мають різні часові горизонти — найдовший у фахівців R&D, найкоротший у фахівців із виробництва. Усі вони синхронізують ритми, щоб вкладатися в терміни. І хоч проєктна команда починає з нульової точки відділу, та дуже скоро кожен її член здобуває інформацію маркетингового і технічного напрямків. Як результат, усі працюють як одне ціле. Команда й особистість стають неподільними. Ритми окремої людини і групи перехрещуються, створюючи цілковито нове биття. Цей пульс і стає силою, що штовхає команду вперед.

Швидкість пульсу буде різною на різних етапах розробки. Биття є найпотужнішим на ранніх етапах і сповільнюється з часом. Ось як описує цей ритм член проєктної команди Canon PC-10:

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

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

Fuji-Xerox успадкували систему поетапного планування проєкту (тип А на Рисунку 1) від батьківської компанії, але переглянули її у двох моментах. По-перше, вони зменшили кількість етапів роботи з шести до чотирьох, змінивши опис деяких і відтворивши їх по-іншому. По-друге, вони змінили лінійну, послідовну систему на так звану систему сашімі (сашімі — рибні слайси, розкладені на тарілці так, що один накладається на інший) (див. Рисунок 2).

Система сашімі вимагає широкої взаємодії не тільки серед учасників проєкту, але і з постачальниками. Команда FX-3500 запросила постачальників приєднатися до проєкту на початку (адже ті виготовляли 90% запчастин). Кожна сторона регулярно відвідувала іншу і підтримувала постійний інформаційний контакт. Такий тип обміну й відкритості — як всередині команди, так і з виходом назовні, до постачальників — підвищує швидкість і гнучкість. Завдяки цьому Fuji-Xerox скоротили процес розробки з 38 місяців (стільки пішло на створення попередньої моделі) до 29.

Якщо сашімі — хороше слово для опису підходу Fuji-Xerox, то регбі ідеально описує перекриття етапів у Honda. Точно як у команді з регбі, головні гравці в Honda зберігають свої позиції протягом усього проєкту і відповідають за комбінування етапів.

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

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

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

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

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

Мультинавчання

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

Навчання через роботу виявляється у двох вимірах: через безліч рівнів (індивідуальний, груповий, корпоративний) та функцій.

Багаторівневе навчання. Існує безліч варіантів навчання на індивідуальному рівні. Наприклад, 3М дає інженерам змогу витратити 15% робочого часу на власну мрію. Canon використовує тиск колег, щоб стимулювати членів команди навчатися. Інженер-конструктор проєкту PC-10 пояснив це так:

На груповому рівні мультинавчання також є ефективним. Honda відправила кількох членів команди проєкту City в Європу на три тижні. Якраз перед кінцевим терміном, на етапі розробки ідеї. Людям було сказано:

Як результат, на відпочинку вони побачили Міні-Купер — маленьку машинку, розроблену в Великобританії кількадесят років тому — і це сильно вплинуло на філософію нового дизайну.

Розробляючи ксерокс PC-10, члени команди Canon йшли з офісів і проводили зустрічі в сусідніх готелях. На одній із таких зустрічей вся команда розбилась на підгрупи, у кожній із яких був представник відділу дизайну і відділу виробництва. Кожній підгрупі поставили задачу підрахувати вартість основних запчастин і знайти спосіб зменшити її на третину. Один з учасників зустрічі згадує:

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

Hewlett-Packard розробила чотириетапну програму навчання маркетингу в рамках корпоративної мети стати більш ринково орієнтованими. Тепер компанія випускає найкращих академіків і бізнес-консультантів із розповсюдження маркетингового меседжу. Вона також застосовує техніки, що зазвичай використовуються в індустрії товарів широкого вжитку: фокус-групи, кількісні ринкові дослідження і пробний маркетинг. Ще Hewlett-Packard створила корпоративний маркетинговий розподіл, щоб підсилити те, що один інсайдер назвав “переходом від інженерної компанії для інженерів до такої, що краще орієнтується на потреби ринку”.

Багатофункціональне навчання. Експертів спонукають збирати досвід в інших областях.

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

• Команда, що працювала над PC 8000 від NEC, складалася з інженерів продажу з відділу електронних пристроїв. Безліч знань, необхідних для запуску першого ПК компанії, вони отримали, підготувавши комп’ютерний комплект TK 80 і вивівши його на ринок за два роки до PC 8000. Ще впродовж року, навіть на вихідних, вони проводили час у сервісному центрі NEC BIT-IN в центрі Акіхабари, спілкуючись із фанатами комп’ютерів і вивчаючи точку зору користувачів.

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

Корпоративні “регбі”-очки

Деякі компанії пришвидшують розробку нових продуктів.

• Новий ксерокс 9900 розробили в Xerox за три роки, тоді як на попередню модель витратили більше ніж п’ять років.
• Портативний принтер Brother EP-20 розробили за неповні два роки. Попередня модель “з’їла” чотири роки робочого часу проєктної команди.
• Одним із пріоритетів Джона Скаллі, президента компанії Apple в 1984 році, було скорочення часу на розробку продукту з трьох з половиною до одного року.

Інші організації додають процесу розробки нових продуктів гнучкості.

• Black&Decker представила 50 нових електроінструментів на Національній виставці техніки в Чикаго, щоб ефективніше конкурувати з японськими виробниками.
• Коли Yamaha стала загрожувати лідерству Honda на японському ринку в 1982 році, Honda випустила 30 нових мотоциклів за 6 місяців.
• IBM відмовилась від традиції розробляти все всередині компанії і використала мікропроцесор Intel і базову операційну систему Microsoft, створюючи свій персональний комп’ютер.

Слабкий контроль

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

Існує сім шляхів введення слабкого контролю в процес розробки нового продукту.

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

2. Створіть відкритий робочий простір, як у кейсі Fuji-Xerox.

3. Підштовхніть конструкторів вийти за межі своєї вузької області, послухати відгуки замовників і дилерів. Інженер Fuji-Xerox каже:

4. Встановіть систему оцінок і нагород на базі групової ефективності. Наприклад, Canon подавав групові патентні заявки в проєкті PC-10.

5. Керуйте ритмами під час розробки продукту. Пам’ятайте: на початку проєкту ритм роботи просто шалений, а до кінця він природним чином сповільнюється. Це нормально.

6. Передбачайте і пробачайте помилки. Інженери Honda люблять повторювати:

Ось як говорить про це виконавчий директор відділу R&D у Brother:

Представник 3М підмітив:

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

Передача навчання

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

Передача знань наступним проєктам розробки продуктів чи іншим відділам організації має відбуватися постійно. В деяких вивчених нами компаніях ця передача відбувалася шляхом осмосу — через введення ключових особистостей в команди наступних проєктів. Виконавчий директор Honda пояснив:

Передача знань всередині організації також виконується через перетворення проєктної діяльності на стандартну практику. В Canon, наприклад, під час роботи над Auto Boy було створено формат оглядів, що використовувався в наступних проєктах. Один із учасників команди згадує:

Природно, що компанії намагаються інституціоналізувати уроки, отримані з власних успіхів. IBM намагається повторити проєкт розробки персонального комп’ютера, який завершили за 13 місяців із застосуванням сторонньої допомоги, у всій компанії.

В Hewlett-Packard група, що займалась персональними комп’ютерами, змінила спосіб розробки і продажу нових продуктів компанії. В минулому компанія була відома тим, що проєктувала машину для конкретного клієнта за високу ціну. Але згодом вона розробила ThinkJet – недорогий тихий струменевий принтер для масового виробництва. За шість місяців із моменту запуску принтер охопив 10% ринку недорогих товарів. Hewlett-Packard стали застосовувати те, чому навчилися при проєктуванні і визначенні цінової політики ThinkJet, у наступній лінійці мінікомп’ютер. Через кілька місяців після виходу ThinkJet на ринок компанія представила мінікомп’ютер для широкої аудиторії за помірною ціною.

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

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

• Мета Epson — щоб модель наступного покоління вже була в процесі розробки, в той час, як нова модель виходить на ринок. Компанія вимагає від проєктних команд, щоб кожна нова модель була мінімум на 40% кращою за попередню.
• Коли Honda конструювала Civic третього покоління, її проєктна команда вирішила зламати всі старі запчастини і почати з нуля. На дебюті авто перед публікою команда попросила поруч з автомобілем поставити стенд з усіма новими запчастинами. Вони отримали нагороду “Автомобіль року” в Японії в 1984 році.
• Fuji-Xerox оновила підхід сашімі, вперше використаний при розробці FX-3500. У порівнянні з початковими зусиллями, сьогодні для нового продукту потрібна половина від початкової кількості людських ресурсів. Також Fuji-Xerox зменшила цикл розробки продукту від 4 до 2 років.

Певні обмеження

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

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

Деякі обмеження також пов’язані з обсягом дослідницької роботи. Розмір вашої вибірки і наші висновки обмежені кількома компаніями й управлінням процесами розробки в Японії. Загальні висновки треба робити обережно. Однак, оскільки ці методи вже отримали визнання у США, різниця між країнами може полягати не стільки в типі управління, скільки в рівні готовності до змін.

Наслідки для менеджменту

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

Щоб досягти швидкості й гнучкості, компанії мусять по-різному підходити до керівництва процесом розробки продукту. Треба враховувати три типи змін.

1. Адаптувати стиль керівництва, щоб той сприяв розвитку процесу. Керівники мають від початку усвідомлювати, що розробка продукту рідко протікає лінійно і статично. Це ітеративний, динамічний процес, що складається зі спроб і помилок. Щоб керувати таким процесом, компанія має дотримуватися високоадаптивного стилю.

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

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

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

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

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

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

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

Сформована команда проєкту починає рости завдяки відчуттю власної важливості (“нас обрали вручну”), законної влади (“ми маємо безумовну підтримку згори, щоб створити щось нове”) і місії (“ми працюємо, щоб перемогти кризу”). Вона слугує двигуном корпоративних змін, адже учасники проєкту з різних функціональних областей починають застосовувати стратегічні ініціативи, що виходять за межі традиційної діяльності компанії. Слідом за успіхом цих ініціатив знання передаються в наступні проєкти.

Середовище, в якому працює будь-яка багатонаціональна компанія — у США, Японії чи деінде — за останні роки різко змінилось. Відповідно, змінилися правила гри для ефективної конкуренції на сучасному світовому ринку. Беззаперечно, транснаціональні корпорації потребують швидкості і гнучкості в розробці.

Це вимагає динамічного процесу шляхом проб і помилок, а також активного навчання в процесі роботи.

У світі постійних змін потрібні постійні інновації. Чи не так?