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

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

Что такое RACI

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

Название инструмента представляет собой аббревиатуру из первых букв основных обязанностей участников:

  • Responsible (исполняет) — так обозначают непосредственного исполнителя работы.
  • Accountable (подотчётный) — обозначение того, кто несёт ответственность за результаты работы исполнителя.
  • Consulted (консультирует) — так обозначают специалистов, оказывающих услуги консультаций в процессе выполнения работы.
  • Informed ( информирует) — используется в случае необходимости информирования о результатах работы конкретного специалиста или роли.

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

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

Для RACI-матрицы существуют ограничения: для каждого процесса матрица должна содержать минимум одного Исполнителя и одного Ответственного.

Стоит отметить, что допускается, хотя и строго не рекомендуется:

  • Совмещение ответственностей Исполнителя и Ответственного. В этом случае важно подробно описать процесс валидации результатов.
  • Наличие более чем одного Исполнителя в одном процессе. Здесь нужно чётко описать, какая работа и как должна выполняться каждым Исполнителем.

Собираем RACI-матрицу для Scrum-команды

1. Определяем процессы

Предположим, что наша Scrum-команда так или иначе пересекается со следующими процессами:

  • Формирование роадмапа
  • Формирование бэклога спринта
  • Декомпозиция задач
  • Тестирование задач
  • Аналитика
  • Выпуск релиза
  • Разработка
  • Фасилитация мероприятий

2. Определяем роли

Наша Scrum-команда представлена следующими специалистами: 2 senior-разработчика, 2 middle-разработчика, 1 бизнес-аналитик, 1 scrum-мастер, 1 product owner, 2 специалиста по тестированию. Исходя из этого можно попробовать получить роли внутри команды:

  • Разработчик
  • QA специалист
  • Аналитик
  • Scrum master
  • Product owner

3. Делаем черновик RACI-матрицы для представленных ролей и процессов

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

4. Исправляем недочёты и принимаем ограничения

Большое количество AR

В нашей команде есть домены, которые являются и Исполнителями и Ответственными за процесс. Считаем это недочётом.

Как исправить: использовать существующую или описать новую схему валидации. Как правило, для большинства процессов схемы валидации уже будут. Так, для процесса «Аналитика» валидно, если есть объём задач на спринт, а для процессов «Разработка» и «Тестирование» есть готовый механизм Sprint Review и т.д. Для процессов, которые команда не может отвалидировать (например «Формирование Roadmap»), можно построить матрицу ответственности для Product Owner, его руководителя и стейкхолдеров.

Много ролей в одном процессе участвуют как консультанты

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

Как исправить: например, вести внутреннюю документацию и использовать её как основной источник информации.

Когда стоит считать схему правильной?

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

Когда эта схема может быть полезна?

При формировании бизнес-процессов внутри предприятия. Она на это и рассчитана.

Если мы говорим про вышеописанный кейс применения, то можно использовать RACI как один из артефактов Kick-off встречи или как один из инструментов онбординга сотрудника в команду.

Когда мы говорим про трансформацию процессов, RACI может быть полезна в качестве инструмента формализации как as-is так и to-be.

Читайте также:  Стандарт babok бизнес это

Заключение

RACI — отличный инструмент усиления бюрократии в её хорошем смысле. Но возможно она вам будет нужна только для определения вертикальных взаимодействий.

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

Используйте RACI matrix как и любой другой инструмент: тщательно взвесив все «за» и «против». Пробуйте, масштабируйте и не бойтесь отказываться от технологии, если замечаете, что её внедрение приносит больше проблем, чем пользы.

Источник: slowkazak.medium.com

«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица

Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул.

Настолки состоялись.

Недавно я снова заглянула в гости. Стикеры на холодильнике висят, а Маша и Саша опять ссорятся. Точнее, громко выясняют, кто хотел починить стол / вывести холодильник / искупать кота, кто по-факту должен был это делать, и почему до сих пор ничего не сделано. Я промолчала, т.к. в чужие семейные разборки со своим PMBOK-ом не лезут.

Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:

