Як виходити з ситуації, коли бізнес-консультанти стали проблемою, а не рішенням

Це щире зізнання, розвінчування міфів про теорії менеджменту, порадник, як будувати бізнес, а ще — розповідь про цілком очевидне, але таке, що ми відмовляємося бачити 

21.01.2022

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

Авторка книги «Вибачте, я зруйнувала вашу компанію»  Карен Фелан розповідає, як створити бізнес, який даватиме не тільки гроші, а й відчуття сенсу, як бути ефективними у довгостроковому періоді. Карен американська бізнес-консультантка з 30-річним досвідом, яка понад 30 років працювала в менеджменті: від військово-дослідницького центру в Лос-Анджелесі, Pfizer Consumer Healthcare до IT-сфери та власної справи. Співзасновниця компанії Operating Principals, що пропонує альтернативний погляд на бізнес-консалтинг. Публікуємо уривок з її книги.

Не забудьте переналаштувати ще й людей

Оптимізовані процеси мають добрий вигляд тільки на папері

Усе, що вам насправді потрібно, — це люди, на яких можна покластися

Переналаштування процесів, а також їхня автоматизація — робота, якою я займалася велику частину кар’єри. Я це робила, коли тільки почала працювати в консалтингу, лише раніше ми називали це «операційним удосконаленням». Спогади про більшість клієнтських проєктів тих часів розмиті: це було багато років тому. Але першу роботу з клієнтом пам’ятаю добре — я тоді багато чого дізналася про проблеми бізнесу. Клієнтом був маленький виробник холодильників, який страждав від надлишку неліквідних запасів, прострочення виконання замовлень і невідповідності потребам клієнтів. За роки бізнес виріс із кількох продуктів у широку лінійку, яка пропонувала клієнтам вибір функціоналу й навіть індивідуальний дизайн. Операції ускладнилися, а конфігурація заводу залишилася та сама. Мій менеджер продав клієнту дуже дороге передове програмне забезпечення, яке мало покращити управління виробництвом, — це була велика інвестиція для компанії такого розміру. Він пообіцяв, що ПЗ оптимізує виробничий цех компанії та суттєво підвищить обсяг виробництва. На жаль, коли компанія послухала його рекомендації і запустила у себе це ПЗ, справи тільки ледь-ледь поліпшилися. Незадоволення клієнта — річ серйозна; у цьому випадку ще й тому, що та компанія користувалася й іншими нашими послугами; тож партнеру, який відповідав за напрямок роботи з виробництвами, довелося мчати до клієнта й залагоджувати ситуацію. Внаслідок перемовин моєму менеджеру заборонили з’являтися на підприємстві, і ми запропонували безкоштовно проаналізувати операції компанії та написати техзавдання для інтегрованого виробництва, інвентаря й фінансової інформаційної системи. Зрештою ця система розв’язала проблеми компанії, тому що зібрала всі її операції в єдине ціле.

Я опинилася на цьому виробництві разом з двома консультантами з бухгалтерського обліку, які мали писати ТЗ з фінансової частини. Вони сиділи в кабінеті нагорі, разом з іншими бухгалтерами, а мені дали місце якраз над головним цехом. Оскільки на цьому проєкті ми нічого не заробляли й на подальшу співпрацю з клієнтом шансів було мало, — наші місцеві начальники фактично кинули нас напризволяще. Я була вчорашньою випускницею інституту (з вищою інженерною освітою з обладнання електронної промисловості) й абсолютно не тямила у виробництві — і намагалася сама розв’язати проблеми цієї компанії. Так, мене продали їм як випускницю інженерного факультету Массачусетського технологічного інституту, диплом я отримала зі спеціальності «Напівпровідникові матеріали», де працювала з ультрамікроскопами на атомному рівні — це не зовсім таке виробництво, яке було тут у головному цеху. (Хіба що це мало б бути набагато, набагато менше виробництво!)

Я почала аналіз із екскурсії цехом з його начальником. Перше, що привернуло мою увагу, — деталі були повсюди. Офіційно вони називалися «робочим матеріалом». Це були заготовки на шляху від одного верстата до іншого. До кожного верстата було дві «черги» деталей — ті, які входили в нього, і ті, які з нього виходили. Через це в цеху був безлад і тіснява. По-друге, усі оператори біля верстатів були зайняті проштамповкою. І, нарешті, я звернула увагу на кількох чоловіків, краще й чистіше одягнених, ніж оператори машин. Вони ходили цехом і сперечалися з операторами. Щоразу, коли такий чоловік підходив до верстата, робота припинялася, і ці двоє немовби сварилися. Я спитала начальника цеху, що роблять ці люди. Він пояснив, що це експедитори. Робота експедиторів — стежити за терміновими чи високопріоритетними замовленнями. Вони супроводжували проєкт від початку до кінця, наче няньки. Експедитор приносив термінове замовлення до першого верстата, стежив, щоб першу деталь зробили, потім ніс її до другого верстата і так далі, поки не отримував готове замовлення. На жаль, цей процес надзвичайно шкодив графіку виробництва, особливо відколи його оптимізували дорогим ПЗ. Оператор мав припинити свою роботу — а саме робити деталь для іншого замовлення, — переналаштувати верстат і зробити деталь для експедитора. Нічого дивного, що наше ПЗ не працювало! Після екскурсії я почала говорити з робітниками цеху, плановиками виробничого процесу — з усіма, хто був готовий зі мною спілкуватися. Мене попередили, що працівники мають профспілку й навряд захочуть співпрацювати, але виявилося, що більшість навіть дуже рада була поговорити, а дехто й добряче виговорився, розповів усе, що думає про ситуацію: вони були раді, що з’явилася можливість бути почутими. Їхні власні керівники були такі зайняті, що ніяк не могли спуститися в цех і з кимось поспілкуватися.

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

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

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

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

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

