PLM(Ann)

Внедрение PLM

102 сообщения в этой теме

А почему материал в дереве попал раньше стандартных изделий? И почему дерево не отсортировано по ГОСТ?

По-моему, дерево должно ПОЛНОСТЬЮ отражать спецификацию. Т.е. дерево и должно быть спецификацией только без названий разделов (уже давно никому не нужных).

Не так ли?

Вот и будет максимально информативно!

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

необходимо было найти преобразование, сворачивающее обратно в изначальный объект СИ его раздвоение КОМПАСом

новейшим методом PingWin замечена команда "Исключить из расчета", которая, в частности, сохраняя крепежные изделия в 3D модели (полученные из справочника СИ) побочно блокирует их передачу в дерево ЛОЦМАН. Используя указанный побочный эффект, когда нужно, конструктор всегда сохранит в модели КОМПАС элемент (экземпляр объекта со всеми значениями его атрибутов) с типом "крепежное изделие" из СИ, равно когда конструктор возвращает или берет в работу архивные файлы документов и моделей ЛОЦМАН, что и чем по собственному усмотрению может исключать дублирование сущности объекта из модифицированного отчета "Ведомость крепежных изделий" ЛОЦМАН.

Ведомость построена, проверена :g: Преобразование свертки в ЛОЦМАН раздвоения сущности крепежного объекта КОМПАСом обнаружено.

Разработчики КОМПАС молодцы... ведь как-то сдали свои тесты ? :throw: Чувствовал ... найду их позицию - получу отчеты :rolleyes:

PS

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

post-30704-1342503997_thumb.png

Ведомость_крепежных_изделий_-_РЕЗУЛЬТАТ_АВТОМАТИЧЕСКОЙ_ГЕНЕРАЦИИ_ОТЧЕТА.doc

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пару соображений по поводу WorkFlow.

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

Если говорить о нашей фирме, то на данный момент мы имеем одну проблему: главный конструктор задает вопрос конструктору, готова ли сборка, ответ - готова. На самом деле она готова только им, но подписей проверяющего и технологов на ней нет. После чего начинается конфликт. Гл. констр. понимает слово "готово" это когда ему кладут на стол для утверждения чертеж, конструктор понимает "готово" когда он отдал проверяющему свой чертеж на подпись. Из-за этого начинают срываться сроки выхода документации, сроки запуска произв. и т.п. Поэтому и пришла в голову мысль разделить процесс выхода чертежа на составляющие. Итак, схема (см. рис). Здесь все просто. Инициатор бизнес процесса запускает его. Задает исполнителя, проверяющего (у нас проверяющий и нормоконтролер одно и то же лицо), срок проектирования, срок проверки, срок утверждения технологом, даже срок утверждения гл. конструктором (хотя это можно задать прямо в шаблоне бизнес-процесса, например 2 дня). Инициатор может в процессе работы менять исполнителя, сроки. Гл. конструктор все изменения видит, т.к. он находится в списке контролеров любых запущенных бизнес-процессов на предприятии. Если конструктор не успеет в срок выполнить задание, его блок будет выделен красным цветом. Все достаточно наглядно и интересно. Есть соблазн усложнить данную схему введением условий типа: проверяющий проверил, все нормально? Если нет, то вернуть на доработку конструктору, но я пока не хочу усложнять схему, боюсь, что конструктора только и будут друг другу пересылать информацию о состоянии объекта. Сейчас данную схему обкатываем на предприятии. О результатах сообщу позже.

post-35936-1342962104_thumb.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

В прикреплённом примере нет покупных крепежных изделий... но нет и спецтехники.

Словами:

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

- Странно выглядит?

- Не очень :doh: потому что в итоге ... весь Комплекс по КД работает как надо :velho:

применяем "Ведомость покупных изделий" с замечанием, когда покупное изделие единственное в изделии... как в примере :boxed: (сдвиг строки вправо).

PS Видно, что изделие покупное, когда принадлежит разделу спецификации "Прочие изделия", тип объекта в примере - "Деталь".

Теперь то же относится к любому крепежному изделию, если именовать его с заменой символа. Тип данных "Крепежное изделие" изящно исключён из всех отчётов без остатка, удвоение КОМПАСом объекта СИ при передаче его в дерево ЛОЦМАН передано на усмотрение конструкторов.