Простите. Не могу промолчать. Не надо так.

Общая суть

Есть в проектном менеджменте такой инструмент — RACI матрица PMBOK Guide (9.1.2.1 Organization Charts and Position Descriptions, Matrix-based charts)

RACI — это аббревиатура:

R — Responsible
A — Accountable
C — Consulted
I — Informed

И вокруг этой матрицы есть путаница. Responsible и Accountable можно перевести на русский язык одинаково — ответственный, иногда это можно использовать как синонимы, но не в RACI matrix. В матрице ответственности между Responsible и Accountable семантическая пропасть, вот вам мостик через неё.

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

Responsible — тот, кто будет выполнять этап, прям физически, к примеру, Вася делает кликабельный прототип приложения. Он Responsible за этап проекта «прототипирование».

Accountable — тот кто апрувит результат и отвечает за него. В некоторых вариациях звучит как Authorize. В зависимости от команды, это может быть менеджер Васи, может быть старший дизайнер Васи, а если в команде 2,5 человека, то это может быть и сам Вася. Но такая практика сгодится только для супер-маленьких команд, не надо к ней прилипать.

Informed и Consulted тоже кажутся близки по смыслу. Основное отличие в том, что у C двусторонняя коммуникация в проекте, а у I — односторонняя. C может влиять на проект, а I — нет.

Я нашла в сети еще объяснения RACI матрицы, на бытовых примерах из жизни:

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

Рекомендации по составлению матрицы

Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.

  1. В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
  2. Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта.
  3. Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
  4. В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
  5. Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней.
  6. Лучше устанавливать A и R на минимальный соответствующий уровень.
  7. Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
  8. Сведите к минимум позиции I и С.
  9. Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
  10. RACI матрицу иногда приходится обновлять по ходу проекта, т.к. она может устареть.
Читайте также:  Самый дорогой бизнес центр в Санкт Петербурге

Проверка матрицы

Проверяют матрицу по двум направлениям: по вертикали и по горизонтали. Вот чек-лист, как проверить свою RACI матрицу на вшивость.

Вертикальная (по ролям)

Т.е. оценивается насколько сбалансированы роли в проекте

Слишком много R

Проверочный вопрос: «Вывезет человек на этой роли так много задач?»

Нет пустых мест

Проверочный вопрос: «Человеку в этой роли действительно необходимо участвовать во всех этапах проекта?»

Слишком много A

Проверочный вопрос: «Можно ли снизить количество процессов, в которых человек в этой роли принимает решение и отчитывается за них?»

Нет R или A

Проверочный вопрос: «Это нужная роль? Можно ли перераспределить часть ответственности на другие роли или передать часть ответственности с других ролей на эту?»

Двойные позиции A/R, или A/I

A/R, A/C, R/C — возможная картина для очень маленькой компании, но лучше избегать.
A/I, R/I, C/I- свидетельствует о непонимании RACI матрицы как инструмента.

Общая картина

Проверочный вопрос: «Соответствует ли количество ответственности на проверяемой роли уровню подготовки человека / его вовлеченности в проект?

Горизонтальная (по этапам)

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

Нет R

Нет исполнителя данного этапа. Проверочный вопрос: «Кто будет это делать?»

Слишком много R

Работа может замедлиться. Проверочный вопрос: «Можно ли разбить этап на более конкретные задачи, чтобы снизить количество исполнителей в этапе?»

Нет A

Нет ответственных, нет выполненной работы. Проверочный вопрос: «У кого есть полномочия из участников проекта, чтобы принять окончательное решение и иметь дело с последствиями данного этапа?» Т.е. кто отдает команду в каком направлении атаковать, и кому снесут голову с плеч, если направление оказалось неверным.

Больше, чем одна A

Первое правило RACI матрицы — только одна А для каждого этапа проекта.

Все ячейки заполнены на каждом этапе

Проверочный вопрос: «Действительно ли нужны все участники проекта на каждом этапе? Есть при преимущества от их участия?»

