Як швидко протестувати нові організаційні дизайни

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

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

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

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

Золотий стандарт: Рандомізовані контрольні випробування

Польові експерименти, також відомі як рандомізовані контрольні випробування (Randomised Control Trials, RCT), є золотим стандартом для визначення того, чи буде дизайн працювати в конкретному контексті. Експерименти передбачають випадкове призначення одних одиниць (тобто людей, команд, проєктів або відділів) до умов впливу (нової політики, яку ви плануєте впровадити), а інших — до контрольної групи (де все залишається так, як і було без нової політики). Потім ми перевіряємо, чи результати статистично відрізняються між цими двома умовами.

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

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

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

В ідеалі ви б випадковим чином призначили половину команд у вашій компанії до нової agile-структури, залишивши решту без змін, і перевірили б статистично та економічно значущі відмінності в їхній роботі наприкінці кількох місяців. На практиці вартість, ризик для безперервності бізнесу та політичні виклики, пов’язані з просуванням рандомізації, можуть зробити це непростим завданням.

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

Альтернатива: Гейміфікація поєднується з рандомізацією

Ось альтернативний протокол, який, на мою думку, може перемогти сліпе впровадження поточних «найкращих практик».

Крок перший

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

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

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

Крок другий

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

Крок третій

Призначте половину команд, які беруть участь у хакатоні, до нової agile-структури. Решту команд залиште в їхніх стандартних структурах із тими ж командними лідерами та розподілом ролей. Дуже важливо, щоб це було зроблено випадковим чином — киньте жереб, якщо це необхідно.

Крок четвертий

Порівняйте, як працювали команди в agile- та в традиційній структурі.

Ось і все! За один день ви можете поєднати тимбілдинг із пілотним тестуванням нового дизайну, який ви плануєте впровадити.

Чому це хороша ідея

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

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

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

Ілюстрація: gpstrategies.com