Розробка внутрішнього регламенту по роботі з проектною документацією

Зміст внутрішнього регламенту

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

Внутрішній регламент може включати в себе наступні розділи:

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

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

Облік проектних документів. У цьому розділі доцільно описати порядок обліку тільки проектних документів.

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

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

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

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

Відео: Слово Експертові 68. Експертиза проектної документації // Експертиза проектів

У табл. 2 наведений приблизний правила кодифікації проектних документів.

З метою спрощення ідентифікації та класифікації шифри проектної документації присвоюються за таким правилом:

Приблизний шифр проекту: P_F_TTT_ NNN _YYYY-MM-DD,

де:

P - код проекту;

F - код фази проекту;

TTT - тип документа;

NNN - порядковий номер документа;

YYYY-MM-DD - дата створення документа в форматі РРРР-ММ-ДД.

наприклад: АСДОУ.1.ТЗ.001.2012.11.01,

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

Структура електронного проектного репозитария

Варто також описати вимоги до розміщення документів.

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

Відео: Автономна газифікація, газопостачання, газовий котел, терморегулятор

Документи в папках 1-3 необхідно розміщувати в двох форматах: форматі PDF і в форматі програми, використаної для розробки документа (MS Word, Excel, Power Point і т.д.), в папці 4 - тільки в форматі програми, використаної для розробки документа. Окремо слід закріпити періодичність розміщення документів.

Наприклад, щотижня до 15.00 п`ятниці, а в разі гострої необхідності документ направляється за запитом по електронній пошті.

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

Наприклад, логічно припустити, що технічна документація на СЕД буде зберігатися у відділі ІТ, вхідні / вихідні листи по проекту - в канцелярії і т.д.

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

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

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

Розглянемо докладніше нюанси і вимоги щодо заповнення даного шаблону.

Найменування документа: повне найменування документа (наприклад, «Технічне завдання на створення автоматизованої системи документаційного забезпечення управління»).

Шифр документа: шифр документа, зазначений на титульній сторінці документа (наприклад, «АСДОУ.1.ТЗ. 001»).

Автор документа: прізвище, ініціали автора документа (наприклад, «Федорова І.А.»).

Версія: версія документа (наприклад, «версія 3»).

Ітерація: порядковий номер ітерації узгодження документа (наскрізна нумерація). Цей параметр дуже істотний: крім того, що може бути кілька версій документа, може бути і декілька ітерацій узгодження.

            № вих., Дата відправки: вихідний номер і дата листа, яким був направлений документ (наприклад, №00-11 від 11.01.2012).

            № вх., Дата отримання: вхідний номер і дата реєстрації листа в організації, до якої передано лист (наприклад, №000-00-00 від 12.01.2012).

Виконавець: ПІБ працівника, у якого знаходиться в роботі документ.

Термін узгодження (план): плановий термін відповіді на лист відповідно до статуту проекту.

Термін узгодження (факт), № вих., Дата: вихідний номер і дата відповідного листа.

Статус: можливі статуси документа, а саме:

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

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

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

Наприклад, порядок приймання / здачі проектних документів (коротко закріплено в договорі підряду), місце зберігання паперових та електронних версій, порядок видачі копій / оригіналів необхідних документів і т.д.

Моніторинг. У цьому розділі потрібно описати схему моніторингу статусу документів.

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

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

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