:clap_1:

post-30704-1343044204_thumb.png

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Показанные выше результаты среди прочего были получены весной 2008 года и... законсервированы. Расконсервировано весной 2011 года :)

Весной 2010 года на другом предприятии внедрял Комплекс 2009, где 14 человек были сертифицированно обучены ЛОЦМАН в АСКОН, а пилотный проект терпел фиаско.

Это (плюс три дополнительных) проверочное соотношение оказалось решающим для выступления сначала на форуме АСКОН, а затем здесь ... по многим причинам.

Как получается, что в 2010 году

главные руководители, которые входили в группу внедрения новейшего на тот момент Комплекса 2009, настаивали на внедрении схем, которые описал Дмитрий22 ?

Доводы специалистов группы внедрения с опытом, номенклатурно развернувшие новые качества Комплекса 2009, блокировались как заведомо фантазийные. Иными словами, что это за "традиции машиностроения", а именно - "верните всё взад", когда сплетни в курилке значат больше, чем документация и факт соответствия?

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

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

На весну 2012 года инновация "традиционна": <noindex>сами создадим себе проблему, сами героически будем её решать</noindex>

Меня учили и я учусь и иногда учу по известным традициям :poster_dont: когда на первом месте - компетентность, и на втором - порядочность... остальное - всё может быть.

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итак, схема (см. рис). Инициатор бизнес процесса запускает его. Задает исполнителя, проверяющего (у нас проверяющий и нормоконтролер одно и то же лицо), срок проектирования, срок проверки, срок утверждения технологом, даже срок утверждения гл. конструктором (хотя это можно задать прямо в шаблоне бизнес-процесса, например 2 дня). Инициатор может в процессе работы менять исполнителя, сроки. Гл. конструктор все изменения видит, т.к. он находится в списке контролеров любых запущенных бизнес-процессов на предприятии. Если конструктор не успеет в срок выполнить задание, его блок будет выделен красным цветом. Все достаточно наглядно и интересно. Есть соблазн усложнить данную схему введением условий типа: проверяющий проверил, все нормально? Если нет, то вернуть на доработку конструктору, но я пока не хочу усложнять схему, боюсь, что конструктора только и будут друг другу пересылать информацию о состоянии объекта. Сейчас данную схему обкатываем на предприятии. О результатах сообщу позже.

Дмитрий22 :g:

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

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

Здесь нужно придерживаться метода программирования "снизу-вверх".

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

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

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

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще, про свой опыт внедрений. В 97-м мы купили Т-Flex и Гемму 5-й версии. Через год умирает мамин старший брат. Он раньше работал военпредом на одном заводе. Через четыре года, когда нам наконец одну копию T-Flex оплатили обновление с 5-й до 7-й 3D буквально через одну-две недели в Кронштадте машина сбивает насмерть его старшего сына, еще через 4 года, когда мы опять обновили T-Flex и Гемму и решили вопрос проектирования и изготовления СТО с 3D на российских САПРах и в 2005- побывали в ОТД Хруничева, где внедряли Лоцман, умирает мой отец накануне восьмого марта. Но самое интересное, следом умирают еще двое, кто его встречал в Улан-удэ - его двоюродный брат и его жена. А на заводе наш ГБист предлагает мне внедрять Лоцман и идет грязная поставка SolidWorks. Кому понадобилась такая обработка специалиста, который занимается задачами САПР и документооборота на предприятии Роскосмоса. Я думаю, что специалисты Аскона и Solid Works знают с кем они вели переговоры на СПЗ и на каких условиях. У меня поубивали всех мужчин из семьи старшего возраста, кто мог бы оказать поддержку, а у меня две дочки и муж с Украины. Да и попутно на меня еще и компроматы собирали.

Да, T-Flex мы покупали и Обновляли в Векторе у Лихачевых, Гемму в 97-м в Векторе, в 2004-м в Аэроконе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Елена

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Елена

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

на меня еще и компроматы собирали.

Вам очень близок по духу топикстартер <noindex>http://fsapr2000.ru/index.php?showtopic=55369</noindex>

