Матрица ответственности показывает распределение полномочий между участниками бизнес процесса

Матрица распределения ответственности (матрица RACI) – это инструмент, который помогает определить, как распределяются роли и задачи участников проекта. 

RAСI — аббревиатура, сформированная по первым буквам названий ролей в проекте:
Responsible (Исполнитель) – сотрудник, на котором лежит ответственность за выполнение задачи. Он определяет конкретные шаги, составляет список ресурсов, анализирует ход выполнения работ и предоставляет отчет о результатах.
Accountable (Ответственный) – руководитель проекта, который принимает (или отвергает) итоговую работу и несет за нее ответственность, выбирает команду исполнителей, контролирует ход работы над проектом, рассматривает идеи и предложения членов команды.
Consult before doing (Консультант) – тот, кто консультирует участников проекта во время выполнения задач и согласовывает принимаемые решения. Обычно эта роль достается руководителям высшего звена, которые решают стратегические вопросы и определяют глобальные цели проекта.
Inform after doing (Наблюдатель) – тот, кто знает о решениях по проекту и о ходе выполнения задач, но никак не влияет на рабочий процесс. Выполняет функции администратора, занимается документооборотом и не несет ответственности за результат проекта, в отличие от других участников.

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

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

Пример матрицы RACI

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

Аннотация: Определение ролей проекта. Матрица ответственности проекта. Построение матрицы ответственности. Закрепление функций и полномочий в проекте. Реестры навыков.

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

Определение ролей проекта

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

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

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

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

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

Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.

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

Ключевые роли со стороны исполнителя — руководитель проекта (менеджер проекта) со стороны исполнителя и бизнес-менеджер.

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

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

В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].

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

Состав команды управления должен быть достаточным, чтобы осуществлять [11]:

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

В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролей исполнителей, характерных для IT-проектов: функциональный архитектор, функциональный консультант, разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик. В проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается в небольших проектах, что позволяет снизить накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика.

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

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

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

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

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

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

Для отражения иерархии подотчетности на проекте и указания обязанностей каждой из групп, входящих в проектную команду, в документ описания содержания проекта рекомендуется включить матрицу ответственности, наиболее распространенный вариант которой известен как RACI-матрица. Использование данного инструмента особенно актуально в ситуации, когда проектная команда состоит из представителей различных юридических лиц (например, типичная команда на проекте внедрения КИС включает в себя сотрудников заказчика, генерального подрядчика и субподрядчиков). Матрица ответственности решает задачу демонстрации межорганизационного или межгруппового взаимодействия и, как следствие, позволяет избежать недоразумений, которые время от времени возникают в проектах между подразделениями и организациями из-за неясности, к кому следует обращаться по тем или иным вопросам и кто должен принимать по ним решение, а кто — непосредственно реализовать принятую резолюцию.

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

Построение матрицы ответственности

  1. Перечислить основные работы проекта.

    По вертикали в матрице отражаются только основные работы проекта (не ниже уровня 2-3 ИСР), но с достаточной степенью детализации для обеспечения возможности указывать разные роли, необходимые для выполнения этих работ. Когда речь идет о крупных проектах и программах, может возникнуть необходимость разработать несколько матриц ответственности с различной степенью детализации.

  2. Перечислить группы/роли внутри проектной команды.

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

  3. Закодировать матрицу ответственности.

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

    Таблица
    6.1.
    Условные обозначения матрицы ответственности (RACI)

    Обозначение Расшифровка Описание
    Исп. (R) Исполнитель (Responsible) Несет ответственность за непосредственное исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя
    Утв. (A) Утверждающий (Accountable) Отвечает за конечный результат перед вышестоящим руководством. На каждую работу должен быть назначен строго один подотчетный
    Cогл. (C) Согласующий (Consulted) Согласует принимаемые решения, взаимодействие с ним носит двусторонний характер
    Н. (I) Наблюдатель (Informed) Его информируют об уже принятом решении, взаимодействие с ним носит односторонний характер

    Таблица
    6.2.
    Распределение функциональных обязанностей команды управления проектом

    Функциональные обязанности Куратор проекта (Спонсор) Руководитель проекта Архитектор системы Администратор проекта
    Планирование
    Разработка и периодическая актуализация плана + +
    Утверждение плана +
    Управление командой проекта
    Назначение сотрудника на роль Руководителя проекта +
    Формирование команды проекта +
    Определение квалификационных требова ний и состава рабочих групп специалистов по функциональности ИС +
    Обеспечение выделения необходимых ресурсов для выполнения проекта +
    Непосредственное руководство Командой проекта +
    Формирование предложений по стимулированию Команды проекта +
    Обеспечение стимулирования Команды проекта +
    Организация выполнения работ
    Организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта +
    Организация подготовки, согласования и утверждения всей технической документации, необходимой для создания ИС в рамках проекта +
    Организация, проведение и документирование процедур передачи Заказчику разработанной ИС + +
    Рассмотрение и утверждение регламентирующих документов, необходимых для организации и выполнения проекта +
    Ведение организационно-распорядительной и отчетной документации. Поддержание в актуальном состоянии списка команды проекта +
    Обеспечение команды проекта необходимыми информационными материалами +
    Материально-техническое и хозяйственное обеспечение команды проекта +
    Контроль хода выполнения проекта
    Организация и проведение совещаний по обсуждению хода работ проекта +
    Подготовка и предоставление Куратору отчетов о ходе работ проекта +
    Получение и анализ сводной отчетности о ходе реализации проекта +
    Контроль соответствия результатов проекта Техническому заданию на разработку ИС +
    Согласование фактических трудозатрат специалистов при исполнении проекта + +

    На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов.

  4. Инициировать использование матрицы и включить процедуру использования матрицы ответственности в документ «План управления проектом«.

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

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

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

