Электронный архив конструкторской документации

Содержание

Функциональные возможности решения

  • Совместное хранение в архиве отсканированных и электронных документов, в частности исходных документов формата среды разработки данного документа
  • Хранение заданий на проектирование или технических заданий, исходно-разрешительной документации, технических условий и т.д.
  • Хранение изыскательской документации – геодезии, геологии, гидрометеорологии и экологии
  • Хранение проектной документации, прошедшей государственную экспертизу
  • Хранение технической документации по изделиям, инструкций и эксплуатационной документации
  • Хранение регламентной и нормативной документации
  • Хранение рабочей документации: все марки чертежей, схем и текстовых документов
  • Хранение локальной и объектной сметной документации, исполнительной документации
  • Хранение любых других видов документов с возможностью настройки атрибутов карточек документов
  • Поддержка версионности документов, их связывание, средства поиска и формирования выгрузок
  • Предкэширование и сжатие изображений документов для работы по низкоскоростным каналам связи

Требования к электронным архивам проектной и конструкторской документации

От переводчика. В настоящее время наша компания ведет активную работу по созданию и внедрению систем электронного архива проектной и конструкторской документации. Начиная публикацию цикла статей по данной тематике, в который войдут как оригинальные тексты, так и переводные материалы, мы хотели бы предложить вниманию наших читателей статью Лена Аспри, австралийского специалиста в области ECМ, посвященную проблемам использования ECM-систем для работы с чертежами. Статья написана в 2006 году, но затрагиваемая в ней проблематика не утратила своей актуальности и сегодня: автор ведет речь о специфике чертежей как особого вида документов, о проблемах совместимости форматов хранения технической информации, о практических аспектах внедрения ECM-решений для работы с чертежами.
При переводе текстов по ECM-проблематике неизбежно встает проблема адекватной передачи терминологии. Для многих терминов достаточно сложно подобрать адекватные русские эквиваленты. Поэтому в переводе данной статьи мы в некоторых случаях сознательно отказываемся от калькирования английских выражений и передаем их при помощи уже закрепившихся в русском языке оборотов. Так, в некоторых случаях мы передаем аббревиатуру ECM (Enterprise Content Management) как СЭА (система электронного архива). Мы считаем этот шаг вполне оправданным, так как: (1) системы электронного архива принадлежат к классу ECM-систем; (2) в статье чертежи рассматриваются как записи (records), а термин «системы управления записями» (ERM, electronic records management) в русском языке не прижился, и для обозначения ERM-систем в русскоязычных публикациях гораздо чаще употребляется термин СЭА.

Чертежи являются носителями важной информации во многих государственных и коммерческих организациях, однако им еще не уделяется должного внимания при внедрении СЭА.
Чертежи важны уже потому, что они представляют такие активы предприятия, как здания, машины и оборудование. Вместе с технической документацией чертежи описывают эти активы.
Чертежи вполне можно рассматривать как записи, свидетельствующие о проектной и конструкторской активности, но при этом специалисты в области управления информации нередко недооценивают их важность, что зачастую подвергает организацию серьезному риску.
Нередко бывает так, что чертежам не уделяют внимания до возникновения чрезвычайной ситуации. К сожалению, в таких ситуациях нередко имеет место и потеря капитальных активов (Прим. перев.: работа по систематизации и переводу в электронный вид документации Саяно-Шушенской ГЭС началась лишь после печально известных событий августа 2009 года. В это же время наша компания оцифровывала проектные и технические документы Богучанской ГЭС).
Риск возникновения чрезвычайной ситуации может усугубляться в том числе и по причине неправильного обращения с чертежами. Например:

  • Чертежи в организации создаются с помощью CAD-программ, но затем распечатываются и отправляются на хранение в бумажном виде. Все изменения в проекте отображаются на бумажных чертежах.
  • Организация сканирует чертежи и использует цифровые копии в работе, но все надписи и отметки о выполнении работ делаются исключительно в бумажных вариантах чертежей.
  • Необходимо также понять, какие чертежи в организации являются контролируемыми, а какие — неконтролируемыми документами. Если цифровые чертежи являются контролируемыми, а бумажные — неконтролируемыми, то следует определить, каким образом осуществляется пересмотр чертежей и установка отметок о выполнении работ. И цифровая, и бумажная версия чертеже могут одновременно считаться контролируемыми документами. Но даже в этом случае должна быть четко продумана процедура синхронизации внесения изменений в документы.
    Следует четко описывать свойства чертежей. Метаданные чертежа могут включать его номер, название, номер версии, даты изменения и утверждения, и т. п. Свойства чертежа могут также включать классификационную структуру, которая может быть извлечена из внешней системы: например, место чертежа в ERP-системе предприятия.
    При внедрении системы электронного архива нужно учитывать и принятый в организации подход к нумерации чертежей. Необходимо, чтобы все использованные программы поддерживали принятую систему нумерации. То же самое касается системы нумерации версий чертежей.
    Исходя из специфики работы организации, ECM-специалист должен описать жизненный цикл чертежа и понять, какие свойства чертежа изменяются на каждой конкретной стадии жизненного цикла (номер версии и т. п.). Нужно также разобраться в том, кто и каким образом получает возможность просмотра, копирования, редактирования чертежа на разных стадиях работы.
    Получив представление о бизнес-процессах, о специфике изображенных на чертежах объектов и о соотношении разных форматов чертежей, ECM-специалист должен понять, каким образом внедрение СЭА позволит оптимизировать бизнес-процессы, расширить возможности обмена информацией и повысить качество работы.
    Следует рассмотреть возможность координации с другими информационными системами (с ERP-системами в частности), автоматизация процессов редактирования и утверждения чертежей, работы с различными форматами чертежей и т. п. И это — далеко не полный список.