Почему вы с ним не общаетесь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я считаю, что на протяжении как минимум 15 лет ( с 91-го по 2005-й) определяла политику в области информационных технологий в ОГТ предприятия, в силу своей компетентности и некомпетентности в этой области руководства, даже находясь на должности просто инженера. Нет всю цепочку я от себя убрала. А когда так вокруг по-умирали убрала и ответственнось за покупку софтов (единственное T-Flex на 10 лицензий купили, я настояла, так как работали уже давно, хотя их заставляли пересаживаться на SolidWorks). Разработку документооборота и Cапров техпроцессов взяла на себя (свое подразделение). Покупать не будем. В 97-м году заплатили хорошую сумму (при курсе 6 рублей за доллар) - где-то 100 с лишним тысяч за T-Flex, Инис, Гемму и Calcomp - струйный (т.е больше 16000 $). Так просто никто деньги не даст. В 97-м мне дал указание бывший главный инженер Ламакин - что купить, а дальше каждую копию приходилось очень долго обосновывать, выслушивая оскорбления, каких я до этого за свою почти 40-летнию жизнь ни разу не слышала. Разбираться приходилось мне и моему мужу. Так вот к тому подлецу, которого здесь за заслуги перед отечеством наградили, я близко не подойду.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

определяла политику в области информационных технологий в ОГТ

Тема: "Внедрение PLM, Процесс внедрения".

Я почему и уточнил

непосредственно вы способны завернуть ВСЮ цепочку бизнес-процессов

А так - всё ясно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Я считаю, что все эти совпадения не случайными.

Совпадения не случайны. Возможно также, что они случайны не совсем так, как кажется.

Вот это, всё-таки, неспешно рассматривается... Елена, мы Вас слышим. Последовательность утверждений очень важна.

Вы правы, внедрение не только вопрос технического перевооружения.

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

Методология внедрения сильно зависит от результатов проверки продукта на соответствие (по правилам испытаний).

Является ли эта зависимость частью интеллектуального продукта ?

Как меня учили, начиная с Прикладной математики МАИ - является.

Рабочее место проектировщика на заводе - не испытательный стенд... Набор тестов определяет методику и эксплуатацию ПО.

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

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

Мы все дружно что-то пропустили, начиная с перестройки СССР, приватизации, дефолта РФ ?

В таком случае Покупатель вправе, а Продавец - обязан... и ни в чём не наоборот !

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

Возможно, Елена, Вы не так далеки от истины, как кажется. Невозможное возможно, если системные ошибки скрываются сознательно.

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

Понятно, что АСКОН ищет во всём только собственную выгоду.

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

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

Сегодня каждое КБ в части собственных представлений о "законности" ответственности, смеживает право. АСКОН - не КБ?

Если так, пусть каждое КБ готовит себе кадры собственно (Английская модель), тогда или пусть ВУЗы профильно учат КБ (Американская модель). Этот умозрительный эксперимент обезличивания чъё мечущееся воображение столь мощно поразил? Он реально мешает учить студентов правильно, обученные не правильно кадры - не работают, а заняты самореализацией. Тем же страдают вследствие КБ, а ... "чай" был, есть и будет.

ЛОЦМАН 8.5 отлично объективизирует множественные отношения и нормирует смеживание, отбрасывая документы c инструментальными ошибками, например КОМПАС, на исправление. Концепция ЛОЦМАН смотрит через настоящее в будущее. А вот КОМПАС, включая V13, не поддерживает даже конфигурирование изделий с группой замен, реализованное в ЛОЦМАН. Значит, КОМПАС не мыслится его разработчиками как потенциальный элемент бизнес-процесса, он где-то "в небесах и даже вне", вне зависимости, какая PLM/PDM. Я показал: сначала на форумах АСКОН - виртуальном и реальном в 2011 году и частично, здесь сейчас - как и почему в нашем КБ конфигурирование изделия востребовано. Более того, внедрение рвануло вперёд когда конструкторы убедились в работоспособности именно метода конфигурирования, благодаря ЛОЦМАН, что "тянет" c собой новые, свежие технологические концепции. Уже не вопрос - "как тестировали", и даже не "что тестировали". Другой вопрос, который, большей частью, не только АСКОН.

На этом кончим...

замечание по методу конфигурирования изделия Комплексом и является причиной забанивания и оскорбления меня на форуме АСКОН его владельцами.

В реакциях на мои выступления "Герои форума" АСКОН не смогли продвинуться дальше пифагорейского первопринципа математического порядка. Зато необоснованных обвинений в "троллинге", грубости и самоуправства на форуме сверх всякой меры. Это явление позволяет мне, уважая школу Платона, выразить невосхищение форумом АСКОН, его содержанием и порядком функционирования.

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

Только улыбка Чеширского кота исчезает...

Известное всем математикам и недоступное профанам чувство математической красоты до такой степени, что они часто склонны смеяться над ним, "специальное эстетическое чувство играет роль решета, и этим объясняется, почему тот, кто лишен его, никогда не станет настоящим изобретателем" [8]

стр.106 Котина С.В. Поиск красоты. Москва. 2002. Издательство "Вестком"

Спасибо

Илларионову С.В. за <noindex>Система методологических принципов в научном познании. М. 1989</noindex>

Иванову Н.А. за курс <noindex>ФИЛОСОФИЯ БОЛЬШЕСИСТЕМНЫХ ИССЛЕДОВАНИЙ</noindex>

"Идеология машиностроения" или, даже, некоторые смелеют до, "философия машиностроения" выглядит, очевидно, следующим образом:

<noindex>CAD/CAM/CAE Observer #5 (35) / 2007 </noindex> о внедрении на ЗАО "ВАГОНМАШ"

Обратите внимание на состав дерева в Комплексе, полученный в 2006-2007 году, а именно

- объекты "Крепежные изделия" ... откуда попали в сборку, если

- объект "Спецификация" и объект "Сборочный чертеж" есть ... а объект "3D-модель КОМПАС" ... отсутствует !!!

Ладно, глюк объектной модели КОМПАСа поймали -> врукопашную в ЛОЦМАН состав изделия завели --> но... тогда... что было получено в дерево из Спецификации, как по азам построения дерева положено ? Куда не кинь - клин, а точнее - красивая и простая подделка.

Как работают фактические бизнес-процессы КБ ЗАО "ВАГОНМАШ", если отчётные формы по КД не упоминаются даже... по-студенчески... :flush:

Цена всей этой "*логии", одним словом, по древне-гречески - тщеславие. Знаете, что за такой случай сделали в Японии ?

Что, всё-таки, мы оплатили ?

Деньгами, личным и рабочим временем, иерархией в коллективе, отчётами наверх ... правильно Елена говорит - жизнями ?

Все вышесказанное не столь важно, как:

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

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

Случай окружён открытием, суть которого я обещал рассказать п.2 сообщения #29 этой темы, но воздержусь... полагая, что методология окружения отстала на 11-12 лет от фактических внутренних возможностей РФ. Учить "учёных" - оскорбления выслушивать, а рассказать о хорошем внедрении пока, видимо, некому. За красивым фасадом мероприятий АСКОН даже не скрываются непроходимая дремучесть, затянутость и безинициативность. На протяжении пяти наблюдаемых лет стиль компании не меняется. Приятного мало...

... только потому, что в вышеупомянутой статье (за 2007 год)

упоминается успешное внедрение АСКОН на Уралвагонзаводе: <noindex> "Уралвагонзавод" и "Сименс" внедрят 
концепцию жизненного цикла изделий</noindex>

PS

<noindex>Принцип детекции достоверных сведений о бизнес-процессах</noindex> (вздох-шутка: читается на вдохе, обдумывается на выдохе...):

данные от инициаторов воспринимайте противоположно

данные от аудиторов в части данных от инициаторов воспринимайте противоположно (дискурсивно)

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

post-30704-1345115415_thumb.png

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Итак, инициатор бизнес-процесса (как правило поверяющий) запускает процесс, показанный на приложенном рисунке.

post-35936-1369839419_thumb.jpg

