Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Вимоги до інформаційної системи управління проектами

До чинників, що впливають на підходи і, відповідно, вимоги до АІСУП відносяться:

- стиль управління проектом;

- потреби робочої групи проекту;

- вимоги вищих керівників.

Ці аспекти необхідно детально розглянути, перш ніж визначитись, яка необхідна АІСУП.

Існують чотири категорії стилей управління:

1. Детальне знання проекту та високий рівень контролю;

2. Детальне знання проекту та невисокий рівень контролю.

3. Невисокі знання деталей проекту та невисокий рівень контролю;

4. Невисоке знання деталей проекту та значний рівень контролю.

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

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

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

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

АІСУП не повинна бути надто чутливою.

Третій стиль не потребує розробки дуже деталізованого плану проекту для введення в БД або забезпечення доступності інформації. Цей стиль також надає робочій групі більше свободи в розробці власних планів такий підхід називається управління «по відхиленням» АІСУП також не повинен бути надто чутливою.

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

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

В цьому випадку АІСУП повинна бути виключно чутливою.

Ефективність роботи менеджера залежить від його здатності здійснювати контроль через заздалегідь внесені відповідні зміни.

При визначенні вимог до ІС УП (конкретної) необхідно чітко визначитись на який стиль слід орієнтуватись і для вирішення яких задач буде потрібна АІСУП.

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

Потім необхідно визначитися з класами функцій планування і управління, які повинна реалізувати ІСУП:

· тільки планування або планування і контроль ходу проекту;

· планування і контроль лише термінів виконання робіт;

· планування і контроль фінансових вкладень без детального планування використання ресурсів;

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

· багатопроектне управління.

Корисно заздалегідь визначити:

1. Приблизні вимоги до розмірності проектів і детальності планування, організаційної структури управління і звітності.

2. Скільки проектів буде вестися одночасно і чи будуть вони взаємозалежними?

3. Яка приблизна кількість задач в одному проекті?

4. Скільки видів ресурсів буде задіяно в одному проекті і як будуть розділятися ресурси між проектами?

Важливим є також міркування, пов’язані з кваліфікацією персоналу, який буде використовувати ІСУП.

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

Після аналізу всіх вимог необхідно прийняти рішення про вибір ІСУП з тих, що пропонує ринок, або при відсутності на ринку системи, яка відповідає вимогам– про розробку власної.

Розробка власної ІС пов’язана з такими труднощами:

1. Розробка власної обійдеться значно дорожче (на 1-2 порядки)

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

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

4. Розробка нової ІС сама по собі є проектом і відповідно вимагає управління.

Тому, розробка ІС із застосуванням готових ПЗ (як власними силами, так із залученням сторонньої фірми) є більш доцільним, крім випадків, коли фірма сама є розробником ПЗ.

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

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

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

2. Стратегічний рівень, що складається з професіоналів по управлінню проектами, що займаються плануванням і контролем корпоративних проектів. Як правило, цей рівень представляється вельми малою кількістю людей, основний обов’язок яких – саме управління проектами, і які в своїй роботі спираються на програмне забезпечення по управлінню проектами. Місія подібних професіоналів є ключовою в організації. Вони працюють як група підтримки управління проектами, навіть якщо офіційно їм не дають таку назву.

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

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

Вимоги до інтегрованої системи по управлінню проектами універсальні і не залежать від специфіки організації. Модель обміну даними можна спрощено представити таким чином:

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

Кожний рівень управління характеризується своїми специфічними вимогами до програмного забезпечення УП (Табл.15.1)

Таблиця 15.1 Вимоги до програмного забезпечення по управлінню проектами.

Рівень вищого керівництва	Стратегічний рівень	Рівень операцій
 Простота в застосуванні  Можливість отримувати демонстраційні звіти  Потужні можливості узагальнення відомостей  Засоби для інтеграції даних з інших програмних додатків  Процедури для планування зверху вниз	 Можливість інтеграції з іншими засобами (додатками)  Засоби для згортання даних по проекту (представлення звітів керівництву) і поглибленню для планування на більш детальному рівні  Засоби для контролю за реалізацією проекту  Гнучкість при настроюванні вихідних форм звітності	 Простота використання  Простота вивчення  «Прозорість» процедур введення даних.  Наочність

Для рівня вищого керівництва(насправді у вищого керівництва не завжди є бажання працювати з системами управління проектами) самою головною вимогою є простота використання. Керівництво, якщо у нього з’явиться потреба працювати з ПЗ УП, буде робити це не дуже часто, і навряд чи захоче витрачати на вивчення системи більше 2-3 днів.

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

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

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

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

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Перша група	\|	Базові функціональні можливості системи для управління проектами

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.