Шаблоны успеха в системной инженерии

Конспект

Задачей этой работы было определить шаблоны успешного использования системной инженерии в ИТ-проектах со значительной программной составляющей. Шаблоны выявлялись методом положительных отклонений (positive deviance, Gawande 2007) от принятых способов работы.
Вначале мы определили 30 госпрограмм, каждая из которых была в итоге признана успешной почти всеми участниками программы. Из этих 30 мы отобрали 12 для последующего изучения. Мы провели интервью с непосредственными участниками программ, у которых были полномочия положительно влиять на принятые способы работы.

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

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

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

Метод положительных отклонений описан Гаванде в его книге Better, 2007 by Atul Gawande.

Разработчики AT&L System of Systems Engineering Guide при разработке руководства  использовали метод положительных отклонений.

Метод шаблонов (patterns) разрабатывал архитектор Кристофер Александер. Он опубликовал его в книге The Timeless Way of Building, Oxford U. Press 1979.

Шаблон состоит из трех частей:

1) Контекст. Определяет ту надсистему, частью которой является та система, которую вы проектируете. Надсистема накладывает ограничения на возможные архитектурные решения.
2) Действующие силы. Выражают отношения между элементами в заданном контексте.
3) Решение. Представляет дизайн или конфигурацию элементов, которая успешно использует действующие силы.

Шаблоны предлагают только принципиальные, архитектурные решения. Шаблоны основаны на практиках.

Формат описания шаблона:

Краткое описание.
Контекст.
Проблема.
Рисунок.
Силы.
Решение.
Примеры.
Результат или итоговый контекст.
Ссылки.

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

Понятие успеха в госпрограммах

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

Мы определяли сложность по 8 критериям:

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

Мы провели краткие интервью с руководством успешных программ, обработали результаты и обсудили их с руководством программ еще раз. 

Итогом нашей работы стали 12 шаблонов.

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

"Балансирование сети поставок"

Краткое описание. 
Балансирует взаимодействие между стейкхолдерами в сложных программах по разработке и госзакупке.
Контекст.
- Сеть поставок вместо цепи поставок.
- Деньги текут от Конгресса и дотекают до подрядчиков.
- Регулирование и стандарты идут от госорганов.
- Оргспособность (capability) появляется не от одиночной целевой системы, которую вы создаете и поставляете, а от множества систем, которые находятся под контролем различных организаций.
Проблема.
- Надо иметь сбалансированную стратегию, чтобы удовлетворить правомочные потребности стейкхолдеров.
- Нужно справляться с множественными потребностями в условиях ограниченных ресурсов.

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

"Укрощение технической сложности"

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

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