У число проектно-кошторисної документації входить встановлений в нормативному порядку комплекс документів - проектна і робоча документація на будівництво (реконструкцію) об'єктів нерухомості, розроблена на підставі:
Умов, відображених в Початково-дозвільної документації;
- Технічного завдання;
- правил і норм, що діють на території РФ.
Містобудівна кодекс Росії встановив обов'язкову розробку для планованого будівництва, реконструкції проектної документації
. Причому на ділянку, в межах якого здійснюється будівництво, повинні бути оформлені права забудовника (інвестора).
У комплект проектних матеріалів входить текстова документація і графічна частина. Постанова Уряду Росії встановило комплектність проектної документації та її зміст. У текстових проектних матеріалах повинні бути:
- відомості про об'єкт, що будується,
- перелік інженерно-технічних рішень,
- Пояснювальна записка,
- посилання на нормативно-технічну документацію, яка регламентує підготовку проекту,
- проектні розрахунки, на підставі яких приймалися архітектурні рішення.
На кресленнях повинні бути відображені прийняті проектні рішення у вигляді планів, схем та інших документів, відображених в графічній формі.
На стадії узгодження проектна документація на будівництво узгоджується в уповноважених державних організаціях
На стадії узгодження проектна документація узгоджується в уповноважених державних організаціях Москви, де на неї видається позитивний висновок експертизи в порядку, регламентованому в законодавстві РФ і міста.
Узгодження проектної документації в Москві здійснює технічний замовник.
Експертиза проектної документації
Результат інженерних вишукувань і проект підлягають обов'язковій експертизі. З квітня 2012 р експертиза результату проектної документації може бути проведена як в формі державної, так і недержавної експертизи. Причому, висновок недержавної, має бути прийнято нарівні з державною експертизою.
Предмет експертизи - відповідність:
- вимогам технічних регламентів;
- результатами інженерних вишукувань;
- вимогам до змісту розділів такого роду документів;
- санітарним нормам;
- вимогам пожежної безпеки;
- вимогам з охорони пам'яток культурної спадщини.
Результат експертизи - висновок про відповідність (невідповідність) перерахованим вище вимогам.
Державну експертизу проводить орган виконавчої влади (підвідомче державна установа).
Недержавну експертизу можуть проводити юридичні особи, які відповідають вимогам, які встановлені в статті №50 Цивільного кодексу Росії.
Розділи проектної документації
У число розділів проектної документації повинні входити:
Пояснювальна записка.
Схема земельної ділянки.
Проект, розроблений архітектором і враховує економічні, соціальні, інженерні, функціональні, протипожежні, технічні та інші вимоги до об'єкту.
Об'ємно-планувальні рішення.
Відомості про інженерно-технічному забезпеченні та інженерному обладнанні, перелік технологічних рішень:
- електропостачання;
- водопостачання;
- водовідведення;
- вентиляція, опалення, кондиціонування, теплові мережі;
- мережі звязку;
- газопостачання.
Проект робіт по знесенню (якщо це необхідно).
Проект будівництва.
Перелік заходів для охорони навколишнього середовища.
Заходи для забезпечення пожежної безпеки.
Заходи для забезпечення доступу інвалідів.
Заходи, щоб вони відповідали вимогам з енергетичної оснащеності будівель приладами обліку.
Кошторис.
Інша документація в передбачених законом випадках.
Регламент управління проектами (корпоративний стандарт управління проектами) - це внутрішній нормативний документ в організації, який визначає підхід до управління проектами, програмами та портфелем. Основна частина регламенту присвячена опису процесу, ролей, відповідальностей і результатів (проміжних і остаточних). Регламенти зазвичай пишуться на підставі різних світових або локальних стандартів (PMBoK, PRINCE2, ISO 21500, ГОСТ 54 і т.д.). Будь-регламент містить в основі процеси, описані на основі стандартів, про які писалося раніше і за великим рахунком мало відрізняються один від одного. Специфіка по областям діяльності (ІТ, Будівництво і т.д.) досягається випуском додаткових додатків, уточнюючих деталі тієї чи іншої області, специфіки роботи.
Приклад регламенту управління проектами
Далі описано структуру регламенту управління проектами та наведено приклад для великих ІТ-компаній. Легенда наступна - існує Група Компаній (Група "PME"), до складу якої входить головна компанія (ВАТ "ГОЛОВНИЙ КОМПАНІЯ") і безліч дочірніх. І головний і дочірні мають мережу філій по країні. Одна з дочірніх компаній (ТОВ «ДОЧІРНЯ КОМПАНІЯ») є виконавцем (оператором) за проектами і відповідає за інформаційно-технологічне забезпечення всієї Групи компаній (проекти з розробки та впровадження інформаційних систем управління).
Регламент написаний досить докладно і дає основне розуміння (приклад) того, що саме пишеться в тих чи інших розділах, як самого регламенту управління проектами, так і всіх невід'ємних додатків (Статут проекту, План управління проектом, Опис змісту і т.д.). При використанні даного регламенту управління проектами для потреб своєї компанії, досить просто позбутися від зайвого і скорегувати пов'язані процеси. Регламент служить докладним прикладом написання такого роду документів і доступний для безкоштовного скачування. Завантажити регламент управління проектами можна в кінці статті за посиланням.
опис
Мета регламенту управління проектами за напрямками ІТЗ в ТОВ «ДОЧІРНЯ КОМПАНІЯ» (далі - Регламент) - сформувати єдиний підхід до управління проектами за напрямками інформаційно-технологічного забезпечення (далі - проектами), оператором за якими є ТОВ «ДОЧІРНЯ КОМПАНІЯ».
Завдання Регламенту:
- опис порядку проведення основних процедур управління проектами;
- розмежування функцій між учасниками процесу управління проектами;
- визначення вимог до складу документів, необхідних при проведенні процедур управління проектами;
- визначення термінів виконання функцій при проведенні процедур управління проектами.
Структура і опис регламенту управління проектами:
Регламент процесу управління проектами
за напрямками ІТЗ в
ТОВ «ДОЧІРНЯ КОМПАНІЯ»
1. Загальні положення
1.1. Вступ
В даному розділі описуються цілі і завдання регламенту і самого підходу до управління проектами. Даються посилання на основоположні документи, затверджені всередині організації та безпосередньо впливають на процеси даного документа (Наприклад верхнеуровневий документ - політика управління проектами).
наприклад:
Мета Регламенту процесу управління проектами - сформувати єдиний підхід до управління проектами за напрямками інформаційно-технологічного забезпечення (далі - проектами), оператором за якими є ТОВ «ДОЧІРНЯ КОМПАНІЯ».
Завдання Регламенту:
- опис порядку проведення основних процедур управління проектами;
- розмежування функцій між учасниками процесу управління проектами;
- визначення вимог до складу документів, необхідних при проведенні процедур управління проектами;
- визначення термінів виконання функцій при проведенні процедур управління проектами.
Мета процесу управління проектами - забезпечення досягнення цілей проектів при заданих ресурсних і часових обмежень.
Завдання вдосконалення процесу управління проектами:
- підвищення якості планування проектів;
- підвищення оперативності та забезпечення повноти контролю стану проектів, оцінки і прогнозування ходу їх виконання;
- забезпечення своєчасного реагування на можливі відхилення за завданнями, термінами, бюджету та якості, оперативного виявлення «вузьких місць» і прийняття превентивних дій.
1.2. Галузь застосування
В даному розділі описується область охоплення регламенту - то, на які структурні підрозділи (внутрішні та зовнішні) поширюється даний документ.
наприклад:
Дія цього Регламенту поширюється на всі структурні підрозділи апарату управління ТОВ «ДОЧІРНЯ КОМПАНІЯ» і філії в частині діяльності з управління реалізацією проектів ІТЗ.
У філіях ТОВ «ДОЧІРНЯ КОМПАНІЯ» управління проектами та портфелями проектів філій здійснюється відповідно до цього Регламенту та нормативно-регламентними документами, що розробляються в філіях і відображають особливості процесів управління в умовах конкретної організації.
1.3. Нормативні документи
Тут визначається перелік внутрішніх і зовнішніх нормативних документів, Які послужили основою для написання даного регламенту. На відміну від розділу "Загальні положення", де давалася посилання на політику, як первинний документ, в даному розділі перераховані внутрішні незалежні документи, але впливають на написання даного регламенту і зовнішні світові, локальні практики.
наприклад:
Цей Регламент розроблений на підставі наступних документів:
- Інвестиційна політика Групи «PME», затверджена рішенням Правління ВАТ «ГОЛОВНИЙ КОМПАНІЯ» від --. - .--;
- Положення про управління інвестиційною діяльністю в Групі «PME», затверджене рішенням Правління ВАТ «ГОЛОВНИЙ КОМПАНІЯ» від --. - .--;
- Методика оцінки ефективності проектів в області інформаційно-технологічного забезпечення, затверджена рішенням Правління ВАТ «ГОЛОВНИЙ КОМПАНІЯ» від --. - .--;
- Бюджетний регламент Групи «PME», затверджений рішенням Правління ВАТ «ГОЛОВНИЙ КОМПАНІЯ» від --. - .--.
При розробці Регламенту використовувалися рекомендації, що містяться в наступних методиках і стандартах:
- The Standard for Portfolio Management (PMI 2006);
- ANSI / PMI 99-001-2008. Project Management Body of Knowledge (PMBOK);
- Information Technology Infrastructure Library (ITIL);
- ISO / IEC 20000 Information Technology - Service Management;
- ДСТУ ISO / IEC 12207. «Інформаційна технологія. Процеси життєвого циклу програмних засобів »;
- ГОСТ 34.601-90 «Автоматизовані системи. Стадії створення »;
- ДСТУ ISO 9000: 2000;
- ГОСТ 54869-2011 « проектний менеджмент. Вимоги до управління проектом »;
- ГОСТ 54870-2011 «Проектний менеджмент. Вимоги до управління портфелем проектів »;
- ISO / ТО 10006: 1997 (Е). «Менеджмент якості. Керівництво якістю при управлінні проектами ».
1.4 Терміни, визначення та прийняті скорочення
Опис термінів і їх визначень використовуваних в цьому Регламенті, а також прийняті скорочення.
Перелік внутрішніх нормативних документів, на які може посилатися даний регламент, але не впливають безпосередньо на сам регламент.
2. Вимоги до об'єктів управління
2.1 Визначення об'єктів управління
Наводиться перелік об'єктів управління (див. Приклад нижче). Не завжди регламенти описують процеси, пов'язані з усіма основними об'єктами управління, найчастіше обмежуються проектом і роботою, а для Портфеля проектів випускають окремий регламент.
наприклад:
Об'єктами управління є:
- портфель проектів;
- проект / інвестиційний захід;
- підпроект;
- робота.
Категоріювання проектів вводиться з метою уніфікації системи управління проектами за рахунок виділення категорій проектів зі схожими властивостями і застосуванням до них типізованих процедур управління. В даному розділі визначаються категорії проектів в розрізі вартості і тривалості. Для певної категорії проектів прописується свої процеси. Для великих проектів більш формалізований і складний процес, для більш маленьких - простий. Також визначаються умови зміни пріоритетів проектів і їх категорії (деякі проекти стратегічно важливі для організації можуть бути не дорогими і короткостроковими, але категорія їм присвоюється найвища тому потрібен контроль за виконанням даних проектів).
2.3. Класифікація проектів
Класифікація проектів служить для забезпечення можливості аналізу портфеля проектів, формування звітності про реалізацію проектів в різних аналітичних зрізах. Класифікатор проектів - структурована сукупність ознак, що дозволяє відносити проект до тієї чи іншої групи.
наприклад:
Основними класифікаційними ознаками для угруповань проектів є:
- приналежність до Бізнес-сегменту організації - користувачеві / загальнокорпоративні проекту;
- приналежність до Бізнес-сегменту організації - балансоутримувачу результатів проекту ІТЗ;
- приналежність до напрямку діяльності ІТЗ;
- категорія проектів;
- обсяги інвестицій в проект;
- наявність оцінюваного економічного ефекту;
- організації-користувачі / Функціональні замовники проектів ІТЗ;
- організації - балансоутримувачі результатів проекту ІТЗ;
- куратори проектів;
- структурні підрозділи ТОВ «ДОЧІРНЯ КОМПАНІЯ», що реалізують проект.
2.4. Життєвий цикл проекту
В даному розділі перераховуються стадії життєвого циклу проекту.
наприклад:
Для цілей цього Регламенту в рамках життєвого циклу проекту виділяються наступні стадії:
- стадія запуску;
- стадія планування;
- стадія виконання;
- стадія завершення.
3. Учасники процесів управління проектами
3.1. Учасники процесів управління проектами
Перерахування учасників процесу управління проектами. Починаючи з окремих юридичних осіб (Наприклад дочірні компанії) і закінчуючи конкретними ролями (основними, немає потреби перераховувати всіх і необхідно ролі не плутати з посадами).
наприклад:
Основними учасниками процесу управління проектами в ТОВ «ДОЧІРНЯ КОМПАНІЯ» є:
- Рада з управління проектами;
- Відділ організації управління проектами;
- Відділ управління портфелем програм і проектів;
- Куратор проекту;
- Куратор проекту від ЦАУ (за проектом 3-й категорії, що реалізується філією);
- Керівник Проектного офісу (Проектної групи);
- Адміністратор Проектної офісу (Проектної групи);
- Власник ресурсу;
- Менеджер проектних ризиків;
- Власник ризику.
3.2. Функції з управління проектами
У табличній формі перераховуються всі ролі (починаючи з колегіальних органів і закінчуючи виконавцем) і їх функції. Таким чином за певними ролями також закріплюються сфери відповідальності в частині процесу управління проектами.
наприклад:
Рада з управління проектами:
- Формування пропозицій по призначенню Кураторів проектів, визначення категорій проектів;
- Координація запуску пов'язаних проектів, формування пропозицій щодо коригування дат запуску проектів;
- Розгляд звітності, аналітичних матеріалів за станом портфеля проектів;
- Розгляд Запитів на зміни за окремими проектами, управління конфігурацією змін в цілому по портфелю проектів;
- Підготовка рішень щодо перерозподілу інвестицій між окремими проектами і щодо коригування ліміту інвестицій по Товариству в цілому;
- Підготовка рішень в частині ресурсного забезпечення портфеля проектів;
- Ініціація дострокового завершення проектів.
Відділ організації управління проектами:
- Розробка проектів Наказів ТОВ «ДОЧІРНЯ КОМПАНІЯ» про реалізацію Інвестиційної програми в планованому році;
- Перевірка коректності введених в ІАС даних по проектам;
- Внесення даних до Реєстру Керівників Проектних офісів (Проектних груп);
- Аналіз звітних даних по проектам;
- Формування зведених звітів про стан і прогрес проектів, аналітичних звітів про стан портфеля проектів і його ресурсообеспеченности;
- Формування пропозиції за варіантами рішень по запитах на зміни параметрів проектів;
- Розробка прогнозів щодо реалізації проектів;
- Розсилка аналітичних матеріалів для розгляду членам Ради по управлінню проектами;
- Контроль виконання рішень щодо змін портфеля проектів.
Власник ресурсу:
- Узгодження Ресурсного плану;
- Прийняття рішень про притягнення до роботи в Проектному офісі (Проектної групі) конкретних співробітників;
- Розгляд представленої Керівником Проектної офісу (Проектної групи) інформації про ефективність роботи співробітників для проведення атестації проектного персоналу.
3.3. Вимоги до організаційної структури проектів
В даному розділі визначаються типові схеми організаційних структур проектів з диференціацією залежно від категорії проекту. Тобто для кожної категорії визначається своя організаційна структура. Це необхідно для спрощення процесу управління проектами в частині середніх і маленьких з метою визначення більш простого проходження даного процесу.
4. Опис процесів управління проектом
Основний розділ регламенту управління проектами, в текстовій формі або в табличній (більш легко читається варіант) якого дається покроковий опис всього процесу, ролей, термінів проходження етапів, визначаються проміжні результати. Залежно від категорії проекту цим Регламентом передбачаються різні процедури управління проектом і порядок їх виконання.
Процесами управління проектом є:
- запуск (відповідає стадії запуску в життєвому циклі проекту);
- призначення Кураторів проектів, категорирование і формування графіка запуску проектів;
- підготовка та видання наказів про запуск і реалізації проекту;
- розробка та затвердження Статуту проекту;
- введення даних про проект до Реєстру проектів ІАС.
- планування (відповідає стадії планування в життєвому циклі проекту);
- Формування Плану проекту (після запуску проекту) в першому річному циклі;
- формування деталізувати календарного плану, Ресурсного плану, Бюджету проекту та Плану витрат по інвестиційному проекту ІТЗ на плановані річні періоди, наступні за роком запуску проекту;
- Формування Бюджету проекту та Плану витрат по інвестиційному проекту ІТЗ на планований квартал / місяць;
- Укладання договорів.
- моніторинг і управління (відповідає стадії виконання в життєвому циклі проекту);
- моніторинг параметрів проекту;
- управління змінами параметрів проекту;
- моніторинг ризиків за проектом;
- моніторинг усунення недоліків за результатами дослідно-промислової експлуатації;
- управління трудовими ресурсами.
- управління змінами (відповідає будь-якій стадії життєвого циклу проекту);
- завершення договору;
- завершення етапу;
- завершення проекту.
- завершення (відповідає стадіях виконання та завершення в життєвому циклі проекту).
наприклад:
5. Опис процесів управління портфелем проектів
У разі, коли не запроваджена методологія управління портфелем проектів, можна її додатково і верхнеуровнево прописати в даному регламенті тому сама по собі система управління проектами має на увазі в кінцевому підсумку якусь консолідацію даних в портфель проектів і саме на підставі аналітики та звітності по портфелю проектів, приймаються управлінські рішення тактичного рівня. У той час, як на проектах приймаються рішення оперативного рівня.
В основному обмежуються наступними процесами управління портфелем проектів:
- формування звітності про стан портфеля проектів;
- формування зведеної звітності по портфелю проектів;
- формування звітності по динаміці реалізації проектів;
- формування прогнозів виконання портфеля проектів;
- формування звітів за показниками портфеля проектів;
- формування звітів по структурі портфеля проектів.
- аналіз звітності по портфелю проектів;
- управління змінами портфеля проектів;
- завершення окремих проектів;
- тимчасова зупинка реалізації окремих проектів;
- ініціація відкриття нових проектів.
6. Документування та зберігання Регламенту
В даному розділі визначають структурний підрозділ відповідальне за супровід даного регламенту і місце зберігання регламенту з управління проектами.
наприклад:
Контрольний примірник цього Регламенту зберігається в ООУП. Електронна версія цього Регламенту знаходиться на внутрішньому корпоративному порталі та доступна для читання всім користувачам.
7. Внесення змін до Регламенту
В даному розділі описуються ролі тих, хто може вносити зміни в даний регламент або через кого можна вносити ці зміни. Насправді тільки Проектний офіс (PMO) в праві фізично коригувати корпоративну методологію, тому що він відповідає за розвиток проектного управління всередині компанії. Також в обов'язки якої Проектної офісу входить своєчасне оповіщення всіх зацікавлених сторін про зміни. Затверджується регламент наказом генерального директора.
8. Розподіл Регламенту
Відповідальними за порядок доведення вимог цього Регламенту до Керівників структурних підрозділів є ООУП (Проектний офіс).
9. Організація вивчення Регламенту
Відповідальними за доведення вимог цього Регламенту до працівників структурних підрозділів є Керівники структурних підрозділів компанії.
Додатки до регламенту
- Додаток 1. Порядок виконання процедур запуску проектів
- Додаток 2. Наказ ТОВ «ДОЧІРНЯ КОМПАНІЯ»
- Додаток 3. Наказ ВАТ «ГОЛОВНИЙ КОМПАНІЯ»
- Додаток 4. Наказ ТОВ «ДОЧІРНЯ КОМПАНІЯ»
- Додаток 5. Наказ про реалізацію проекту
- Додаток 6. Наказ ТОВ «ДОЧІРНЯ КОМПАНІЯ»
- Додаток 7. Реєстр проектів ІТЗ ТОВ «ДОЧІРНЯ КОМПАНІЯ»
- Додаток 8. Наказ ВАТ «ГОЛОВНИЙ КОМПАНІЯ»
- Додаток 9. Типовий Статут проекту
- Додаток 10. Типовий Статут проекту (спрощена)
- Додаток 11. Порядок виконання процедур планування проектів
- Додаток 12. Наказ про завершення проекту ТОВ «ДОЧІРНЯ КОМПАНІЯ»
- Додаток 13. План по віх
- Додаток 14. Укрупнений календарний план
- Додаток 15. Деталізований календарний план
- Додаток 16. Бюджет проекту
- Додаток 17. Ресурсний план (форма УП-13-1)
- Додаток 17. Ресурсний план (форма УП-13-2)
- Додаток 17. Ресурсний план (форма УП-13-3)
- Додаток 17. Вимоги до визначення ставки працівника
- Додаток 18. План комунікацій
- Додаток 19. План управління ризиками
- Додаток 20. Методичні вказівки по календарному планування та обліку фактичного виконання календарних планів
- Додаток 21. Реєстр ризиків
- Додаток 22. Методичні вказівки з управління ризиками
- Додаток 23. Матриця призначень на проектні ролі
- Додаток 24. Рольові профілі
- Додаток 25. Порядок виконання процесів моніторингу та управління
- Додаток 26. Запит на зміни
- Додаток 27. Реєстр запитів на зміни
- Додаток 28. Підсумковий звіт
- Додаток 29. Наказ про завершення проекту
- Додаток 30. Реєстр Керівників Проектних офісів \\ Проектних груп (Керівників проектів)
- Додаток 31. Аналітична записка
- Додаток 32. Порядок виконання процедур завершення проекту
- Додаток 33. Зміст розділу «Технічна підтримка» керівництва користувачів ІС
У цій статті розглядаються тільки структура і загальний вміст регламентує документації, яка описує процес проектування з використанням сучасних САПР, яка, на думку авторів, необхідна для розробки і застосування у всіх проектних організаціях.
Вступ
Основне завдання автоматизації проектних робіт - прискорення темпів їх проведення і підвищення якості технічної документації проектів.
Одним з важливих, так і наймодніших напрямків автоматизації останнім часом вважається застосування ЗD-техно-логій.
На це витрачається багато сил і коштів, закуповується нове програмне забезпечення, Обладнання, проводиться навчання і виконуються пілотні проекти. Але, на жаль, все в кінцевому підсумку в більшості випадків зводиться до «підняття» тривимірних моделей за розробленими 2D-креслень для виявлення колізій і показу потенційним замовникам красивою моделі.
Спроби заміни одного ПО на інше, більш просунуте, на думку фахівців з інформаційних технологій, ні до чого доброго не приводять. Часом дивуєшся, дивлячись на перелік програм, куплених організаціями. Впадають в око метання людей в безуспішною спробі знайти ту горезвісну «червону кнопку». Але, на жаль, все це нагадує відому байку Крилова «... А ви, друзі, як не сідайте.».
Чого ж не вистачає організаціям для впровадження в життя повноцінним автоматизації проектування?
Відповідь лежить на поверхні. Купуючи і впроваджуючи нове програмне забезпечення, розробляючи різні концепції комплексної автоматизації, застосовуючи сучасне програмне забезпечення, ми забуваємо, що при цьому змінюється сама технологія проектування. З'являється можливість паралельної роботи над одним проектом різних фахівців, що використовують єдину базу проекту, можливість верифікації на різних стадіях розробки, можливість автоматизації формування завдань і багато іншого.
Але при цьому не існує регламентує документації, яка описує процес проектування з урахуванням нових умов.
Звичайно, вже робляться певні спроби розробки стандартів на державному рівні, але це в основному стосується галузі машинобудування.
У цій статті розглядаються питання, що зачіпають тільки етап проектування. Але вирішуючи питання вдосконалення його процесів, ми готуємо проектні організації до впровадження ДСТУ ISO 15926-1-2008 «Промислові автоматизовані системи та інтеграція. ІНТЕГРАЦІЯ ДАНИХ життєвого циклу ДЛЯ ПЕРЕРОБНИХ ПІДПРИЄМСТВ, В ТОМУ ЧИСЛІ НАФТОВІ І ГАЗОВІ ВИРОБНИЧІ ПІДПРИЄМСТВА ». На нашу думку, не запровадивши нові регламенти в процес проектування, до цього приступити неможливо.
Процеси / регламенти / нормативні документи
Щоб система управління працювала ефективно, необхідна технологічна основа - інформаційні технології. Існуючий рівень регламентації процесів проектування не дозволяє використовувати весь потенціал комплексу сучасних програм.
Досвід впровадження САПР свідчить, що труднощі найчастіше виникають через опір системи організації внесеним в неї змін. У більшості проектних підприємств процес проектування формалізований досить незначно. При цьому, як правило, існує неявна склалася схема виконання проекту, тобто немає документованого алгоритму, але є загальноприйнята схема взаємодії, яку цілком не знає ніхто. Для невеликих підприємств така формалізація - занадто дороге задоволення, і ефект же від неї зовсім незначний. Зате у великих проектних організаціях та їх об'єднання віддача може бути вельми відчутною, оскільки «прозорість» системи дозволяє раціональніше управляти процесами в ній, прогнозувати і рентабельніше розподіляти ресурси. Незаперечним плюсом з точки зору підприємства є також зниження наслідків втрати співробітника. Негативний ефект заміни ключових фахівців обернено пропорційний ступеню формалізації процесів, якими він управляє. На жаль, і опірність великих систем набагато вище через інертність і страху перед новим ...
У чому полягає формалізація і з чого вона складається? А полягає вона, в тому числі, і в розробці та впровадженні пакету документів, що регулюють власне процес проектування. Структура такого пакета приведена на рис. 1. Складається ж формалізація як процес з:
- виявлення та аналізу наявних моделей бізнес-процесів проектування;
- побудови нової моделі з урахуванням комплексної системи автоматизації проектування організації;
- розробки регулюючої документації;
- навчання персоналу, виконання пілотних проектів;
- коригування регламентів за результатами виконаних пілотних проектів;
- введення документації як норми організації на постійній основі.
структура документації
Для великих проектних організацій оптимальна, на нашу думку, така структура регулюючої документації:
- документи, що вводять необхідні поняття, терміни та визначення основоположні документи, що забезпечують єдність термінології комплексу стандартів;
- документи, що описують процес концептуально - не прив'язані до конкретних програм, а служать для регламентації правил взаємодії учасників процесу;
- документи, що описують процеси з урахуванням специфіки певних програм - створюються на основі документів, що описують процес концептуально;
- інструкції - покрокове керівництво для учасників процесу.
Структура документів може варіюватися в залежності від того, для кого документи розробляються - для окремої організації або для концерну (Газпром, Роснефть і т. Д.).
В обох випадках на верхньому рівні повинен бути документ із загальними визначеннями, а на наступних рівнях - стандарти, регламенти, що описують процес проектування з використанням комплексних САПР.
Для тих організацій, які обрали конкретне ПО і не планують здійснювати перехід на інше, рекомендується об'єднувати документи другого і третього рівня. Для об'єднань і концернів важливі перший і другий рівні. Наявність цих документів дозволить організаціям, що входять до складу об'єднання, розробляти уніфіковані документи третього і четвертого рівнів.
Зупинимося докладніше на змісті цих документів.
Перший рівень
Стандарт «Електронна модель об'єкта» (рис. 2) повинен визначати поняття електронної моделі об'єкта проектування, загальні вимоги до неї, види контролю електронної моделі, її статуси і етапи життєвого циклу. Немає необхідності його читати повністю, вивчати, але він завжди повинен бути під рукою, щоб завжди однозначно розуміти значення тих чи інших термінів.
другий рівень
Включає в себе «Технологічні правила проектування із застосуванням електронних моделей». Розробку документів цього рівня (рис. 3) оптимально було б почати з формування моделей бізнес-процесів проектних робіт з використанням САПР і регламентує на їх основі документації. При цьому описуються загальні принципи без прив'язки до конкретного ПО.
Мал. 3. Приклад стандартів, регламентів, документованих процедур другого рівня "))" title \u003d "(! LANG: Рис. 3. Приклад стандартів, регламентів, документованих процедур другого рівня"> !}
В ході розробки моделей необхідно визначити і створити «Уніфіковані варіанти моделей бізнес-процесів», що передбачають створення різних типів проектів і різних спеціальностей - провідних технологів.
третій рівень
Документація цього рівня створюється або на основі документації другого рівня при його наявності, або, коли документи розробляються для конкретної організації, включає в себе другий і третій рівні з прив'язкою до конкретного ПО (рис. 4). Документація цього рівня містить:
Мал. 4. Приклад структури документації третього і четвертого рівня з проектування КВП із застосуванням SmartPlant Instrumentation "))" title \u003d "(! LANG: Рис. 4. Приклад структури документації третього і четвертого рівня з проектування КВП із застосуванням SmartPlant Instrumentation"> !}
- регламенти та інструкції, що описують правила колективної роботи всередині однієї спеціальності;
- регламенти та інструкції щодо взаємодії різних спеціальностей в ході спільної роботи;
- регламенти та інструкції по створенню, поповненню і ведення баз даних.
четвертий рівень
Як правило, документи цього рівня - інструкції по роботі з конкретним ПО - є в кожної організації (рис. 4). Для прискорення розробки і впровадження зазвичай попередньо розробляються тимчасові регламенти - документи, що містять все необхідне для організації проектних робіт із застосуванням певного набору програм. Регламенти вводяться в дію на невеликий термін (до року), який необхідний для усунення недоліків і навчання персоналу. Для невеликих організацій, як правило, цього цілком достатньо, і допрацьовані регламенти вводяться на постійній основі. У великих організаціях регламенти є основою для розробки комплексу стандартів.
Роль системного інтегратора
Здавалося б, Америку тут ніхто не відкрив, всім і так зрозуміла необхідність документації цього типу. Так в чому причина, чому її немає?
Розробка такого роду документів вимагає тривалої і копіткої роботи, наявності знає проектне виробництво персоналу, здатного аналізувати існуючу ситуацію, генерувати рішення.
Якщо із знавцем процес проектування персоналом в організаціях, як правило, справа йде добре, то з вільним часом і можливістю відволікання провідних спеціалістів від основної роботи на довгий термін - дуже проблематично.
Ось тут і повинен підключатися системний інтегратор, що володіє знаннями не тільки в області САПР, але і в області проектування, бізнес-процесів, а також має досвід аналогічної роботи з проектними організаціями. У цьому випадку роль провідних фахівців-проекти-ровщіков буде зводитися до оцінки пропонованих варіантів рішення і вибору з них оптимальних.
Група компаній CSoft здійснює консалтинг та впровадження комплексних рішень в області систем автоматизованого проектування (САПР), технологічної підготовки виробництва (ТПП), документообігу і геоінформаційних систем (ГІС). Велика частина рішень базується на унікальному поєднанні світових і вітчизняних розробок у цій галузі.
Сьогодні в нашому активі - десятки успішних комплексних проектів, власні методики обстеження організацій, впровадження проектно-конструкторських і технологічних рішень, досвід створення стандартів в області САПР і документообігу, спеціалізовані рішення для вузькопрофільних замовників.
Послуги, пропоновані CSoft, включають аналіз існуючої технології виконання робіт, визначення найбільш ефективних програмно-апаратних рішень, розробку концепції розвитку САПР на підприємстві, поставку, установку і настройку компонентів автоматизованої системи, навчання користувачів, виконання пілотних проектів, впровадження автоматизованих систем «під ключ» .
,
генеральний директор ЗАТ «СиСофт Інжиніринг»
Тел .: (8313) 34-3352
E-mail: RevzinV at cs-eng dot ru, RevzinV at csoft dot ru
