пятница, 16 ноября 2018 г.

The Guide to Lean Enablers for Managing Engineering Programs на русском

Цепочка предшествующих текстов:
Когда руководитель проекта становится руководителем программы
Оригинал:
Oehmen, Josef, (Ed.). 2012. The Guide to Lean Enablers for Managing Engineering Programs, Version 1.0. Cambridge, MA: Joint MIT PMI INCOSE Community of Practice on Lean in Program Management.
Конспект:
Руководство по факторам, которые способствуют экономически обоснованному управлению инженерными программами

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

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

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

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

В 40-х годах появились три новые предметные области: исследование операций, системная инженерия и проектное управление. Все вместе они позволили перейти к реализации очень больших и сложных инженерных и технических программ. 70 лет спустя Lean Advancement Initiative (LAI), Project Management Institute (PMI) и International Council of Systems Engineering (INCOSE) объединили усилия экспертов, чтобы вместе отобрать и объединить лучшие идеи и практики из этих трех областей, чтобы решать с помощью них сегодняшние проблемы.

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

Любое самое большое изменение начинается с первого шага. Реализуйте хотя бы один способствующий фактор (lean enabler) и вы можете увидеть разницу. Мы рекомендуем посмотреть на наши рекомендации, выбрать 2-3 и сделать их.

Опыт успешных программ доказывает, что наша просьба реалистична и стало быть вы тоже можете ее выполнить!

Josef Oehmen, PhD
May 2012, Cambridge, MA (USA)

Краткая сводка для руководства
Это руководство описывает находки, сделанные Joint MIT PMI INCOSE Lean in Program Management Community of Practice в проекте, который осуществляла эта группа в 2011-2012. Группа была составлена из представителей коммерческих и правительственных и учебных организаций. Находки, которые описаны в этом руководстве, основаны на лучших практиках из литературы, экспертного опыта реализации программ и данных, полученных от широкого сообщества специалистов.

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

Ядро документа составлено из 10 тем по количеству основных проблем управления инженерными программами и 43 основных и 286 подчиненных сопутствующих факторов, которые позволяют справиться с этими проблемами. Они также позволяют лучше объединить управление программой и системную инженерию и вести программу, приспособленную под обстоятельства, к совершенству.
Список основных проблем управления инженерными программами:
- Борьба с пожарами - запаздывающее исполнение программы.
- Нестабильные, нечеткие и неполные требования.
- Недостаточная согласованность и нескоординированность производственной кооперации.
- Практики оптимизированы локально и не учитывают работу предприятия в целом.
- Нечеткие роли, ответственность за исполнение и ответственность за результат.
- Запущенная культура программы, невнимание к компетенциям и знаниям команды.
- Недостаточное планирование программы.
- Неправильно выбранные показатели, системы показателей и KPI.
- Недальновидное управление рисками.
- Плохое управление закупками и контрактацией.
Способствующие факторы, структурированные по 6 принципам устранения потерь:
LE 1.x Уважайте людей в программе - 6 основных факторов и 38 вторичных
LE2.x Выявляйте пользу, которую видят ключевые стейкхолдеры заказчика - 6 основных факторов и 44 вторичных
LE 3.x Моделируйте жизненный цикл целевой системы, обосновывайте применение практик жизненного цикла и устраняйте потери - 11 основных факторов и 75 вторичных
LE 4.x Обеспечивайте проход работы через запланированные и выстроенные практики - 10 основных факторов и 64 вторичных
LE 5.x Позвольте стейкхолдерам заказчика самим определять пользу - 2 основных факторов и 10 вторичных
LE 6.x Стремитесь к совершенству всех практик - 8 основных факторов и 5 вторичных
Всего - 43 основных фактора и 286 вторичных

Влияние способствующих факторов на реализацию инженерных программ.
Три наиболее успешных программы, отобранных PMI Project of the Year Award, использовали от 60 до 75% факторов. Для остальных программ, которые попали в списки лучших, удалось найти свидетельства того, что они использовали около 30% факторов.

Мы обнаружили, что все факторы присутствовали как минимум один раз, а некоторые были популярнее остальных. Вот некоторые из наиболее часто используемых факторов:
- Строить культуру программы с уважением к людям (LE 1.1)
- Часто вовлекать стейкхолдеров на всем жизненном цикле программы (LE 2.3)
- Разрабатывать план коммуникаций (LE 3.11)
- На каждой программе использовать роль руководителя программы, который должен объединять и вести программу от запуска до окончания (LE 4.3)
- Дальновидно управлять неопределенностью и рисками, чтобы получить максимальные выгоды от программы (LE 6.6)
Отрасли и области, в которых реализовывались программы, самые разные.

147 способствующих факторов, которые указаны в Lean Enablers for Systems Engineering, 2009, включены в 329 факторов, перечисленных в этом руководстве.

Потери в инженерных программах
Перепроизводство информации:
- Производить больше, чем требует следующая практика
- Создавать документы, которые не запрашивали
- Избыточные и ненужные задачи
- Рассылка информации тому, кому она не нужна (например, почтовый спам)
- Отсылка нескольких образцов, когда запрошен был один
- Работа над неправильным некорректным релизом (работаю вхолостую)
- Недоиспользование имеющейся экспертизы, изобретение колеса
Ожидание:
- Ожидание информации либо принятия решения
- Информация есть или решение принято, но люди не ей пользуются и не исполняют
- Большие очереди в жизненном цикле
- Длительные согласования
- Ненужные повторяющиеся усилия
Ненужное движение информации:
- Переадресация
- Избыточное распространение информации
- Разрозненные технические средства, политически мотивированное географическое распределение работы (“сделано в 50 штатах”), недостаточное совместное размещение
Избыточная обработка информации:
- Избыточное уточнение информации
- Закрепление конструкции, отвечающей заданным требованиям (утверждение базиса конфигурации) происходит слишком рано и ведет к многочисленным итерациям
- Неконтролируемые итерации (слишком многие задачи повторяются, избыточная сложность)
- Недостаток стандартизации
- Преобразования данных
- 2D чертежи (необходимо везде использовать 3D)
- Использование избыточно сложного монолитного программного обеспечения без видимой причины (например, использование сложного софта, когда достаточно таблицы Эксель)
Запасы информации:
- Хранение большего количества информации, чем требуется
- Слишком большие промежутки между защитами и проверками
- Плохое управление конфигурацией и сложное извлечение и получение информации
- Плохое 5S (сортировка, соблюдение правил, содержание в чистоте, стандартизация, совершенствование) и в базах данных
Ненужное перемещение людей:
- Ненужные перемещения при выполнении задачи
- Людям нужно передвигаться, чтобы получить информацию или доступ к ней
- Ручное вмешательство, которое компенсирует недостаток систематичности
Переделки, дефекты:
- Убийственные “пере-”: переделка, переписывание кода, перепрограммирование, перетестирование…
- Нестабильные требования
- Нескоординированная сложная задача, которая занимает слишком много времени на выполнение и результат которой становится невостребованным к моменту завершения так что она должна быть переделана
- Неполная, расплывчатая или неточная информация
- Инспекции по выявлению дефектов
К сожалению, в большинстве случаев топ-менеджмент программы заперт в рамках мышления по отдельным функциям в деятельности. Им не хватает понимания и признания критичности компетенций их контрагентов, и понимания того, как компетенции контрагентов дополняют их компетенции. PMI и INCOSE договорились, что будут всеми силами содействовать объединению проектного менеджмента и системной инженерии. Руководитель программы должен хорошо разбираться в обеих дисциплинах.


