Вы находитесь на странице: 1из 7

МАШИНОСТРОЕНИЕ

С чего
начинается
АСТПП НЕТИПОВЫЕ РЕШЕНИЯ НА БАЗЕ СИСТЕМЫ TechnologiCS

азалось бы, название статьи тизированной системы технической  Технологическое проектирование и вы

К обязывает авторов сообщить о


том, с чего начинается
АСТПП, нечто принципиаль
но новое. С другой стороны, искушен
ный читатель резонно заметит – что еще
подготовки производства (АСТПП) на
крупном машиностроительном пред
приятии, которое уже было упомянуто в
предыдущей статье1 как одно из веду
щих в области авиационного агрегато
пуск документации – требуется обес
печить возможность параллельной
работы цеховых технологических бю
ро со "своими" техпроцессами, а так
же предусмотреть эффективные ме
здесь может быть нового? Внедряемая на строения. ханизмы согласования действий под
предприятии система уже предполагает Предприятие относится к отрасли, разделений в процессе разработки и
типовые способы решения задач, харак сильной своими традициями. Более того, проведения изменений. В ряде случа
терных для автоматизируемой области. А эти традиции помогли сохранить его ев требования безопасности ограни
принятое решение об использовании си "технологическую устойчивость" в усло чивают доступ к информации (в том
стемы подразумевает, что предприятие с виях быстро меняющейся рыночной сре числе на просмотр) смежных участ
этими типовыми способами согласилось ды и, соответственно, обеспечить требуе ников процесса.
и остается их только внедрить. мый уровень качества продукции. Таким Анализ данных требований вызвал
Тем не менее, оба этих утверждения образом, автоматизация подготовки про серьезные сомнения относительно воз
не вполне соответствуют истине. Конеч изводства прежде всего должна сохра можности применения стандартных под
но, в процессе построения АСТПП мы нить преемственность традиций – мы не ходов, предлагаемых системой
всего лишь используем уже разработан имеем права устраивать революции. С TechnologiCS.
ную систему и ничего кардинально ново другой стороны, переход к "электронно Традиционно для управления соста
го в ее устройство внести не можем. С му" проектированию и выпуску докумен вом изделия система TechnologiCS имеет
другой стороны, мы понимаем, что уст тации неизбежно диктует собственные всего один инструмент – версии специ
ройство выбранной системы не в полной законы, иногда находящиеся в серьезном фикаций с возможностью управлять их
мере обеспечивает требования предпри противоречии с законами, действующи статусами и связанными документами.
ятия. Система TechnologiCS в данном ми при работе с бумажными документа Так же традиционно TechnologiCS
случае является среди прочих лишь наи ми. И последнее – для реализации про предлагает использование версий "сквоз
более подходящей для реализации про екта мы имеем систему, которая распола ного" техпроцесса. Это значит, что мож
екта. Это заставляет нас находить вари гает ограниченным набором средств и но управлять только статусом версии це
анты, порой выходящие за рамки преду способов решения задач. ликом; при этом не обеспечивается неза
смотренных разработчиками типовых Проиллюстрируем сказанное на при висимое управление "цеховыми" техпро
решений. Заметим, что данное утвержде мерах. В данном случае среди особенно цессами, так как они, с одной стороны,
ние справедливо для любой системы, вы стей предприятия, которые существенно представляют собой "фрагменты" сквоз
бранной в качестве инструмента автома повлияли на способы решений задач, ха ного, а с другой – соответствуют разным
тизации. Возможность ее глубокой наст рактерных для предметной области, комплектам документации. Возмож
ройки и адаптации – необходимое усло можно отметить следующие: ность выпуска различных комплектов
вие реализации проекта. Достаточным  Управление составом изделия – осо технологической документации в рамках
условием является умение увидеть под бенности предприятия требуют уп "сквозной" версии создает лишь иллю
час скрытую суть проблем и найти реше равления двумя видами состава, кон зию управления.
ния, адекватные ситуации, – в против структорским и технологическим. Однако были и моменты, которые
ном случае результат внедрения будет При этом процесс управления должен облегчали задачу.
носить формальный характер. обеспечить их неразрывную взаимо Использование на предприятии са
Продолжим делиться опытом вы связь и определенную последователь мостоятельной производственной систе
полнения проекта построения автома ность преобразования. мы (ERP) давало нам возможность про

1
Дмитрий Докучаев "Цель подсказывает средства". – CADmaster, № 5/2007, с. 50355.

30 №1 | 2008 | CADmaster
программное обеспечение

явить определенную "вольность" в обра вовать действующей на данный мо занные с версиями, были названы "кар
щении со структурой информации – мы мент технологической версии (если тами ввода", поскольку именно они от
не были связаны требованиями произ таковой нет, то конструкторской). ражают процесс поэтапного ввода в дей
водственного модуля TechnologiCS. Все спецификации, находящиеся в ствие соответствующего объекта (в дан
В основе решения вопроса о том, ка разработке, должны быть доступны ном случае спецификации) и позволяют
ким же образом совместить требования только кругу лиц, причастных к это отследить все стадии процесса.
предприятия и имеющиеся возможнос му процессу в рамках прав, опреде Стадия конструкторской разработки:
ти системы, лежат несколько достаточно ленных системой. 1. Создается пустая версия специфика
простых идей. Рассмотрим их более по  Преобразование состава необходимо ции, не связанная с управляющим
дробно. автоматизировать, так как "ручной" документом. Она имеет наименова
способ формирования технологичес ние "Версия в разработке" и статус
Часть первая. Управление конст кой спецификации может привести к "Активная – утверждена" – следова
рукторским и технологическим ви возникновению ошибок, особенно в тельно, видна "по умолчанию". Ее
дами состава изделия случае больших объемов информа назначение – послужить своеобраз
Процесс формирования состава из ции. ной "ширмой", за которой будет про
делия заключается в последовательном исходить процедура разработки и со
выполнении двух этапов: Как ни странно, для решения задачи гласования "настоящей" специфика
 Разработка конструкторского соста предложено использовать не две, а три ции.
ва. Выполняется традиционно, и в версии спецификации! Кроме того, по 2. Одновременно создается версия,
нашем случае функциональность си скольку TechnologiCS позволяет иметь связанная с документом "Карта вво
стемы стопроцентно позволяет обес только "плоский" список версий, при да" и имеющая статус "Редактирова
печить управление этим процессом, шлось организовать их иерархическую ние". Версия проходит последова
включая работу с документацией, зависимость с использованием так на тельные этапы разработки, выпуска
электронное согласование и утверж зываемых "управляющих документов", документов, электронного согласо
дение состава. связанных с версиями. Напомним, что вания и утверждения, при этом полу
 Анализ конструкторских специфика документы TechnologiCS позволяют ор чает статус "Архив". (Она попрежне
ций и принятие решения о необходимо ганизовать между ними связи типа "вхо му не видна "по умолчанию"!) Управ
сти преобразования состава. Выпол димость" и "применяемость". Управляю ление процессом передается техно
няется технологическими службами. щие документы, непосредственно свя логическим службам.
При этом отдельные позиции специ
фикаций могут быть объединены в
так называемые "технологические
узлы" (сборочные единицы, являю
щиеся реальными объектами произ
водственного планирования и учета,
но не имеющие "собственного" чер
тежа). Технологические узлы могут
объединять детали и сборочные еди
ницы с разных уровней входимости в
изделие. В отдельных случаях появ
ляются "технологические детали" –
они не остаются в изделии (могут
быть разрушены в процессе изготов
ления), но при этом требуют техно
логической проработки и изготовле
ния.
Таким образом, можно сформулировать
задачу:
 Сборочные единицы должны иметь
"управляемую пару" версий специ
фикаций, при этом технологическая
версия должна хранить информацию
о том, на основании какой именно
конструкторской она создана. Кон
структорская версия при этом играет
роль "оригинала" и служит объектом
проведения изменений, а технологи
ческая – ее "порождением".
 Необходимо обеспечить последова
тельную обработку двух версий спе
цификации разными службами, при
этом обеспечив требования безопас
ности – разделение прав доступа и
управление статусами этих версий.
Спецификация, видимая в системе Рис. 1. Структура версий спецификации, управляющих документов и их отражение в системе
"по умолчанию", должна соответст

