Методологія формування бази технічної документації при спорудженні та здачі в експлуатацію
технологічно складного об'єкта
Фраза «хто володіє інформацією - володіє світом», несе в собі глибокий практичний сенс.
Забезпечення високої швидкості отримання інформації, її доступності, або, навпаки, недоступності, можливості групувати наявні дані в різні комбінації, передбачити наявність яких заздалегідь не завжди можливо, досягнення прозорості в справі управління проектом при тому достатку інформації, яке формується сьогодні під час спорудження та здачі в експлуатацію будь-якого технологічно складного об'єкта (наприклад, електростанції), являє собою нетривіальну задачу.
Спорудження технологічно складного об'єкта супроводжується величезною кількістю інформації. Ця інформація зосереджена в тисячах, сотнях тисяч і навіть мільйони документів. Вона носить різноспрямований характер, формує складний конгломерат. що складається з багатьох сотень тисяч груп, вузлів, що складаються, в свою чергу, як з окремих документів, так і з груп документів. Комплекс доступної інформації, як правило, представляється у вигляді бази (або декількох баз) даних, покликаної забезпечити простоту реалізації функції пошуку і обробки інформації.
У міжнародних нормах з інформаційної забезпеченості зазначено, що неподання необхідної інформації з будь-якого елементу або системі технологічного об'єкта протягом 15 хвилин на екрані комп'ютера і протягом 30 хвилин в паперовому варіанті говорить про її відсутність.
Існуючі методи організації пошуку і їх недоліки
Традиційно, в основу пошуку в існуючих програмно-технічних засобах закладений пошук по кодам та / або ключові слова, як окремих документів, так і груп документів.
До певного обсягу документації пошук по кодам дає хороший результат. Однак коли кількість символів в коді окремого документа, або групи документів перевищує 25-30 позицій, пошук ускладнюється. Причина даного явища полягає в тому, що поява великої кількості груп кодів зобов'язує формувати бібліотеку кодів, власний обсяг якої ускладнює пошук, і вимагає певної підготовки для користування інформацією цієї бібліотеки.
Не у кращому становищі і в разі організації пошуку за ключовими словами. Спорудження такого складного об'єкта, як теплова або атомна електростанція супроводжується великим обсягом проектної документації. Кількість комплектів робочих проектів може досягати 10-11 тисяч. А кількість виконавчих документів, що підтверджують виконання робіт за цими проектами, досягає сотень тисяч - мільйонів документів. Так як не існує загального каталогу назв робіт, що наводяться в цих документах, (його створення неможливо, зважаючи на величезну кількість варіацій назви робіт), то однакові за технологічним принципом роботи часто носять різний назву. Наприклад, робота з бетонування стін в одному акті звучить як «Бетонування стін», а в іншому як «Укладання бетону в стіни». Зустрічаються і такі, складні для організації пошуку по темі «бетонні роботи», назви як «Пристрій стін». В цілому, назва роботи в акті залежить від фантазії виконавця робіт або фахівця, що заповнює цей документ.
У зв'язку з тим, що часто, технологічно ідентичні документи носять різні назви, пошук за ключовими словами призводить до того, що витягується не вся наявна в базі даних інформація по предмету пошуку або, навпаки (наприклад, при розширенні зони пошуку), витягується теж що відноситься до предмету пошуку інформація.
За існуючою практикою, для оперативного контролю як стану інформації по об'єкту, так і стану самого об'єкта (ступеня завершеності), періодично, як правило, щомісяця, формуються звіти по документації, занесеної в бази даних. У різних організаціях для цієї мети існує безліч типових форм звітів. Однак, незалежно від досконалості бази даних, програмно-технічного засобу, в якому виконана база, структури звітів і т. П. Вибірка інформації для формування цих звітів носить суб'єктивний характер, якщо він зазнав впливу з боку людського фактора. Більш того, перевірити якість винесеною в звіти інформації дуже важко: для перевірки необхідно мати доступ до першоджерел, а він утруднений, оскільки вимагає, фактично, повторення роботи, виконаної при формуванні звіту. Той, кому доводилося стикатися з формуванням таких звітів, добре знайомий з проблемою суб'єктивності пошуку. Так, доручивши підготувати два однакових звіту двом фахівцям, ми отримаємо два відмінних (найчастіше, істотно відрізняються) один від одного документа.
В цілому, можна вказати, що підготовка звітів з використанням програмного продукту, що реалізує традиційну систему формування баз даних і організації пошуку в них, призводить, як мінімум, до неповноти одержуваної інформації. У той же час, неможливість надати вчасно необхідну інформацію практично завжди веде до фінансових втрат.
Проблеми формування комплектів виконавчої документації
Найбільш об'ємної і складної інформацією для організації в бази даних базується на інформації, представлена виконавчою документацією.
У нормативної та проектної технічної документації докладно викладено, якими виконавчими документами має супроводжуватися виконання робіт, Однак, не існує ніякої нормативної інформації, яка визначає принципи організації цих документів в бази даних.
Разом з тим, останнім часом практично у всіх укладених контрактах на спорудження або реконструкцію об'єктів в якості одного із зобов'язань генпідрядника наводиться вимога формування інформаційної бази даних по всій технічної документації. Крім того, в контрактах передбачається, що до здачі об'єкта за 10 днів до початку роботи комісії з приймання в експлуатацію кожного об'єкта генпідрядник передає виконавчий екземпляр проектної документації з письмовим підтвердженням відповідності фактично виконаних робіт проекту.
Формування бази даних виконавчої документації традиційними методами вимагає дуже високих трудозатрат, при цьому якість робіт завжди залишається низьким. Однією з причин, що обумовлюють високі трудовитрати при низьку якість, служить необхідність зв'язати воєдино велику кількість документів, що мають різний діапазон дії і знаходяться в різних комплектах, вузлах, проектах. Наприклад, для типового об'єкта енергетичного будівництва при постановці завдання якісного формування комплекту виконавчої документації, в разі неможливості забезпечення взаємозв'язку між документами, що мають різний діапазон дії і різне місцезнаходження, кількість документів в комплекті (з огляду на дублювання документів, що відносяться одночасно до кількох комплектів) зростає в 5 і більше разів. Без урахування трудовитрат приймальної комісії, величина яких майже порівнянна з трудомісткістю формування самого комплекту прийнятої виконавчої документації, середня існуюча трудомісткість формування комплекту, з розрахунку на один документ, становить цифру понад 3,5 чол / год.
Необхідність формування комплектів виконавчої документації
Виконання вимоги щодо формування виконавчого примірника проектної документації з письмовим підтвердженням відповідності фактично виконаних робіт проекту призводить до витрат, порівнянним з витратами на виготовлення самого проекту. На практиці це виливається в ігнорування вимоги формування виконавчого примірника проектної документації. При цьому якщо в РФ стан даної проблеми ще в недостатній мірі усвідомлено замовниками робіт, то на спорудженні зарубіжних об'єктів силами російських компаній невиконання цієї вимоги вже неодноразово приводило до великих фінансових втрат, пов'язаних з неповерненням так званих гарантій виконання (performance bond), що складають до 10 % від вартості спорудження об'єкта. У той же час, якщо з самого початку будівництва задати загальні правила формування виконавчої документації, то до моменту здачі об'єкта в експлуатацію замовник отримає в свої руки повну інформацію по спорудженому об'єкту, і підряднику можна буде уникнути великих фінансових втрат.
Передана підрядником інформація буде з успіхом використана також при експлуатації об'єкта. Необхідно відзначити, що, в першу чергу, в наявності комплекту виконавчої документації по об'єкту зацікавлений замовник робіт, тому процес формування бази даних виконавчої документації доцільно виносити за межі компетенції підрядника, відносячи його або до спеціалізованої організації, яка супроводжує діяльність замовника, або створюючи підрозділ по формуванню зазначеної бази даних в організації замовника.
Складність вирішення завдання формування повноцінної та якісної бази даних виконавчої документації полягає ще й в тому, що побудувати закінчену систему технічної документації, не маючи в наявності всієї документації, апріорі неможливо. Створення ж системи апостеріорі, для вже спорудженого об'єкта, коли є вся технічна документація, вимагає витрат, порівнянних з об'ємом гарантій виконання.
Суть пропонованого методу рішення
Незважаючи на велику складність, рішення вищевказаної задачі можливо і вже існує. Воно було випробувано в складі інформаційної системи для двох зарубіжних об'єктів атомної енергетики і добре зарекомендувало себе.
В основу розробленої системи закладений нетрадиційний механізм пошуку: по візуальному принципом. Пошук виконується на основі взаємозалежної системи графічних зображень від більшого обсягу до меншого (генплан> будівля> поверх> система> одиниця устаткування> зварений шов і т. Д.). Перехід між рівнями деталізації виконується за допомогою посилань. Кінцевою точкою пошуку служить група документів, об'єднаних загальним технологічним принципом, і, нарешті, сам документ, що зберігається в базі даних в відсканованому вигляді.
У частині ув'язки графічної основи і виконавчої документації використаний наступний підхід: всі елементи графічних зображень, для яких є в наявності виконавча документація (або графічна підсистема нижчого рівня, що містить виконавчу документацію), мають колір, відмінний від чорного (для чорного кольору мається на увазі відсутність виконавчої документації).
Вихідна система графічних зображень формується або на основі наданої проектною організацією документації в електронній формі, або, в разі наявності тільки паперового комплекту графічної документації, створення графічної основи бази даних виконується фахівцями організації, що супроводжує цю базу в процесі спорудження об'єкта. Необхідно відзначити, що кількість графічного матеріалу, необхідне для організації бази даних, відносно невелике, тому навіть у разі відсутності електронної форми креслень, трудовитрати на створення бази даних з використанням пропонованого підходу швидко окупаються.
Приклад реалізації запропонованого методу в програмній оболонці «Tracing»
На малюнках нижче дана ілюстрація процесу пошуку документації на основі запропонованого методу (скріншоти програми «Tracing», що реалізує вищеописаний принцип пошуку).
Розглянемо конкретний приклад монтажу технологічної системи в будівлі. Монтаж обладнання та трубопроводів даної системи, виконувався трьома організаціями, кожна з яких підтвердила закінчення своїх робіт підписанням відповідного акта. Поставимо задачу підтвердження або спростування факту готовності всієї системи в цілому.
Знаходимо потрібну будівлю на генеральний план будівництва (в нашому випадку машзал), клацаємо по ньому мишкою для переходу на наступний крок пошуку (рис. 1).