Тема 1. Борьба с пожарами - запаздывающее исполнение программы.
- ресурсы направляются на решение проблем, а не на их предотвращение
- конкуренция за ресурсы
- меняющиеся приоритеты проекта
- нечеткое или неподходящее распределение ответственности и прав на принятие решений
- недостаток управления приоритетами или согласованности в целях сотрудничающих организаций
- недостаточное понимание риска программы
- нет согласованной руководящей команды, которая представляет все важные функции
Тема 2. Нестабильные, нечеткие и неполные требования.
- неполное понимание требований стейкхолдеров
- недостаточное понимание всей сложности требований, пропуск производных требований
- нестабильные приоритеты программы
- стейкхолдеры не в состоянии четко выразить свои требования
- неправильное понимание требований стейкхолдеров
- неполное доведение до людей об изменениях в стоимости, сроках и требуемых характеристиках в течение программы
- требования формулируются с нарушениями правил
- недостаточная адаптация базисов по срокам, стоимости и техническим характеристикам к меняющемуся окружению и предположениям программы
- требования к соответствию (внутренние требования, стандарты, законодательные требования) различных стейкхолдеров не связаны друг с другом, не объединены, могут конфликтовать, все это приводит к дополнительной нагрузке, несогласованности требований и не дает возможности эффективно согласовывать похожие требования
- нечеткое понимание восприятия пользы стейкхолдерами
- отсутствие учета определенных ранее потребностей
- запрос коммерческого предложения выпущен заказчиком слишком рано
Тема 3. Недостаточная согласованность и нескоординированность производственной кооперации.
- конкурирующие требования к ресурсам
- недостаточное управление и согласованность приоритетов работы стейкхолдеров и организаций в производственной кооперации
- нечеткие приоритеты при исполнении непосредственных бизнес-целей (например, прибыльность текущей программы) и ответственностью за другие программы (например, сбор и распространение полученного опыта, постоянные улучшения)
- неструктурированная или незапланированная коммуникация стейкхолдеров
- нечеткое либо различное понимание состава предпринятия
- недостаточная интеграция стейкхолдеров, в особенности с заказчиками и поставщиками
Тема 4. Практики оптимизированы локально и не учитывают работу предприятия в целом.
- недостаток усилий по оптимизации на уровне всего предприятия, оптимизация только локальных процессов и организации
- недостаток стандартизации процессов
- что касается потока создания ценности, недостаток понимания того, как работать с различными видами потерь,
- отсутствие механизмов улучшения потока создания ценности
Тема 5. Нечеткие роли, ответственность за исполнение и ответственность за результат.
- ведущее к проблемам распределение ответственности и прав принимать решения
- недостаток согласованности и интеграции между программным менеджментом и системной инженерии
- отсутствие поощрений и мер по поддержанию чувства личной ответственности за планы и результаты
- нет согласованной команды управления, которая бы представляла все важные функции
- роли и ответственность персонала программы и линейных функций не определены
- несогласованные и мешающие совместной работе KPI и премии персонала программы, команд проектов, поставщиков, заказчиков и других стейкхолдеров
Тема 6. Запущенная культура программы, невнимание к компетенциям и знаниям команды.
- неэффективные практики передачи знаний от опытных сотрудников и членов команды к новым членам команды (в частности, это происходит в отраслях со стареющими кадрами)
- недостаток механизмов обратной связи, которые бы превращали накопленный опыт в действия, новые практики не ставятся по результатам накопленного опыта и рекомендаций
- нет адекватного распространения накопленного опыта по всему предприятию
- неадекватное определение личных потребностей в развитии навыков
- накопленный опыт не документируется
- неадекватный сложности задачи опыт команды
- недостаточный уровень личных навыков
Тема 7. Недостаточное планирование программы.
- нереалистичные базисы по срокам, стоимости и техническим характеристикам
- недостаточное распространение внутри программы изменений по стоимости, срокам и техническим характеристикам
- недостаточная адаптация базисов по срокам, стоимости и техническим характеристикам к меняющимся предположениям и окружению программы
- нереалистичное расписание программы
- проблемы с общением на нужном уровне организационной иерархии во время запуска и закрытия проекта
- оценки не отражают все аспекты жизненного цикла
- нехватка вероятностных оценок
- слишком редкие обновления оценок стоимости, сроков и технических характеристик на ранних стадиях программы и во время исполнения
Тема 8. Неправильно выбранные показатели, системы показателей и KPI.
- показатели дают ретроспективную оценку и не помогают предсказывать появление проблем
- показатели не учитывают человеческое поведение (теория игр)
- нет метрик для кросс-функциональных процессов
- распределенные и несвязанные ИТ-системы и хранилища данных не позволяют эффективно собирать и объединять данные для расчета показателей
- недостаточный присмотр за соблюдением базисов по срокам, стоимости и техническим характеристикам
- показатели ориентированы на короткий период
Тема 9. Недальновидное управление рисками.
- недостаточное вовлечение необходимых для управления рисками специалистов
- неполное понимание рисков программы
- недостаточное финансирование и ресурсное обеспечение мероприятий по управлению рисками (выявление, оценка, предотвращение и отслеживание)
- пренебрежение человеческим фактором при управлении рисками, такими как культура сокрытия ошибок и плохих новостей
- отсутствие тесной связи управления рисками и других практик жизненного цикла
- недостаточное внимание на быстрое устранение выявленных рисков
Тема 10. Плохое управление закупками и контрактацией.
- заказчик выпускает запрос на предоставление коммерческого предложения слишком рано, еще до того, как достаточно определится с требованиями
- чрезмерное влияние финансовых ограничений
- контрактные ограничения и стимулы не согласованы с задачами программы и профилем риска
- нет подходящей практики обкатки технологии для программ (технические характеристики и системная интеграция)
- непонимание между операционным менеджментом программы и контрактными требованиями


Обзор способствующих факторов

Как читать таблицы:

Первая строка - группа практик стандарта по управлению программами PMI. Т.е., открываете стандарт PMI и смотрите общий контекст применения практик.
Вторая строка - какие проблемы решает фактор.
Третья строка - группа практик стандарта по системной инженерии INCOSE. Открываете руководство и смотрите общий контекст применения практик. 1. Относиться к людям как к самому важному активу
1.1 Строить культуру программы, основанную на уважении к людям.

1.1.1 Осознавайте, что программа проваливается или становится успешной в первую очередь за счет усилий людей, а не имеющихся практик. Обращайтесь с людьми как с ценными активами, а не как с материалом.
1.1.2 Вкладывайтесь в отбор и развитие людей, чтобы было какими силами достигать совершенства в программе и предприятии. Убедитесь, что практика найма соответствует реальным потребностям программы в талантах и компетенциях.
1.1.3 Руководитель программы должен быть ментором и показывать своим примером желаемое поведение. Он должен быть образцом доверия, уважения, честности, воодушевления, командной игры, надежности, мотивации и стремления к совершенству для всей команды.
1.1.4 При найме людей ориентируйтесь на страсть к делу, “искру в глазах” и широкий профессиональный кругозор, а не только на конкретно сейчас нужные вам навыки. Это принцип “нанимайте таланты, обучайте их навыкам”. Не поручайте эту работу компьютерам, которые ищут совпадения по ключевым словам.
1.1.5 Вознаграждайте за заслуги команды и оценивайте способность работать в команде при найме и продвижении. Поощряйте командообразование и командную работу.
1.1.6 Практикуйте обход территории, не управляйте сидя на рабочем месте. Сходите и посмотрите как все происходит лично.
1.1.7 Стройте культуру взаимного доверия и поддержки, когда людям не стыдно и не опасно просить помощи.
1.1.8 Поощряйте плотное взаимодействие и тесные отношения между внутренними заказчиками и поставщиками. Не позволяйте людям быть “одинокими волками”.
1.1.9 Когда набираете руководство программы, включая менеджера программы, предпочитайте командных игроков и людей, способных мыслить в группе. Люди с идеальными резюме и дипломам не всегда оказываются командными игроками.
1.1.10 Когда решаете вопросы, атакуйте проблему, а не людей.
1.2 Мотивировать людей, делая высшую цель и элементы программы прозрачными.
1.2.1 Создавайте общее видение, которое вызывает в людях лучшее и вдохновляет их.
1.2.2 Удостоверьтесь, что каждый понимает свой личный вклад в успешную реализацию общего видения.
1.3 Поддерживать автономный стиль работы.
1.3.1 Используйте и передавайте на места ответственность и полномочия действовать, чтобы решения принимались на как можно более низком, но приемлемом уровне.
1.3.2 Избавляйтесь от страха на рабочем месте. Поощряйте решение конфликтов на низовом уровне.
1.3.3 Разрешите совершать некоторое количество “ошибок” в контролируемых условиях на низовых уровнях, чтобы люди учились принимать риски и накапливать опыт.
1.3.4 В своей зоне ответственности и в рамках, дозволенных политиками программы, поощряйте людей принимать на себя ответственность и действовать. Реализуйте принцип: “Лучше просить прощения, чем разрешение”.
1.3.5 Четко доводите причины и принципы, по которым были приняты управленческие решения. При этом поощряйте низовую культуру постоянного улучшения, творчества и предпринимательства.
1.4 Ожидать от людей стремления к профессиональному совершенству и карьерному продвижению и поддерживать их в этом.
1.4.1 Основывать и поддерживать сообщества практик.
1.4.2 Вкладываться в развитие персонала.
1.4.3 Удостовериться, что все прошли обучение тому, как разумно приспосабливать практики под обстоятельства, чтобы избегать потерь.
1.4.4 Обучить лидеров на всех уровнях организации глубокому пониманию методов разумного приспособления практик под обстоятельства.
1.4.5 Поощрять и уважать профессиональное признание заслуг и продвижение по результатам работы.
1.4.6 Заведите собрание старейшин, которые показывают пример другим и задают образец поведения.
1.4.7 Закрепляйте профессиональное совершенство посредством наставничества, дружеской оценки коллегами, обучения, тренингов и с помощью других средств.
1.5 Поощрять способности быстро учиться и улучшаться.
1.5.1 Поощряйте и вознаграждайте постоянное саморазвитие. Саморазвитие может идти как по учебным материалам, так и на основе практического опыта.
1.5.2 Обеспечьте легкий доступ к знающим экспертам как к ресурсам и как к наставникам, включая их участие в дружественной оценке коллег.
1.5.3 Цените необычные идеи, которые люди реализуют в программе.
1.5.4 Фиксируйте и распространяйте скрытое знание, чтобы программу не трясло при смене команды.
1.5.5 Разрабатывайте стандарты с оглядкой на человеческий фактор, учитывайте наличие опыта и особенности восприятия.

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

1.6 Поощрять развитие личных контактов и взаимодействий.

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

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

1.6.3 Поощряйте прямой человеческий контакт, чтобы построить личные отношения.

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

1.6.5 Вовлекайтесь и поддерживайте интенсивное взаимодействие со стейкхолдерами.

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

1.6.7 Поощряйте и когда надо документируйте открытый обмен информацией внутри программы.

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

2. Максимум пользы от программы
2.1 Установить, в чем видят пользу и выгоды от реализации программы стейкхолдеры.

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

2.1.2 Определять добавленную пользу в терминах стейкхолдеров заказчика и их потребностей.

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

2.1.4 Дальновидно решайте возможные конфликты пользы и ожиданий различных стейкхолдеров и ищите полного согласия.

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

2.2 Сосредоточьте все мероприятия программы на выгодах, которые планирует принести программа.

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

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

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

2.3 Часто вовлекайте стейкхолдеров на всем жизненном цикле программы.

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

2.3.2 Установите частое и эффективное взаимодействие между внутренними и внешними стейкхолдерами.

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

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

2.3.5 Структурируйте коммуникации стейкхолдеров (кто, с какой частотой, что).

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

2.3.7 Регулярно и без утайки сообщайте стейкхолдерам о достижениях и основных препятствиях программы.

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

2.3.9 Терпеливо слушайте комментарии и опасения стейкхолдеров и цените их точку зрения и вклад.

2.3.10 Четко отслеживайте предположения и изменение обстановки, которые влияют на требования стейкхолдеров и их восприятие выгод программы.

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

2.4 Разрабатывайте высококачественные требования к программе с участием стейкхолдеров заказчика перед запросом коммерческих предложений и стартом исполнения программы.

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

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

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

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

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

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

2.4.7 Требуйте личной и корпоративной ответственности рецензентов требований, пока программа не продемонстрирует успех.

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

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

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

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

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

2.5 Уточняйте, расширяйте и расставляйте приоритеты по требованиям рано, часто и дальновидно.

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

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

2.5.3 Используйте методы представления и моделирования архитектуры системы (3D CAE, цифровые двойники, модели, симуляции и инструменты проектирования ПО), которые позволяют взаимодействовать с заказчиком и другими стейкхолдерами и выявлять их требования.

2.5.4 Слушайте и записывайте неявно выраженные требования заказчика.

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

2.5.6 Настойчиво повышайте зрелость требований стейкхолдеров, например производите изучение вариантов решений, исследуйте реализуемость технических решений, делайте виртуальные прототипы.

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

2.5.8 Создавайте эффективные каналы уточнения требований, например, включайте стейкхолдеров заказчика в работу команды проекта.

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

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

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

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

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

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

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

3.1.1 Планируйте разработку только того, что нужно разрабатывать.

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

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

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

3.2 Интенсивно проектируйте предпринятие и управляйте программой, чтобы достичь ее максимальной эффективности как системы.

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

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

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

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

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

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

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

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

3.3 Развивайте несколько наборов решений параллельно.

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

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

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

3.3.4 На ранних стадиях разработки исследуйте несколько вариантов концепций продукта, архитектур и дизайнов.

3.3.5 Исследуйте ограничения и изучайте последствия выборов в натурных экспериментах прежде чем выберете конкретные параметры изделия.

3.3.6 При прочих равных выбирайте более простое решение.

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

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

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

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

3.5 Активно используйте ресурсы на старте программы и интегрируйте предпринятие в цепочку производственной кооперации.

3.5.1 С самого начала планируйте проблемоустойчивое исполнение и правильное выполнение задач с первого раза в нормальных обстоятельствах. Не надо героически решать проблемы по мере их возникновения.

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

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

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

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

3.5.6 В критических подпроектах проведите мероприятия, описанные в п. 3.5.5

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

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

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

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

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

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

3.5.13 Убедитесь, что руководство уделило достаточно времени на планирование решения технических проблем.

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

3.5.15 Активно вовлекайте ключевых поставщиков в планирование программы и на ранних стадиях программы.

3.6 Используйте вероятностные оценки при планировании программы.

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

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

3.7 Будьте дальновидны при работе с поставщиками, не допускайте возникновения конфликтов с ними в будущем, предсказывайте риски и уклоняйтесь от них.

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

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

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

3.7.4 Указывайте своим партнерам и поставщикам на недостатки в их работе и помогайте им улучшать практики. Этим вы покажете свое уважение к ним.

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

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

3.7.7 Четко и однозначно доводите до поставщиков все ожидания, включая системные контексты и потребности, все процедуры работы, сдачи-приемки и испытаний. Убедитесь, что требования, которые вы им передали, не изменяются.

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

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

3.7.10 Ключевые поставщики должны быть частью вашей команды.

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

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

3.8 Разрабатывайте опережающие показатели и метрики для управления программой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.10.2 Дайте руководящие указания и отслеживайте их исполнение в части повышения зрелости технологии и вставки технологии в рабочие процессы предприятия. Четко определите какой уровень технологических рисков и связанных с ними рисков по стоимости и срокам допустим в разных обстоятельствах (паралич от анализа против провала программы).

3.10.3 Полностью осознавайте риски и возможности использования новой технологии или производственного процесса.

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

3.10.5 Чтобы справиться с технологическими рисками программы активно применяйте практику управления рисками. У вас должны быть планы реагирования на технологические проблемы.

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

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

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

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

3.10.10 Обеспечьте четкое и единое понимание того, какие технологии и технологические стандарты будут использованы в программе.

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

3.11 Разрабатывайте план коммуникаций.

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

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

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

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

4.2 Обеспечивайте четкие зоны ответственности и полномочий (RAA, responsibility, accountability, authority) в течение всей программы от сбора начальных требований до итоговой поставки.

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

4.2.3 Четко донесите полномочия и ответственность руководителя программы до всех стейкхолдеров.

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

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

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

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

