Матрица ответственности мероприятия: кто за что отвечает

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

Матрица ответственности мероприятия показывает, кто готовит результат, кто принимает финальное решение, кого спрашивают заранее и кому сообщают об изменении. Она нужна до запуска работ: после начала монтажа спор о полномочиях уже стоит времени и денег. Если роли в вашем проекте пока живут в переписке, запросите разбор проекта и смету. Мы в «Авентуре» соберём рабочую схему под состав команды, площадку и формат события.

Почему ролей в чате недостаточно?

Коротко: Общий чат показывает участников разговора, но не даёт права на решение. В нём легко получить пять мнений и ни одного утверждения. Матрица ответственности связывает каждый результат с конкретным владельцем, исполнителями, профильными консультантами и получателями информации. Команда заранее видит, кто готовит решение, кто его принимает и кому нужно сообщить итог.

Фраза «это ведёт маркетинг» звучит понятно только до первого спорного вопроса. Бюджет, технические ограничения площадки, дополнительный расход и готовность сцены могут принадлежать разным владельцам. У подразделения нет руки, которая подпишет решение. Нужен конкретный человек с понятными полномочиями.

Проблема заметнее в проектах с несколькими сторонами. Заказчик определяет бизнес-задачу и лимиты. Агентство собирает проект и управляет связями.

Площадка подтверждает условия объекта, а профильные подрядчики отвечают за технологию и исполнение. Если границы не записаны, каждая сторона достраивает их по-своему.

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

Четыре действия вместо букв RACI

RACI - это четыре роли: исполнитель, владелец результата, консультируемый специалист и информируемый участник. Международная модель различает того, кто выполняет работу, того, кто принимает итог, тех, кто даёт данные до решения, и тех, кому сообщают статус. Для русскоязычной команды эти действия понятнее букв в таблице.

В классической модели R выполняет работу, а A владеет итогом и даёт финальное одобрение. C подключается до решения и даёт данные или экспертизу. I получает статус и итог, но не становится скрытым участником утверждения.

Мы переводим эту логику на язык проекта:

У одной строки может быть несколько исполнителей и консультантов. Владелец итога должен быть один. Если финальных владельцев два, при расхождении голосов решение снова уходит наверх и матрица теряет смысл.

Не нужно заносить в таблицу каждое письмо. Строка описывает результат, который можно проверить: «утверждён бюджет», «принята схема площадки», «разрешён запуск монтажа», «подтверждена готовность к открытию», «принят результат подрядчика».

Кто входит в матрицу проекта?

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

Начните с ролей. Фамилии меняются из-за отпусков, смен и замены подрядчика, а роль остаётся. Рядом можно вести отдельный список: основной человек, заместитель, контакт и часы доступности.

Базовый состав для корпоративного или делового события выглядит так:

• бизнес-владелец со стороны заказчика;
• руководитель проекта заказчика;
• руководитель event-проекта со стороны агентства;
• представитель площадки;
• технический или производственный руководитель;
• профильный подрядчик;
• закупки, финансы или казначейство заказчика;
• безопасность, медицина, информационные технологии и юридическая служба в тех строках, где нужна их экспертиза.

Для небольшого события один человек может совмещать несколько ролей. Это нормально, если полномочия не противоречат друг другу. Например, руководитель проекта агентства может готовить рабочую смету и отвечать за её целостность. Но увеличение лимита всё равно утверждает уполномоченный представитель заказчика.

На сложном проекте полезно отдельно назвать владельца общего статуса готовности. Профильные специалисты подтверждают свои системы. Один человек собирает эти подтверждения, видит ограничения и принимает решение о переходе к следующему этапу.

Если проект уже вышел за рамки одного подрядчика, организация мероприятия под ключ помогает вести решения, версии документов и сроки в одном проекте вместо нескольких несвязанных переписок.

Если роли расходятся между несколькими юридическими лицами и подрядчиками, мы соберём матрицу, календарь решений и смету в одном комплекте рабочих документов.

Матрица от брифа до закрытия

Рабочая матрица проходит через весь жизненный цикл события и показывает маршрут каждого ключевого решения. Сначала в ней фиксируют цель, бюджет, бриф, площадку и концепцию. Затем добавляют смету, договоры, производство, допуски, приёмку и изменения. Последние строки относятся к план-факту, документам и финальному платежу.

Ниже базовый шаблон. Названия ролей нужно заменить на реальные роли вашей компании и проекта. Строки тоже меняются: форуму понадобится отдельный блок по спикерам и трансляции, корпоративу на природе - по погоде и транспорту, открытию предприятия - по режиму объекта и протоколу гостей.

Таблица не заменяет договор, должностную инструкцию или требования площадки. Она показывает рабочий маршрут решения. Юридическую ответственность и право подписи определяют договоры, доверенности, внутренние положения и применимые нормы.

