Работа Комлекса программ Аскон на Вашем предприятии

[tur]

Внедряем у себя на предприятии систему инженерного документооборота на базе программного комплекса Аскон (Лоцман, Компас, Вертикаль, МиС и т.д.).
В принципе все ПО по отдельности работает нормально, но как только начинаем все объединять появляется множество организационных проблем, которые сильно тормозят внедрение.

Основная масса баз данных для всего ПО создана, создаем состав изделия в Лоцман, техпроцессы разрабатываем в Вертикали, все привыкли (конструктора и технологи) и им даже нравится, но при этом:
1. Те же самые конструктора упираются и не хотят привязывать чертежи в лоцмане непосредственно к составу изделия, а только хранят их как файлы.
2. Технологи хотят только хранить свои ТП в Лоцмане, а не передавать данные в состав изделия.
Вроде все есть, настроено, работает, но конечного результата когда все данные по изделию хранятся в одной системе - нет.

Поделитесь опытом у кого работает такой же или аналогичный пакет программ.

Интересует, получилось ли у кого-нибудь запустить всю систему в целом и если да, то насколько она нужна, может стоит бросить все как есть и не мучаться?

[GL_E]

Разработать СТП (и не одно) и заставить всех работать по ним! Без вариантов!

Плюс грамотная система пряник-кнут

[Kirilius83]

Данная ситуация очень сильно напомнила пару старых тем про точ, что старые конструктора/технологи не хотели работать в компасе/вертикали, дескатьим на бумаге удобнее. Потом народ непринимал трехмерку, дескать нафиг нужна, когда проще ручками в 2Д чертеж накидать? Теперь следующий этап. Прогресс налицо однако)))))

Думается мне основная проблума - нежелание разбиртся в софте. Это ведь на самом деле нетак просто, изучить программу и перестроить свою работу на другой лад. Тем более когда не поняно зачем (а как понять пока не попробуешь?), ведь и так работается! ПРосто файл чертежа ведь всегда можно подправить, держать его на своем компе и никому не давать, и т.д. и т.п. А главное - разбираться в новой системе не надо, т.е. не придется думать лишний раз.
В общем, кроме как принять волевое решение "делать так и все" другого выхода не вижу...


А про запущеную систему тоже интересно послушать, как оно? 

[Николай]

Пару лет назад ездили смотреть, как это всё внедрено на Бугульминском машиностроительном заводе.( всё по АСКОНу).Вроде всё работло, что показали- все связки, кострукторских и технологических документов, базы даных, нормирование.Нам понравилось...

[tur]

Разработать СТП (и не одно) и заставить всех работать по ним! Без вариантов!

Плюс грамотная система пряник-кнут

В теории правильно, в жизни не получается.

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

А насчет СТП, вы сами когда нибудь пытались написать и утвердить СТП?
Ведь его нужно согласовать с технологами и конструкторами, а если они не хотят его согласовывать?

Пару лет назад ездили смотреть, как это всё внедрено на Бугульминском машиностроительном заводе.( всё по АСКОНу).Вроде всё работло, что показали- все связки, кострукторских и технологических документов, базы даных, нормирование.Нам понравилось...

А есть на форуме кто-нибудь с Бугульминского машиностроительного завода?

[Maxxx]

Главная проблемма как раз и заключается в

Технологи хотят

, (конструктора хотят, еще кто то чего то хотит))))...). А нет изначально желания делать так как нужно! И это довольно таки тяжело побороть. Зато потом, когда все заработает как нужно - все видят прелести и уже не представляют как по другому. И к хотелкам относятся попроще...

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

[tur]

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

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

[Николай]

И СТП писали, и угрожающие приказы и "подковёрные игры"- а как же без интриг... Волков бояться- в лес не ходить. 

[Warrior]

В теории правильно, в жизни не получается.

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

А насчет СТП, вы сами когда нибудь пытались написать и утвердить СТП?
Ведь его нужно согласовать с технологами и конструкторами, а если они не хотят его согласовывать?

Абсолютно согласен!!!

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

Особенно если люди которые эту систему разрабатывали и поддерживают ещё работают и всячески защищают СВОЁ детище, а всё новое неизбежно подразумевает некоторые проблемы до полной отладки.

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

[Maxxx]

Без волевого решения большого начальника ситуация патовая

Полностью согласен

[tur]

Особенно если люди которые эту систему разрабатывали и поддерживают ещё работают и всячески защищают СВОЁ детище, а всё новое неизбежно подразумевает некоторые проблемы до полной отладки.

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

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

У нас ситуация не патовая, просто внедрение идет медленнее чем хотелось бы.

И СТП писали, и угрожающие приказы и "подковёрные игры"- а как же без интриг... Волков бояться- в лес не ходить. 

Тут много говорят про СТП, это правильно, но повторяюсь системы две и обе рабочие, более старую остановить нельзя так как далеко не все расчеты переведены на асконовский комплекс - поэтому выпускать СТП сейчас не имеет большого смысла.


Но все же интересно, есть на форуме представители предприятий на которых этот комплекс работает в полном объёме?
Хотелось бы услышать их отзывы.

[Дмитрий22]

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

Попробуйте заинтересовать конструкторов привязывать чертежи в лоцмане непосредственно к составу изделия. В Лоцмане состав изделия может строится по Компас-спецификации, при этом все чертежи автоматически привязываются к составу, более того материал из этих чертежей автоматически извлекается из штампа и появляется в составе. Ключевое слово в предложении автоматически. Автоматизируйте ручной труд конструктора и они сами будут следить за порядком в Лоцмане.
После этого сообщения многие начнут возражать, что достоверности такой системы нет. Она ЕСТЬ! После утверждения КД гл. конструктором, конструктор, который разрабатывал данный узел переводит состав изделия в состояние "Серия", предварительно убедившись, что состав изделия в Лоцмане и КД соответствуют друг другу. После этого ни одна живая душа, даже он сам не сможет внести изменения в чертежи (только по извещению). Т.е. за достоверность в Лоцмане отвечает сам конструктор до перевода в серию, после уже сам Лоцман.Если конструктор переведет в серию, не убедившись в достоверности КД, ему хана. Ему придется принести системному администратору столько шоколадок и вытерпеть столько нареканий со стороны гл. конструктора, что "мало не покажется" (про нарекания от коллег я расскажу дальше). Для нас отклонение от достоверности по вине конструктора такой же брак, как и для токаря проточить вал меньшего диаметра, чем нужно. Ведь с базой Лоцмана работают другие конструктора, которые заимствуют, копируют объекты в свои чертежи и если там будет, например, устаревшая инф. то страдает не один, а уже несколько конструкторов.
Но, вернемся к началу разговора.

2. Технологи хотят только хранить свои ТП в Лоцмане, а не передавать данные в состав изделия.

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

[tur]

Страница 27

http://ascon.ua/source/info_materials/ascon_corporate_magazine_8.pdf

[tur]

Попробуйте заинтересовать конструкторов привязывать чертежи в лоцмане непосредственно к составу изделия. В Лоцмане состав изделия может строится по Компас-спецификации, при этом все чертежи автоматически привязываются к составу, более того материал из этих чертежей автоматически извлекается из штампа и появляется в составе. Ключевое слово в предложении автоматически. Автоматизируйте ручной труд конструктора и они сами будут следить за порядком в Лоцмане.
.........
Так дайте технологам средства автоматизации их труда, как мы дали конструкторам и они потянутся к Вам.
Я уже приводил пример, как знакомая фирма приобрела пакет PDM 1С в результате конструктора половину времени тратят на разработку КД, а другую половину на вбивание в базу состава изделия. Т.е. высококвалифицированные конструктора работают в роли печатной машинки. Неудивительно, что они такую автоматизацию ругают почем свет стоит.

Классическая схера разработки документации представляет собой:
1. Разрабатывается состав изделия
2. На базе состава изделия выпускается документация КД.
3. На базе документации по КД выпускается технологическая документация.

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

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

P.S. Хорошо когда используется одна CAD, а если их две или больше? А еще встречаются конструктора которые до сих пор чертят на комбайнах и как быть для сканированных документов.
Например на нашем предприятии до сих пор в производстве могут использоваться чертежи 60-70 годов и перевыпустить их быстро нет возможности, очень большой объем.

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

