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

Інша відмінність полягає в підході паралельного проектування на основі набору, яким відомий LPPD. У традиційному NPD ви використовуєте концепції для вибору дизайну – по суті, ви повинні базуватись на тому, «що найкраще виглядає на папері». На жаль, коли ви наближаєтеся до фінішу і вникаєте в деталі інженерного процесу, неминуче виникають проблеми. Проте не з LPPD. Алан Лейбс, колишній головний архітектор нашого продукту Subsea 2.0, доручив нам детально описати всі можливі конструкції та навіть прототипувати їх, щоб побачити, наскільки вони справді технологічні. Я не пам’ятаю жодного дизайну, який залишився таким самим після того, як ми це зробили (зазвичай ми поєднували найкращі елементи зі створених нами прототипів у остаточне рішення). Такий спосіб роботи займає більше часу, і здається, що він коштує дорожче, але насправді він швидше, оскільки запобігає помилкам, збоям і зрізам кутів.

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

Коли ми впровадили LPPD у команді інженерів (це був 2016 рік), з першого дня наші головні інженери тісно співпрацювали з нашим спонсором, віце-президентом, який пропустив кілька рівнів управління, щоб бути ближчим до розробки. Це не завжди добре сприймалося людьми, але через п’ять років усі звикли до такої поведінки, бо знають, що це найкращий спосіб отримати інформацію. Отже, керувати без повноважень, звичайно, нелегко, але ви можете впоратися з цим.

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

Порівняно із загальним складанням усього портфоліо в 1.0, ми зменшили кількість деталей більш ніж на 75%, розмір деталей на 45%, а вагу лише на 30%. Основна причина, через яку ми так сильно боролися з цільовою вагою, що зрештою втратили її пріоритет, полягає в тому, що люди використовували її неправильно, намагаючись робити речі, які додавали витрат заради зменшення ваги.

Коли ми перейшли до процесу розробки, коли ми розробили новий процес конфігурації на замовлення, ми почали впроваджувати більше міжфункціональних цілей: час виконання має становити 12 місяців, а вартість — на 25% нижча. Ми подивилися на прогалину, з якою зіткнулися в кожній частині продукту, і почали з’ясовувати, які саме його частини ми хочемо атакувати в першу чергу, в результаті чого наш час виконання скоротився з 24 місяців до 13 місяців.

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

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

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

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

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