Для цих винятків відділ кадрів мав свої способи впливу, але, на жаль, вони поширювались і на решту. У мене опускалися руки від того, як рідко люди з різних відділів спілкувалися між собою, і часто я почувалася медіаторкою. Опускалися руки ще й від «неконтрольованого розширення рамок проєкту». Мій менеджер попередив мене, що я маю займатися суто виробничим процесом і не потрапляти в популярну серед консультантів пастку: не виходити за рамки свого проєкту; але причини багатьох проблем були не в самому виробничому процесі. Коренем зла переважно була система винагород, але оскільки інформацією ніхто не ділився, а стосунки з клієнтами й постачальниками не були налагоджені — це теж спричиняло проблеми в цеху. Я виявила, що деякі закупівельні відділи робили замовлення у двох різних постачальників, щоб отримати продукт швидше, а потім скасовували друге замовлення. Щоб справді налагодити роботу цеху, потрібно було б залучити всіх учасників процесу.

Оптимізувати людину складно

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

  • Недовіра. Це, мабуть, найбільша проблема зіпсованих процесів. Коли люди роз’єднані й не спілкуються між собою, вони не розуміють, чому їхні колеги з інших підрозділів роблять ту дурню, яку роблять. Через це непорозуміння з’являються різноманітні ігри, контроль, кросперевірка, зустрічі для критики та затвердження — і все це ніяк не покращує процес. Недовіра, а також страх і надія — фундаментальні причини сумнозвісного ефекту батога в постачанні, коли маленькі зміни в попиті поширюються по всій ланці й спричиняють величезні девіації на іншому її кінці. По суті, клієнти роблять більше замовлень, бо не вірять, що постачальники все привезуть вчасно, і це впливає на всю ланку клієнтів і постачальників. Отримавши потрібну кількість товару, клієнти скасовують решту замовлень, і це знову впливає на всю ланку. Через це постачань стає або забагато, або замало.
  • Цілі, які конфліктують одна з одною / робота над перевагою. Про цю причину я більше розповім у наступному розділі, але суть така: окремо взятий функціональний підрозділ часто може мати мету, яка конфліктує з цілями іншого підрозділу. Наприклад, відділ продажу хоче закрити всі потреби в продукції, а відділ обліку працює над скороченням рівня товарних запасів; відділ маркетингу прагне якнайшвидше запустити продукт, а нормативно-правовий відділ наполягає на детальній перевірці його якості; головний офіс намагається скоротити кількість внутрішніх ініціатив, а регіональні — запускають програми вдосконалення, після яких з’являється купа нових ініціатив. Це всього кілька прикладів з усіх, з якими я стикалася.
  • Нетерплячість. Це впливає майже на всі ініціативи та проєкти в компанії, і при швидкому темпі роботи стає все більшою проблемою. Найчастіше я таке помічаю в розробці продуктів: коли розробляється важливий новий продукт або йде обговорення проєкту, який усім подобається, люди не можуть дочекатися запуску — буквально. На жаль, якщо портфель проєктів напхати, він переповнюється. Люди можуть працювати тільки над парою проєктів одночасно, а якщо запустити багато — вони залишаться незавершеними. Таку ж ситуацію я помічала і з багатьма корпоративними ініціативами. Команді, яка працює над проєктом, не вистачає терпіння, і працівники пропускають стадію аналізу, не знаходять реальних причин проблем і зрештою впроваджують рішення, які все тільки погіршують.
  • Страх видатися дурнем. У розробці нових продуктів це велика проблема. Часто співробітники, які працюють над новим продуктом, хочуть довести його до ідеалу, перш ніж показувати іншим. На жаль, нерідко через кілька місяців вилизування концепції вони дізнаються, що вона так і не побачить світ з юридичних, нормативних чи виробничих причин. Вони витратили купу часу на роботу над проєктом, який ніколи не запуститься. Якщо показати іншим незакінчений проєкт — можна раніше дізнатися, якщо він не годиться, але ніхто не хоче здатися дурним.

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

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

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