Skip to main content
Home
2П - Консалтинговая компания

Main navigation

  • Обо мне
  • Почему мы
  • Наш подход
  • Услуги
  • Статьи
    • Мое мнение
    • Все статьи
    • Наши статьи
    • Процессы
    • Бережливое производство
    • Управление проектами
  • Канал

Диаграмма RACIS

RACIS — это инструмент распределения ролей в проекте или процессе. Он показывает, кто выполняет работу, кто отвечает за результат, с кем нужно консультироваться, кого информировать и кто оказывает поддержку. На бумаге все просто. В реальной компании именно здесь часто начинается конфликт: участвуют многие, а отвечать за результат должен кто-то один.

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

Что означает RACIS

  • R — Responsible. Исполнитель, который делает работу. В сложных задачах исполнителей может быть несколько, но их зоны нужно разделять.
  • A — Accountable. Владелец результата. Он принимает работу и отвечает за итог. Для одной задачи лучше иметь одного такого владельца.
  • C — Consulted. Эксперты и заинтересованные стороны, мнение которых нужно получить до решения или выполнения.
  • I — Informed. Участники, которых нужно держать в курсе. Они получают информацию, но не управляют задачей.
  • S — Supportive. Люди или функции, которые предоставляют ресурс, данные, доступ, помощь или техническую поддержку.

Зачем нужен один владелец результата

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

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

Когда использовать RACIS

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

Инструмент также помогает при разборе конфликтов. Если отделы спорят, кто должен сделать действие, кто принимает результат и кого нужно было предупредить, RACIS переводит спор из эмоций в структуру ролей.

Как составлять диаграмму

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

Пример

ЗадачаРуководитель проектаЭкспертЗакупкиПоддержка
Согласовать требованияAR/CIS
Закупить оборудованиеICA/RS
Настроить системуIAIR
Принять результатACIR

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

Ограничения

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

Инструмент работает только тогда, когда компания готова честно говорить о полномочиях и ответственности.

Вывод

RACIS помогает не тем, что красиво распределяет буквы, а тем, что вытаскивает наружу конфликт ответственности. Кто делает, кто принимает, кто советует, кто получает информацию и кто поддерживает работу — это разные роли.

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

Если ответственность в процессе размыта

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

предварительная проверка процесса
Проверьте процесс на узкое место

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

  • подходит для заявки, заказа, согласования, обработки обращения или внутренней операции;
  • помогает отделить рабочую гипотезу от ощущения, что «где-то не успеваем»;
  • не заменяет разбор процесса с людьми, если проблема в полномочиях, правилах или конфликте подразделений.
Рассчитать процесс Когда нужен разбор с 2П
Расчёт работает только для простого линейного процесса: без ветвлений, возвратов, рабочих календарей и сменных графиков.
контакт
Обсудить управленческую задачу
Напишите 5–7 строк: сфера, масштаб (люди/точки/смены), где теряется управляемость и какой результат нужен. Ответим, с чего начинать и какой формат подойдет.
Email Telegram WhatsApp 
Детали проектов могут быть ограничены договором о конфиденциальности.
2П: операционное управление, процессы и внедрение изменений.

Бизнес-процессы

  • Все статьи
  • Мое мнение
  • Наши статьи
  • Процессы
    • Зачем документировать процессы?
    • Принципы организации процессов
    • Типичные ошибки при описании процесса
    • Стандартные процедуры - зачем?
    • Что такое Инженерная модель?
    • Диаграмма SIPOC
    • Диаграмма RACIS
    • SWOT-анализ
    • Принцип Парето
    • Диаграмма Ишикава
    • Метод 5 Почему
    • Проверка рабочего дня перед внедрением
    • Зачем нужны стандарты ISO/ГОСТ?
    • Карта процесса и Технологическая карта: в чем разница
  • Бережливое производство
  • Управление проектами
@ Сергей Балашов, 2026.