Сценарное планирование, бизнес-кейс, BSC программы, КонЭксп

Решил развернуть схему, которую не раз показывал, и объяснить связь сценарного планирования, "дорожных карт", КонЭксп, бизнес-кейса (это все байесовские обоснования выбранного стратегического курса, заложенные в BPM-движок, а не ТЭО инвестпроекта, именно что "дело по стратегированию").
Пояснительный текст и вводный вебинар по управлению программами на основе этой диаграммы и итеративной-эволюционной модели жизненного цикла будут позже.

Посмотреть схему в PDF 

Роли: разбор в 4Д

Роли: разбор в 4Д
Перевод Roles: A Four-Dimensional Analysis by Matthew West, 2008

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

1.Какие роли были найдены в литературе и индустрии
Хороший обзор литературы по ролям можно найти у Steimann [11], большое исследование сделал Loebe [3].
В литературе можно найти следующие роли:
1. Отношенческие роли (например, Loebe [3], Masolo et al [3], Sowa [3])
2. Участвующие или процессуальные роли (Loebe [3], Sowa [1])
3. Социальные роли (Loebe [3], [12] Msolo et al [6], Smith [7], Mizigouchi [13])
4. Функциональные роли (например, ISO15926)
Steimann [11] определил свойства ролей, а Loebe [12] развил эти определения в виде вопросов. Результат показан в списках ниже.

Steimann
У роли есть свои свойства и поведение
Роли зависят от отношений
Объект может одновременно играть несколько ролей
Объект может играть одну роль несколько раз одновременно
Объект может занимать роль и выходить из роли
Последовательность занятия и выхода из роли может быть предметом ограничения
Объекты несвязанных типов могут играть одинаковую роль
Роли могут играть роли
Роль может передаваться от одного объекта к другому
Состояние объекта может быть привязано к роли
Свойства объекта могут быть привязаны к роли
Роли ограничивают доступ
Разные роли могут разделять структуры и поведение
Объект и его роли разделяют идентичность
Объект и его роли имеют разную идентичность

Loebe
Роль как индивид против роли как концепта [1, 14, 15]. Существуют ли индивиды ролей или роли являются особым видом концепта?
Идентичность роли [14, 15]. Есть ли у роли идентичность отличная от той, которая есть у исполнителя?
Зависимость, относительная природа ролей и контексты [2]. В каком смысле роли зависят от остальных сущностей?
Роли с собственными свойствами и поведением [1, 11]. Все ли роли обладают своими свойствами и поведением?
Динамичность и гибкость в отыгрывании ролей (dynamicity and anti-rigidity) [4, 5, 6, 9]. В каком смысле роли рассматриваются как “динамичные”? Все ли роли могут быть гибкими?
Роли, которые играют роли [8, 9]. В каких отношениях могут находиться роли в общем?
Множественность ролей [3, 4, 7, 9].
Иерархии обобщения с ролями [13]. Как можно объединить ролевые и неролевые термины в единую иерархию обобщения?
Ролевая абстракция и дополняющие роли. Почему имеют смысл абстракции в отношенческих процессуальных ролях? Что должна значить дополнительность на уровне концептов?
Чистые роли. Какая разница между ролями “ребенок” и “сын”?
Объединение ролей с помощью ква-индивидов. Должны ли индивиды ролей идентифицироваться/обозначаться ква-индивидами?

Метауровневый статус ролей. Являются ли индивиды ролей истинными сущностями с метауровня представленной модели?

Вот некоторые вопросы, по которым есть разногласия:
1. Чем являются эти разные виды ролей - индивидами или классами? И если индивидами, то абстрактными или конкретными?
2. Типы ролей являются специализацией базовых типов или нет? Например, является ли наемный сотрудник специализацией человека?
3. Идентична ли роль объекту, который играет эту роль?

2.Роли в отношениях

Я хочу начать с различения того, как что-то представлено и того, чем оно является. Например, вполне допустимо представить деятельность как связь, в которой роли в этой деятельности представлены местом в этой связи. Однако это не делает деятельность связью. Деятельность - это индивид, который вызывает изменение. С другой стороны отношение есть что-то статичное, существующее в течение своего срока и области применимости. Отношение может либо не может быть представлено связью, альтернативным вариантом, например, могло бы быть представление отношения классом, а роли в этом отношении связями. Здесь я больше говорю про отношения и деятельность, чем про связи.
В 4Д-экстенсионализме первичными объектами являются пространственно-временные экстенты и классы, где экстенты служат основанием идентичности. Поэтому я рассмотрю три типа отношений:
1. Отношения между индивидами
2. Отношения между индивидами и классами
3. Отношения между классами
2.1 Роли индивидов в отношениях
Я должен начать с пространственно-временной диаграммы владения как примера отношения между индивидами, рис. 1.

