Уже много лет в беседах с представителями промышленных предприятий самого разного профиля я утверждаю, что в области ИТ нет более запутанного вопроса, чем вопрос электронного архива инженерной (технической, конструкторской, проектной и т.п.) документации и системы электронного документооборота. Количество аббревиатур и сокращений для обозначения этого понятия на английском (TDM, Workflow, PDM, PLM, CALS, PIM) и русском языках (электронный архив, документооборот, система управления структурой изделия, ИПИ, ИЛП и т.п.) приближается к критическому для понимания сути дела. Проблема заключается в том, что все специалисты, имеющие отношение к упомянутой теме, в каждую из перечисленных аббревиатур и сокращений вкладывают свой смысл, зачастую не очень понимая, как они связаны друг с другом.
Именно об этой проблеме мы и будем сегодня говорить.
Условно можно назвать две группы отраслей промышленности, в которых изначально используются разная терминология, принципы проектирования и оформления проектной документации:
Даже предмет проектирования в этих двух группах называется по-разному: в первом случае — «изделие», во втором — «объект». Однако такое разделение весьма условно: так, установка, стоящая на земле, — это объект, который строится на месте эксплуатации, а нефтедобывающая платформа — это изделие, изготавливаемое на заводе. Хотя их конструкция может быть одинакова.
Почти во всех случаях мы имеем дело со сложными техническими изделиями и объектами, которые состоят из огромного количества компонентов (корабль, атомный реактор, атомная или тепловая электростанция, нефтеперегонная установка, вооружение и т.п.), поэтому речь будет идти в основном о них. Хотя смею утверждать, что положения, приведенные в данной статье, справедливы и для менее технически сложных изделий и объектов (таких как холодильник или коттедж), разве что востребованность тех или иных информационных решений выглядит по-разному.
Как-то, читая журнал CADmaster, наткнулся на следующую фразу: «За годы работы стоимость архива организации может превысить стоимость всех остальных ее активов». С этим утверждением, бесспорно, можно согласиться: в историческом плане от деятельности любой организации, занимающейся разработкой, производством и эксплуатацией подобных изделий и объектов, в первую очередь, остаются архивы проектной и конструкторской документации. Давно ушли люди, стоявшие у истоков проектирования, могут исчезнуть и компании, которые этим занимались, а корабли и электростанции еще десятилетиями продолжают исправно работать, дома стоят столетиями, и в них живут люди. Поэтому проблема создания современных электронных архивов инженерной документации и обеспечения доступа к ним крайне актуальна.
Однако все объекты и изделия, как правило, состоят из множества компонентов, связанных между собой самыми разнообразными способами. И в первую очередь мы нуждаемся в информации о характеристиках этих компонентов, о способах их связи друг с другом. Например, для ремонта или замены насоса нам необходимо знать его габаритные размеры, потребляемую мощность, производительность, систему крепления и т.п.
Но современная конструкторская и проектная документация устроена таким образом, что человек может понять ее, только визуально просматривая. Поиск соответствующей информации также в большинстве случаев осуществляется визуально. А это накладывает определенные требования к организации архива. Можно утверждать, что в глобальном масштабе нам следует стремиться к созданию не электронных архивов инженерной документации, а систем хранения инженерных данных, в которых электронный конструкторский или проектный документ — необходимый, но далеко не единственный элемент хранения информации.
Приведем небольшой пример из опыта создания электронного архива одной очень уважаемой проектной организации Газпрома.
В промышленном и гражданском строительстве общепринятой является классификация проектных документов по маркам основных комплектов рабочих чертежей. Именно в таком виде сдается заказчику проектная документация.
Казалось бы, повторение этой классификации в электронном виде при построении структуры архива — естественный шаг. И да, и нет. С одной стороны, заказчик потребовал от нас сохранить в электронном архиве эту структуру марок, томов и альбомов. Но с другой — попросил сформировать другую. Структуру проектируемого объекта с доступом к той же проектной документации, которая находится в структуре, построенной по традиционному принципу.
Подробный анализ показал, что требовалось реализовать аж четыре структуры:
Таким образом, сформулируем основное требование современного заказчика: «Я должен иметь возможность быстро отыскать в электронном архиве всё, что мне нужно, поскольку в «бумажном» мне это не удается!» Попытки решить данную задачу, используя традиционные подходы, по крайней мере, неэффективны, а то и бессмысленны.
Сегодня в самых разных кругах обсуждаются проблемы информационного обеспечения жизненного цикла сложных изделий и объектов. Правда, во многих случаях эти обсуждения сводятся к вопросам информационного обеспечения логистической поддержки функционирования изделий/объектов и планирования технического обслуживания и ремонта (ТО и Р). А если проще — к задаче своевременной поставки запасных частей и принадлежностей (ЗИП) на эксплуатируемый объект. Причины этого упрощения понятны: такой подход наиболее востребован, особенно иностранными заказчиками. С нашей точки зрения, к вопросам создания электронных архивов конструкторской (проектной) документации следует подходить с позиций информационного обеспечения жизненного цикла. Ведь проектирование изделия или объекта и является важнейшим этапом реального жизненного цикла! Следовательно, чем больше информации на этом этапе будет введено в электронный архив (или систему хранения инженерных данных), тем более эффективным будет ее дальнейшее использование.
Таким образом, формирование электронного архива проектной организации следует рассматривать как первый этап создания системы информационного обеспечения жизненного цикла изделий и объектов. При этом абстрагируемся от проблем множественности организаций, участвующих в проекте, проблем секретности и безопасности, часто возникающих при проектировании и создании подобных изделий и объектов, от проблем разорванности целей участвующих организаций и т.п. Современные информационные и административные технологии могут позволить решить все подобные проблемы.
Попробуем проанализировать, какую же функциональность запрашивают заказчики, пытаясь сформулировать свои требования к системам электронного архива.
В статье «Ступени внедрения ИПИ-технологий" 3 мы попытались проанализировать последовательность внедрения ИПИ-технологий от электронного архива инженерной документации (TDM) до единой системы информационной поддержки жизненного цикла (PLM) (рис. 1).
Как видим, одной из ступеней является «единая среда проектирования изделий и объектов», предусматривающая формирование единого информационного пространства для работы всех участников технологического процесса. В этом информационном пространстве должна накапливаться вся информация по проекту в процессе его разработки.
Сегодня в среде проектировщиков появился термин «оперативный архив инженерной документации», в который, по сути, вкладывается тот же самый смысл, хотя «единая среда проектирования изделий и объектов», с нашей точки зрения, лучше отражает суть дела.
Опыт внедрения на различных предприятиях показал, что мы недооценивали важность этой ступени. Фактически все заказчики, произнося слова «электронный архив», имеют в виду не только архив долговременного хранения, но и оперативный архив. Причем востребованность последнего зачастую выше, чем архива долговременного хранения, хотя сформулировать к нему требования на порядок сложнее.
В обеих группах отраслей при традиционном проектировании применяются отображаемые на бумаге структуры изделий и объектов. В машиностроении и близких к нему отраслях основными документами являются спецификации, набор которых отражает структуру изделий, что и узаконено в ЕСКД. В промышленно-гражданском строительстве дело обстоит иначе. Согласно СПДС, спецификации и ведомости здесь — вторичные документы, сопровождающие чертежи.
На самом деле для отображения тех или иных изделий либо объектов в зависимости от поставленных нами целей используется множество структур. Наиболее яркий пример — судостроение. С точки зрения строителя корабль состоит из секций, изготавливаемых отдельно, и собирается из них. Команда рассматривает его как совокупность палуб и помещений, и совсем не интересуется, как они были построены. С точки зрения функциональности корабль состоит из множества систем жизнеобеспечения, вооружения и т.п., которые строитель должен создать, а команда — уметь эксплуатировать.
Таким образом, в идеальной системе должна быть обеспечена возможность формирования множества структур на основе одних и тех же данных и документов.
Подобный пример из области ПГС приведен выше.
При обсуждении проблем создания систем электронного архива мы много говорим о различных видах графических документов (сканированных, созданных в различных САПР и т.п.) и лишь мельком замечаем: «Ну и, конечно, офисные: текстовые и табличные (то есть в Word и Excel)». И при этом абсолютно забываем о сути этих «простых» офисных документов. А в них может оказаться множество технических данных о характеристиках изделия и/или его компонентов. Такая информация абсолютно необходима для дальнейших этапов жизненных циклов: для заказа компонентов при строительстве, для анализа возможностей замены, для той самой пресловутой задачи обеспечения информационной логистической поддержки. При традиционном подходе в создаваемом архиве оказываются неструктурированные документы, содержащие эти данные, распознать которые человек может только визуально.
На сегодняшний день реально внедрены самые разнообразные системы планирования. Наиболее распространены среди них MS Project и Primavera. Как только речь заходит о создании электронного архива, любой заказчик, у которого уже внедрена система планирования, начинает разговор об интерфейсе между ними. Психологически это совершенно понятно. Во-первых, структура работ тесно связана со структурой объекта или изделия, и если она уже в каком-либо виде существует, никто не захочет повторять проделанную работу еще раз.
Во-вторых, — и это, пожалуй, самое главное — процент исполнения той или иной работы заносится в систему планирования вручную на основе субъективной информации от исполнителя работы. Даже такая простая вещь, как передача из системы электронного архива в систему планирования простой информации о количестве документов, находящихся в определенном состоянии (например, на согласовании или утверждении), приводит заказчика в восторг — у него появляются объективные данные о ходе работы! А представьте себе, какая будет реакция, если будет выводиться информация по компонентной части, например о проценте компонентов технологической схемы, уже размещенных в трехмерной модели!
Cистема планирования связана не только со структурой проекта, но и с внедряемой системой технического документооборота, а именно — с подсистемой выдачи и обмена заданиями между главными инженерами проекта и отделами, а также между отделами, о чем речь пойдет ниже.
Заметим, что такие вопросы возникают при внедрении подобных систем уже сегодня.
Недавно меня пригласили проконсультировать консалтинговое предприятие по тематике, связанной с созданием электронного архива. Но на вопрос, какие системы автоматизированного проектирования будут использованы в проекте, я получил ответ, что ни проектант, ни тем более САПР еще не выбраны. Вопрос о рекомендуемой системе электронного архива отпал сам собой. То есть, конечно, создать склад абстрактных документов в абстрактной структуре не составляет труда (по большому счету, это и файловая структура ОС умеет), но толку от него не будет никакого. Мне, естественно, возразят: «А процедуры?.. А безопасность?.. А версии?.. А изменения?..» Все правильно, однако сама суть будет выхолощена: в лучшем случае получится электронный вариант традиционного архива с окошечком в двери — «документ сдал», «документ принял».
Количество специализированных САПР (в основном, построенных на базе стандартных) превышает всякие разумные пределы. Для примера просто полистайте каталоги нашей компании. Там и строительные САПР, и архитектурные, и по внутренней инженерии, и по внешней, и молниезащита, и черт знает что еще! И заметим, что все они создавались с одной понятной целью: максимально автоматизировать процесс проектирования в той или иной области. И эту цель они иногда решают очень успешно. Иногда не очень.
Но большинство используемых сегодня специализированных САПР абсолютно не готовы передавать информацию в единую систему хранения инженерных данных, то есть представляют собой «закрытые» системы, ориентированные не на передачу данных в другие подсистемы, а на выпуск конкретных инженерных документов. Хотя, что передавать, в общем-то, понятно: структуру проектируемых объектов и изделий, их технические характеристики, компонентный состав, технические характеристики компонент, возможно, взаимосвязи. И как передавать, вроде тоже ясно: существует уже фактически общепринятая технология XML-файлов.
За последнее десятилетие появился целый ряд САПР, которые используют идею систем баз данных для хранения инженерной информации и рассматривают документы как отображения этих баз в графическом или табличном виде. К сожалению, пока никто не придумал, как эти САПР должны взаимодействовать с другими. Например, некоторые известные системы проектирования технологических установок плохо взаимодействуют с архитектурно-строительными. Хотя следует признать, что уровень «открытости» этих САПР на порядок выше традиционных.
Вывод очень прост — если мы хотим строить некие единые сквозные (комплексные) системы проектирования, то должны, наконец, начать думать не только о сути задач, решаемых в той или иной САПР, но и о том, как и откуда взять необходимые исходные данные и куда и как передать полученную информацию, то есть обеспечить «открытость» этих САПР.
Огромное количество дискуссий ведется о трехмерном моделировании сложных объектов. Горы копий ломаются вокруг изменения мышления проектанта, автоматической генерации чертежей и их взаимосвязи с трехмерными моделями, автоматического получения программ для станков с ЧПУ и т.п. Множество мнений высказывается насчет автоматического получения из трехмерных моделей структуры изделия (или, по-простому, спецификации). Однако обсуждаемые проблемы на самом деле сводятся к вполне традиционным вопросам:
Но мы почему-то забываем, что кроме трехмерных моделей существует еще масса графических документов, из которых также надо извлекать структуры изделий, объектов и их компонентный состав. Это технологические схемы, электрические чертежи, чертежи КИП и, наконец, просто картинки, на которых в графическом виде представлены структуры изделий и объектов.
Между прочим, создавая трехмерные модели, в большинстве случаев компоновщик может использовать только те компоненты, которые уже включены в соответствующую технологическую или электрическую схему. А это означает, что при проектировании система хранения инженерных данных используется не только для сбора информации, но и для ее выдачи с целью дальнейшего проектирования.
С вопросом используемых САПР очень тесно связана проблема применения классификаторов стандартных изделий, комплектующих и материалов. Фактически во всех современных системах имеются свои классификаторы стандартных изделий и материалов. Однако в организациях существуют корпоративные классификаторы и разрешительные списки для конкретных проектов, которые теоретически должны отражаться в САПР. На базе этих классификаторов формируются спецификации и разнообразные ведомости (стандартных изделий, закупочные и т.п.). Если изначально при проектировании использованы не поставляемые или не удовлетворяющие техническим требованиям стандартные изделия и особенно оборудование, может потребоваться серьезное перепроектирование изделия или объекта. На более поздних стадиях жизненного цикла изделий/объектов эти ведомости служат основой при составлении ведомостей деталей и инструментов для обслуживания сложной техники. И надежность, и конкурентоспособность изделий оказываются в большой зависимости от доступности комплектующих для проведения ТО и ремонта.
Именно на этапе эксплуатации вопрос о стандартной кодификации ЗИП выходит на первый план. Но с точки зрения создания и настройки систем это административная проблема: необходим единый непротиворечивый подход к кодификации хотя бы на отраслевом уровне. И в предлагаемых системах такой подход может быть реализован.
Сегодня бросается в глаза несогласованность корпоративных классификаторов и разрешительных списков и классификаторов, применяемых в САПР и других прикладных программах (в частности, в расчетных). Ситуация может быть исправлена только принятием административного решения о ведении корпоративных (или отраслевых) классификаторов и созданием модулей отображения их в форматах, используемых конкретными САПР и другими прикладными программами.
Находиться эти корпоративные классификаторы должны всё в той же корпоративной системе хранения инженерных данных, куда должны входить в первую очередь атрибутивные данные по конкретным стандартным изделиям, а во вторую — варианты их представления в различных САПР.
Замечу, что регламент выдачи заданий обычно не прописан, а если и прописан в документах по сертификации системы управления качеством по ИСО 9002, то не выполняется. Именно внедрение технического документооборота и обеспечивает в полной мере выполнение регламентов по ИСО 9000.
Если решение вопроса электронного согласования заказчик подразумевает «по умолчанию», то вот вопрос электронного утверждения в силу юридических аспектов обычно ставит его в тупик.
Когда мы начинаем разговор о техническом документообороте, рано или поздно заходит речь и о документообороте административных документов. Тут следует иметь в виду два существенных момента:
Одним из принципиальнейших вопросов остается вопрос о легитимности документов и данных. В конце 2006 года наконец были приняты ГОСТ 2.051−2006 (Электронные документы. Общие положения) 4 об электронных документах и ГОСТ Р 34.10−2001 о формировании электронной подписи 5. Но последний реально пока не используется. Чтобы вывести электронную подпись на уровень взаимодействия между предприятиями, их сети должны быть подключены к центрам сертификации, чему иногда препятствуют службы безопасности предприятий. Пока речь идет об электронной подписи на электронных документах в том или ином виде, все более-менее понятно. Но ГОСТ 2.051−2006 (п. 4.4) оговаривает использование электронной подписи и для легитимизации трехмерных моделей (как агрегированного электронного документа). На сегодняшний день это никем не используется и трехмерные модели трактуются как справочная информация, однако понятно, что в ближайшее время вопрос их легитимности встанет очень остро. Предположительно это произойдет, как только возникнет и будет востребована возможность обмена трехмерными моделями между предприятиями.
Еще один серьезнейший вопрос — легитимность систем хранения инженерных данных. Существует ряд САПР (и не только САПР), в которых документы — это отражение состояния накопленных баз данных. То есть конструктор, инженер или проектировщик в процессе проектирования тем или иным способом вводит инженерные данные в СУБД. По окончании проектирования осуществляется выпуск традиционной конструкторской и проектной документации. Это означает, что одновременно с утверждением документации должно происходить и «утверждение» (или «подписание») базы данных, на основе которой эта документация создается. Таких систем уже немало, наиболее известны TechnologiCS, PLANT-4D и ряд других. А кто отвечает за корректность данных, на которых основываются документы? Сегодня нормативные документы ответа на этот вопрос не дают.
Возможность хранения версий документов считается одной из принципиальных в системах электронного архива и электронного документооборота инженерной документации. Когда речь идет об одном документе, все более-менее понятно. Но ведь он существует не сам по себе, а входит в некий комплект или альбом. И что, у нас появляется новая версия альбома? И так далее, вплоть до самого верхнего уровня — у нас новая версия изделия? Да и сами процедуры проведения изменений, в общем, нетривиальны — загляните в ГОСТы. А уж то, что такие процедуры не имеют никакого отношения к существующим реалиям автоматизированного проектирования, это точно. И отговорки про простую замену файла документа и сохранение предыдущей версии тоже не более чем отговорки.
Вопрос об инструментальной, то есть о такой стандартной поставляемой информационной системе, на базе которой будет строиться конкретная система электронного архива для конкретного предприятия, воспринимается заказчиками очень болезненно. Основное заблуждение — это твердая уверенность, что в инструментальной системе уже есть все, что необходимо заказчику. Реально же стоимость работ по внедрению подобных систем, по нашим оценкам, колеблется от 30% до 500% от стоимости инструментальной системы, в зависимости от требуемой функциональности. Инструментальные системы отличаются функционалом, привязанностью к той или иной САПР (с которой они обычно имеют общего производителя), распространенностью в той или иной отрасли и ценой. С нашей точки зрения, при сегодняшнем уровне интеграции с САПР принципиальными аргументами в пользу выбора той или иной инструментальной системы являются распространенность в отрасли, цена и, самое главное, внедренческий опыт предполагаемого исполнителя работ.
Я сознательно не привожу названия конкретных инструментальных систем, представленных на отечественном рынке, поскольку уже давно убедился, что их выбор в большинстве случаев — дело не науки, а любви и прецедента.
Итак, из вышесказанного следует, что количество нюансов превращает задачу создания системы электронного архива и документооборота в слабо формализуемую. Обычно заказчик начинает разговор с «аналога» бумажного архива, однако уже вскоре понимает, что всё значительно сложнее. И такая ситуация, к сожалению, повторяется фактически на каждом предприятии.
Поэтому попробуем сформулировать концепцию разработки систем электронного архива:
На рис. 2 представлена структура подобной системы в том виде, в котором она представляется нам сегодня.
 |
 |
 |
 |
 |
 |
Несомненно, стратегическое принятие решений по указанным вопросам, утвержденное на высшем административном уровне заказчика, обеспечит минимизацию проблем при внедрении.
На наш взгляд, прежде чем приступать к работам по внедрению электронного архива и электронного документооборота, следует задать заказчику ряд вопросов.
1. Собираетесь ли Вы строить только электронный архив долгосрочного хранения готовой документации или Вам необходим оперативный архив (единая система проектирования изделий и объектов)?
2. Собираетесь ли Вы строить систему электронного архива инженерной документации (конструкторской, технологической, проектной и т.п.) или Вам нужна система хранения инженерных данных?
3. Собираетесь ли Вы использовать электронную подпись?
4. Собираетесь ли Вы использовать возможности трехмерного проектирования?
5. Собираетесь ли Вы использовать ассоциативную связь между 3D-моделью объекта (изделия) и двумерной документаций (чертежами)?
6. Необходимо ли Вам создание в рамках единой системы проектирования корпоративного классификатора стандартных изделий, комплектующих и материалов?
7. Какую систему проведения изменений Вы собираетесь использовать?
8. Хотите ли Вы автоматически отслеживать изменения во всех связанных документах и 3D-моделях?
9. Требуется ли Вам документооборот, обеспечивающий согласование и утверждение документов и 3D-моделей?
10. Требуется ли Вам документооборот, обеспечивающий распределение заданий между главными конструкторами (ГИП) и отделами, а также между отделами?
11. Требуется ли Вам подключение административного документооборота к системе технического?
12. Требуется ли Вам взаимодействие между электронным архивом и существующей системой планирования с точки зрения согласования плана проектных работ и структуры объекта (структуры комплектов документов)?
13. Требуется ли Вам взаимодействие между электронным архивом и существующей системой планирования с точки зрения получения объективной информации о ходе выполнения работ, например, о статусе документов?
14. Требуется ли Вам взаимодействие между системой технического документооборота и системой планирования с точки зрения автоматизации планово-диспетчерской деятельности, обмена заданиями между специальностями?
Это далеко не все вопросы, ответы на которые следует получить у заказчика. Требуется целый ряд количественных показателей объемов проектирования, тиражирования и хранения, сведения о необходимости конвертации бумажного архива, списки применяемых САПР и другого прикладного программного обеспечения, используемых систем ERP, финансовых и систем планирования и многое другое. Только после ответов на эти вопросы можно предварительно оценить стоимость проекта внедрения системы электронного архива и/или системы хранения инженерных данных.
Заметим, что подробные функциональные спецификации (то есть техническое задание) можно получить только после тщательного обследования предприятия заказчика бизнес-аналитиками, специализирующимися в этой области.
В этой статье я попытался отразить наш опыт внедрения систем электронного архива и электронного документооборота инженерной документации. Сначала нам казалось, что никаких особых сложностей быть не должно. Жизнь показала, насколько это мнение ошибочно. Я абсолютно уверен, что в будущем реально востребованными окажутся только системы хранения инженерных данных. А системы электронного архива следует рассматривать как первый шаг в этом направлении.
Эл. версия "CADmaster" 3, 2008 г.
вернуться к
списку