Матрица ответственности в управлении IТ- проектами

В настоящее время используются много разновидностей матрицы ответственности. Они могут отличаться друг от друга по уровню детализации работ (функций, процессов) и структурных единиц. Например, на этапе разработки концепции проекта бывает вполне достаточно использовать матрицу ответственности, в которой весь проект представлен в виде укрупненных комплексов работ, соответствующих модели жизненного цикла проекта [4]. Множество разновидностей матрицы ответственности образуется по причине использования различных символов, обозначающих степень ответственности или характер участия структурной единицы в выполнении работы.

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

На практике используют также [5]:

RASCI = RACI+S.«S» означает Support «Поддерживает»;

RACIO = RACI+О. «O» означает Out of the Loop «Вне цикла» или «не участвует»

RACI-VS = RACI+VS. «V» означает, что Verify «проверяет» и «S» означает Signatory «Подписывает».

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

1. Перечислите действия (задачи), которые должны быть выполнены на одной стороне таблицы.

2. Перечислите всех участников процесса (заинтересованные стороны) на другой стороне таблицы.

3 Заполните сетку буквами, R, A, C, I. отвечающими роли каждого частника. Конец процесса, матрица готова.

Заметим, что матрица ответственности может применяться не только в управлении проектами, но и в других сферах [6]:

ѕ В процессном управлении, там ее называют матрицей ответственности по бизнес-процессу.

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

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

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

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

Существует практика использования матрицы ответственности не только для отображения системы ответственности, но и для отображения информационно-технологических связей между отдельными участниками выполнения работы. Однако матрица ответственности не имеет полноценных возможностей для отображения сложных информационно-технологических связей между отдельными операциями, так как ее основное назначение -- наглядно представить систему ответственности. Для соединенного представления информационно-технологических связей между операциями и ответственности за их выполнение целесообразно использовать другие модели и инструменты [7].

2. МАТРИЦА ОТВЕТСТВЕННОСТИ В УПРАВЛЕНИИ ИТ-ПРОЕКТАМИ

В руководстве PMBOK (пятое издание) матрица ответственности имеет также иные обозначения: «матричные диаграммы», «матрица RAСI» (Рисунок 1) [3]. В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ [7].

Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing).

Рисунок 1 - Пример матрицы RACI из Руководства PMBOK

В зависимости от масштаба проекта PMBOK допускает использование МО на различных уровнях с разной степенью проработки ответственности членов рабочей группы. Если мы рассматриваем МО высокого уровня, то для построения матрицы привлекаются группы и подразделения команды с одной стороны и крупные компоненты ИСР - с другой. Напротив, МО низкого уровня «спускаются» до детализации распределения ответственности конкретных участников команд вплоть до уровня операций.

Построить RACI матрицу несложно, все, что нужно, это [6]:

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

ѕ Определить и выписать по горизонтали все роли или конкретных людей.

ѕ Проставить “А” для каждой задачи. Этот пункт, кстати, здорово прочищает мозги, так как сказать, “кто будет делать - легко”, а вот “за кем будет последнее слово” - уже сложнее.

ѕ Проставить “R” для каждой задачи.

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

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

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

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

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

2.2 Особенности применения матрицы ответственности в управлении ИТ проектами

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

Рассматривая проектную деятельность в области информационных технологий, можно отметить, что процессы реализации, принятые в методологии PMBOK, протекают неравномерно и конечный результат зачастую может значительно отличаться от первоначально запланированного, что в свою очередь повышает степень неопределенности ИТ-проектов. Основные причины, почему методология PMBOK в исходном виде не подходит для реализации проектов в сфере информационных технологий [8]:

1. Требования заказчика изменяются по ходу реализации проекта

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

3. Разработка программного обеспечения по своей природе является процессом итерационным, завязанным на повторяющихся операциях.

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

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

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

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

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

Рассматривая проектную деятельность в области информационных технологий, можно отметить, что процессы реализации, принятые в методологии PMBOK, протекают неравномерно и конечный результат зачастую может значительно отличаться от первоначально запланированного, что в свою очередь повышает степень неопределенности ИТ-проектов [10].

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Stufref, [Электронный ресурс], Дата обращения к ресурсу: 13.02.2023г., Режим доступа:

https://studref.com/367108/sotsiologiya/korrektiruyuschie_deystviya ,

2. ИНТУИТ [Электронный ресурс], Дата обращения к ресурсу: 13.02.2023г., Режим доступа:

https://intuit.ru/studies/courses/646/502/lecture/11398.

3. Гордон, Уэбстер Планирование и управление проектами для менеджеров / Уэбстер Гордон. - М.: Дело и сервис (ДиС), 2019. - 738 c

4. Грекул В. И., Коровкина Н. Л., Куприянов Ю. В. Методические основы управления ИТ-проектами. - Интернет-университет информационных технологий, 2019. - 392 с.

5. Локк, Дэннис Основы управления проектами / Дэннис Локк. - М.: Гиппо, 2019. - 242 c.

6. Мороз, О.А. Управление проектами в ProjectLibre / О.А. Мороз. - Рн/Д: Феникс, 2018. - 384 c.

7. Кремлев, В.С. Ковшов. - М.: Инфра-М, 2020. - 320 c.

Размещено на Allbest.ru