[Вячеслав]

Внедряем у себя на предприятии систему инженерного документооборота на базе программного комплекса Аскон (Лоцман, Компас, Вертикаль, МиС и т.д.).
В принципе все ПО по отдельности работает нормально, но как только начинаем все объединять появляется множество организационных проблем, которые сильно тормозят внедрение.

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

Не может быть ХОЧУНЕХОЧУ на предприятии, есть приказ и его выполнение.
Не конструкторы и технологи "НЕ ХОТЯТ что-либо сделать", а руководители "НЕ МОГУТ обеспечить выполнение". У них или нет желания что-либо изменять в лучшую сторону, или они просто не могут потребовать выполнения элементарных требований.
Нет желания что-либо изменять в лучшую сторону, не нужно и затевать автоматизацию...На мой скромный взгляд...

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

[Дмитрий22]

Классическая схера разработки документации представляет собой:
1. Разрабатывается состав изделия
2. На базе состава изделия выпускается документация КД.

Не правда Ваша, вернее не вся правда. Заранее известен состав первого уровня входящих узлов проекта и то не более 10. Представьте, что в проект входит рамная конструкция. Вы сразу скажете из скольких подсборок она будет состоять и сколько деталей будет в нее входить? Да, никогда. Бывает, в процессе проектирования детали объединяются в подсборку и наоборот потому как проектирование процесс творческий и все меняется в этом процессе. Извините меня, забить 10 подсборок в дерево верхнего уровня не представляет труда, а вот забить все подсборки все детали в эти подсборки это уже сложнее. Если этот процесс не автоматизировать, конструктора всегда будут возмущаться, потому как они один раз в спецификацию в вбивают номера, второй раз в Лоцман. Зачем эта двойная работа?

[obesov]

Не правда Ваша, вернее не вся правда. Заранее известен состав первого уровня входящих узлов проекта и то не более 10.

Вот как раз неумение или нежелание разрабатывать состав проекта и приводит к двойной, тройной и т.д. работе. 
Автоматизировать что-либо можно на основе достоверной базы данных. Состав проекта и является частью этой базы!
P.S. Интересно: чем у Вас ГК занимается, если конструкторам приходится детали по подсборкам туда-сюда перетаскивать? 

[Дмитрий22]

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

[tur]

Не правда Ваша, вернее не вся правда. Заранее известен состав первого уровня входящих узлов проекта и то не более 10. Представьте, что в проект входит рамная конструкция. Вы сразу скажете из скольких подсборок она будет состоять и сколько деталей будет в нее входить? Да, никогда. Бывает, в процессе проектирования детали объединяются в подсборку и наоборот потому как проектирование процесс творческий и все меняется в этом процессе. Извините меня, забить 10 подсборок в дерево верхнего уровня не представляет труда, а вот забить все подсборки все детали в эти подсборки это уже сложнее. Если этот процесс не автоматизировать, конструктора всегда будут возмущаться, потому как они один раз в спецификацию в вбивают номера, второй раз в Лоцман. Зачем эта двойная работа?

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

Вот как раз неумение или нежелание разрабатывать состав проекта и приводит к двойной, тройной и т.д. работе. 
Автоматизировать что-либо можно на основе достоверной базы данных. Состав проекта и является частью этой базы!
P.S. Интересно: чем у Вас ГК занимается, если конструкторам приходится детали по подсборкам туда-сюда перетаскивать? 

Это правильно! +

[Kirilius83]

Насколько я понимаю, есть изделие. изделие состоит из узлов. Так ведь количество узлов известно изначально ! Во всяком случае имея некоторый опыт и и чутка подумав, можно аккуратно разбить изделие на узлы. Вот и есть состав изделия, нет?
Ну а узел состоит из подсборок и деталей, и да, они определяются походу разработки КД. Если же в процессе проектирования приходится нумерацию деталей менять - ну так это уже от неправильно выбранной номурации изначально. И разве Лоцман (как и спецификация) сам не берет номера чертежей из основной надписи и из спецификации? Как это туда номера вручную вбивать?