Электронный архив технической документации, документооборот
и PDM — что дальше?

Николай Ширяев

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

Определение стратегических целей автоматизации

Выработка требований к системе автоматизации

Изучение рынка систем автоматизации, удовлетворяющих требованиям ТЗ

Расчет расходов на внедрение системы и данных о возврате инвестиций

Оценка надежности, уровня квалификации и перспективности вашего потенциального партнера в области автоматизации

Обследование предприятия и реорганизация бизнес-процессов

Внедрение

Изучение результатов внедрения и определение дальнейшей стратегии развития предприятия

А не написать ли нам свою систему?

Несколько слов в заключение

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

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

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

Определение стратегических целей автоматизации

Именно от этого в значительной мере зависит, будете ли вы и ваше руководство довольны результатами внедрения или же, наоборот, разочарованы.

В качестве примеров таких целей можно привести:

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

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

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

Запомните! Эффективное внедрение автоматизированной системы масштабов предприятий невозможно без выработки стратегической концепции развития предприятия в области автоматизации.

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

Выработка требований к системе автоматизации

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

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

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

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

Постарайтесь не отвлекаться на различные модные течения и рекламные обещания производителей. (Например, так ли вам будет нужен в ближайшие годы доступ к архиву через Internet, если ваши каналы связи обеспечивают соединение только на скорости до 28,8 Кбайт/с, средний размер файла составляет около 1 Мбайт, а специалистов, которые могли бы обеспечить защиту ваших данных от несанкционированного доступа хакеров, у вас нет? Возможно, до приведения каналов связи предприятия к современному уровню правильнее было бы работать в режиме удаленного доступа к системе.) Гораздо важнее четко сформулировать, как именно система должна работать и на какие стандарты опираться.

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

Изучение рынка систем автоматизации, удовлетворяющих требованиям ТЗ

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

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

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

Другой пример — возможность работы с RISC-серверами под управлением ОС UNIX в организации, избравшей в качестве стратегической платформы Wintel.)

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

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

Расчет расходов на внедрение системы и данных о возврате инвестиций

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

Оцените, какую экономию вы получите в результате внедрения системы.

Рассчитайте данные по возврату инвестиций (ROI), они послужат хорошим аргументом в разговоре с руководством или инвесторами. Если инвестиции не окупаются за 3-3,5 года, то, возможно, стоит подумать о более экономичном решении. Разумеется, при оценке экономической эффективности необходимо учитывать и неявные показатели. Например, сколько стоит предотвращение одной кражи ваших данных конкурентами или проигрыш крупного тендера из-за несоответствия вашего предприятия формальным требованиям к участникам (наличия сертификации по стандартам ISO 9000).

Оценка надежности, уровня квалификации и перспективности вашего потенциального партнера в области автоматизации

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

К сожалению, ориентироваться только на имя поставщика нельзя. Необходимо узнать количество сертифицированных специалистов в штате компании. Приоритетным является наличие сертифицированных специалистов по сетевым ОС, СУБД и САПР. Проверьте, насколько совпадает профиль имеющихся в распоряжении поставщика решений специалистов с планируемым вами к использованию ПО.

Поинтересуйтесь реальным опытом внедрения и сопровождения данной компанией подобных информационных систем.

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

Обследование предприятия и реорганизация бизнес-процессов

Если обследование предприятия не было сделано на начальном этапе, самое время заняться этим перед внедрением системы, разумеется с учетом ее реальных возможностей.

Позаботьтесь о сохранении и передаче в новую систему унаследованных данных.

Внедрение

Начните с внедрения пилотного проекта. Внедрять систему следует поэтапно.

Разработайте жесткий временной график внедрения и старайтесь ему следовать.

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

После доработки системы внедрение проводится в полном объеме.

Изучение результатов внедрения и определение дальнейшей стратегии развития предприятия

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *