CADmaster

Казалось бы, название статьи обязывает авторов сообщить о том, с чего начинается АСТПП, нечто принципиально новое. С другой стороны, искушенный читатель резонно заметит — что еще здесь может быть нового? Внедряемая на предприятии система уже предполагает типовые способы решения задач, характерных для автоматизируемой области. А принятое решение об использовании системы подразумевает, что предприятие с этими типовыми способами согласилось и остается их только внедрить.

Тем не менее оба этих утверждения не вполне соответствуют истине. Конечно, в процессе построения АСТПП мы всего лишь используем уже разработанную систему и ничего кардинально нового в ее устройство внести не можем. С другой стороны, мы понимаем, что устройство выбранной системы не в полной мере обеспечивает требования предприятия. Система TechnologiCS в данном случае является среди прочих лишь наиболее подходящей для реализации проекта. Это заставляет нас находить варианты, порой выходящие за рамки предусмотренных разработчиками типовых решений. Заметим, что данное утверждение справедливо для любой системы, выбранной в качестве инструмента автоматизации. Возможность ее глубокой настройки и адаптации — необходимое условие реализации проекта. Достаточным условием является умение увидеть подчас скрытую суть проблем и найти решения, адекватные ситуации, — в противном случае результат внедрения будет носить формальный характер.

Продолжим делиться опытом выполнения проекта построения автоматизированной системы технической подготовки производства (АСТПП) на крупном машиностроительном предприятии, которое уже было упомянуто в предыдущей статье ¹ как одно из ведущих в области авиационного агрегатостроения.

Предприятие относится к отрасли, сильной своими традициями. Более того, эти традиции помогли сохранить его «технологическую устойчивость» в условиях быстро меняющейся рыночной среды и, соответственно, обеспечить требуемый уровень качества продукции. Таким образом, автоматизация подготовки производства прежде всего должна сохранить преемственность традиций — мы не имеем права устраивать революции. С другой стороны, переход к «электронному» проектированию и выпуску документации неизбежно диктует собственные законы, иногда находящиеся в серьезном противоречии с законами, действующими при работе с бумажными документами. И последнее — для реализации проекта мы имеем систему, которая располагает ограниченным набором средств и способов решения задач.

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

• Управление составом изделия — особенности предприятия требуют управления двумя видами состава, конструкторским и технологическим. При этом процесс управления должен обеспечить их неразрывную взаимосвязь и определенную последовательность преобразования.
• Технологическое проектирование и выпуск документации — требуется обеспечить возможность параллельной работы цеховых технологических бюро со «своими» техпроцессами, а также предусмотреть эффективные механизмы согласования действий подразделений в процессе разработки и проведения изменений. В ряде случаев требования безопасности ограничивают доступ к информации (в том числе на просмотр) смежных участников процесса.

Анализ данных требований вызвал серьезные сомнения относительно возможности применения стандартных подходов, предлагаемых системой TechnologiCS.

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

Так же традиционно TechnologiCS предлагает использование версий «сквозного» техпроцесса. Это значит, что можно управлять только статусом версии целиком; при этом не обеспечивается независимое управление «цеховыми» техпроцессами, так как они, с одной стороны, представляют собой «фрагменты» сквозного, а с другой — соответствуют разным комплектам документации. Возможность выпуска различных комплектов технологической документации в рамках «сквозной» версии создает лишь иллюзию управления.

Однако были и моменты, которые облегчали задачу.

Использование на предприятии самостоятельной производственной системы (ERP) давало нам возможность проявить определенную «вольность» в обращении со структурой информации — мы не были связаны требованиями производственного модуля TechnologiCS.

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

Часть первая. Управление конструкторским и технологическим видами состава изделия

Процесс формирования состава изделия заключается в последовательном выполнении двух этапов:

• Разработка конструкторского состава. Выполняется традиционно, и в нашем случае функциональность системы стопроцентно позволяет обеспечить управление этим процессом, включая работу с документацией, электронное согласование и утверждение состава.
• Анализ конструкторских спецификаций и принятие решения о необходимости преобразования состава. Выполняется технологическими службами. При этом отдельные позиции спецификаций могут быть объединены в так называемые «технологические узлы» (сборочные единицы, являющиеся реальными объектами производственного планирования и учета, но не имеющие «собственного» чертежа). Технологические узлы могут объединять детали и сборочные единицы с разных уровней входимости в изделие. В отдельных случаях появляются «технологические детали» — они не остаются в изделии (могут быть разрушены в процессе изготовления), но при этом требуют технологической проработки и изготовления.

Таким образом, можно сформулировать задачу:

• Сборочные единицы должны иметь «управляемую пару» версий спецификаций, при этом технологическая версия должна хранить информацию о том, на основании какой именно конструкторской она создана. Конструкторская версия при этом играет роль «оригинала» и служит объектом проведения изменений, а технологическая — ее «порождением».
• Необходимо обеспечить последовательную обработку двух версий спецификации разными службами, при этом обеспечив требования безопасности — разделение прав доступа и управление статусами этих версий. Спецификация, видимая в системе «по умолчанию», должна соответствовать действующей на данный момент технологической версии (если таковой нет, то конструкторской). Все спецификации, находящиеся в разработке, должны быть доступны только кругу лиц, причастных к этому процессу в рамках прав, определенных системой.
• Преобразование состава необходимо автоматизировать, так как «ручной» способ формирования технологической спецификации может привести к возникновению ошибок, особенно в случае больших объемов информации.

Как ни странно, для решения задачи предложено использовать не две, а три версии спецификации! Кроме того, поскольку TechnologiCS позволяет иметь только «плоский» список версий, пришлось организовать их иерархическую зависимость с использованием так называемых «управляющих документов», связанных с версиями. Напомним, что документы TechnologiCS позволяют организовать между ними связи типа «входимость» и «применяемость». Управляющие документы, непосредственно связанные с версиями, были названы «картами ввода», поскольку именно они отражают процесс поэтапного ввода в действие соответствующего объекта (в данном случае спецификации) и позволяют отследить все стадии процесса.

Стадия конструкторской разработки:

1. Создается пустая версия спецификации, не связанная с управляющим документом. Она имеет наименование «Версия в разработке» и статус «Активная — утверждена» — следовательно, видна «по умолчанию». Ее назначение — послужить своеобразной «ширмой», за которой будет происходить процедура разработки и согласования «настоящей» спецификации.
2. Одновременно создается версия, связанная с документом «Карта ввода» и имеющая статус «Редактирование». Версия проходит последовательные этапы разработки, выпуска документов, электронного согласования и утверждения, при этом получает статус «Архив». (Она по-прежнему не видна «по умолчанию»!) Управление процессом передается технологическим службам.

Стадия технологической проработки:

1. В случае, если анализ конструкторской документации выявил необходимость создания технологических узлов, создается еще одна версия спецификации (копия конструкторской), связанная с собственной картой ввода (технологической). Статус версии при этом — «Редактирование». Технологическая карта ввода «входит» в конструкторскую, отражая иерархию версий.
2. Происходит автоматизированное преобразование состава с выделением технологических узлов — новых номенклатурных позиций, имеющих собственные спецификации и соответствующие карты ввода. Спецификация, «ведомая» картой ввода, проходит необходимые стадии согласования и утверждения.
3. Маршрут обработки документа «Карта ввода» предусматривает обязательную стадию «Ввод в действие». Когда вся информация готова и документ принимает соответствующий статус, связанная с ним версия меняет состояние на «Активная — утверждена» и становится видимой «по умолчанию». Понятно, что в отсутствие технологической версии данный статус примет конструкторская. Пустая версия, созданная на старте процесса, при этом автоматически переходит в архив как выполнившая свою роль.

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

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

Часть вторая. Структура технологической информации

Как уже было отмечено, версии «сквозного» техпроцесса не совсем подходят для обеспечения согласованного управления процессами технологического проектирования и выпуска документации при децентрализованном способе подготовки производства. Прежде всего это происходит потому, что в данном случае не удается обеспечить однозначного соответствия объектов TechnologiCS (версий техпроцессов) и порожденных ими комплектов технологической документации. Отношение получается «один ко многим». Комплект технологической документации как носитель юридического статуса обязательно требует синхронного управления с «электронным» техпроцессом. Данное утверждение приобретает особый смысл в условиях повышенных требований к документации, процессу ее разработки, согласования и утверждения, диктуемых отраслевой принадлежностью предприятия.

Формулируем задачу:

• Предприятие использует децентрализованный способ подготовки производства, при котором службы главного технолога отвечают за предварительный маршрут (расцеховку) и координируют процессы технологического проектирования в цеховых технологических бюро (выполняют роль диспетчера).
• Разработка маршрутной и операционной технологии производится в цехах, при этом состав и формы документации очень сильно разнятся в зависимости от вида обработки, действующих стандартов и сложившихся устойчивых традиций.
• Маршрутная карта цеха (впрочем, как и комплект цеховой документации) объединяет весь перечень операций, производимых данным цехом над данной деталью, — независимо от того, является ли этот маршрут «непрерывным» или имеет «выходы» для обработки в других цехах. В рамках цехового комплекта операции имеют сквозную нумерацию.
• Проектирование технологии в цехах ведется параллельно, при этом для «смежных» операций в подавляющем большинстве случаев согласуются лишь граничные условия и технические требования (входные и выходные параметры).
• Процедура согласования и утверждения комплектов технологической документации цеховыми техбюро осуществляется также параллельно и в ряде случаев даже независимо друг от друга.

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

Анализ технологической документации предприятия позволил выявить определенные закономерности, которые помогли нам правильно сформулировать требования к такому объекту. Вот некоторые из них:

