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

Обновлено: 07.07.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс согласования в 1С: Документооборот

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

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

Отличие электронного от бумажного согласования

Сравнение типичной ситуации согласования договора наглядно показывает различие двух способов решения задачи.

Согласование документов вручную

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

Электронный вариант согласования документов

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

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

Сначала создается группа доступа всех пользователей, имеющих право участия в процедурах согласований. Настраивать функции согласования можно пользователям, включенным в одну из двух вариантов групп:
- Администраторы;
- Новая группа в профиле с ролью «Согласование (настройка).
Создаются роли для исполнителей, которые будут участвовать в согласовании. Они могут быть записаны как по фамилиям с именами, отчествами так и по должностям. Например, Федоров Иван Николаевич находится в списке пользователей. Его можно выбрать из другого списка по роли Главный бухгалтер.

Виды программной связи документов

Типовой функционал программы 1С: Документооборот способен отслеживать несколько десятков согласований к одному документу. Сложное переплетение взаимоотношений можно автоматизировать. Для этого классифицируют типы связей при обработке документа:
- Автоматическая, создающаяся программой, или ручная, добавленная пользователем. В ручном режиме система зафиксирует время добавления и имя сотрудника, внесшего связь во внутреннюю, входящую или исходящую карточку документа.
- Единичная, при обработке одного документа, или множественная связь. В последней может быть задействовано несколько разных документов так называемых источников, первоначальных версий, и последующих вариантов, именуемых приемниками.
- Имеющая обратную связь или нет. При наличии такой возможности программа автоматически выстраивает связь с заданными настройками от источника к преемнику. В случае удаления одного из связанных документов, их обратные связи тоже автоматически исчезнут.
Обзор процессов согласования документов

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

Ход согласования документов

По мере движения задачи по указанному маршруту каждому задействованному сотруднику направляются соответствующие команды:

Рассмотрение

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

Согласование

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

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

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

Шаблоны согласований

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

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

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

Контроль процессов

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

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

Анализ и мониторинг согласований документов

Автоматическая служба 1С: Документооборота отслеживает более 100 показателей процессов согласований. Основные из них:
- число циклов;
- количество просроченных задач;
- время просрочки;
- средние трудозатраты.
Устанавливается пороговое значение роста или снижения показателей согласования. Программа информирует о достижении нижнего критического значения.

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

Заключение
- подготовка договора;
- согласование договора;
- контроль возврата переданных экземпляров;
- учет сопроводительных документов;
- учет срока действия;
- исполнение обязательств;
- расторжение.
- продлевает договоры при необходимости;
- отслеживает передачу документа контрагенту на подпись;
- контролирует сроки договоров и этапов.
Планирование и исполнение проектных задач

План проекта. Состоит из списка проектных задач, объединенных в иерархическую структуру, с указанием плановых сроков выполнения. Календарный план проекта рассчитывается автоматически на основе связей проектных задач, рабочего календаря, ограничений и настроек. План проекта можно загрузить из MS Project. Просматривать план проекта и отслеживать состояние проектных задач на всех этапах выполнения можно в следующих режимах:
- планирование — для составления плана проекта;
- отправка на выполнение — для своевременной отправки проектных задач на выполнение;
- контроль выполнения — для контроля выполнения проектных задач;
- анализ трудозатрат — для анализа плановых и фактических трудозатрат;
- полный — режим выводит полный набор колонок в списке;
- диаграмма Ганта — графическое представление плана проекта.
Подготовка по шаблону

Договор — это особенный вид внутреннего документа. Карточка договора содержит все сведения о нем (всего 75 реквизитов). Можно настраивать состав стандартных реквизитов и добавлять новые. Из карточки доступен переход ко всему, что связано с договором (переписка, процессы, сопроводительные документы, история сроков действия и прочее).
- черновики;
- согласованные материалы;
- скан-копии подписанных оригиналов;
- вспомогательные файлы.
Автозаполнение реквизитами

Программа поддерживает автоматическое заполнение файлов договоров. Текст договора заполняется автоматически из реквизитов карточки, например, Номер, Дата, Заголовок, Сумма, Срок действия и другие.
- подготовить шаблоны файлов для всех видов договоров, которые используются на предприятии;
- настроить правила автозаполнения для всех созданных шаблонов файлов;
- подготовить шаблоны внутренних документов, приложив к ним созданные шаблоны файлов.
Доступно заполнение полей файлов MS Word и Open Office. Правила заполнения полей задаются в виде конструктора или выражением на встроенном языке.

Согласование договора

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

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

Многосторонние договоры

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

Контроль возврата и передачи

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

Автоматическое продление
- при заключении дополнительного соглашения с новым сроком действия;
- при досрочном расторжении договора;
- при автоматическом продлении договора.
Срок можно изменить и вручную. Вся история изменения сроков действия договора сохраняется.

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

Планирование и исполнение проектных задач Подготовка по шаблону Автозаполнение реквизитами Согласование договора Многосторонние договоры Контроль возврата и передачи Автоматическое продление Анализ договорной работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Традиционные подходы и рекомендации

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

Подзадачи и ответственность

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

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

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

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

Ответственность и полномочия: как избежать ошибок?

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

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

Читайте также: