С чего начать внедрение

[Route 2]

Например, предприятие только сканирует и привязывает к вручную созданной ЭСИ старые калечные чертежи, при этом не создавая ничего нового. CAD-овскую PDM систему они конечно понавтыкали буквально везде, вплоть до бухгалтерии, и даже пользуют WORKFLOW, вот только 3D моделей как таковых у них фактически нет.

Ребята действительно искренне верят, что у них идёт автоматизация, но ведь в самом то деле это далеко не так.

Да, да есть такие предприятия. Что ж им еще делать если они в таком упадническом состоянии....

Эти предприятия, насколько я понимаю, решают проблему актуализации лоскутков информации поднимая структуру изделия из самопальных программок на FoxPro. Такой способ создания структуры изделия намного быстрее тягомотного создания 3D-моделей. Ведь здесь важно скорее всего понять что точно следует восстанавливать в 3D-моделях, а что оставить не тронутым бумажным архивом. Создавать модели в этом случае они наверно будут постепенно, отсеевая шелуху.

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

Главная причина таковой невозможности это постоянное обновление версий систем.

Однако, почему бы не остановиться на каком либо определённом наборе релизов лет на 7...8...9...10 и только посмеиваться в ответ на все заявления продавцов софта о ретроградстве?

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

Да вроде как верно…. Но только в случае если предприятие монополист в своей нише, да с заказами на 100 лет в перед.

А если приходится добросовестно соревноваться с конкурентами, схема документооборота «администрация - конструктор - технолог - производство - бухгалтерия – администрация» будет, мягко сказано, не гибкой, да и жутко медлительной.

Знаем…проходили…все теже последовательные согласования…согласования..согласования...., а потом с пометкой «Срочно» недопроектированное изделие в производство…. Еще цифровую подпись сюда прилепить и вообще получится не подвижная махина.

Во интересно то как, а повышение точности итерации при разработке новой техники с соответствующим уменьшением затрат на отработку и общее сокращение сроков уже как бы не в зачёт?

Синхронизация баз данных это конечно вопрос не из лёгких, но почему считается, что его нельзя решить на основе точного ЭЦМ с максимально упрощеным программными средствами вводом самим конструктором/технологом ключевых атрибутов?

Например, просто вводя название файла модели в строгом соответствии с СТП вполне можно незаметно получить атрибуты <Обозначение>, <Наименование> и <Разработал>, если немного подумать, то и <Первичное применение>, а если ещё чуть-чуть помудрить с шаблонами то можно тут же идентифицировать тип обработки, точности, заготовку и материалы и т.д. Как именно сие реализовать в максимально комфортном для пользователя виде - это и есть собственно работа IT специалистов, а передать дальше по цепочке весь этот джентельменский набор и сейчас вполне возможно, хотя бы посредством html.

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

Вы верите в силы IT-отдела? А может вы взвалили на IT-шнеков непомерную ношу? Ведь то чего Вы хотите не существует. Я повторюсь, этот путь проходят все российские предприятия смотря при этом друг на друга , грабли то уже поломаны…, ан нет..надо попробовать самим.

Я сейчас знакомлюсь с ознакомительной версией новой системы 1С:PDM. Могу уверить Вас в том что, все разговоры про «обозначение», «наименование», «разработал», тип обработки и т.п. это все цветочки.

Попробуйте реализовать связь всех вычисляемых и не вычисляемых свойств 3D-модели с технологией изготовления изделия. Так чтоб при изменении и сохранении 3D-модели менялся вычесляемый параметр технологии (в реальном времени). А потом выпустите извещение с изменением геометрии модели, потом отменяющее извещение. И все это с сохранением истории изменений ( а то трудновато вручную пересчитывать плюсы и минусы таких изменений) . Забыл совсем - 1 минута на все операции - с отображением результата проделанных изменений для всех участников КТПП сразу после проведения изменений.

"Автоматизация КТПП" это и не цель вовсе, но средство, при чём средство сие в самом деле и называется то иначе.

Главное когда цель есть Дело за выбором инструмента!

Изменено 14 июля 2009 пользователем Route

[DmitryV 0]

Я сейчас знакомлюсь с ознакомительной версией новой системы 1С:PDM. Могу уверить Вас в том что, все разговоры про «обозначение», «наименование», «разработал», тип обработки и т.п. это все цветочки.

Попробуйте реализовать связь всех вычисляемых и не вычисляемых свойств 3D-модели с технологией изготовления изделия. Так чтоб при изменении и сохранении 3D-модели менялся вычесляемый параметр технологии (в реальном времени). А потом выпустите извещение с изменением геометрии модели, потом отменяющее извещение. И все это с сохранением истории изменений ( а то трудновато вручную пересчитывать плюсы и минусы таких изменений) . Забыл совсем - 1 минута на все операции - с отображением результата проделанных изменений для всех участников КТПП сразу после проведения изменений.

Прошу прощения,, я про 1С не понял.

С какой CAD - системой она вообще может работать?

[Странник 6]

...если приходится добросовестно соревноваться с конкурентами, схема документооборота «администрация - конструктор - технолог - производство - бухгалтерия – администрация» будет, мягко сказано, не гибкой, да и жутко медлительной.

…все теже последовательные согласования…согласования..согласования...., а потом с пометкой «Срочно» недопроектированное изделие в производство…. Еще цифровую подпись сюда прилепить и вообще получится не подвижная махина.

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

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

Вы верите в силы IT-отдела? А может вы взвалили на IT-шнеков непомерную ношу? Ведь то чего Вы хотите не существует. Я повторюсь, этот путь проходят все российские предприятия смотря при этом друг на друга , грабли то уже поломаны…, ан нет..надо попробовать самим.

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

Вообще же говоря, создание "обвязки" для CAD/PDM под конкретные предприятия является прямою обязанностью IT подразделений, пусть ребята пишут программы средствами API. Лучше бы конечно было сразу готовое купить, да что то не предлагают такого товара.

[Route 2]

Прошу прощения,, я про 1С не понял.

С какой CAD - системой она вообще может работать?

Могу сказать только что с SolidWorks 1С-PDM работает точно. Своими глазами видел в реальном режиме времени. Могу подробней рассказать или же ролики выложить куда нибудь, если захотите.

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

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

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

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

Вообще же говоря, создание "обвязки" для CAD/PDM под конкретные предприятия является прямою обязанностью IT подразделений, пусть ребята пишут программы средствами API. Лучше бы конечно было сразу готовое купить, да что то не предлагают такого товара.

Прочитал полностью тему. Увидел реализацию считывания атрибутов из названия файлов. Вот как раз это я и могу назвать началом физического внедрения системы. Да именно этим и должны заниматься IT-шники при внедрении помогать-облегчать и т.п.

Но после того как внесение CAD-данных закончилось...не хочется ли выйти на новый уровень автоматизации? Передать атрибуты одно дело, а сделать эти атрибуты физически едиными и для технологии , и для CAD, и т.п.? Можно я думаю и эту проблему решить IT-отделу…. лет так через 5-ть.

Я бы не советовал экспериментировать, а покупать действительно серьезную систему. Я более склоняюсь к западным системам (TeamCenter, Windchill), если же из нашенских то к 1С:PDM.

Изменено 14 июля 2009 пользователем Route

[Странник 6]

Но после того как внесение CAD-данных закончилось...не хочется ли выйти на новый уровень автоматизации? Передать атрибуты одно дело, а сделать эти атрибуты физически едиными и для технологии , и для CAD, и т.п.?

Тут есть 2 нюанса, про которые нельзя забывать в принципе.

1. Технологу конструкторская модель нужна не более чем собаке пятая лапа.

2. Производству до изделия дело не более чем мёртвому до славы.

