3136 Управление проектами

В цілому можна сказати, що Р3 – функціонально розвинутий і зручний інструмент.

Open Plan - розробник – Welcom Software Technology www.wst.com / представник в Росії – A-Project Technologies (в даний час – Департамент управління проектами холдингу

«Щок» www.projectmanagement.ru)

Цей продукт позиціонується як професійна система управління проектами масштабу підприємства. Випускається в трьох версіях: Enterprise, Professional і Desktop. За відомостями фахівців з A-Project Technologies версія Enterprise в Росії ще не поставлялася.

Інтерфейс продукту вельми оригінальний. Робочий простір представлений у вигляді декількох робочих столів, на яких поміщаються ярлики до стандартних об'єктів (файли проектів, календарів, ресурсів, кодів, шаблонів), так і до будь-якого файлу. При відкритті проекту відкривається «записник проекту» - набір робочих столів з ярликами до файлів, безпосередньо що відноситься до проекту. В поставку входить декілька десятків найпоширеніших шаблонів представлення проекту. Застосування шаблона до проекту здійснюється простим перетягуванням потрібного ярлика на записник проекту. Окремої згадки заслуговує функція «Директор Управління Проектами» (ДУП). ДУП це інструментарій автоматизації процесів, що повторюються, при управлінні проектами. Об'єктами ДУП можуть бути не тільки стандартні форми, уявлення і процедури Open Plan, але і об'єкти з інших додатків, наприклад, текстового редактора, електронних таблиць, CAD. В поставці – 35 стандартних шаблонів ДУП, розбитих, згідно рекомендаціям PMI (www.pmi.org) на 8 категорій. Природно, є функція створення і збереження призначених для користувача шаблонів уявлення і шаблонів ДУП.

В продукті вельми розвинута система ресурсного планування. Реалізовано два базові методи розрахунку розкладу:

Ресурсне планування при обмеженому часі – пріоритетної є необхідність дотримуватися загальної дати завершення проекту при спробі мінімізувати ступінь перевантаження ресурсів. В результаті ресурси можуть бути переобтяжений.

Ресурсне планування при обмежених ресурсах – пріоритет віддається запобіганню перевантаження ресурсів, навіть якщо це приведе до виходу проекту за рамки розкладу. При цьому сповільнюється завершення проекту на стільки, на скільки це необхідне для повного уникнення перезавантаження ресурсів.

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

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

Слід особливо відзначити, що функція аналізу ризиків – вбудована в систему, тоді як в деяких продуктах вона поставляється як окремий модуль. Для тривалості вибраних або всіх робіт проекту вводяться оптимістична і песимістична оцінки. Далі по методу Монте-Карло визначається внесок вірогідності в дати проекту.

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

-142 -

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

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

Для аналізу виконання проекту, а також для аналізу “що якщо” дуже важливо мати нагоду зберігати колишні версії проекту і мати нагоду для порівняння і аналізу відхилень поточної версії проекту від попередніх. В Spider Project є можливість берегти необмежену кількість версій проекту і аналізувати хід виконання робіт не тільки в порівнянні з якоюсь базовою версією, але і з будь-ким інший.

Розрахунок розкладу проекту методом критичного шляху проводиться без урахування обмеження по ресурсах і має точне математичне рішення. Якщо ж при розрахунках враховується обмеженість ресурсів, то поняття резервів, у тому числі і повного резерву (total float) втрачає значення. В Spider Project обчислюється ресурсний критичний шлях і резерви термінів виконання операцій з урахуванням обмеженості ресурсів.

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

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

Система взаємодії між учасниками проекту з використанням внутрішньофірмової Intranet або Internet по наступному механізму:

- створена головним менеджером повна версія проекту передається на сервер з вказівкою списку користувачів і рівня доступу тих, яким вона призначається

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

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

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

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

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

Spider Project підтримує OLE (у візуальні уявлення можна вставляти текст і графіку). Експорт даних проекту в інші додатки здійснюється за допомогою форматуcsv.

-144 -

Інтеграція СУП в КІС

Рідкісний постачальник програмного забезпечення для управління проектами не заявляє про можливості інтеграції свого програмного забезпечення з іншими компонентами корпоративних інформаційних систем (КИЦЬ). У тому числі і із спеціалізованими компонентами їх компонентами, такими як САПР і кошторисні системи. Рідко зустрічаються компанії, в яких існує цикл «проектування – будівництво» власними силами. Тому можливості інтеграції з САПР ми в даній статті розглядати не будемо.

Можливі напрями подібної інтеграції в додатку до будівельної компанії (по частоті запитів):

інтеграція з кошторисним ПО;

інтеграція з комплексами бухобліку;

інтеграція з системами документообігу;

інтеграція з системами управління автотранспортом і механізмами.

