Интеграция данных, интеграция деятельности: федеративные PLM-системы.
1. Когда-то возникла хорошая идея: интегрировать данные различных специальных (механических, электрических, технологических) САПР в одной базе данных, чтобы хоть как-то обеспечить общее для них управление конфигурацией (маркирование базисов "типовой проект", "как спроектировано для площадки/изделия X", "как удалось сделать в реальности"), нахождение коллизий и управление изменениями ("тут мы нашли очередную проблему, поменяйте ваши дурацкие проектные решения!"). Так появились системы PDM (product data management), которые сначала объединяли электронные "документы" под общим управлением конфигурацией, и поддерживали workflow по утверждению этих конфигураций и отгрузке конфигураций в архивы заказчика, а также issue tracking по отслеживанию изменений в рабочей конфигурации. Потом жизнь заставила перейти от PDM к PLM:
-- от документоцентрики был сделан огромный скачок в датацентрику, к настоящей объектой базе данных "для всего на свете". В самых продвинутых продуктах у САПРов уже нет своих баз данных, а они просто имеют свой кусочек в общих данных.
-- захвату не только конструкторских/проектных моделей, но и требований, тестов, интеграция поведенческих моделей целевой системы, производственных моделей в составе САПР, что задало дополнительные требования к гибкости модели данных главного хранилища ("репозитория" -- так обычно называют помойку для очень разнородных данных).
-- от поддержки рудиментарного workflow/issue tracking к полноценному гибко настраиваемому процессному/трекинговому движку, по мощности вполне сравнимого с промышленными системами документооборота/управления процессами/управления кейсами
2. PLM начали бойко внедряться, ибо сулили невиданные перспективы. "Управление жизненным циклом" стало модно. Но тут произошла беда: поскольку частных жизненный циклов в холонически построенном изделии много, то одновременно в крупных проектах начало внедряться много PLM. Вместо одной PLM на сотни и сотни рабочих мест проектировщиков и конструкторов обнаружилось, что по одной PLM приходится чуть ли не на каждое подразделение крупного предприятия. Мало того, что для каждой вендорской линейки САПР выбиралась PLM того же вендора, и зоопарковость от этого только повысилась, так еще и начали появляться по многу инстансов по-разному настроенных PLM одного вендора. Выяснилось, что в реальном мире никакого "жизненного цикла" нет (кроме существующего где-то в головах менеджеров, и ГИПа/главного конструктора в той мере, в которой его таки интересует проект в целом), но есть множество самых разных жизненных циклов, которые как-то сосуществуют друг с другом и каждый такой жизненный цикл обзаводится своей системой PLM.
В ответ менеджеры и мечтатели из разных организаций выдали на-гора множество директив, в которых упоминалось слово "единый". Проблема в том, что точек собирателей земли сапровой оказалось огромное количество: "единство" уровня проектно-конструкторского бюро (ибо там ведь не просто "проектирование", а "комплексное проектирование"!), единство стадии жизненного цикла (напомню: в ISO 24744 совершенно не случайно стадии жизненного цикла выделяются по "ментальным установкам", cognitive framework -- то есть подразумевают абсолютно разную настройку PLM, разные используемые стандарты обмена данными, разные классификаторы оборудования), единство отдельного предприятия (ибо весь этот зоопарк кому-то нужно сопровождать, да и заказчику лучше бы сдавать что-то согласованное уже внутри предприятия, и сдавать лучше бы из одной точки, а не из многих), единство уровня холдинга (а в таких случаях, как атомщики -- это единство уровня отрасли), и единство уровня эко-системы (как сейчас на Западе любят называть расширенное предприятие, занимающееся какой-то производственной программой по системе связанных контрактов -- например, предприятия, которые строят атомные электростанции, или подводные лодки, или буровые ледовые платформы. Это даже не отрасли, а какой-то срез поперек отраслей: так, атомщики, машиностроители и судостроители связаны много запутаннее, чем подразумевают границы отраслей). Нет ничего единее этой борьбы за единство на всех уровнях, но нижние уровни почему-то всегда ухитряются реализовать сепаратизм -- и настроить свои PLM так, как никакой системе мало не покажется.
3. Тем самым мы имеем множество "фокусов интеграции данных/обеспечения Единого Информационного Пространства Для Всего", и эти фокусы интеграции находятся буквально в каждой клеточке матрицы "уровни структуры вещества * уровни воплощения" (подробнее см. http://incose-ru.livejournal.com/29605.html). А посколько отдельные организационные единицы специализируются на полном жизненном цикле в одной клеточке (в том числе вся эта матрица -- отдельная клеточка в надсистеме, ничему не противоречит), то этих PLM будет огромное количество. Федерация PLM, а не централизованная PLM. Федеральные настройки, местные настройки, федеральные стандарты, местные стандарты, борьба за суверинитеты, а на уровне получивших суверинитет и таможни со злобными спецами по секьюрити.
Проблема в том, что всё это должно работать совместно, в рамках проекта и жизненного цикла верхнего уровня. Так что единственная надежда -- на стандарты, по которым работает федерация.
Когда-то было много-много разных несовместимых в том числе друг с другом компьютерных сетей. На нижнем уровне эти сети использовали витые пары, телефонную лапшу, оптоволокно, радиоканалы и много еще чего. На верхнем уровне использовали тоже много чего. А потом появилось понятие "сети сетей" -- интенет. Интернет не имеет структуры (структуру имеют сети, из которых этот интернет состоит), но он имеет организацию. И эта организация основана на стандартах.
Мы не сможем сделать СУЖЦ на базе одной PLM, которая заменит собой все остальные PLM. Мы не сможем заменить остальные PLM, мы сможем только федерировать всё это разнообразие PLM, в которых на разных уровнях вещества и воплощения воткнуты самые разные предметные САПР и самое разное специальное программное обеспечение собственной разработки мелких предприятий и мелких подразделений крупных предприятий. Жизнь предприятий устроена не так, как устроена жизнь крупных инженерных проектов, через эти предприятия проходящих: жизненных циклов разных систем, которыми нужно управлять на какой-то одной их стадии воплощения и каком-то определенном уровне декомпозиции системы, много на каждом предприятии, и эти "жизненные циклы проектов" только части полных жизненных циклов системы, да к тому же управляемых по ходу этих жизненных циклов еще откуда-то (скажем, поменялся у системы хозяин, и новая метла будет мести всё это PLM-хозяйство по-новому -- так, что ли?).
Мы должны делать СУЖЦ по образу и подобию интернета, как интеграционное решение "PLM PLMов" -- то есть основываться на архитектурных стандартах взаимодействия по-разному устроенных узлов такой сети. Единство интернета обеспечивается не единством его центрального узла, через который проходит абсолютно весь трафик, и оптимизируется вся мировая сеть. Единство управления жизненным циклом и "информационного пространства подразделения/предприятия/расширенного предприятия/эко-системы" обеспечивается отнюдь не копированием всей информации в одну базу данных одной PLM-системы, и ведением всего workflow и issue tracking процессным движком этой системы.
4. В любой PLM можно выделить модели двух систем, приходящие из разных воткнутых в неё САПР:
-- целевой системы (system-of-interest), product model. СМД-методологи тут говорят о "предметной доске".
-- обеспечивающей системы (enabling system -- которая обеспечивает продвижение system-of-interest по ее жизненному циклу), project model. СМД-методологи тут говорят об "организационной доске".
Фишка в том, что целевая система рассматривается в ходе разработки не столько как "активная структура" (в терминах Архимейт), сколько как "пассивная структура", над которой выполняет разные трансформации обеспечивающая система как "активная структура". Другими словами, разработка описывается как "объект целевой системы -- поведение объекта обеспечивающей системы -- объект обеспечивающей системы".
Это совершенно не исключает того факта, что есть и поведенческие модели целевой системы, которые целиком находятся в продуктной модели и гарантируют работоспособность целевой системы на ее стадии эксплуатации, когда она сама будет активной системой и будет взаимодействовать с другими системами в ее надсистеме/операционном окружении. Но это совсем другая история, и мы не будем путать "целевые процессы" с "обеспечивающими жизненный цикл целевой системы, т.е. организационные процессы".
Поведение обеспечивающей системы (работы!), выполняемые ее объектами, могут быть поделены на работы людей, компьютеров, инструментов. Я не буду разделять все эти случаи. Обычно про последовательность работ, в которой не разделяют работы людей, компьютеров и других (как правило, интеллектуальных - внутри них либо сидит человек, как в экскаваторе, либо компьютер, как в автопилоте) инструментов, называют воркфлоу -- потоком/ходом работ.
Модель обеспечивающей системы и структурная модель целевой системы оказываются тесно связанными. Всё, что мы делаем в обеспечивающей системе, должно быть отнесено к чему-то в целевой системе. И уж как минимум, эти две модели должны следовать общей картине мира -- модель данных этих двух моделей должна быть одна и предусматривать указание этих связей задействования объектов целевой системы в работах объектов обеспечивающей системы.
5. Во всех современных PLM в моделях данных их репозиториев есть как части, отвечающие за описание целевой системы, так и части, отвечающие за описание ролей исполнителей и тех или иных действий в workflow (включая управление процессами/проектами/кейсами/issue).
Тут нужно заметить, что workflow (хоть в варианте его "на лету" составления из обрывков-шаблонов, как в adaptive case management, хоть в варианте предварительно спроектированного целиком, как в BPM и/или проектном управлении) сам по себе является исполнением программы, а его описание -- программой.
Программа -- это двойственный объект. Программа является данными с одной стороны, а с другой стороны, она подразумевает какую-то развертку во времени, набор альтернативных будущих, соответствующих ветвям программы -- программа подразумевает исполнение, реальное выполнение процесса.
Интеграция пассивных описаний целевой системы подразумевает собой только традиционную для PLM интеграцию данных жизненного цикла целевой системы (как пассивной структуры).
Интеграция описаний обеспечивающей системы подразумевает
а) интеграцию данных жизненного цикла целевой системы (иначе у операций "программы создания целевой системы" не будет операндов -- этими операндами являются объекты целевой системы)
б) интеграцию данных описания процесса обеспечивающей системы (traversal workflow -- нужно интегрировать знание о том, как этот workflow проходит по разным PLM).
в) интеграцию собственно процесса выполнения этой программы/процесса обеспечивающей системы.
Грубо говоря, в концепции "единой PLM одной на всех" у нас типичное "программирование-в-малом", а вот в федерации PLM и эко-системе у нас типичное "программирование-в-большом" (когда разные части программы расположены в узлах сети, и выполняются асинхронно). По сути дела, работа над сложными инженерными проектами представляет собой что-то типа массивно-параллельного вычисления, в котором можно забыть об идее собрать в одной PLM всю программу/workflow/tracking этого масштабного "вычисления" (выполнения работ/операций на десятках тысяч компьютеров, в десятках тысяч мозгов, в десятках тысяч программ в случае проектов типа создания самолётов, подводных лодок, атомных электростанций, нефтегазовых месторождений).
6. Увы, при наличии развитых архитектур интеграции данных (взять хотя бы ISO 15926), пригодных для интеграции как данных описания проекта, так и данных описания системы, для интеграции workflow (создания traversal workflow) нет почти никаких заделов:
-- справочные данные для интеграции описаний геометрии изделия, или технологии (P&ID) активно тестируются уже, и есть возможность сообщить из одной PLM о происходящем с целевой системой другому PLM. Но справочных данных для интеграции описания поведения/деятельности обеспечивающей системы пока нет. Хотя у нас есть проект praxos, но требуемой для интеграции данных мощной онтологии деятельности в готовом виде соответствующих ISO 15926 справочных данных пока нет. Это первое, что нужно сделать для обеспечения traversal (проходящий через разные PLM и независимые пока от PLM софтинки) workflow: получить справочные данные для интеграции описаний деятельности. И тогда можно будет сообщить одной PLM о происходящем с обеспечивающей системой в другой PLM. Хинт: нельзя иметь отдельную интеграционную архитектуру для данных по workflow от архитектуры интеграции данных по целевой системе. Ибо элементы workflow работают с элементами целевой системы -- не проинтегрируешь элементы, не на что будет ссылаться. Так что задача интеграции данных PLM просто должна быть расширена с частной задачи интеграции данных продукта включением задачи интеграции данных проекта, включая данные о текущем состоянии дел в "непроектных движках" (т.е. движках процессного управления и трекинга) -- желательно, по одной и той же технологии, и с использованием одних и тех же (нейтральных) справочных данных, чтобы гарантировать целостность и связность результата интеграции.
-- "передача управления" от программы в одном узле в сети в программу на другом узле сети требует особой организации и связано обычно с передачей сообщений. Структура этих сообщений и протоколы передачи требуют особого обсуждения. Обычно это обсуждается в рамках той или иной реализации SOA. То есть для обсуждения интеграции исполнения требуется понимать реализацию SOA в части, позволяющей дистанционно из процессного движка одних программ толкнуть процессный движок находящейся совсем в другом месте другой программы. Понятно, что этих SOA в разных системах может оказаться столько же, сколько разных PLM (у каждой ведь есть любимый SOA-framework, интегрирующий PLM со своими САПР/authoring tools). Тем самым нужно иметь какие-то средства интеграции для выполненных в разных SOA-frameworks вычислений, что (по аналогии) требует разработки онтологии для описания вычислений ровно так же, как онтология деятельности требуется для интеграции данных по workflow.
Увы, в этом всём пока конь не валялся, и никакие общие декларации типа "держите структуры данных отдельно, а выполняющие workflow приложения отдельно" тут принципиально не помогут. Выделение из приложений одного-на-всех корпоративного воркфлоу-движка (BPM engine, или issue tracker или что угодно) не поможет, ибо таких движков оказывается много, по числу корпораций с выбранными для них движками. То есть нужно честно озаботиться workflow traversal через множество процессных движков -- уметь это описывать на нейтральном языке, и далее реализовывать на тех обрывках исполняющей процессы айтишной инфраструктуры, которые удастся найти в подразделении/организации/холдинге/эко-системе.
-- от документоцентрики был сделан огромный скачок в датацентрику, к настоящей объектой базе данных "для всего на свете". В самых продвинутых продуктах у САПРов уже нет своих баз данных, а они просто имеют свой кусочек в общих данных.
-- захвату не только конструкторских/проектных моделей, но и требований, тестов, интеграция поведенческих моделей целевой системы, производственных моделей в составе САПР, что задало дополнительные требования к гибкости модели данных главного хранилища ("репозитория" -- так обычно называют помойку для очень разнородных данных).
-- от поддержки рудиментарного workflow/issue tracking к полноценному гибко настраиваемому процессному/трекинговому движку, по мощности вполне сравнимого с промышленными системами документооборота/управления процессами/управления кейсами
2. PLM начали бойко внедряться, ибо сулили невиданные перспективы. "Управление жизненным циклом" стало модно. Но тут произошла беда: поскольку частных жизненный циклов в холонически построенном изделии много, то одновременно в крупных проектах начало внедряться много PLM. Вместо одной PLM на сотни и сотни рабочих мест проектировщиков и конструкторов обнаружилось, что по одной PLM приходится чуть ли не на каждое подразделение крупного предприятия. Мало того, что для каждой вендорской линейки САПР выбиралась PLM того же вендора, и зоопарковость от этого только повысилась, так еще и начали появляться по многу инстансов по-разному настроенных PLM одного вендора. Выяснилось, что в реальном мире никакого "жизненного цикла" нет (кроме существующего где-то в головах менеджеров, и ГИПа/главного конструктора в той мере, в которой его таки интересует проект в целом), но есть множество самых разных жизненных циклов, которые как-то сосуществуют друг с другом и каждый такой жизненный цикл обзаводится своей системой PLM.
В ответ менеджеры и мечтатели из разных организаций выдали на-гора множество директив, в которых упоминалось слово "единый". Проблема в том, что точек собирателей земли сапровой оказалось огромное количество: "единство" уровня проектно-конструкторского бюро (ибо там ведь не просто "проектирование", а "комплексное проектирование"!), единство стадии жизненного цикла (напомню: в ISO 24744 совершенно не случайно стадии жизненного цикла выделяются по "ментальным установкам", cognitive framework -- то есть подразумевают абсолютно разную настройку PLM, разные используемые стандарты обмена данными, разные классификаторы оборудования), единство отдельного предприятия (ибо весь этот зоопарк кому-то нужно сопровождать, да и заказчику лучше бы сдавать что-то согласованное уже внутри предприятия, и сдавать лучше бы из одной точки, а не из многих), единство уровня холдинга (а в таких случаях, как атомщики -- это единство уровня отрасли), и единство уровня эко-системы (как сейчас на Западе любят называть расширенное предприятие, занимающееся какой-то производственной программой по системе связанных контрактов -- например, предприятия, которые строят атомные электростанции, или подводные лодки, или буровые ледовые платформы. Это даже не отрасли, а какой-то срез поперек отраслей: так, атомщики, машиностроители и судостроители связаны много запутаннее, чем подразумевают границы отраслей). Нет ничего единее этой борьбы за единство на всех уровнях, но нижние уровни почему-то всегда ухитряются реализовать сепаратизм -- и настроить свои PLM так, как никакой системе мало не покажется.
3. Тем самым мы имеем множество "фокусов интеграции данных/обеспечения Единого Информационного Пространства Для Всего", и эти фокусы интеграции находятся буквально в каждой клеточке матрицы "уровни структуры вещества * уровни воплощения" (подробнее см. http://incose-ru.livejournal.com/29605.html). А посколько отдельные организационные единицы специализируются на полном жизненном цикле в одной клеточке (в том числе вся эта матрица -- отдельная клеточка в надсистеме, ничему не противоречит), то этих PLM будет огромное количество. Федерация PLM, а не централизованная PLM. Федеральные настройки, местные настройки, федеральные стандарты, местные стандарты, борьба за суверинитеты, а на уровне получивших суверинитет и таможни со злобными спецами по секьюрити.
Проблема в том, что всё это должно работать совместно, в рамках проекта и жизненного цикла верхнего уровня. Так что единственная надежда -- на стандарты, по которым работает федерация.
Когда-то было много-много разных несовместимых в том числе друг с другом компьютерных сетей. На нижнем уровне эти сети использовали витые пары, телефонную лапшу, оптоволокно, радиоканалы и много еще чего. На верхнем уровне использовали тоже много чего. А потом появилось понятие "сети сетей" -- интенет. Интернет не имеет структуры (структуру имеют сети, из которых этот интернет состоит), но он имеет организацию. И эта организация основана на стандартах.
Мы не сможем сделать СУЖЦ на базе одной PLM, которая заменит собой все остальные PLM. Мы не сможем заменить остальные PLM, мы сможем только федерировать всё это разнообразие PLM, в которых на разных уровнях вещества и воплощения воткнуты самые разные предметные САПР и самое разное специальное программное обеспечение собственной разработки мелких предприятий и мелких подразделений крупных предприятий. Жизнь предприятий устроена не так, как устроена жизнь крупных инженерных проектов, через эти предприятия проходящих: жизненных циклов разных систем, которыми нужно управлять на какой-то одной их стадии воплощения и каком-то определенном уровне декомпозиции системы, много на каждом предприятии, и эти "жизненные циклы проектов" только части полных жизненных циклов системы, да к тому же управляемых по ходу этих жизненных циклов еще откуда-то (скажем, поменялся у системы хозяин, и новая метла будет мести всё это PLM-хозяйство по-новому -- так, что ли?).
Мы должны делать СУЖЦ по образу и подобию интернета, как интеграционное решение "PLM PLMов" -- то есть основываться на архитектурных стандартах взаимодействия по-разному устроенных узлов такой сети. Единство интернета обеспечивается не единством его центрального узла, через который проходит абсолютно весь трафик, и оптимизируется вся мировая сеть. Единство управления жизненным циклом и "информационного пространства подразделения/предприятия/расширенного предприятия/эко-системы" обеспечивается отнюдь не копированием всей информации в одну базу данных одной PLM-системы, и ведением всего workflow и issue tracking процессным движком этой системы.
4. В любой PLM можно выделить модели двух систем, приходящие из разных воткнутых в неё САПР:
-- целевой системы (system-of-interest), product model. СМД-методологи тут говорят о "предметной доске".
-- обеспечивающей системы (enabling system -- которая обеспечивает продвижение system-of-interest по ее жизненному циклу), project model. СМД-методологи тут говорят об "организационной доске".
Фишка в том, что целевая система рассматривается в ходе разработки не столько как "активная структура" (в терминах Архимейт), сколько как "пассивная структура", над которой выполняет разные трансформации обеспечивающая система как "активная структура". Другими словами, разработка описывается как "объект целевой системы -- поведение объекта обеспечивающей системы -- объект обеспечивающей системы".
Это совершенно не исключает того факта, что есть и поведенческие модели целевой системы, которые целиком находятся в продуктной модели и гарантируют работоспособность целевой системы на ее стадии эксплуатации, когда она сама будет активной системой и будет взаимодействовать с другими системами в ее надсистеме/операционном окружении. Но это совсем другая история, и мы не будем путать "целевые процессы" с "обеспечивающими жизненный цикл целевой системы, т.е. организационные процессы".
Поведение обеспечивающей системы (работы!), выполняемые ее объектами, могут быть поделены на работы людей, компьютеров, инструментов. Я не буду разделять все эти случаи. Обычно про последовательность работ, в которой не разделяют работы людей, компьютеров и других (как правило, интеллектуальных - внутри них либо сидит человек, как в экскаваторе, либо компьютер, как в автопилоте) инструментов, называют воркфлоу -- потоком/ходом работ.
Модель обеспечивающей системы и структурная модель целевой системы оказываются тесно связанными. Всё, что мы делаем в обеспечивающей системе, должно быть отнесено к чему-то в целевой системе. И уж как минимум, эти две модели должны следовать общей картине мира -- модель данных этих двух моделей должна быть одна и предусматривать указание этих связей задействования объектов целевой системы в работах объектов обеспечивающей системы.
5. Во всех современных PLM в моделях данных их репозиториев есть как части, отвечающие за описание целевой системы, так и части, отвечающие за описание ролей исполнителей и тех или иных действий в workflow (включая управление процессами/проектами/кейсами/issue).
Тут нужно заметить, что workflow (хоть в варианте его "на лету" составления из обрывков-шаблонов, как в adaptive case management, хоть в варианте предварительно спроектированного целиком, как в BPM и/или проектном управлении) сам по себе является исполнением программы, а его описание -- программой.
Программа -- это двойственный объект. Программа является данными с одной стороны, а с другой стороны, она подразумевает какую-то развертку во времени, набор альтернативных будущих, соответствующих ветвям программы -- программа подразумевает исполнение, реальное выполнение процесса.
Интеграция пассивных описаний целевой системы подразумевает собой только традиционную для PLM интеграцию данных жизненного цикла целевой системы (как пассивной структуры).
Интеграция описаний обеспечивающей системы подразумевает
а) интеграцию данных жизненного цикла целевой системы (иначе у операций "программы создания целевой системы" не будет операндов -- этими операндами являются объекты целевой системы)
б) интеграцию данных описания процесса обеспечивающей системы (traversal workflow -- нужно интегрировать знание о том, как этот workflow проходит по разным PLM).
в) интеграцию собственно процесса выполнения этой программы/процесса обеспечивающей системы.
Грубо говоря, в концепции "единой PLM одной на всех" у нас типичное "программирование-в-малом", а вот в федерации PLM и эко-системе у нас типичное "программирование-в-большом" (когда разные части программы расположены в узлах сети, и выполняются асинхронно). По сути дела, работа над сложными инженерными проектами представляет собой что-то типа массивно-параллельного вычисления, в котором можно забыть об идее собрать в одной PLM всю программу/workflow/tracking этого масштабного "вычисления" (выполнения работ/операций на десятках тысяч компьютеров, в десятках тысяч мозгов, в десятках тысяч программ в случае проектов типа создания самолётов, подводных лодок, атомных электростанций, нефтегазовых месторождений).
6. Увы, при наличии развитых архитектур интеграции данных (взять хотя бы ISO 15926), пригодных для интеграции как данных описания проекта, так и данных описания системы, для интеграции workflow (создания traversal workflow) нет почти никаких заделов:
-- справочные данные для интеграции описаний геометрии изделия, или технологии (P&ID) активно тестируются уже, и есть возможность сообщить из одной PLM о происходящем с целевой системой другому PLM. Но справочных данных для интеграции описания поведения/деятельности обеспечивающей системы пока нет. Хотя у нас есть проект praxos, но требуемой для интеграции данных мощной онтологии деятельности в готовом виде соответствующих ISO 15926 справочных данных пока нет. Это первое, что нужно сделать для обеспечения traversal (проходящий через разные PLM и независимые пока от PLM софтинки) workflow: получить справочные данные для интеграции описаний деятельности. И тогда можно будет сообщить одной PLM о происходящем с обеспечивающей системой в другой PLM. Хинт: нельзя иметь отдельную интеграционную архитектуру для данных по workflow от архитектуры интеграции данных по целевой системе. Ибо элементы workflow работают с элементами целевой системы -- не проинтегрируешь элементы, не на что будет ссылаться. Так что задача интеграции данных PLM просто должна быть расширена с частной задачи интеграции данных продукта включением задачи интеграции данных проекта, включая данные о текущем состоянии дел в "непроектных движках" (т.е. движках процессного управления и трекинга) -- желательно, по одной и той же технологии, и с использованием одних и тех же (нейтральных) справочных данных, чтобы гарантировать целостность и связность результата интеграции.
-- "передача управления" от программы в одном узле в сети в программу на другом узле сети требует особой организации и связано обычно с передачей сообщений. Структура этих сообщений и протоколы передачи требуют особого обсуждения. Обычно это обсуждается в рамках той или иной реализации SOA. То есть для обсуждения интеграции исполнения требуется понимать реализацию SOA в части, позволяющей дистанционно из процессного движка одних программ толкнуть процессный движок находящейся совсем в другом месте другой программы. Понятно, что этих SOA в разных системах может оказаться столько же, сколько разных PLM (у каждой ведь есть любимый SOA-framework, интегрирующий PLM со своими САПР/authoring tools). Тем самым нужно иметь какие-то средства интеграции для выполненных в разных SOA-frameworks вычислений, что (по аналогии) требует разработки онтологии для описания вычислений ровно так же, как онтология деятельности требуется для интеграции данных по workflow.
Увы, в этом всём пока конь не валялся, и никакие общие декларации типа "держите структуры данных отдельно, а выполняющие workflow приложения отдельно" тут принципиально не помогут. Выделение из приложений одного-на-всех корпоративного воркфлоу-движка (BPM engine, или issue tracker или что угодно) не поможет, ибо таких движков оказывается много, по числу корпораций с выбранными для них движками. То есть нужно честно озаботиться workflow traversal через множество процессных движков -- уметь это описывать на нейтральном языке, и далее реализовывать на тех обрывках исполняющей процессы айтишной инфраструктуры, которые удастся найти в подразделении/организации/холдинге/эко-системе.