March 2015 Download this article as a PDFAbstract

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

Введение

Около одной пятой мировых ВВП, или более $12 трлн, будут потрачены на проекты каждый год с 2010 до 2020 года (пиво & Nohria, 2000). Однако несмотря на эти тяжелые инвестиции, слишком много проектов – до 18%, по данным Международной группы Стэндиш (2013) – не будут. Из-за повсеместное отсутствие управления проектами только 20% проектов достижения ожидаемых результатов с точки зрения качества, расходы и сроки (пиво & Nohria, 2000). Недавние исследования выявили текущие перегородки между системами инженерных процессов и практики управления проектом, ведущих к конкурирующих приоритетов и компромиссов в ходе проекта.

Систем инжиниринг и управление проектами являются двумя критически важными аспектами в успехе проектов в области развития продукта (Бенджамин и др., 2010; Conforto и др., 2013). Литература свидетельствует о том, что с самых ранних стадий проектов, реализация инженерных систем и процессов управления проектами является важным (Sharon соавт., 2011). Действительно разработка сложных систем является весьма интерактивный социальный процесс с участием сотен людей, которые должны принять совместные и последовательные решения (Эппингер & Салминен, 2001). В этом динамичном процессе продукта, Организация процесса и инжиниринг должны действовать совместно. Целью управления проектом является первым для определения миссии проекта и организации, а затем для определения бюджета и планировать график, а затем обеспечить оперативный контроль проекта посредством оценки производительности путем анализа возможных отклонений относительно первоначального графика и осуществления корректирующих действий или новые превентивные действия при необходимости для уменьшения рисков (Даниловичу & Браунинг 2007). Ее роль также состоит в организации систем и мониторинга технологических процессов.

Компании обычно обращают внимание на этих инженерных систем и проектами процессов управления, но, как правило, отдельно: они не рассматривают связи между ними. Действительно для многих лет, инженеров систем и проектов руководители подумал что их работа была отдельной, уделяя больше на своих собственных доменах, чем в целом проект (Conforto соавт, 2013). Однако недавние исследования указывают это непродуктивные разобщенности процессов и подчеркнули необходимость налаживания сотрудничества между процессами на нормативном уровне (Pyster & Olwell, 2013).

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

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

Необходимость сотрудничества между системами инженеров и менеджеров проектов

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

Таким образом многие компании полагаются на стандарты и инструменты управления жизненным циклом продукции для промышленных процессов (Rachuri соавт., 2008). Однако систем инженерных и проектов стандартов управления описывают что Инжиниринг «наилучшей практики», но воздерживаться от говорить как это сделать. Они сосредоточены на процессах и деятельности («что»), а не на методах и инструментах («как»). С другой стороны по данным исследования Пьер Audoin, консалтинг инструменты управления жизненным циклом продукта только помогает в совместной технической деятельности (Nayagam, 2011). Таким образом помимо использования некоторых средств бизнес-аналитики (например, SQuORE платформа, которая представляет собой новое поколение инструмент для оптимизации управления проектами программного обеспечения), некоторые крупные промышленные группы разработать свои собственные инструменты для поддержки процесса предприятия (например, «единая планирование» на AIRBUS) или программа «предприятие» Dassault системы. Эти инструменты, которые были настроены для поддержки процессов собственных компаний, полагаются на стандартов управления проектами. Однако эти средства до сих пор не считают управление проектами и инженерных процессов совместно систем. Кроме того они не предлагают механизмы поддержки решений для мониторинга проекта; Таким образом, будет необходимо разработать инструмент в ближайшем будущем для осуществления и координации сотрудничества между процессами инженерных систем и проектов управления и обеспечения проектов управленческих решений во время инженерных систем проекта.

Поддержка важность разработки инструмента для интеграции инженерных систем и управления проектами можно найти в нынешней экономической тенденции, которая направлена на сокращение расходов на деятельность. Действительно, в исследовании глобального института McKinsey (2013), который занимает 12 технологий, которые будут наибольшее влияние экономики к 2025 году, «работа автоматизированных знаний» (например, управление, инженерия, финансы) ранга второй в списке; Таким образом, цель будет сократить расходы на около 5 000 миллиардов долларов США в год! Это исследование подтверждает нашу убежденность в том, что пристальное внимание следует уделять интеграции систем с управлением проектом потому, что это полностью соответствует нынешней озабоченности.

Наша цель – таким образом предоставлять руководителю проекта стандартам метод и средства, которые поддерживают сотрудничество между системами инженеров и менеджеров и их соответствующих процессов для управления проектом и оптимизировать сотрудничество между процессами. Для этого, первый шаг состоит из определения и моделирования инженерных систем и проектов процессов управления, а затем найти соответствующие показатели для наблюдения за ними. Есть три цели: i) для поддержки управления путем координации процессов; II) предложить метод заинтересованным сторонам следить за прогрессом в любое время и на любом уровне, с различных точек зрения; и iii) предоставлять средства, чтобы помочь им принимать решения и исследовать несколько направлений для руководства проекта. Этот инструмент предназначен для упрощения и формализации осуществления элементарных процессов, предлагаемых стандартов при использовании имеющихся данных, включая данные, созданные средствами поддержки бизнес-проекта.

Согласование систем инжиниринг и управление проектами на нормативном уровне

В совместных технологий, с использованием данных обмена, связи или продукта инструменты управления жизненным циклом не является достаточно, чтобы заставить людей сотрудничать; само понятие роли должны быть пересмотрены, а также процессов и взаимодействий между процессами работы Организации в компании и умонастроений. Бизнес-подразделения должны сотрудничать, и что требуется, это другой менталитет, который переопределяет профессионализм как достижение миссии и иметь довольных клиентов или конечных пользователей по сравнению с изо всех сил пытается защитить «газон». Системных инженеров и руководителей программ, приносят уникальные навыки и опыт для программ, на которых они работают (Sudarsan и др., 2005). Эти уникальные возможности необходимы для успешного выполнения программы, как навыки и возможности членов команды из других дисциплин (Langle, 2011). Однако есть также «общее пространство» где Программа менеджеров и инженеров систем сотрудничают для производительности и успех команды программы. Затем каждая дисциплина выиграют от понимания другой дисциплины.

Интеграция систем инжиниринг и управление проектами рассматривался только с начала XXI века. Шарон и коллеги (2011) выдвинул, системы инженерного управления всегда использует некоторые подмножества методы управления проектами и инструментов. Технические мероприятия относятся к области продукта и управленческой деятельности относятся к домену проекта. Однако они представляют собой два взаимодополняющих аспекта системы инженерного управления.

В 2011 и 2012 годах INCOSE и PMI признали важность интеграции систем инженерного управления проектами (Conforto соавт, 2013). С помощью Массачусетского технологического института (MIT), они провели обследование, чтобы лучше понять обязанности системных инженеров и руководителей проектов и, таким образом, чтобы помочь организациям снизить риск программы и повысить их рентабельность инвестиций (ROI). Другая цель заключалась в том, чтобы лучше понять, как управление проектами и инженерных систем были интегрированы в организациях. Результаты выявили как критические интеграции инженерных систем и управления проектами было облегчить непродуктивных напряженности между системами инженерных и управление проектами. Руководство, чтобы помочь системных инженеров и менеджеров проектов повышения эффективности их программ была представлена Oehmen и коллегами (2012). Он указывает на четыре метода для укрепления сотрудничества на основе анализа нескольких случаев для более эффективной интеграции управления проектами и инженерных систем: i) использование стандартов из обоих доменов, ii) формализации определение интеграции, iii) разработка комплексных инженерных оценок программ и iv) разделение ответственности за управление рисками, качество, планирование жизненного цикла и внешних поставщиков

В нашем исследовании мы провели теоретические исследования в соответствие стандартов из обоих доменов. Мы впервые выявлены и проанализированы стандарты и руководства в инженерных систем (например, ANSI/EIA 632, IEEE 1220, INCOSE руководство и Шебок) и сделал то же самое с PM стандартов и руководств (например, ISO 21500 и PMBoK), как указано в графе 1. Мы пришли к выводу, что не единый стандарт или руководство созерцает сотрудничества между инженерных систем и управление проектами, несмотря на то, что инженеры и менеджер должны тесно сотрудничать на всех этапах разработки проекта. Итак мы по сравнению и проанализировали различия и сходства между инженерных систем и стандартов управления проектами и руководства с целью дополнить их во время реализации проекта. Мы пришли к выводу, что это может быть интересно принять ISO 15288 и включить в процесс некоторые процессы ОВОС (Xue и др., 2014a). Однако учитывая, что предлагая выпуск нового стандарта может включать длительный и сложный процесс, мы решили сравнить стандартов и руководств из обоих доменов, чтобы оценить, какие из них лучше всего могут быть выровнены. Мы пришли к выводу, что стандарт ISO/IEC 15288 могут быть согласованы с PMBoK довольно легко.

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

Вставка 1. Стандарты и руководства, рассмотренных в настоящем исследовании

Проектирование систем

Управление проектами

Предложенный метод и инструмент

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

  1. Ускорение и оптимизация процесса развития от дизайна до прототипов
  2. Улучшение управления все более сложного проекта путем усиления координации всех субъектов и процессов

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

В этих корпоративных подходов мы уже определили основные механизмы, которые создают препятствия для бесперебойной работы проекта, включая недостаточно подробный или даже противоречивые набора спецификаций, априорное unjustified (не сказать опасных) выбор технологий, неуклюжие ресурсов, недостаточно общие четкие, структурированные и понятной информации. Мы сосредоточены на проблемах и тупики, связанные с полями обнаружения, анализа, координации и принятия решений: как может ошибки или недостаточной функции обнаружены при первой же возможности? Как можно обнаружить происхождение в истории выбор, сделанный в ходе проекта? Как можно лучшее решение – или хотя бы лучшие корректирующие действия – быть выбраны?

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

Эти предложения основаны на предыдущих исследований, стремясь доказать концепцию и целесообразности такого инструмента (Барон, Эстев & Rochet, 2004; Барон, Rochet & Эстев, 2004; Чжан и др., 2012). На промышленной стороне анализ рынка показывает, что промышленные инструменты, доступные лишь частично удовлетворяют потребностям. Эти инструменты, принадлежащие области бизнес-аналитики стали необходимым для организаций для выявления изменений рано и быстро реагировать и адаптировать свои стратегии. Однако они страдают с их собственными ограничениями, потому что они не обеспечивают общее видение, необходимые для решения критических проблем, таких, как: «Сколько усилий следует мы обязуемся достичь достаточного уровня зрелости для конечного потребителя» или «Как оптимизировать качество продукции при соблюдении ограничений бюджета и времени?» Таким образом научный опыт, а также анализ промышленных потребностей и существующих инструментов, заставили нас разработать первый прототип, названный «Атлас», который постепенно эволюционировали к определению более амбициозной один, DECWAYS. В следующем разделе мы кратко опишите цели и результаты системы «Атлас» и где DECWAYS стоит относительно первого прототипа.

АТЛАС

Исследовательский проект НРУ/атлас (2008-2011 годы) рассматривается связь между проектами и дизайн продукта, как показано на рисунке 1.

Рисунок 1

Рисунок 1. Архитектура платформы Атлас

Эти два домена были предметом многих исследований в течение многих лет, и были предложены довольно широкий спектр программных решений (например, в области управления проектами: Primavera, MS Project, и др.; в Управление жизненным циклом продукта: Windchill, центр группы, ENOVIA, и др.). С другой стороны Формализация отношений, которые всегда существовали между этими процессами была новая идея. Он был протестирован с промышленниками двадцати или около того; обследование, проведенное показали высокий уровень заинтересованности в принципе и подчеркнул ожидаемые результаты (DRIRE, 2009).

Технически говоря, отправной точкой проекта «Атлас» является стандарт EIA-632 для инженерной системы. Этот стандарт позволяет проект быть разбита на подпроекты, ведущие к классическим древовидным представлением. Это разложение также позволяет обзор альтернативных решений, когда придет время, чтобы выбрать для технического решения для проекта в памяти для последующего использования. Что касается разбивки проекта на подпроекты и преодоление трудности обмена данными в этой древовидной структуре, ключевым результатом «Атлас» был рисунок из общей информационной модели передачи между проектом и подпроекта (Geneste соавт., 2009).

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

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

Чтобы стать оперативным, эти два сцепного механизма требуют формального механизма принятия решений активироваться всякий раз, когда сцепного устройства информации или связи изменения сети оправдывает его. Этот механизм не были определены в системе «Атлас».

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

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

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

Сосредоточив внимание на ограничения системы «Атлас» (то есть версии, которые не являются управляемыми, жесткая древовидная структура, которая должна быть Гомоморфные, процессы проверки, не принимается во внимание, т. д.), стало ясно, что мы должны продолжить изучение вопроса: i) методология, используемая (путем проведения более подробного анализа промышленной практики и инструментов); II) стандарты путем осуществления весьма подробный сравнительный анализ инженерных систем и стандартов управления проектами; и iii) технические характеристики (включив в проект вычислительной платформы новых технологий, доступа к данным и обмена, новый интерфейс поколений. и др.).

DECWAYS

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

По сравнению с ATLAS DECWAYS предлагает новые предложения:

  1. Представляет общий процесс управления высокого уровня проекта, который легко может быть присвоен компаний, обработка междисциплинарных функций и дополнений PMBOK практики. Цель заключается в том, чтобы содействовать согласованности между дисциплинами и особенно инженерных систем и управления проектами путем согласования их описания концепции проекта и его составляющие процессы стратегической потребности как основывается на INCOSE/PMBOK выравнивание (Conforto соавт, 2013). Таким образом проект «Атлас» была усовершенствована принять во внимание стандартизации между системами, технологических процессов и управления проектами и использовать понятие показателей поддержки этого выравнивания.
  2. Уточнение понятия индикаторов как языковых элементов, общих для соответствующих дисциплин. Цель заключается в:
    • Выделите индикаторы, позволяющий проверить, как заинтересованные стороны обрабатывают любое несоответствие между ожиданиями и результатами. Эти ожидания могут иметь дело с системой для создания (как видно с точки зрения производительности, стабильности и целостности Организации, поддержка проекта) или системы (как с точки зрения продукта или услуги) (Барон соавт., 2009).
    • Показать, как построить «совокупные показатели» и «панели» обеспечение общего процесса надзора потенциала. Цель заключается в том, чтобы объединить и содействовать использованию всех данных, управлять проектами и более в целом поддержки принятия решений при управлении reputedly очень сложными проектами.
  3. Разработка смарт-системы для комплексного управления проекта в области развития, опираясь на модель универсального процесса и показателей и панелей мониторинга для мастер междисциплинарный и хода выполнения проекта; Цель заключается в:
    • Определите механизмы, которые обеспечивают подлинную помощь с учетом потребностей заинтересованных сторон и последующих мер, проверка и проверка этих потребностей согласно показателей, отобранных.
    • Предвидеть и планировать усилия необходимо, тем не менее дорогостоящей, но неизбежно, чтобы проверить и проверить обе системы (например, системы и системы для создания).
    • Предложить механизмы для отслеживания любых неисправностей, опираясь в частности на анализе тенденций и предлагая помощь для решения решений и продольного последующих эволюции проекта.
    • Разрешить исследование вариантов для направления развития систем будет построен проект.

Чтобы указать контуры, цели, функционирования и услуг, предлагаемых DECWAYS, первая цель заключалась в том, чтобы добиваться согласования управления проектами и систем моделирование процессов (потребностей и требований, проектирование архитектуры, системный анализ, проверка и проверка), применяемых к проекту. Как упоминалось ранее, Zolghadri и коллеги (2010, 2011) позволил нам проанализировать основные различия в их описания, а также роли участвующих в процессе. Сравнительное исследование процессов определены основные отклонения в их описаниях (Xue соавт, 2014b), роль в любом процессе и представлены пути и средства придания более оперативного характера этих процессов путем содействия их сотрудничеству на практике путем искать и определения связей между ними (Xue и др., 2014b). Это является предпосылкой и условием для успешного достижения универсального процесса управления проектами, который включает координацию, принятие решений, отслеживания, анализа, запоминания, последующей деятельности и коррекции. Стандартизация описания процесса является одним из способов сближения совместно систем инженерных и подходов к управлению проектами.

