Графическое представление БП должно содержать информацию о входящих и выходящих документах, времени, затрачиваемом на каждую операцию (стадию, работу)

2. Построение дерева бизнес-процессов. Рассмотрим пример дерева бизнес-процессов компании, занимающейся бизнесом по производству и продаже аудио-видео продукции и торгового оборудования (рис. 31).

Первая группа бизнес-процессов - это основные процессы:

1) закупка и розничная торговля аудио видео продукцией;

2) производство и продажа аудио продукции;

3) производство и продажа торгового оборудования.

Вторая группа бизнес-процессов — это обеспечивающие процессы:

1) обеспечение безопасности;

2) административно-хозяйственное обеспечение (АХО);

3) юридическое обеспечение.

Третья группа процессов — это процессы управления. В этой компании существовали следующие критические объекты управления, которыми нужно было управлять: «Стратегия», «Деньги», «Клиент», «Персонал» и «Товарный запас». Для управления этим объектами существовали следующие бизнес-процессы управления:

1) стратегическое управление;

2) управление персоналом;

3) управление финансами;

4) управление маркетингом;

5) управление товарным запасом

Рисунок 31- Пример построения дерева бизнес-процессов компании

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

Примерами процессных регламентов являются следующие документы:

положение о внутрифирменной деятельности (бизнес-процессах компании); положение о бизнес-процессе;

положение о функции;

положение о процедуре.

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

Рисунок 32 - Процессные и структурные регламенты

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

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

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

Таблица 10 - Структура системы регламентирующих документов

Уровень компании	Процессные регламенты	Структурные регламенты
Верхний	Положение о внутрифирменных видах деятельности	Положение об организационной структуре, группе компаний
Средний	Положения о бизнес-процессе	Положения о подразделениях
Нижний	Положения о функциях, процедурах	Должностные инструкции

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

Документы сложно читать (многословие, недостаточная четкость, нелогичность изложения).

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

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

Нет рычагов для контроля по предложенным регламентирующим документам (не описаны ответственные, а также последствия невыполнения регламентов).

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

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

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

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

Таблица 11 - Типовая структура регламента бизнес-процесса с максимальным перечнем разделов

Общие положения

1.1. Назначение (цель) положения; 1.2. Область применения (работы и структурные звенья, регламентируемые положением); 1.3. Термины и определения

Описание бизнес-процесса

2.1. Назначение (цели) бизнес-процесса; 2.2. Работы бизнес-процесса; 2.3. Подразделения и должностные лица, участвующие в бизнес-процессе; 2.4. Распределение ответственности подразделений / должностных лиц за работы бизнес-процесса. При более детальном описании желательно также указать следующую информацию: 2.5. Последовательность выполнения работ; 2.6. Входящие и исходящие информационные и материальные потоки; 2.7. Даты / события инициирования и завершения работ; 2.8. Длительность работ; 2.9. Прочие количественные показатели бизнес-процесса

Критерии оценки эффективности бизнес-процесса

Ответственность и контроль

4.1. Процедура контроля исполнения Положения; 4.2. Ответственность должностных лиц за соблюдение данного Положения.

Порядок внесения изменений в Положение

Приложение 1. Схемы бизнес-процессов, документооборота, материальных потоков и взаимодействий подразделений / должностных лиц

Приложение 2.Формы документов, используемые в бизнес-процессе

Характеристика разделов регламента бизнес-процесса

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

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

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

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

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

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

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

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

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

5. ОРГАНИЗАЦИОННЫЙ ПЛАН

Описание данного раздела включает:

1. Построение структурной схемы организации (ССО) проекта

2. Разработку матрицы ответственности

3. Подготовку внутрифирменных регламентирующих положений.

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

В основе построения ССО лежит ИСР проекта. Смысл построения ССО состоит в том, чтобы: учесть все работы, производимые по проекту и закрепить их за сотрудниками; предварительно оценить требуемые квалификационные характеристики работников и методы их привлечения в проект; предварительно оценить требуемые ресурсы; оптимизировать расходы на оплату труда.

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

Рисунок 33 – Оргструктура проекта

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

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

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

1) соответствие организационной структуры системе взаимоотношений участников проекта;

2) соответствие организационной структуры содержанию проекта;

3) соответствие организационной структуры требованиям внешнего окружения.

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

• «выделенная» (разовая или «адхократическая») организационная структура управления проектами применяется тогда, когда основные механизмы управления и непосредственные источники основных ресурсов проекта находятся в рамках одной организации и после завершения проекта такая структура ликвидируется;

• «управление по проектам» – когда «выделенная» организационная структура управления проектом превращается во внутреннюю, постоянно действующую структуру;

• «всеобщее управление проектами» – когда организационная структура проекта и «материнской» организации составляют единое целое и управляются общей системой управления;

• «двойственная» (dual) организационная структура – когда в проекте участвуют две равнозначные с точки управления проектом, организации;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· управление ресурсами проекта, в том числе:

o определение требуемых для достижения целей проекта ресурсов;

o подготовка предложений по изменению состава группы управления проектом;

o утверждение персональных изменений в составе рабочих групп проекта;

o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов;

· управление сроками выполнения проекта, в том числе:

o подготовка плана работ проекта;

o контроль над выполнением проекта;

o подготовка отчетов о ходе работ проекта;

· управление качеством проекта, в том числе:

o контроль соответствия разрабатываемых проектных решений техническому заданию;

o организация экспертизы проектных решений;

· управление рисками проекта, в том числе:

o анализ рисков проекта;

o разработка планов мероприятий по снижению рисков;

o реализация мероприятий по снижению рисков;

· управление проблемами проекта, в том числе:

o анализ проблем проекта;

o разработка мероприятий по разрешению проблем проекта;

o реализация мероприятий по разрешению проблем проекта;

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

o согласование отчетов о ходе работ;

o контроль над функционированием системы сбора и распределения информации;

o контроль документирования проектных результатов.

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

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

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

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

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

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

Рисунок 34 – Пример организационной структуры проекта

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

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

• формирование и развитие организационной системы управления проектами компании;

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

• внедрение и обеспечение эффективной эксплуатации и развития информационной системы управления проектами компании (ИСУП);

• контроль качества планирования и ведения проектов компании в ИСУП;

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

• разработка программ обучения, учебно-методических материалов и организация обучения и консультирования управляющих проектами и специалистов команд управления проектами;

• ведение архива проектов в ИСУП;

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

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

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

• формирование и ведение базы рисков проектов и базы рисков компании;

• формирование методологической базы оценки и минимизации рисков;

• организация и проведение экспертных оценок рисков проектов и рисков компании

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

Для решения указанных задач центром управления проектами должны выполняться следующие функции:

• методологическая – разработка и внедрение документов системы документационного управления проектами, создание типовых моделей проектов и выдача их в команды управления проектами на фазах инициации и планирования, выявление и формирование типовых фрагментов проектов для последующего использования, разработка учебно-методических материалов, программ подготовки и организация обучения сотрудников планированию и ведению проектов в ИСУП, методологическое обеспечение оценки и минимизации рисков проектов и рисков компании;

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

• архивная – хранение информации, формализация накопленных дел проектов, ведение базы данных типовых проектов и типовых этапов проектов, ведение базы данных рисков проектов и рисков компании;

• инфраструктурная – участие в проектах по созданию и развитию ИСУП, менеджмент лицензий и прав на доступ к ИСУП, контроль технологического состояния ИСУП, поддержка функционирования распределенной системы управления рисками компании;

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

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

• контроль правильности планирования проекта в ИСУП;

• контроль ведения проекта в ИСУП.

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

При распределении ответственности в системе отчетности используют матрицу отчетности, которая приведена на рис. 36.

В данной матрице обозначают:

символом П – ответственного за подготовку отчета;

символом Р –ответственного за рассмотрение отчета и принятие решений;

символом А – ответственного за архивацию отчета.

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

Рисунок 37 – Матрица отчетности

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

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

При разработке матрицы ответственности исходят из следующих определений:

- ответственность – обязательство, которое человек должен выполнять;

- сфера ответственности – круг задач, за успешное решение которых отвечает человек в данном проекте;

- полномочия – право на приятие решений в рамках выделенного круга задач.

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

Рисунок 38 – Сложная матрица ответственности

Существует еще один способ разработки матрицы ответственности. Этапы разработки матрицы ответственности:

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

2. Перечислите участников/группы участников проекта в столбцах матрицы.

3.: Закодируйте матрицу ответственности: О, У, К, И.

◊ ≪О – отвечает≫ – тот, кто несет ответственность за данный результат (обычно это член команды, непосредственно обеспечивающий получение данного результата).

◊ ≪У – утверждает≫ – тот, кто утверждает результат (выбирается из числа лиц, принимающих окончательное решение о выполнении работы и качестве результата).

◊ ≪К – консультирует≫ – тот, кто дает дополнительные ориентиры для своевременного получения качественного результата (в этой роли выступают сведущие в данной области люди).

◊ ≪И – информирует≫ – тот, кого обязательно надо информировать о полученном результате (это те члены команды проекта, действия которых зависят от качества и времени получения данного результата).

Рисунок 39 – Пример взаимосвязи ИСР и матрицы ответственности

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

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

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

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

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

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

Таблица 12 – Пример матрицы ответственности

	Папа	Мама	Сын	Дочь
Выбор рецепта	И	У/О	К	К
Покупка продуктов	О	У/И	О	К
Подготовка ингредиентов	К	У/И	К	О
Приготовление	И	У/О	И	И

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

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

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

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

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

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

Рисунок 40 – Процесс заполнения матрицы ответственности

Дата добавления: 2017-01-14