Нет C/I

Возможно вы кого-то забыли. Проверочный вопрос: «Вы учли всех участников проекта? Коммуникация между «отделами» налажена? Могут ли отделы начать выполнять какой-то этап параллельно или без учета последних изменений? »

Слишком много C

Замедляет проект. Проверочные вопросы: «Действительно нужно консультироваться со всеми C? Затраты часов на эти консультации окупаются? Можно просто проинформировать эти роли?»

Слишком много I

Проверочные вопросы: «Приносит ли это информирование пользу проекту? Или просто создает лишние созвоны и совещания? Можно информировать людей на этих ролях только в исключительных обстоятельствах? Можно ли отказаться от информирования людей на этих ролях?»

Много двойных позиций

Да, в маленькой команде могут возникать «двойные позиции», к примеру, когда на одном и том этапе один человек и выполняет задачу R и принимает по ней конечное решение A. Но такая формулировка может показывать непонимание матрицы, задач, команды, ответственности.

Непоняточки

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

RACI матрица не регулирует, кто будет планировать этап. С другой стороны, это гибкость, можно менять условия под свою команду/проект.

Читайте также:  Виды деятельности бизнеса список

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

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

Ошибки из примера

А теперь, с чек-листом, я проведу проверку шуточной матрицы из интернетов, из-за которой я начала писать:

Горизонтальная проверка (по этапам)

− Подготовить машину.

Нет R (исполнителя), того, кто будет это делать: пойдет выгонять машину из гаража, проверять масло и т.д.

+ Купить еду.

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

± Взять игрушки.

Если речь идет о детских игрушках (в такой маленькой команде, как семья), скорее всего сыну пришлось бы взять на себя и A и R. Вряд ли папа смог бы его проконсультировать о том, какие игрушки сын любит. И вряд ли семья вызвала бы маму на ковёр, если бы сын поехал без игрушек.

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

+ Взять одежду.

Все окей: мама скомандовала всем взять теплые кофты, все взяли теплые кофты. Все в порядке.

− Взять алкоголь

Та же ошибка, что и с подготовкой машины, нет R. Непонятно, кто побежит в магазин за пивом. Да и польза этапа для всего проекта сомнительная. Убираем этот этап.

+ Замариновать шашлык

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

+ Взять рассаду

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

− Взять инструмент

Опять нет R, кто этим будет заниматься — непонятно.

− Оценить погоду

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

Итого, 4 или 5 из 9 этапов требуют корректировки.

Вертикальная проверка (по ролям)

Участвует абсолютно в каждом этапе проекта. При горизонтальной проверке, на этапе «Подготовить машину» нет R. Папа — единственный компетентный член семьи, так что ему придется совмещать A и R. Вероятно, эта роль перегружена, и надо перераспределить часть задач на других членов команды.

В целом роль выглядит сбалансированной, но т.к. в ходе горизонтальной проверки, мы нашли этапы, на которых нет R (исполнителей), Мама может стать R на этапе «Оценить погоду». Если мама маленькая и хрупкая (некомпетентная), то она не сможет стать R на этапе «Взять инструмент», но обычно мама знает, где что лежит, так что может выступить C (консультантом).

В целом роль выглядит сбалансированной. Если сын большой и сильный мальчик, то на этапе «Взять инструмент», может стать R (исполнителем).

В целом роль выглядит сбалансированной, я бы даже сказала ненапряжной. На этапе «Подготовить машину», Бабушку решили не информировать. Она может сорвать сроки по проекту «Поездка на дачу», т.к. не будет знать, что пора искать очки и начинать спуск по лестнице. Добавим Бабушке I на этапе «Подготовить машину», чтобы она успела подготовиться.

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

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

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

  • RACI matrix
  • RACI матрица
  • матрица ответственности
  • проектный менеджмент
  • управление проектами
  • управление командой
  • планирование
  • распределение ответственности

Источник: habr.com

Рейтинг
( Пока оценок нет )
Загрузка ...
Бизнес для женщин