Матриця розподілу функціоналу або як припинити дублювання ролей

«У нас за цей проект відповідають комерційний директор разом із керівником виробництва».

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

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

Для розв'язання цього вузла ми впроваджуємо адаптовану під наші реалії модель RACI. Її суть — не просто намалювати таблицю для галочки, а жорстко розкласти ключові кроки процесу за чотирма однозначними ролями:

• R (Responsible — Виконавець): Співробітник або підрозділ, який фізично виконує задачу власними руками. Таких фахівців на етапі може бути кілька (наприклад, група проектувальників чи бригада монтажу).

• A (Accountable — Відповідальний за результат): Єдина особа, яка одноосібно підписує акт здачі, контролює дотримання дедлайну та бюджету і несе персональну фінансову відповідальність за помилку. Ключове правило нашої школи: біля однієї задачі в матриці ніколи не може стояти дві літери «A». Якщо це станеться — ви знову повертаєтеся до колективної безвідповідальності.

• C (Consulted — Експерт): Фахівець, чия думка обов'язкова до початку виконання етапу (наприклад, юрист при складанні договору або головний технолог перед запуском нестандартної партії). Експерт надає технічний висновок або рекомендацію, але не приймає остаточного рішення і не блокує процес затягуванням узгоджень.

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

Коли матриця розписана на рівні щоденних бізнес-процесів, із компанії зникає «сіра зона», де зазвичай тонуть прибутки та з'являється перекладання провини. Кожен знає, де він працює руками, де ставить остаточний підпис, а куди заходить виключно як експерт.