Справка по системе
Платформа ELMA BPM

×


Поиск

Поиск





Поиск




  •  Предыдущая
  • Следующая 

  (c) Company name, 2016Copyright © 2006–2021 ELMA

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

На рис. 1 приведен пример отображения вкладки «Матрица ответственности».

Рис. 1. Матрица ответственности процесса

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

Флажками можно обозначить роли исполнителей:

  • Владелец — сотрудник, полностью отвечающий за весь процесс. Это означает, что владелец несет ответственность не только за результат, то есть продукт процесса, но также за ход его выполнения и удовлетворенность клиентов бизнес-процесса. Владелец может быть выбран из исполнителей зон ответственности процесса или добавлен вручную из оргструктуры. В качестве владельца процесса могут быть выбраны следующие элементы оргструктуры: должность или группа сотрудников. У процесса может быть только один владелец (один сотрудник или одна группа сотрудников).

  • Участник — исполнитель одной из зон ответственности. Участники процесса видят экземпляры этого процесса в разделе Мои процессы в веб-приложении. Эта роль назначается по умолчанию всем исполнителям зон ответственности.

  • Информируется — сотрудник, информируемый о ходе процесса организационными мерами. Такой сотрудник не взаимодействует с процессом в системе ELMA, однако информация о нем попадает в документацию по процессу и регламент процесса.

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

Кроме ролей, назначаемых в матрице ответственности, пользователям автоматически назначаются роли в веб-приложении:

  • Инициатор — пользователь, запустивший экземпляр бизнес-процесса.

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

Контекстное меню матрицы ответственности

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

Рис. 2. Вкладка «Матрица ответственности» карточки процесса. Контекстное меню списка исполнителей

Контекстное меню содержит следующие элементы:

  • Добавить — позволяет добавить нового участника процесса. В открывшемся диалоговом окне необходимо выбрать элемент оргструктуры (рис. 3).

  • Удалить — позволяет удалить добавленного вручную участника процесса. Данный пункт меню недоступен для участников процесса, добавленных в список по умолчанию.

Рис. 3. Вкладка «Матрица ответственности» карточки процесса. Окно выбора исполнителя

Верхняя панель инструментов

Верхняя панель инструментов вкладки Матрица ответственности карточки процесса состоит из общих блоков, находящиеся на любой из вкладок процесса и блоков, присущих определенной вкладке.

Блок «Действия вкладки Матрица ответственности»

Позволяет добавить нового участника процесса. В открывшемся диалоговом окне необходимо выбрать элемент оргструктуры (рис. 3).

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


См. также:

Дата публикации: 28 февраля 2023

Время чтения: 4 минуты

Распределение ролей в команде, или Зачем нужна матрица ответственности

Поговорим о матрице ответственности: как этот инструмент помогает упростить управление проектами и что учесть в процессе работы.

В рамках спецпроекта «Горячая линия» нам поступил вопрос от читателя: «Как управлять проектами, всё выполнять в срок, не теряя при этом задачи? Как распределить полномочия, роли в команде и контролировать сотрудников?»

На вопрос ответила Екатерина Здесенкова, исполнительный директор iConText Group. Привет. Спасибо за вопрос. Существует достаточно большое количество инструментов управления задачами, распределения ролей в команде и способов контроля результатов. Но есть один, который я настоятельно рекомендую попробовать, он будет уместен практически в любой ситуации.

Причём не важно, какую именно методику управления вы в итоге выберете. Этот инструмент — матрица ответственности.

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

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

Существует два подхода к определению владельца:

  1. Кто отвечает за большее количество вопросов, тот и владелец;
  2. Кто самый заинтересованный, тот и владелец.

Звучит сложно и непонятно? Сейчас во всём разберёмся. На самом деле всё проще, чем кажется.

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

Первое, что важно сделать, — определить всех участников процесса. Например, в нашем случае это будут:

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

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

  1. Получение заявки в CRM.
  2. Проведение первичного скоринга заявки специалистом отдела продаж.
  3. Поиск потенциальной команды на стороне агентства.
  4. Брифинг клиента.
  5. Принятие решения о работе.

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

Теперь всё готово, чтобы начать рисовать матрицу ответственности. Она будет выглядеть так:

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

У меня получилось вот так:

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

  1. Кто отвечает за большее количество вопросов, тот и владелец;
  2. Кто самый заинтересованный, тот и владелец.

В данном случае «Владелец процесса» — отдел продаж.

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

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

Хотите задать вопрос экспертам iConText Group?

Как подготовить и провести классное мероприятие? Гайд для ивент-менеджера

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

Одна статья в Forbes или 10 на малоизвестных площадках: как оценить работу пиарщика

Какой KPI поставить PR-специалисту, чтобы оценивать эффективность его работы? Рассказала Юлия Шелыгина, директор по маркетинговым коммуникациям iConText Group.

Гостевые статьи: где искать внешних авторов и какой формат контента выбрать?

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

Будьте в курсе новостей от компаний группы

Понравилась статья? Поделить с друзьями:

Другие крутые статьи на нашем сайте:

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии