Больше чем документооборот…

Дмитрий Докучаев, Елена Докучаева

Почему недостаточно «просто документооборота»?

Идеи и инструменты для их реализации

С чем не справился TechnologiCS

Заключение

Литература

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

Почему недостаточно «просто документооборота»?

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

• прозрачность процессов проектирования и проведения изменений;
• понятную логику и простоту управления этими процессами для пользователей;
• подконтрольность процессов для руководства предприятия;
• безопасность с точки зрения хранения информации и организации коллективного доступа к ней.

Почему наладить? Ведь на предприятии уже действует традиционная система «бумажного» технического документооборота, которая как раз и призвана обеспечить выполнение всех указанных требований! Казалось бы, достаточно не разрушить то, что есть, тем более что практически все виды документов, задействованных в процессах подготовки производства, остаются в работе. Меняется только способ получения этих документов. Более того, имея в распоряжении систему TechnologiCS (technologics.ru), располагающую развитыми средствами создания электронного архива и управления электронными документами, можно претендовать на решение проблемы путем аккуратного переноса уже существующих принципов управления документацией. Тем не менее, существует ряд причин, которые заставляют смотреть на ситуацию шире, не ограничиваясь только документами.

Чтобы ясно представить себе, чего можно ждать от внедрения системы электронного документооборота (СЭД), а чего нельзя, попытаемся понять традиционную трактовку этого термина.

Основной нормативный документ (ГОСТ Р 51141-98 — Делопроизводство и архивное дело. Термины и определения) дает следующее определение документооборота:

«Документооборот — движение документов в организации с момента их создания или получения до завершения исполнения или отправления».

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

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

«СЭД — это <…> система, позволяющая решать все типовые задачи электронного документооборота для работы с документами — регистрация и ввод документов, поиск документов, маршрутизация, создание отчетов, ведение архива, управление правами доступа в системе» [3].

Как видим, объединяет все эти трактовки то, что в качестве объекта хранения и управления рассматривается именно документ как носитель информации.

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

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

2. Совершенно по-другому «работают» технологические документы. Комплекты технологической документации — это воплощение процесса проектирования, который осуществляется непосредственно в системе. В данном случае первоисточником служит объект системы TechnologiCS, а комплект документации может быть получен из него в качестве отчета. Заметим также, что отчет формируется в любой момент по желанию разработчика и, соответственно, может отражать все стадии разработки технологического процесса. Этот пример иллюстрирует утверждение, приведенное в [4]: «…внедрение электронных средств работы с информацией, основанных на базах данных, предполагает изменение самой сути документа: из «носителя информации» он становится лишь ее отображением в форме, привычной для пользователя».

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

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

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

Таким образом, на каждом из этапов (на финише каждого из подпроцессов подготовки производства) необходим зафиксированный, утвержденный состав и объем необходимой информации, а также соответствующих ей документов.

Все перечисленное позволяет сделать следующие выводы:

• во-первых, нельзя рассматривать документы, сопровождающие процессы подготовки производства, отдельно от соответствующих им структурированных данных, составляющих базу нормативно-справочной информации. Документы и соответствующая им информация представляют собой единое целое и, следовательно, должны управляться как один объект;
• во-вторых, необходимо четко представить себе, какие из документов являются исходными, а какие порождаются системой. Это позволит понять, что в данном процессе — база данных или документ — является объектом управления, а что должно «отслеживать» изменение оригинала. При этом желательно по возможности сформулировать единый подход к управлению; во всяком случае, логика управления и тем и другим должна быть одинаковой с точки зрения пользователя;
• в-третьих, все процедуры управления должны быть процессно-ориентированными.

Эти выводы легли в основу реализации системы управления процессами технической подготовки производства на упомянутом предприятии.

Идеи и инструменты для их реализации

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

Идей, которые легли в основу решения, по большому счету было всего две:

• структура данных, подробно описанная в [1];
• способ управления этими данными и документами, на котором мы подробно остановимся.

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

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

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

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

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

Виды документов, их связи с объектами базы данных и между собой

Этот раздел касается только специфических управляющих документов. Описание работы электронных документов, являющихся типовыми и использующихся традиционным образом (например, «Заявка на проектирование оснастки»), сознательно опущено.

Итак, для обеспечения возможности синхронного управления документами и соответствующими им объектами необходимо прежде всего обеспечить их связь «один к одному», тем более что разработанная структура данных позволяет нам сделать это в полной мере. Таким образом, появляется управляющий документ «Карта ввода» и его подвиды:

• Карта ввода ДСЕ (детале-сборочной единицы) конструкторская КВ ДСЕ (к) — связана с конструкторской версией спецификации;
• Карта ввода ДСЕ технологическая КВ ДСЕ (т) — связана с технологической версией спецификации;
• Карта ввода техпроцесса цеха-изготовителя КВ ЦИ;
• Карта ввода техпроцесса цеха-соисполнителя КВ Ц (соответствует цеходетали).

КВ ЦИ и КВ Ц связаны с соответствующими версиями техпроцессов.

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

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

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

Рис. 1. Документы «КВ ДСЕ» и их связи с объектами системы

 

Рис. 2. Пример способа обработки документа «КВ ДСЕ (к)»

Если для управления конструкторским и технологическим составом достаточно КВ ДСЕ, то для управления разработкой технологического процесса, а также для выделения этапа работы с расцеховкой и материалом необходим еще один управляющий документ, объединяющий КВ ЦИ и все относящиеся к ней КВ Ц. Этот документ называется Карта ввода техпроцесса (КВ ТП). Он объединяет версии техпроцессов посредством входящих в него КВ ЦИ и КВ Ц и определяет совокупность информации о техпроцессе изготовления целиком. КВ ТП не имеет файлового состава, ее способ обработки специфичен и не содержит этапов согласования и утверждения — только отслеживает статусы входящих в него документов, тем самым позволяя вовремя осуществить ввод в действие утвержденных комплектов технологической документации и соответствующих им версий техпроцессов (рис. 3 и 4).

Рис. 3. Документы «КВ ТП» и их связи с объектами системы

 

Рис. 4. Пример способа обработки документа «КВ ТП»

Любой процесс — будь то разработка нового изделия или проведение изменений — в общем случае подразумевает работу сразу с группой номенклатурных позиций:

• разработка новой продукции подразумевает появление информации по всему номенклатурному перечню, составляющему изделие;
• замена (модернизация) оборудования на одном из участков цеха приводит к необходимости массовой коррекции техпроцессов.

Подобных примеров можно привести множество, и все они диктуют необходимость еще одного вида управляющего документа, который должен объединять весь вводимый (изменяемый) номенклатурный перечень. Этот документ называется «Извещение об изменении» (ИИ) или «Извещение о создании» (ИИ0); он в какой-то мере соответствует своему традиционному (бумажному) прообразу, но при этом выполняет еще ряд специфических функций:

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

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

Рис. 5. Документ «ИИ/ИИ0» и его связи с объектами системы

 

Рис. 6. Пример способа обработки документа ИИ

Логика управления и взаимодействие документов

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

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

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

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

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

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

При инициировании любого процесса анализируются три условия:

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

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

Рис. 7. Изменение расцеховки — шаг 1

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

1. Шаг 1. Пользователь — Разработчик в рабочей группе ТБ ОГТ (подразделение, отвечающее за технологический состав и разработку маршрутов) — должен провести изменение расцеховки. Он просто выбирает соответствующее действие (рис. 7).

2. Шаг 2. Проанализировав информацию об инициаторе процесса, программный модуль запускает выполнение процесса по определенному сценарию, при этом уточняя информацию о создаваемом документе (рис. 8).

Рис. 8. Изменение расцеховки — шаг 2

3. Шаг 3. В случае если ИИ требует предварительного согласования, разработчик может воспользоваться дополнительными функциями, реализующими этот процесс (рис. 9).

Рис. 9. Изменение расцеховки — шаг 3

4. Шаг 4. Пользователь выбирает необходимый ему сценарий и получает перечень возможных дальнейших действий (рис.  10).

Рис. 10. Изменение расцеховки — шаг 4

5. Шаг 5. Система проанализировала соответствие полномочий пользователя (разработчик в рабочей группе) выбранному им сценарию, отобразила ему материал и расцеховку из версий техпроцессов, соответствующих выбранному ИИ (!), и предложила в данной ситуации два варианта действий (рис. 11):

• редактировать техпроцесс (изменить расцеховку);
• указать цех-изготовитель.

Рис. 11. Изменение расцеховки — шаг 5

6. Пользователь производит требуемые изменения, при этом не рискуя ошибиться при выборе версии: система сама предоставляет ему для работы нужную.

Обратите внимание, что пользователь выполняет понятные ему действия, а система в это время автоматически:

• формирует все необходимые управляющие документы;
• создает соответствующие изменению версии;
• устанавливает все необходимые связи;
• устанавливает права на созданные объекты.

7. Следующим этапом необходимо согласовать изменение с цехами. Это удобно сделать, сформировав отчет «Материально-расцеховочная ведомость» (рис. 12), который наглядно отобразит суть внесенного изменения (шаг 1).

Рис. 12. Согласование изменения — шаг 1

Обратите внимание, что ведомость (отчет, полученный в Excel) дает возможность запустить макрос, который умеет:

• обращаться к TechnologiCS;
• находить там управляющий документ, к которому он должен быть добавлен (в нашем случае это файловый состав Извещения об изменении);
• проверять права пользователя, создавшего данный документ, на предмет возможности выполнения данного действия;
• автоматически выполнять все действия по сохранению себя в архиве.

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

8. Следующее действие пользователя — отправить Извещение на согласование (рис. 13) в техбюро цехов (шаг 2).

Рис. 13. Согласование изменения — шаг 2

Обратите внимание — пользователь просто выбирает действие. Система при этом автоматически:

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

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

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

Прежде всего это «Монитор» — универсальное средство, отражающее состояние документов и позволяющее пользователю получать актуальную информацию о состоянии процесса, участником которого он является (рис. 14 и 15).

Рис. 14. Монитор: отображение степени готовности технологической документации по конкретному техпроцессу

 

Рис. 15. Монитор не только отображает информацию, но и позволяет выполнять действия, разрешенные ему для данного документа

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

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

Рис. 16. Протокол работы программы-робота

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

Рис. 17. Сообщения программы-робота

И в заключение — несколько слов об управлении правами доступа пользователей к объектам системы. Данный процесс также удалось максимально автоматизировать, используя:

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

 

Пример

Разработчик ОГК выполняет понятное ему действие: «Отправить утвержденный документ в ОГТ для проработки технологического состава». При этом автоматически выполняются следующие действия:

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

С чем не справился TechnologiCS

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

Существует два варианта формирования итоговой спецификации: разузлование по активным версиям спецификаций и по назначенным версиям.

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

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

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

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

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

1. Разработчик должен определить перечень изделий, на которые повлияет его изменение. При этом решается не такая уж тривиальная задача — надо не просто определить применяемость изменяемой номенклатуры, а сделать это с учетом того, что на дату вступления в действие «нашего» ИИ, по другим номенклатурным позициям, входящим в те же изделия, могут быть проведены другие изменения. Эту задачу решает специально разработанный модуль «Применяемость» (рис. 18).

Рис. 18. Определение полной применяемости в изделиях на дату ввода в действие ИИ

 

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

Рис. 19. Результат разузлования изделия: исходные данные для построения ведомостей

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

Рис. 20. Результат работы — сводная конструкторско-технологическая ведомость

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

Заключение

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

В качестве краткого резюме приведем следующее:

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

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

И это существенно больше чем документооборот.

Литература

1. Дмитрий Докучаев. С чего начинается АСТПП. // САПР и графика. № 11. 2008. С. 20-24.

2. Информационное агентство «Клерк.Ру» (www.klerk.ru). Интернет-ресурс. Открытый доступ. «Выбор системы электронного документооборота: взгляд заказчика» (обзор).

3. Википедия — проект свободной многоязычной энциклопедии. Интернет-ресурс. Открытый доступ, русскоязычный раздел (http://ru.wikipedia.org).

4. Дмитрий Докучаев. Цель подсказывает средства. // САПР и графика. № 3. 2008. С. 70-75.

САПР и графика 12`2008