PDM очень удобно реализуется на базе BPM-системы. В этом случае она гармонично вписывается еще и в PLM.

? GaryaPDM очень удобно реализуется на базе BPM-системы. В этом случае она гармонично вписывается еще и в PLM.Вы сами поняли, что сказали?Я - понял. Если есть вопросы, задавайте.

Предвосхищая вопросы... В BPM, разумеется, одной разрисовкой BP всё не сделаешь. Необходимо сотворить службу в концепции SOA, в БД создать структуру BOM - своими руками. В отличие от стандартных решений, ориентированных на конкретную CAD и CAM, такой подход позволяет организовать двусторонний обмен информацией с другими подразделениями, а не только "от конструкторов". В частности, отдел снабжения может прорабатывать материалы, и материалы будут появляться в перечне CAM и CAD систем. Внесение изменений в конструкторскую и технологическую документацию реализуется легко.

Но это еще не всё... Возникает возможность реализации методов робастного проектирования (один из методов Тагути), FMEA-анализа, увязки управления проектами (на стадии подготовки производства) с процессным управлением (на стадии собственно производства), увязки управления инвестициями и бюджетного управления ABB на базе ABC-анализа (еще на стадии робастного проектирования определяются ключевые показатели для ABB). Гармоническая привязка всего массива информации PDM к процедурам мониторинга технологических процессов и внесение корректировок в конструкцуию и техпроцесс еще на первых фазах производства (когда идет работа над стабилизацией процесса). Далее, управление изменениями КД и ТД на основе RCA (анализа коренных причин), включенного в цикл 8D обработки жалоб клиентов и выявленного потребителем брака - а также управления изменениями процедур робастного проектирования.

При таком подходе PDM рассматривается как маленькая часть PLM, и информация по большей части передается не ИЗ CAD и CAM, а в обратном направлении.

?Задаю: какие свойства BPM позволяют реализовать функционал PDM удобно?
Что Вы вкладываете в понятие "удобно": более удобно, чем что и менее удобно, чем что?Да, пожалуй, имеет смысл уточнить, что я имел в виду под "удобством". Если PDM используется только для мониторинга версий КД и ТД, то перечисленные Вами продукты более удобны. Они позволяют добиться локального оптимума меньшими усилиями. Если PDM рассматривается как маленькая часть масштабной системы процессного управления, то лучше реализовывать PDM в виде WEB-сервиса, являющегося частью общей системы бизнес-процессов. PDM сделать будет сложнее, но в масштабах всего предприятия и всей системы упраления выигрыш окажется существенным.

?Воизбежание недоразумений уточню: я воспринял вопрос как вопрос о Product Data Management. А Вы?Разумеется, то же самое.

?Теперь назовите мне хотя бы одно предприятие, на котором все это сделано именно так.Ford Motor
General Electric
Siemens
Toshiba
ABS Pumps (это уже поменьше и менее известна)
В России сейчас внедряется в ОАО "Ашасвет". Если мне удастся уговорить руководство, будет и у нас.

?Это самое малое, что надо сделать. А еще надо
- создать структуры классификаторов...Да, разумеется. Я уж не стал подробно это всё расписывать...

?- организовать хранение документов (файлов)Они могут храниться непосредственно в БД BPM-системы.

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

?>такой подход позволяет организовать двусторонний обмен информацией с другими подразделениями
Как буд-то просто электронный архив не может сделать обмен двусторонним...Традиционно отдел снабжения получает перечень материала от конструкторов через PDM-систему. Скажете нет? Если конструктору требуется провести предварительную оценку стоимости изделия и материалов, он обычно общается по телефону с отделом снабжения. Да, можно попытаться каким-то иным образом преставить превичные и вторичные источники информации, но в "классическом варианте" мне видеть не приходилось. Кстати, не просвятите, может быть, где-нибудь видели?

?>В частности, отдел снабжения может прорабатывать материалы, и материалы будут появляться в перечне CAM и CAD систем
Не вижу связи с BPM... Класть информацию в общее хранилище - это не BPM.А инициировать проработку отделом снабжения различных вариантов материала - это BPM?

?Хочу сказать ради справедливости, что существует множество интеграционных задач, по выниманию данных из CAD форматов и заковыриванию их обратно, но я не верю, что современные интеграционные сервера дают какие-то преимущества при работе со сложными многофайловыми документами. Покажите мне интеграционные компоненты, одинаково хорошо вынимающие структуру изделия из NX и AIS, а потом еще из Компаса и Adem... А так, чтобы части сборки сразу правильно попадали в нужный раздел спецификации? Только системы, ориентированные на конкретные CAD/CAM сегодня кое как еще работают с родными форматами...XML, XML, XML... Нужно пользоваться теми CAD и CAM системами, которые умеют забирать информацию из XML и которые умеют представлять ее в формате XML. Далее всё дело техники. XSLT-преобразование, построенное в графической среде...

?Все, что написано дальше к PDM прямого отношения не имеет. По сути и определения PDM - это сложный архив документации, сложно перевязанной со структурой изделия и историей его разработки. Именно из за очень сложной перевязки и необходимости тесной интергации это называется PDM, а не архив. Если вы сможете интегрировать ваш BPM с имеющимся PDM, то рулите процессами на здоровье, но валить все в кучу зачем?Именно на этапе разработки, а точнее еще ДО этого этапа (при сборе информации о предпочтениях потребителей и формировании матрицы QFD) должны определяться критичные для процесса разработки характеристики. При выполнении робастного проектирования используются методы теории вероятностей и математической статистики, DFMEA- и PFMEA-анализ. Когда КД и ТД разработана, на ней обязательно помечаются специальными знаками (у Ford Motor это CC и SC - соответственно для критических и для важных характеристик). При запуске первых же операций уже имеется бизнес-процесс, в нем производится мониторинг критических и важных характеристик, производится оценка их стабильности. Если стабильности нет, выявляются особые причины вариаций. Пока процесс не будет стабилизирован, он не считается управляемым и зрелым - на этой фазе производимая продукция расценивается как "опытные партии". После стабилизации процесса он запускается на полную мощность и производится реальная отгрузка реальной продукции реальным потребителям. Если от потребителей поступили жалобы или претензии к качеству, они запускаются в процесс 8D (8 Discipline), который использует совокупность множества инструментов (5W+1H, RCA и т.д. и т.п.) и имеет возможность влиять практически на всё - на технологию производства, на процедуры взаимодействия с поставщиками, на процедуры внесения изменений в КД... Таким образом, подготовка производства оказывается тесно связанной со всеми процессами жизненного цикла продукции. Она интегрирована в них, причем, интегрирована таким образом, что тщательное проектирование с применением методов Тагути позволяет избежать впоследствии огромных потерь от брака и неудовлетворенности клиентов, а также "на ходу" устранять причины проблем, которые могут быть выявлены в дальнейшем.

Кстати, RCA я сначала сам не воспринял всерьез. Пока один раз не проследил за циклом 8D. Производитель пластиковых бутылок получил сообщение от одного из своих клиентов, что внутри некоторых бутылок обнаружены кусочки пластмассы, дребезжащие при транспортировке и попадающие в напитки, разливаемые в пластиковые бутылки. Тут же стартует 8D. Сначала идет RCA (анализ коренных причин). Во-первых, выясняется, что кусочек пластика попадает в бутылки не на одном станке, а на всех, но эпизодически. Во-вторых, выясняется, что попадает он туда незадолго до замены иглы, с помощью которой протыкают пластиковую заготовку и надувают ее сжатым воздухом. В-третьих, выясняют, что кусочек пластика образуется из-за затупления иглы - она не до конца протыкает заготовку, и на кончике иглы образуется наплыв, который после остывания пластмассы от тряски при транспортировке может отвалиться от дна бутылки. В-четвертых, выясняют, что наплыв возникает от преждевременного износа иглы. В-пятых, организуют срочные временные меры для предотвращения образования наплывов в последующих партиях - начинают чаще производить замену игл и регулярно мониторить заточку иглы. В-шестых, выясняют, когда появилась проблема. В-седьмых, выясняют, почему появилась проблема - произошла смена поставщика игл. В-восьмых, выясняют, почему произошла смена поставщика игл - у нового поставщика иглы дешевле. В-девятых, запускается алгоритм разрешения данной проблемы. И вот тут-то происходит самое интересное. В результате анализа нескольких вариантов выбирается самый оптимальный, и далеко не самый очевидный. Я-то полагал, что нужно просто вернуться к закупкам у прежнего поставщика. Оказывается, наиболее экономически выгодный - оставить нового поставщика, но изменить схему работы с ним и внести изменения в техпроцесс. Вот такая петрушка...

?BPM - это средство поддержки исполнения регламента, оно само ничего из того, что Вы перечисляете не делает.Делает, хотя и не само. Нужно в нем настроить все так, чтобы делалось именно то, что нужно. Дело в том, что BPM это не просто DocFlow, в отличие от DocFlow оно обязано иметь средства мониторинга. В перечень параметров, подверженных мониторингу, обязательно включается ВРЕМЯ - это основная идея Lean Manufacturing. Сводятся к минимуму вариации времени выполнения каждой операции. В итоге для кажого материала, ДСЕ и готовой продукции соотношение времени, которое они находятся в процесс добавления потребительской стоимости (станочной обработки, транспортировки, покраски, упаковки и т.д.) и "просто пролеживания" (на складе, возле станков и т.д.) изменяется от 1%/99% к, например, 80%/20%. Всего лишь за счет уменьшения вариаций. При этом производственный цикл сокращается в 4 раза, а уровень запасов может тоже упасть до нескольких раз. Выручка возрастает потому что клиентам интереснее работать с поставщиком, способным быстрее реагировать. Качество вырастает тоже. Непроизводительные потери уменьшаются. Какое это отношение всё это имеет к PDM? Такое, что так называемые "технологические задержки" между технологическими операциями на самом деле определяются ни чем иным, как степенью стабильности процесса и размахом вариаций. Если вариации взяты под контроль, если всё это хозяйство мониторится, управляемость процессом возрастает, автоматически уменьшаются "технологические задержки" между операциями - и это автоматически должно находить отражение в ТД. Аналогичным образом, если происходит оптимизация цепочки поставок, может резко сократиться задержка в поставке материала от поставщика, могут быть радикально уменьшены партии. Если поставщик продвинутый, то с ним можно наладить так называемую "цифровую" цепочку поставок.
Если выявлены особые причины вариаций в техпроцессе или брак, обнаруженный потребителем, запускается специальная процедура. Которая в конечном итоге может привести к изменению как ТД, так и КД. Согласование перечня материалов с отделом снабжения - это не такая простая процедура как "созвонились по телефону"). Она итерационная, в нее могут быть вовлечены не только собственные снабженцы, но и одновременно несколько предприятий, расположенных раньше по цепочке поставок (если только предприятие намерено управлять цепочками поставок). Она может требовать существенных усилий. Усилия должны быть экономически оправданы. В силу наличия функциональных барьеров в иерархической структуре и локальных интересов подразделений по телефону вы можете получить тривиальный отлуп "отстань, я тебе уже проработал материалы - ими и пользуйся". В особенности, если это инновационная разработка требует новых материалов, ранее не применявшихся.
Методология робастного проектирования требует проверки гипотез, которые производятся на стадии "устаканивания" производственного процесса. BPM-система, с помощью которой производится мониторинг критических и важных характеристик (и в первую очередь - времени выполнения операций!), может предоставить информацию, на основе которой производится изменение конструкции изделия и изменение технологии. Всё взаимно увязано в большом количестве вложенных друг в друга циклов и процессов.

?Интеграция, предоставляемая BPM полезна, но не является незаменимой.Интеграция - это только одна грань, и не самая важная. Самая важная грань - это реализация принципов процессного управления. Да, конечно, их можно реализовать и без BPM-системы (и до недавнего времени многие компании реализовывали "на коленке", при этом получали огромные выигрыши). Но все-таки с BPM-системой реализовать всё это гораздо проще. Примерно настолько же проще, насколько оттащить большую кучу земли бульдозером на расстояние 100м, нежели перетаскивать ее с помощью ведер и лопаты.