DECWAYS намеревается полагаться на расширенную версию ANSI/EIA 632 стандарт для инженерных систем и PMBOK для управления проектами (Xue и др., 2014b). В результате выбор DECWAYS лежит в рамках подхода, определенных в проекте INCOSE-PMI-MIT.

Однако анализ выходит за рамки этого результата. Действительно, для того чтобы удовлетворять наши прагматические высказанная ранее (то есть, для адаптации стандартов и их масштаб для МСП посредством простых в использовании инструментов), необходимо упростить организацию и взаимосвязь процессов и определить, каким образом и когда процессы были (или могут быть) взаимосвязаны и кто (то есть, роль) был вовлечен в компании. Вариант, который уже определены в проекте «Атлас» состоял из рекурсивного описания пакетов сцепленных задач и муфты проектирования и управления через прозрачность модели, связывая лидеров этих двух общин. Возможное решение в DECWAYS бы распределить общее руководство проекта по трем видам деятельности с взаимодополняющими обязанностями-Executing (Ex), планирование (Pl), контроллинг (Co)-опираясь на одно структурное представление проекта (например, тип декомпозиции работ). Эти три функции (Ex, Pl, и Co) разделяют такое же обязательство, при программировании так диктует или при неисправности предупреждающий знак, приступить к обсуждению и идти вперед, только если принято решение, и если было проведено распространение и запоминание.

Для этих мероприятий, благо совместного использования общего представления заключается в сотрудничестве, которое влечет за собой и формализует: на каждом временном шаге, любые расхождения относительно первоначального программирования будут охарактеризованы путем использования показателей и проект будет разрешено только продолжать, если три партнера-Ex, Pl и Co-разрешение. Как охарактеризовать потенциальные расхождения каждый партнер может в пределах их компетенции анализировать вверх по течению требования, которые не были выполнены и найти причины для такого отклонения в пределах или без их области знаний и инициировать диалог со своими партнерами. Однако, DECWAYS не мешает выбора механизма для принятия решений: это может быть либо результатом обсуждения путем консенсуса или заниматься непосредственно каждый руководитель проекта. Что здесь важно, чтобы записать решение и его контекст для того, чтобы запомнить маршруты решения и постепенно улучшить их с течением времени на основе опыта.

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

В оперативном плане, эти показатели имеют различные жизненные циклы: их определения, переговоры между заинтересованными сторонами объективных ценностей и связанных с ними параметров (то есть, пороговые значения, диапазоны действия, т. д.) и их эволюцию с течением времени, как во время выполнения. Они отражают или вычисляются на основе данных, молчаливым информации и знаний, зарегистрированных компанией в своей информационной системе (например, данные, поступающие от корпоративного планирования ресурсов, данные о ходе осуществления проекта и последующей деятельности в связи с инструментом планирования, и др.). В DECWAYS, цель заключается таким образом, чтобы получить большее понимание в концепцию показателей, с тем чтобы обеспечить в нескольких индикаторов подхода (то есть, чтобы выразить это в виде нескольких индикаторов), с возможностью диалога, для обнаружения опасности и сугробы, чтобы диагностировать и проанализировать с конечной целью отслеживания его обратно дизайн и набор спецификаций , в случае необходимости, технической и организационной стороны. Для этого мы определили ряд показателей, функции и характер которых отличаются: предопределенные «классические» показатели, связанные с определением процессов в инженерных стандартах систем и «подгонять» из них, в зависимости от проекта или по отношению к стратегии компании. Как и в системе «Атлас», определение панели мониторинга и оператора взаимодействия являются неотъемлемой частью проекта: с учетом необходимости иерархической конструкции задач, показатели будут постепенно агрегироваться, что может привести к многоуровневой конструкции этих показателей. На рисунке 2 обобщаются основные принципы метода и инструмента.

Рисунок 2

Рисунок 2. Архитектура платформы DECWAYS

Заключение

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

