Впровадження електронних архівів інженерної документації

1. Вступ Вже багато років в бесідах з представниками промислових підприємств найрізноманітнішого профілю...
2. Інформаційна підтримка життєвого циклу виробів / об'єктів
3. аспекти впровадження
4. Архів довготривалого зберігання і оперативний архів інженерної документації
5. Структури виробів і об'єктів
6. Атрибутивні дані компонентів
7. системи планування
8. Системи автоматизації проектування
9. Тривимірні моделі і двовимірні креслення і схеми
10. Класіфікаторі стандартних виробів, комплектуючих и матеріалів
11. адміністративний документообіг
12. Електронний підпис і легітимність
13. Версії і зміни
14. інструментальна система
15. попередні висновки
16. попереднє тестування
17. Висновок

Вступ

Вже багато років в бесідах з представниками промислових підприємств найрізноманітнішого профілю я стверджую, що в області ІТ немає більш заплутаного питання, ніж питання електронного архіву інженерної (технічної, конструкторської, проектної та т.п.) документації та системи електронного документообігу. Кількість абревіатур і скорочень для позначення цього поняття англійською (TDM, Workflow, PDM, PLM, CALS, PIM) і російською мовами (електронний архів, документообіг, система управління структурою вироби, ИПИ, ИЛП і т.п.) наближається до критичного для розуміння суті справи. Проблема полягає в тому, що всі фахівці, що мають відношення до згаданої теми, в кожну з перерахованих абревіатур і скорочень вкладають свій зміст, часто не дуже розуміючи, як вони пов'язані один з одним.
Саме про цю проблему ми і будемо сьогодні говорити.

визначення цілей

Умовно можна назвати дві групи галузей промисловості, в яких спочатку використовуються різна термінологія, принципи проектування та оформлення проектної документації:

• машинобудування, приладобудування, суднобудування, літакобудування, автомобілебудування і т.п .;
• блок галузей, які називаються промисловим і цивільним будівництвом (ПГС).

Навіть предмет проектування в цих двох групах називається по-різному: в першому випадку - «виріб», у другому - «об'єкт». Однак такий поділ досить умовно: так, установка, що стоїть на землі, - це об'єкт, який будується на місці експлуатації, а нафтовидобувна платформа - це виріб, що виготовляється на заводі. Хоча їх конструкція може бути однакова.

Майже у всіх випадках ми маємо справу зі складними технічними виробами і об'єктами, які складаються з величезної кількості компонентів (корабель, атомний реактор, атомна або теплова електростанція, нафтоперегінна установка, озброєння і т.п.), тому мова буде йти в основному про них . Хоча смію стверджувати, що положення, наведені в цій статті, справедливі і для менш технічно складних виробів і об'єктів (таких як холодильник або котедж), хіба що затребуваність тих чи інших інформаційних рішень виглядає по-різному.

Якось, читаючи журнал CADmaster, наткнувся на наступну фразу: «За роки роботи вартість архіву організації може перевищити вартість всіх інших її активів». З цим твердженням, безперечно, можна погодитися: в історичному плані від діяльності будь-якої організації, що займається розробкою, виробництвом і експлуатацією подібних виробів і об'єктів, в першу чергу, залишаються архіви проектної та конструкторської документації. Давно пішли люди, які стояли біля витоків проектування, можуть зникнути і компанії, які цим займалися, а кораблі і електростанції ще десятиліттями продовжують справно працювати, будинки стоять століттями, і в них живуть люди. Тому проблема створення сучасних електронних архівів інженерної документації і забезпечення доступу до них вкрай актуальна.

Однак всі об'єкти і вироби, як правило, складаються з безлічі компонентів, пов'язаних між собою найрізноманітнішими способами. І в першу чергу ми потребуємо інформації про характеристики цих компонентів, про способи їх зв'язку один з одним. Наприклад, для ремонту або заміни насоса нам необхідно знати його габаритні розміри, споживану потужність, продуктивність, систему кріплення і т.п.

Але сучасна конструкторська та проектна документація влаштована таким чином, що людина може зрозуміти її, тільки візуально переглядаючи. Пошук відповідної інформації також в більшості випадків здійснюється візуально. А це накладає певні вимоги до організації архіву. Можна стверджувати, що в глобальному масштабі нам слід прагнути до створення НЕ електронних архівів інженерної документації, а систем зберігання інженерних даних, в яких електронний конструкторський або проектний документ - необхідний, але далеко не єдиний елемент зберігання інформації.

Наведемо невеликий приклад з досвіду створення електронного архіву однієї дуже поважної проектної організації Газпрому.

У промисловому і цивільному будівництві загальноприйнятою є класифікація проектних документів по маркам основних комплектів робочих креслень. Саме в такому вигляді здається замовникові проектна документація.

Здавалося б, повторення цієї класифікації в електронному вигляді при побудові структури архіву - природний крок. І так і ні. З одного боку, замовник зажадав від нас зберегти в електронному архіві цю структуру марок, томів і альбомів. Але з іншого - попросив сформувати іншу. Структуру проектованого об'єкта з доступом до тієї ж проектної документації, яка знаходиться в структурі, побудованій за традиційним принципом.

Докладний аналіз показав, що потрібно реалізувати аж чотири структури:

• структуру об'єкта проектування;
• структуру документації по проекту;
• структуру стадій проекту;
• структуру документації за договорами (один проект може виконуватися за кількома договорами).

Таким чином, сформулюємо основну вимогу сучасного замовника: «Я повинен мати можливість швидко відшукати в електронному архіві все, що мені потрібно, оскільки в« паперовому »мені це не вдається!» Спроби вирішити це завдання, використовуючи традиційні підходи, по крайней мере, неефективні , а то і безглузді.

Інформаційна підтримка життєвого циклу виробів / об'єктів

Сьогодні в самих різних колах обговорюються проблеми інформаційного забезпечення життєвого циклу складних виробів і об'єктів. Правда, у багатьох випадках ці обговорення зводяться до питань інформаційного забезпечення логістичної підтримки функціонування виробів / об'єктів та планування технічного обслуговування і ремонту (ТО і Р). А якщо простіше - до задачі своєчасного постачання запасних частин і приладдя (ЗІП) на експлуатований об'єкт. Причини цього спрощення зрозумілі: такий підхід найбільш затребуваний, особливо іноземними замовниками. З нашої точки зору, до питань створення електронних архівів конструкторської (проектної) документації слід підходити з позицій інформаційного забезпечення життєвого циклу. Адже проектування вироби або об'єкта і є найважливішим етапом реального життєвого циклу! Отже, чим більше інформації на цьому етапі буде введено в електронний архів (або систему зберігання інженерних даних), тим ефективнішим буде її подальше використання.

Таким чином, формування електронного архіву проектної організації слід розглядати як перший етап створення системи інформаційного забезпечення життєвого циклу виробів і об'єктів. При цьому абстрагуємося від проблем множинності організацій, що беруть участь в проекті, проблем секретності і безпеки, часто виникають при проектуванні і створенні подібних виробів і об'єктів, від проблем розірваності цілей беруть участь організацій і т.п. Сучасні інформаційні та адміністративні технології можуть дозволити вирішити всі подібні проблеми.

аспекти впровадження

Спробуємо проаналізувати, яку ж функціональність запитують замовники, намагаючись сформулювати свої вимоги до систем електронного архіву.

Архів довготривалого зберігання і оперативний архів інженерної документації

У статті «Сходинки впровадження ИПИ-технологій" 3 ми спробували проаналізувати послідовність впровадження ИПИ-технологій від електронного архіву інженерної документації (TDM) до єдиної системи інформаційної підтримки життєвого циклу (PLM) (рис. 1).

Як бачимо, однією із ступенів є «єдине середовище проектування виробів і об'єктів», що передбачає формування єдиного інформаційного простору для роботи всіх учасників технологічного процесу. У цьому інформаційному просторі повинна накопичуватися вся інформація по проекту в процесі його розробки.

Сьогодні в середовищі проектувальників з'явився термін «оперативний архів інженерної документації», в який, по суті, вкладається той же самий сенс, хоча «єдине середовище проектування виробів і об'єктів», з нашої точки зору, краще відображає суть справи.

Досвід впровадження на різних підприємствах показав, що ми недооцінювали важливість цієї ступені. Фактично всі замовники, вимовляючи слова «електронний архів», мають на увазі не тільки архів довготривалого зберігання, а й оперативний архів. Причому затребуваність останнього часто вище, ніж архіву довготривалого зберігання, хоча сформулювати до нього вимоги на порядок складніше.

Структури виробів і об'єктів

В обох групах галузей при традиційному проектуванні застосовуються відображаються на папері структури виробів і об'єктів. У машинобудуванні і близьких до нього галузях основними документами є специфікації, набір яких відображає структуру виробів, що і узаконено в ЕСКД. У промислово-цивільному будівництві інша справа. Згідно СПДС, специфікації і відомості тут - вторинні документи, які супроводжують креслення.

Насправді для відображення тих чи інших виробів або об'єктів в залежності від поставлених нами цілей використовується безліч структур. Найбільш яскравий приклад - суднобудування. З точки зору будівельника корабель складається з секцій, що виготовляються окремо, і збирається з них. Команда розглядає його як сукупність палуб і приміщень, і зовсім не цікавиться, як вони були побудовані. З точки зору функціональності корабель складається з безлічі систем життєзабезпечення, озброєння і т.п., які будівельник повинен створити, а команда - вміти експлуатувати.

Таким чином, в ідеальній системі повинна бути забезпечена можливість формування безлічі структур на основі одних і тих же даних і документів.

Подібний приклад з області ПГС наведено вище.

Атрибутивні дані компонентів

Під час обговорення проблем створення систем електронного архіву ми багато говоримо про різні види графічних документів (сканованих, створених в різних САПР і т.п.) і лише мигцем помічаємо: «Ну і, звичайно, офісні: текстові і табличні (тобто в Word і Excel) ». І при цьому абсолютно забуваємо про суть цих «простих» офісних документів. А в них може виявитися безліч технічних даних про характеристиках вироби та / або його компонентів. Така інформація абсолютно необхідна для подальших етапів життєвих циклів: для замовлення компонентів при будівництві, для аналізу можливостей заміни, для тієї самої горезвісної завдання забезпечення інформаційної логістичної підтримки. При традиційному підході в створюваному архіві виявляються неструктуровані документи, що містять ці дані, розпізнати які людина може тільки візуально.

системи планування

На сьогоднішній день реально впроваджені найрізноманітніші системи планування. Найбільш поширені серед них MS Project і Primavera. Як тільки мова заходить про створення електронного архіву, будь-який замовник, у якого вже впроваджена система планування, починає розмову про інтерфейс між ними. Психологічно це цілком зрозуміло. По-перше, структура робіт тісно пов'язана зі структурою об'єкта або виробу, і якщо вона вже в будь-якому вигляді існує, ніхто не захоче повторювати виконану роботу ще раз.

По-друге, - і це, мабуть, найголовніше - відсоток виконання тієї чи іншої роботи заноситься в систему планування вручну на основі суб'єктивної інформації від виконавця роботи. Навіть така проста річ, як передача з системи електронного архіву в систему планування простий інформації про кількість документів, що знаходяться в певному стані (наприклад, на погодження або затвердження), призводить замовника в захват - у нього з'являються об'єктивні дані про хід роботи! А уявіть собі, яка буде реакція, якщо буде виводитися інформація по компонентної частини, наприклад про відсоток компонентів технологічної схеми, вже розміщених в тривимірній моделі!

Cистема планування пов'язана не тільки зі структурою проекту, але і з впроваджуваної системою технічного документообігу, а саме - з підсистемою видачі та обміну завданнями між головними інженерами проекту і відділами, а також між відділами, про що мова піде нижче.

Зауважимо, що такі питання виникають при впровадженні подібних систем вже сьогодні.

Системи автоматизації проектування

Нещодавно мене запросили проконсультувати консалтингове підприємство по тематиці, пов'язаної зі створенням електронного архіву. Але на питання, які системи автоматизованого проектування будуть використані в проекті, я отримав відповідь, що ні проектант, ні тим більше САПР ще не вибрані. Питання про рекомендовану системі електронного архіву відпало саме собою. Тобто, звичайно, створити склад абстрактних документів в абстрактній структурі не складає труднощів (за великим рахунком, це і файлова структура ОС вміє), але толку від нього не буде ніякого. Мені, звичайно, можуть заперечити: «А процедури? .. А безпеку? .. А версії? .. А зміни? ..» Все правильно, однак сама суть буде вихолощена: в кращому випадку вийде електронний варіант традиційного архіву з віконечком в двері - «документ здав», «документ прийняв».

Кількість спеціалізованих САПР (в основному, побудованих на базі стандартних) перевищує всякі розумні межі. Для прикладу просто погортайте каталоги нашої компанії. Там і будівельні САПР, і архітектурні, і по внутрішній інженерії, і по зовнішній, і блискавкозахист, і чорт знає що ще! І зауважимо, що всі вони створювалися з однією зрозумілою метою: максимально автоматизувати процес проектування в тій чи іншій області. І цю мету вони іноді вирішують дуже успішно. Іноді не дуже.

Але більшість використовуваних сьогодні спеціалізованих САПР абсолютно не готові передавати інформацію в єдину систему зберігання інженерних даних, тобто являють собою «закриті» системи, орієнтовані нема на передачу даних в інші підсистеми, а на випуск конкретних інженерних документів. Хоча, що передавати, в общем-то, зрозуміло: структуру проектованих об'єктів і виробів, їх технічні характеристики, компонентний склад, технічні характеристики компонент, можливо, взаємозв'язку. І як передавати, начебто теж ясно: існує вже фактично загальноприйнята технологія XML-файлів.

За останнє десятиліття з'явився цілий ряд САПР, які використовують ідею систем баз даних для зберігання інженерної інформації і розглядають документи як відображення цих баз в графічному або табличному вигляді. На жаль, поки ніхто не придумав, як ці САПР повинні взаємодіяти з іншими. Наприклад, деякі відомі системи проектування технологічних установок погано взаємодіють з архітектурно-будівельними. Хоча слід визнати, що рівень «відкритості» цих САПР на порядок вище традиційних.

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

Тривимірні моделі і двовимірні креслення і схеми

Величезна кількість дискусій ведеться про тривимірному моделюванні складних об'єктів. Гори копій ламаються навколо зміни мислення проектанта, автоматичної генерації креслень і їх взаємозв'язку з тривимірними моделями, автоматичного отримання програм для верстатів з ЧПУ і т.п. Безліч думок висловлюється щодо автоматичного отримання з тривимірних моделей структури вироби (або, по-простому, специфікації). Однак обговорювані проблеми насправді зводяться до цілком традиційним питань:

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

Але ми чомусь забуваємо, що крім тривимірних моделей існує ще маса графічних документів, з яких також треба витягувати структури виробів, об'єктів і їх компонентний склад. Це технологічні схеми, електричні креслення, креслення КВП і, нарешті, просто картинки, на яких в графічному вигляді представлені структури виробів і об'єктів.

Між іншим, створюючи тривимірні моделі, в більшості випадків компоновщик може використовувати тільки ті компоненти, які вже включені в відповідну технологічну або електричну схему. А це означає, що при проектуванні система зберігання інженерних даних використовується не тільки для збору інформації, але і для її видачі з метою подальшого проектування.

Класіфікаторі стандартних виробів, комплектуючих и матеріалів

З харчуванням вікорістовуваніх САПР дуже тісно пов'язана проблема! Застосування класіфікаторів стандартних виробів, комплектуючих и матеріалів. Фактично в усіх сучасних системах є свої класифікатори стандартних виробів і матеріалів. Однак в організаціях існують корпоративні класифікатори та дозвільні списки для конкретних проектів, які теоретично повинні відображатися в САПР. На базі цих класифікаторів формуються специфікації і різноманітні відомості (стандартних виробів, закупівельні і т.п.). Якщо спочатку при проектуванні використані не надані або не відповідають технічним вимогам стандартні вироби і особливо обладнання, може знадобитися серйозне перепроектування вироби або об'єкта. На більш пізніх стадіях життєвого циклу виробів / об'єктів ці відомості є основою при складанні відомостей деталей і інструментів для обслуговування складної техніки. І надійність, і конкурентоспроможність виробів виявляються у великій залежності від доступності комплектуючих для проведення ТО і ремонту.

Саме на етапі експлуатації питання про стандартну кодифікації ЗІП виходить на перший план. Але з точки зору створення та налаштування систем це адміністративна проблема: необхідний єдиний несуперечливий підхід до кодифікації хоча б на галузевому рівні. І в пропонованих системах такий підхід може бути реалізований.

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

Перебувати ці корпоративні класифікатори повинні все в тій же корпоративної системі зберігання інженерних даних, куди повинні входити в першу чергу атрибутивні дані по конкретним стандартним виробам, а в другу - варіанти їх подання в різних САПР.

Зауважу, що регламент видачі завдань зазвичай не прописаний, а якщо і прописаний в документах по сертифікації системи управління якістю за ІСО 9002, то не виконується. Саме впровадження технічного документообігу і забезпечує повною мірою виконання регламентів по ISO 9000.

Якщо вирішення питання електронного узгодження замовник має на увазі «за замовчуванням», то ось питання електронного затвердження в силу юридичних аспектів зазвичай ставить його в глухий кут.

адміністративний документообіг

Коли ми починаємо розмову про технічний документообіг, рано чи пізно заходить мова і про документообіг адміністративних документів. Тут слід мати на увазі два істотні моменти:

• спроби використовувати системи адміністративного документообігу для інженерного в більшості випадків залишаються безуспішними або незадовільними через великі обсягів інженерної документації і специфіки проблем, викладених вище;
• необхідно розділити адміністративний документообіг, що має відношення до інженерного (ТЗ, узгодження і т.п.) від власне адміністративного документообігу (кадрового, зарплатного і т.п.). Зрозуміло, що першу частину необхідно інтегрувати в інженерний документообіг, а другу можна включати, а можна і реалізовувати окремо - він не має тієї історичної цінності, про яку ми говорили вище. Хоча треба зазначити, що питання зберігання теж актуальне: кадрова, податкова, пенсійна й інша інформація зберігається десятиліттями.

Електронний підпис і легітимність

Одним з найпринциповіших питань залишається питання про легітимність документів і даних. В кінці 2006 року нарешті було прийнято ГОСТ 2.051-2006 (Електронні документи. Загальні положення) 4 про електронні документи та ГОСТ Р 34.10-2001 про формування електронного підпису 5. Але останній реально поки не використовується. Щоб вивести електронний підпис на рівень взаємодії між підприємствами, їх мережі повинні бути підключені до центрів сертифікації, чому іноді перешкоджають служби безпеки підприємств. Поки мова йде про електронний підпис на електронних документах в тому чи іншому вигляді, все більш-менш зрозуміло. Але ГОСТ 2.051-2006 (п. 4.4) обумовлює використання електронного підпису і для легітимізації тривимірних моделей (як агрегованого електронного документа). На сьогоднішній день це ніким не використовується і тривимірні моделі трактуються як довідкова інформація, однак зрозуміло, що найближчим часом питання їх легітимності встане дуже гостро. Імовірно це станеться, як тільки виникне і буде затребувана можливість обміну тривимірними моделями між підприємствами.

Ще один дуже серйозне питання - легітимність систем зберігання інженерних даних. Існує ряд САПР (і не тільки САПР), в яких документи - це відображення стану накопичених баз даних. Тобто конструктор, інженер або проектувальник в процесі проектування той чи інший спосіб вводить інженерні дані в СУБД. Після закінчення проектування здійснюється випуск традиційної конструкторської та проектної документації. Це означає, що одночасно із затвердженням документації повинно відбуватися і «твердження» (або «підписання») бази даних, на основі якої ця документація створюється. Таких систем вже чимало, найбільш відомі TechnologiCS, PLANT-4D і ряд інших. А хто відповідає за коректність даних, на яких ґрунтуються документи? Сьогодні нормативні документи відповіді на це питання не дають.

Версії і зміни

Можливість зберігання версій документів вважається однією з принципових в системах електронного архіву та електронного документообігу інженерної документації. Коли мова йде про один документ, все більш-менш зрозуміло. Але ж він існує не сам по собі, а входить в якийсь комплект або альбом. І що, у нас з'являється нова версія альбому? І так далі, аж до самого верхнього рівня - у нас нова версія вироби? Та й самі процедури проведення змін, в загальному, нетривіальні - загляньте в ГОСТи. А вже те, що такі процедури не мають ніякого відношення до існуючих реалій автоматизованого проектування, це точно. І відмовки про просту заміну файлу документа і збереження попередньої версії теж не більше ніж відмовки.

інструментальна система

Питання про інструментальну, тобто про таку стандартної продукції, що поставляється інформаційній системі, на базі якої буде будуватися конкретна система електронного архіву для конкретного підприємства, сприймається замовниками дуже болісно. Основна помилка - це тверда впевненість, що в інструментальній системі вже є все, що необхідно замовнику. Реально ж вартість робіт по впровадженню подібних систем, за нашими оцінками, коливається від 30% до 500% від вартості інструментальної системи, в залежності від необхідної функціональності. Інструментальні системи відрізняються функціоналом, прихильністю до тієї чи іншої САПР (з якої вони зазвичай мають загального виробника), поширеністю в тій чи іншій галузі і ціною. З нашої точки зору, при сьогоднішньому рівні інтеграції з САПР принциповими аргументами на користь вибору тієї чи іншої інструментальної системи є поширеність в галузі, ціна і, найголовніше, внедренческий досвід передбачуваного виконавця робіт.

Я свідомо не наводжу назви конкретних інструментальних систем, представлених на вітчизняному ринку, оскільки вже давно переконався, що їх вибір в більшості випадків - справа не науки, а любові і прецеденту.

попередні висновки

Отже, з вищесказаного випливає, що кількість нюансів перетворює задачу створення системи електронного архіву та документообігу в слабо формалізуються. Зазвичай замовник починає розмову з «аналога» паперового архіву, проте вже незабаром розуміє, що все значно складніше. І така ситуація, на жаль, повторюється фактично на кожному підприємстві.

Тому спробуємо сформулювати концепцію розробки систем електронного архіву:

• електронний архів інженерної документації - це перший крок до створення системи зберігання інженерних даних. Що, в свою чергу, є першим кроком до створення повномасштабної системи інформаційної підтримки життєвого циклу об'єктів і / або виробів;
• в зв'язку з цим особливого значення набувають модулі отримання інженерної інформації з різних САПР, розрахункових підсистем та інших прикладних систем; + Як наслідок, необхідні модулі генерації різних звітів, в першу чергу - специфікацій, відомостей, експлікаций і т.п. відповідно до використовуваних системами стандартизації;
• Важливе значення мають система проведення змін (ревізій) документів, моделей і даних, стратегія поширення цих змін по структурам об'єктів і виробів, а також управління однозначним відповідністю між моделями, документами і даними;
• інженерний і пов'язаний з ним адміністративний документообіг спільно з модулем зв'язку з системою планування забезпечують прозоре управління і контроль процесу проектування;
• величезне значення має стратегія використання електронного підпису по відношенню до документів, моделям і даними.

На рис. 2 представлена ​​структура подібної системи в тому вигляді, в якому вона представляється нам сьогодні.

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

попереднє тестування

На наш погляд, перш ніж приступати до робіт з впровадження електронного архіву та електронного документообігу, слід задати замовнику ряд питань.

