Внедрение PLM

[Дмитрий22 1]

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

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

Не так ли?

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

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

[Дед Мороз 3]

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

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

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

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

PS

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

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

Изменено 10 сентября 2012 пользователем Дед Мороз

[Дмитрий22 1]

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

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

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

[Елена 116]

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

[Дед Мороз 3]

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

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

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

Словами:

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

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

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

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

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

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

Изменено 4 сентября 2012 пользователем Дед Мороз

[Дед Мороз 3]

Благодарность нашего КБ!

[Дед Мороз 3]

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

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

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

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

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

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

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

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

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

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

Изменено 7 сентября 2012 пользователем Дед Мороз

[Дед Мороз 3]

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

Дмитрий22

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

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

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

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

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

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

Изменено 7 августа 2012 пользователем Дед Мороз

[Елена 116]

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

[Елена 116]

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

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

[streamdown 1 565]

Елена

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

[Елена 116]

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

[streamdown 1 565]

Елена

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

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

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

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

[Елена 116]

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

[streamdown 1 565]

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

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

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

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

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

[Дед Мороз 3]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛОЦМАН 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-модель КОМПАС" ... отсутствует !!!

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

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

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

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

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

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

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

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

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

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

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

PS

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

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

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

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

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

[Дед Мороз 3]

<noindex>Всем спасибо!</noindex> http://mashportal.ru/interview-27765.aspx

Интересные статьи

<noindex>Проблемы и особенности оценки соответствия оборонной продукции (работ, услуг) и связанных с нею процессов установленным требованиям</noindex>

<noindex>Концепция жизненных циклов: необходимо ли ее понимание и применение финансистами на российском рынке?</noindex>

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

[Дмитрий22 1]

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

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

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

[Дед Мороз 3]

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

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

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

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

...

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

...

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

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

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

Изменено 5 июня 2013 пользователем Дед Мороз

[NGM 267]

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

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

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

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