RACI-матрица для модернизации ИТ в госоргане: роли и сроки

Почему в проектах модернизации ИТ появляются «ничейные» задачи

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

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

Чаще всего «ничейными» становятся подготовка исходных данных (планы помещений, перечень рабочих мест, требования ИБ), доступы и окна работ (пропуска, сопровождение, отключения), стыки и границы работ (СКС, сеть, серверная, электропитание), а также протоколы испытаний, акты и исполнительная документация. Отдельная зона риска - устранение замечаний после пилота и перед финальной приемкой: все понимают, что это нужно сделать, но «владелец» не назначен.

Частая ловушка: есть «список ответственных», но он не отвечает на главный вопрос - кто принимает решение и отвечает за результат. Для этого и нужна RACI: она разделяет роли по типу участия. Кто выполняет работу, кто отвечает за итог, кого обязательно консультируют (например, ИБ), а кого просто информируют. Тогда у каждой задачи появляется владелец, а у проекта - понятная логика принятия решений, даже если интегратор (например, GSE.kz) привлекает нескольких подрядчиков.

Участники проекта и где обычно проходят границы ответственности

В модернизации ИТ в госоргане обычно участвуют 4-6 сторон. Проблемы начинаются там, где «между» ними никто не назначен ответственным: кто дает доступ в помещения, кто согласует трассы, кто подтверждает готовность к приемке.

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

Интегратор держит проект «в руках»: план, риски, координацию подрядчиков, общую архитектуру, поставки и пусконаладку. Если интегратор также производит оборудование и ведет поддержку, важно отдельно зафиксировать, где заканчивается поставка и начинается внедрение, обучение и передача в эксплуатацию.

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

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

Чтобы не было «ничейных» зон, заранее проговорите стыки:

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

Простой пример: СКС смонтирована, но серверная не готова по питанию, а ИБ не дала разрешение на подключение к сети. Если у этих пунктов нет владельца в RACI, срок сорвется даже при идеально выполненном монтаже.

Что заносить в RACI: задачи, решения и результаты

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

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

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

Отдельно отметьте задачи со стыками: СКС, доступы в помещения и серверные, согласования с ИБ, окна работ, переключения и откаты. Если стыков нет в матрице, сроки будут срываться «тихо», без явного владельца.

В каждой строке полезно фиксировать:

• результат (документ, акт, настроенный сервис, переданный доступ);
• владельца решения (кто утверждает и отвечает за итог);
• входы и выходы (что нужно получить до старта и что отдать дальше);
• зависимости (от кого ждете и кому передаете);
• критичность решения (что нельзя «повесить на всех»).

Пример: «Окно работ на переключение ядра сети». Заказчик утверждает окно и ограничения, интегратор готовит план переключения и отката, подрядчик по СКС подтверждает готовность линий, ИБ согласует временные правила доступа и журналирование. Если не указать, кто именно закрывает результатом согласованное окно работ, внедрение легко упрется в последнюю ночь перед запуском.

R, A, C, I простыми словами

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

R (Responsible) - исполнитель. Тот, кто реально выполняет работу: пишет ТЗ, тянет кабель, настраивает сервер, готовит акт, собирает документы для согласования. R может быть несколько, если задача большая.

A (Accountable) - владелец результата. Он принимает итог и отвечает за то, чтобы задача была доведена до конца. Главное правило: на одну задачу должен быть один A. Иначе решение зависает между двумя руководителями.

C (Consulted) - те, кого обязательно спрашивают до выполнения. Их требования влияют на способ выполнения. Типичный пример - служба ИБ: если ее не подключить до закупки или настройки, позже появится запрет, переделка и срыв сроков.

I (Informed) - информируемые. Их не спрашивают для решения, но уведомляют по факту или на контрольных точках: руководитель подразделения, бухгалтерия, служба эксплуатации.

Проверка на путаницу:

• R: «Кто делает?»
• A: «Кто принимает и у кого потом спросят?»
• C: «Кого нужно спросить до старта, чтобы не переделывать?»
• I: «Кому важно знать статус?»

Пример: «Подготовить и согласовать схему подключения серверов в новой серверной». R - интегратор (готовит схему), C - служба ИБ и эксплуатация (дают требования), A - руководитель проекта со стороны заказчика (утверждает), I - руководитель департамента (получает статус на контрольной точке).

Как собрать RACI на одном рабочем совещании