Рисунок 1. Пространственно-временная шкала для показа отношения между индивидами
Рисунок показывает как я владею своей машиной. Серые стрелки представляют меня в течение всей жизни и машину Х в течение всего ее существования, показано, что начало и окончание моей жизни и существования машины находится за пределами диаграммы. Черные прямоугольники на этих стрелках показывают мое состояние владения машиной и состояние машины, которой я владею. Черная рамка показывает объединение этих состояний в отношение владения. Обращаю внимание, что отношение является пространственно-временным экстентом. Стрелки показывают классификацию каждого состояния в подходящий класс, в случае закрашенных областей стрелок это классы ролей. Светло-серая вертикальная стрелка представляет период, временной частью которого является отношение. То, что обычно представляется простым отношением, по факту состоит из отношений часть-целое.
Особым случаем этой типовой ситуации является часть-целое. На рисунке 1 этот случай приведен дважды, роли владельца и владеемого являются частями отношения владения, а само отношение владения является частью периода, в котором это владение происходит.
Можно заметить, что сложные отношения между индивидами разбиваются на отношения либо классификации либо состава. Я предполагаю, что это справедливо для всех не примитивных совпадающих во времени отношений между индивидами, примером не совпадающих по времени отношений может служить отношение между учителем истории и Наполеоном, в тот момент, когда учитель рассказывает о Наполеоне. Masolo [4] и Kozaki [10] пришли к таким же выводам.
2.2 Роли в отношениях между индивидами и классами
На рисунке 1 также приведен пример отношения классификации между классом и индивидом, оно показано стрелкой. Классификация является особым случаем, т.к. она является примитивным отношением, которое нужно, чтобы вообще сказать что-либо. Однако оно показывает природу отношений между индивидами и классами. Ключевым моментом является его временный характер. Отношение существует между состоянием индивида, его ролью, для которого это отношение верно, и классом. В случае классификации это поддерживает экстенсионализм классов, т.к. состав класса меняется со временем, состояния, которые содержат в себе  период действия отношений, просто являются членами класса, который в этом случае является постоянным суждением. Несмотря на то, что классификация является особым случаем, эта схема соблюдается между остальными индивидами и классами.
2.3 Роли в отношениях между классами

Рисунок 2 приводит пример отношений между классами. Построен на примере, который показан ранее. Нотация:
- не закрашенный ромб показывает простое отношение, линии связывают связанные объекты;
- не закрашенный ромб с двойным штрихом показывает класс отношений, например, набор отношений;
- закрашенный ромб показывает отношение между классом отношений и классом роли, которые участвуют в отношениях член класса;
- пунктирная стрелка показывает следствие того, что отношение существует между ролями, относящимися к классу отношений;
- жирные линии показывают отношения специализации, подкласс на стороне жирной точки;
- молния означает выноску названия объекта;
- как и на рисунке 1 стрелка показывает отношения классификации с членом на конце стрелки.
Если мы начнем с нижней части диаграммы, мы обнаружим отношение между моим владением машиной и моей машиной. Это отношение классифицировано как отношение, составленное из отношений ownership by owned. Этот класс, в свою очередь, относится к классам ownership и owned, это показывает, что они являются классами играемых ролей в составе отношений ownership by owned.
Двигаемся по диаграмме вверх, и видим, что состав ownership by owned есть специализация состава, и что ownership есть специализация класса ролей whole, а owned есть специализация класса ролей part. Наконец, мы видим, что и whole и part есть специализация пространственно-временного экстента.
Теперь, в добавление к сказанному выше, есть отношение между классами ownership и owner, и отношение между whole и part. Их существование подразумевается наличием классов отношений, показанных началом пунктирной стрелки. Теперь, поскольку у нас есть отношения между классами, они сами начинают играть роль. Это все потому, что классы находятся вне времени, поэтому если отношение верное, то оно всегда верное. Также, как и с отношениями между индивидами, есть и класс отношений для отношений между классами. Это отношение состава по классам (composition by class), показано почти на самом верху диаграммы. Отношения выше показаны как члены класса.
3.Роли индивидов в деятельности

