Прийняття бізнес-рішень: ключове питання оцінки якості рішення

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

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

Для прийняття рішення необхідні:

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

Якщо мова йде про знаходження рішення, то самого рішення (або його варіантів) ще не існує, їх необхідно розробити.

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

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

Алгоритм роботи з рішенням

На першому кроці етапу знаходження рішення ми формулюємо проблему або задачу як різницю між тим, що ми хотіли б мати, і тим, що ми маємо.

На другому – аналізуємо проблему або задачу: в чому полягає перешкода, яку потрібно подолати, або які є способи досягнення цілі? Тут важливо розрізняти симптоми і корінну причину.

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

 Що означає прийнятних версій? Як оцінити якість рішення, що приймається? Переходимо на етап прийняття рішення. Автор теорії обмежень д-р Е. Голдратт запропонував питання для перевірки рішення, що приймається: якщо ЦЕ є рішенням, то ЩО є проблемою?

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

• На прийманні черга є? – Так.
• В сезон? – Так.
• Як Ви її вимірюєте? – В кілометрах.
• Як боретеся? – Ніяк. І не збираємося боротися.
• Чому? – Тому що в контрактах з перевізником немає плати за простої. Наш юрвідділ «відбив» цей пункт, тому ми за простої не платимо…

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

Як Ви думаєте, що стало новим рішенням? Консультант запропонував два варіанти механізмів управління чергою: 1) точний (що потребував впровадження ERP-системи) і 2) спрощений (що потребував приблизного розрахунку). І перш, ніж описати, подробиці цих механізмів, повернемося до методології по роботі з рішенням.

Оцінюючи варіанти на кроці 4, ми перш за все перевіряємо: якщо це є рішенням, то яку проблему воно усуне або зведе до мінімуму. І після відповіді на це ключове питання ми застосуємо ще декілька фільтрів (здійснимо крок №5 «Вибрати найбільш прийнятний варіант»):

• Чи створює рішення нові небажані явища в системі?
• Як ми будемо усувати нові небажані явища або зводити їх ефект до мінімуму?
• Які є критерії вибору найбільш прийнятного рішення? – Наприклад, відповідність критеріям якості продукту, що створюється; складність реалізації; термін впровадження і т.д.
• Який фінансовий ефект рішення, що приймається?

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

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

• Черга була необхідна як буфер, оскільки автомобілі починали з’їжджатися близько 12:00. Якби черги не було, то пункт приймання (вузьке місце) простоював би з 8:00 до 12:00.
• Час приймання для авто різної вантажопідйомності відрізняється незначним чином, що давало можливість розраховувати буфер в автомобілях, а не в тонах.
• О 12:00 визначали фактичний розмір черги, наприклад, 50 авто. Далі його співставляли з  пропускною спроможністю пункту приймання, наприклад, 30 авто з 12:00 до 20:00.
• Замовлення авто на наступний день корегувалося з урахуванням перевищення, наприклад, замість 90 запланованих авто замовляли 70.

Ми наблизилися до 6-го завершального кроку алгоритму «Впровадити рішення». Складні рішення потребують тестування і пілотних проектів для підтвердження своєї ефективності. Важливо розробити метрики успішності впровадження і проконтролювати їх виконання.

І, звичайно, впровадити задумане.