DECWAYS метод и средство устранения любых несоответствий, которые могут существовать между системами инженерных и проектов управления доменами с прагматической точки зрения. Это выполнить по проекту «Атлас», который продемонстрировал осуществимость концепции и служил в качестве прототипа для проверки промышленного значения этих предложений. Решает вопрос о совместной работы и рулевое управление проекта в последовательно с точки зрения последующей деятельности и решений. DECWAYS стремится предложить метод и инструмент, способный сближения систем инженерии и управления проектами ближе, выявления практических различий, принятия согласованных решений и совместно контроль надлежащего развития проекта и системы. Эта статья представлены цели и характеристики DECWAYS инструмент, который направлен на решение этой проблемы. Как подчеркнул INCOSE-PMI-MIT анализ естественным средством достижения процесса сотрудничества, в DECWAYS, является использование стандартов из доменов, так и процессов от этих стандартов. Но, помимо простого вопроса о выборе между основными стандартами и с целью достижения лучшего соответствия процессов управления проектами, DECWAYS также рассматривает другие способы согласования процессов из обоих доменов, таких как разделение ответственности и пересечения данных к процессу совместного решения. Для этого, он намеревается структурировать сотрудничество (например, между процессами, актеров, т. д.) и предоставить руководителям проектов и инженеров с информацией производится для оказания помощи в принятии решений. Техническая и научная озабоченность вписывается в хорошо с текущей целью снижения стоимости интеллектуальной работы (например, управление, инжиниринг, финансы) 5000 миллиардов долларов ежегодно до 2025 года через «умные» программного обеспечения (глобального института McKinsey, 2013. Таким образом, DECWAYS должно облегчить управление проектами в компании путем предоставления: i) прогресс видимости, ii) формального процесса принятия решений и iii) Отслеживаемость.

 

Выражение признательности

Более ранняя версия этой статьи была представлена в 2014 году Международной конференции по технологии, технологии и инноваций (ICE), которая проходила с 23 июня по 25 в Бергамо, Италия. ICE Конференция обсуждает систем как социально технической задачи, с уделением особого внимания разработке продуктов и услуг и предпринимательства инновационного процесса для его принятия в обществе и экономике.

 


Ссылки

Барон, C., Эстев, д & Rochet, S. 2004. Как эволюционные вычисления могут быть введены для выбора и оптимизировать сценарии вдоль процесса проектирования продукта. Операции на системах, 3(2): 888-893.

Барон, C., Rochet, S. & Estève д 2004. Генетический подход поддержки директивным органам во время управления проектами. Операции на системах, 3(3): 1027-1032.

Барон, C., Auriol, г., Zolghadri, м., Вехбе, а., Merlo, C. & Жирар, р. 2009. Livrable L6: Децентрализованные сопоставительное et de планировка - версия финал des вара et использует принципы. Раппорт де Contrat: Projet АНР RNTL: АТЛАС 07TLOG002.

Пиво, м. & Nohria, н. 2000. Крекинг код изменения. Harvard Business Review, 78(3): 133-141.

Conforto, э., Росси, м., Rebentisch, э., Oehmen Дж. & Pacenza, м. 2013. Улучшение интеграции управления программами и системотехники. Опрос доклад, представленный на 23 INCOSE ежегодный Международный
Symposium.http://cepe.mit.edu/survey-results-pm-se/

Даниловичу, м. & Браунинг, т. р. 2007. Управление проектами разработки сложных изделий с проектирования структуры матрицы и матрицы сопоставления доменов. Международный журнал управления проектами, 25(3):
300-314.http://dx.doi.org/10.1016/j.ijproman.2006.11.003

DRIRE. 2009. Отчет о проекте APOSAR: Analyse des Problématiques Organisationnelles du Secteur Aéronautique Régional. Париж: Направление деятельности де l'Industrie, de la Recherche et де l'Environnement (DRIRE).

Эппингер, с. д. & Салминен, против 2001. Шаблоны продукта развития взаимодействий. Международная конференция по
Design.http://hdl.handle.net/1721.1/3808
инженерии

Geneste, л, Reversat ю., Роберт, а., Эстебан, стр., Esteve, д., Паскаль, ж. C., Abeille, Дж. 2009. Livrable L5: Spécification подробные действие де l'environnement де зачатия. Раппорт де Contrat: Projet АНР RNTL: АТЛАС 07TLOG0022009.