1. Чи збираєтеся Ви будувати тільки електронний архів довгострокового зберігання готової документації або Вам необхідний оперативний архів (єдина система проектування виробів і об'єктів)?

• Нам потрібна тільки система електронного архіву довгострокового зберігання готової документації.
• Нам потрібна тільки система оперативного архіву (єдина система проектування виробів і об'єктів). Нам потрібні обидва компонента як єдиний електронний архів інженерної документації.

2. Чи збираєтеся Ви будувати систему електронного архіву інженерної документації (конструкторської, технологічної, проектної та т.п.) або Вам потрібна система зберігання інженерних даних?

• Нам потрібна система електронного архіву, що містить тільки інженерні документи в різноманітному вигляді (векторному, растровом, PDF, офісному і т.п.).
• Нам потрібна система накопичення інженерних даних, яка не тільки містить інженерні документи, а й дозволяє отримувати специфікації, відомості та інші необхідні табличні документи (фактично PDM-система).
• Нам потрібна система інформаційної підтримки життєвого циклу виробу (об'єкта), яка буде використовуватися на подальших етапах життєвого циклу (будівництво, виготовлення, експлуатація, ремонт і т.п.) (фактично PLM-система).

3. Чи збираєтеся Ви використовувати електронний підпис?

• Ні, не збираємося, ми плануємо зберігати скановані оригінали підписаних документів.
• Збираємося, але не сертифіковану, в рамках декількох підрозділів або нашого підприємства.
• Збираємося, сертифіковану в рамках нашого підприємства.
• Збираємося, сертифіковану в рамках групи підприємств (замовника, контрагента, будівельника, експлуатуючої організації і т.п.).

4. Чи збираєтеся Ви використовувати можливості тривимірного проектування?

• Ні, не збираємося.
• Збираємося в рамках обмеженої кількості підрозділів (3D-моделі окремих вузлів, подоб'ектов і т.п.).
• Збираємося в рамках побудови повної 3D-моделі об'єкта (вироби), але з обмеженим ступенем деталізації.
• Збираємося в рамках побудови повної 3D-моделі об'єкта (вироби) з повною деталізацією в моделі.

5. Чи збираєтеся Ви використовувати асоціативний зв'язок між 3D-моделлю об'єкта (вироби) та двовимірної документацій (кресленнями)?

• Ні, нам цього не потрібно.
• Так, нам потрібна однонаправлена ​​асоціативний зв'язок (від 3D-моделі до креслень).
• Так, нам потрібна двунаправленная асоціативний зв'язок.

6. Чи необхідно Вам створення в рамках єдиної системи проектування корпоративного класифікатора стандартних виробів, комплектуючих і матеріалів?

• Ні, нам цього не потрібно.
• Так, нам потрібен корпоративний класифікатор стандартних виробів і комплектуючих.
• Так, нам потрібен корпоративний класифікатор матеріалів.

7. Яку систему проведення змін Ви збираєтеся використовувати?

• Ми будемо замінювати документи цілком.
• Ми будемо використовувати традиційну вітчизняну систему повідомлень про зміни.
• Ми будемо використовувати традиційну вітчизняну систему повідомлень про зміни, але документи - заміняти цілком.
• Ми будемо використовувати західну систему ревізій.

8. Чи хочете Ви автоматично відстежувати зміни у всіх пов'язаних документах і 3D-моделях?

• Ні, не хочемо.
• Хочемо мати контроль, що сповіщає, які документи і 3D-моделі зачіпають зміни.
• Хочемо глобально відстежувати зміни у всіх пов'язаних документах і 3D-моделях.

9. Чи потрібна Вам документообіг, що забезпечує узгодження та затвердження документів і 3D-моделей?

• Ні, не потрібно.
• Потрібно лише для узгодження документів.
• Потрібно для затвердження документів.

10. Чи потрібна Вам документообіг, що забезпечує розподіл завдань між головними конструкторами (ГІП) і відділами, а також між відділами?

• Ні, не потрібно.
• Так, потрібно.

11. Чи потрібна Вам підключення адміністративного документообігу до системи технічного?

• Ні, не потрібно.
• Потрібно тільки в рамках адміністративного документообігу, що має безпосереднє відношення до інженерного.
• Так, потрібно в повному обсязі.

12. Чи потрібна Вам взаємодія між електронним архівом і існуючою системою планування з точки зору узгодження плану проектних робіт і структури об'єкта (структури комплектів документів)?

• Ні, не потрібно.
• Так, потрібно.

13. Чи потрібна Вам взаємодія між електронним архівом і існуючою системою планування з точки зору отримання об'єктивної інформації про хід виконання робіт, наприклад, про статус документів?

• Ні, не потрібно.
• Так, потрібно.

14. Чи потрібна Вам взаємодію між системою технічного документообігу і системою планування з точки зору автоматизації планово-диспетчерської діяльності, обміну завданнями між спеціальностями?

• Ні, не потрібно.
• Так, потрібно.

Це далеко не всі питання, відповіді на які слід отримати у замовника. Потрібно цілий ряд кількісних показників обсягів проектування, тиражування і зберігання, відомості про необхідність конвертації паперового архіву, списки застосовуваних САПР і іншого прикладного програмного забезпечення, що використовуються систем ERP, фінансових і систем планування і багато іншого. Тільки після відповідей на ці питання можна попередньо оцінити вартість проекту впровадження системи електронного архіву та / або системи зберігання інженерних даних.

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

Висновок

У цій статті я спробував відбити наш досвід впровадження систем електронного архіву та електронного документообігу інженерної документації. Спочатку нам здавалося, що ніяких особливих складнощів бути не повинно. Життя показало, наскільки ця думка помилкова. Я абсолютно впевнений, що в майбутньому реально затребуваними виявляться тільки системи зберігання інженерних даних. А системи електронного архіву слід розглядати як перший крок в цьому напрямку.