Пути и варианты в пространстве выборов проекта

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

В английском языке для обозначения решения используются два разных слова - decision и solution. Например, руководитель проекта - это decision maker, тот, кто принимает управленческие решения, а руководитель проектного отдела, который ведет работы по подсистеме - это solution architect, тот кто принимает технические, проектные решения. Если уходить от составных терминов "управленческие решения" и "проектные решения" и пытаться сказать проще, то наиболее близким по смыслу будут слова "пути" и "варианты" соответственно.

Какие есть пути достижения цели? Другими словами, какие цепочки действий надо выполнить и какие ресурсы и средства нужны, чтобы их выполнить и прийти туда, куда надо?

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

Первый набор вопросов задается руководителями и ответы на них ищутся в дисциплине проектного управления (P3M, portfolio, program and systems management). Второй набор вопросов задается системным инженерам и ответы на них ищутся в дисциплине системной инженерии (MBSE, model-based systems engineering).

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

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

Начинается все с определения проблемы.

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

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

Из Martin 2003

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

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

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

Системная инженерия описывает проблемы и варианты решения проблем с помощью наборов требований. Каждому варианту наборов требований для предлагаемого решения (целевой системы) соответствует своя системная архитектура. Хотим сделать МЦК? Свой набор требований и своя архитектура такого решения проблемы. Хотим запустить МЦД? Свой набор требований и своя архитектура. Даже если мы будем решать проблему рекламной кампанией "Работай из дома, езди попозже", все равно будет свой набор требований и архитектура.

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

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

Чек-лист систем в обеспечении:
- Люди и организации
- Здания, сооружения и оборудование
- Материалы и поставщики
- Услуги и сервисы
- Процессы и методы
- Инструменты и технологии
- Политики и процедуры
- Информация и данные
- Знания

- и многое-многое другое

После того, как мы создали целевую систему и вмешались в бизнес-процесс, у нас меняется не только сам процесс, но и его контекст. Запуск МЦД повлиял на работу метрополитена, операционный и бизнес контексты изменились. И это тоже надо моделировать. В презентациях ИТ-проектов часто можно встретить слайды AS IS и TO BE, это оно. Набор требований как раз и описывает целевую ситуацию, то, как будет устроен бизнес-процесс после внедрения целевой системы, какие будут сценарии выполнения работы, концепция использования целевой системы, какие у нее будут режимы функционирования и характеристики. А проработанная системная архитектура ответит на вопросы за счет чего эти требования будут реализованы.

Но вмешательство не всегда несет только улучшения. Мы меняем старое известное на новое неизвестное. У нас появляется неизвестность и риски.

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

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

Допустим, мы едем в аэропорт и выезжаем за 5 часов до отлета, хотя в среднем на то, чтобы добраться из дома до выхода на посадку у нас уходит 1,5 часа. Есть неопределенность, когда мы доберемся до выхода на посадку - метро может ходить с перебоями, мы можем опоздать на запланированный Аэроэкспресс, на входе в аэропорт, на регистрацию или паспортный контроль может быть большая очередь, но рисков почти нет. Невозможно опоздать, выехав за 5 часов. А вот если мы выезжаем за 1 час и 15 минут до вылета, у нас появляется множество рисков. Все может пойти не так на каждом шаге нашего пути.

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

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

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

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

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

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

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

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

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