Рисунок 3 показывает, как роли появляются в деятельности. Этот пример показывает замену лопаток насоса. Использована та же нотация, что и на рисунке 1. Вначале кто-то в инженерном отделе создает запрос кому-то в отделе закупок на новые лопатки. Потом отдел закупок организации заказчика размещает заказ в отдел продаж организации поставщика. Отдел продаж затем запрашивает поставку лопаток в организацию заказчика у отдела поставок, который выполняет поставку, которую получает организация заказчика. Затем лопатки устанавливаются, подробности опущены.
Роли в этой деятельности есть состояния объектов во время этой деятельности. Деятельность состоит из ролей, которые участвуют в ней. Можно заметить, что схема ролей в деятельности такая же, как и схема отношений между индивидами. Различие между ними в том, что деятельность приводит к изменениям, а отношения - это про что-то неизменное.

4.Роли как заменяемые части системы

Как мы увидим с помощью анализа 4Д, социальные и функциональные роли описываются одинаковой схемой, поэтому, хотя они и рассматриваются по отдельности, я их объединил в один раздел.
4.1 Социальные роли
Социальная роль в человеческих отношениях определяется отдельно от человека, выполняющего эту роль, и время от времени человек, выполняющий эту роль, может меняться. Например, мэр Москвы, президент США или ректор МГУ.
Анализ социальных ролей в 4Д был представлен в [11]. Описанный здесь пример приведен на рисунке 4.

Рисунок показывает как Билл становится президентом на какой-то срок, т.о. состояние Билла также является состоянием президента США. Когда Билл покидает офис, его заменяет Джордж, и теперь он является президентом в течение определенного срока, т.о. состояние Джорджа есть также состояние президента США. В этом примере нужно отметить  4 вещи:
1. Социальная роль состоит из временной/темпоральной части тех, кто играет роль, пока они ее играют;
2. Социальная роль может изменить все свои части разом и пережить это изменение, и в этом ее отличие от физического объекта;
3. Социальная роль может проходить периоды, в которых она не существует, например, если есть промежуток времени, когда один человек покидает офис, а другой еще не вступил в должность;
4. Если нет США, то нет и президента США, т.е. социальная роль зависит от социальной системы, частью которой является. Mizigouchi [13] также распознает эту зависимость социальных ролей, но привязывает ее к контексту, не указывая явное отношение социальной роли как части социальной системы.
Следствием этого является наличие смысла у выражения “пожать руку президенту”, потому что президент реальный физический объект, хотя и не совсем обычный.
4.2 Функциональные роли
Функциональная роль это часть функционального объекта, которую можно полностью заменить, и при этом сохранить идентичность. Примерами могут служить колесо машины, двигатель самолета, или откачивающая помпа дистилляционной колонны обрабатывающего завода.

Последний пример, который я взял из [8] и [9], показан на рисунке 5.

В установке фильтрации нефти есть насос на дне дистилляционной колонны, с номером Р101. Насос с серийным номером изготовителя, Pump 1 установлен как Р101, и как таковой используется и обслуживается операторами завода. Они обеспечивают работу Р101, а не конкретного насоса, который установлен в эту позицию. Однако инженеры по обслуживанию регистрируют обслуживание Pump 1. В какой-то момент времени Pump 1 ломается и заменяется Pump 2. Операторы продолжают использовать замену насоса как Р101. Инженеры по обслуживанию ремонтируют Pump 1 и возможно устанавливают его в другое место на заводе выполнять другую функцию.
Как и с социальной ролью, необходимо заметить, что:
1. Функциональная роль состоит из временной/темпоральной части физического объекта, которая играет эту роль, в тот момент, когда он ее играет;
2. Функциональная роль может изменить все свои части в один момент и пережить это изменение, в отличие от физических объектов;
3. Функциональная роль может проходить периоды, в которых она не существует, например, если есть промежуток времени, когда один физический объект был убран, удален, а другой еще не был установлен;
4. Существование функциональной роли (Р101) зависит от существования установки фильтрации нефти.
Особо сложным является прийти к соглашению касательно периодов несуществования. Как что-то может не существовать, если я могу об этом говорить? Но достаточно просто осознать в чем дело, если сравнить это с обсуждением исторических фактов, которые сейчас не существуют. Возможно, будет понятнее на практическом примере. Если вы оператор завода и от вас требуют запустить насос Р101 в тот момент, когда на его место ничего не установлено, вы не сможете это сделать. И причина, по которой вы не можете это сделать - это то, что в этот момент эта вещь не существует.
4.3 Схожесть и различия функциональных и социальных ролей
Общая схема социальных и функциональных ролей очевидно одинаковая. Различие лишь в уровне реальности, в котором работает система. Можно посмотреть на разные уровни реальности и увидеть, что и на них могут существовать системы с заменяемыми частями. Например, в живых организмах орган может быть заменяемой частью.

5.4Д-онтология верхнего уровня для ролей

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

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

6.Обсуждение

В разделе 1 я привел список свойств и вопросов, которые Steimann и Loebe подняли в отношении ролей. Теперь, когда я рассмотрел 4Д онтологию ролей, я могу вывести из нее следствия, и приведу следующие суждения.
1. Роль, индивид в роли, суть состояние индивида, которое является отдельным объектом с отдельной от индивида, играющего роль, идентичностью. Поэтому у него есть свои свойства и поведение. Steimann [1, 10, 11, 14, 15], Loebe [1, 2, 4, 10, 11, 12].
2. Существование роли, индивида в роли, зависит и от индивида, который играет эту роль, и от отношения, деятельности или системы, частью которой является роль. Steimann [2], Leobe [5].
3. Т.к. нет никаких ограничений на то, чтобы одно состояние индивида перекрывалось с другим, объект может играть одну роль много раз или разные роли одновременно. Steimann [3, 4], Loebe [3].
4. Роль, индивид в роли, суть временная часть индивида, играющего роль. Steimann [5], Loebe [5].
5. Последовательность, в которое можно получать и освобождаться от ролей, можно ограничить. Steimann [6].
6. Индивиды несвзяанных типов могут играть одну роль. Steimann [7], Loebe [7].
7. Роли, индивиды в в роли, могут играть роли. Ничто не мешает одному индивиду в роли быть временной частью другого индивида в роли, что в 4Д означает, что одна роль играет другую. Steimann [8], Loebe [7].
8. Для заменяемых частей, все части могут быть заменены, и они могут проходить через периоды не существования. Steimann [13], Loebe [7].
9. Один тип роли может быть подтипом другой, и поэтому может разделять структуру и поведение. Steimann [13], Loebe [8, 9].
10. Деятельность или отношение построены из индивидов в ролях, которые участвуют в деятельности или отношениях. Loebe [9].
Особенно хочется заметить, что на множество вопросов удалось ответить в результате понимания, что роль суть состояние индивида, играющего роль.

7. Заключительная часть

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

8.Литература

[1] Sider, Theodore Four Dimensionalism - An Ontology of Persistence and Time 2001 Oxford University Press, ISBN 0-19-926352-3
[2] Hawley, Katherine How things persist Oxford: Clarendon Press 2001
[3] Loebe, F. 2003. An Analysis of Roles. Toward Ontology-Based Modelling. Master's Thesis, University of Leipzig.
[4] Masolo, C. and Guizzardi, G. and Vieu, L. and Botazzi, E. and Ferrario, R. (2005) Relational roles and qua-individuals. In: AAAI Fall Symposium on Roles, an Interdisciplinary Perspective, 2005, Virginia, USA. pp. 103-112. American Association for Artificial Intelligence (AAAI). ISBN 978-1-57735-254-9
[5] Sowa, J.F. Knowledge Representation: logical, philosophical and computational foundations Brooks/Cole - Thomson Learning, 2000, ISBN 0-534-94965-7
[6] Masolo, C., Vieu, L., Bottazzi, E., Catenacci, C., Ferrario, R., Gangemi, A., and Guarino, N., 2004. Social roles and their descriptions. In Ninth International Conference on the Principles of Knowledge Representation and Reasoning, Whistler Canada.
[7] B. Smith, Social Objects http://ontology.buffalo.edu/socobj.htm 2002
[8] ISO 15926-2:2003, Industrial automation systems and integration - life cycle data for process plant - Part 2: Data model.
[9] West, Matthew Some Industrial Experiences in the Development and Use of Ontologies EKAW04 Workshop on Core Ontologies, 2004
[10] Kozaki, K., Sunagawa, E., Kitamura, Y., Mizoguchi, R.,Fundamental Consideration of Role Concepts for Ontology Evaluation, Proc. of Evaluation of Ontologies for the Web (EON2006) 4th EON Workshop, Edinburgh, United Kingdom, May 22, 2006
[11] Steimann, F. On the representation of roles in object-oriented and conceptual modelling. Data & Knowledge Engineering, 35(1), 83–106, 2000
[12] Loebe, F. Abstract vs. social roles – Towards a general theoretical account of roles, Applied Ontology 2 (2007) 127–158, IOS Press
[13] Mizoguchi, R. et al The model of roles within an ontology development tool: Hozo, Applied Ontology 2 (2007) 159–179, IOS Press

