Система електронного архіву д'Арен - перший крок до побудови системи управління проектними даними

1. І знову про термінологію Дана стаття продовжує висвітлення теми побудови систем управління проектними...
2. Про деякому практичному досвіді
3. Один із прикладів реалізації
4. Довідники
5. Автоматизація відвантаження ПКД замовникам
6. проведення змін
7. Звіти та автоматизоване формування деяких документів
8. Висновок
9. список літератури

І знову про термінологію

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

Ми спробували визначити «Ідеальну СУПД» як систему, що управляє всіма даними, реально існуючими в сучасних умовах (в проектних організаціях РФ), що враховує рівень автоматизації, розвиток нормативної бази, принципи проведення проектних робіт,
ментальність, традиції, наявність двох основних підходів (2D і 3D) і інші фактори.

Тепер уже за традицією починати процес викладу з приведення до єдиного розуміння термінів, докладніше зупинимося на здавалося б давно всім відомому понятті «Електронний архів» ... «Стоп! При чому тут електронний архів? Тема давно відома і детально висвітлена. І яке відношення це все має до СУПД? »- може вигукнути читач, згадавши« оскому »та інші характеризують цей термін епітети ... Але не будемо поспішати з висновками і все ж подивимося на електронний архів« під дещо іншим кутом ».

Для початку викладемо коротку концепцію і наше розуміння таких термінів, як «Електронний архів», «Електронний архів ПКД», «Електронний архів проектної організації».

Отже, під терміном «Електронний архів» будемо розуміти фізично впорядковане розміщення електронної інформації (можливо, в компактному вигляді) або створення такого уявлення для користувача (через відповідний інтерфейс) при відсутності реального фізичного упорядкування (наприклад, розподілені БД, хмарні технології і т.д .).

Як правило, крім упорядкованого розташування (зберігання), до електронного архіву висувається ряд вимог по організації пошуку, поділу прав доступу і т.д. Під терміном «Електронний архів ПКД» ми будемо розуміти «деталізацію» попереднього терміну з точки зору предмета «зберігання» - проектно-кошторисної документації. Проведемо такі уточнення:

• з точки зору ГОСТ 2.051-2006 (ЕСКД. Електронні документи. Загальні положення), будемо вести мову про електронну документації. Нагадаємо, що, відповідно до зазначеного ГОСТом, електронний документ включає як змістовну, так і реквізитний частини. Тобто «просто файл» без реквізитів електронним документом з точки зору ГОСТу не є. Є кілька способів реалізації змістовної і реквизитной частин.
Всі вони описані в наведеному Гості. Останнім часом найбільш часто реквізити записуються в таблиці СУБД;
• при створенні електронного архіву ПКД, як правило, існує необхідність автоматизації ряду бізнес-процесів, пов'язаних не тільки з розподілом прав доступу, пошуком в сховище, а й з поповненням (здаванням електронної документації), проведенням змін в електронній ПКД, відвантаження електронної ПКД, її тиражуванням і т.д. Іншими словами, існує якийсь «необхідний мінімальний набір функціоналу», без якого «Електронний архів ПКД» перетворюється в «просто Електронний архів», визначення якого дано вище.

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

• ОРД, листування;
• субпідрядну документацію (не обов'язково ПКД);
• документацію, яка містить інформацію про виробах, устаткуванні, матеріалах і постачальників;
• нормативи;
• документи планування;
• іншу інформацію і електронні документи, які використовуються в процесі діяльності проектної організації.

Перераховані типи інформації, що зберігається часто включають проектні дані, які можуть міститися як в структурованому, так і в неструктурованому вигляді. Нічого не нагадує? Для тих, хто не знайомий зі змістом попередньої статті, нагадаємо, що ми дозволили собі дати визначення «Ідеальною СУПД» і сформулювати необхідні функції, ключовий з яких є «управління всіма типами проектних даних, реально існуючими в сучасних умовах (в проектних організаціях РФ) ». Таким чином, поняття «Електронний архів проектної організації» і «СУПД», які могли б здатися спочатку «абсолютно не пов'язаними», безсумнівно, мають «щось спільне». Що саме? Про це мова піде далі.

Про «відносинах» між електронним архівом проектної організації і СУПД ...

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

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

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

• система електронного архіву (визначення дано раніше), як правило, не представляє дуже великий інтерес для проектної організації в зв'язку з відсутністю автоматизації «мінімально необхідного набору» бізнес-процесів: поповнення, проведення змін, відвантаження ПКД. Тому, на наш погляд, «мінімальної ступенем» автоматизації може стати система електронного архіву ПКД;
• системи електронного архіву ПКД та електронного архіву проектної організації аж ніяк не є в повній мірі СУПД;
• при впровадженні та подальшому розвитку електронного архіву в проектних організаціях неминуче виникають завдання, «близькі» або повністю відповідають завданням, що розв'язуються СУПД;
• виходячи з існуючих реалій, насамперед наявності великої кількості неструктурованих проектних даних, що містяться в електронних документах, система електронного архіву ПКД є неминучим кроком до системи електронного архіву проектної організації (див. Визначення вище);
• система електронного архіву проектної організації, в свою чергу, містить ряд елементів СУПД і є необхідним кроком, сходинкою до СУПД.

Про деякому практичному досвіді

Далі перейдемо в практичну площину нашого викладу, і поговоримо про реалізацію першого ступеня СУПД.

Залежно від обсягів інформації, прийнятих принципів проектування, ступеня автоматизації, що використовуються САПР, і інших чинників, існують р азлічних підходи до створення СУПД. Про це ми вже писали. Наприклад, на відповідних проектах можна намагатися будувати повноцінну СУПД, використовуючи лінійку САПР і механізм обміну даними (як правило, від виробника цієї ж лінійки САПР). Прикладами таких рішень можуть служити лінійки від Intergraph, Bentley, Autodesk з відповідними механізмами SmartPlant Fondation, Bentley ProjectWise, Autodesk Vault. При цьому «неминучість» еволюційного кроку - електронного архіву проектної організації - на перший погляд може бути поставлена ​​під сумнів. Однак, на наш погляд, «відмирання» еволюційної гілки - електронного архіву проектної організації - цілком можливо, але при виконанні необхідної умови: всі учасники процесу забезпечення всіх стадій ЖЦ об'єкта переходять на роботу з електронною інформацією в рамках єдиної інформаційної моделі, легітимність якої в цілому і легітимність всіх «відчужених» даних і документів забезпечується сучасним законодавством ... Пропонуємо читачам навести приклад в області ПГС хоча б одного такого об'єкта ...

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

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

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

2. Підсистеми, що автоматизують необхідний мінімум процесів першого ступеня створення СУПД:
• підсистема побудови структур ПКД відповідно до нормативних документів РФ;
• підсистема поповнення;
• підсистема проведення змін;
• підсистема відвантаження замовникам;
• підсистема звітів;
• сервісні підсистеми:
- довідники,
- автоматизоване формування
- деяких ПКД,
- запис на CD,
- підсистема замовлення-нарядів (облік роботи з документацією - тиражування, сканування і т.д.),
- інше.

Один із прикладів реалізації

Перерахований функціонал «універсальний» для більшості проектних організацій в області ПГС. Тому в нашій компанії створено базисне рішення - система д'Арен, яка успішно впроваджується в проектних організаціях і відповідає викладеним в статті підходам. Весь функціонал д'Арен реалізований компанією InterCAD в середовищі програмного комплексу TDMS (розробки компанії CSoft Development).

Безсумнівно, навіть при впровадженні такого типизированного рішення неминучі деякі коригування процесів, але, на наш погляд, вони в масштабах організації-замовника несуттєві. Наведемо невеликий приклад: в більшості проектних інститутів архівний номер документа присвоюється в архіві під час приймання документа. У деяких організаціях (зустрічається в області ПГС рідко) архівний номер «бронюється» проектувальником заздалегідь з якогось діапазону. Наш досвід дозволяє впевнено стверджувати наступне: для підприємства в більшості випадків дешевше і швидше відкоригувати бізнес-процес, обгрунтуванням якого є лише те, що «так історично склалося». Хоча при необхідності ми готові внести зміну і в «типізацію».

Детальніше розглянемо реалізацію функціоналу «першого ступеня» в системі д'Арен.

Довідники

Як і будь-яка інформаційна система, що вимагає роботи з класифікується інформацією, система д'Арен має ряд довідників, а саме:

• контрагентів;
• договорів;
• об'єктів;
• інші.

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

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

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

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

Наведемо лише один приклад, наявність якого, по-перше, представить Систему у вигідному світлі в очах ГИПа, а по-друге, пояснить, навіщо потрібна інформація про договори і дасть пояснення до рис. 1.

Використовуючи зв'язки між елементами структур, можна простежити:

• якими актами закритий договір (додаткова угода) або етап;
• які накладні на відвантаження ПКД були сформовані (пов'язані з актами);
• які з накладних були передані;
• які накладні повернуті;
• які комплекти були відвантажені.

При цьому здійснимо перехід безпосередньо до документів комплекту з усіма змінами (зміненими документами та дозволами на їх проведення) і всією історією. Також можливий перегляд накладних і будь-якою пов'язаною інформації (про договір, про замовника і т.д.).
Крім інструментів побудови структур і зв'язків з договорами, додатковими угодами та етапами, для подання ПКД структурованої, згідно з вимогами Постанови № 87 від 16 лютого 2008 «Про склад розділів проектної документації та вимоги до їх змісту», система д'Арен має механізм автоматичного створення ієрархічної структури ПКД в залежності від стадії проведення проектних робіт, з автоматизованим заповненням назв і присвоєнням основних позначень.

Створена структура цілком може зажадати коригування, якщо, наприклад, вона надлишкова. Процес коригування доступний відповідному користувачеві д'Арен - ГІПу або його помічникові. Приклад фрагмента структури ПКД по «стадії Р» (доступно через призначений для користувача інтерфейс) наведено на рис. 2.

Поповнення БД Після створення структури документації в д'Арен використовується механізм поповнення електронного архіву ПКД. Процес включає:

• безпосередньо створення томів і комплектів в структурі ПКД (виконує начальник відділу / сектора);
• «наповнення» томів і комплектів безпосередньо розробленими документами;
• реєстрацію в технічному архіві (виконує користувач, який виступає в ролі працівника «Електронного архіву»), проведення необхідних перевірок;
• передачу ПКД в групу відвантаження, на роботі якої докладніше зупинимося пізніше.

Відзначимо, що в процесі роботи з підсистемою поповнення електронного архіву ПКД в системі д'Арен використовуються різні механізми, що дозволяють автоматизувати введення і виключити помилки. До таких механізмів відносяться: автоматизоване формування ряду атрибутів, використання формалізованих списків, довідників і т.д.

Наша практика показує, що на початковому етапі впровадження Системи часто доводиться вирішувати завдання введення не тільки знову розробляється ПКД, а й раніше розробленої та зберігається в електронному вигляді, наприклад на файлових серверах, DVD і т.д. Щоб позбавити замовника від рутинного введення, в д'Арен передбачений інструмент, настройка якого доступна користувачу з відповідними правами (адміністратору). Цей інструмент дозволяє здійснювати пакетний введення документів в БД із заповненням карток, використовуючи логіку найменування файлів (рис. 3).

Не будемо детально зупинятися на висвітленні питання. Відзначимо лише наступне: існує кілька технологій, що дозволяють здійснювати пакетний введення в БД. Ми маємо досвід їх використання. У д'Арен же реалізована одна з них. Ми готові запропонувати не тільки «вбудовану» в Систему функцію, а й інші, найбільш доцільні для конкретного випадку.

Автоматизація відвантаження ПКД замовникам

Після надходження томів / комплектів в групу відвантаження документації в рамках Системи автоматизуються наступні процеси:

• присвоєння архівних номерів;
• формування накладних на відвантаження (автоматизовано створюється бланк накладної встановленої форми);
• вивантаження з д'Арен в файлову систему або запис на CD для подальшої передачі замовнику.

Крім того, після повернення підписаної накладної в системі робиться відповідна відмітка, а підписаний бланк може бути відсканований і поміщений в Систему.

проведення змін

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

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

Ця можливість системи проілюстрована малюнками 4а, б, в.

Звіти та автоматизоване формування деяких документів

У разі наявності в базі даних інформації і всіх необхідних зв'язків дозволяє за умови грамотного використання механізму
запитів можливе отримання з неї будь-звітної інформації. Д'Арен не є винятком: аналітична інформація може представлятися у вигляді звітів із застосуванням призначеного для користувача інтерфейсу (перехід зі зв'язків і механізм збережених запитів-вибірок).

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

Висновок

На закінчення спробуємо сформулювати висновки:

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

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

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

список літератури

1. Риндін А., Тучков А. Системи управління проектними даними в області промислового і цивільного будівництва: наш досвід і розуміння. САПР та Графіка. 2013. № 2. C. 20-26.
2. Риндін А., Галкіна О., Благодир А., Кораго Н. Автоматизація потоків документації - важливий крок до створення ЄІП // REM. 2012. № 4. С. 42-48.
3. Чіковская І., Данилова Л., ляндія А. Перехід на тривимірну технологію проектування станцій Санкт-Петербурзького метрополітену на основі вертикальних рішень компанії Autodesk, Inc. // САПР і графіка. 2012. № 9. С. 108-112.
4. Малашкін Ю., Шатських Т., Юхов А., Галкіна О., Кораго Н., Риндін А., Фертман І. Досвід розробки системи електронного документообігу
в ВАТ «Гіпроспецгаз» // САПР і графіка. 2011. № 12. С. 96-98.
5. Долгальов Д. Обмін даними між різними системами // САПР і графіка. 2011. № 9. С. 73-75.
6. Тучков А., Максимов Н. Робота з даними на різних етапах життєвого циклу промислових об'єктів з використанням SmartPlant Enterprise // САПР і графіка. 2011. № 8. С. 2-5.
7. Воробйов А., Данилова Л., Ігнатов Б., Риндін А., Тучков А., Уткін А., Фертман І., Щеглов Д. Сценарій і механізми створення єдиного інформаційного простору // CADmaster. 2010. № 5. С. 48-51.
8. Санев В., Суслов Д., Смирнов С. Використання інформаційних технологій в ЗАТ «ЦНДІ суднового машинобудування» // CADmaster.
2010. № 3 (53). С. 29-32.
9. Данилова Л., Щеглов Д. Методологія створення єдиного інформаційного простору ракетно-космічної галузі // REM. 2010. № 6. С. 14-15.
10. Воробйов А., Пивоваров В., Щеглов Д., Алімов М., Ведерникова Т., Данилова Л., Риндін А., Тучков А., Фертман І. Концепція створення єдиного середовища проектування як перший етап забезпечення життєвого циклу виробів ( досвід ВАТ «КБСМ») // CADmaster. 2008. № 2. С. 18-20.
11. Грачов В. Сучасний стан справ з електронними архівами // CADmaster. 2008. № 2. С. 92-97.
12. Тучков А. Впровадження електронних архівів інженерної документації // CADmaster. 2008. № 3. С. 42-49.
13. Чіковская І. Тиха революція. Електронний кульман або інформаційна модель будівлі // CADmaster. 2008. № 3. С. 88-92.
14. Риндін А., Тучков А., Фертман І. Сходинки впровадження ІПІ- технологій. Досвід реализаци електронного документообігу // Матеріали конференції «Морінтех-практик інформаційні технології в суднобудуванні - 2006», 2006 р
15. Ведерникова Т., Смирнов С. Використання сучасних досягнень інформаційних технологій в ЦНДІ суднового машинобудування // CADmaster. 2005. № 5. С. 31-33.
16. Галкіна О., Риндін А., Рябенький Л., Тучков А., Фертман І. Побудова інформаційних моделей виробів суднобудування на різних стадіях життєвого циклу з елементами логістичної підтримки // Збірник доповідей конференції «Технології інформаційної підтримки життєвого циклу складних виробів в російській промисловості », 2004 р
17. Голованов В., Рябенький Л., Давиденко С., Острокопитов Д., Тучков А., Фертман І. Досвід впровадження комплексних програмно-апаратних рішень САПР і електронного архіву інженерної документації на суднобудівних підприємствах // Збірник доповідей конференції «Роль і значення "Адміралтейських верфей" в науково-технічному розвитку російського і світового суднобудування », 2004 р
18. Риндін А. Введення сканованих документів в електронний архів підприємства // CADmaster. 2003. № 1. С. 41-43.
19. Риндін А. Архів без запорошених полиць, або Способи організації архіву підприємства // JetInfo. 2002. 10/113.
20. Фертман І., Тучков А., Попов К. Апаратне забезпечення електронного технічного документообігу // CADmaster 2001. № 8/3.
21. Давиденко С., Павлович М. Реалізація системи конструкторського документообігу та вирішення проблеми тиражування документації в ЦКБ МТ «РУБІН» // CADmaster. 2000. № 5. С. 16-19.