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

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

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

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

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

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

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

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

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

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

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

На базе 3-Д моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства. Компоненты РКД включают 3-Д модели и сборки согласно ЭМИ, производственные чертежи, спецификацию (график работ), извещения об изменениях, алфавитную базу данных проекта для справочных нужд. Все чаще на сложных изделиях вместо РКД передают в технологическую службу образмеренные (аннотированные) 3-Д модели деталей, согласно стандартам ISO 16792:2015, ASME Y14.41—2012, MIL-STD-31000A.

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

В стандарте ГОСТ Р 58301—2018 «Управление данными об изделии. Электронный макет изделия. Общие требования» предложена классификация моделей, привязанных к основным фазам жизненного цикла. Функциональный макет ЭМИ-Ф включает взаимосвязанную совокупность данных, описывающих устройство, состав, характеристики, принципы работы и возможные нарушения исправного состояния изделия. Конструкторский макет ЭМИ-К содержит взаимосвязанную совокупность данных, описывающих конструкцию и требования к изготовлению и сборке изделия. Технологический макет ЭМИ-Т концентрирует взаимосвязанную совокупность данных, описывающих технологию изготовления и используемых для планирования, оценки и организации процесса производства изделия. Эксплуатационный макет ЭМИ-Э включает взаимосвязанную совокупность данных, описывающих эксплуатационные свойства изделия и требования к процессу его технической эксплуатации.

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

В каждом узле большого проекта должен работать один или несколько ЭМИ-интеграторов, чьи задачи состоят в следующем:

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

• проводить анализ проблем и подтверждать корректность ЭМИ (особенно после фаз интеграции), т.е. проверки, что нет «коллизий», аномальных данных, «наездов» деталей друг на друга;

• управлять качеством данных ЭМИ (рекомендуется иметь выделенного сотрудника, занятого на этой конкретной позиции);

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

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

Вышеперечисленный объем работ нескольких проектных групп одновременно на регулярно актуализируемом ЭМИ и его компонентах, отработка электронных сборок, включающих до 50 000 деталей, позволяют существенно повысить качество выдаваемой конструкторами документации, в 6…10 раз снизить стоимость затрат на корректировки конструкторских решений в производстве. Первым самолетом, спроектированным с использованием электронной документации, был Boeing-777 (в серии с 1995 г.). Его проектирование, разработка и испытания с широким использованием моделирования и виртуального эксперимента, замена физических макетов на ЭМИ позволили получить (сравнительно с созданием предыдущих самолетов В-757, B-767) ряд преимуществ:

a) исключено более 3000 сборочных интерфейсов;

b) получено 90% снижения запросов на изменение РКД (т.е. в 10 раз);

c) на 50% ускорен цикл обработки запросов на изменения;

d) достигнуто 90% снижения переделок конструкции (т.е. в 10 раз);

e) обеспечено улучшение допусков на сборку фюзеляжа (повышена точность подгонки секций).

На рис.13 показано улучшение качества конструкторской документации на разных фазах ЖЦ при использовании ЭМИ. Здесь ПИ обозначает предварительные извещения об изменениях.

Рис. 13. Влияние ЭМИ на снижение числа изменений РКД

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

Напомним некоторые термины и принципы процесса интеграции.

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

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

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

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

Принцип разделения (декомпозиции) делит концепции высокого уровня на несколько объектов низкого уровня для упрощения работ.

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

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

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

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

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

• интеграция на уровне компонентов: способность убедиться, что дискретная функция компонента соответствует общей системе, в которой он находится;

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

• на уровне процесса: постепенное наращивание компонентов продукта в единое работающее и протестированное изделие;

• на функциональном уровне: идентификация интегрированных функций как объединения многих отдельных функций для формирования наглядного эффективного (измеримого) результата.

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

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

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

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

a) аспекты развития (графические ограничения, ресурсы, оборудование, рабочая сила);

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