4.3.1 Выращивайте исключительно компетентных стейкхолдеров “руководитель программы”. У них должны быть хорошие навыки управления разработкой, людьми, они должны уметь взять на себя задачу достижения успеха программы.
4.3.2 Убедитесь, что у руководителя программы есть необходимый опыт в: бизнесе, общем менеджменте, инженерный опыт, лидерские навыки и навыки управления людьми, есть опыт работы в сложных инженерных программах.

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

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

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

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

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

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

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

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

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

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

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

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

4.5.7 Опишите четкую понятную практику принятия критических решений, решения конфликтов интересов и приведения к консенсусу.

4.5.8 Проблемы должны исправлять те, кто их создал, там, где они появились и как можно скорее.

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

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

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

4.6 Объединяйте все функции и элементы программы посредством корпоративного управления программы (program governance).

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

4.6.4 Используйте модель стадий-гейтов для планирования и исполнения программы. Активно используйте функциональную экспертизу в гейтах.

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

4.6.6 Согласуйте показатели и KPI по всей программе.

4.7 Используйте эффективную и результативную коммуникацию и координацию с командой программы.

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

4.7.2 Максимально координируйте работы и поток.

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

4.8.1 Введите стандарты на показатели и системы отчетности в программе.
4.8.2 Выявите повторяющиеся мероприятия в программе и введите на них стандарты.
4.8.3 Поощряйте стандартные практики проектирования с инженерными чек-листами, стандартными архитектурами целевых систем, модулями, шинами и платформами.
4.8.4 Поощряйте стандартизацию практик разработки, производства и управления.
4.8.5 Поощряйте стандартизацию навыков с их тщательной тренировкой и наставничеством, ротациями, стратегическими назначениями и оценкой компетентности.
4.9 Думайте, что практично делать в конкретных обстоятельствах, чтобы обеспечить непрерывный ход работ в программе.

4.9.1 Часто устраивайте формальные точки интеграции в добавок к точкам интеграции на уровне программы. Доискивайтесь до истинных причин с использованием техники “5 почему”. Выравнивайте поток принятия решений и поток работ. Решайте все проблемные моменты взаимодействия в формальных точках интеграции. Обсуждайте выборы и варианты.
4.9.2 Будьте готовы оспорить предположения заказчика, основываясь на технической экспертизе и дисциплинах не глядя на должности и звания. Ваша цель - увеличить стабильность программы.
4.9.3 Сведите к минимуму передачи результатов работы при технологических переделах. Это поможет уменьшить количество переделок.
4.9.4 При назначении задач учитывайте пользу, которую приносит исполнение задачи. Используйте профессионалов, чтобы делать задачи, которые приносят пользу; если профессионалы не нужны, либо задачу просто надо сделать, а пользу она не приносит, используйте обычные ресурсы.
4.9.5 Используйте единую систему измерений во всех проектах и единые справочные данные.
4.9.6 Используйте инструменты бережливого производства, чтобы облегчить протекание информации и свести к минимуму сдачи-приемки промежуточных результатов. Перейдите на малые партии при работе с информацией, держите минимальные запасы информации, сводите к минимуму количество одновременных задач на исполнителях, стремитесь уменьшать сроки исполнения задач, расширяйте ширину каналов связи, вводите стандарты, организуйте рабочие ячейки и обучение.
4.9.7 Уменьшайте количество используемых компьютерных программ и старайтесь унифицировать их использование на предприятии.
4.9.8 Для используемых компьютерных программ старайтесь устанавливать только критические обновления. Централизованно контролируйте смену версий прикладного программного обеспечения.
4.9.9 Адаптируйте прикладное программное обеспечение под производственные нужды.
4.9.10 Не используйте слишком навороченное прикладное программное обеспечение. Адаптируйте программное обеспечение к производственным потребностям, а не наоборот.
4.10 Делайте видимыми для всех достижения программы.

4.10.1 Делайте продвижение программы видимым и понятным для всех, включая внешних стейкхолдеров.
4.10.2 Отслеживайте, как программа в целом продвигается к тому, чтобы принести запланированные выгоды.
4.10.3 Используйте графики, диаграммы и канбаны там, где их будут видеть все. Не выводите средства визуального контроля на экраны мониторов.
4.10.4 Разработайте систему, которая делает задержки и несовершенства видимыми для всех.
4.10.5 Используйте цвета светофора, чтобы показывать статус задач и не позволять скрывать проблемы.
4.10.6 Задайте методологию управления подпроектами программы, чтобы оценить качество их работы и вклад в успех программы.
4.10.7 Согласуйте показатели программы с ожидаемыми выгодами и ожиданиями стейкхолдеров.
4.10.8 Обеспечьте четкую прослеживаемость между показателями подпроектов программы и показателями успеха всей программы.
4.10.9 Разработайте панель показателей программы, которая будет использоваться на протяжении всего жизненного цикла проекта либо программы и публикуйте ее в общем доступе.
4.10.10 Поставьте KPI “Уровень риска и неопределенности” и отслеживайте его уменьшение в ходе программы.
4.10.11 Отслеживайте с помощью KPI эффективность и качество организационных интерфейсов.
5. Вытягивайте пользу из программы.
5.1 Выполняйте задачи и добивайтесь результата там, где он востребован, отказывайтесь от выполнения остальных задач, т.к. они являются потерями.

5.1.1 Список задач должен определяться потребностью в информации, которая появляется в результате выполнения этих задач.
5.1.2 Создавайте культуру получения только востребованных знаний и ограничивайте отсылку информации только тем, кому она самом деле нужна.
5.1.3 Тренируйте команду для каждой задачи определять заказчика и исполнителя. Используйте модель SIPOC для того, чтобы лучше понять модель жизненного цикла.
5.1.4 Оставайтесь на связи с внутренним заказчиком при исполнении задачи.
5.1.5 Поощряйте прямое общение между внутренним заказчиком и исполнителем непосредственно во время выполнения задачи. Такое общение должно быть построено на доверии, уважении и взаимном понимании потребностей и ограничений.
5.1.6 Для нестандартных задач координируйте требования к результату с внутренним заказчиком, это позволит избежать переделок.
5.1.7 Чтобы определить какие задачи делать и в каком объеме, руководствуйтесь пониманием пользы для заказчика. Так вы поймете, какие задачи надо взять из буфера и начать исполнять.
5.2 Создавайте эффективные механизмы контрактации программы, которые позволяют ей достигать запланированных выгод и создают эффективное вытягивание пользы из программы.

5.2.1 Создайте типовые структуры контрактов для программы.
5.2.2 Чтобы справедливо поделить между участниками программы риски и возможности, которые возникают из-за вероятностной природы оценок, согласуйте контракты и премии исполнителей. Это позволит вам избежать игр с прогнозированием и создаст выигрышную для всех ситуацию.
5.2.3 Убедитесь, что контракты поддерживают исчерпывающую и открытую коммуникацию между стейкхолдерами программы.
6. Совершенство программы.
6.1 Эффективно используйте существующие стандарты управления программой и управления практиками.

6.1.1 Используйте существующие стандарты управления программами, руководства и применимые модели уровней зрелости практик наилучшим для программы способом.
6.1.2 При выборе стандартов, руководств и моделей зрелости руководствуйтесь выгодами программы.
6.1.3 Согласуйте ввод целевой системы в эксплуатацию с существующей бизнес-стратегией предприятия и со стандартами предприятия.
6.1.4 Если программа требует обязательной сертификации, то не вводите стандарт только для того, чтобы пройти сертификацию.
6.1.5 Чтобы быстро оценить свой уровень готовности к бережливому управлению программами, используйте существующие инструменты самооценки. С их помощью вы быстро обнаружите слабые места, сможете поставить цели для развития и отслеживать постановку практик.
6.2 Стремитесь к обоснованности использования практик на всем жизненном цикле программы.

6.2.1 Разработайте долгосрочный подход к освоению мышления, ориентированного на минимизацию потерь. Встройте подход в практику управления портфелем проектов предприятия и начните использовать это мышления во всем предприятии.
6.2.2 Организуйте отдел, который объединит в себе всю работу по освоению и постановке практики системной минимизации потерь. Этот отдел должен разрабатывать базовый метод, поддерживать и заполнять хранилище знаний и методов и собирать доказательства эффективности применения подхода и его влияния на достижение запланированных выгод программ.
6.2.3 Создайте инфраструктуру обучения методу системной минимизации потерь: руководители среднего звена и менеджеры проектов должны обучать и мотивировать своих подчиненных.
6.2.4 Создайте стимулы в программе и подпроектах, которые будут способствовать принятию практик системной минимизации потерь.
6.2.5 Дополните существующие практики организационных изменений и постоянных улучшений практиками системной минимизации потерь. Так вы создадите кумулятивный эффект от применения этих практик.
6.2.6 Начинайте постановку практик с небольших проектов по реализации наиболее выгодных для вашей программы факторов.
6.2.7 Запишите накопленный опыт и оцените эффективность полученных рекомендаций.
6.2.8 Ищите новые и необычные способы работы, которые приносят больше пользы.
6.3 Стремитесь к совершенству в программном менеджменте и системной инженерии.

6.3.1 Освойте базовые практики управления качеством. Не создавайте, не передавайте, не принимайте дефекты.
6.3.2 Следуйте базовым техникам решения проблем (PDCA) и перенимайте культуру блокирования последствий и надежного решения проблем.
6.3.3 Поощряйте работу в нормальном режиме и постоянное улучшение практик. Вознаграждайте дальновидность и избегание проблем, а не героическое решение созданных своими же руками трудностей.
6.3.4 Используйте ошибки в качестве полезных уроков. При этом делайте упор на практиках, а не на людях.
6.3.5 Используйте любое несовершенство как возможность для улучшения. Часто обращайтесь к формально собранному и обработанному накопленному опыту, чтобы найти там возможности для улучшения.
6.3.6 Поддерживайте последовательный и дисциплинированный подход в управлении программой и системной инженерии. Сюда входит согласование целей, результатов, практик, коммуникации и стандартизации лучших практик.
6.3.7 Распространяйте идею о необходимости постоянных улучшений в программе.
6.3.8 Достигайте совершенства применения практики только в том случае, когда это приносит пользу программе. Избегайте потерь перепроизводства и излишней обработки. Добивайтесь выполнения практики с первого раза.
6.3.9 Используйте сбалансированную матричную либо сбалансированную проектную организационную структуру. Избегайте крайностей как в виде чисто функциональной организации так и в виде чисто проектной организации.
6.4 Дальновидно управляйте неопределенностью и рисками, чтобы получить максимум пользы от программы.

6.4.1 Создавайте механизмы, которые позволят фиксировать, коммуницировать и применять опыт реализации.
6.4.2 Четко документируйте контекст “лучших практик” и “ключевых уроков”, чтобы другие могли понять, применимы ли эти знания в их условиях.
6.4.3 Поставьте практику, которая будет регулярно просматривать, оценивать и стандартизировать накопленный опыт и готовить его к применению.
6.4.4 Назначьте ответственных за практику просмотра, оценки, стандартизации накопленного опыта и за его применение.
6.4.5 Настаивайте на том, чтобы определение корневых причин и реализация корректирующих действий с последующим обучением персонала всегда проводилась единообразно.
6.4.6 Ищите лучшие практики с помощью бенчмаркинга и в профессиональной литературе.
6.4.7 Если вы замеряете показатели внешних партнеров, то делитесь с ними этой статистикой и обсуждайте планы по улучшению ситуации.
6.5 В меняющейся обстановке эффективно используйте практику управления изменениями. Она позволит программе согласовывать внутренние изменения с изменениями внешней обстановки.

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

6.6.1 Практика управления рисками должна сосредоточиться на создании и защите выгод программы.
6.6.2 Добейтесь общего понимания неопределенностей, которые существуют в программе. Поймите и задокументируйте ключевые факторы риска для программы и найдите какие есть лучшие практики, чтобы работать с этими рисками.
6.6.3 Поддерживайте принятие всех критических решений с помощью практики управления рисками.
6.6.4 Максимально снижайте все внутренние и внешние неопределенности программы.
6.6.5 Делайте программу устойчивой ко всем внешним неопределенностям, на которые вы не можете повлиять.
6.6.6 Развивайте организационную способность управления рисками и обеспечивайте ее достаточными ресурсами.
6.6.7 Адаптируйте практику управления рисками к потребностям программы и встраивайте ее в остальные практики управления программой.
6.6.8 Удостоверьтесь, что мероприятия по управлению рисками вносят свой вклад в постоянные улучшения практик и организации программы.
6.6.9 Регулярно отслеживайте и пересматривайте риски, планы реагирования на них, и оценивайте всю систему управления рисками в целом.
6.6.10 Отслеживайте появление возможностей и используйте их.
6.7 Стремитесь к совершенной координации, коммуникации и совместной деятельности организационных звеньев и практик.

6.7.1 Разработайте общую для всей программы политику, руководство либо базовый метод, в котором определите ожидания по координации, коммуникации и совместным действиям.
6.7.2 Используйте стандартные форматы подачи информации на одну страницу, например, Тойота А3, для стандартизации общения. Не рассылайте неструктурированные протоколы собраний. Включите в дополнительные материалы подробную информацию на случай, если она понадобиться получателю.
Слайды доклада по внедрению А3 техники в Skype
Видео доклада по внедрению А3
6.7.3 Используйте стандартные форматы подачи информации на одну страницу для решения межфункциональных проблем. Это позволит быстро решать проблемы.
6.7.4 С самого начала программы создайте план, который установит ответственность за реализацию положений политики по коммуникации, совместной деятельности и порядку принятия решений.
6.7.5 Учитывайте компетентность в общении людей, которых вы назначаете на позиции, с требованиями их ролей в программе.
6.7.6 Опубликуйте инструкции по тому, как вести переписку.
6.7.7 Опубликуйте инструкции по содержанию хранилищ информации. Должен быть баланс между централизованным и распределенным хранением, достоверностью информации и уровнем бюрократии, бумажными и электронными копиями.
6.7.8 Опубликуйте органиграмму программы и список участников с их контактами. Учите вновь нанятых сотрудников искать нужных людей.
6.7.9 Обеспечьте своевременный и эффективный доступ к централизованным данным.
6.7.10 Разработайте эффективный и легкодоступный свод знаний программы. В нем должны быть исторические данные, поиск, а участники должны использовать его для передачи и распространения знаний в программе.
6.8 Содействуйте появлению взаимодополняющих методов постоянных улучшений, которые позволят раскрыть творческие способности и потенциал всех стейкхолдеров.
6.8.1 Используйте и вознаграждайте низовые предложения работников, направленные на решение проблем, которые возникают на их уровне.
6.8.2 Используйте небольшие команды быстрого реагирования для решения локальных проблем и разработки стандартов.
6.8.3 Для решения проблем на уровне программы организуйте большие оформленные формально проекты улучшений.
6.8.4 Поставьте практики локальных улучшений в разных частях программы.
Автор: на Комментариев нет:

пятница, 9 ноября 2018 г.

Strategizing with OODA and PDCA loops

Abstract
Concept of practice is central to strategizing. Strategy is defined as facts about endeavour with regards to 5P Mintzberg’s definition of strategy. These facts first forecasted with practice discipline as hypotheses and then produced as a result of performing practice. Produced facts are either support or reject hypotheses. Such verification is evaluated by endeavour stakeholders to the level they shift chances of endeavour success from stakeholder’s viewpoint. Business actors that represent stakeholders deliver and test hypotheses and strategy in specially allocated space-time extents according to prespecified protocols, which is called business interface. Strategy, thus is influenced in discipline change which is described by OODA loops strategizing or by business actor change which is described by PDCA loops strategizing.
Topic starter:
Marcus Guest OODA Loops. Now this is getting interesting. The cycle diagram above though is wrong. For example, if you make faster decisions but they're all wrong you only die quicker. Better to get to grips with the real OODA Loops (plural, not singular), which looks intimidating but is well worth the time to explore as it provides insight into how humans act in an uncertain world without having access to all the information they need -- critical skills in a volatile and unpredictable world

Александр Турханов Of course, OODA as well PDCA is strategizing. Continuous development and implementation of strategy. But when we are talking PDCA we're changing only technology, and when OODA then we can change discipline and practice. That what moves object on wardley/power map between maturity lanes. PDCA progresses object within the lane.

Marcus Guest Alexander Turkhanov components on Wardley/PowerMaps move through evolution (ubiquity over certainty), which I agree that OODA is a major part of. Unlike Wardley though I don’t see OODA as a type of strategising but the DNA of how we interact with the world, often muddling through, while I would agree with you that PDCA is more about tech/process shifts where cause and effect is predictable. Both required — now more than ever as it’s how humans interact with the technology and how these emergent cyborgs interact with each other.

Александр Турханов Marcus Guest I'll address that tomorrow if you don't mind. I have definition of strategizing as practice of how do we change practice. And we have either improvement step (that's PDCA) or development step (that's OODA). And that's basics of decision making because when you need to invest you should consider different options and you cannot do that with PDCA. So, for development part of strategy you need OODA.

Marcus Guest Alexander Turkhanov I agree with that. I’m teaching this next week at MISiS: convergent and divergent thinking. PDCA may be the former but I’d argue that OODA covers both as it’s also a subcomponent of PDCA. Look forward to your further thoughts on it tomorrow.
Thesis:

We perceive about 7% of ‘objective reality’, just an example, large corpus of research is behind this: The rest 93% is our construction of observed world and in systems approach we say that people are stakeholders meaning by that they see objects defined by their ontology. Once you learn new practice and start to see new things in the world and your ontology extends.
Man as a stakeholder is assigned to perform some practice. When he is performing this practice he sees mostly objects defined by this practice and misses the rest of the world. So, when you put professional optics on, you always missing changes of the rest of the world that does this practice does not define. Typical example is ‘missing gorilla’ series of tests. So, your ontology defines what things you can potentially see in the world and your stakeholder position define what optics are you wearing now and what objects are in your attention focus now.

I am operating here and further with BORO ontology and this defines my ontology choices, see slide 30: presentation slides
That basically mean we are using B-theory of time by John McTaggart: https://en.wikipedia.org/wiki/B-theory_of_time
This also knowns as 4-dimensionalism or perdurantism: https://en.wikipedia.org/wiki/Perdurantism

In perdurantism we are not distinguishing future, past and present, they all exist in 4D. Past, present and future are just relative markers that tag event sequence. And we know lesser about the future then we know about the present.

So, what does it say about my definition of strategy?
Practice has underlying discipline that defines this practice. We can say that practice consists of people with disciplinary thinking and technology that supports this disciplinary thinking and domain actions. Discipline is consistent set of theories in certain domain. But disciplines can be of course contradictory and you cannot apply them together. Discipline defines Goals, when you apply finance management practice goals will come from finance controlling discipline, but not from mechanical engineering discipline. Basically discipline is stating facts about the future. There are two ways I can get facts in rational thinking - from observing reality (facts per se) and from discipline (hypothesis). If they match, I say that discipline can be valid, hypothesis is not rejected. It is interesting because in 4D we don’t distinguish between future and present and thus hypothesis are just another fact with just tag ‘future’. You just have not observed it.

So, from one point of view strategy comes from discipline. If you want to set some goal that your current discipline says impossible to reach, you need to change discipline. ‘You cannot reach the Moon, climbing successively taller trees’.

So I define practice as some shared by many people view on how to see and operate the world.

Now we need to move to pragmatism and find out how stakeholders get disciplinary goals. We model pragmatic approach with concern and assessment, see details further in:
Stakeholder who is assigned to perform, execute particular practice has concern regarding the system or project. Concern is definition of discipline. For example, if I am concerned whether it is enough money to finish the project, I start looking for some discipline that can predict cash sufficiency and can find few - traditional controlling, lean budgeting or beyond budgeting. So my concern defines discipline and practice I want to execute. Because if I want to cut expenses in half I need to go with lean budgeting because it is impossible to reach such stretched target with controlling. And that will define my strategy. But concern per se does not define goal and we apply assessment to it. For example, the same concern ‘cash flow’ two stakeholders - finance manager and operations manager will assess quite differently. Bean counter will say that cash flow is poor and cash deficit is imminent, but shop floor guy will say there’s plenty of cash. We don’t judge right and wrong in pragmatism, we just need to account for it. So, stakeholder set goals based on their assessment of concern. If money is not enough, goal will be to earn more or spend less. And we achieve that goal through practice.

And we go to the strategy now. I’d say that concept of practice is central to understanding what strategy is. I use Mintzberg’s 5P definition of strategy:

Plan, Ploy, Pattern, Position, Perspective.

Strategy is definition, not description. It obsoletes once been written and communicated. So you need to strategize, it’s like DevOps, you continually redefine and incrementally deliver strategy. It is dynamic goal not static. But how do you know you’re executing strategy? You need evidence, facts that shift stakeholder’s assessment of the overall endeavour closer to success and farther from failure. In practice this means that using discipline from certain practice we set goals that meet stakeholder assessment of concern. And we make hypotheses about the future. We call these hypotheses ‘requirements’. So, requirements are such facts, statements about the future, that currently look pretty challenging to deliver. So stakeholder should be pretty much surprised when she observes the fact of requirement fulfillment. It should be like ‘wow, iPhone 10 Siri is sooo smart’ and not like ‘it has 5 Mp camera on it, duh’. But we can set not only systems requirements, but endeavour requirements, why not? If we say that company should perform unrealistic plan or persist current market position despite fierce competition or any other hypothesis from Mintzberg’s 5P it is definitely strategy.

So, funny thing, endeavour requirements is our strategy. So we can use requirements engineering discipline to excel our strategizing practice. We can discover strategy the same way we discover requirements, we can verify strategy, validate it.
Requirement realizes discipline means that through discipline stakeholder makes hypothesis about the goal that are captured in form of requirement and once we verify requirement, we can test, confirm or reject hypothesis and this test shifts stakeholder’s perception of endeavour/system success. That’s pragmatism, success is defined by stakeholders.

But that’s not all. Meanwhile stakeholder are defining success of endeavour and system, organization consists of business actors and not stakeholders. And this is organization that has strategy and not stakeholder. We need to put that together.
Business actor is any organization: enterprise, department, project team, committee, working group or just single position. Business actors give and deliver promises in orchestrated activity. These promises meet at some point in the world which I call Business interface. Let’s consider practical example. You go to pizzeria and you place an order, you get pizza and pay money. This is you as business actor assigned to customer stakeholder role performing nourishment practice. And there is pizzeria business actor assigned to salesman stakeholder role performing cooking and selling pizza practice. Once I am over with buying pizza be as business actor can switch back to being project manager and pizza guy can switch back to finance manager and continue bookkeeping. Business actor are usually assigned to several stakeholder roles.

Transaction is performed between business actors over the counter, specially located place in space and time, business interface. You cannot get pizza outside, you should go to the counter. You cannot violate practice and pay in Euros. And you expect that check will be exactly as price tag shows. So there is protocol on this transaction.

What is important here is that requirements, hypotheses are tested on business interfaces, strategy is delivered and verified on business interfaces. And business actors deliver promises on business interfaces. May be that is somehow reflected in the language, because we deliver strategy, meaning we produce facts that are out of ordinary and when stakeholder observes such fact she is starting to think “may be they are moving in the right direction”.

So, as we can see from the last diagram, strategy=endeavour requirements can be influenced in two ways: by changing discipline or by changing business actor. Either way it is some development project, which changes people way of thinking and that would be discipline change or changing business actor organization or tools and that is technology change.

Now we back up a little to what discipline is and why do we need it. Discipline is set of coherent theories with which we can make forecasts and plans. If we don’t change discipline, we can plan-do-check-act. But if we change discipline, we cannot forecast very well, we just not familiar with new set of theories, we don’t have enough knowledge of it. So we observe-orient-decide-act.

And that is what I meant when said that OODA is for development step of strategy and PDCA is for excel step of strategy.

Автор: на Комментариев нет:

пятница, 2 ноября 2018 г.

Моделирование причинно-следственных связей в SysArchi

Метамодель SysArchi разделяется на две группы описаний:
Основные группы описаний, области предметного моделирования - работы, организация, система, целеполагание и знания.
И служебные группы описаний, которые объясняют причинно-следственную связь.
Поясню на конкретном примере. Допустим, я заболел и мне прописали антибиотики:
Related image
Это система, которая должна привести меня в целевое состояние - быть здоровым. Первая причинно-следственная связь, которая может быть - это связь через дисциплину практики.
Мой прием антибиотика (пакет работ) происходит в соответствии с практикой приема антибиотиков два раза в день в дозировке 500 мг в течении минимум 5 дней до и не менее 24 часов после исчезновения всех симптомов. Эта практика реализует дисциплину антибиотикотерапии. Эта дисциплина говорит, что должна поддерживаться определенная концентрация лекарства в течение определенного срока, чтобы не появились резистентные штаммы. Так я обеспечиваю логику реализации цели от конкретного действия - приема лекарства к цели.
В результате приема антибиотика появляется предмет поставки - пациент на антибиотикотерапии. Этот пациент реализует рабочий продукт (запись в журнале приема лекарств) и физический объект (лекарство в терапевтической дозе в биологических жидкостях организма). Запись в журнале приема лекарств реализует концепты практики антибиотикотерапии "дозировка" и "периодичность приема". Мы можем задать требования (факты в отношении физических и информационных объектов в деонтической модальности), например, антибиотик должен приниматься в дозировке 500 мг; антибиотик должен приниматься 2 раза в сутки с периодичностью 12 часов; посев мокроты должен быть чувствителен к антибиотику. Дисциплина антибиотикотерапии с помощью своих микротеорий объясняет нам как выполнение этих требований помогает достичь целей. Поэтому лечащий врач вправе требовать исполнение этих требований.
И на уровне самой таблетки препарата мы можем провести еще одну логическую линию отношений реализации. Таблетка будет воплощением системы (оборудованием), у нее есть физический интерфейс к бактериям (интерфейс к аппарату синтеза белка бактерии). И мы можем либо напрямую объяснить как воплощение системы помогает достигать нам цели - синтез белка бактерии прекращается, бактерия не растет и не размножается, доживает свой срок жизни и после этого мы выздоравливаем. Либо объясняем как мы достигаем цель через факты (требования) - т.е. мы замеряем скорость роста бактерий, их концентрацию в крови и жидкостях, и через дисциплину антибиотикотерапии объясняем логику достижения цели.
Автор: на Комментариев нет:

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

Соглашение о моделировании программ проектов SysArchi