Langle, м., 2011. К нового мышления – преодоление разрыва между системами управления программами и инжиниринг. PM сеть, Сентябрь: 24 – 26.

Ли, с. г., мА, ю. S., Thimm, г. л. & Верстратен, Дж. 2008. Управление жизненным циклом продукции в авиации обслуживания, ремонта и капитального ремонта. Компьютеры в промышленности, 59(2-3):
296 – 303.http://dx.doi.org/10.1016/j.compind.2007.06.022

Глобального института McKinsey. 2013. Подрывной технологии: Авансы, что превратит жизнь, Бизнес и глобальной экономики. McKinsey & компании. http://www.McKinsey.com/Insights/business_technology/disruptive_technolo...

Nayagam. 2011. Расформировать sur les использований de решения PLM en entreprise. Пресс-релиз. Консультанты Пьер Audoin (ПАК), 13 декабря 2011. Доступ к 1 марта,
2015:https://www.pac-online.com/enqu%C3%AAte-sur-les-usages-de-solutions-plm-...

Oehmen, Дж. и др. 2012. Руководство по Lean создают условия для управления инженерных программ. Кембридж, Массачусетс: Совместный MIT PMI INCOSE сообщества практики Lean в программе
Management.http://hdl.handle.net/1721.1/70495
, 2012.

Pyster, а. & Olwell, д 2013. Руководство для систем инженерного органа знаний (Шебок), v.1.1. Хобокен, Нью-Джерси: Попечителей Института Стивенса. Доступны с 1 марта
2015:http://www.sebokwiki.org/

Шарон а., де, в. & Оливье, л 2011. Системы управления проектами и инженерного управления: Практикующий вид интеграции проекта и продукта домены. Проектирование систем, 14(4):
427 – 440.http://dx.doi.org/10.1002/sys.20187

Стэндиш Group International. 2013. Манифест хаоса 2013: Think Big, Act Small. Стэндиш Group International.

Sudarsan, р., Fenves, S. Дж., Sriram, р. д & Ван, ф 2005. Моделирования основы для управления жизненным циклом продукта информации продукта. Компьютерный дизайн, 37(12):
1399 – 1411.http://dx.doi.org/10.1016/j.cad.2005.02.010

Sudarsan, р., Сабрахманиан е., Боурас, а., Fenves, S.J., Foufou, S. & Sriram, р. д 2008. Обмен информацией и в контексте управления жизненным циклом продукта: Роль стандартов. Computer-Aided Design, 40(7):
789-800.http://dx.doi.org/10.1016/j.cad.2007.06.012

Сюэ, р., барон, C. & Эстебан, P. 2014a. Интеграция систем инженерного управления проектами: Текущий вызов! INCOSE 2014 Международный симпозиум.

Сюэ, р., барон, C. & Эстебан, P. 2014b. Управление процессами инженерных систем: Мульти стандартный подход. 8-й ежегодной Конференции международных систем IEEE.

Чжан, х., Ориоль, г., Eres, х. & Барон, C. 2013. Предписывающий подход и количественно оценить потребительскую ценность для стоимости на основе требований инженерных. Международный журнал компьютерных интегрированных производства, 26(4):
327-345.http://dx.doi.org/10.1080/0951192X.2012.717718

Zolghadri, м., барон, C. & Жирар, стр. 2010. Моделирование взаимной зависимости между продуктом архитектуры и сети партнеров. Международный журнал по разработке продукции, 10(1/2/3):
62-86.http://dx.doi.org/10.1504/IJPD.2010.032451

Zolghadri, м., барон, C., Aldanondo, м. & Жирар, р. 2011. Общие рамки для новых проектов разработки продукта. Международный журнал управления технологиями, 55(3/4):
250-262.http://dx.doi.org/10.1504/IJTM.2011.041951

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!

Ключевые слова: Совместный инжиниринг, поддержки принятия решений, инженерных процессов, управление проектами, проектирование систем, инженерных систем, систем стандартов

Добавить новый комментарий

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.