Регламент по регламентам

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

1.      Командная работа (взять за основу Эссенс)

a.     Требования к организации рабочей группы

i.      Требования к комплектованию рабочей группы

 ii.      Требования к согласованию миссии рабочей группы

iii.      Требования к подготовке рабочей группы к работе

iv.      Требования к роспуску рабочей группы

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

b.    Правила взаимодействия в рабочей группе (Agile Teams Core Protocols, правило 4 предложений)

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

d.     Правила взаимодействия с исполнителями процесса (процесс объяснений (см. «Искусство объяснять»), визуальный менеджмент (см. кабан и бережливое производство), парафраз, правила разработки чек-листов)

2.    Процесс разработки документации

a.     Общие требования к процессу разработки документации (процесс БАПС)

b.    Требования по определению заинтересованных сторон процесса и их интересов

c.     Требования к постановке целей разработки процесса (целеориентированная инженерия требований)

d.     Требования по определению сервиса и результатов процесса

e.     Требования по определению и описанию интерфейсов процесса

f.       Требования по согласованию метода описаний процесса

g.     Требования по определению критических элементов (архитектуры) процесса

h.    Требования по формированию бизнес-требований на автоматизацию процесса

i.       Требования к разработке положений и политик

j.       Требования к разработке чек-листов и рабочих инструкций

k.     Требования к повторному использованию бизнес-норм (business rules reuse)

l.       Требования к постоянному совершенствованию процесса разработки документации

3.    Качество документации

a.     Общие требования к качеству документации (шаблоны, руководящие документы)

b.    Требования к качеству текста (Инфостиль Максима Ильяхова)

c.     Стоп-лист слов, терминов, формулировок

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

e.     Требования к процессу коллективной вычитки текста

4.    Проверка и приемка процесса против описания

a.     Требования к планированию проверки процесса

b.    Требования к планированию приемки процесса

c.     Требования к отслеживанию исполнения плана проверок и приемок

d.     Требования к организации проверок

e.     Требования к организации приемок

f.       Требования к оформлению результатов проверок и приемок

g.     Требования к хранению результатов проверок и приемок

5.     Управление конфигурацией

a.     Требования к версионности описаний (в имени файла)

b.    Требования к организации процесса проверки коллизий конфигурации

c.     Требования к процессу выпуска и введения документации в действие

d.     Требования к организации хранения исходников документации и печатных копий

6.    Смена владельца процесса и вывод процесса из использования

a.     Требования к передаче процесса другому владельцу

b.    Требования к выводу процесса из использования

Управление проектами организации - архитектурные требования, архитектура и кусочек viewoint’а

В продолжение этого поста, дополнительные разъяснения.

Перед рассуждениями объясню понятие платформы системы.

Возьмем кубики Лего https://shop.lego.com/en-US/Themes

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

Для автомобиля платформа и интерфейсы будут уже сложнее, но принцип сохраняется:

Платформа

Интерфейсы

Рассмотрим обеспечивающую систему (предприятие) как черный ящик. Какую потребность (user need) удовлетворяет освоенная практика управления проектами организации (organizational project management)?

Организация с УПО должна иметь заметно более высокую устойчивость к возникновению непредвиденных ситуаций (robustness) и возможность самодостаточного развития (sustainability) по сравнению с организацией без УПО.

Эта потребность ведет за собой (drives) архитектурные требования:

1. Достаточность и корректность инвестиций. В рамках ОУП обеспечиваются надлежащие и достаточные (proper) в плане объема, распределения и графика, инвестиции, которые отвечают потребностям в возврате и профиле риска (ROI and risk profile) стейкхолдеров, осуществляющих надзор за общей деятельностью организации (governance stakeholders)
2. Ориентированность на рынок при распределении ресурсов между работами. Ресурсы направляются на реализацию тех характеристик выпускаемой продукции и оказываемой этой продукцией клиентских сервисов, которые востребованы целевым рынком (стейкхолдерами системы) с приемлемым уровнем возврата инвестиций и профилем риска работ по реализации этих характеристик
3. Точные оценки требуемого времени для завершения работ по созданию продукта и/или системного описания либо части продукта и/или системного описания с приемлемым уровнем риска.

Рассмотрим архитектуру ОУП, неважно, будет ли она реализована в рамках P2M, OPM3, P3M.

Стейкхолдер портфельный менеджер смотрит на обеспечивающую систему (организацию), и видит портфель, который состоит из проектов, программ и работ BAU (business as usual). Его интересуют (stakeholder concerns) маржинальные финансы организации и глобальное распределение работ. Программы, проекты и BAU - это модули портфельного управления, ниже них он не идет, портфель собирается именно из этих блоков, это его системный уровень. Портфельный менеджер отвечает за то, чтобы делались правильные вещи, другими словами, портфельный менеджмент реализует архитектурное требование №1 “Достаточность и корректность инвестиций”.

Стейкхолдер программный менеджер отвечает за весь жизненный цикл продукта/сервиса. Другими словами, за удовлетворение потребностей внешних стейкхолдеров, другими словами, за системные эффекты. Поэтому он рассматривает систему в ее операционном окружении, оно же “использующая система” (using system). Крупные проекты - это как правило программы, тем более учитывая тенденцию проникновения Scrum и two pizza teams в разные области.

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

Стейкхолдер проектный менеджер отвечает за то, чтобы дать точную оценку, когда будет готов продукт, за который он отвечает. Все проектные методологии, независимо от того, критический ли это путь, цепь, график сгорания и прочее, отвечают только на этот вопрос. “С текущими ресурсами когда будет готово”? При этом учитывается профиль риска работ. Поэтому менеджер проекта смотрит на организацию, и видит пакеты работ, это его системный уровень. На этом уровне производятся оценки длительности, с помощью самых разных моделей. Его интерес - работа, а точнее даже тот ее аспект, который связан с “проходом” (throughput). Точность оценки, в частности, обеспечивается тем, что обеспечивается стабильная защищенная среда проекта (PRojects IN Controlled Environment, Скрам, PMBOK  - все говорят об одном и том же, проекты надо защищать от изменений).

За что отвечает P3O (Portfolio, program, project management office)?

1. Связанность системных уровней, единый viewpoint
2. Платформа УПО (типовые интерфейсы и модули на каждом системном уровне)
3. Поддержание целостности требований стейкхолдеров к технологии УПО

Различие областей знаний Р3М по системным уровням

Сегодня шел профессиональный разговор с Адвантой про системный подход в проектном управлении. Немного обсудили различия между проектным, программным и портфельным менеджментом. Повторю свои тезисы - никаких отдельных самостоятельных практик проектного, программного и портфельного менеджмента не существует, есть управление проектами организации (organizational project management). Эта точка зрения Axelos, PMI, P2M и ISO15288, в котором, напомню, есть:

5.3.3 Процесс управления инвестициями

5.3.5 Процесс управления ресурсами

5.4 Процессы проекта

В чем ключевые отличия между этими практиками? В принимаемых решениях, системных уровнях и стейкхолдерах. Здесь и далее опираюсь на системную схему предприятия:

Системная схема предприятия

Пойдем снизу вверх.

Проектный менеджмент управляет пакетами работ, это его системный уровень, ниже которого он не опускается. Сами работы и их исполнение - это предмет профессиональных дисциплин, лучше всего эта тема объяснена в PRINCE2, различие между work package и team plan. Менеджер проекта принимает решения по распределению ресурсов проекта между пакетами работ. Еще он может, по согласованию с программой и портфелем изменять сроки исполнения работ. Цель проектного менеджмента в управлении подальфой Cost альфы Opportunity и в верификации того, что ключевые результаты (deliverables) проекта будут доступны стейкхолдерам в приемлемое для них окно возможностей (не показанная подальфа Opportunities). Ведь все практики календарного планирования и прогнозирования ориентированы ровно на это - предсказать estimate to complete.

Программный менеджмент. С ним несколько сложнее, давайте посмотрим на program master schedule:

Integration Master Schedule

Как видим, на уровне программы (Event, Accomplishment, Criteria, Task) отслеживается исполнение архитектурных требований. Архитектура - это про все важное, и архитектурные требования будут разными для разных уровней, что мы и видим в расписании. Event важен для уровня системы, которая приобретается в рамках закупки, Accomplishment для подсистем, Criteria и Task - для отдельных проектов создания системных модулей и сборки системы. Контрольная точка с точки зрения системного подхода - это реализация требования, привязанная ко времени. Контрольные точки - это системный уровень программы, программа строится из контрольных точек.

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

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

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

Портфельный менеджмент. Глобальные работы и финансы.

Примерно так.

Форма регламента для системного описания жизненного цикла

{Название компании}

{Название документа}

Ландшафт процесса {отсылка к архитектурному описанию}

Автор 10/05/2017

Дата изменения	Содержание изменений	Автор
10 мая 2017	Первичный выпуск	Имя

Основной сервис и результат выполнения процесса:

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

Таблица 1. Ключевые ответственные

Ответственные за процесс	Кто назначен	С какой даты назначен
Держатель бюджета
Владелец описания
Ответственный за корректное исполнение
Бизнес-контролер
Корпоративный аудитор
Бизнес-аналитик
Владелец бизнес-требований
Разработчик
Техподдержка

Таблица 2. Чек-лист процесса

Пункт	Подробности см. документ
Условия запуска процесса: ·         Есть инициатор расхода, готовый выполнить все шаги процесса ·         Определена статья бюджета, с которой будет оформлен расход ·         Руководитель инициатора согласен с необходимостью расхода ·         Возможные источники поставок определены
1.       Предмет договора определен и согласован с руководителем и юристами
2.       Коммерческие предложения получены
3.       Документы контрагента проверены службой безопасности, карточка контрагента передана в канцелярию
Не более 10 пунктов
Условия досрочной остановки процесса: 1.       Контрагент не прошел проверки СБ 2.       Тендерный комитет не одобрил поставщика 3.       Расход не одобрен 4.       Условия договора не согласованы 5.       Документы на оплату некорректные 6.       Исчезла необходимость в расходе 7.       Заявка на оплату не утверждена
Условия завершения процесса: ·

Таблица 3. Связь с другими процессами

Входит в процесс верхнего уровня «Практика финансового контроля»

С каким процессом взаимодействует (код документа)	Формат взаимодействия (документ, отчет, интерфейсы)	Соглашение об уровне сервиса
Тендерная процедура для коммерческих закупок	Заявка на потребность по форме … Служебная записка о резервах по форме … Коммерческое предложение по форме … Служебная записка с обоснованием выбора безальтернативного поставщика по форме … Отсканированные копии документов	Инструкция о порядке заключения договоров 01-3-СЕО/16 от 08.04.2014 Положение о выборе контрагента для коммерческих закупок

Таблица 4. Роли в процессе

Роль	Что делает	Необходимые компетенции	Ключевые требования роли, предъявляемые к процессу	Должность, назначенная на роль
Инициатор расхода	·         Общается с контрагентом, получает от него документы ·         Обеспечивает исполнение всех шагов процесса	·         Ведение переговоров ·         Общение с контрагентом ·         Оформление договоров ·         Оформление документов ·         Управление версиями документов	Должен своевременно узнавать о проблемах исполнения шага процесса, должен немедленно получать уведомление о завершении шага процесса. Должен быть поиск поставщиков из списка одобренных контрагентов и действующих договоров, чтобы избегать задвоенных контрактов.	Любой сотрудник компании
Держатель статьи бюджета	·	·
Финансовый контроль	·	·

Таблица 5. Документы и отчетность процесса

Документ или отчет	Источник документа/данных	Процедура получения отчетности (ссылка)
Коммерческий договор поставки
…

Таблица 6. План и результаты проверок

Требование	Процедура	Результат (ссылка на документ)

Таблица 7. План и результат приемки

Требование	Процедура	Результат (ссылка на документ)

1.      Функциональное описание процесса
{Не блок-схема, а именно из каких функциональных блоков (компонент) состоит процесс и связи между ними. Принципиальная схема деятельности в процессе.}

2.      Пошаговое описание SIPOC (не обязательный блок)

От кого	Что на входе	Шаг процесса и место его выполнения	Что на выходе	Кому передается