Казалось бы, название статьи обязывает авторов сообщить о том, с чего начинается АСТПП, нечто принципиально новое. С другой стороны, искушенный читатель резонно заметит — что еще здесь может быть нового? Внедряемая на предприятии система уже предполагает типовые способы решения задач, характерных для автоматизируемой области. А принятое решение об использовании системы подразумевает, что предприятие с этими типовыми способами согласилось и остается их только внедрить.
Тем не менее оба этих утверждения не вполне соответствуют истине. Конечно, в процессе построения АСТПП мы всего лишь используем уже разработанную систему и ничего кардинально нового в ее устройство внести не можем. С другой стороны, мы понимаем, что устройство выбранной системы не в полной мере обеспечивает требования предприятия. Система TechnologiCS в данном случае является среди прочих лишь наиболее подходящей для реализации проекта. Это заставляет нас находить варианты, порой выходящие за рамки предусмотренных разработчиками типовых решений. Заметим, что данное утверждение справедливо для любой системы, выбранной в качестве инструмента автоматизации. Возможность ее глубокой настройки и адаптации — необходимое условие реализации проекта. Достаточным условием является умение увидеть подчас скрытую суть проблем и найти решения, адекватные ситуации, — в противном случае результат внедрения будет носить формальный характер.
Продолжим делиться опытом выполнения проекта построения автоматизированной системы технической подготовки производства (АСТПП) на крупном машиностроительном предприятии, которое уже было упомянуто в предыдущей статье как одно из ведущих в области авиационного агрегатостроения.
Предприятие относится к отрасли, сильной своими традициями. Более того, эти традиции помогли сохранить его «технологическую устойчивость» в условиях быстро меняющейся рыночной среды и, соответственно, обеспечить требуемый уровень качества продукции. Таким образом, автоматизация подготовки производства прежде всего должна сохранить преемственность традиций — мы не имеем права устраивать революции. С другой стороны, переход к «электронному» проектированию и выпуску документации неизбежно диктует собственные законы, иногда находящиеся в серьезном противоречии с законами, действующими при работе с бумажными документами. И последнее — для реализации проекта мы имеем систему, которая располагает ограниченным набором средств и способов решения задач.
Проиллюстрируем сказанное на примерах. В данном случае среди особенностей предприятия, которые существенно повлияли на способы решений задач, характерных для предметной области, можно отметить следующие:
Анализ данных требований вызвал серьезные сомнения относительно возможности применения стандартных подходов, предлагаемых системой TechnologiCS.
Традиционно для управления составом изделия система TechnologiCS имеет всего один инструмент — версии спецификаций с возможностью управлять их статусами и связанными документами.
Так же традиционно TechnologiCS предлагает использование версий «сквозного» техпроцесса. Это значит, что можно управлять только статусом версии целиком; при этом не обеспечивается независимое управление «цеховыми» техпроцессами, так как они, с одной стороны, представляют собой «фрагменты» сквозного, а с другой — соответствуют разным комплектам документации. Возможность выпуска различных комплектов технологической документации в рамках «сквозной» версии создает лишь иллюзию управления.
Однако были и моменты, которые облегчали задачу.
Использование на предприятии самостоятельной производственной системы (ERP) давало нам возможность проявить определенную «вольность» в обращении со структурой информации — мы не были связаны требованиями производственного модуля TechnologiCS.
В основе решения вопроса о том, каким же образом совместить требования предприятия и имеющиеся возможности системы, лежат несколько достаточно простых идей. Рассмотрим их более подробно.
Таким образом, можно сформулировать задачу:
Как ни странно, для решения задачи предложено использовать не две, а три версии спецификации! Кроме того, поскольку TechnologiCS позволяет иметь только «плоский» список версий, пришлось организовать их иерархическую зависимость с использованием так называемых «управляющих документов», связанных с версиями. Напомним, что документы TechnologiCS позволяют организовать между ними связи типа «входимость» и «применяемость». Управляющие документы, непосредственно связанные с версиями, были названы «картами ввода», поскольку именно они отражают процесс поэтапного ввода в действие соответствующего объекта (в данном случае спецификации) и позволяют отследить все стадии процесса.
Стадия конструкторской разработки:
Стадия технологической проработки:
Отметим, что принятая структура при всей ее логичности и полном соответствии сформулированным требованиям достаточно сложна. Управление такой структурой с использованием штатных средств системы было бы крайне затруднительным. Поэтому в ходе проекта было разработано целое семейство скриптовых модулей, облегчающих работу конструкторов и технологов. По сути эти модули являются макрофункциями, автоматизирующими рутинные последовательности выполнения определенных действий. Кроме того, использование макрофункций если не исключает совсем, то снижает до минимума риск возникновения ошибок. Функция конструктора и технолога в данном процессе сводится к выбору определенного сценария из меню и следованию указаниям, которые предоставляет соответствующий модуль.
Как уже было отмечено, версии «сквозного» техпроцесса не совсем подходят для обеспечения согласованного управления процессами технологического проектирования и выпуска документации при децентрализованном способе подготовки производства. Прежде всего это происходит потому, что в данном случае не удается обеспечить однозначного соответствия объектов TechnologiCS (версий техпроцессов) и порожденных ими комплектов технологической документации. Отношение получается «один ко многим». Комплект технологической документации как носитель юридического статуса обязательно требует синхронного управления с «электронным» техпроцессом. Данное утверждение приобретает особый смысл в условиях повышенных требований к документации, процессу ее разработки, согласования и утверждения, диктуемых отраслевой принадлежностью предприятия.
Формулируем задачу:
Таким образом, напрашивается решение: сформировать в системе TechnologiCS информационный объект, однозначно соответствующий цеховому комплекту технологической документации, обеспечить одинаковые права доступа к данному объекту и связанному с ним документу, а также синхронное управление ими.
Анализ технологической документации предприятия позволил выявить определенные закономерности, которые помогли нам правильно сформулировать требования к такому объекту. Вот некоторые из них:
В результате перечень требований к новому объекту (сущности) TechnologiCS получился следующим:
Объект представляет собой специфическую сущность, которая, являясь номенклатурой, в то же время используется в техпроцессе и обрабатывается как операция, а также, в свою очередь, имеет собственный техпроцесс изготовления. (Браво, TechnologiCS, позволяющий подобные вольности!)
Для наименования этого объекта был предложен термин «Цеходеталь», который мы позаимствовали у наших коллег, внедряющих ERP-систему. Уникальное обозначение цеходетали формируется путем добавления определенного суффикса к обозначению детали. Хотя цеходеталь является виртуальной номенклатурой (фантомом), это не создало дополнительных трудностей у технологов — напротив, они получили «собственный», понятный им объект, однозначно соотносящийся с комплектом документации и позволяющий обеспечить реальное разделение прав доступа к нему.
Упрощенно метаморфозу структуры технологической информации, представляющую собой переход от линейной (плоской) структуры сквозного техпроцесса к «пространственной», совмещающей принципы иерархической модели и обеспечивающей «параллельное» управление, можно представить так, как показано на рис. 5 и 6.
Следует заметить, что при такой структуре для обеспечения требований управления процессами проектирования понадобилась еще более сложная, иерархически организованная совокупность управляющих документов — появились специфические карты ввода техпроцесса цеха-изготовителя и карты ввода цехов-соисполнителей.
В свою очередь, для организации управления разработкой техпроцесса ДСЕ в целом, возникла необходимость в еще одном управляющем документе — карте ввода техпроцесса, который объединяет все объекты, относящиеся к техпроцессу изготовления ДСЕ.
Подобная структура позволила решить еще одну важную задачу — процедура проведения технологических изменений стала более компактной и логичной по отношению к стандартной, предусмотренной системой TechnologiCS. Действительно, изменение технологии цеха влечет за собой появление новой версии только объекта изменения (техпроцесса соответствующей цеходетали), не затрагивая остальные объекты. При этом устанавливаются новые связи между управляющими документами, обеспечивающие хранение истории изменений и восстановление состояния ДСЕ на момент, соответствующий выбранному Извещению об изменении (при этом не важно, были это изменения прошлых периодов или изменения, которые планируются для внедрения в будущем).
Не вдаваясь в подробности, отметим лишь, что для управления процессами технологического проектирования использовались те же принципы, которые были описаны выше (управление версиями спецификаций и связанных с ними документами). Подобное единообразие позволило специалистам предприятия достаточно быстро освоить логику управления и овладеть приемами работы с электронными объектами и документами.
Казалось бы, разработанная с учетом специфических требований предприятия структура информации должна обеспечить устойчивую работу подразделений, занятых в процессах подготовки производства. Действительно, все было бы гладко, если бы мы начинали «с чистого листа», то есть с пустой базы данных.
В жизни все было не так. Как уже упоминалось в предыдущей статье, необходимым условием выполнения всего проекта было поставлено первоочередное наполнение базы данных конструкторской и технологической информацией в объеме, достаточном для начала функционирования производственной системы. Задача была выполнена, при этом использовалась имеющаяся на предприятии информация. Основным источником данных был ИВЦ. И вот результат: мало того что импортированная информация нуждалась в серьезных преобразованиях и потребовала масштабной работы по ее выверке, так мы еще и унаследовали структуру, которая напрямую препятствовала правильной организации процессов проектирования:
Единственное, что утешало — такая структура полностью устраивала ERP. Таким образом, не возникло необходимости ее переделки в масштабах всей базы данных.
При этом мы понимали, что, с одной стороны, проектирование новых изделий может выполняться с учетом наших разработок, не принимая во внимание состояние и структуру уже имеющейся информации, а с другой — любое конструкторское или технологическое изменение с использованием уже имеющихся данных может поставить сотрудников предприятия в тупик.
В сложившейся ситуации были сделаны следующие выводы, приняты и реализованы соответствующие решения:
Схема, отражающая последовательность преобразования, приведена на рис. 8.
Конечно же на ранних стадиях проекта невозможно учесть все нюансы, и модернизация разработанной структуры в ходе выполнения проекта неизбежна. Важно, однако, заложить такую основу, которая позволит на стадии реализации не откатиться к самому началу чтобы переделывать вообще всё.
В очередной раз сравнивая процесс построения системы автоматизации со строительством здания, позволим себе аналогию: структура данных является фундаментом, каркасом и коммуникациями всей системы. И в данном случае применение типовых решений, зачастую носящих «лабораторный» характер и не подкрепленных серьезным анализом индивидуальных требований конкретного проекта, может привести в лучшем случае к дополнительным затратам на переделку, а в худшем — к провалу всего проекта.
В процессе разработки и согласования структуры данных важнейшим этапом является совместная работа специалистов предприятия и консультантов над документом «Соглашение о ведении данных» — одним из определяющих из состава проектной документации. Кроме всего прочего, данная работа сближает требования предприятия и возможности консультанта, тем самым позволяя найти взаимоприемлемые решения.
Достаточно подробно остановившись на вопросах формирования структуры данных, авторы сознательно оставили за рамками статьи ряд других важнейших составляющих проекта, анонсированных в предыдущей статье. Впрочем, мы упомянули о некоторых вопросах, связанных с разработкой и реализацией системы электронного документооборота и автоматизированного управления процессами проектирования — и обязательно вернемся к этой теме в следующем номере журнала.