суббота, 28 октября 2017 г.

СВЯЗЬ АРХИТЕКТУРНОГО ОПИСАНИЯ, АРХИТЕКТУРЫ И ПРАКТИК КЕЙС, ПРОЕКТНОГО И ПРОЦЕССНОГО МЕНЕДЖМЕНТА

кп.png

Одной из ключевых проблем в управлении проектами организаций (organizational project management) является подготовка и назначение единого ответственного лица (ЕОЛ). В зависимости от типа предпринятия в роли ЕОЛ может выступать: менеджер продукта или ведущий системный инженер, менеджер проекта, операционный менеджер или бизнес-архитектор (менеджер по развитию бизнеса).

Наиболее сложным и интересным случаем являются предпринятия, в которых циклы развития применяются как к целевой системе, так и к обеспечивающей. Обычно при обсуждении таких программ говорят не о практиках (practices), а о потенциале, функциональных возможностях (capabilities). О функциональных возможностях можно думать как о воплощенных, реализованных практиках, когда технологии развернуты на местности и применяются обученными исполнителями с дисциплиной в голове. В программах новые функциональные возможности появляются как в использующей системе обеспечивающей системы, так и в использующей системе. Например, программа разработки истребителя F-35 совместно с комплексом его технического и боевого обслуживания и сопровождения создает новые функциональные возможности для ВВС и других родов войск, а в ходе его разработки и производства у подрядчиков и головного исполнителя появляются новые технологии и знания. Аналогичный пример можно привести для автомобилей или, к примеру, новой операционной системы.
В предпринятиях такого масштаба одним из ключевых моментов является   интероперабельность деятельности (business interoperability), концепт, активно развивающийся, также см. здесь, в последние 10 лет для становящихся предприятий (emerging enterprises). За выполнение плана реализации интероперабельности и достижение целей всеми участниками программы отвечает ЕОЛ - менеджер программы.
На рабочем совещании обсуждался набор технологий управления программой - ориентированная на продукта иерархическая структура работ (product-oriented work breakdown structure, PO-WBS) и сетевой сводный план-график программы (integrated master schedule).
Были обсуждены основные проблемы постановки практики PO-WBS, ее связь с разбиением системы (system breakdown structure) и графиками работ подразделений, принципы взаимодействия между инженерной организацией и бизнесом, а также вопросы разделения ответственности между ключевыми стейкхолдерами команды управления программой:
Направление интересов у различных стейкхолдеров команды управления программой.
PgMO - program management office (методологическое обеспечение управления программой)
CTO/CIO - chief technical/information officer
COO - chief operations officer
Chief SE - chief systems engineer

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

Ссылка на презентацию.


Команда - следует ли форма за функцией?


У системы есть символьное описание и объективное воплощение. Люди интерпретируют символьные описания и создают на их основе концепции.
Символы и объекты конкретны и доступны всем. Концепции субъективны и абстрактны. Люди формулируют концепции в символах, и они становятся доступны другим через интерпретацию.
Люди действуют, основываясь на своих концепциях, пока человек не поймет, сделать он ничего не может. Концепции имплементируются в воплощении системы.
Когда человек изучает воплощение системы и создает у себя в голове модель ее функционирования, например, “автомобиль ездит и перевозит пассажиров с грузом”, это называется концептуализацией.
ontology.png
Субъективное и абстрактное.

Но в то же время концепция материальна и является частью 4Д экстента личности, см. нейропластичность мозга.

Слово "команда" используется в 4 случаях:
1) Конкретные люди, выполняющие конкретное поручение (команда как модуль организации). Конструктивно-объективное рассмотрение. Область интересов менеджера проекта.
team positions.jpg
Команда как часть организации с полномочиями и ответственностью, конкретными людьми и технологиями

2) Конкретные люди, выполняющие конкретную практику (команда как компонент организации). Функционально-объективное рассмотрение. Область интересов системного инженера и лидера.
team roles.jpg
Команда как система из ролей, исполняющая практику жизненного цикла системы

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


4) Модель команды как часть жизненного цикла системы (команда как тип компонент). Компонентно-концептуальное рассмотрение.
штатное расписание.png
Правая часть диаграммы показывает ролевую концепцию команды.

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

classification.png
Команда с одной стороны отвечает по своим обязательствам и соблюдает подоотчетность, “отвечает за слова” (трансакционный аспект, поставленная практика), а с другой выполняет работы жизненного цикла системы, “дело делает”. Эджайл манифест - это приоритет дела перед формальными обязательствами и регламентацией, приоритет функции над конструкцией, “конструкция следует функции”.

среда, 25 октября 2017 г.

Программы проектов, освоенные практики и технологические стеки предприятия


В продолжение разговора про поставленные практики (capabilities), программы проектов (programs, PMI Standard for program management) и технологические стеки.

Работы как 4Д экстент являются классом, экземплярами которого могут быть конкретные процессы, кейсы, проекты и программы, см., например здесь. Они описываются типами.
work ontology.png
Онтологический параллелограмм работ

При этом функция работ - продвинуть целевую систему по жизненному циклу. Функции модулей работ (экземпляров процессов, кейсов, проектов и программ):
Программа - выполняет функцию постановки практики (capability acquisition). Подробная дискуссия была здесь, записи видео доступны (1 и 2) для членов сообщества ШСМ.
Процесс - выполняет функцию оптимального исполнения практики (best practice, делать так и никак иначе).
Кейс - выполняет функцию исполнения практики, когда оптимальный вариант исполнения не известен (обычно в виде набора стандартных операционных процедур, SOP, standard operating procedures)
Проект - выполняет функцию разработки описания, концептуализации (интернализация описания системы командой) или реализации воплощения системы. Лучше всего описывается системной схемой проекта.

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

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

Axelos
“In MSP, a programme is defined as a temporary, flexible organization created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organization’s strategic objectives. A programme is likely to have a life that spans several years. A project is also a temporary organization, usually existing for a much shorter duration, which will deliver one or more outputs in accordance with an agreed business case. A particular project may or may not be part of a programme.”

P2M и BIM раскрывают тему лучше, используя несколько диаграмм.

Еще понятнее различие раскрывается в Lean Program Enablers, написанной PMI совместно с INCOSE и MIT.

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

Программа работает с практикой и нацелена на ее воплощение (capability acquisition). Системных холархий в программе множество. Цель программы - освоение предприятием какой-то практики, ее постановка (оценивается субъективно, по модели зрелости практики, например, CMMI).
Если рассматривать проекты и программы через вьюпойнт технологического стека предприятия, то проект работает в пределах одного уровня, слоя стека, а программа работает по всему стеку.
price leadership view.png
Технологический стек ритейл организации

Сравните, например, проект строительства типового панельного дома и программу перехода нефтеперерабатывающих производств на стандарты Евро 5. Или, если брать ритейл, программу внедрения ФГИС Меркурий, который перетряхивает всю цепочку поставок.

Еще раз - программа затрагивает весь технологический стек, там множество стейкхолдеров и холархий. Постановка практики перетряхивает деятельность предприятия на несколько уровней вниз и вверх.
В этом плане интересно посмотреть на lean enablers и PMI Standard for program management:
1) Программный менеджер должен быть один и не меняться на протяжении всей программы. Систем и стейкхолдеров очень много, интересы сильно переплетены, текущие решения исторически обусловлены, и эти знания не выражены явно.
2) Чем занимается руководитель программы? Выявляет и работает со стейкхолдерами (много систем, много стейкхолдеров), строит инфраструктуру (интерфейсы между уровнями технологического стека), оптимизирует пользу для стейкхолдеров и обеспечивает поднадзорность программы.


суббота, 21 октября 2017 г.

Надежность человека

Трансакционный и функциональные аспекты моделей деятельности

По Диетцу [1] акторы взаимодействуют между собой трансакциями.
Шаблон описания трансакции

Вторая схема из Диетца, которая понадобится для объяснения – это онтологический параллелограмм, который показывает мета-модель абстракций, используемой в мышлении, см. также [2].
Онтологический параллелограмм

Третья схема – это архимейтовское представление деятельности в разрезе «внутренее»-«внешнее», «поведение» - «структура».
Шаблон описания деятельности в ArchiMate

Т.е., при взгляде на 4Д-экстент работ можно увидеть либо трансакцию (через вьюпойнт «онтологии предприятия» ™) либо практику, через вьюпойнт системного подхода. И тогда люди в этой деятельности могут выступать как акторы, дающие и выполняющие обещания, либо как стейкхолдеры, занимающиеся деятельностью.
Вьюпойнт трансакций. Обсуждается в терминах RAA (Responsibility, Accountability, Authority) – ответственность за исполнение, ответственность за результат и полномочия оргпозиции. Фокус на исполнении обещанного (управленческий аспект).

Вьюпойнт практик. Обсуждается в терминах практик, ролей, команд, назначенных на исполнение практик , и освоенных практик (capabilities). Фокус на том, что и как сделать (инженерный аспект).

Онтологический параллелограмм позволяет четко увидеть, что в обеих схемах мы говорим про поведение, но в одном случае мы ссылаемся на поведение в трансакции, а в другом в поведении в деятельности. И модель такого поведения можно и в том и в том случае назвать (сослаться, знак, sign) ролью.
Проектные менеджеры часто не озабочены тем, как будет выполнена задача, деятельностный аспект их не интересует, это четко выражено в PMBOK, который не привязан к предметной области и описывает типовые трансакции, которые хорошо бы производить в проектах. И для проектного менеджера стейкхолдер – это тот, кто обещает и исполняет. Способность повлиять на результат проекта и на целевую систему для менеджера проекта заключается именно в исполнении или неисполнении трансакций. И лидерство они понимают как распределение RAA.
Инженеры предприятия и другие системные инженеры интересуются деятельностным аспектом, т.к. обеспечивающие системы строятся с учетом обратного маневра Конвея, игнорировать деятельностный аспект они не могут. Поэтому они видят в работах не трансакции, а воплощенные, поставленные  практики, которые состоят из модулей процессов, проектов и кейсов. И если менеджеры проектов назначают акторов на модули работ (менеджерское мышление - модульно), то инженеры предприятия назначают команды на практики (инженерное мышление в первую очередь компонентное). И лидерство в инженерии предприятия подразумевается как соответствие, исполнение ролей, назначенных членам команды.
Пунты сравнения
Вьюпойнт трансакций-акторов
Вьюпойнт практик-стейкхолдерских ролей
Метод описания
DEMO
ArchiEssence
Фокус на
Кто кому что делает
Как технологически устроена деятельность
Связь с целевой системой
Напрямую не связан
Жизненный цикл проектируется от целевой системы
Больше подходит для
Реинженерии деятельности
Синтеза новой деятельности
Аспект людей
RAA
Лидерство
Модель личности
Актор
Стейкхолдер

Другими словами, когда мы говорим про «людей», всегда надо уточнять, про какой уровень  системной холархии человеческого капитала идет речь.
Холархия человеческого капитала. Темпоральные части личностей.

Заключение
1) Можно правильно исполнять трансакции. Отправлять полномочия, нести ответственность. Трансакционная модель явно заложена в диаграммах Гантта – кто что кому обещает с указанием сроков и акторов.
2) Можно правильно производить целевую систему. Определять компетенции, практики, технологии. Модель практик явно заложена в диаграммах Архимейта с указанием стейкхолдеров и практик.

[1] Enterprise ontology, 2006 Jan Dietz

понедельник, 9 октября 2017 г.

MVP тренинга по системному лидерству - есть!

В воскресенье, 08 октября, прошел тренинг 7-го потока школы системного мышления "Системное лидерство".

Материал давался по новой схеме:
1) Привязка к материалу курса системного мышления через понятие "поставленных практик" (capabilities). Поставленные практики рассматриваются на уровне исполнителей стейкхолдерских ролей, на уровне команд и на уровне предпринятия.
2) Системная холархия команд.


Разбор двух систем - "квалифицированный исполнитель/воплощение компетенции" и "команда проекта". Модель жизненного цикла и практики, применяемые к этим системам.
3) Вьюпойнт и определение поставленной практики лидерства, системное окружение поставленной практики лидерства. Пятиуровневая стратегия работы с человеческим капиталом.
4) Фитнес лидера как готовность к действию. Причины провала программ развития и обучения, постановки практики лидерства.
5) Эссенс (основы) лидерства, подальфы "Команды", дела, компетенции, паттерны.
6) Симуляция организационного изменения.


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

Несколько важных для меня моментов со вчерашнего дня.
1) В ШСМ сформировался язык для обсуждения capabilities (поставленных, освоенных практик). Понимание уже почти достигнуто.
2) 4Д-экстенсионализм и системный подход позволяет передать материал по лидерству если не за 1, то точно за 2 дня, что уже намного круче, чем у тех же Global Integration. Для меня это еще один proof-of-concept самого фреймворка системного мышления в варианте ШСМ.
3) Кейс по оргизменению был решен за невероятное время - 1 час 10 минут на первый шаг. Обычно у команд уходит около 2,5 часов, качество принимаемых решений на первой итерации при этом обычно намного хуже, чем было у группы.
4) Мало того, что группа очень быстро решила кейс, она успела еще отрефлексировать, что в их плане действий слабо проработана альфа "Технологии". При этом системные рассуждения с выявлением стейкхолдеров, требований, разработки архитектуры и планирования жизненного цикла шли автоматом без подсказок.


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