CADmaster | 2008 | №1 31
МАШИНОСТРОЕНИЕ

Рис. 2. Схема последовательного создания и обработки конструкторского и технологического состава (версий спецификаций)

Стадия технологической проработки: конструкторская. Пустая версия, со дят для обеспечения согласованного уп
1. В случае, если анализ конструктор зданная на старте процесса, при этом равления процессами технологического
ской документации выявил необхо автоматически переходит в архив как проектирования и выпуска документа
димость создания технологических выполнившая свою роль. ции при децентрализованном способе
узлов, создается еще одна версия спе Отметим, что принятая структура при подготовки производства. Прежде всего
цификации (копия конструктор всей ее логичности и полном соответст это происходит потому, что в данном слу
ской), связанная с собственной кар вии сформулированным требованиям чае не удается обеспечить однозначного
той ввода (технологической). Статус достаточно сложна. Управление такой соответствия объектов TechnologiCS
версии при этом – "Редактирование". структурой с использованием штатных (версий техпроцессов) и порожденных
Технологическая карта ввода "входит" средств системы было бы крайне затруд ими комплектов технологической доку
в конструкторскую, отражая иерар нительным. Поэтому в ходе проекта бы ментации. Отношение получается "один
хию версий. ло разработано целое семейство скрип ко многим". Комплект технологической
2. Происходит автоматизированное товых модулей, облегчающих работу документации как носитель юридическо
преобразование состава с выделени конструкторов и технологов. По сути эти го статуса обязательно требует синхрон
ем технологических узлов – новых модули являются макрофункциями, ав ного управления с "электронным" тех
номенклатурных позиций, имеющих томатизирующими рутинные последова процессом. Данное утверждение приоб
собственные спецификации и соот тельности выполнения определенных ретает особый смысл в условиях повы
ветствующие карты ввода. Специфи действий. Кроме того, использование шенных требований к документации,
кация, "ведомая" картой ввода, про макрофункций если не исключает сов процессу ее разработки, согласования и
ходит необходимые стадии согласо сем, то снижает до минимума риск воз утверждения, диктуемых отраслевой при
вания и утверждения. никновения ошибок. Функция конст надлежностью предприятия.
3. Маршрут обработки документа "Кар руктора и технолога в данном процессе Формулируем задачу:
та ввода" предусматривает обязатель сводится к выбору определенного сцена  Предприятие использует децентра
ную стадию "Ввод в действие". Когда рия из меню и следованию указаниям, лизованный способ подготовки про
вся информация готова и документ которые предоставляет соответствую изводства, при котором службы глав
принимает соответствующий статус, щий модуль. ного технолога отвечают за предва
связанная с ним версия меняет состо рительный маршрут (расцеховку) и
яние на "Активная – утверждена" и Часть вторая. Структура координируют процессы технологи
становится видимой "по умолчанию". технологической информации ческого проектирования в цеховых
Понятно, что в отсутствие технологи Как уже было отмечено, версии технологических бюро (выполняют
ческой версии данный статус примет "сквозного" техпроцесса не совсем подхо роль диспетчера).
32 №1 | 2008 | CADmaster
программное обеспечение

 Разработка маршрутной и операци


онной технологии производится в
цехах, при этом состав и формы до
кументации очень сильно разнятся в
зависимости от вида обработки, дей
ствующих стандартов и сложивших
ся устойчивых традиций.
 Маршрутная карта цеха (впрочем,
как и комплект цеховой документа
ции) объединяет весь перечень опе
раций, производимых данным цехом
над данной деталью, – независимо
от того, является ли этот маршрут
"непрерывным" или имеет "выходы"
для обработки в других цехах. В рам
ках цехового комплекта операции
имеют сквозную нумерацию.
 Проектирование технологии в цехах
ведется параллельно, при этом для
"смежных" операций в подавляющем
большинстве случаев согласуются
лишь граничные условия и техничес
кие требования (входные и выход Рис. 3. Скриптовые модули для работы с составом изделия
ные параметры).
 Процедура согласования и утвержде "раскрываются" в виде со
ния комплектов технологической до ответствующих комплек
кументации цеховыми техбюро осу тов документации соис
ществляется также параллельно и в полнителей.
ряде случаев даже независимо друг от В результате перечень тре
друга. бований к новому объекту
Таким образом, напрашивается ре (сущности) TechnologiCS по
шение: сформировать в системе лучился следующим:
TechnologiCS информационный объект,  Объект должен представ
однозначно соответствующий цеховому лять собой номенклатур
комплекту технологической документа ную позицию, имеющую
ции, обеспечить одинаковые права до собственные версии тех
ступа к данному объекту и связанному с нологического процесса
ним документу, а также синхронное уп для обеспечения требова
равление ими. ния раздельного, незави
Анализ технологической документа симого управления. Рис. 4. Модули, автоматизирующие преобразование состава
ции предприятия позволил выявить оп  Технологический процесс
ределенные закономерности, которые данного объекта должен объединять мируется путем добавления определен
помогли нам правильно сформулиро все операции, выполняемые данным ного суффикса к обозначению детали.
вать требования к такому объекту. Вот цехом над данной деталью в рамках Хотя цеходеталь является виртуальной
некоторые из них: сквозного техпроцесса. номенклатурой (фантомом), это не со
 По отношению к процессу изготов  Объект сам по себе должен иметь здало дополнительных трудностей у тех
ления любой детали или сборочной возможность использования в тех нологов – напротив, они получили "соб
единицы (ДСЕ) всегда можно опре процессе (быть включенным в тех ственный", понятный им объект, одно
делить цех, отвечающий за ДСЕ в це процесс в виде операции). Данное значно соотносящийся с комплектом
лом. При этом остальные цеха, при требование диктуется еще и необхо документации и позволяющий обеспе
нимающие участие в обработке, дей димостью обеспечения единства (не чить реальное разделение прав доступа к
ствуют в рамках граничных условий разрывной связи) расцеховки и опе нему.
(технических требований), которые раций техпроцесса. Упрощенно метаморфозу структуры
определены ответственным цехом. Объект представляет собой специ технологической информации, пред
 Другими словами, по отношению к фическую сущность, которая, являясь ставляющую собой переход от линейной
конкретной ДСЕ всегда можно выде номенклатурой, в то же время использу (плоской) структуры сквозного техпро
лить цехизготовитель, остальные ется в техпроцессе и обрабатывается как цесса к "пространственной", совмещаю
причастные к изготовлению будут операция, а также, в свою очередь, име щей принципы иерархической модели и
являться цехамисоисполнителями. ет собственный техпроцесс изготовле обеспечивающей "параллельное" управ
 Комплекты технологической доку ния. (Браво, TechnologiCS, позволяю ление, можно представить так, как пока
ментации цехов содержат "обобщен щий подобные вольности!) зано на рис. 5 и 6.
ные" операции, выполняющиеся в Для наименования этого объекта Следует заметить, что при такой
других цехах и содержащие те самые был предложен термин "Цеходеталь", структуре для обеспечения требований
технические требования, которые который мы позаимствовали у наших управления процессами проектирова
должен обеспечить цехсоисполни коллег, внедряющих ERPсистему. Уни ния понадобилась еще более сложная,
тель. Эти операции, в свою очередь, кальное обозначение цеходетали фор иерархически организованная совокуп

CADmaster | 2008 | №1 33
МАШИНОСТРОЕНИЕ

Рис. 5. "Сквозной" техпроцесс в системе Рис. 6. "Пространственная" структура технологического процесса


TechnologiCS
этом устанавливаются новые связи меж функционирования производственной
ду управляющими документами, обеспе системы. Задача была выполнена, при
чивающие хранение истории изменений этом использовалась имеющаяся на
и восстановление состояния ДСЕ на мо предприятии информация. Основным
мент, соответствующий выбранному Из источником данных был ИВЦ. И вот ре
вещению об изменении (при этом не зультат: мало того что импортированная
важно, были это изменения прошлых пе информация нуждалась в серьезных пре
риодов или изменения, которые плани образованиях и потребовала масштабной
руются для внедрения в будущем). работы по ее выверке, так мы еще и унас
Не вдаваясь в подробности, отметим ледовали структуру, которая напрямую
лишь, что для управления процессами препятствовала правильной организации
технологического проектирования ис процессов проектирования:
пользовались те же принципы, которые  конструкторские и технологические
были описаны выше (управление вер версии спецификаций были импор
сиями спецификаций и связанных с ни тированы линейным списком;
ми документами). Подобное единооб  техпроцесс, полученный в результате
разие позволило специалистам пред импорта, носил сквозной характер;
Рис. 7. Структура версий цеховых техпроцессов приятия достаточно быстро освоить ло  все права на версии спецификаций и
и управляющих документов гику управления и овладеть приемами техпроцессов принадлежали безли
работы с электронными объектами и кому пользователю "Администратор".
ность управляющих документов – по документами. Единственное, что утешало – такая
явились специфические карты ввода тех структура полностью устраивала ERP. Та
процесса цехаизготовителя и карты вво Часть третья. Война структур ким образом, не возникло необходимос
да цеховсоисполнителей. Не дадим оппонентам возможности ти ее переделки в масштабах всей базы
В свою очередь, для организации уп упрекнуть авторов в лукавстве – расска данных.
равления разработкой техпроцесса ДСЕ жем о неизбежных трудностях и путях их При этом мы понимали, что, с одной
в целом, возникла необходимость в еще преодоления. стороны, проектирование новых изде
одном управляющем документе – карте Казалось бы, разработанная с учетом лий может выполняться с учетом наших
ввода техпроцесса, который объединяет специфических требований предприятия разработок, не принимая во внимание
все объекты, относящиеся к техпроцессу структура информации должна обеспе состояние и структуру уже имеющейся
изготовления ДСЕ. чить устойчивую работу подразделений, информации, а с другой – любое конст
Подобная структура позволила ре занятых в процессах подготовки произ рукторское или технологическое измене
шить еще одну важную задачу – проце водства. Действительно, все было бы ние с использованием уже имеющихся
дура проведения технологических изме гладко, если бы мы начинали "с чистого данных может поставить сотрудников
нений стала более компактной и логич листа", то есть с пустой базы данных. предприятия в тупик.
ной по отношению к стандартной, пре В жизни все было не так. Как уже В сложившейся ситуации были сде
дусмотренной системой TechnologiCS. упоминалось в предыдущей статье, необ ланы следующие выводы, приняты и ре
Действительно, изменение технологии ходимым условием выполнения всего ализованы соответствующие решения:
цеха влечет за собой появление новой проекта было поставлено первоочеред 1. Нет ничего страшного, что в системе
версии только объекта изменения (тех ное наполнение базы данных конструк TechnologiCS какоето (пусть доста
процесса соответствующей цеходетали), торской и технологической информаци точно длительное) время будут одно
не затрагивая остальные объекты. При ей в объеме, достаточном для начала временно существовать данные со
34 №1 | 2008 | CADmaster
программное обеспечение

Рис. 8. Преобразование структуры данных – подготовка к изменению

старой, унаследованной структурой данного процесса, осуществле применение типовых решений, зачас
и "новая" информация, обладающая ние контроля процесса. тую носящих "лабораторный" характер и
модифицированной структурой. 4. Автоматизированное преобра не подкрепленных серьезным анализом
Действительно, такое положение дел зование структуры по отношению к индивидуальных требований конкрет
устраивает всех до тех пор, пока не каждой номенклатурной позиции про ного проекта, может привести в лучшем
потребуется внесение изменений в водится однократно, только в случае не случае к дополнительным затратам на
действующую документацию. Для обходимости ее изменения. Таким обра переделку, а в худшем – к провалу всего
корректной передачи данных в ERP зом, появляется возможность целена проекта.
надо лишь научиться единообразно правленного постепенного преобразова В процессе разработки и согласова
представлять обе структуры на "вы ния структуры данных, обновляющего ния структуры данных важнейшим эта
ходе" из TechnologiCS. информацию для актуального (то есть пом является совместная работа специа
2. Чтобы обеспечить возможность кор "находящегося в работе") номенклатур листов предприятия и консультантов
ректного проведения изменений до ного перечня. над документом "Соглашение о ведении
кументации разработан комплекс Схема, отражающая последователь данных" – одним из определяющих из
программных средств, автоматичес ность преобразования, приведена на состава проектной документации. Кро
ки преобразующих структуру с уче рис. 8. ме всего прочего, данная работа сближа
том "новых" требований и, таким об ет требования предприятия и возможно
разом, готовящих почву для последу Заключение сти консультанта, тем самым позволяя
ющей работы соответствующих под Вернемся к началу статьи, вернее, к найти взаимоприемлемые решения.
разделений. ее заголовку. Так с чего же всетаки на Достаточно подробно остановив
3. Данный комплекс обеспечивает: чинается АСТПП? Опыт выполнения шись на вопросах формирования струк
 автоматическое создание версий данного проекта лишний раз подтвердил туры данных, авторы сознательно оста