У этой братии есть номер ведомости/партии/серии, есть потребность в комплекте КД, что в этом заказе фигурирует, а какова эта "железяка" и куда она пойдёт им сугубо фиолетово. Кончилась ведомость и они отправят чертежи в топку без всякого сожаления, будь то хоть бумажный, хоть электроный вид.

Посему ИМХО чётко просматривается как минимум 2 разных хранилища: в одном лежат изделия, а в другом ведомости. Вот между этими то двумя островками и должна будет "ходить" ЭСИ с привязанными чертежами, карточками отступления, предварительными извещениями, извещениями, актами, служебками и прочей макулатурой в электронном виде. Это мост №1.

Выходными данными технологов является техпроцесс, но он в чистом виде не нужен бухгалтеру-плановику, а нужны таковым сотрудникам некие выжимки из техпроцесса по материалам, комплектующим, трудоёмкости, расценкам и т.п. Это мост №2.

В свою очередь конструктору весьма недурно представлять хотя бы себестоимость своих измышлизмов, впрочем как и технологическому человеку. Стало быть нужен ещё один мостик - №3.

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

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

-единого WORKFLOW, при чём не факт что этим WORKFLOW сможет быть какое либо из принадлежащих любому из 3 названных "островков".

Таким образом, самой тяжёлой представлятся работа по созданию синхронизаторов обменных данных для для разных сфер деятельности, а так же интегратора единой базы знаний предприятия.

[Route 2]

Тут есть 2 нюанса, про которые нельзя забывать в принципе.

1. Технологу конструкторская модель нужна не более чем собаке пятая лапа.

2. Производству до изделия дело не более чем мёртвому до славы.

Спорно, но так и есть на российских предприятиях.

У этой братии есть номер ведомости/партии/серии, есть потребность в комплекте КД, что в этом заказе фигурирует, а какова эта "железяка" и куда она пойдёт им сугубо фиолетово. Кончилась ведомость и они отправят чертежи в топку без всякого сожаления, будь то хоть бумажный, хоть электроный вид.

Посему ИМХО чётко просматривается как минимум 2 разных хранилища: в одном лежат изделия, а в другом ведомости. Вот между этими то двумя островками и должна будет "ходить" ЭСИ с привязанными чертежами, карточками отступления, предварительными извещениями, извещениями, актами, служебками и прочей макулатурой в электронном виде. Это мост №1.

Выходными данными технологов является техпроцесс, но он в чистом виде не нужен бухгалтеру-плановику, а нужны таковым сотрудникам некие выжимки из техпроцесса по материалам, комплектующим, трудоёмкости, расценкам и т.п. Это мост №2.

В свою очередь конструктору весьма недурно представлять хотя бы себестоимость своих измышлизмов, впрочем как и технологическому человеку. Стало быть нужен ещё один мостик - №3.

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

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

-единого WORKFLOW, при чём не факт что этим WORKFLOW сможет быть какое либо из принадлежащих любому из 3 названных "островков".

Таким образом, самой тяжёлой представлятся работа по созданию синхронизаторов обменных данных для для разных сфер деятельности, а так же интегратора единой базы знаний предприятия.

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

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

Совершенно ясно что любой интегратор, шлюз, синхронизатор замедляет работу предприятия в геометрической прогрессии. Ведь любое изменение (ИИ) пойдет практически по всем базам (лоскуткам), и если изделие не является ложкой или вилкой то изменение пройдет по всем базам только вечером или глубокой ночью, когда все уйдут со своих рабочих мест. Зачем тогда WORKFLOW, можно ходить тогда пешочком согласовывать, не торопясь?

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

Что касается передачи значений вычисляемых свойств из CAD-модели в PDM...(в технологию или еще куда), конечно это уж по желанию. Думаю, технологам будет проще автоматом получать в типовых ТП расчет каких либо режимов или еще чего, исходя из параметров модели.

Наверное Вы слышали о технологических платформах? Ну и как же тут конструктор без технолога и технолог без конструктора?

А это (я надеюсь) наши предприятия в будущем ждет.

Изменено 15 июля 2009 пользователем Route

[Странник 6]

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

Карточки отступлений появляются как последствие чьей либо ошибки, либо недееспособности. Штука это всегда склочная и вполне неизбежная, ибо каждый человек имеет право совершить и исправить ошибку, либо заплатить за неё по счёту. Впрочем, иногда эта же карточка выполняет и в чистом виде управляющую функцию, как и ПИ, ИИ, акт, служебная записка и т.п. Пути прохождения этих докУментов, вместе с заказными листами, оперативными распоряжениями, маршрутами согласования техпроцессов, приказами, распоряжениями и т.п. собственно WORKFLOW и определят.

С другой стороны, в идеальном случае конструктору из отдела №13 заботы до проблем цеха №7 одинаково нету, будь он хоть во Владивостоке, хоть в Бресте, хоть в 100 метрах от от его собственного рабочего стола. Конструктору важно что бы изготовленное строго по его КД изделие выполняло бы все требования технического задания, а какие там в производстве запятые - это дело самого производства.

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

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

Пусть себе изделие АБВГ.00.000 окончательно собирается в Туле, а вот блок АБВГ.01.000 изготавливаться будет в Чите, АБВГ.02.000 в Архангельске, АБВГ.03.000 в Екатеринбурге т.д. При этом по факту заключения договора из Тулы в соответствующие города должна будет "уехать" таж самая ЭСИ с привязанной КД в нередактируемом формате, а оттуда должна будет приехать уже матчасть, но опять же с соответсвующей сопроводительной документацией и тоже в привязке к ЭСИ.

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

Совершенно ясно что любой интегратор, шлюз, синхронизатор замедляет работу предприятия в геометрической прогрессии. Ведь любое изменение (ИИ) пойдет практически по всем базам (лоскуткам), и если изделие не является ложкой или вилкой то изменение пройдет по всем базам только вечером или глубокой ночью, когда все уйдут со своих рабочих мест. Зачем тогда WORKFLOW, можно ходить тогда пешочком согласовывать, не торопясь?

А что нам помешает

1. выделить технический перерыв, например, совпадающий с обеденным, специально для обновления хранилищ ещё и в дневное время?

2. организовать те самые комплексные конструкторско-технологические бригады, в которых документация будет согласовываться в одном хранилище вплоть до её утверждения и помещения в "электронный сейф единой базы знаний"?

Что касается передачи значений вычисляемых свойств из CAD-модели в PDM...(в технологию или еще куда), конечно это уж по желанию. Думаю, технологам будет проще автоматом получать в типовых ТП расчет каких либо режимов или еще чего, исходя из параметров модели.

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

[Route 2]

Карточки отступлений появляются как последствие чьей либо ошибки, либо недееспособности. Штука это всегда склочная и вполне неизбежная, ибо каждый человек имеет право совершить и исправить ошибку, либо заплатить за неё по счёту. Впрочем, иногда эта же карточка выполняет и в чистом виде управляющую функцию, как и ПИ, ИИ, акт, служебная записка и т.п. Пути прохождения этих докУментов, вместе с заказными листами, оперативными распоряжениями, маршрутами согласования техпроцессов, приказами, распоряжениями и т.п. собственно WORKFLOW и определят.

С другой стороны, в идеальном случае конструктору из отдела №13 заботы до проблем цеха №7 одинаково нету, будь он хоть во Владивостоке, хоть в Бресте, хоть в 100 метрах от от его собственного рабочего стола. Конструктору важно что бы изготовленное строго по его КД изделие выполняло бы все требования технического задания, а какие там в производстве запятые - это дело самого производства.

Ну, хоть в одном мы уже точно с Вами сошлись. Да действительно, "Пути прохождения этих документов собственно WORKFLOW и определят." Только не "определяет", а копирует существующий на предприятии документооборот. Зачем? Что WORKFLOW ускорит, прохождение документов? Люди станут быстрее ставить флажки в окошках системы? Нет, они сначала стайками на совещаниях будут собираться, а потом уже эти флажки ставить. Это пустая трата времени без реорганизации бизнес-процессов. Это мы проходили...

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