Цепочка предшествующих материалов:
https://ailev.livejournal.com/1427265.html “Онтика онтологизации”
http://anticomplexity.org/sobytie-i-fakt-v-kommunikatsii/ “Событие и факт в коммуникации”
http://anticomplexity.org/decision-oriented-enterprise-architecture/ “Decision-Oriented Enterprise Architecture”
https://yadi.sk/i/DgjcxXh3yPjQIA Соглашение о моделировании SysArchi
http://sdu2020.blogspot.com/2018/10/blog-post_18.html “Как управление по контрольным точкам влияет на восприятие успешности проекта”
http://sdu2020.blogspot.com/2018/06/blog-post.html “Когда руководитель проекта становится руководителем программы”
http://sdu2020.blogspot.com/2018/05/blog-post.html “Объединение системной инженерии, программного менеджмента и инженерии предприятия”
http://sdu2020.blogspot.com/2018/02/blog-post_22.html “Продукт-ориентированные ИСР. Почему они лучше других?”
Соглашение о моделировании состоит из четырех частей - метамодель, модель атрибутов объектов и отношений, паттерны проектирования, визуальный стиль оформления. В этом тексте я разбираю метамодель.
Программа - совокупность связанных проектов со своими целевыми системами, у которых есть общие практики жизненных циклов. Эти практики реализуются разделяемыми, в общем пользовании, орг.способностями программы. За счет разделения орг.способностей между проектами программа получает экономические эффекты.
Зачем нужно системное мышление?
Единственный способ изменить будущее - сделать что-то сейчас. Иногда надо сделать что-то настолько большое, что для этого надо звать очень много людей разных специальностей, каждый из которых будет заниматься своей небольшой частью. И тогда стоит задача координации текущих действий и построения общей логики объединения результатов работ. Системное мышление на базе системной инженерии (т.н. системноинженерное мышление) предлагает отработанные на тысячах крупных проектов технологии такой координации, комплексирования и проверки результатов работ. Весь системный подход можно выразить компактной схемой:
Она состоит из пяти блоков:
- модели действий и результатов действий (что делаем?)
- модели знаний и технологий (как и почему действия приведут к результату?)
- модели целеполагания (какой измененный кусок мира мы хотим видеть и почему мы его хотим изменить?)
- модели измененного куска мира (что мы изменяем в мире, какие новые объекты появляются, что они делают и как они взаимодействуют с миром?)
- модели организации (у кого какие ресурсы, полномочия, обязательства?)
Эти блоки соединены цепочками реализации:
Пакет работ-Практика-Дисциплина-Цель
Координация через практику и дисциплину практики, координация на основе знаний. Здесь находятся практики индуктивного вывода и прогнозирования. Условно, если мы будем соблюдать эту практику, то достигнем цели. Условно первый и второй квадранты Кеневин.
Предмет поставки-Объекты практики-Требование-Дисциплина-Цель.
Координация через значимые факты и дисциплину. Подведение фактов под теорию. Здесь находятся практики абдукции, условно второй и третий квадранты Кеневин.
Предмет поставки-Оборудование/Орг.звено-Интерфейс-Цель.
Координация почти однозначной причинно-следственной связи. “Если у меня будет дом, то моя жизнь улучшится”, “если у меня будет машина, я буду быстрее добираться куда мне надо”. При этом система может быть частью орг. звена, например, машина является частью домохозяйства, производственная линия является частью цеха. Первый квадрант Кеневин.
Предмет поставки-Оборудование/Орг.звено-Интерфейс-Требование-Дисциплина-Цель.
Координация факт-ориентированной причинно-следственной связи изменения мира. То же, что и предыдущее, но причинно-следственная связь задается дисциплиной практики. Например, “правильное питание и комплекс упражнений в 80% случаев приводят к заметному росту мышечной массы и увеличению силы”. Второй квадрант Кеневин.
Модели действий и результатов действий, уровень абстракции М0-М1
Пакет работ (work package). 4Д-индивид, который состоит из орг. звена (business actor), инструментов, которое использует это орг. звено, в момент применения практики (practice) в фиксированном контексте применения практики. Особенностью пакета работ является его предсказуемость - постоянство состава орг. звена, постоянство инструментов, соблюдение дисциплины (discipline) практики, постоянство контекста. Здесь же допускается наибольшее количество ошибок, т.к. в проектном управлении вместо этих принципов часто используют эмпирики типа 8/80. На пакетах работ основаны оценки работ, по которым орг. звенья дают обязательства и координируют работы.
Предмет поставки (deliverable). 4Д-индивид либо описание целевой, обеспечивающей, использующей системы либо системы в операционном окружении. Для использующей системы и систем в операционном окружении только описание, менять их полномочий у команды программы нет. Предмет поставки определен методом работ. Методы работ определяются в зависимости от рисков отклонений производимого элемента системы (equipment) от спецификаций. Более подробно смотри доклад Филиппа Дельгядо
Отношения:
Пакет работ исполняется орг. звеном. У любого пакета работ есть ответственное за его выполнение орг. звено (accountable).
Пакет работ как самый конкретный объект реализует практику как менее конкретный объект. Пакет работ исполняется в соответствии с практикой, следует ее дисциплине и использует технологии практики.
Пакет работ имеет отношение доступа к предмету поставки, “пишет” в предмет поставки. Это означает, что в ходе пакета работ создается, изменяется либо уничтожается какой-то системный элемент либо описание.
Предмет поставки реализует физический объект практики. Физический объект практики определен в рамках онтики практики как класс, а при исполнении пакета работ люди оперируют индивидами. Отношение реализации показывает, что индивид предмета поставки и есть физический объект, определенный практикой. Если вы кидаете конкретную бутылку и пытаетесь рассчитать ее траекторию с помощью ньютоновской физики, вы должны отождествить конкретную бутылку с понятием “физическое тело” из ньютоновской механики, и после этого вы можете применить к ней три закона механики Ньютона и рассчитать траекторию.
Предмет поставки реализует рабочий продукт, артефакт практики. Если практика прикладная, например, управление проектами, то роспись денежных средств на работы, которую вы сделали с бригадиром на стройке дома отождествляется для вас с рабочим продуктом “бюджет проекта”. И тогда вы можете применять к этой росписи практики планирования, прогнозирования, контроля.
Предмет поставки реализует системный элемент. Означает, что в результате выполнения пакета работ должен появиться системный элемент.
На практике в проектном управлении используется три типа разбиения работ, см. “Продукт-ориентированные ИСР. Почему они лучше других?” Из них два основаны на разбиении предметов поставки, один на разбиении пакетов работ. Эти типы ИСР/WBS равноправно могут использоваться для основанной на фактах координации рабочих групп. Проблемы такой координации описаны в “Как управление по контрольным точкам влияет на восприятие успешности проекта”.
Модели знаний и технологий
Практика (practice). Класс действий, при которых стейкхолдер видит определенные практикой объекты и оперируют с ними в соответствии с дисциплиной практики. При этом появляются рабочие продукты практики.
Физический объект (physical object). Часть мира, 4Д-индивид, который выделяет стейкхолдер и работает с ним по определенным дисциплиной практики правилам, паттернам внимания и действий. Например, конкретный автомобиль.
Информационный объект (information object). Концепт, понятие. Часть нейронной сетки стейкхолдера, которая моделирует поведение физического объекта. Например, “личный транспорт”, простое понятие в моей голове, которое представляет сложную систему автомобиля в составе еще более сложной системы городского дорожного движения. Но я могу использовать простой концепт личного транспорта, чтобы оценить время, за которое я доберусь в место назначения. При этом я отвязываюсь от того, на каком автомобиле я поеду, если, допустим, я поеду на такси.
Дисциплина (discipline). Связанный набор микротеорий и понятий, который позволяет предсказывать состояние мира с какой-то достаточной для практических целей точностью и достоверностью.
Отношения:
Стейкхолдер назначается на практику. Т.е., стейкхолдер с инструментами в момент исполнения практики и практика есть один и тот же 4Д-индивид. Мы различаем практику сантехнического ремонта, сантехника, который ставит ванную, или пакет работ по установке ванной как разные объекты 1-го класса, но при этом должны понимать, что это один и тот же 4Д-индивид. Подробнее можно почитать в http://sdu2020.blogspot.com/2018/06/4_10.html (Перевод Roles: A Four-Dimensional Analysis by Matthew West, 2008).
Практика имеет отношения доступа к объектам и рабочим продуктам. Смысл в том, что при организации работ мы отслеживаем не людей, а рабочие продукты, которые выражают альфы, alpha, информационные объекты, либо физические объекты. Именно они являются единицами логистики работ. Стейкхолдеры выделяют объекты на фоне остального мира и что-то с ними делают.
Практика [более конкретная] реализует дисциплину [более абстрактная]. Дисциплина позволяет переносить знания между разными контекстами. Практика всегда привязана к конкретному контексту, и часто привязана к исполнителям. Например, финансовый учет или управление проектами в конкретной компании учитывает конкретные обстоятельства, цели и участников практики. Но если руководитель проекта знает дисциплину проектного управления, то легко сориентируется в деталях реализации, т.к. привяжет информационные объект практики к конкретным рабочим продуктам и будет понимать, что  ними делать.
Дисциплина [более конкретная] реализует цель [более абстрактная]. Цель находится в возможном мире будущего, дисциплина существует прямо сейчас как разделяемое знание стейкхолдеров. И то и то представлено нейронными сетками стейкхолдеров, но дисциплина может лежать в основе действий (discipline is actionable). Эта связь подразумевает, что следование дисциплине приближает нас к цели.
Модели целеполагания
Интерес (concern). В полном соответствии с онтикой онтологизации.
Оценка интереса (assessment). В полном соответствии с онтикой онтологизации.
Цель (goal). Желаемое состояние мира, 4Д-индивид либо 3Д-индивид, событие, в возможном мире.
Требование (requirement). Факт, правдивость которого мы требуем для цели. Цель описана в требованиях. Требования исполнены, т.е., факты правдивы, означает, что цель достигнута. Требования, как и другие факты, имеют смысл только для определенных стейкхолдеров. Требования как факты проверяются на истинность в заранее определенных 4Д-местах мира, которые называются интерфейсами. Проверка требований происходит в соответствии с дисциплиной. Например, есть USB-интерфейс как заранее заданная часть мира, в которой мы проверяем выполнение “мышкой” требований к ней. При этом в месте подключения “мышки” есть несколько интерфейсов - сигнальный (протокол USB), тепловой (дисциплина теплотехники), электрический (дисциплина электротехники), химический (дисциплина химии) и другие. В каждой из этих дисциплин есть свои объекты, для каждого объекта можно указать факт и установить для этого факта модальность долженствования, тогда это станет требованием. Это первое ключевое отличие требования от архитектуры - исполнение требования проверяется в строго заданных частях мира, на интерфейсах. Второе отличие требований от архитектуры - это то, что требование выражается как факт в объектах дисциплины практики, в то время как архитектура - это факт, выраженный в предметной области целевой системы. Сравните, “Низкоплан нормальной аэродинамической схемы, со стреловидным крылом и однокилевым оперением. Два турбовентиляторных двигателя.” (описание архитектуры в фактах предметной области самолета) и “Максимальное количество пассажиров (в одноклассовой конфигурации): от 250 до 330, экономичность выше аналогов, багажное отделение на 45% больше, чем в Боинг 767, салон на 40 см шире”. Архитектура - это, как и требования, факты, разделяемые командой. Но это факты, учитывающие и проект и компетенции команды, в то время как требования относятся только к системе.
Модели измененного куска мира и модели организации
Все в соответствии с онтикой онтологизации и соглашением о моделировании.
Интерфейсы - части мира, в которых доказывается выполнение требований.

Автор: на 2 комментария:

суббота, 27 октября 2018 г.

Запуск практики архитектуры предприятия

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

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

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


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

Как практика архитектуры предприятия справляется с проблемами:
Модель архитектуры предприятия объединяет точки зрения различных специалистов в одном месте, и вы можете разносторонне обсуждать различные аспекты решений, меняя темы прямо в ходе встречи. Это позволяет сократить сроки принятия решений.
Неочевидный плюс: сами решения после этого оказываются достаточно детальными и проработаными, так что людям проще их исполнить, чем объяснить, почему их исполнить не получится.
Модель архитектуры предприятия позволяет быстро перестраивать бизнес в условиях неопределенности, т.к. в ней отражены связи между критическими элементами организации.
За счет сквозных связей между процессами, людьми, ИТ-системами и данными позволит менеджеру быстро найти места, которые могут заблокировать орг. изменение, и подготовить план реагирования.
Бизнес-аудиты и проверки комплаенса проводить будет проще: в организации всегда будут существовать множество различных моделей - для операционного учета, финансовые, ИТ-инфраструктуры и многие другие. Модель архитектуры предприятия позволяет объединять все эти разношерстные представления в единую связанную структуру.
Пример: https://blog.leanix.net/en/gdpr-eu-compliance

Как происходит создание модели предприятия?
Технологии для внедрения - структурированные интервью и рабочие встречи для сбора знаний. Мы проведем семантический анализ переписки и корпоративных баз данных, чтобы выявить ключевые понятия, с которыми работают сотрудники организации. Для архитектурного проектирования мы используем ArchiMate с соглашением о моделировании SysArchi. В ArchiMate мы картируем ключевые практики и ИТ-решения, указываем связи между процессами, людьми, данными и ИТ-системами.

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

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

Модели архитектуры предприятия в ArchiMate преобразуются в структурированный текст на естественном языке, текстовую документацию. Так заказчик постепенно осваивает новую практику целенаправленного улучшения архитектуры предприятия. 
Автор: на Комментариев нет:
Подписаться на: Сообщения (Atom)