Что такое успешность проектов, программ и портфелей

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

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

Тип деятельности	Цель	Успешность
Проект	Конкретный измеримый продукт за определенную стоимость, в определенный срок, с заданной спецификацией	Исполнение утвержденного плана проекта и договора поставки
Программа	Конкретные измеримые бизнес-эффекты, в достаточно широких пределах стоимости, сроков, с постоянно уточняющимися спецификациями множества продуктов, линеек продуктов, продуктовых платформ	Получение линейки продуктов и/или продуктовой платформы и процессов их разработки, производства, продажи и использования, которые дают запланированный бизнес-эффект и реализуют стратегию развития предприятия
Портфель	Эффективное использование ресурсов и возможностей предприятия	Выполнение краткосрочных финансовых  экономических показателей предприятия и положительная динамика этих показателей

Как устроено управление проектами организации?

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

Векторная диаграмма в высоком разрешении ПО ЭТОЙ ССЫЛКЕ

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

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

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

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

Современная матричная структура

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

Нужно понимать, что сейчас предприятия разбивают в двух плоскостях - как структуры подразделений (цех №2, СКТБ-15, корпоративный центр) и как орг.возможности (технологии имитационного и математического моделирования, автоматизированные системы интегрированного брифинга). Когда все необходимые компетенции и ресурсы для реализации орг.возможности совпадают со структурой подразделений, то говорят про функциональную организационную структуру. Все компетенции и ресурсы находятся в подчинении начальника подразделения и он ими распоряжается. В функциональных структурах часто получается так, что некоторые ресурсы недозагружены, и тогда им начинают ставить другие задачи, они становятся частью других орг.возможностей, например, инженеры отдела цифро-натурного моделирования изучают смежную дисциплину и технологии имитационного моделирования и часть времени работают над задачами симуляции и имитации в других проектах. В таких случаях говорят про матричную структуру организации. Орг.возможность является частью цепочки производственной кооперации. Например, программа разработки метеолокаторов может работать с внешними подрядчиками и заказчиками изолированно от всей остальной организации и почти с ней не взаимодействовать.

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

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

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

Деятельность по управлению портфелями, программами и проектами объединяется в системе управления ресурсами предприятия (ERP) и информационной системе управления проектами (ИСУП). В ИСУП поддерживаются текущие иерархические структуры работ (ИСР), расписание программы и дерево всех программ и проектов компании. В ERP осуществляется планирование финансов, материалов и персонала для операционной и проектной деятельности. Все работы программы делятся на пакеты планирования, а все работы проекта делятся на пакеты работ. Пакеты планирования распределяются между проектами программы, а пакеты работ распределяются между рабочими группами и отделами организации. В результате исполнения пакетов работ появляются системные элементы и рабочие продукты, которые сопровождают эти системные элементы - документация, данные измерений, обученный персонал. Системные элементы собираются в техническое решение, которое называется целевой системой. За целевую систему отвечает менеджер продукта.

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

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

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

Что такое успешность системы

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

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

Цели всегда в возможном мире, не в реальном.

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

Люди планируют и исполняют задуманное с помощью дисциплины в голове. Нет дисциплины - нет целей.

Дисциплины бывают научные, такие как физика, химия, математика, и прикладные, такие как бухгалтерский учет, строительство, транспортная логистика. Дисциплина в голове, но люди чаще всего используют какую-то технологию, чтобы практиковать эту дисциплину. Бухгалтер использует калькулятор, 1С и Экселевские таблицы, математик программный пакет R, справочники и поисковики по научным базам знаний, водители ездят по навигатору, а логисты используют GPS трекеры. Дисциплина и технология вместе называются практикой - практикой бухгалтерского дела, практикой вычислительной математики, практикой пассажирских перевозок, практикой транспортной логистики. Человек, который использует практику, называется практиком. Практик - это не человек, который презирает теорию, напротив, он очень хорошо знает теорию, использует ее на уровне дисциплины, подчиняет ей свои действия, и знает, как технология и инструменты поддерживают дисциплину. Он может планировать, ставить цели и достигать их с помощью выбранной практики.

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