Пусть себе изделие АБВГ.00.000 окончательно собирается в Туле, а вот блок АБВГ.01.000 изготавливаться будет в Чите, АБВГ.02.000 в Архангельске, АБВГ.03.000 в Екатеринбурге т.д. При этом по факту заключения договора из Тулы в соответствующие города должна будет "уехать" таж самая ЭСИ с привязанной КД в нередактируемом формате, а оттуда должна будет приехать уже матчасть, но опять же с соответсвующей сопроводительной документацией и тоже в привязке к ЭСИ.

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

Специально для обмена информацией между поставщиками разработаны на западе стандарты (формы) обмена информацией. У нас в России ни кто эти стандарты выработать не может, так как везде есть заумные IT отделы, которые между подразделениями своей компании обмен устроить пытаются (все у нас с ног на голову).

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

Для справки - стандарты CALS разработаны изначально для решения проблем обмена информацией между поставщиками в оборонной отрасли США.

Объясните, что за "таковой подход"? И какие 10 отличий я должен найти, в чем?

А что нам помешает

1. выделить технический перерыв, например, совпадающий с обеденным, специально для обновления хранилищ ещё и в дневное время?

2. организовать те самые комплексные конструкторско-технологические бригады, в которых документация будет согласовываться в одном хранилище вплоть до её утверждения и помещения в "электронный сейф единой базы знаний"?

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

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

"электронный сейф единой базы знаний" - что это? Шутите? Сами изобрели?

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

Да конструктор и так занимается конструированием.

Ну понятно, технологи не люди же. Пусть сами создают, сами цепляют.... Зачем тогда вся эта автоматизация? Чтоб потом косяки все на технологах зависали, да и технологическая подготовка так же все тормозила? Ну да, в этом случае может показаться что конструктор в шеколаде.....До определенного момента. Предприятие только в пролете...

Советую почитать книгу "Бережливое производство." Как избавиться от потерь и добиться процветания вашей компании. (Джеймс Вумек, Дэниел Джонс).

Она переиздается достаточно часто. По моему последняя 2008 г.

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

[Странник 6]

Ну, хоть в одном мы уже точно с Вами сошлись. Да действительно, "Пути прохождения этих документов собственно WORKFLOW и определят." Только не "определяет", а копирует существующий на предприятии документооборот. Зачем? Что WORKFLOW ускорит, прохождение документов? Люди станут быстрее ставить флажки в окошках системы? Нет, они сначала стайками на совещаниях будут собираться, а потом уже эти флажки ставить. Это пустая трата времени без реорганизации бизнес-процессов. Это мы проходили...

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

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

К тому же, совещание легко может быть реализовано посредством web-конференции, не так уж это технически сложно и дорого реализовать.

Специально для обмена информацией между поставщиками разработаны на западе стандарты (формы) обмена информацией. У нас в России ни кто эти стандарты выработать не может, так как везде есть заумные IT отделы, которые между подразделениями своей компании обмен устроить пытаются (все у нас с ног на голову).

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

Чем не подходят для информационного обмена между подразделениями и даже предприятиями ИИ, ПИ, карточки отступлений, служебные записки, распоряжения, приказы и договоры?

Неужели так велика проблема согласования формата атрибутов?

Объясните, что за "таковой подход"? И какие 10 отличий я должен найти, в чем?

Для варианта внутри одного предприятия алгоритм примерно такой:

1. по факту получения приказа о начале работ по новой теме конструктор разрабатывает КД, согласовывает её с ОГТ и нормоконтролем, передаёт подлинники в БТД (сейф) и докладывает о выполнении руководству. Дальнейшая работа конструктора сводится к поддержанию разработанного изделия в работоспособном и конкурентноспособном состоянии, а также консультации производства/потребителя по техническим вопросам.

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

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

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

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

А меня, как конструктора, эти проблемы и не касаются, ну никаким боком.

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