Інтеграція з кошторисним ПО. Здавалося б, як зручно: отримати від проектувальників проектно-кошторисну документацію і кошториси (в електронному вигляді!), потім експортувати змету в систему управління проектами і модель проекту готова. Адже в кошторисі є і найменування робіт, і потрібна кількість матеріалів, і трудовитрати. Але навряд чи це панацея. Вартість матеріалів на ринку і в кошторисній базі – розрізняються. Приводити їх у відповідність за допомогою коефіцієнтів – та ще «цікава задача». Трудовитрати, закладені в кошторисі і фактичні – швидше за все теж розрізнятимуться. «Зарплатная частина» кошторису теж відрізняється від існуючих на ринку одиничних розцінок по зарплаті. Та і WBSструктура вашого проекту напевно відрізнятиметься від кошторисної структури. Так тоді який в цьому значення? Що саме ми отримаємо, імпортуючи в СУП кошторис? І які трудовитрати на приведення моделі проекту, заснованої на кошторисі в належний вигляд? Створюється ситуація, коли є красиве рішення для неіснуючих, загалом, задач. Формувати акти виконаних робіт (форми КС-2) в СУП теж навряд чи хто то буде. Адже достатньо часто зустрічаються ситуації при яких замовник може прийняти роботи, фактично не виконані. І навпаки. Роботи виконані, матеріали витрачені, а замовник, через різні причини, не приймає ці роботи.

Що ж залишається? Зовсім закинути ці спроби? Цілком можливо, що ні. Але повертатися до них у міру розвитку нової нормативної бази. В цьому випадку кошторис вельми корисний для порівняння моделі проекту (в частині потреби матеріалів) і кошторису.

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

16.2.Делегування прав і відповідальності

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

-146 -

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

Передачу (делегування) повноважень доцільно використовувати в наступних випадках:

-коли підлеглий зможе роботу зробити краще;

-коли керівник (менеджер) зайнятий і не може сам виконати роботу;

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

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

Передача прав і відповідальності підлеглим припускає строге дотримання ними норм управлінської діяльності: влади, відповідальності і звітності.

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

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

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

16.3. Документація по проекту

Зразкова посадова інструкція керівника проекту

Керівник проекту призначається на посаду і звільняється з посади у встановленому чинним трудовим законодавством порядку наказом генерального директора компанії.

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

Керівник проекту підкоряється безпосередньо генеральному директору.

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

Керівник проекту зобов'язаний знати:

законодавчі, нормативно-правові і нормативні, регламентуючі будівельні роботи;

технічні, економічні, екологічні вимоги, що пред'являються до проектованих об'єктів;

-147 -

будівельні норми і правила, економіку і організацію будівництва, основи будівельного виробництва;

стратегію розвитку підприємства;

виробничі потужності підприємства і його виробничої бази;

спеціалізацію підрозділів підприємства і виробничі зв'язки між ними;

організацію виробничого планування на підприємстві;

порядок розробки моделі проекту, календарних графіків будівництва, бюджету проекту;

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

основи трудового законодавства;

правила і норми охорони праці;

основи техніки безпеки і контролю якості;

керівник проекту зобов'язаний володіти системою управління проектами Spider Project на рівні упевненого користувача.

Функціональні обов'язки:

Керівник проекту забезпечує виконання всіх робіт за проектом (об'єкту будівництва) по будівництву і своєчасному введенню в експлуатацію об'єкту.

Для цього:

1.Здійснює планування і управління проектом на всіх його стадіях від запуску до завершення.

2.Розподіляє завдання між підлеглими працівниками. Координує роботу виробничої ділянки і інших учасників команди управління проектом. При необхідності і за узгодженням з функціональними керівниками залучує фахівців інших функціональних підрозділів.

3.Здійснює координацію робіт субпідрядних організацій.

4.Здійснює взаємодію з міськими службами

5.Здійснює взаємодію із службою Замовника. Спільно з начальником ділянки, погоджує

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

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

7.Організовує технічну підготовку будівництва, керує роботою по оперативному управлінню будівництвом відповідно до затвердженого графіка виробництва робіт.

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

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

10.Ініціює підготовку і оформлення договорів з постачальниками і субпідрядниками на проект. Бере участь у формуванні умов договорів.

-148 -

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

12.Здійснює контроль за дотриманням графіка поставки матеріалів і конструкцій.

13.Керує обліком матеріалів і конструкцій відповідно до лімітної карти матеріалів проекту (відомістю потреби матеріалів і конструкцій).

14.Забезпечує виконання термінів по введенню об'єкту в експлуатацію і виконання бюджету проекту.

15.Інформує керівництво про хід робіт за проектом.

16.Відповідає за надання затвердженої звітності за проектом.

Права керівника проекту

Керівник проекту має право:

1.Виконувати всі необхідні дії для успішного виконання поставленої задачі – будувати об'єкт у встановлені терміни, з належною якістю і в межах затвердженого бюджету.

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

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

4.керівник проекту зобов'язаний своєчасно інформувати керівництво про допущені порушення з подальшим застосуванням відповідних заходів дії.

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

Відповідальність керівника проекту

Керівник проекту несе відповідальність за: 1.Виконання всіх робіт проекту в затверджені терміни.

2.отримання затвердженого бюджету проекту по всіх вартісних складових.

3.своєчасне забезпечення проекту необхідними ресурсами: матеріалами, машинами і механізмами, трудовими ресурсами.

4.за цільове використовування привернутих ресурсів і ресурсів компанії.

5.Представлення достовірної інформації про стан виконання робіт за проектом, про розмір фактичних витрат за матеріалами, трудовитратами, машинами і механізмами.

6.Забезпечення якості виконання будівельних робіт.

7.виконання наказів, розпоряджень і доручень генерального директора підприємств і його заступників.

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

9.забезпечення дотримання трудової і виконавської дисципліни членами команди проекту.

-149 -