Одной встречи на 60-90 минут обычно хватает, чтобы матрица перестала быть «теорией» и стала рабочим инструментом. Важно позвать тех, кто реально принимает решения и делает работу: представителя заказчика (владельца процесса), интегратора, подрядчика по СКС, службу ИБ и эксплуатацию.

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

Удобный порядок обсуждения:

1. Утвердить границы проекта и список результатов по этапам.
2. Пройти задачи сверху вниз и назначить R (кто делает) и A (кто утверждает).
3. Добавить C (кого спрашиваем) и I (кого уведомляем).
4. Отметить задачи, где нужен формальный документ или подпись.
5. Договориться, кто ведет матрицу и как вносятся правки.

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

Зафиксируйте две роли: кто утверждает изменения и кто подписывает акты. Если это не проговорить, любая мелкая корректировка (добавить точку, перенести стойку, поменять окно работ) превращается в спор и съедает сроки ожиданием.

В конце задайте ритм обновления: например, матрицу ведет интегратор и обновляет раз в неделю и после каждого изменения плана работ, а заказчик подтверждает изменения на коротком статусе.

Шаблон распределения ролей по этапам модернизации ИТ

Ниже - простой шаблон, который помогает закрыть типичные «ничейные» зоны в проектах, где участвуют заказчик, интегратор, подрядчики по СКС и служба ИБ. Его удобно взять как основу и дополнять под ваш контур.

Роли (как их назвать в матрице)

Обычно достаточно пяти колонок: Заказчик (владелец результата), ИТ-эксплуатация (будущие пользователи и дежурные), Интегратор (генподрядчик), Подрядчик СКС, Служба ИБ.

Шаблон по этапам (минимум, чтобы не терять задачи)

Чтобы шаблон работал, в каждой строке оставляйте ровно одного A. Если получается два A (например, у ИБ и заказчика на согласовании), разделите задачу на две: «подготовить пакет на согласование» и «утвердить/выдать заключение».

Проверка на реальность: на этапе монтажа отдельно фиксируйте, кто отвечает за окна работ и за допуск людей на объект. Если это не назначено, пусконаладка почти всегда съезжает по срокам.

Пример набора задач для матрицы: СКС, ИБ, сеть, серверы, приемка

Чтобы матрица помогала управлять сроками, в нее важно заносить не «крупные этапы», а проверяемые результаты. Ниже - задачи, на которых чаще всего появляются серые зоны между заказчиком, интегратором, подрядчиком по СКС и службой ИБ.

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

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

Для приемки занесите в матрицу не просто «провести испытания», а конкретику:

• сценарии испытаний и критерии «принято/не принято»;
• состав комиссии и ответственный за протокол;
• кто предоставляет стенд, доступы и тестовые данные;
• кто закрывает замечания и в какие сроки;
• кто подписывает итоговый акт.

Если в проекте есть системный интегратор, отдельной строкой стоит закрепить ведение общего журнала изменений и единую точку сбора вопросов. Это снижает риск, что СКС, сеть, серверы и ИБ «разъедутся» по разным чатам и срокам.

Как закрепить RACI в документах проекта и ежедневной работе

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

Перенос в ТЗ, план-график и приемку

Практичный подход - привязать RACI не к людям, а к ролям, и закрепить роли за результатами, которые можно проверить. В ТЗ и план-графике рядом с работой укажите: кто готовит результат (R), кто утверждает (A), кого обязательно консультируют (C) и кого уведомляют (I).

Обычно достаточно закрепить это в четырех местах:

• ТЗ: для каждого результата (схемы, акты, отчеты, конфигурации) указать A и критерии приемки.
• План-график: у каждой задачи добавить поле «A (утверждает)» и правило эскалации, если срок под угрозой.
• Договоры и приложения: связать ответственность A с этапами и условиями приемки.
• Протоколы приемки: заранее прописать роли и кто имеет право финальной подписи.

Правило то же: «A» должно быть ровно одно. Если утверждают двое, решение зависает.

Управление изменениями и ежедневные коммуникации

Чтобы изменения не размывали сроки, договоритесь о простой схеме: инициатор изменения делает заявку (R), интегратор оценивает влияние на сроки и бюджет (R/C), заказчик утверждает или отклоняет (A), служба ИБ согласует только то, что влияет на риски (C), остальные получают уведомление (I).

По статусам помогает короткий ритм:

