Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проактивне управління Учебное пособие по УП.doc
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
589.31 Кб
Скачать

1.6.Концепції технологічної зрілості

Визначення 1.3: Технологічна зрілість – це міра готовності підприємства до ефективного управління своєю діяльністю і розвитком на основі проектного підходу.

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

Модель технологічної зрілості CMM

В нинішній час в світовій практиці управління проектами застосовується більш 20 різноманітних моделей технологічної зрілості організацій. Історично однією з перших моделей була модель Інституту Меллона США CMMI.

CMM (Capability Maturity Model) — модель зрілості процесів створення програмного забезпечення (ПО), або еволюційна модель розвитку спроможності компанії розробляти якісне програмне забезпечення.

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

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

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

    1. Початковий рівень (initial level) — це основний стандарт. До даного рівня, як правило, відноситься будь-яка компанія, якої вдалося отримати замовлення, розробити і передати замовнику програмний продукт. Підприємства першого рівня не відрізняються стабільністю розробок. Як правило, успіх одного проекту не гарантує успішність наступного. Для компаній даного рівня властива нерівномірність процесу розробки — наявність авралів в роботі. До цієї категорії можна віднести будь-яку компанію, що хоч якось виконує взяті на себе зобов'язання.

    2. Рівень. що повторюється (repeatable level). Даному рівню відповідають підприємства, що володіють певними технологіями управління проектами. Планування і управління в більшості випадків грунтується на наявному досвіді. Як правило, в компанії даного рівня вже вироблені внутрішні стандарти і організовані спеціальні групи перевірки якості.

    3. Певний рівень (defined level). Рівень характеризується наявністю формального підходу до управління. Тут описані всі типові дії, необхідні для багатострокового повторення: ролі учасників, формати документів, створювані дії і інше. Для створення і підтримання подібного стандарту в актуальному стані в організації вже підготована спеціальна група. Компанія постійно проводить спеціальні тренінги для підвищення професійного рівня своїх співробітників. Починаючи з цього рівня, організація перестає залежати від особистих якостей конкретних розробників і не має тенденції скочуватися на нижчі рівнів. Абстрагування від розробників зумовлене продуманим механізмом порушення задач і контролю виконання.

    4. Рівень, що управляється (managed level). Рівень, при якому встановлюються кількісні показники якості.

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

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

Модель технологічної зрілості Г. Кезнера

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

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

  • Подолання опору змінам:

  • Пошук добре працюючих частин і змін.

  • Ключові дії по переходу на другий рівень:

  • Підготовка і утворення по проектному менеджменту;

  • Сертифікація професіоналів;

  • Забезпечення комунікацій з допомогою мови проектного менеджменту в компанії;

  • Визначення засобів і технологій, необхідних компанії;

  • Розвиток розуміння принципів по управлінню проектами;

Чинники, що формують ризики на 1 рівні:

  • Помилки реформування організації.

  • Зміна ролей відповідальності.

  • Зміна пріоритетів.

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

  • Визначення користі по професійному управлінню проектами.

  • Організаційна підтримка всіх рівнів.

  • Визначення необхідних процесів і методології.

  • Визначення різноманітних частин бізнесу компанії, де проектний менеджмент може бути застосований.

  • Визначення необхідних змін в компанії для впровадження ефективного управління проектами.

Чинники, що формують ризики на 2 рівні:

  • Відсутність підтримки вищого керівництва.

  • Тимчасове ослаблення корпоративної культури.

  • Опір змінам.

  • Швидкість, з якої може бути створена ефективна методологія.

  • Швидкість, з якої проектний менеджмент може принести результати.

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

  • Моделювання єдиної методології.

Основні характеристики цього рівня:

  • Інтегровані процеси управління.

  • Підтримка з боку культури управління.

Зміна відношення до управління проектами.

Рівень 4. Benchmarking – перенос кращого світового досвіду. На цьому рівні проектна команда на чолі з керівником проекту аналізує отримані результати. Виробляє порівняльний аналіз з аналогічними роботами наших зарубіжних колег. Вишуковує переваги і недоліки в своїй роботі і роботі команди, і кращі рішення переносить в практику управління проектами проектної компанії ,що зорієнтувалася. Основні кроки:

  • Створення проектного офісу.

  • Орієнтація на використання кращих світових технологій.

  • Перенесення досвіду в процеси і методологію.

  • Перенесення досвіду в культуру управління.

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

  1. Постійне поліпшення.

  2. Вивчення уроків проектів, трасфер знань.

  3. Стратегічне планування в управлінні проектами.

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

Модель технологічної зрілості ОРМ3

Подальший розвиток РМВОК в сфері технологічної зрілості компаній представлений в моделі ОРМ3 – моделі розвитку технологічної зрілості підприємств. Структура моделі наведена на рис. 3.

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