Читать книгу: «Системный подход к управлению высокотехнологичными проектами. 2-е издание, переработанное и дополненное», страница 5

2.5. Принятие проектных решений

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

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

•Лучше продвигаться по проекту, имея несколько «сомнительных» решений, чем опоздать с решениями в поисках «совершенного» варианта. Лучшее – враг хорошего.

• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски и стоимость и обеспечить легкую реализацию и эксплуатацию.

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

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

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

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

1) использовать модели для проектирования систем;

2) использовать иерархический дизайн сверху вниз;

3) сначала выполняется работа с высокорисковыми компонентами;

4) конструировать минимум интерфейсов, разделяя их на механические, электрические, программные;

5) применять в альтернативах проекта удовлетворительные конструкции;

6) рекомендуется не проводить оптимизации на ранней стадии работ, пока нет уверенности, что база оптимизации выбрана достаточно обоснованно;

7) свои ошибки нужно находить самим, т.е. определить, что не так в очередном варианте;

8) полезно перечислить функциональные требования в случае использования системы;

9) выделить каждую функцию для только одного компонента;

10) категорически нельзя использовать недокументированные функции;

11) полезно применять быстрое прототипирование (варианты аддитивных технологий);

12) разрабатывать несколько итераций и сразу тестировать результат;

13) создавать библиотеки повторно используемых субъектов;

14) написать глоссарий соответствующих терминов;

15) удобно использовать создание конструктивных резервов (запасы);

16) следует проектировать компоненты с возможностью тестирования;

17) выполнять анализ чувствительности конструкции для альтернативных вариантов;

18) изменять поведение людей в команде для достижения результата.

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

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

Можно выделить несколько присущих характеристик процесса.

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

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

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

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

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

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

1) наблюдаемые симптомы;

2) определение проблемы;

3) целевой результат;

4) анализ основной причины;

5) количество компонентов в эксплуатации;

6) частота отказов среди этих компонентов;

7) происходит ли сбой равномерно по всей совокупности или он связан с конкретной партией изделий;

8) связан ли отказ с конкретным пользователем или рабочим циклом;

9) предлагаемое решение;

10) план действий;

11) результаты плана действий;

12) подтверждение решения;

13) уроки на будущее.

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

Вовлекаемый в процесс выработки решений опытный критический мыслитель должен обладать следующими качествами:

a) поднимает важные вопросы и проблемы, формулируя их четко и ясно;

b) собирает и оценивает соответствующую информацию, используя абстрактные идеи и объективные данные для ее эффективной интерпретации;

c) приходит к обоснованным выводам и решениям, проверяя их на соответствие заданным критериям и стандартам;

d) думает непредвзято в рамках альтернативных систем мышления, признавая и оценивая, при необходимости, их предположения и практические последствия;

e) эффективно общается с другими коллегами, находя решения сложных проблем;

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

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

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

При принятии проектных решений следует начинать с выбора критериев оценки влияния решений на ход реализации проекта:

•когда решение связано с умеренным или высоким риском по результату;

• когда решение влияет на управление конфигурацией;

• когда результат решения может привести к значительным задержкам графика работ;

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

• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости ПКИ.

Следует принимать во внимание, что каждое конкретное решение имеет свою «стоимость» в части объема затрат на реализацию. Схематично можно выделить четыре фазы зависимости «характеристика – ресурсы» (рис. 10). Здесь под стоимостью понимаются затраты любого ресурса (не только финансового).

Рис. 10. Кривая «стоимости» проектных решений

A. Рост характеристики от 0 до 1 дает ее заметное улучшение при минимуме затрат ресурса.

B. Рост характеристики 1—2 обеспечивает эквивалентный прирост характеристики на единицу затрат.

C. В приросте характеристики от 2 до 3 заметные затраты приводят к некоторому улучшению характеристики, но процесс сопровождается увеличением риска.

D. Рост характеристики выше 3 уровня показывает, что там невозможно получить улучшение характеристики при любом вложении ресурса.

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

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

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

Рис. 11. Схема реализации проектных решений

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

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

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

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

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

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

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

Процесс принятия решений может включать следующие этапы.

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

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

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

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

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

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

• Работает ли система так, как ожидалось?

• Как система реагирует на сбои, сбои и аномалии?

• Доступна ли система?

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

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

Результаты процесса определения проектного решения рекомендуется документировать.

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

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

• Начальные спецификации подсистем, которые предоставляют подробную информацию, если требуется.

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

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

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

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

Пример критериального решения показан для выбора места рабочего обеда. Назначены три критерия: расстояние до кафе (пункта питания), качество пищи и ее стоимость. В результате опроса группы сотрудников получены относительные оценки критериев в баллах. Далее проведена операция нормирования результатов, чтобы перейти к весовым коэффициентам в долях единицы (колонка справа в таблице 1).

Таблица 1

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

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

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

Необходимы некоторые разъяснения по поводу новизны принимаемых решений, а именно, нужно ли изобретать в проекте? На основе результатов статистического исследования сделан вывод, что большинство концепций и проектов есть модификации предыдущих с относительно малой новизной (Г. Альтшуллер, автор Теории Решения Изобретательских Задач). Их следует разыскивать первыми. В качестве примера можно привести появление в 2010 г. на рынке планшетного устройства, завоевавшего умы покупателей в возрасте от 3 до 90 лет, в конструкции которого не было использовано ни единого нового компонента.

Еще одним важным вопросом принятия проектных решений является применение правила копирования при использовании компонентов, модулей, подсистем, покупаемых готовыми на рынке (ПКИ):

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

b) при проверках обязательно учитываются доработки проекта, изменения в эксплуатационных требованиях и условиях относительно указанных в технических условиях на ПКИ;

c) должен быть приложен набор документов, требуемых для обоснования применения ПКИ в конкретном проекте;

d) не следует проверять компоненты с рынка через теорию подобия, необходимо использовать традиционные верификационные методы: испытания, анализ, проверки.

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

Например, вследствие выстроенного хаотично процесса конструирования был получен перегруженный узел конструкции «парашютный замок» (используемой для закрепления лямок ранцевого парашюта на груди парашютиста). Пересмотр с позиций системной инженерии привел к уменьшению количества деталей с 46 (включая 20 резьбовых и заклепочных соединений) до 7 (2 соединения), снижению массы на 25% при увеличении разрешенной нагрузки вдвое (с 160 до 320 кг силы), себестоимость при этом снизилась на 50%.