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

[Горбушин Даниил 0]

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

Процесс проектирования можно поделить на стадии:

1. Определение технических требований и разработка технического задания

2. Эскизное проектирование

3. Согласование требований заказчика

4. Опытно-конструкторские работы

5. Испытания

4. Доводка серийного образца

Стадии могут оличаться...

Далее при выпуске серийной продукции возможны модернизации/модификации.

Также фирма изготовитель проводит гарантийное и сервисное обслуживание.

Теперь сама тема для обсуждения...

Непосредственно каждый из этапов жизненного цикла - проект. По проекту нужно планировать и учитывать время выполнения этапов, планировать бюджет проекта, сроки и т.д. Это особенно важно если предприятие работает по принципу "Проектирование на заказ", т.е. проектирование + производство.

Из выше сказанного совершенно очевидно, что существует потребность в связке PDM + Project Management. т.е. управление данными + управление проектом. И это только если охватывать стадию проектирования...

Что есть в современных PLM-системах закрывающие данные задачи?

[Max KZK 2]

В Smarteam есть модуль Program Management, для управления портфелями проектов.

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

Менеджер проекта периодически проводит синхронизацию данных с Project.

Есть возможность создавать шаблоны проектов с ресурсами, WBS и документами, а также использовать существующие проекты как шаблоны.

Единственный недостаток этого модуля - работа только через Web интерфейс, который в СТ дюже корявый. Хотя, в 17 релизе налицо серьезный прогресс в этом.

В России этот функционал внедряет у себя Питерский "Арсенал". На Украине планирует внедрять наша контора.

[nester 0]

У нас решение конечно не такое глобальное, по сравнению с вышесказанным - просто колхоз, однако

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

Руководитель высшего звена ответственный за разработку и сроки с помощью простых отчетов (самописных на базе crystal report) может увидеть загрузку исполнителей, контроль сроков исполнения и т.д. в различныхъ разрезах (на самом деле "полет для фантазии" просто безграничный).

Когда мы заваривали свою кашу еще небыло такой интеграции с проджектом, да и сейчас на web решении я еще бы десять раз подумал делать или не делать (в свое время 13 релиз, клиент работал из рук вон плохо, хотя сейчас все могли поправить)

[Горбушин Даниил 0]

Управления проектированием меня интересует как учет и планирование затрат, а также загрузки сотрудников занимающихся проектированием...

Если производством можно управлять и планировать по MRPII, то процесс проектирования остается закрытым для получения актуальной информации о сроках и затратах.

Может кто возразит, но PLM давно уже не равно (PDM + линейка CAD/CAM систем), для меня это уже нечто большее...

С моей точки зрения PLM - это концепция, с точки зрения функциональности, включающая в себя:

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

2. Управление производством

3. Управление сервисным обслуживанием и ремонтами

... и т.д.

[Max KZK 2]

Что-то вопросы у вас уж очень абстрактные. Такое впечатление, что вас буквы интересуют, а не конкретные вопросы.

Что касается PLM, то на одной из презантаций того же "Арсанала" я видел такое, ИМХО очень точное, определение:

На вопросы "Что", "Из чего", "Как" и "Где" отвечает PLM.

На вопросы "Сколько" и "Когда" отвечает ERP.

Так что, управление производством - это не совсем PLM.

[Горбушин Даниил 0]

Скажите мне отгда откуда вы узнаете из чего былы изготовлена ваша продукция для последующего его сервисного обслуживания или ремонта?

Как потом заказывать запасные части если конструкторский состав изделия в производстве стал отличаться на 30%, а то и более?

Как вы будете организовывать работу КБ, которое кроме разработки новых видов продукции занимается сопровождением уже выпускаемых (проведение изменений) и ремонтными заказами?

Так что производство здесь очень тесно вплетается в концепцию PLM.

[Che 0]

Даниил!

Я вплотную работаю над внедрениями как раз в таких областях. MRPII тут не просто вплетается, некоторые ее части живут в PLM, но MRPII практически не решает задачи PLM. Причем эти залачи не решает практически ни одна из существующих на рынке PDM/PLM ситсем. Многие к ним приближаются, особенно после внедрения и сооружения кучи дополнительных механизмов.

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

Но как доходит до экземплярных характеристик тут вся концепция классической PDM/PLM рушится.

Например вы изготавливаете свои изделия, осуществляете гарантийный и постгарантийный ремонт, вплоть до утилизации. В общем живете со своим изделиями.

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

Храним информацию по каждой детали выпущенной на преприятии с конкретным серийным/индивидуальным номером.

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

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

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

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

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

Добавлено позже

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

[nester 0]

Да можно делать некие "снимки" состава изделия перед началом выпуска очередного изделия (или при серийном производстве после каждого изменения) и кажется вопрос закрывается, прицепляй к системе тех обслуживания и ремонта соотвествующий состав, но вступают такие понятия, как например переменные данные или/и взаимозаменяемость и в условиях "нашего" производства это становиться практически непреодолимой задачей, т.к. практически все поставки идут "с колес" и достаточно сложно отследить, какой же в итоге "шуруп" вкрутили в панель тот или этот, мало того, что конструктор позволяет делать взаимозаменяемость, так существует еще куча нормативных документов разного уровня и масштаба (ГОСТ, каталог фирты производителя, стандарт завода изготовителя) и настроить систему на учет ВСЕГО этого становиться нетривиальной задачей, это еще усугубляется тем что заказчикам либо не надо, либо они не знают о том, что существует возможность организации электронных каталогов и систем тех обслуживания и ремонта), можно при вложении определенных технологий снять эту проблему, но владельцы заводов не хотят этого делать, потому что никто этого не требует и не несет никакой практической пользы ПОТОМУЧТО НИКОМУ ЭТО НЕ НАДО. И поверьте как только заказчики потребуют все начнут шевелиться (мой пример).

[Che 0]

но владельцы заводов не хотят этого делать, потому что никто этого не требует и не несет никакой практической пользы ПОТОМУЧТО НИКОМУ ЭТО НЕ НАДО.

В общем-то в последнее время стало надо, причем даже не из-за тербований заказчика, а чтобы было потом кому претензии выставлять за некачественные материалы и т.п.

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

достаточно сложно отследить, какой же в итоге "шуруп" вкрутили в панель тот или этот, мало того, что конструктор позволяет делать взаимозаменяемость

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

Ну а на счет того кому чего закомплектовали - это строго, потому как когда в ремонт изделия приходят нужно четко сомтреть а не поменяли ли там чего-нибудь? Если да, то на наши ли детали, которые им туда отгружали? А если на контрафактные детали поменяли (которые непонятно кто сделал, да и делать их он не имеет право) то люлей заказчику!!!

[Горбушин Даниил 0]

Для Che...

Я на прошлом месте работы занимался PDM/PLM-системами, сейчас занимаюсь ERP...

Опыта общения с предприятими было достаточно и все проблемы мне очень хорошо знакомы.

Если говорить о PDM, MRPII, CMMS, то очевидно что для поддержки жизненого цикла все эти системы нужны и работа их должна быть тесно связана.

PLM - в моем понимание концепция, а не система как сейчас предлагают на рынке.

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

Насчет изменений - согласен более чем на 100%. Что приходит из PDM очень сильно разниться с тем как реально изготавливают изделия. А когда доходит до проведения изменений, то тут начинаются проблемы из-за неактуальности данных. А что говорить о ремонтах. когда призодит заказ от клиента на ЗИП и конструкторский состав поставляемых в комплекте изделий в корне отличается от того как изготовили.

Если уж говорить о PDM, то в каждой MRPII системе есть встроеный PDM, т.к. без НСИ работать ничего не будет...

Предлагаю пересмотреть концепцию PLM, начав понимать как комплекс систем (PDM+Project Management)+MRPII+CMMS+...

Начать осуждение предлагаю с управлением проектированием.

Насколько PDM, WorkFlow, Project Management необходимы для управлением проектироваем?

[Che 0]

Насколько PDM, WorkFlow, Project Management необходимы для управлением проектироваем?

В теории и с точки зреня здравого смысла нужно все. Но на практике и из опыта, оказывается что электронное согласование - полная утопия, оно вообще для согласования чертежей не нужно, по крайней мере пока. В общем Workflow нужен только, чтобы разослать на основании данных из PM кому чего и когда делать (а это можно сделать и простым exchange'м). PDM необходим, чтобы видеть текущую ситуацию, сколько на сегодня сделано, сколько еще осталось... Ну а без PM управлять проектом нельзя совсем.

PLM - в моем понимание концепция, а не система как сейчас предлагают на рынке.

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

Как ни странно но такие системы есть, хотя в их названиях аббривеатур PLM нет точно. Именно такие системы становятся стержнем-центром ИТ-инфраструктуры предприятия а не ERP/MRPII.

Именно они являются главным местом создания, хранилищем и поставщиком исходных данных для всех остальных систем - MRP, SCM, CRM ...

[Горбушин Даниил 0]

Не работает на форуме цитирование...

Уважаемый Che!

"Как ни странно но такие системы есть, хотя в их названиях аббривеатур PLM нет точно. Именно такие системы становятся стержнем-центром ИТ-инфраструктуры предприятия а не ERP/MRPII.

Именно они являются главным местом создания, хранилищем и поставщиком исходных данных для всех остальных систем - MRP, SCM, CRM ..."

Это какие это системы, если не секрет??? Что-то вы загадками говорите...

MRPII - это стандарт! SCM - Supply Chain Management (Управление цепочками поставок). СRM - вообще управление взаимоотношениями с клиентами...

Никто не говорит, что ERP - ядро комплекса систем для управления жизненным циклом продукта на предприятии. Задачи решаемые ERP совершенно иные чем вы понимаете... Посмотрите на схему, может вы перестанете заблуждаться...

http://forum.ascon.ru/index.php?action=dlattach;topic=6362.0;id=1128

Что вы подрузамеваете под ядром, объясните???

[Che 0]

Данила! ПОстараюсь в трех словах объяснить :).

Существуют системы в которых - в рамках одной системы, естественно в рамках одной БД вы можете:

1. Вести конструкторский состав изделий со всеми историями

2. Хранить и разрабатывать ТП на изготовление деталей и изделий и т.п. + хранить все нормы (материальные и трудовые)

3. Вести список заказов, контрагентов и т.п.

4. На основе данных указанных в заказах и данных из п.1,2,3 создавать производственные планы (ессно нужно вести справочники цехов, субодрядчиков, оборудования и т.п.).

5. Вести складское хозяйство, особенно межцеховые ПРОСКи, поступающий материал, параметры экземпляров/партий материала и серийные номера заготовок и деталей, также учитывать из какого конкретно материала (вплоть до номера плавки) изготовлен тот или иной экземпляр заготовки.

6. Фиксировать сдачу работ (пооперационно) вплоть до данных об исполнителе, нормоконтролере, контролируемых и других параметров на каждый конкретный экземпляр детали, есстественно отслеживать и хранить ТП по которому деталь была изготовлена реально.

7. Контролировать непосредственную сборку узлов изделия (какой экзмепляр детали в какой экземпляр узла ушел) и комплектацию кокретного изделия (поэкземплярно) + параметры собранных узлов, конструктивные пары и т.п.

8. Фиксировть отгрузку изделий потребителям.

9. Фиксировать наработку изделий.

10. Фиксировать получение изделий от потребителей в ремонт.

11. Фиксировать результаты ремонтных работ (планировать эти работы с учетом существующих ресурсов, если есть соответсвующие регламенты и техпроцессы)

12. Фиксировать экземплярные характеристики в замененных/отремонтированных деталях и вести подетальную/поузловую наработку каждого экземпляря деталей/узлов.

13. После ремонта отдаем изделие обратно потребителю см. п.8. и так до бесконечности, пока изделие не умрет.

Система вертит всеми основными данными - это костяк кмоплекса котором есть вся необходимая информация.

Ессно, что можно ее получать в любых видах и на пример на п. 4 оценить дефицит необходимых материалов/инструментов и т.п. и сделать соответсвующие заказы-распоряжения в службы снабжения и т.п.

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

[Горбушин Даниил 0]

Это вы функционал TecnologiCS описали как понимаю...

Все чо описано - можно поделить на 3 класса систем

1. PDM+САПР ТП

2. MES

3. CMMS

И чем вы хотели меня удивить?

[Che 0]

А почему сразу же TechnologiCS?

Существует несколько таких систем и самое интересное что называть системы подобного класса - PDM+САПР ТП + MES + CMMS как-то язык нее поворачивается (особенно учитывая то, что разарбатывать ТП там не очень-то и удобно). Это именно PLM системы. Это на мой взгляд и есть класс такого рода систем.

А концепция про которую вы говорите - называется CALS, а под PLM понимается именно класс подобных систем.

[Горбушин Даниил 0]

PLM - Product LifeCycle Management (Управление жизненным циклом продукта). Что есть жизненный цикл?

1. Зародилась идея или появилась потребность в каком-то продукте - написали ТЗ.

2. Спроектировали.

3. Испытали, довели до серии.

4. Запустили в серию - производим.

5. Надо модифицировать либо нашлись проблемы, которые не были выявлены при испытаниях - управляем изменениями.

6. Продали клиенту - осещесвляем сервисное обслуживание и ремонты.

7. Возможно что-то надо мождернизировать...

8. Окончание срока эксплуатации - утилизация или переделали в другой вид продукции.

Исходя из этого можно выделить основные этапы:

1. КТПП.

2. Производство.

3. Обслуживание и ремонты (CMMS).

4. Утилизация.

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

Понятно, что экземпляры должны рождаться в PDM. Но это только как спроектировали...

Как изготовили, а именно из чего, важно знать чобы потом правильно ремонтировать и опредеилять графики и сроки обслуживания.

Кстати, чо-то я совсем ничего не видел в CALS о производсве и ремонтах...

[Che 0]

Кстати, чо-то я совсем ничего не видел в CALS о производсве и ремонтах...

Странно в тех документах которые видел я описано все, вплоть до логистической поддержки. А то что пишут на сайте <noindex>www.cals.ru</noindex> дык это лишь малая доля того что есть в мире и не стоит заморачиваться только на том что описано там.

Как расшифровывается CALS я думаю говорить не надо, там черным по белому написано - Lifecycle Support и все стандарты CALS описывают именно идеологию а вести ее ты можешь хоть на бумаге, хоть в какой-нидь системе/ах. А PLM - на мой взгляд - класс систем а не идеология.

Хотя даже у них на сайте написано

CALS (Continuous Acqusition and Life cycle Support) — это концепция, объединяющая принципы и технологии информационной поддержки жизненного цикла продукции на всех его стадиях , основанная на использовании интегрированной информационной среды (единого информационного пространства), обеспечивающая единообразные способы управления процессами и взаимодействия всех участников этого цикла: заказчиков продукции (включая государственные учреждения и ведомства), поставщиков (производителей) продукции, эксплуатационного и ремонтного персонала, реализованная в соответствии с требованиями системы международных стандартов, регламентирующих правила указанного взаимодействия преимущественно посредством электронного обмена данными.

[Горбушин Даниил 0]

Уважемый Che!

Расскройтесь...

Какие системы внедряете?

Есть ли успешные проекты?

З.Ы.: Страна должна знать своих героев! ;-)

[slaz 0]

Давайте вернемся к тому с чего начинали - PDM+PM.

Затронем пока только управление разработкой.

Если разделить сферы компетенции то PM - это управление ресурсами, сроками, бюджетом.

PDM - управление данными, по большому счету - результатами работ проекта.

Так нужна нам интеграция PDM и Project Management?

Если нужна то какова должна быть схема потоков данных между этими системами?

[Marian 0]

На сайте PMsoft пару лет назад попадался мне такой документик Концепция интеграции PDM и системы управления проектом. может и сейчас там лежит. Разрабатывалалсь вроде для MS Project и Party.

А суть информационных потоков: в СУП формируется перечень задач, назначаются плановые сроки и исполнители.Далее это спускается в ПДМ собственно для сбора фактических данных о исполнителях и сроках.

в ПДМ каждой задаче поставлено в соответствие объект "задание" (разработать КД на узел ХХХ), связанное с предметом работ "КД". в ПДМ состав узла детализируется обрастает КД, исполнители, сдавая ее в архив, атоматически закрывают задания ит.п.

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

В СУП планирование и контроль результатов производится примерно на уровне отделов (разделов проекта/или подсистем изделия), а в ПДМ - до уровня исполнителя/ документа.