• По отношению к процессу изготовления любой детали или сборочной единицы (ДСЕ) всегда можно определить цех, отвечающий за ДСЕ в целом. При этом остальные цеха, принимающие участие в обработке, действуют в рамках граничных условий (технических требований), которые определены ответственным цехом.
• Другими словами, по отношению к конкретной ДСЕ всегда можно выделить цех-изготовитель, остальные причастные к изготовлению будут являться цехами-соисполнителями.
• Комплекты технологической документации цехов содержат «обобщенные» операции, выполняющиеся в других цехах и содержащие те самые технические требования, которые должен обеспечить цех-соисполнитель. Эти операции, в свою очередь, «раскрываются» в виде соответствующих комплектов документации соисполнителей.

В результате перечень требований к новому объекту (сущности) TechnologiCS получился следующим:

• Объект должен представлять собой номенклатурную позицию, имеющую собственные версии технологического процесса для обеспечения требования раздельного, независимого управления.
• Технологический процесс данного объекта должен объединять все операции, выполняемые данным цехом над данной деталью в рамках сквозного техпроцесса.
• Объект сам по себе должен иметь возможность использования в техпроцессе (быть включенным в техпроцесс в виде операции). Данное требование диктуется еще и необходимостью обеспечения единства (неразрывной связи) расцеховки и операций техпроцесса.

Объект представляет собой специфическую сущность, которая, являясь номенклатурой, в то же время используется в техпроцессе и обрабатывается как операция, а также, в свою очередь, имеет собственный техпроцесс изготовления. (Браво, TechnologiCS, позволяющий подобные вольности!)

Для наименования этого объекта был предложен термин «Цеходеталь», который мы позаимствовали у наших коллег, внедряющих ERP-систему. Уникальное обозначение цеходетали формируется путем добавления определенного суффикса к обозначению детали. Хотя цеходеталь является виртуальной номенклатурой (фантомом), это не создало дополнительных трудностей у технологов — напротив, они получили «собственный», понятный им объект, однозначно соотносящийся с комплектом документации и позволяющий обеспечить реальное разделение прав доступа к нему.

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

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

В свою очередь, для организации управления разработкой техпроцесса ДСЕ в целом, возникла необходимость в еще одном управляющем документе — карте ввода техпроцесса, который объединяет все объекты, относящиеся к техпроцессу изготовления ДСЕ.

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

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

Часть третья. Война структур

Не дадим оппонентам возможности упрекнуть авторов в лукавстве — расскажем о неизбежных трудностях и путях их преодоления.

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

В жизни все было не так. Как уже упоминалось в предыдущей статье, необходимым условием выполнения всего проекта было поставлено первоочередное наполнение базы данных конструкторской и технологической информацией в объеме, достаточном для начала функционирования производственной системы. Задача была выполнена, при этом использовалась имеющаяся на предприятии информация. Основным источником данных был ИВЦ. И вот результат: мало того что импортированная информация нуждалась в серьезных преобразованиях и потребовала масштабной работы по ее выверке, так мы еще и унаследовали структуру, которая напрямую препятствовала правильной организации процессов проектирования:

• конструкторские и технологические версии спецификаций были импортированы линейным списком;
• техпроцесс, полученный в результате импорта, носил сквозной характер;
• все права на версии спецификаций и техпроцессов принадлежали безликому пользователю «Администратор».

Единственное, что утешало — такая структура полностью устраивала ERP. Таким образом, не возникло необходимости ее переделки в масштабах всей базы данных.

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

В сложившейся ситуации были сделаны следующие выводы, приняты и реализованы соответствующие решения:

1. Нет ничего страшного, что в системе TechnologiCS какое-то (пусть достаточно длительное) время будут одновременно существовать данные со старой, унаследованной структурой и «новая» информация, обладающая модифицированной структурой. Действительно, такое положение дел устраивает всех до тех пор, пока не потребуется внесение изменений в действующую документацию. Для корректной передачи данных в ERP надо лишь научиться единообразно представлять обе структуры на «выходе» из TechnologiCS.
2. Чтобы обеспечить возможность корректного проведения изменений документации разработан комплекс программных средств, автоматически преобразующих структуру с учетом «новых» требований и, таким образом, готовящих почву для последующей работы соответствующих подразделений.
3. Данный комплекс обеспечивает:
   • автоматическое создание версий спецификаций и техпроцессов, а также управляющих документов, обеспечивающих управление соответствующими версиями, установление их связей на версии и между собой;
   • автоматическое преобразование «плоского» техпроцесса в «иерархический». Автоматическое создание цеходеталей;
   • раздачу прав пользователям в рамках рабочих групп на версии и документы, в зависимости от вида изменения и подразделения, его выпускающего;
   • автоматическое информирование участников процесса о произведенных преобразованиях, отслеживание цепочки действий, которые должны произвести сотрудники предприятия в рамках данного процесса, осуществление контроля процесса.
4. Автоматизированное преобразование структуры по отношению к каждой номенклатурной позиции проводится однократно, только в случае необходимости ее изменения. Таким образом, появляется возможность целенаправленного постепенного преобразования структуры данных, обновляющего информацию для актуального (то есть «находящегося в работе») номенклатурного перечня.

Схема, отражающая последовательность преобразования, приведена на рис. 8.

Заключение

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

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

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

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

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