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

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

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

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

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

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

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

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

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

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

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