"электронный сейф единой базы знаний" - что это? Шутите? Сами изобрели?

Шутить не люблю.

Да конструктор и так занимается конструированием.

Ну понятно, технологи не люди же. Пусть сами создают, сами цепляют.... Зачем тогда вся эта автоматизация? Чтоб потом косяки все на технологах зависали, да и технологическая подготовка так же все тормозила? Ну да, в этом случае может показаться что конструктор в шеколаде.....До определенного момента. Предприятие только в пролете...

А вот и ключевой момент, при чём в классической форме.

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

-снабжению,

-комплектации,

-инструментальному отделу,

-отделу нестандартного оборудования,

-...

Контроль качества готовой продукции опять же будет вестись по КД.

Интересно, откуда берётся мнение, что конструктор должен строить технологические модели, то бишь формировать КД под техпроцесс, которого к тому же в это время и в принципе то не может ещё быть?

[VOleg 228]

Похоже внедрение постепенно переходит в "обсуждение" "кто и чем занимается". Это неправильно.

Я так думаю.

[Странник 6]

Ну понятно, технологи не люди же. Пусть сами создают, сами цепляют.... Зачем тогда вся эта автоматизация? Чтоб потом косяки все на технологах зависали, да и технологическая подготовка так же все тормозила? Ну да, в этом случае может показаться что конструктор в шеколаде.....До определенного момента. Предприятие только в пролете...

Не далее чем сегодня видел как технолог чуть не со слезвми на глазах утверждала начальнику IT отдела, что не знает как должно запивывать по ГОСТ обозначения болтов-винтов-шурупов.

Ситуация просто классическая: технологов хлебом не корми, а дай прикинуться дураками, ибо они рассуждают просто

за умение думать не платят.

Похоже внедрение постепенно переходит в "обсуждение" "кто и чем занимается". Это неправильно.

Я так думаю.

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

[vl 327]

за умение думать не платят.

Надо чтобы за НЕ умение думать НЕ платили бы. Проверки на профпригодность? Хотя бы пользование компьютером.

[Странник 6]

Надо чтобы за НЕ умение думать НЕ платили бы. Проверки на профпригодность? Хотя бы пользование компьютером.

Замечательная мысль, спасибо.

[VOleg 228]

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

Схема-то работает?

[Странник 6]

Схема-то работает?

Ну я же пока не генеральный директор и даже не главный конструктор.

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

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

Кроме того, можно ещё раз подивиться мудрости Р.Л.Бартини, что говорил о большом опытном заводе и маленьких КБ вынесенных как бы в самостоятельные предприятия... действительно иначе появляется культ личности "самого большого пупка" со всегдашним

спячка-раскачка-горячка-наказание невиновных-награждение непричастных.

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

Есть и кое-что ещё.

[VOleg 228]

Ну я же пока не генеральный директор и даже не главный конструктор.

Жаль...

А вот я как раз "главный" и у меня работает... правда есть еще владелец.... хххххххх, соответственно....

Так что на каждую умную задницу всегда найдется.....

Т.е. получается замкнутый круг и никому это не надо...

Ну, можно, конечно воду в ступе потолочь...

[Странник 6]

Жаль...

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

Т.е. получается замкнутый круг и никому это не надо...

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

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

[VOleg 228]

Разделение структуры предприятия на классическое производство, например, ОАО и выведенные в хотя бы ДОАО конструкторские подразделения хорошо

Так Вы этим сейчас и занимаетесь?

[Странник 6]

Так Вы этим сейчас и занимаетесь?

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

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

[Елена 116]

Отделение предприятий от конструкторов - плохо. Начинается дележ заслуг уже на финансовом уровне между организациями.

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

А завод в технологиях должен ориентироваться на профиль КБ. Внедрение технологий - это достаточно трудоемкий процесс и должен проводиться совместно.

Иначе теряют в результате и те и другие. КБ начинает бегать от одного завода к другому. Конструктора разбегаются по другим КБ. В результате теряют все.