Матрица ответственности в проекте поставки и внедрения

Почему задачи зависают между сторонами

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

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

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

Чаще всего сроки и решения теряются в четырех местах:

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

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

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

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

Кто участвует в проекте и за что отвечает

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

В типовом проекте обычно участвуют пять сторон.

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

Где чаще путают границы

Закупка нередко считает, что после подписания договора ее роль закончена. ИТ может ожидать, что интегратор сам учтет все требования ИБ. ИБ, в свою очередь, часто подключают слишком поздно, когда оборудование уже приехало и сроки уже поджимают.

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

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

Что должна решать матрица ответственности

Матрица ответственности - это простая таблица, в которой заранее записано, кто что делает, кто принимает решение и к кому идти, если работа застопорилась. Ее задача - не дать вопросам "плавать" между закупкой, ИТ, ИБ, интегратором и сервисом.

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

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

Если упростить, матрица должна заранее снять четыре вопроса:

• кто запускает действие
• кто выполняет работу
• кто принимает результат
• кто решает спор или отклонение

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

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

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

Как составить матрицу шаг за шагом

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

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

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

Как распределять роли

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

Удобно идти по такому порядку:

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

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

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

Шаблон для поставки, внедрения и поддержки техники

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

Если вы используете RACI для ИТ-проекта, владельца этапа можно считать ролью A. Исполнители идут как R, согласующие - как C, информируемые - как I. Но даже без полной RACI-таблицы одна строка на этап уже сильно снижает число споров.

Отдельно стоит добавить еще три строки, которые часто забывают, а потом именно они тормозят работу.

Какие строки добавить отдельно

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

Для небольшой команды шаблон можно упростить до трех блоков: заказчик, ИТ/ИБ, подрядчик. Но правило остается тем же: у каждой задачи должен быть один владелец, один понятный результат и один срок эскалации. Иначе даже простая замена рабочего места превращается в длинную цепочку писем.

Пример на реальном сценарии

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

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

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

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

Кто отвечает в момент запуска

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

В первый день работы маршрут инцидентов должен быть максимально простым:

• не включается ПК - сервис или поставщик оборудования
• есть сеть, но нет доступа к системам - ИТ и ИБ
• не установлено нужное ПО - ИТ или интегратор, в зависимости от того, кто готовил образ
• доставили не ту модель или не хватает комплекта - закупка и поставщик
• рабочее место собрано с ошибкой, не подключен монитор или периферия - интегратор

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

Частые ошибки и спорные места

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

Самый частый спор звучит просто: "мы думали, это делает другая сторона". Если у одной задачи несколько "ответственных", по факту ответственного нет. Один согласует, второй участвует, третий ждет письма, а срок уже горит.

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

Первая типовая ошибка - размытая граница между поставкой и вводом в эксплуатацию. Оборудование приехало, документы подписаны, но кто проверяет комплектность, серийные номера, базовую работоспособность и готовность к запуску? Если владелец приемки не назван поименно, техника может неделями стоять на складе.

Вторая ошибка - позднее подключение ИБ. Когда служба безопасности приходит уже после закупки или даже после монтажа, внезапно выясняется, что не согласованы образы, правила доступа, требования к журналированию или сетевые ограничения. Тогда ИТ обвиняет закупку, закупка - интегратора, а проект теряет время.

Третья проблема - сервис вспоминают только после конфликта. До сбоя никто не уточняет, кто принимает обращение, кто делает первичную диагностику, кто меняет комплектующие, а кто подтверждает, что система снова работает нормально. В результате инцидент висит между внутренней ИТ-командой, подрядчиком и сервисной службой.

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

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

Что лучше уточнить заранее

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

• у каждой задачи есть один владелец результата
• приемка и ввод в эксплуатацию разделены и закреплены
• ИБ участвует до закупки и до настройки
• путь инцидента описан от первого обращения до закрытия
• гарантийные и платные работы перечислены отдельно

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

Короткий чек-лист перед стартом проекта

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

Вот минимальный чек-лист, который стоит подтвердить письменно до начала поставки, монтажа и запуска:

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

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

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

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

Что делать дальше, чтобы схема работала

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

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

Что закрепить сразу

После утверждения матрицы полезно провести короткий общий разбор ролей. Обычно хватает 30-40 минут, но на встрече должны быть все ключевые участники: закупка, ИТ, ИБ, интегратор, сервис и, при необходимости, бизнес-заказчик.

На таком разборе лучше проходить не по всем строкам таблицы, а по самым рискованным моментам:

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

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

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

Когда пересматривать схему

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

Для комплексных проектов полезно заранее сверить роли с тем, как реально устроен подрядчик. Если у партнера есть собственное производство, интеграция и сервис, как у GSE.kz, это стоит сразу отразить в матрице по этапам, а не оставлять на уровне общих формулировок.

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