Форум Сообщества Аналитиков
Общий раздел => Методологии => Тема начата: p_safin от 15 Декабря 2011, 12:28:12
-
Коллеги, обращаюсь к вам с советом. Ваше мнение и советы будут очень важны и ценны для меня.
Как известно, во многих программных средствах изначально заложены какие-то принципы, правила, методологии, стандарты. Например, как известно, стандарт UML используется (в той или иной мере) для всех программных средств UML-моделирования, причём, при изменении версии стандарта происходит обновление программного обеспечения таким образом, чтобы оно удовлетворяло стандарту. Но это что касается разработки ПО.
Мне же будут интересны следующие моменты:
1. Какие методологии и стандарты заложены в промышленные программные средства (PDM, CAD, CAE, CAM)? Больше всего, наверное, будут интересны методологии, по которым "построены" и организованы PDM-системы.
2. Реально ли использовать IT-шные принципы и методологии управления проектами в промышленности (например, для организации работы какого-либо проектного бюро по разработке какого-либо агрегата)?
Прошу поделиться опытом и своими мыслями.
Спасибо за внимание.
-
Павел,
ИМХО тут тебе мало помогут участники форума, если они не сталкивались с внедрением таких систем.
Это лучше спрашивать на спец форумах по таким направлениям, причем нужно немного переформулировать вопрос №2: какие принципы и методологии управления проектами используются в промышленности, а уже на основе этого ответа и знания ИТ методологий делать вывод.
-
Я работал с одной из PLM систем, в связке с САПР, срозу оговорюсь что это было на очень масштабном предприятии, поэтому не знаю, насколько информация об этой системе может пригодиться.
1. Касательно PDM системы - она была организована целиком по принципу ООП. Все, начиная от деталей, кончая связями, между ними являются отдельными объектами в системе. Теоретически подобная организация позволяет работать со сборками и объектами неограниченых размеров и сложности, практически предел для сборки - 100 000 деталей...
2. Да, реально, некоторые методологии даже очень близки к тем, что рекомендованы производителем системы. PDM система, в которой я работал поддерживала все стадии, от формирования требований, до сопровождения и послепродажного обслуживания. Также в самой системе были средства для организации работ по проектам - диаграммы ганта, назначение ресурсов и т.п.
-
Поддержу Tinner, косвенно это подтверждает и недавнее слияние PTC и MKS Integrity, первый - предлагает PLM-решения, второй - ALM (ну скорее SDLC).
http://www.engineering-matters.com/2011/07/ptc-mks/
Вообще, рекомендую полистать этот блог, похоже автор в Вашей теме.
-
PDM система, в которой я работал, поддерживала все стадии, от формирования требований, до сопровождения и послепродажного обслуживания. Также в самой системе были средства для организации работ по проектам - диаграммы ганта, назначение ресурсов и т.п.
Не Windchill + Pro/E случаем?
2. Да, реально, некоторые методологии даже очень близки к тем, что рекомендованы производителем системы.
А какие, например, методологии управления проектами предлагают производители систем? Как извлечь эту информацию из системы, ведь, по сути, эта информация заложена глубоко в ней, а пользователям доступны только инструкции в виде алгоритма. При этом вся суть остается не ясной.
Кстати, это на самом деле довольно большая и современная проблема. В университетах учат тыкать мышкой, выполняя какой-либо сценарий, хотя суть решаемых системой задач остается непонятной.
Коллеги, спасибо за ответы.
-
Не Windchill + Pro/E случаем?
Я занимался внедрением и доработкой Teamcenter в связке с NX.
А какие, например, методологии управления проектами предлагают производители систем?
Имелось в виде не управление проектами а сам процесс проектирования деталей/сборок. Процесс рекомендовался итерационный, с параллельной работой проектировщика (CAD), расчетчика (CAE), и расчетчика (CAM), для сокращения цикла производства, ну и т.д.
Как извлечь эту информацию из системы, ведь, по сути, эта информация заложена глубоко в ней, а пользователям доступны только инструкции в виде алгоритма. При этом вся суть остается не ясной.
Эта информация не заложена в систему. В том то и дело, что хорошие PLM системы целиком настраивается под производственную систему Компании, и под ее бизнес-процессы.
Многие вендоры предлагают готовые типовые решения на платформе этих систем, но все дело в том, что сама PLM система - лишь платформа. Для предоставления решения, нужно продумать модель данных, проанализировать процессы в Компании и т.д. Объем работ достаточно большой, и это не считая программных доработок...
Кстати, это на самом деле довольно большая и современная проблема. В университетах учат тыкать мышкой, выполняя какой-либо сценарий, хотя суть решаемых системой задач остается непонятной.
В университете сложно эту тему раскрывать... У нас сотрудники преподавали в университете целиком на опыте нашего предприятия. Опять же, суть решаемых задач целиком зависит от конкретного проекта внедрения. Если интересно - могу перечислить, какие задачи решались у нас.
-
Имелось в виде не управление проектами а сам процесс проектирования деталей/сборок. Процесс рекомендовался итерационный, с параллельной работой проектировщика (CAD), расчетчика (CAE), и расчетчика (CAM), для сокращения цикла производства, ну и т.д.
Как я считаю, всё-таки проектирование какой-то детали и можно отнести с отдельному проекту (подпроекту в рамках более крупного проекта).
А в чем заключалась итерационность процесса: сначала создавалась первоначальная CAD-модель, потом она следовала на расчёты CAE-специалисту, а потом создавался техпроцесс в CAM-системе, затем модель дорабатывалась после прохождения этих стадий и снова проходила расчёты и доработку техпроцесса? Или как-то по-другому?
Эта информация не заложена в систему. В том то и дело, что хорошие PLM системы целиком настраивается под производственную систему Компании, и под ее бизнес-процессы.
Многие вендоры предлагают готовые типовые решения на платформе этих систем, но все дело в том, что сама PLM система - лишь платформа. Для предоставления решения, нужно продумать модель данных, проанализировать процессы в Компании и т.д. Объем работ достаточно большой, и это не считая программных доработок...
Собственно, вы дали ответ на мой 1-й вопрос в инициирующем сообщении этой темы. Из него можно сделать вывод, что какой-то конкретной методологии изначально в PLM/PDM-систему не заложено. Я с вами соглашусь.
То есть, первоначально можно разделить работы по проектам внедрения PLM-системы в следующем виде (глобально):
1. Аналитика процессов компании.
2. Настройка и оптимизация бизнес-процессов с помощью PLM-системы. Выяснение перечня необходимых доработок.
3. Доработка дополнительных модулей и интеграция с существующими системами (с существующим ПО). Вот здесь и можно применять методологии и средства разработки уже ПО.
В университете сложно эту тему раскрывать... У нас сотрудники преподавали в университете целиком на опыте нашего предприятия. Опять же, суть решаемых задач целиком зависит от конкретного проекта внедрения. Если интересно - могу перечислить, какие задачи решались у нас.
Но, согласитесь, опыт практиков не всегда бывает удачным. Иногда изобретают велосипед, как говорится. На некоторых предприятиях принцип нисходящего проектирования считают ноу-хау и по сей день, и не важно, что продвинутые страны этого принципа придерживаются уже лет как 15-20.
Уважаемый Tinner, спасибо за информацию. Мне интересно увидеть перечень задач, которые вы решали.
-
Начну с конца...
Но, согласитесь, опыт практиков не всегда бывает удачным.
Как я уже говорил, в целом, PLM система лишь платформа, и если изучать ее в отрыве от конкретных примеров - остается лишь "тыкать мышкой". Примерно то же самое, что изучать системный анализ без примеров... К тому же подобное обучение проводят сразу с ориентацией на конкретного работодателя, в моем случае это было на факультете летательных аппаратов.
То есть, первоначально можно разделить работы по проектам внедрения PLM-системы в следующем виде (глобально):
1. Аналитика процессов компании.
2. Настройка и оптимизация бизнес-процессов с помощью PLM-системы. Выяснение перечня необходимых доработок.
3. Доработка дополнительных модулей и интеграция с существующими системами (с существующим ПО). Вот здесь и можно применять методологии и средства разработки уже ПО.
В целом все так, когда уже есть некоторое решение.
Единственное в пункте 2 идет оптимизация бизнес-процессов в Компании, потом уже их реализация в PLM системе.
Если готового решения нет, то добавится еще пункт между 1 и 2 - разработка модели данных системы. Считаю это очень важным пунктом, поскольку опираясь на полученную иерархию классов хранимых объектов можно будет заниматься оптимизацией бизнес-процессов, и дальнейшую доработку и системы укладывать в полученную архитектуру.
И небольшая ремарка по 3-му пункту: Функционал хорошей PLM системы покрывает 95% потребностей почти любого предприятия. Доработки в основном касаются экранных форм, упрощения работы в системы, консолидация полученной архитектуры модели данных в самостоятельный модуль. И остается формирование отчетности. Поскольку ГОСТЫ на спецификацию, извещения об изменении и т.п. являются лишь рекомендованными - может возникнуть необходимость разрабатывать их под каждого заказчика.
А в чем заключалась итерационность процесса: сначала создавалась первоначальная CAD-модель, потом она следовала на расчёты CAE-специалисту, а потом создавался техпроцесс в CAM-системе, затем модель дорабатывалась после прохождения этих стадий и снова проходила расчёты и доработку техпроцесса? Или как-то по-другому?
Можно и так. Но в оригинале было - на каждой итерации увеличивается детализация проработки, ведь изначальное представления о прочностных характеристиках можно получить имея деталь в самом базовом виде, соответственно меньше будет тратиться времени на изменение детали, исходя из результатов анализа. Аналогично и с разработкой техпроцесса - представление о технологичности проектируемой детали можно получить на ранних стадиях ее разработки.
Как я считаю, всё-таки проектирование какой-то детали и можно отнести с отдельному проекту (подпроекту в рамках более крупного проекта).
Тут я не соглашусь. Требования, как правило предъявляются к готовому узлу, а не к отдельным деталям, и если на проектирование детали не требуется 60+ часов, выделять ее в отдельный проект нет особого смысла... Ну и еще имеет значение возможность декомпозиция проектируемой сборки на агрегаты и узлы..
По решаемым задачам - отвечу чуть позже..
-
К тому же подобное обучение проводят сразу с ориентацией на конкретного работодателя, в моем случае это было на факультете летательных аппаратов.
Собственно, так оно и есть на том же факультете самарского СГАУ.
Если готового решения нет, то добавится еще пункт между 1 и 2 - разработка модели данных системы. Считаю это очень важным пунктом, поскольку опираясь на полученную иерархию классов хранимых объектов можно будет заниматься оптимизацией бизнес-процессов, и дальнейшую доработку и системы укладывать в полученную архитектуру.
Здесь, как я понимаю, уже необходимо привлекать программистов и системных архитекторов.
Функционал хорошей PLM системы покрывает 95% потребностей почти любого предприятия.
А вот это для меня действительно открытие...
Тут я не соглашусь. Требования, как правило предъявляются к готовому узлу, а не к отдельным деталям, и если на проектирование детали не требуется 60+ часов, выделять ее в отдельный проект нет особого смысла... Ну и еще имеет значение возможность декомпозиция проектируемой сборки на агрегаты и узлы..
Да, с этим согласен. Проект - это нечто цельное. Про декомпозицию: она, действительно, необходима в любой работе.
А как управлять тогда таким проектом и зависит ли выбранный процесс управления от типа проекта?
-
Здесь, как я понимаю, уже необходимо привлекать программистов и системных архитекторов.
Скорей здесь нужно определить границы автоматизации, если это делается для внешнего проекта.
Для заказчика, который согласен провести реинженеринг бизнес-процессов - построить модель откуда какая информация берется, как взаимодействуют объекты друг с другом, и исходя из этого оптимизировать сами процессы. Для этого достаточно будет понимания базовых принципов ООП, и это может сделать и аналитик, но тут нужно смотреть на масштаб проекта по внедрению.
Если заказчик не хочет идти на изменения в регрламентах своей работы - будет уже посложней...
Еще раз скажу, что я основываюсь на своем опыте работы, у меня перед глазами был пример замечательной модели данных, поставляемой на несколько предприятий в россии, и для партнеров за границу, и пример нашей собственной модели данных, с которой мы намучались, и в итоге отказались от нее. Потому я и определил ей такое важное место...
-
Итак задачи, которые решала PLM система у нас (что сразу вспомнилось, уже не работаю там...):
1 Базовые задачи
1.1 Хранение всех данных об изделии в одном месте, с организацией удобного и быстрого доступа к ним и разграничение прав доступа. Цель - сокращение затрат времени на поиск связанно й информации, обеспечение актуальности информации по всему предприятию и отсутствие дублирования хранимой информации, обеспечение доступности информации только тем лицам, которым она нужна.
1.2 Хранение НСИ в отдельной базе. Цель - обеспечить актуальность справочной информации по предприятию (станки, инструменты, и т.п.) и по всему холдингу (стандартные изделия, материалы и т.п.).
1.3 Хранение двухуровневой версионности файлов, с указанием статусов версий. Цель - обеспечить хранение информации по всему жизненному циклу изделия в соответствии с конструкторской документацией. Первый уровень версионности - хранение указанного количества измененных файлов, с описанием объекта, для обеспечения возможности отката на предыдущее сохранение. Второй уровень - создание модификаций (ревизий) объекта, с назначением статусов, и указанием порядковых номеров изделий, либо диапозона дат выпуска, когда действовала эта ревизия.
1.4 Создание workflow процессов выпуска, изменения, утверждения и т.п. деталей, в соответствии с бизнес-процессами предприятия. Цель - сократить сроки согласования изменений в конструкторской и технологической документации.
1.5 Обеспечение взаимодействия внутри холдинга. Цель - обеспечить быструю и корректную передачу актуальной информации от разработчика к подрядчикам.
2 Продвинутые задачи (доработки разной сложности)
2.1 Выгрузка информации по конкретным экземплярамизделия. Цель - обеспечения взаимодействия со смежными системами (ERP, SCMO).
2.2 Автоматизация формирования технологической документации, в соответствии с хранимой в системе информации. (РТК, ТП). Цель - сокращение затрат времени расчетчика и технолога на оформление результатов работы.
2.3 Автоматизация формирования конструкторской документациии, в соответствии с хранимой в системе информации. (спецификация, чертеж, извещение об изменении, и т.п.). Цель - сокращение затрат времени конструктора на оформление результатов работы.
3 Перспективные задачи
3.1 Ведение проектов внутри системы.
3.2 Ведение расцеховки в системе (было реализовано своими способами, в последней версии программы модуль manufacturing был улучшен настолько, что его для этого можно использовать)
3.3 Хранение конфигураций изделия
И еще кроме этого есть куча возможностей, до которых просто не успели еще добраться
-
Добрый день,
пусть немного позже, но встряну, т.к. опыт по внедрению PDM/PLM таки имеется. Более того, непосредственно столкнулся с двумя производителями (Dassault и PTC) и, соответственно, их PDM-системами и CAD-системами. CAM/CAE в проекте не рассматривали, но если что, то можно и их присобачить...
Кстати, дело частично (пилот) проходило в Самаре :о)))
Из прочитанного выше у меня не сложилось понимания, что понимание автора топика обладает по меньшей мере связностью. Поэтому толковые мысли Tinner'а, прошедшего определенные горнила, не находят четко выраженного отклика.
Что тут можно посоветовать?
во-первых, учить матчасть... причем долго и упорно...
во-вторых, есть МАССА тематических сайтов, где можно многое почерпнуть. например, www.johnstark.com - это из импортного, а теперь отечественный производитель - тульский токарев, он же ТТ, сегодня один, извини, очень быстро разбирают isicad.ru . в инете можно найти кучу форумов по этой тематике. также есть куча тематических мероприятий, которые в т.ч. проводят упомянутые компании. но штука в том, что сами по себе они не дадут просветления сознания - нужно самому сначала допереть.
в-третьих, у того же джона старка на сайте должна быть отличная книжка на языке вероятного противника - Introducing to PDM. Очень рекомендую почитать. Там нет ничего заумного, но очень хорошо определены ключевые моменты и расставлены акценты. Есть там книжка и про PLM, но она в тот период была за деньги, поэтому я ее не скачал, и потом, она большая и тяжелая (в физическом смысле)
К сожалению, не прозвучало выше, поэтому скажу, что основное для чего предназначены эти системы - для автоматизации технологии проектирования, которая на очень многих наших предприятиях недалеко ушла от времен царя Гороха. Есть приятные исключения, но они пока исключения, например, завод электропульт в питере (или где-то поблизости). Так вот, технология проектирования является составной частью культуры производства. Если Вы оглянетесь на Вашем предприятии, то легко определите, какая у вас технология проектирования. Кстати, технология проектирования, как и бизнес процессы, есть всегда. Другое дело, какая она и какова ее эффективность? Однако наличие технологии не означает, что ее можно натянуть на систему или, наоборот, натянуть систему на технологию. Такой вот парадокс. Причина - в принципиально разных парадигмах, которые используют западные производители (включая производителей софта для проектирования) и наши отечественные компании и институты, проектирующие по отечественным же гостам.
Постараюсь, коротенько минут на сорок дать пояснения по рассматриваемому предмету.
В практике существует три понятия "проект", точнее три варианта интерпретации термина, которые обозначают совершенно (практически) разное по смыслу:
а) проект - как объект технологии управления проектами (подробно определение смотри в PMBOK или НТК (буквы русские). тут все достаточно понятно, пояснять здесь не имеет смысла.
б) проект - как сам проектируемый объект: здание, конструкция, изделие и тп., в контексте "вариант/версия". Правильное название как раз такое - "проектируемый объект" или "проектируемое изделие".
в) проект - как набор проектной документации, грубо говоря, чертежей (различных марок), схем, спецификаций, пояснительных записок и тп., которая разрабатывается в ответ на ТЗ. Правильное название - "комплект документации", но его обычно никто не использует.
Из триединости понятия возникает много путаницы, поэтому смысловая нагрузка должна быть четко разнесена. Но Вы, очевидно, спросите, а где же тут технология проектирования? и будете правы! здесь технологии проектирования нет.
Она будет посередине между вершинами тетраэдра, три из которых перечислены выше, а четвертой являются ресурсы (по сути исполнители). Технология проектирования (в отечественной интерпретации) определяет последовательность разработки проектной документации на проектируемый объект. Причем содержание выполняемых операций существенно зависит от сути (содержания) объекта. По своему опыту могу утверждать, что технология проектирования зданий и автомобилей - содержательно разные.
Управление проектами здесь пришивается довольно просто - как планирование/балансировка ресурсов для выполнения операций в заданной технологии проектирования, ну и плюс контроль выполнения, управление рисками и прочее.
Отсюда я делаю вывод о первичности технологии проектирования перед управлением проектами. Хотя с этим можно и спорить.
Мне нравится проводить аналогию проектирования к.-либо изделия с разработкой софта. тогда для технологии проектирования аналогией будет нечто вроде RUP, ресурсы и управление проектом будут иметь тот же смысл, проектная документация - соответственно, документация на софт, а модель изделия соответствует разработанному софту.
с точки зрения инструментов тоже можно провести аналогию CAD - редактор кода/RAD/компилятор и остальная шняга.
Такая схема вполне конкретно определяет место каждого компонента технологии разработки проектирования.
Но где же тут PDM/PLM? Все очень просто PDM = Source Safe.
-
Доходчиво!
-
еще вопросы появились?
:о))
-
еще вопросы появились?
:о))
размечтался, на улице полдвенадцатого ночи. спать пора :) Завтра появятся:) Иди лучше про СИ (http://www.uml2.ru/forum/index.php?&topic=4474.msg31137;topicseen#msg31137) выскажись
-
К счастью (или к сожалению, кому как) PLM и PDM системы далеко не ограничены лишь проектированием, их основная задача - управление данными об изделии (всем его жизненном цикле) в масштабах предприятия (группы предприятий), и не стоит зацикливаться только на проектировании. С этого можно начать, в качестве пилотного проекта (для предприятий, занимающихся проектированием).
Эти системы можно применять на предприятиях, где проектирования как такового нет, например в фармакологии, или на предприятиях, где продуктом являются услуги.
-
С этого можно начать, в качестве пилотного проекта (для предприятий, занимающихся проектированием).
именно так и было. затем обязательно встанет вопрос - а что дальше?
конечный же смысл той системы был - обеспечить информационную поддержку на всех стадиях жизненного цикла объектов, которые сначала проектируются, потом строятся, потом эксплуатируются, ремонтируются и т.д.
-
Можно начинать автоматизацию сразу с производства, в случае, когда заказчик занимается аутсорсингом производства - это естественно, если есть собственное проектирование, то это имхо извращение. Я этот и предыдущий мой пост писал с целью показать, что не стоит зацикливаться только на автоматизации проектирования, надо с самого начала смотреть шире...
-
так-то оно так, только у нас заказчиком была проектная организация, у которой было, считай, одно проектирование, что на стадии строительства, что при ремонтах. ну и авторский надзор при строительстве. так что там технология проектирования во взаимосвязи с управлением проектами и архивом проектной документации - в полный рост.
-
Из прочитанного выше у меня не сложилось понимания, что понимание автора топика обладает по меньшей мере связностью. Поэтому толковые мысли Tinner'а, прошедшего определенные горнила, не находят четко выраженного отклика.
Здравствуйте. Возможно, Вы правы.
В целом, Водолей, спасибо за "лекцию". Многое что для себя понял и уяснил. Просто, понятно и доходчиво.
Что касается
Мне нравится проводить аналогию проектирования к.-либо изделия с разработкой софта. тогда для технологии проектирования аналогией будет нечто вроде RUP, ресурсы и управление проектом будут иметь тот же смысл, проектная документация - соответственно, документация на софт, а модель изделия соответствует разработанному софту.
с точки зрения инструментов тоже можно провести аналогию CAD - редактор кода/RAD/компилятор и остальная шняга.
Такая схема вполне конкретно определяет место каждого компонента технологии разработки проектирования.
Но где же тут PDM/PLM? Все очень просто PDM = Source Safe.
Меня недавно на мысль подтолкнули - провести некоторые исследования и сравнить технологию проектирования какого-либо изделия и технологию разработки программного обеспечения. Собственно, поэтому я и затеял эту тему.
-
Меня недавно на мысль подтолкнули - провести некоторые исследования и сравнить технологию проектирования какого-либо изделия и технологию разработки программного обеспечения. Собственно, поэтому я и затеял эту тему.
Если по верхам - то очень похоже. (см.выше аналогии). Хорошо сопоставляется проектирование сверху вниз и определение интерфейсов между компонентами. Но в остальном все разное. Даже если говорить о конечной сборке 3Д-модели (если такую вообще удастся собрать), то аналогия с программой неполная, хотя бы потому, что программа - это конечный продукт, а модель - вариант чертежа для дальнейшего производства. Со стыковками разных CADов не очень хорошо дело обстоит с точки зрения совместимости. не говоря уже о CAE и CAM. в крайнем случае линейка одного производителя будет друг с другом совместима, и то не факт (почему так - мне непонятно, но тем не менее это имеет место быть, хоть и улучшается со временем). Например, для того чтобы какие-нибудь прочностные расчеты сделать, недостаточно просто импортнуть CADовский файл, нужно кое-что ручками "довертеть" или просто перерисовать по образцу. Короче говоря, много разных нюансов имеется. Впрочем разработка софта тоже своими феньками изобилует...
-
Меня недавно на мысль подтолкнули - провести некоторые исследования и сравнить технологию проектирования какого-либо изделия и технологию разработки программного обеспечения. Собственно, поэтому я и затеял эту тему.
Кстати говоря, неплохая тема для диплома.
-
Коллеги, пролистал тему, но никто почему-то не упомянул ISO 10303 - так же есть Российская адаптация стандарта - ГОСТ Р ИСО 10303 от ВНИИКИ. Когда-то, лет 5 назад, участвовал в адоптации и частичной реализации стандарта NATO PDM, который является, по сути, PDM + PLM (основан на английском военном стандарте, а тот, в свою очередь, на ISO 10303). И очень хорошо все переносится в UML с языка EXPRESS-G, а затем и в XSD и схемы БД.
Стандарт подробно описывает все аспекты изделия - как процесс управления данными об изделии, так и требования к материалу, из которого изготовлено изделие, жизненный цикл изделия (от идеи до утилизации), форматы обмена данными об изделии (STEP) - PART 21, 28 (ISO 10303-21, 10303-28). Также включает и геометрическое описание для CAD-систем - PART 5xx)))
Ссылка на описание из википедии (http://en.wikipedia.org/wiki/ISO_10303)
Стандарт активно поддерживается всеми крупными мировыми производителями (тот же DASSAULT).