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

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

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

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

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

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

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

При принятии решений проекта важно точно формулировать цели и объемы их исполнения. При работе с европейскими авиастроителями нашей команде был предложен проект переделки списанных пассажирских самолетов в грузовые. Исходный самолет был спроектирован в бумажных чертежах, а новые чертежи нужно было делать в электронном виде. Попытки оформить предложения по правилам выпуска новой документации в проекте (для минимизации переделки серийных деталей старой конструкции) не были услышаны. Заказчики потребовали при наличии сопряжений между старой и новой деталью оцифровывать их обе. При этом формально появлялась новая деталь для конструктора и для производства. В итоге контракт был подписан на доработку по трудоемкости 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%.

2.6. Синтез системы

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

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

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

Важнейшим элементом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. На ЭМИ разрабатывают чертежи и сборки, а также управляют комплектом документации. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения в ГОСТ 2.051…2.058. Он создается и направляется системой управления данными о продукте, которая поддерживает выпуск технической документации и управление конфигурацией изделия.

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

В ЭМИ могут быть включены технические данные системы, 3-Д модели, документы и обеспечивающие процессы, необходимые для использования при дальнейших этапах работ. Например, трехмерная модель системы, набор и система управления техническими документами проекта, система управления составом изделия, система управления жизненным циклом изделия, технологические данные, содержащие необходимые указания для производства (используемые инструменты, материалы, технологии, средства контроля и т.д.), результаты расчетов различными средствами CAE, данные для проектирования и изготовления оснастки, технологические процессы, библиотеки операций и переходов в производстве.

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

Рис. 12. Три этапа «зрелости» ЭМИ

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