• еженедельно: общий статус по этапам, рискам и решениям для A;
• 2-3 раза в неделю: рабочий статус по критическим работам (СКС, сеть, серверы);
• в день блокировки: сообщение «что остановилось, кто A, до какого времени нужно решение»;
• после решения: фиксация в протоколе и обновление план-графика.

Если ИБ требует доработки, а сроки горят, не останавливайте все работы. Разделите поток: задачи, влияющие на безопасность, идут через согласование ИБ, а параллельно выполняются безопасные подготовительные работы (поставка, монтаж без ввода, оформление схем). Компромисс фиксируется как временная мера, а срок закрытия утверждает A.

Частые ошибки: почему задачи теряются и сроки срываются

Срывы по срокам чаще происходят не из-за «плохих исполнителей», а из-за пустот в ответственности. Пока проект идет ровно, их не видно. Они проявляются на согласованиях, тестах и приемке.

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

Вторая боль - службу ИБ подключают поздно. Тогда на финале всплывают требования к сегментации, журналированию, доступам, сертификатам, настройкам домена или СЗИ, и приемка блокируется. ИБ должна быть C на этапе проектирования и быть в курсе изменений, чтобы не узнавать о них в день сдачи.

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

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

Сигналы, что задачи теряются:

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

Проверка перед стартом: есть ли A за тест-план и критерии приемки, за доступы и окна работ, за комплект исполнительной документации, и за финальное «разрешение на ввод» со стороны ИБ.

Короткий чек-лист: как понять, что RACI готова к старту

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

• По каждому результату (документ, акт, настроенная система) есть ровно один A и указан конкретный R.
• Все стыки между СКС, сетью, ИБ и эксплуатацией вынесены отдельными строками (например: «маркировка портов и схемы», «заявки на правила МЭ», «передача доступа в серверную», «окна работ и откат»).
• Для приемки составлен минимальный пакет обязательных документов, и напротив каждого документа стоит, кто готовит, кто согласует и кто подписывает.
• У согласований есть срок и понятная эскалация: что делаем, если C не ответил вовремя.
• Есть правило обновления RACI при изменениях: новый подрядчик, замена ответственных, расширение объема работ, добавление требований ИБ.

Быстрый тест: возьмите 2-3 рискованных места (например, ввод новых серверов, допуск к СКС в режиме действующего здания, согласование с ИБ) и спросите участников, что именно они должны выдать «на выходе» и к какой дате. Если ответы совпадают с матрицей и не содержат «ну, это вроде не наше», можно стартовать.

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

Реалистичный пример: как RACI помогает пройти приемку без «хвостов»

Районное управление модернизирует рабочие места и серверную: меняют ПК, обновляют сеть, ставят новые серверы, наводят порядок в шкафах и маркировке. В середине проекта выясняется, что часть задач «между стульями»: интегратор ждет доступ в серверную, служба ИБ ждет схемы, подрядчик по СКС ждет окно работ, а заказчик думает, что это «уже согласовано».

На рабочей встрече команду просят заполнить RACI не по «ролям в целом», а по конкретным результатам приемки. Для задачи «перенос сервисов на новые серверы» исполнителем (R) назначают интегратора, владельцем результата (A) - руководителя проекта со стороны заказчика, консультируемыми (C) - ИБ и админов, информируемыми (I) - бухгалтерию и пользователей.

Для СКС логика другая: подрядчик по СКС - R за монтаж и тестирование линий, интегратор - C по требованиям к портам и патч-панелям, заказчик - A за предоставление помещений и утверждение точек, ИБ - C по физдоступу и журналам.

Чаще всего «вылезают» пять забытых задач, и именно их стоит явно закрепить в матрице:

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

Договоренности фиксируют в протоколе: по каждой задаче - один A, сроки, входы и выходы, и отдельной строкой «что блокирует старт». После встречи обновляют план работ: добавляют окна, этапы согласований ИБ и контрольную точку «готовность к приемке» с владельцем.

Следующий шаг - короткий воркшоп на 60-90 минут, где назначают владельцев приемки по направлениям (СКС, серверы, рабочие места, ИБ) и подтверждают, какие документы нужны для подписи. При выборе интегратора имеет смысл заранее проверить, кто реально способен закрыть полный цикл: от поставки оборудования до внедрения и поддержки, с понятными границами ответственности и единым управлением изменениями.