Бизнес-процессы управления портфелем проектов

VAD-диаграмма

ГОСТ Р 54870—2011 Проектный̆ менеджмент. Требования к управлению портфелем проектов.
Устанавливает требования к управлению портфелем проектов, как и следует из названия ГОСТ.

В тексте ГОСТ, в разделе 5 "Управление портфелем проектов", в пункте 5.1 "Общие положения" приведен список процессов управления портфелем проектов.

Уместно представить процессы управления портфелем проектов в виде VAD-диаграммы в соответствие с методологией ARIS.

Что и было сделано.

Примечание. Для автоматизации SAP предлагает решение SAP PPM.

Выходные данные по процессам

Процессы обеспечения управления портфелем

Сбор информации об условиях, ограничениях и требованиях к проекту:

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

Примечание. Для придания определенности "миссии", в рамках управления портфелем проектов можно принять в качестве миссии: "расширение возможностей принятия решений".

Формализация процедуры управления и параметров оценки портфеля проектов:

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

Процессы формирования портфеля проектов

Идентификация компонентов портфеля:

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

Оценка компонентов портфеля:

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

Расстановка приоритетов:

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

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

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

Авторизация портфеля проектов:

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

Процессы мониторинга и контроля портфеля проектов

Контроль реализации портфеля проектов:

• Отчет об исполнении компонентов портфеля и портфеля в целом.
• Отчет по запросам на изменение портфеля проектов.
• Управленческие решения:
• - решения по внесению изменений в состав компонентов портфеля.
• - решения по изменению приоритетов компонентов портфеля
• - решения по перераспределению ресурсов между компонентами портфеля.
• - рекомендации по изменению методологии управления портфелем.

Управление изменениями портфеля проектов:

• Регистрация запросов на изменения для принятия решения по ним.
• Утвержденные запросы на изменения.
• Скорректированные компоненты портфеля и портфель в целом в соответствии с утвержденными запросами на изменение.

Дополнение

В числе компонент портфеля могут быть программа и проект. Касательно этих компонент имеются следующие стандарты:

• ГОСТ Р 54871―2011 - Проектный менеджмент. Требования к управлению программой. Настоящий̆ стандарт устанавливает требования к управлению программой̆ на этапах её формирования и реализации, при этом предметом стандартизации являются обязательные выходы процессов управления программой̆.
• ГОСТ Р 54869—2011- Проектный менеджмент. Требования к управлению проектом. Настоящий стандарт содержит основные термины и процессы проектного управления.

Методология в части требований к документам

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

Тем не менее документами нужно тоже управлять, хотя они и не люди. Но формируются и двигаются людьми.

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

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

Почерпнуто из "ГОСТ Р 54870—2011 Проектный̆ менеджмент. Требования к управлению портфелем проектов".

Риск-менеджмент

Классификация рисков:

Стратегические	Х	Х
Финансовые	Х	Х
Операционные	Х	Х
Риски «опасностей»	Х	Х
	Внутренние	Внешние

Примерный перечень стратегических рисков.

№	Наименование риска	Краткое описание	Методы исследования
1	2	3	4
1	Смена лидеров во властных структурах	Перемены во властных структурах может привести к конфликтам в органах власти	BPEST-анализ, PESTLE-анализ
2	Иностранная конкуренция	Усиление конкуренции приводит к потере доли рынка	BPEST-анализ, PESTLE-анализ
3	Падение рентабельности отрасли	Структурные изменения в отрасли	BPEST-анализ, PESTLE-анализ
4	Появление крупного игрока	Монопольные возможности крупного игрока приводит и к потере доли роли, возможно угроза демпинга со стороны крупного игрока для захвата последним рынка	BPEST-анализ, PESTLE-анализ
5	Отсутствие новых продуктов	Угасание и потеря бизнеса	BPEST-анализ, PESTLE-анализ
6	Старение технологий	Избыточные затраты, снижение рентабельности бизнеса и как следствие – неконкурентоспособность предприятия	BPEST-анализ, PESTLE-анализ
7	Изменение отраслевого законодательства	Необходимость срочного изменения технологических процессов, получения лицензий и разрешений	PESTLE-анализ
8	Экологические запреты	Необходимость изменения технологических процессов, строительства новых объектов, внедрения экологических технологий	PESTLE-анализ
9	Отсутствие персонала требуемой квалификации	Срыв производственной программы, невозможность увеличения объемов производства	STEEPLED-анализ
10	Демографические проблемы	Снижение численности население и как следствие повышенные издержки с набором персонала	STEEPLED-анализ

   