спецификаций и техпроцессов, а тезис о том, как важно уже на этапе ис вили за рамками статьи ряд других важ
также управляющих документов, следования разработать такую структуру нейших составляющих проекта, анонси
обеспечивающих управление со данных (или, во всяком случае, базовые, рованных в предыдущей статье. Впро
ответствующими версиями, уста основополагающие требования к ней), чем, мы упомянули о некоторых вопро
новление их связей на версии и которая впоследствии обеспечит прин сах, связанных с разработкой и реализа
между собой; ципиальную возможность решения по цией системы электронного документо
 автоматическое преобразование ставленных задач. оборота и автоматизированного управ
"плоского" техпроцесса в "иерар Конечно же на ранних стадиях про ления процессами проектирования – и
хический". Автоматическое со екта невозможно учесть все нюансы, и обязательно вернемся к этой теме в сле
здание цеходеталей; модернизация разработанной структуры дующем номере журнала.
 раздачу прав пользователям в в ходе выполнения проекта неизбежна.
рамках рабочих групп на версии и Важно, однако, заложить такую основу, Дмитрий Докучаев,
документы, в зависимости от ви которая позволит на стадии реализации Елена Кузнецова,
да изменения и подразделения, не откатиться к самому началу чтобы пе Елена Зырянова,
его выпускающего; ределывать вообще всё. Борис Бабушкин
 автоматическое информирова В очередной раз сравнивая процесс CSoft
ние участников процесса о про построения системы автоматизации со Тел.: (495) 9132222
изведенных преобразованиях, от строительством здания, позволим себе Email: Dokuchaev@csoft.ru
слеживание цепочки действий, аналогию: структура данных является Kuznetcova@csoft.ru
которые должны произвести со фундаментом, каркасом и коммуника Zyryanova@csoft.ru
трудники предприятия в рамках циями всей системы. И в данном случае Babushkin@csoft.ru

CADmaster | 2008 | №1 35
Уважаемые читатели!
Если вы хотите получать печатную версию журнала CADmaster, вы можете оформить бесплатную
подписку, заполнив нижеприведенный бланк. Обращаем ваше внимание, что частным лицам на
домашний адрес журнал не высылается.
Заполненный бланк присылайте:
Факс: 8 (495) 913-2221
E-Mail: marketing@csoft.ru
Почта: 121351, г. Москва, ул. Молодогвардейская, дом 46, корпус 2

Бланк бесплатной подписки

ФИО адресата: ______________________________________________________________________

Полное наименование организации: ____________________________________________________

Отдел: _____________________________________________________________________________

Должность: _________________________________________________________________________

Телефон: (______)_________________________________________________________________
код города

Факс: (______)_________________________________________________________________
код города

E-mail: _____________________________________________________________________________

Издания направлять по адресу:

Почтовый индекс Страна ________________________________________

Область ___________________________________________________________________________

Город ___________________________ Улица _________________________________________

Дом _____________________________ Строение/корпус ________ Офис ___________________

Вид деятельности:

Машиностороение Проектирование промышленных


объектов
Электроника и электротехника Архитектура и строительство

Нефть и газ Другое ______________________________

Геоинформационные системы
______________________________
и картография
Изыскания, генплан и транспорт

Электронная подписка: www.cadmaster.ru/info/signed.html