БИЗНЕС-СЕТЬ KINETICS CRM CALL-ЦЕНТРЫ ERP ECM ITSM АБС

 ПоискПоиск   ПользователиПользователи   РегистрацияРегистрация   ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 


Машиностроение? - см. Omega Production

 
ERP Форум -> ERP системы и поставщики
Автор Сообщение
Николай Нагорных



Зарегистрирован: 20.05.2010
Сообщения: 6


СообщениеДобавлено: Чт Май 20, 2010 8:58 am     Посмотреть профиль Отправить личное сообщение

Нам простым парням с Урала, конечно, не сравнится со столичными зубрами сбыта и маркетинга (хотя стараемся), но тем не менее, отметимся здесь ))

1. Ядром MPRII Omega Production является тяжелая PDM система, что позволяет оперировать "живым составом" без интеграции с другими решениями. Это позволяет эффективно выполнять сложные многофакторные отчеты, начиная с "руды", например, решить задачу, как повлияло на с/с конструктивное изменение изделия или во что выльется в будующем переход на альтернативный технологический процесс.
Интеграция с PDM решением - "костыль". Как правило, актуальность и полнота данных резко падают. Я говорю о разного рода промежуточных выгрузках, загрузках, анализ протокола ошибок, исправление и поиск, чей "косяк" - в топку.

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

3. Omega Production - только ORACLE. Утверждаем, что выбор КИС систем на КРУПНЫХ машиностроительных предприятиях с СУБД, отличных от ORACLE приводит к проблемам с производительностью.

4. Поддержка распределенных ХОЛДИНГОВЫХ решений.

5. Omega Production - является де факто стандартом машиностроения в р. Беларусь, в том числе является соразработчиком государственной программы CALS технологий.

Готовы ответить на вопросы.

Теперь можно БАН. ))
_________________
C уважением и наилучшими пожеланиями
Нагорных Николай,
Уральское представительство компании ОмегаСофтвер
SM.Artem



Зарегистрирован: 30.08.2010
Сообщения: 2


СообщениеДобавлено: Пн Авг 30, 2010 5:32 am     Посмотреть профиль Отправить личное сообщение

Добрый день, Николай.

Николай Нагорных писал(а):
1. Ядром MPRII Omega Production является тяжелая PDM система, что позволяет оперировать "живым составом" без интеграции с другими решениями. Это позволяет эффективно выполнять сложные многофакторные отчеты, начиная с "руды", например, решить задачу, как повлияло на с/с конструктивное изменение изделия или во что выльется в будующем переход на альтернативный технологический процесс.

Интеграция с PDM решением - "костыль". Как правило, актуальность и полнота данных резко падают. Я говорю о разного рода промежуточных выгрузках, загрузках, анализ протокола ошибок, исправление и поиск, чей "косяк" - в топку.


Хотелось бы уточнить. Если Омега содержит внутри себя мощный функционал по части PDM, как там выполняется реализация связки CAD, CAPP - систем?
Понятно, что, например, в строительстве можно обойтись без выгрзок данных с КД, но как быть с машиностроением - где есть составы, где есть технологическая документация?
Есть ли возможность получить состав изделия в Омеге имея только спецификацию и чертежи в каком-либо CAD, например SW, T-Flex или КОМПАС?
А как быть с технологами, если они разрабатывают ТП также используя какую-либо систему автомтаизированного проектирования?
_________________
Never out off till tomorrow what you can do today
Николай Нагорных



Зарегистрирован: 20.05.2010
Сообщения: 6


СообщениеДобавлено: Пн Авг 30, 2010 8:17 am     Посмотреть профиль Отправить личное сообщение

SM.Artem писал(а):
1. Ядром MPRII Omega Production является тяжелая PDM система, что позволяет оперировать "живым составом" без интеграции с другими решениями. Это позволяет эффективно выполнять сложные многофакторные отчеты, начиная с "руды", например, решить задачу, как повлияло на с/с конструктивное изменение изделия или во что выльется в будующем переход на альтернативный технологический процесс.

Интеграция с PDM решением - "костыль". Как правило, актуальность и полнота данных резко падают. Я говорю о разного рода промежуточных выгрузках, загрузках, анализ протокола ошибок, исправление и поиск, чей "косяк" - в топку.


Хотелось бы уточнить. Если Омега содержит внутри себя мощный функционал по части PDM, как там выполняется реализация связки CAD, CAPP - систем?
Понятно, что, например, в строительстве можно обойтись без выгрзок данных с КД, но как быть с машиностроением - где есть составы, где есть технологическая документация?
Есть ли возможность получить состав изделия в Омеге имея только спецификацию и чертежи в каком-либо CAD, например SW, T-Flex или КОМПАС?
А как быть с технологами, если они разрабатывают ТП также используя какую-либо систему автоматизированного проектирования?


Добрый день, Артем!
1. СAPP - встроенная полноценная технологическая подсистема. Как показало недавнее уральское мероприятие "Парад Технологических Систем" -ничем не хуже Techcard, Вертикаль и пр. Там выдавались реальные техпроцессы и шла параллельно разработка в разных системах. Я даже поначалу был против участия, в опасении, что создастся негатив в сравнении с "монстрами", использующими "продвинутый функционал" типа КТЭ. Сила Омеги в том, что это сквозная система и сравнивать с локальными решениями невыгодно. Оказалось - был неправ. В боевых условиях все эти КТЭ - не востребованы и Omega была на равных, а по сварке - вышла вперед ))

2. CAD - да, есть вычитка состава из SolidWorks, Компас 3D, Inventor, Unigraphics, SolidEdge, CATIA, Pro/Engineer, P-CAD, Altium Designer.

Я бы хотел отдельно высказаться по поводу интеграции с САПР.
2.1 Думается, что полноценной интеграции нет даже у разработчиков CAD + PLM. Есть разные погрешности передачи данных, зависящие от неучтенных ньансов проектирования и "исключений" конструктора, как, например, вставка в графе примечание "доп. зам. поз. 3 на поз. 5 совм. с поз 8." Скорее всего, это не будет учтено даже при "родной" интеграции. У конструктора могут возникнуть другие ситуации, влекущие искажение данных, которые не будут обрабатываться при интеграции, и в лучшем случае, о них сообщится в логе при передаче данных.
Использование неформализованных и "неподхватываемых" при интеграции "вспомогательных объектов" в модуле разработки спецификаций одного известного CAD поставщика - вообще стандартная конструкторская практика. При организации ЕИП, я бы вообще запретил использование этого модуля (и сэкономил бы деньги на лицензиях )) )
2.2 Справочники - камень преткновения. Они должны быть едиными. Это - неотемлимая часть интеграции. Используются всякие там полуручные сопоставления, что ставит под сомнения даже родную интеграцию поставщиков CAD+ PLM
2.3 Если что-то передалось не так как надо, в данных ошибки, специалист всегда сможет перевести стрелки на интеграцию, мол, программа не так "передала" и кстати, в большинстве случаев окажется прав ))
2.4 Конструкторский состав зачастую перерождается в технологический (технологические решения по видоизменению сборки, появление технологических деталей, образцов и т.д.) который уже ближе к данным для планирования. Т.е. технолог - вторая стадия уточнения и актуализации данных для планирования.
Т.е. интеграция с CAD важна - но недостаточна для получения данных для планирования.

Я это клоню к следующему:
- Конструктор должен печатать документ спецификация из под PLM и точка. Изменение - печатать по новой. Другие способы - исключены. Да, он может использовать закачку данных из CAD файла как вспомогательный процессс, но конечный результат должен быть проверен и актуализирован в PLM.

Кстати, если говорить об интеграции с СAPP, сейчас полгода "завершаем" таковую с ВЕРТИКАЛЬ. Это очень трудоемкий процесс. Одни ТТП/ГТП чего стоят. А еще есть оснастка, у нее свой состав, свои процессы. Я даже не знаю когда 100 процентов сделаем. Структура данных очень сложная, добавляешь оснастку - и не знаешь в какую таблицу вписать - их там 16 штук. Вот если бы предприятие выразило желание перевести технологов на омегу - бесплатно бы дали лицензии и обучили, но они уже там столько наработали ...
_________________
C уважением и наилучшими пожеланиями
Нагорных Николай,
Уральское представительство компании ОмегаСофтвер
SM.Artem



Зарегистрирован: 30.08.2010
Сообщения: 2


СообщениеДобавлено: Ср Сен 15, 2010 3:53 am     Посмотреть профиль Отправить личное сообщение

День добрый!

Николай Нагорных писал(а):

1. СAPP - встроенная полноценная технологическая подсистема. Как показало недавнее уральское мероприятие "Парад Технологических Систем" -ничем не хуже Techcard, Вертикаль и пр. Там выдавались реальные техпроцессы и шла параллельно разработка в разных системах. Я даже поначалу был против участия, в опасении, что создастся негатив в сравнении с "монстрами", использующими "продвинутый функционал" типа КТЭ. Сила Омеги в том, что это сквозная система и сравнивать с локальными решениями невыгодно. Оказалось - был неправ. В боевых условиях все эти КТЭ - не востребованы и Omega была на равных, а по сварке - вышла вперед ))


Тут я с вами согласен. КТЭ, о чем многие разработчики кричат, пока не позволяют реализовать того функционала, ради которого они были придуманы.
Вопрос в удобстве представления данных технологической информации. Если взять ВЕТИКАЛЬ, TechnologiCS и T-Flex Технология и тому подобные - там весь техпроцесс представляется в давольно удобной форме, близкой к бумажной, в том плане, что есть операция, куда входят оборудования, переходы, оснастка и т.д. и все это ввиде иерархической структуры. Глядя на "дерево" сразу становится понятным, что, где и почем.

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

Но это все дело времени и привычки.



Николай Нагорных писал(а):
Я это клоню к следующему:

- Конструктор должен печатать документ спецификация из под PLM и точка. Изменение - печатать по новой. Другие способы - исключены. Да, он может использовать закачку данных из CAD файла как вспомогательный процессс, но конечный результат должен быть проверен и актуализирован в PLM.


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

Ну с обозначением все довольно просто и понятно. Вопросы начинают возникать, когда спецсимволы есть в наименовании ДСЕ.
Например, Калибр на "диаметр" 23 "плюс-минус" 0.05. В данном случае спецсимволы "диаметр" и "плюс-минус" должны быть записаны в основной надписи как значки и также в виде значков перейти в спецификацию. И таких примеров достаточно.
Проблема многих PDM в том, что строку с наименованием хранят в обычном строковом типе со стандартным шрифтом, кторый не поддерживает подобные символы. Что делать в этом случае? Править вручную основную надпись и спецификацию - не совсем верно, точнее даже совсем не верно. Я сейчас, не говорю о какой-то конкретной PDM.
Хотелось бы узнать, как дело обстоит в Омеге?


Николай Нагорных писал(а):
Кстати, если говорить об интеграции с СAPP, сейчас полгода "завершаем" таковую с ВЕРТИКАЛЬ. Это очень трудоемкий процесс. Одни ТТП/ГТП чего стоят. А еще есть оснастка, у нее свой состав, свои процессы. Я даже не знаю когда 100 процентов сделаем. Структура данных очень сложная, добавляешь оснастку - и не знаешь в какую таблицу вписать - их там 16 штук. Вот если бы предприятие выразило желание перевести технологов на омегу - бесплатно бы дали лицензии и обучили, но они уже там столько наработали ...


Очень интересная информация. Насколько я знаю, структура техпроцесса ВЕРТИКАЛи достаточно понятна, если выполнить экспорт в XML. Да, объем данных большой за счет объектной модели данных и большого числа атрибутов, но вполне читабельно.
Или проблема на стороне Омеги?
_________________
Never out off till tomorrow what you can do today
Николай Нагорных



Зарегистрирован: 20.05.2010
Сообщения: 6


СообщениеДобавлено: Ср Янв 12, 2011 1:34 pm     Посмотреть профиль Отправить личное сообщение

Прошу прощения долго не было.
По интеграции с ВЕРТИКАЛЬ:
Сделали.
Полноценная интеграция требует не только передачи техпроцесса, но и преварительной синхронизации многих справочников. При этом не разово, а системно. Ну и хотелки у Заказчика постоянно менялись ))
Вообще, "интеграция - костыль автоматизации". Мы статью даже написали в САПР и ГРАФИКА за октябрь 2010.
Статья в итоге вышла нудная, но отклик есть - мне даже в ЖЖ отписался аноним с критикой ))

Из новостей - окончательная победа в тендере на УВЗ
http://cad4net.livejournal.com/4283.html

Также лично посетил МТЗ. Впечатляет, конечно. Комплектации формирует отдел маркетинга по набранным конструкторами правилам и СРАЗУ уходит в подготовку и само производство. На конвейере почти нет одинаковых тракторов.

Также посетил МАЗ, там все хорошо, кроме того, что конструктора исторически работают в TeamCenter и это влечет за собой разрыв между конструкторами и производством, несмотря на полнейшую интеграцию (передаются даже извещения) - там конструктора набивают в TC комплектации и на бумаге отдают в подготовку.
_________________
C уважением и наилучшими пожеланиями
Нагорных Николай,
Уральское представительство компании ОмегаСофтвер
ERP Форум -> ERP системы и поставщики Часовой пояс: GMT
Страница 1 из 1

 


Powered by LP © 2001, 2005 phpBB Group