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

Вибір програмного забезпечення корпоративної СУП.

Проблеми адаптації західних пакетів.

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

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

Майже у всіх, відомих авторам західних пакетах для управління проектами, поширених на російському ринку відсутнє поняття фізоб’єм. Робота вимірюється тривалістю. Немає його в TimeLine, P3, OpenPlan, SureTrak, MS Project. Тому при упровадженні і використанні Супів доводиться займатися рішенням цієї проблеми.

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

Алгоритм вибору:

1. Сформулювати вимоги до пакету, заздалегідь визначивши потрібні функції. Це дуже важливий етап, оскільки за відсутності належної уваги можуть бути упущений вельми істотні вимоги до продукту.

2. Скласти таблицю порівняння специфікацій функцій різних систем.

3. Оцінити пропозиції постачальників ПО, їх сервісу, допомоги при упровадженні і т.п.

Хоча програмний продукт і не є стрижнем системи управління проектами, але його можливості і недоліки цілком можуть бути серйозним чинником і обмеженням. Не кожна компанія може дозволити собі займатися «доведенням» програмного забезпечення під себе. Хоча, безумовно, настройка робочих місць, залежно від виконуваних співробітником функцій, має місце бути.

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-04