Инициатор прикрепляет к процессу объект в Лоцмане, который необходимо наполнись конструкторской документацией, при этом указывает разработчика, срок выполнения КД, задание. Особенно удобно то, что теперь, когда гл. конструктор подходит с вопросом, "что ты ему поручил?", я ссылаюсь на созданный бизнес-процесс - там все написано(аудитором процесса гл. конструктора я оставил). Разработчик когда закончил чертеж нажимает кнопку и процесс переходит к проверяющему. Автоматически объект в Лоцмане меняет состояние. Было - "Проектирование", стало - "Согласование". Проверяющий, если находит ошибки в проекте, ПЕРЕВОДИТ объект в состояние "Проектирование" и заявляет об окончании проверки. Бизнес-процесс видит, что объект опять изменил состояние на "Проектирование", снимает статус "Выполнен" со всех участников процесса и отправляет процесс опять разработчику. И так по кругу пока проверяющий не перестанет менять состояние объекта в "Проектирование". Технолога и Гл. конструктора мне пришлось из бизнес-процесса убрать, хотя не сложно данный алгоритм распространить еще на 2-х человек, просто надоело бегать за ними и отмечать выполнения их этапов проверки. Это реальность. Хотелось, конечно, чтобы проверяющий не вручную менял состояние "Согласование" состояние "Проектирование" при нахождении ошибок, а чтоб объект сам переводился при нажатии на кнопку "Есть вопросы", но обработчика событий на эту кнопку я не нашел. Будем искать. Вот как-то так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот как-то так.

Да, вполне возможный и работоспособный бизнес-процесс :clap_1:

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

цитирую В.А.Моляко по книжке "Психология конструкторской деятельности", Машиностроение, 1983

...

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

...

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

Повальное непонимание руководителями систем САПР на внешней стороне этого явления приводит к нарушениям порядка комбинирования сроками, что часто характеризуется как самоуправные действия и решения; иными словами, мнимое или действительное нарушение правил и порядка, установленного законом, обычаем, инженерно-типовым решением, или отрицание их сущности. (С) Дед Мороз, 2013

Выглядят такие явления как частные и в рамках видимости обсуждаются как личные отношения, в то время как на самом деле это системные общегражданские разрезы. (С) Дед Мороз

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Хотелось бы пару уточнений:

1. Неужели исполнитель самостоятельно изменяет статус документа? Система не может делать этого автоматически по завершению процесса?

2. Не увидел ни одного слова про подписание документов и считаю сие очень странным. В Лоцмане какая-то своя интерпретация подписи? А как там ЭЦП и все такое?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Неужели исполнитель самостоятельно изменяет статус документа? Система не может делать этого автоматически по завершению процесса?

2. Не увидел ни одного слова про подписание документов и считаю сие очень странным. В Лоцмане какая-то своя интерпретация подписи? А как там ЭЦП и все такое?

Вопросы содержат несколько вариантов ответов.

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

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

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

Что касается ЭЦП, то у меня встречный вопрос - какой должен быть бюждет проекта и зарплата членов группы внедрения, что бы все востребовали столь осторожную функцию ? Моё мнение, что эта функция необходима, но её применение должно быть обосновано.

Следствие: без понимания нет управления

(кажется просто, а встречается крайне редко)

<noindex>ТЕХНОЛОГИЯ МАШИНОСТРОЕНИЯ: С КОМПЬЮТЕРОМ, НО БЕЗ САПР. РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ АСКОН</noindex>

post-30704-1371732040.jpg

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что касается ЭЦП, то у меня встречный вопрос - какой должен быть бюждет проекта и зарплата членов группы внедрения, что бы все востребовали столь осторожную функцию ? Моё мнение, что эта функция необходима, но её применение должно быть обосновано.

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

Мой вопрос касался гораздо более глобальной стороны - как однозначно идентифицировать электронный документ в системе, который является подлинником? Не спорю, что для этого есть разные пути - специализированные архивы, этапы ЖЦ. Кроме этого, многие системы PDM имеют функционал "внутренней подписи", которая может не соответствовать на 100% ГОСТ Р 34.10-2001, но благодаря грамотно оформленному и утвержденному регламенту/стандарту предприятия вполне себе признается за законный вариант.

Все таки, как решается в Лоцмане вопрос утверждения документа. Или по-старинке - ножками, ручками?...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хотелось бы пару уточнений:

1. Неужели исполнитель самостоятельно изменяет статус документа? Система не может делать этого автоматически по завершению процесса?

2. Не увидел ни одного слова про подписание документов и считаю сие очень странным. В Лоцмане какая-то своя интерпретация подписи? А как там ЭЦП и все такое?

1. Читайте внимательно, где написано "Автоматически объект в Лоцмане меняет состояние".

2. ЭЦП есть в Лоцмане, но нужно настраивать. Ее пока не внедряли. Руководству не нравится, что подпись не вставляется внутрь штампа. Сейчас над этим работаем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

подпись не вставляется внутрь штампа

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мой вопрос касался гораздо более глобальной стороны - как однозначно идентифицировать электронный документ в системе, который является подлинником? Не спорю, что для этого есть разные пути - специализированные архивы, этапы ЖЦ. Кроме этого, многие системы PDM имеют функционал "внутренней подписи", которая может не соответствовать на 100% ГОСТ Р 34.10-2001, но благодаря грамотно оформленному и утвержденному регламенту/стандарту предприятия вполне себе признается за законный вариант.

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

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

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Любой электронный документ электронного архива - подлинный и единственный.

Кто вам такое сказал?! Если сие не прописано в стандарте предприятия, то эти слова не имеют вообще никакой силы. А до стандарта систему нужно еще довести.

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

Мне непонятно - а для чего вставлять в контекст данного поста описание стандартного функционала любой PDM-системы?

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

Я считаю, что правильная постановка вопроса - не "сколько?", а "чьи?". У нас в технологиях присутствует полный комплект электронных подписей всех участников процесса согласования, в среднем выходит порядка 10 штук. Из них "важными" являются три. Все, что далее объяснять правов не имею - вторая форма доступа, гостайна, консалтинг и все прочее :smile:

P.S. Разработчиков у конкретного документа не много, он один. Не мешайте все в кашу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

P.S. Разработчиков у конкретного документа не много, он один. Не мешайте все в кашу.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

:thumbdown:

Любой электронный документ электронного архива - подлинный и единственный.

Кто вам такое сказал?! Если сие не прописано в стандарте предприятия, то эти слова не имеют вообще никакой силы. А до стандарта систему нужно еще довести.

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

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

:surrender:

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

Аналогично тому как не следует смешивать "этот дом" и "право на этот дом", подобно не следует смешивать обработку информации, содержащейся в документе, с обработкой самого документа. Ещё раз, дано: стандартность модели PDM влечет стандарт понимания.

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Любой электронный документ электронного архива - подлинный и единственный.

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

Сказки "внидрентцеф".

Выходим в цех, подходим к станку, обнаруживаем, что технология не соответствует экземпляру в электронном архиве. Спрашиваем у инженера по техобеспечению участка:"Что за фигня?" Получаем ответ:"Покажите СТП, в котором указано, что я обязан проверять соответствие электронного и бумажного документа". Если такого СТП нет - мы посланы куда подальше.

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

Сие необходимо принять как закон физики/информатики/божий/космический/какой угодно

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

Ссылки на закон (-ы) в студию. ГОСТ-ы, стандарты, нормативы, да что угодно. В противном случае - треп.

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

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

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

А система PDM на то и предназначена, чтобы управлять как содержанием документа, так и его статусом. Попробуйте изменить утвержденный чертеж (управление содержанием документа), не выпустив в любом виде извещение и не изменив его статус (управление документом). Ваша система позволит сделать такое? Если да - это не PDM, а обычная свалка документов.

Ещё раз, дано: стандартность модели PDM влечет стандарт понимания.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Стоп!

PDM придумал Сталин: "незаменимых у нас нет" :bleh:

Извините :clap_1:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это все, что можете сказать по существу?

Вопросов больше нет.

С манагерами, тиражирующими макулатуру "Внедрите PDM и станете богатым", общаться интереса нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Читаю, читаю и признаюсь уже совсем не понимаю всех этих хитросплетений.

Так вот, у кого нибудь есть методика внедрения, хотя бы общие слова дабы понять о чём речь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Читаю, читаю и признаюсь уже совсем не понимаю всех этих хитросплетений.

Так вот, у кого нибудь есть методика внедрения, хотя бы общие слова дабы понять о чём речь?

Методика есть у всех.

Только одни стремятся к ней, другие - от неё :wub:

Ссылки на закон (-ы) в студию. ГОСТ-ы, стандарты, нормативы, да что угодно. В противном случае - треп.

Треп в том, что никем не указано, что я нарушил. Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Читаю, читаю и признаюсь уже совсем не понимаю всех этих хитросплетений.

Так вот, у кого нибудь есть методика внедрения, хотя бы общие слова дабы понять о чём речь?

Методика внедрения PDM по большей части универсальна и выглядит примерно следующим образом:

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