Проблемы групповых спецификаций, перекрестных ссылок и т.д. и т.п. мне известны. Никто не утверждает, что они решаются легко именно с помощью BPM-системы. Однако, эти проблемы не должны быть главными. В конце концов собственно разработка может быть представлена как бизнес-процесс, который может пройти оптимизацию методами "шести сигм" (например). И те проблемы, которые прежде казались огромными и неразрешимыми, вдруг станут мелкими и малосущественными. В конце концов, подчинять всё и вся решению только этих проблем - это не рационально. Хотя, никто и не предлагает эти проблемы игнорировать. Я не могу озвучить универсальный рецепт - нужно смотреть по месту. Но одну идейку могу и подкинуть... Зачем, собственно, создается групповая спецификация? Для того, чтобы облегчить жизнь конструктору (никто и не спорит). Однако, если это облегчение жизни конструктору приводит к усложнению жизни всего остального предприятия, то, может быть, проще усложнить жизнь конструктору? :) Только, ради бога, не воспринимайте это как универсальный рецепт - еще раз повторяю, нужно смотреть по месту.

?Еще раз говорю: PDM - это АРХИВ. ПРОЦЕСС - это не PDM. Вы можете поддерживать прроцесс с BPM, а можете работать по бумажным регламентам - это ничего не изменит в структуре архива.Еще раз говорю:... :)
вся информация, с которой имеет дело BPM-система, все результаты мониторинга (в том числе), все рабочие материалы, с которыми она имеет дело, в структурированном виде сохраняются в БД BPM-системы. Кроме своей собственной БД она может соединяться с любыми сторонними БД и/или приложениями и сохраняь информацию там, в том числе параллельно с собственной БД. Это и есть АРХИВ. И не обязательно один, их может быть много.

?И замечание про иглы и бутылки: если бы вы попытались проследить процесс решения проблемы при изготовлении машиностроительного изделия, и рассказали - это бы меня впечатлило. Производство бутылки несравнимо с производством изделия, содержащего десятки тысяч компонентов от сотен поставщиков. Не то, чтобы я не верил прогрессивным методам управления, но в реальных машиностоительных объемах любой метод превращается в шаманские танцы с бубном.В нашем холдинге 5 (пять) машиностроительных производственных предприятий. Некоторые из них производят относительно простые, а некоторые очень сложые изделия. В том числе такие, требования к надежности и качеству которых зашкаливают за все мыслимые границы, потому что поставляются для атомной промышленности. Пример с бутылками мною вычитан в журнале "Стандарты и качество".
И встречный вопрос к Вам. На Вашем производстве некий рабочий нажал не ту кнопку на станке - в результате произошла поломка как самого станка, так и порча дорогостоящей заготовки, которую он обрабатывал. Кто/что виновато, для кого/чего каковы последствия этого события? Лишите ли вы премии рабочего?

Сахават Юсифов Garya
....
Куда Вас несет? :(В процессное управление... :)
Ладно, буду молчать... В принципе, я заранее ожидал "насупленную реакцию". :)

Всё остальное оставлю без комментариев... Отвечу только вот на это:
BoatmanУ меня нет собственного производства. Но если бы было, то пистон получили бы те, кто заказал оборудование без защиты от дурака и те, кто обучал и допускал рабочего к работе, если он зашел на чужое рабочее место, то те, кто отвечает за разграничение доступа. И так далее в том же духе для того, чтобы смотреть в корень проблемы не обязательно приводиьть по дватцать аббревиатур на трир предложения. А вообще сказал бы спасибо, что никому не оторвало руку или голову...RCA изначально исходит из того, что пистон не должен получать НИКТО . По утверждению Деминга 98% проблем возникают по вине системы , а не сотрудников. RCA находит коренные причины в самой системе, а не занимается поиском "стрелочников".

Ну всё, пойду покурю... В смысле, поучусь курить (потому как некурящий)... :)