В условной компании ИИ уже отвечает на письма, собирает предложения и раскладывает обращения по папкам. На совещании всё выглядит бодро. Потом клиенту уходит неправильная комплектация. Маркетолог говорит, что он только дал описание. Разработчик — что правильно подключил модель. Руководитель продаж — что письмо вообще подготовила нейросеть. В комнате внезапно появляется новый сотрудник: коллективное «мы думали, это проверят».
Матрица RACI распределяет участие в конкретном результате: R выполняет работу, A отвечает за её принятие, C даёт необходимую консультацию, I получает уведомление. Для процесса с ИИ полезно отдельно записать человека, принимающего результат, разрешённое действие системы и условие остановки. Название модели в клетке не заменяет управленческую ответственность.
Четыре буквы, из-за которых приходится договариваться
У RACI довольно скромное устройство: строки — результаты или действия, столбцы — участники, в пересечениях — обозначения участия. В описании Atlassian Responsible выполняет работу, Accountable отвечает за итог, Consulted помогает знаниями, Informed должен знать о происходящем. Для одной строки предлагается один A. Несколько исполнителей возможны, но понятнее делить работу на результаты, которые действительно можно принять.
Путаницу создаёт русский перевод. И R, и A часто называют «ответственным», после чего таблица теряет половину смысла. Я предлагаю прямо писать: «делает» и «принимает результат». Это рабочая формулировка для команды, а не новая международная расшифровка. Если подписант имеет право только переслать документ начальнику, он не становится владельцем решения от красивой буквы.
Представьте подготовку коммерческого предложения. Исполнитель собирает комплектацию из согласованного источника. Принимающий проверяет соответствие задаче и разрешает отправку. Технолог консультирует по совместимости. Финансист получает уведомление о согласованных условиях. Пока это одна строка, легко решить, что принимать нужно весь документ одним движением. Но цена, техническая конфигурация и отсрочка могут иметь разных владельцев. Тогда строку следует разделить.
Именно здесь начинается полезная работа. Не в раскраске клеток, а в обнаружении решения, для которого в компании вообще нет уполномоченного человека. Таблица не выдаёт полномочия сама. Она показывает, где их нужно определить. Никакой Excel пока не научился повышать сотруднику лимит согласования по силе заливки.
В строке нужен принимаемый результат, а не должность
«Маркетинг», «продажи» и «работа с документами» слишком велики для распределения ответственности. Под такой вывеской помещаются исследования, тексты, публикации, бюджетные решения и изменения базы. Если всё поручено одному отделу, конфликт просто переехал из общего чата в общий столбец.
Хорошая строка отвечает на три вопроса: что появится, по каким признакам это можно принять и какое действие разрешено после принятия. Например: «Подготовлен проект письма по обращению с указанием источников; руководитель сервиса проверил предмет ответа; отправка разрешена». В этой формулировке результат отделён от последствия. Человек может одобрить содержание, но запретить автоматическую отправку, пока не проверен адресат.
Для начала достаточно выбрать один процесс с заметными потерями. Подготовка предложения, разбор заявки или выпуск экспертной статьи подойдут лучше, чем попытка описать всю компанию за пятницу. Возьмите несколько недавних завершённых случаев и восстановите реальные переходы. Кто добавил сведения? Кто изменил условия? Кто последним видел документ до внешнего действия? Фактическая цепочка бывает интереснее регламента.
Не нужно превращать каждое нажатие кнопки в отдельную строку. Граница нужна там, где меняется владелец, возникает новая проверка или действие становится трудно отменить. Для черновика и публикации границы разные. Исправленный файл можно пересохранить; разосланное клиентам обещание придётся объяснять. Приёмка ИИ-проекта описывает проверку готового решения; здесь мы распределяем участие внутри повторяющейся работы после запуска.
Почему ИИ не стоит назначать владельцем принятия
В обычной рабочей таблице можно указать ИИ-сервис как инструмент исполнения или отдельную техническую дорожку. Проблема начинается, когда он становится единственным A для решения с последствиями. У системы нет управленческого мандата договориться с клиентом о возврате, принять бюджетный риск или выделить сотруднику время. Даже технически успешное действие может оказаться неподходящим решением для бизнеса.
Я бы сохранял основной RACI между людьми и ролями компании, а рядом показывал автоматизацию: что именно делает агент, какие входы использует и где возвращает результат человеку. Это рекомендация для понятного управления, а не запрет на все другие способы моделирования. Если в вашей нотации система обозначена как исполнитель, легенда должна объяснять, кто поддерживает этот шаг и отвечает при его отказе.
В AI Risk Management Framework NIST управление рисками рассматривается через функции Govern, Map, Measure и Manage. Из этого не следует готовая RACI-таблица для любой компании. Практический вывод для нашего процесса другой: ответственность приходится сопровождать контекстом, измерением и управленческим действием. Одной фамилии рядом со словом «нейросеть» мало.
Например, агент извлекает параметры из письма. Если размеры не указаны, он должен вернуть отсутствие данных, а не подобрать популярный вариант. Человек R уточняет запрос; A решает, достаточно ли информации для предложения. Владелец технической системы исправляет сбой извлечения. Эти обязанности могут принадлежать разным людям. Смешав их, компания получит спор «модель виновата» вместо конкретного восстановления процесса.
Учебная матрица для подготовки предложения
Ниже условный пример для небольшой B2B-команды. Он показывает логику разделения, не отражает устройство клиентского проекта и не обещает готовой интеграции. Имена лучше подставлять после согласования полномочий. Заголовок «руководитель» без назначенного заместителя всё ещё оставляет процесс без человека в отпускной сезон.
| Результат | Менеджер | Руководитель продаж | Технолог | Владелец автоматизации |
|---|---|---|---|---|
| Требования клиента собраны и подтверждены | R | A | C | I |
| Конфигурация проверена на совместимость | C | I | R/A | I |
| Цена взята из действующего источника | R | A | I | C |
| Отправка предложения разрешена | R | A | C при исключении | I |
| Ошибка агента воспроизведена и исправлена | C | A за возвращение процесса | C по предмету | R |
Последняя строка специально неудобная. Руководитель продаж может отвечать за восстановление бизнес-процесса, но не за техническую корректность исправления. Если организация требует отдельного допуска изменения в систему, добавьте самостоятельный результат с техническим принимающим. Не нужно прятать два решения под одним A ради красивой симметрии.
Совмещение R/A допустимо, когда человек вправе выполнить и принять небольшую работу. Но при существенном риске независимая проверка полезнее формального совпадения букв. Её необходимость определяется последствиями и внутренними правилами компании. Подрядчик, который пишет интеграцию, не должен автоматически получить право утверждать коммерческие обещания заказчика.
Условное «C при исключении» нужно раскрыть: например, консультация технолога требуется при нестандартной комплектации. Иначе каждый менеджер по-своему определит нестандартность. Ещё хуже — согласовать исключение устно и оставить в таблице обычный маршрут. На следующей неделе команда будет воспроизводить старую инструкцию с новым чувством уверенности.
Рядом с RACI нужна карточка решения
Матрица компактна, поэтому в ней не помещается вся инструкция. Попытка вписать туда сроки, права, источники, исключения и двадцать сносок заканчивается настенной газетой. Полезнее связать строку с короткой карточкой решения. В ней остаются условия, по которым назначенный человек действительно может действовать.
- Вход: какие сведения и из какого источника доступны к началу работы.
- Результат: что именно получает следующий участник, в каком формате и с какой версией.
- Критерий: какие проверки отличают готовый материал от убедительного черновика.
- Полномочие: что можно изменить самостоятельно и что требует отдельного решения.
- Остановка: при каких пропусках, противоречиях или сбоях действие не выполняется.
- Замещение: кто принимает работу, если основной участник недоступен.
- След: где сохраняются решение, причина и использованные материалы.
Допустим, агент подготовил скидку на основании старой переписки. RACI говорит, кому проверять предложение, но не объясняет, какая скидка сейчас разрешена. Карточка должна указывать действующий источник условий и маршрут исключения. Принятие результата нельзя подменить общим «выглядит нормально». Нормально для кого: для клиента, маржи или демоверсии?
Роли в ИИ-команде удобны как способ распределить специализацию: исследовать, писать, проверять, разрабатывать. На странице Везории — ИИ-команды можно обсудить такую конфигурацию под задачу. Наличие роли в описании само по себе не означает, что подключены ваши данные, права и маршруты согласования. Эти условия нужно проверить отдельно. RACI как раз помогает не перепутать специализацию агента с полномочием сотрудника.
Как не собрать комитет по каждой запятой
После первого инцидента организация часто выбирает понятную защиту: пусть всё проверяют все. Число C растёт, время решения увеличивается, а фактическая ответственность снова растворяется. Когда документ посмотрели семь человек, каждый уверен, что настоящий специалист был среди остальных шести.
Консультант нужен из-за конкретного знания. Юрист проверяет определённый договорный вопрос, технолог — совместимость, редактор — точность спорного утверждения. Если вы не можете сформулировать вопрос человеку C, возможно, ему достаточно уведомления I. Уведомление при этом должно быть удобным: краткий итог, ссылка на решение и понятное основание для вмешательства. Поток всех промежуточных версий быстро превращается в цифровой фон.
В практике обсуждения ролей Atlassian участникам предлагают сопоставлять собственное понимание обязанностей с ожиданиями команды. Это полезная отправная точка: сотрудник может искренне считать свою работу консультацией, пока коллеги ждут от него финального решения. Такой конфликт следует обнаруживать до автоматизации, иначе агент начнёт аккуратно ускорять передачу неопределённости.
Срок консультации и реакция на молчание задаются отдельно. Для обратимой внутренней правки команда может разрешить продолжение после установленного окна. Для цены, безопасности или внешнего обязательства отсутствие ответа не стоит автоматически считать согласием. Универсальное правило «не ответил — одобрил» удобно только тому, кто составлял регламент и сейчас в отпуске.
Вместо одинакового маршрута на все случаи введите классы результата. Типовой черновик, публикация с новым фактическим утверждением и нестандартное предложение клиенту могут требовать разных участников. Это уменьшает лишние согласования без отмены значимых проверок. Упрощение должно иметь объяснимое основание, а не зависеть от того, насколько срочно попросил самый громкий коллега.
Буква A тоже занимает рабочее время
Распределение ответственности не создаёт мощность. Если один руководитель принимает все письма, тексты, предложения и изменения системы, таблица просто легализует очередь к его кабинету. Агент сгенерирует больше черновиков, а ожидание принятия станет длиннее. На презентации это выглядит как рост производительности. В работе — как новая папка непрочитанного.
Посчитаем условный пример. На проверку одного результата уходит восемь минут, в день поступает тридцать результатов. Это 240 минут, то есть четыре часа чистой проверки без переключений и обсуждений. Если у принимающего на такую работу есть полтора часа, проблема не лечится напоминаниями. Нужны другой объём, делегирование типовых решений или более подготовленный вход. Эти числа иллюстративные; измерять следует свою выборку и учитывать неоднородность задач.
Полезно различать очередь проверки и очередь исправлений. Если всё ждёт A, узкое место может быть в доступной мощности. Если A быстро возвращает большинство результатов, вероятнее проблема входа, критериев или исполнения. Среднее время прохождения без такого разделения прячет причину. В обоих случаях календарь грустит одинаково, но действия нужны разные.
Делегирование следует сопровождать границами: какие классы решения передаются, какой лимит действует, когда нужна эскалация и как проверяются выборочные результаты. Передать букву без права распоряжаться ресурсом — значит назначить человека отвечать за чужое ожидание. Матрица должна соответствовать полномочиям, а не подменять их.
Проверяйте матрицу неудобными ситуациями
Первую версию стоит прогнать не на идеальном сценарии, а на нескольких отклонениях. Основной принимающий недоступен. Источник цены не отвечает. Два документа противоречат друг другу. Клиент просит то, что система не умеет. Исполнитель считает задачу готовой, следующий отдел не принимает результат. Кто делает следующий шаг в каждом случае?
Это настольная репетиция, для неё не нужно отправлять реальные письма и менять клиентскую базу. Участники получают условную карточку ситуации и показывают маршрут по действующим документам. Если решение каждый раз появляется только после вмешательства собственника, у процесса есть скрытый A. Его либо нужно честно указать, либо действительно передать полномочие.
Отдельно проверьте отказ автоматизации. Ручной резерв должен описывать минимально допустимый результат и способ вернуться в обычную работу без повторного действия. Иначе после восстановления агент обработает то, что сотрудник уже сделал вручную. Техническая защита от повторов — самостоятельная инженерная задача; в матрице важно назначить владельца решения о переключении и сверке.
Репетиция полезна и для подрядчиков. Кто сообщает о сбое, кто оценивает влияние, кто вправе остановить автоматическую отправку, кто согласует возврат? Фраза «поддержка разберётся» не содержит ни результата, ни полномочий. Связать роли с реальным действием лучше до того, как клиент принесёт первый убедительный контрпример.
Как внедрить RACI без месяца организационного театра
Мой вариант старта — небольшой управленческий эксперимент. Выберите один процесс, восстановите несколько недавних случаев и выпишите спорные переходы. Согласуйте принимаемые результаты, затем назначьте R и A. После этого добавьте только необходимые консультации и уведомления. Не начинайте с огромного списка всех сотрудников: он провоцирует заполнить таблицу участием ради участия.
Первые рабочие случаи наблюдайте вручную. Отмечайте, где результат вернули без понятной причины, где ждали отсутствующего участника, где решение приняли вне согласованных прав. Исправляйте правило, а не только конкретную карточку. У матрицы должны быть версия, дата действия и владелец обновления. Документ без процедуры изменения быстро начинает описывать компанию, которая уже переехала.
Для оценки полезны доля результатов с назначенным принимающим, время ожидания принятия, число возвратов из-за неясного критерия и число незапланированных эскалаций. Не надо обещать снижение всех показателей одновременно: после наведения порядка зарегистрированных проблем может стать больше, потому что раньше их не считали. Сравнивайте одинаковые типы работы и отдельно смотрите последствия ошибок.
Если процесс прост, работает один человек и внешние обязательства не меняются автоматически, полноценная RACI может не понадобиться. Достаточно короткой договорённости о результате и проверке. Инструмент оправдан там, где между людьми теряются решения. Цель — сделать передачу работы понятной, а не вырастить ещё один документ, который все подписали и никто не открывает.
При обсуждении разработки и интеграций такую матрицу удобно использовать как часть постановки: какие шаги автоматизируются, кто принимает выход и кто разрешает последствия. Это даёт разработчику проверяемые границы. Самая полезная строка в начале проекта иногда выглядит скучно: «При противоречии в исходных данных письмо не отправляется, решение получает назначенный человек». Именно она и спасает красивую автоматизацию от некрасивого утра.