Практика = дисциплина в голове + технология в месте проведения работ.

Если вы возьмете двух практиков в одной области, то их поведение будет похожим, они будут исполнять роль. Практик бухгалтерского учета исполняет роль бухгалтера РСБУ, а практик транспортной логистики роль логиста MRPII. И два разных человека, которые исполняют эту роль, будут исполнять ее похоже, потому что пользуются одинаковыми моделями и технологиями. В системном подходе людей с ролевым поведением, которое приходит из практики, называют стейкхолдерами.

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

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

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

Разберемся в этом подробнее. Есть точность постановки целей, она связана с точностью прогнозов. Точность прогнозов зависит от формальности, сложности и вычислимости моделей, например, если у вас есть сетевой график проекта строительства атомной станции, в котором надо построить 200 технически сложных зданий и сооружений, то в нем будет множество неопределенностей - от технических проектов зданий и сооружений до источников поставки строительных материалов и погоды. Вы не сможете сказать, что стройка займет 484 дня и будет стоить 34,897,110,212 Евро, вы дадите вероятностный прогноз, что с 90% вероятностью стройка займет от 314 до 610 дней и будет стоить от 22 млрд. до 46 млрд. Отсюда приходит понятие “пространства целей”. Т.е., нет какой-то одной SMART цели, есть куча точек в возможных мирах, попадание в которые устроит стейкхолдера.

Бытовой пример пространства целей. Вы пришли с ребенком в магазин и он видит там игрушку, которую очень хочет. У ребенка нет бюджетной дисциплины, он не понимает, что есть зарплата, есть сбережения, что у игрушки есть цена в этом магазине и есть цена в другом магазине и эти цены могут сильно различаться. Цель ребенка простая - получить игрушку, и если он получит игрушку по любой цене, он будет считать это успехом. Вы все это понимаете, и безоговорочным успехом для вас будет покупка этой игрушки за 50 рублей, а неуспехом покупка за 500 рублей. Где-то в промежутке есть пространство целей, достижение которых для вас приемлемо. Конечно, купить за 100 рублей намного лучше, чем купить 250, но вы готовы заплатить на 150 рублей больше сейчас и не возвращаться к этому вопросу.

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

“Быть довольным” - это купить игрушку за 50 рублей, это очень сложно сделать. А если стейкхолдер скажет, что результат никуда не годится, то ему будет нужно вам объяснить, почему им нельзя пользоваться и привести очень хорошие аргументы, это мало у кого получается.

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

Пример - людям во время разговора меняют собеседника и они этого не замечают

http://www.dailymail.co.uk/video/sciencetech/video-1215218/Experiment-switches-people-middle-conversation.html

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

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

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

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

Поэтому когда вы создаете успешную систему, то вы должны:

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

- создавать систему, менять реальный мир в соответствии с планами

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

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

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

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

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

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

прогнозирование планирование наука инженерия требований

изменение мира инженерия менеджмент

управление вниманием стейкхолдеров дисциплина обучение лидерство

Когда руководитель проекта становится руководителем программы

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

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

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

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

Чтобы понять стандарты ISO15288/12207, нужно различать целевую и обеспечивающую системы. Целевые системы поставляются заказчику, за них платят деньги, у них есть жизненный цикл и их строят инженеры. Целевой системой розничной торговой сети является магазин. У магазина есть жизненный цикл, его надо задумать, разработать, построить, запустить и открыть для покупателей, а потом закрыть. Обеспечивающие системы “протаскивают” целевую систему по жизненному циклу. Обеспечивающие системы - это организации, предприятия, процессы и проекты. Думают про целевые и обеспечивающие системы одинаково, но используют разные слова:

Целевая	Обеспечивающая
Продукт	Проект
Системная архитектура	Архитектура предприятия
Системные требования	Стратегия
Системные интерфейсы	Бизнес-интерфейсы (OLA, SLA)
Системные функции	Бизнес-функции
Конструкция, структура системы	Организационная структура (матричная)

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

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

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

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

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

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

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

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

“Да тут все то же, что и в том проекте!”.

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

Меняется ли что-то в окружении системы? - Скорее всего нет, но времени на изучение не дают.

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

Это же покупное изделие или продукт, зачем проектировать систему? Бери и настраивай.

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

В итоге, если вам нужно начать управлять программами, вам нужно:

- Изучить концептуальную дисциплину управления программами;
- Разработать модель жизненного цикла с использованием ISO15288/12207;
- Избегать ошибок повторного использования.