Перечень финансовых рисков.

№	Наименование риска	Краткое описание	Методы исследования
1	2	3	4
1	Валютный	Падение курса для валютных контрактов	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
2	Кредитный	Увеличение дебиторской задолженности, просроченная кредиторская задолженность	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
3	Потеря ликвидности	Денежные дефицит, кассовые разрывы	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
4	Плохое ценовое соотношение	Увеличение прямых затрат (закупочных цен на материалы, энергию, услуги)	PESTLE-анализ
5	Налоговые претензии	Штрафы, блокирование счета, возможность судебного преследования	HAZOP
6	Увеличение стоимости строительства	Увеличение сроков и факта окупаемости инвестиционных проектов	HAZOP

  

Причины операционных рисков.

№	Наименование риска	Краткое описание	Методы исследования
1	2	3	4
1	Неэффективные маркетинговые компании	Эффективность маркетинга не оценивается, но компаний проводится много	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
2	Упущенная выручка	Например, высокие скидки	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
3	Рост неликвидов	Неэффективная процедура закупок	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
4	Неэффективность НИОКР	Потеря активов	Аудит и инспекция, расследование причин инцендентов
5	Избыточный персонал	Сложно уволить, тем не менее себестоимость слишком высокая	Метод мозгового штурма
6	Рост затрат на соцсферу	Высокие издержки	Метод мозгового штурма
7	Увольнение топ-менеджеров	Снижение эффективности управления	Метод мозгового штурма
8	Проблемы в проектах	Срыв проектов ведет к потере денежных средств	Аудит и инспекция, расследование причин инцидентов
9	Война с акционерами, в частности, с миноритариями, недружественные поглощения	Потеря репутации, вплоть до замены руководства	Метод рабочих групп оценки рисков

 Риски опасностей.

№	Наименование риска	Краткое описание	Методы исследования
1	2	3	4
1	Пожар, авария	Потери основного и рабочего капитала	HAZOP, FMEA, FTA
2	Отключение электроэнергии	Остановка производства	HAZOP, FMEA, FTA
3	Потери данных (ИТ)	Потеря управляемости	Аудит и инспекция, расследование причин инцидентов
4	Потеря ключевого поставщика	Остановка производства	Анализ сценариев
5	Непредвиденные затраты	Убытки	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
6	Откаты и «благодарности»	Убытки, возможность судебного преследования	Рассмотрение каждого бизнес-процесса на предмет выявления рисков
7	Хищения	Потери	Аудит и инспекция, расследование причин инцидентов
8	Рейдерские действия	Затраты на защиту, возможности смены руководства, прекращение деятельности	Анализ сценариев

  

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

• SWOT-анализ.
• BPEST (бизнес, политика, экономика, социология, технология).
• PESTLE (политика, экономика, социология, технология, юриспруденция. экология).
• STEEPLED (PESTLE + образование, демография).
• Анализ сценариев.
• Планирование непрерывности бизнеса: выявление возможных проблем, которые могут привести к невозможности существования (например, стандарт BS 25999).
• Рассмотрение каждого бизнес-процесса на предмет выявления рисков.
• HAZOP (hazard + operability) - поиск потенциально опасных процедур.
• FMEA (failure mode and effects analysis) - анализ видов и последствий отказов.
• FTA (fault free analysis) - анализ дерева неисправностей.
• Метод рабочих групп оценки рисков.
• Метод мозгового штурма.
• Аудит и инспекция, расследование причин инцидентов.

Для визуализации рисков используется карта рисков.

 Формат отчета о рисках.

№	Наименование риска	Описание риска	Вероятность	Ущерб, деньги
1	2	3	4	5

  

  Мероприятия по управлению рисками:

• Избегание риска. Например, продажа актива, отказ от проекта, выход из рынка.
• Передача риска. Страхование, хеджирование, аутсорсинг.
• Удержание (принятие) риска. Принятие бремени убытков и выгод от доходов.
• Снижение риска. Смягчение последствий риска: действия и мероприятия по снижению как вероятности риска, так и ущерба.

Формат отчета о мероприятиях по управлению рисками.

№	Наименование риска	Мероприятия по управлению риском	Ориентировочная стоимость мероприятия	…
1	2	3	4	…

  

…	Текущее значение риска, деньги	Остаточный риск, деньги	Изменение риска, деньги	Эффективность мероприятия
…	5	6	7=[5]-[6]	8=[7]/[4]

  

Методологические желаемо-обязательные свойство ИТ-систем поддержки принятия решения

К ИТ-системам предъявляется много требований. Из них есть общие, довольно абстрактные и конкретные.

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

• Удобство использования и доступность. Вся значимая (релевантная) информация должна быть легко доступной в точке принятия решения.
• Гибкость. Система должна адаптироваться (или предусматривать возможность адаптации) к изменениям в структуре обслуживаемого объекта, а также иметь некоторую степень адаптации к изменению требований.
• Многомерность. Система должна поддерживать декомпозицию - разложение на компоненты; обеспечивать сравнение сценариев; обеспечивать поддержки и согласование иерархий, не исключая поддержки альтернативных иерархий.
• Дружественность и удобство использования. Адаптация системы в расчете не только на продвинутого, но и на обычного пользователя.
• Скорость ответа. Приемлемая реакция системы.
• Открытость системы. Система должна иметь механизмы интеграции с другими система, как "вход", так и "на выход".
• Устойчивость и масштабируемость. Сводится как правило к способности ведения больших наборов данных, поддержка разнообразных источников данных, исполнение большого числа одновременных и распределенных запросов.
• Согласованность и целостность данных. Это свойство обеспечивается уже в рамках "теории данных".

Сложности бюджетирования и ИТ-услуги

Сложности бюджетирования проистекают из следующего фундаментального противоречия:

Структура потребления не равна  структуре финансовой ответственности.

Более того:

• Структура потребления описывается сложным workflow (потоком работ, потоком задач).
• Структура финансовой ответственности описывается сложным cash flow (денежным потоком).

Следующая группа сложностей связана с регистрацией факта.

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

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

И тогда возможна автоматизация, и возможно определить правила ведения.

И здесь возникают решения трех родов

1. Решения которые устраивают всех
2. Компромиссные решения.
3. Бизнес-услуги.

Подобное родовое деление определяется целями.

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

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

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

В этом состоят ИТ-услуги.

ИТ-услуги, это услуги которые идут

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

* * * 

ПОМОЩЬ (автор - Святослав Логинов).

    Клапан был уверен, что пар не должен выходить из котла.
    - На то я здесь и поставлен, - пыхтел он,  чтобы  беречь  пар.  Ни
одного грамма потерь!
    Пар нажимал всё сильнее и наконец Клапан не выдерживал.  "Пш-ш!.."
- пар уходил свистящей белой струёй.
    - Сорвалось! - досадовал Клапан. - Не справился. К следующему разу
надо будет лучше подготовиться.
    - Могу помочь, - предложила неведомо откуда взявшаяся Заусеница. -
Пожалуйста, упритесь в меня...
    Теперь работать стало легче. Пар метался из стороны в сторону,  но
нигде не находил ни малейшей щёлочки. Разумеется, дело не обошлось без
завистников. Котёл,  которому  теперь  приходилось  жарко,  готов  был
взорваться от злости. Но хуже всех поступил Манометр. Он  сообщил  обо
всём Машинисту, и Клапан сняли.
    А за что спрашивается? За то, что принял помощь общественности!

Святослав Логинов.