К каждой строке полезно добавить три служебных поля: документ или ссылка на актуальную версию, срок решения и маршрут эскалации. Тогда таблица отвечает не только на вопрос «кто», но и показывает, где находится подтверждение и что делать при задержке.

Финансовые строки полезно связать с платёжным календарём мероприятия. Профильный специалист подтверждает, что работа выполнена и расход обоснован. Решение о расходе принимает уполномоченный заказчик. Финансовая функция проводит платёж по своему процессу, но не подменяет техническую приёмку или бюджетное решение.

Как назначить одного владельца решения?

Один владелец завершает конкретное решение. Выберите человека с реальным правом принять результат или эскалировать вопрос. Если такого права у роли нет, строку нужно поднять на уровень выше или разделить на несколько решений. Такой подход сохраняет правило одного финального владельца и не смешивает подготовку данных с утверждением результата.

Проверьте владельца тремя вопросами:

1. Может ли он принять результат без дополнительного голосования?
2. Видит ли он последствия для бюджета, срока, качества и соседних функций?
3. Понимает ли команда, когда вопрос обязан уйти к нему?

Если ответ отрицательный, буква A поставлена формально. Например, координатор может собрать три предложения по площадке, но не иметь права выбрать вариант. Значит, он готовит решение, а владельцем остаётся руководитель проекта или бизнес-заказчик.

Большую строку иногда лучше разделить. Вместо «утвердить площадку» появляются отдельные результаты: подтвердить техническую пригодность, принять коммерческие условия, согласовать безопасность и принять финальный выбор. У каждой строки свой владелец, а итоговый выбор учитывает их подтверждения.

Не назначайте владельцем целое подразделение. Запись «отвечает маркетинг» снова создаёт коллективную ответственность. Укажите роль конкретного человека: директор по маркетингу, руководитель внутренних коммуникаций или менеджер проекта.

Границы заказчика, агентства и площадки

Заказчик владеет бизнес-целями, бюджетными полномочиями и корпоративными решениями. Мы собираем проект, актуальные версии и зависимости, а также координируем исполнителей. Площадка подтверждает условия объекта, а профильный подрядчик отвечает за свою технологию и качество результата в пределах договора. Такое разделение не даёт одной стороне незаметно принять чужое решение.

Конкретные права каждой стороны фиксируют договор и регламенты проекта. Поэтому мы заранее отмечаем, какие решения остаются у заказчика и какие подтверждения нужны от площадки или подрядчика.

Заказчик не обязан лично управлять каждым кабелем, пропуском или таймингом поставки. Его зона - цель, лимиты, содержание, внутренние согласования и решения, которые нельзя передать внешней команде. Чем яснее эта граница, тем меньше согласований агентство возвращает на уровень бизнес-владельца.

Мы следим, чтобы решения, документы и сроки не расходились. Для этого собираем требования, ведём актуальные версии, показываем последствия решений и передаём информацию между участниками. При этом мы не можем вместо заказчика увеличить бюджет, раскрыть внутренние данные или утвердить содержание выступления.

Площадка не просто «даёт зал». Её уполномоченные представители подтверждают доступ, режим работ, допустимые нагрузки, маршруты, инженерные условия и правила объекта. Перед выбором мы проводим технический аудит площадки, чтобы значимые ограничения получили владельца и попали в рабочие документы.

Подрядчик готовит и выполняет профильную работу. Техническое заключение по его системе даёт компетентный специалист. Общую координацию и переход между этапами ведёт руководитель проекта или назначенный руководитель производства.

Что делать с подрядчиками и безопасностью?

Коротко: Передача работы подрядчику не отменяет координацию проекта. В матрице отдельно фиксируют требования, выбор исполнителя, допуск, профильную проверку, приёмку и общий статус. Безопасность разбивают на конкретные функции вместо одной расплывчатой строки. Так у каждой проверки появляется компетентный исполнитель и понятный владелец решения.

В руководствах HSE и WorkSafe обязанности организующей стороны, площадки и подрядчиков разделены. У каждой стороны остаётся своя профессиональная зона. Общая команда проекта обеспечивает обмен информацией, совместимость работ и понятную цепочку решений до допуска к работам.

Для подрядчика нужны отдельные строки:

1. Сформировать требования к работе и результату.
2. Проверить компетентность, ресурсы и документы до допуска.
3. Передать ограничения площадки и соседних работ.
4. Разрешить начало монтажа или иной операции.
5. Принять промежуточный и финальный результат.
6. Зафиксировать ограничение, дефект и повторную проверку.

Обычно подрядчик по свету не утверждает сценарий эвакуации, а площадка не принимает художественный результат. Агентство не заменяет профильного инженера. Заказчик не диагностирует технический дефект, если у него нет такой компетенции. Иные полномочия возможны, когда их прямо устанавливают договор или регламент проекта.

Безопасность лучше разложить по функциям:

• риски и пожарные требования;
• медицина и потоки гостей;
• транспорт и временные конструкции;
• электричество и погодный сценарий;
• инструктажи, монтаж и демонтаж.

Для каждой функции назначьте исполнителя, владельца решения и маршрут эскалации.

Для делового мероприятия с несколькими потоками мы добавляем в матрицу регистрацию, навигацию, спикеров, трансляцию и управление залами. Состав строк меняется, а правило одного владельца итога остаётся.

Изменения без параллельных согласований

После утверждения базовой версии программы, схемы и сметы для каждого значимого изменения фиксируют инициатора, проверяют влияние на проект, назначают человека с правом решения и выпускают новую рабочую версию. Сообщение в чате не меняет проект, пока решение не внесено в общий документ и не доведено до затронутых ролей.

Заранее определите уровни полномочий. Координатор может переставить некритичный внутренний слот. Руководитель проекта может согласовать замену в пределах утверждённого резерва. Изменение цели, лимита, договорного объёма или уровня риска уходит уполномоченному заказчику.

Рабочий цикл изменения выглядит так:

1. Назвать результат, который меняется.
2. Зафиксировать причину и инициатора.
3. Оценить влияние на содержание, безопасность, стоимость, срок и соседние работы.
4. Передать решение одному владельцу нужного уровня.
5. Обновить смету, схему, тайминг или иной основной документ.
6. Уведомить исполнителей и профильных консультантов затронутой версии.
7. Вернуть изменённый блок на проверку или приёмку.

Старую версию не удаляют бесследно. Команде нужно видеть, когда и кем принято решение. Это особенно важно в последние дни, когда один комментарий может затронуть экранный контент, репетицию, печать, транспорт и работу ведущего.

Как собрать первый черновик на созвоне?

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

Подготовьте черновик заранее. В строки поставьте главные результаты:

• бриф, цель и бюджет;
• площадка, концепция и схема;
• смета, договоры и контент;
• допуски, приёмка и открытие;
• изменения и закрытие проекта.

На созвоне двигайтесь по порядку:

1. Назовите проверяемый результат строки.
2. Спросите, кто готовит его фактически.
3. Назначьте одного владельца финального решения.
4. Добавьте только обязательных профильных консультантов.
5. Определите, кому нужна информация для следующей работы.
6. Укажите документ, срок и маршрут эскалации.
7. Зафиксируйте заместителя для критичных ролей.

Спор по строке не нужно решать бесконечно. Если у двух руководителей одинаковые полномочия, поднимите вопрос к спонсору проекта. Если никто не готов владеть результатом, это не проблема таблицы. В проекте отсутствует управленческое решение.

После созвона руководители подтверждают свои роли письменно. Разместите матрицу рядом с календарём и актуальными версиями документов. Новому подрядчику показывают только релевантную часть, без лишних внутренних данных.

Проверка перед стартом проекта

Коротко: Матрица готова, если у каждой критичной строки есть один владелец итога, исполнитель, срок, документ и путь эскалации. Участники приняли роли, а изменения версий имеют понятный порядок. Таблица с пустыми ячейками или несколькими финальными владельцами не считается рабочей. Перед стартом команда должна знать, где лежит актуальная версия.

Перед запуском проверьте:

1. Строки описывают результаты, а не общие функции.
2. У каждой строки есть исполнитель и один владелец итога.
3. Подразделения заменены конкретными ролями.
4. Профильные консультанты подключаются до решения, информируемые не блокируют работу.
5. Бюджетное решение отделено от технической приёмки и проведения платежа.
6. Условия площадки подтверждает уполномоченная роль объекта.
7. Работа подрядчика, допуск и приёмка записаны разными строками.
8. Безопасность разложена на конкретные функции.
9. Есть владелец общего статуса готовности и решения об открытии.
10. У каждого изменения определён уровень полномочий.
11. Указаны документы, сроки, заместители и эскалация.
12. Команда знает, где лежит актуальная версия.

Для сложного проекта одной таблицы мало, но без неё остальные документы быстро расходятся. Если вам нужна организация события с единым управлением проектом, запросите смету. Работу можно начать с целей, сторон проекта и карты решений, а затем связать её со сметой, календарём и приёмкой.

Источники

• HHS: RACI Diagram Tool
• HSE: управление безопасностью мероприятия
• HSE: распределение обязанностей по площадке
• WorkSafe Victoria: управление подрядчиками мероприятия
• NASA: Project Planning and Control Handbook, раздел 3.8.3.2, стр. 228-230
• FEMA: планирование специальных мероприятий