2. Ставится цель (-и) проекта внедрения. "Сократить сроки подготовки производства". "Унифицировать применяемые материалы". "Автоматизировать разработку изделий". Нет цели - нет проекта.

3. Формируется перечень технических требований к системе.

4. Анализируется рынок на предмет соответствия требований и функционала PDM, уровню взаимодействия с применяемыми CAD, CAM и каких там еще системами.

5. Выбирается конкретная система и фирма-внедренец, заключается договор, составляется ТЗ и другая проектная документация.

6. Система адаптируется, дорабатывается, допиливавается. Параллельно с этим проводится опытная эксплуатация.

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

8. Шампанское, девочки, лимузины...

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

Треп в том, что никем не указано, что я нарушил.

Ок, готовьтесь, будет больно.

Ваши электронные модели на 100% соответствуют ГОСТ 2.052-2006? Если нет, то где прописаны отклонения?

Ваша система документооборота и ее описательная часть на 100% соответствуют ГОСТ Р 53898-2010? Опять же - если нет, то где отклонения?

Ваши электронные документы содержат полный набор атрибутов по ГОСТ 2.104-2006?

Ну это так, для начала.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо,

Следующий вопрос, сейчас о чём идет спор? О том что называется единственно правильным и достоверным документом или о том что имея на предприятии PDM систему никто не обязан в ней работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ок, готовьтесь, будет больно.

Ваши электронные модели на 100% соответствуют ГОСТ 2.052-2006? Если нет, то где прописаны отклонения?

Ваша система документооборота и ее описательная часть на 100% соответствуют ГОСТ Р 53898-2010? Опять же - если нет, то где отклонения?

Ваши электронные документы содержат полный набор атрибутов по ГОСТ 2.104-2006?

Ну это так, для начала.

странный Вы человек :wub:

укажите конкретно, какие ошибки Вы обнаружили в наших моделях, системе, содержании документов ?

Спасибо,

Следующий вопрос, сейчас о чём идет спор? О том что называется единственно правильным и достоверным документом или о том что имея на предприятии PDM систему никто не обязан в ней работать?

в данную минуту спор ни о чём... NGM ругает мироздание за то, что не знает и знать не может :bleh:

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

странный Вы человек :wub:

укажите конкретно, какие ошибки Вы обнаружили в наших моделях, системе, содержании документов ?

Меня ваши модели и система не волнуют.

Меня коробят утверждения:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Меня ваши модели и система не волнуют.

Меня коробят утверждения:

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

Солнце встает на Востоке и садится на Западе. Коробит ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо,

Следующий вопрос, сейчас о чём идет спор? О том что называется единственно правильным и достоверным документом или о том что имея на предприятии PDM систему никто не обязан в ней работать?

1. "Правильность" и "достоверность" документа (бумажного, электронного) устанавливается стандартом предприятия. Если таковой отсутствует - руководствуются действующими нормами ГОСТ. Для мелких контор такие тонкости не обязательны - там каждый самоудовлетворяется так как соизволит быть нужным.

2. "Использовать или не использовать PDM на предприятии" решает руководство предприятия. Практика показывает, что если руководство не относится к вопросу серьезно и спускает его на тормозах - система не используется. А если руководство ставит эту задачу как приоритетную - система используется. Оттенков серого здесь быть не может.

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

Солнце встает на Востоке и садится на Западе. Коробит ?

Нет. В Норильске оно вообще несколько месяцев не появляется.

Слабо, очень слабо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В разрыве от реального предприятия такие разговоры вообще бессмысленны.

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

Что же отражает интересы предприятия?

Документ правильный, если он успешно прошёл нормоконтроль, далее - другие формы контроля. На практике никакой документ не является "правильным" ни изначально, ни окончательно.

Руководство может изменять точку зрения. Нет ?

Изменено пользователем Дед Мороз

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!


Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.


Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу

  • реклама

  • Реклама

  • Ближайшие события

    Предстоящих событий не найдено
  • Дни рождения сегодня

    1. Closius
      Closius
      (30 лет)
    2. DoLiN_SW
      DoLiN_SW
      (35 лет)
    3. kamagra_online_buy
      kamagra_online_buy
      (43 года)
    4. kamaz
      kamaz
      (35 лет)
    5. ppkpo
      ppkpo
      (76 лет)
    Просмотреть все