CC BY
69
Посилання на статтю_
Бушуев С. Д. Технолопчна зрiлiсть як шструмент CTpaTeri4Horo розвитку компанiй на ochobí управлiння проектами/ С.Д. Бушуев, Н.С. Бушуева, О.О. Покровницька// Управлiння проектами та розвиток виробництва: Зб.наук.пр. - Луганськ: вид-во СНУ ím. В.Даля, 2004. - № 1(9). - C.5-16._
УДК 519.68
С.Д. Бушуев, Н.С. Бушуева, О.О. Покровницька
ТЕХНОЛОГ1ЧНА ЗР1Л1СТЬ ЯК 1НСТРУМЕНТ СТРАТЕГ1ЧНОГО РОЗВИТКУ КОМПАН1Й НА ОСНОВ1 УПРАВЛ1ННЯ ПРОЕКТАМИ
Розглядаються проблеми стратег1чного управлЫня розвитком компан1й на основ! модел1 технолог1чноТ зр1лост1. Виконано анал1з найб1льш в1домих моделей технолог1чноТ зр1лост1 щодо розвитку компанм на основ! проектного пщходу. Рис. 5, табл. 2, дж. 4.
С.Д. Бушуев, Н.С. Бушуева, О. А. Покровницкая
ТЕХНОЛОГИЧЕСКАЯ ЗРЕЛОСТЬ КОМПАНИИ КАК ИНСТРУМЕНТ СТРАТЕГИЧЕСКОГО РАЗВИТИЯ НА ОСНОВЕ УПРАВЛЕНИЯ ПРОЕКТАМИ
Рассматриваются проблемы стратегического управления развитием компаний на основе моделей технологической зрелости. Выполнен анализ наиболее известных моделей технологической зрелости компаний, касающихся развития на основе проектного подхода. Рис. 1, табл. 1, ист. 4.
S.D. Bushuyev, N.S. Bushuyeva, O.O. Pokrovnitskaya
TECHNOLOGICAL MATURITY AS STRATEGIC TOOL FOR DEVELOPMENT IN PROJECT MANAGEMENT
Problems of strategic management in company development are considered on the base of technological maturity model. The analysis of the most typical technological maturity models is carried out on the project approach base.
Постановка проблеми. Розвиток технолопчноТ зртосп компанш у галузi управлшня проектами е важливим стратепчним шструментом Тх розвитку Кожна оргашза^я у своему розвитку проходить певш етапи, як характеризуються рiзними мiсiею, стратепею, продук^ею, технолопею, оргашзацшною структурою, рiвнем компетенци персоналу та iншими якюними i кiлькiсними показниками. Перехiд на кожний наступний, бтьш високий рiвень розвитку, робить органiзацiю бiльш конкурентоспроможною, динамiчно реагуючою на вимоги ринку i дозволяе оптимально використовувати своТ внутршш ресурси. Моделi, якi описують етапи (рiвнi) розвитку оргашзаци, називаються моделями 3pmocmi.
Анал'з ocmaHHix досл'джень та публЫацш. На сьогодш у свт юнуе бiля 30 моделей зртосп i з'являються все новi й новi.
Успiшнi компани в усьому свт розвивають конкурентоспроможнiсть шляхом оцшки зрiлостi своТх бiзнес-процесiв. Зртють же управлiння проектами мае певш особливост - ТТ слiд розглядати як шструмент розвитку фiрми через постшне удосконалення методологи управлiння проектами, бтьш глибоке ТТ iнтегрування
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
1
у загальну систему управлшня компашею i досягнення повторюваностi успiхiв у виконанш проектiв.
По вiдношенню до проектноТ дiяльностi можна видiлити два основних типи оргашзацш:
- Процесно-ор'ентован! оргашзаци. Специфка бiзнесу таких пiдприемств визначае процесний пщхщ до управлiння основною дiяльнiстю (виробничi пiдприемства з конвеерним потоком, пщприемства масового обслуговування). Проектне управлшня використовуеться у процесах внутршнього (по вщношенню до основноТ дiяльностi) розвитку оргашзаци — реорганiзацiя, впровадження шформацшних систем, створення нових продуклв та iн.
- Проектно-ор'ентоваш оргашзаци. Там пщприемства використовують проектний пщхщ до управлшня не ттьки для внутршнього розвитку, але й для реалiзацп основноТ бiзнес-дiяльностi (наприклад, створення локальних атей, будiвництво та ш.)
Проте можна iз впевненiстю констатувати, що в обох типах оргашзацш присутня необхщнють у застосуваннi технологш проектного управлiння. Тому органiзацiТ створюють i розвивають системи управлiння проектами, придтяючи особливу увагу чотирьом основним Тх компонентам:
- персонал;
- методологiя;
- органiзацiйна структура;
- технологи (у тому чи^ шформацшш).
Моделi зрiлостi управлiння проектами надають органiзацiям, якi мають на мет створення ефективного управлiння проектами, можливють оцiнки поточного стану системи управлшня проектами i визначення стратеги i тактики розвитку такоТ системи на пщприемствк
Моделi зрiлостi сьогоднi можуть бути корисними як для проектно-орiентованих компанiй, для яких проекти е основною формою отримання прибутку, так i для будь-яких iнших фiрм, якi придiляють велику увагу розробц нових продуктiв, реоргашзаци та шшим формам удосконалення бiзнесу. Модель зршосп управлiння проектами дозволяе побачити сильш i слабкi боки оргашзаци, зрозумiти, де вона знаходиться зараз i де хоче опинитися. В ходi оцiнки зрiлостi компанiя використовуе модель для того, щоб дослщити, насктьки добре протiкають, контролюються i управляються ТТ бiзнес-процеси.
Основнi ц^ всiх моделей зрiлостi полягають у тому, щоб:
- оцшити поточний стан оргашзаци з управлшня проектами;
- пщготувати i навчити людей, ям беруть участь в управлшш проектами;
- надати можливiсть безперервного удосконалення як особистого, так i оргашзацшного потенцiалу з управлiння проектами.
Метою дано)' статт'1 е дослщження юнуючих моделей технологiчноТ зрiлостi компанш з точки зору стратегiчного розвитку у конкурентному середовищк
Досл'дження моделей технологiчноl зр'лост'1 компанш як ¡нструменту стратег'чного розвитку. Ще в середин 70-х рош першi "симптоми" кризи вщчули на собi вiйськовi замовники США, ям зiткнулися з вибухоподiбним ростом обсягу i складностi задач, що покладалися на програмне забезпечення (ПЗ), який був викликаний появою найновших (на т часи) засобiв обчислювальноТ технiки. Новi грандiознi проекти потребували залучення все нових i нових ресурсiв для Тх реалiзацiТ. Термiни виконання проектiв постiйно зривалися, якють ПЗ (вiдповiднiсть очiкуванням замовника) залишалась на неприйнятно низькому рiвнi, i Мiнiстерство оборони США почало серйозно непокоТтися про ефективнiсть витрачання бюджетних кошлв.
2
"Управл1ння проектами та розвиток виробництва", 2004, № 1(9)
В цш ситуаци, усвiдомивши реальнiсть загрози втрати великих замовлень, багато оргашзацш-розробниш спрямували зусилля на пошук ефективних методологш i iнструментiв для виршення "суто техшчних" (як тодi здавалось) проблем програмного забезпечення. Майже два десятилтгя общянок пiдвищити продуктивнiсть та якють робот за рахунок нових методiв i засобiв розробки ПЗ пшло на усвiдомлення того, що коршь зла — не в технщк
Зрештою, було зроблено висновок, що фундаментальна проблема полягае у неспроможност органiзацiй управляти технологiчним процесом розробки програмного забезпечення. I тодi вiйськовi розпочали пошук формальних i об'ективних методiв оцiнки здатностi оргашзаци-розробника виробити ПЗ потрiбноТ складностi у встановлен термiни i з потрiбним рiвнем якостi. В результатi цтеспрямованоТ' i плщноТ спiвпрацi Мiнiстерства оборони США i Пiтсбургського iнституту програмноТ шженерп (Software Engineering Institute - SEI) у 1993 р. з'являеться остаточна верая т. з. "Моделi технолопчноТ' зрiлостi оргашзаци-розробника ПЗ" (Capability Maturity Model for Software - SW CMM).
Структура СММ. Модель технолопчноТ зрiлостi СММ [1] - це опис стадш еволюцп, як проходять оргашзацп-розробники в мiру того, як вони визначають, реалiзують, вимiрюють, контролюють i вдосконалюють процеси створення ПЗ. Ця модель допомагае оргашзаци обрати адекватну стратепю удосконалення цих процеав, надаючи методичну основу для визначення поточного рiвня Тх досконалост i виявлення проблем, критичних для якост розроблюваного ПЗ.
Рiвень зртосп - це чiтко визначена стадiя в процесi удосконалення процесiв розробки i супроводу програмного забезпечення (ПЗ-процеав). Кожний рiвень зрiлостi мiстить набiр процесних цiлей, при досягненнi яких один iз важливих компонентiв ПЗ-процеса стае стшким. Досягнення кожного рiвня зрiлостi змiцнюе рiзнi компоненти ПЗ-процеав, у результaтi чого збiльшуеться загальний потен^ал ПЗ-процесiв оргaнiзaцiТ. Розробники моделi СММ визначили п'ять рiвнiв технолопчноТ зртосп, за якими замовники можуть оцiнювaти потенцiйних постaчaльникiв (претендентiв на отримання контракту), а постачальники можуть вдосконалювати процеси створення ПЗ (рис.1).
Рис. 1 Структура моделi технолопчноТ зртосп СММ
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
3
Рiвень 1: lнiцiалiзацiя - технолопя розробки ПЗ характеризуеться як довтьна (iмпровiзована), в деяких випадках — навггь хаотична. Лише деякi процеси визначеш, yспiх цiлком залежить вiд зусиль окремих пра^вниш.
Рiвень 2: Повторення - базовi процеси yправлiння ПЗ встановленi для вiдстежyвання вартостi, графка та фyнкцiональностi вихiдного продукту. Необхщна дисциплiна дотримання встановлених процесiв мае мюце i забезпечуе можливiсть повторення устху попереднiх проектiв у тш же прикладнiй галyзi.
Рiвень 3: Визначення - управлшсью та шженерш процеси задокyментованi, стандартизованi й штегроваш в yнiфiкованy для всieï оргашзаци технолопю створення ПЗ. Кожний проект використовуе затверджену, адаптовану до особливостей даного проекту, вераю ^eï технологи.
Рiвень 4: Управлння - детальш метрики (об'eктивнi данi) про якють виконання процесiв i вихщно'Г продукци' збираються i накопичуються. Управлiння процесами i вихщною продyкцieю здiйснюeться за ктькюними та якiсними оцiнками.
Рiвень 5: Оптим'заця - удосконалення технологи' створення ПЗ здшснюеться безперервно на основi кiлькiсного зворотного зв'язку вщ процесiв i пiлотного впровадження шновацшних iдей.
В основi моделi CMM лежить послiдовно-стyпiнчасте або поетапне представлення еволюци оргашзаци' та ïï технологи. В такому представлены оргашза^я здшснюе свое сходження до високоï культури виробництва, крок за кроком пщшмаючись на нову сходинку ^вень) технолопчноГ зрiлостi. Керуючись цieю iдеeю, розробники cMM визначили так званi ключовi областi процесiв створення ПЗ для кожного рiвня зрiлостi.
Ключовi обласп процесiв - це кластери взаемопов'язаних видiв робiт колективу yчасникiв проекту, належне виконання яких ютотно важливе для вiдповiдностi даному рiвню зртосп технологiï. За винятком Рiвня 1, кожний рiвень можна декомпозувати на дектька ключових областей процесiв, ям показують, де органiзацiя повинна сфокусуватися для покращення ПЗ-процеса. Ключовi обласп процесiв визначають задачi, якi повинш бути вирiшенi для досягнення певного рiвня зрiлостi. Це означае, що для оргашзаци, яка прагне вийти на даний рiвень зртосп, виключне значення мають тiльки вiдповiднi цьому рiвню областi процесiв. Це також означае контрпродуктивнють спроб "перестрибування" через рiвнi зрiлостi, оскiльки кожний нижчий рiвень е фундаментом для переходу на наступний.
Лопка оцiнки за CMM достатньо жорстка, проте саме така лопка дозволяе однозначно щентифкувати технологiчнy зрiлiсть органiзацiï i доволi точно дiагностyвати "вyзькi мiсця" в ï'ï повсякденнш практичнiй дiяльностi.
Модель 3p^cmi управлшня проектами РМММ. Mодель зртосп yправлiння проектами (Project Management Maturity Model — РМММ) складаеться с п'яти рiвнiв [2]. Кожний з п'яти рiвнiв представляе рiзний стушнь зрiлостi в yправлiннi проектами.
4
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
Рис. 2 Структура модел1 технолопчно'Т зр1лост1 РМММ
- Рiвень 1 - Спльна мова: на цьому рiвнi оргашза^я усвiдомлюе важливiсть проектного менеджменту i потребу в доброму розумшш базових знань з управлiння проектами i супутньоТ мови/термшологи.
- Рiвень 2 - Спiльнi процеси: на цьому рiвнi органiзацiя усвiдомлюе, що необхщно визначити i розробити сшльш процеси так, щоб успiхи одного проекту могли бути повторен в шших проектах. На цьому рiвнi також вiдбуваеться усвiдомлення застосування i пiдтримки принципiв проектного менеджменту в шших методолопях, якi використовуються компашею.
- Рiвень 3 - €дина методологя: на цьому рiвнi оргашза^я усвiдомлюе синергетичний (взаемно пiдсилюючий) ефект об'еднання уах корпоративних методологiй в едину методолопю, центром якоТ е управлшня проектами.
- Рiвень 4 - Бенчмаркнг: цей рiвень мютить усвiдомлення того, що для утримання конкурентно'! переваги необхiдне покращення процеав. Бенчмаркiнг повинен вiдбуватися безперервно.
- Рiвень 5 - Постiйне покращення: на цьому рiвнi органiзацiя оцшюе iнформацiю, отриману вiд бенчмаркiнгу, i потiм вирiшуе, покращить чи н ця iнформацiя едину методологiю.
Необов'язково ус роботи мають виконуватись послщовно. Деякi рiвнi можуть перекривати один одний. I хоча таке перекриття часто мае мюце, порядок, в якому фази закшчуються, не може змшитися. Наприклад, нав^ь якщо Рiвень 2 частково перекривае Рiвень 1, Рiвень 1 повинен бути закшчений до того, як буде закшчено Рiвень 2. Такi перекриття рiвнiв можуть мати мiсце:
- Перекриття Рiвня 1 Рiвнем 2: таке перекриття буде мати мюце, тому що поки вщбуваються уточнення сшльноТ' мови, органiзацiя може розпочати розробку процеав управлшня проектами.
- Перекриття Рiвня 3 Рiвнем 4: таке перекриття вщбуваеться, тому що поки оргашза^я розроблюе едину методологiю, плануеться, як процеси можуть покращити методолопю.
- Перекриття Рiвня 4 Рiвнем 5: так як дiяльнiсть оргашзаци все бiльше здiйснюеться на основi застосування бенчмаркiнгу i постiйного покращення,
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
5
швидкють, з якою органiзацiя хоче проводити змши, може викликати значне перекриття цих двох рiвнiв.
Рiвень 3, як правило, не перекривае Рiвень 2. Можливо розпочати деякi роботи Рiвня 3 до закiнчення Рiвня 2, але це малоймовiрно. Осктьки компанiя сконцентрована на створеннi едино!' методологи, роботи над шшими методолопями, як правило, припиняються.
Також якщо компашя насправдi розумiеться у проектному менеджменту вона може почати впроваджувати бенчмаркiнг навiть на Рiвнi 1. Таким чином компашя може вчитись на помилках шших, шж на сво!х власних. Тому можливе перекриття Рiвнем 4 всiх трьох попередшх рiвнiв.
Ризики можуть бути визначеш на кожному рiвнi РМММ. Рiвень ризику найчастiше пов'язаний з необхщнютю змiнити корпоративну культуру i може бути низьким, середшм i високим (табл. 1):
- низький ризик: на корпоративну культуру фактично немае впливу або корпоративна культура динамiчна i готова прийняти змши.
- середнш ризик: оргашза^я усвщомлюе, що змши необхщш, але може не знати, який вплив на корпоративну культуру будуть мати ц змши.
- високий ризик: висок ризики мають мiсце, коли органiзацiя усвщомлюе, що змши вщ впровадження проектного менеджменту викликають змiни у корпоративна культурi. Наприклад, створення методологи, пол^ики i процедур управлiння проектами, а також децентралiзацiя влади i прийняття ршень.
Таблиця 1
Ризики за рiвнями технолопчно'|' зрiлостi компанп
Рiвень зрiлостi Опис Рiвень ризику
1 Сптьна мова середн1й
2 Сп1льн1 процеси середн1й
3 Сдина методолопя високий
4 Бенчмарк1нг низький
5 Пост1йне покращення низький
Рiвень 1: Спльна мова. Рiвень 1 - це рiвень, на якому оргашза^я вперше усвiдомлюе важливiсть проектного менеджменту. Оргашза^я може мати поверхневi знання з управлiння проектами або взагалi не мати нiяких знань. Рiвень 1 визначаеться наступними характеристиками:
- використання проектного менеджменту одиничне i випадкове. Вище керiвництво i керiвництво середнього рiвня забезпечують пiдтримку проектного менеджменту тiльки на словах. Пщтримка на рiвнi виконання вщсутня;
- можуть iснувати маленькi "осередки" iнтересу до проектного менеджменту, причому найбтьше такий iнтерес виявляеться в проектно-орiентованих галузях компани;
- не робиться спроб усвщомити вигоди проектного менеджменту. Менеджери бтьше турбуються про свш авторитет i владу i загрозливо зустрiчають новi пiдходи до управлшня;
- прийняття рiшень засноване на задоволенш iнтересiв того, хто 1х приймае, а не на задоволенш штереав компани в цтому;
- навчання i освiта в галузi управлiння проектами не пщтримуються через страх, що цi новi знання можуть змiнити iснуюче становище.
1снуе п'ять ключових дiй, як необхiдно виконати для переходу оргашзаци на Рiвень 2:
1. Оргашзувати початкове навчання i освiту в галузi управлiння проектами.
6
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
2. Заохочення навчання (або наймання) сертифкованих професшних менеджерiв проектiв (РМР).
3. Заохочення службов^в почати спiлкуватись на сшльнш мовi управлiння проектами.
4. Дiзнатися про доступнi iнструменти управлшня проектами.
5. Розробити розумiння принцишв проектного менеджменту (РМВОК).
Рiвень 2: Спшьш процеси. Вивчення основ проектного менеджменту i
навiть наявнiсть дектькох службовцiв, сертифiкованих як професiйнi менеджери проектв (РМР), не гарантуе, що проектний менеджмент буде застосовуватися в оргашзаци. Нав^ь якщо вiн застосовуеться, його використання може бути неефективним. На Рiвнi 2 органiзацiя узгоджуе зусилля, щоб використовувати проектний менеджмент i розробити процеси i методологи для пщтримки його ефективного використання.
На Рiвнi 2 органiзацiя усвщомлюе, що спiльнi методологи та процеси необхщш для того, щоб усшхи в управлiннi одним проектом могли бути повторен в iнших проектах. Рiвень 2 характеризуеться:
- Реальн вигоди вiд використання проектного менеджменту повинш стати очевидними. Найбiльш загальш вигоди — це зниження вартосп, скорочення графiку, нiяких жертв у змют чи якостi i можливють якнайкращого задоволення клiента.
- Управлшня проектами повинне пщтримуватись на вах рiвнях органiзацiТ, включаючи i вищi рiвнi. Можливо, будуть необхiднi змши у корпоративнiй культурi, тому запроваджуеться виконавча пiдтримка.
- Безперервний потк успiшно керованих проектiв вимагае методологш i процесiв, якi можуть використовуватись знову i знову.
- Управлшня проектами здшснюеться у рамках змюту i часу. Але також проекти повинш закшчуватись у рамках вартостк Тому вiдбуваеться усвiдомлення необхiдностi управлшня вартютю.
- Розробка плану навчання з управлшня проектами замють окремих курав i тренiнгiв.
1снуе чотири ключових дм, необхiднi для переходу з Рiвня 2 на Рiвень 3:
1. Розвинути культуру, яка б пщтримувала i поведiнковий, i кiлькiсний бiк проектного менеджменту.
2. Усвщомити рушiйнi сили для управлшня проектами i вигоди, якi можуть бути отримаш у найближчому майбутньому i у перспективi.
3. Розробити процеси i методологiю управлiння проектами таким чином, щоб бажаш вигоди могли бути отримаш на повторюванш основк
4. Розробити план постшного навчання управлiнню проектами для вах службов^в таким чином, щоб вигоди проектного менеджменту могли бути пщтверджеш i покращенi у майбутньому.
Рiвень 3: едина методологiя. На Рiвнi 3 органiзацiя усвiдомлюе, що через розробку единоТ методологiТ вона (оргашза^я) скорiше досягне взаемодiТ та контролю процеав, нiж при використaннi багатьох рiзних методологiй. Цей рiвень мае наступш характеристики:
- Iнтегровaнi процеси: оргашза^я усвiдомлюе, що бaгaточисельнi процеси можуть бути трансформоваш в один штегрований процес, який мiстить ва iншi процеси.
- Культурна пщтримка: iнтегровaнi процеси створюють едину методолопю. Саме через цю едину методолопю досягаються очкуваш вигоди. Виконання методологи вщбуваеться через корпоративну культуру, яка тепер вщ усього серця пщтримуе пiдхiд упрaвлiння проектами. Культура стае сшльною й об'еднаною.
"Управл1ння проектами та розвиток виробництва", 2004, № 1(9)
7
- Пщтримка управлшня: на цьому piBHi пщтримка проектного менеджменту проходить крiзь yci рiвнi управлiння компанieю. Ця пщтримка видима. Кожний рiвень управлшня розумie свою роль, i пщтримка необхщна, щоб змусити едину методолопю працювати.
- Неформальне управлiння проектами: з пщтримкою управлiння i сшльною культурою едина методологiя скорiше заснована на керiвництвах i контрольних списках, шж на розробцi жорстких процедур i пол^ики. Паперова робота зведена до м^муму. В органiзацiï повинш бути налагодженi ефективнi комушкаци', коопера^я, довiра i командна робота.
- Навчання i освгга: з сильною культурною пщтримкою оргашза^я усвiдомлюе фiнансовi вигоди вiд навчання управлiнню проектами. Ц вигоди можуть бути описаш i кiлькiсно, i якiсно.
- Майстернють поведiнки: органiзацiя усвiдомлюе рiзницi у поведiнцi при проектному управлшш i при лiнiйному управлiннi. Розробляються поведiнковi тренiнговi програми для покращення вмшь з управлiння проектами.
Для переходу з Рiвня 3 на Рiвень 4 необхiдно:
1. 1нтегрувати всi пов'язанi процеси в едину методолопю з продемонстрованим усшшним виконанням.
2. Заохотити загальнокорпоративне прийняття культури, яка пщтримуе неформальне управлшня проектами.
3. Розвинути пщтримку розподтено!' вщповщальностк
PiBeHb 4: Бенчмаркiнг. На Рiвнi 4 органiзацiя усвiдомлюе, що ïï iснуюча методологiя може бути покращена далк Але залишаеться складнiсть у розумшш того, як саме досягти цього покращення. Для проектно-орiентованих компанш постiйне покращення е способом пщтримання i подальшого удосконалення своïх конкурентних переваг. Постшне покращення найкраще здшснюеться через постiйний бенчмаркiнг.
Рiвень 4 характеризуеться наступними ознаками:
- Оргашза^я повинна заснувати Проектний Офю або Центр Майстерност для управлiння проектами. Це центральне мюце в компани для знань з управлшня проектами.
- Проектний Офю або Центр Майстерност повинш бути присвячеш процесу покращення управлшня проектами. За звичай це виконуеться персоналом, зайнятим повний робочий день.
- Компашя повинна проводити бенчмаркшг i в подiбних свош галузях, i в зовам шших. Сьогодш в свт компашя з п'ятирiчним досвщом в управлшш проектами може легко перевершити компашю, яка використовуе управлiння проектами 20 рош i бiльше.
- Компашя повинна проводити i ктькюний, i якюний бенчмаркiнг. Кiлькiсний бенчмаркшг аналiзуе процеси i методологiï, а якюний бенчмаркшг розглядае застосування i культуру управлшня проектами.
Для переходу з Рiвня 4 на Рiвень 5 необхщно:
1. Створити оргашзацш, присвячену бенчмаркшгу.
2. Розробити процес бенчмаркшгу управлшня проектами.
3. Вир^ити, що i вщ кого переймати.
4. Усвщомити вигоди бенчмаркшгу.
PiBeHb 5: Постшне покращення. На цьому рiвнi оргашза^я оцiнюе iнформацiю, отриману на еташ бенчмаркiнгу, i впроваджуе змши, необхщш для покращення процесу управлшня проектами. Саме на цьому рiвнi компашя приходить до усвщомлення того, що досконалють в управлшш проектами — це подорож, що школи не закшчуеться.
Рiвень 5 мае наступш характеристики:
8
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
- В кшц кожного проекту оргашза^я повинна створити картотеку отриманого досвщу. Аналiз навчальних ситуацiй по кожному проекту, обговорення зроблених помилок i отриманих знань е виршальними для того, щоб помилки не повторювались.
- Знання, отриман в кожному проекту повиннi бути перенесенi в ^i проекти i команди. Цього можна досягти завдяки щоквартальним або щопiврiчним форумам чи тренiнговим програмам з отриманого досвщу.
- Компашя повинна усвщомити, що для пщготовки майбутнiх проектних менеджерiв потрiбно ввести наставницьк програми. Також через наставницьк програми можуть бути переданi знання отриманий досвщ. Наставницькi програми найкраще адмшютруються через Проектний Офiс або Центр Майстерностк
- Загальнокорпоративне розумшня того, що стратегiчне планування для управлшня проектами е постiйно триваючим процесом.
Так як зрiлiсть в управлшш проектами — це "подорож", що нiколи не закiнчуеться, то досконалють в управлiннi проектами можна визначити як цикл, що школи не закшчуеться, який складаеться з бенчмаркшгу, постiйного покращення та удосконалення едино'' методологи. Це значить, що Рiвнi 3, 4 i 5 повторюються знову i знову.
Модель оргашзацшно! зрiлостi управлiння проектами PMI [3]. Модель оргашзацшноТ зрiлостi управлшня проектами (Organizational Project Management Maturity Model — OPM3) з'явилася в кшц 2003 року i е одшею з найновших моделей зртостк Вона надае базу знань про управлшня проектами в оргашза^ях в цтому i про зртють управлiння проектами в органiзацiях зокрема. Вона допомагае оргашза^ям зрозумiти й оцшити Тх поточний рiвень зртосп управлiння проектами i розробити шлях удосконалення, якщо вони забажають стати бтьш зрiлими.
ОРМ3 складаеться з трьох взаемопов'язаних елементв:
- Знання: описуе управлшня проектами в оргашза^ях i оргашзацшну зрiлiсть управлiння проектами, чому вони е важливими i як може бути визнана оргашзацшна зртють управлшня проектами.
- Оцшка: наводить методи, процеси i процедури, ям органiзацiя може використати для самооцшки своеТ зрiлостi.
- Удосконалення: забезпечуе процес, який призведе до росту зртостк
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
9
Рис. 3. Структура моделi ОРМ3
Елемент: Знання. Ще до р1шення про проведення оцшки чи вступання на шлях удосконалення орган1зац1я повинна мати ч1тке розум1ння того, що таке управлшня проектами в орган1зац1ях I оргашзацшна зр1л1сть управл1ння проектами. Цей елемент ОРМ3 дае таке розумшня I описуе, як може бути визнана оргашзацшна зртють управлшня проектами.
Цей елемент також надае визначення ключових термш1в, таких як Краща Практика, Складова, Результат I Ключовий Показник Ефективносп, I пропонуе, як Тх можна застосувати до управлшня проектами I портфелями проект1в всередиш оргашзаци.
Елемент Знання мютить описов1 роз'яснення для допомоги користувачам у розумшш управлшня проектами в оргашзаци, його визначення I застосування.
Елемент: Оцшка. Цей елемент надае користувачам шструмент для пор1вняння Тх поточного стану оргашзацшноТ' зр1лост1 управл1ння проектами з характеристиками, описаними в Модел1. Оцшюючи себе по в1дношенню до Кращих Практик, оргашзац1я може ктькюно визначити свою загальну зр1л1сть вщносно Складових, яких вона (орган1зац1я) досягла.
Також самооцшка допомагае орган1зацГТ визначити своТ сильн1 I слабк1 боки I визначити мюце на континуум! оргашзацшноТ' зртосп управл1ння проектами. Результати самооцшки будуть показан! на двох схемах (павутиннопод!бних д!аграмах), як! наочно зображують здобуття орган!зац!ею Кращих Практик. Об'еднання цих здобутих ! впроваджених Кращих Практик дасть процентне значення, яке нанесе оргашзацшну зртють управлшня проектами на континуум.
Елемент: Удосконалення. Цей елемент мютить базу даних, в якш знаходяться компоненти ОРМ3 - Кращ! Практики, Складов!, Результати ! Ключов! Показники Ефективност - а також вщношення м!ж ними. Ця база даних, яку користувач! можуть ф!льтрувати ! запитувати, е особливютю ОРМ3. Так як р1зн1
10
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
оргашзаци можуть застосовувати ОРМ3 у pi3HMx галузях, ця база даних дозволить користувачам знайти специфiчнi критери та параметри, важливi саме для ТхньоТ оргашзаци.
Базуючись на результатах оцiнки, органiзацiя може вирiшити пiти шляхом удосконалення i, вiдповiдно, визначити Кращi Практики, якi вона хоче полтшити. Користувач може звернутися до бази даних, щоб переглянути послiдовнiсть Складових, як ведуть до кожноТ КращоТ Практики, i Результатiв, якi необхщно отримати для пiдтвердження iснування даноТ СкладовоТ. Це дасть можливiсть визначити попередш кроки, якi вiд юнуючоТ' зрiлостi приведуть органiзацiю до бтьш досконалого стану. Крiм того, що буде окреслений шлях до такоТ "подорожГ, цей процес може допомогти зберегти обмеженi ресурси оргашзаци.
Концепщя "залежностей". Концепцiя "залежностей" е ще одшею особливiстю ОРМ3. 1снують залежност мiж Кращими Практиками i залежност мiж Складовими. Коли iснування одшеТ КращоТ Практики частково залежить вщ iснування шшоТ' КращоТ Практики, то принаймш одна зi Складових першоТ КращоТ Практики також повинна бути залежною вiд одшеТ' зi Складових другоТ КращоТ Практики.
Декомпозуючи кожну Кращу Практику на Складовi i показуючи залежностi мiж цими компонентами, ОРМ3 встановлюе послiдовнiсть, якоТ треба дотримуватись, щоб провести детальну i правильну оцшку. Крiм того, ця послщовнють також забезпечуе основу для шляху удосконалення. Таким чином, ОРМ3 являе собою об'еднаний i всебiчний пщхщ до управлiння проектами i перетворення стратегiТ оргашзаци на усшшш, послiдовнi i передбачуванi результати проек^в.
Модель зрiлостi для проектно-opicHTOBaHOi компанп [4]. Модель зрiлостi для проектно-орiентованоТ компанiТ (Maturity Model for the Project-oriented Company - РОС) мае павутиноподiбну структуру.
Ця модель також застосовуеться для визначення зртосп проектно-орiентованого суспiльства. Пiд проектно-орiентованим сусптьством розумiеться суспiльство, яке застосовуе проекти i програми як тимчасовi оргашзацшш структури.
Управлiння проектами
100
Стандартизащя УП
Маркетинг УП
Дослiдження в галузi УП
Управлiння програмами
Управлшня портфелем
Управлiння персоналом
Освiта в галузi УП Органiзацiйна модель
Рис. 4. Структура модел1 технолог1чноТ зр1лост1 проектно-ор1ентованоТ компанп "Управл1ння проектами та розвиток виробництва", 2004, № 1(9)
11
Модель мае наступш характеристики:
- Управлння проектами — це б1знес-процес проектно-ор1ентованоТ компани. В1н складаеться з пщпроцеав: старт проекту, координац1я проекту, контролшг проекту, управл1ння розривами проекту та закриття проекту.
- Управлння програмою: програма — це наб1р проект1в I завдань, як1 т1сно пов'язаш сп1льними ц1лями, стратег1ями, правилами I цшностями.
- Портфель проект'в - це наб1р проект1в (I програм), як1 виконуються проектно-ор1ентованою компан1ею в певний момент часу.
- Процеси управлння персоналом у проектно-ор1ентованих компашях — це наб1р персоналу, розподт обов'язк1в I розвиток персоналу проекту (вщ члена команди проекту I молодшого проектного менеджера до старшого проектного менеджера I кер1вника проекту).
- Оргашза^йна модель: проектно-ор1ентован1 компани мають штегроваш структури, так1 як Проектний Офю, Групи управл1ння портфелями проект1в або Групи експерт1в.
- Офщшш освiтнi програми в галуз/ управлння проектами повинн1 забезпечувати отримання наукових ступен1в з проектного менеджменту.
- Дослiдження в галуз управлння проектами та програмами, пов'язаш з проектним менеджментом публкаци та поди - там послуги надають оргашзаци з дослщження УП.
- Основна оргашзац1я з маркетингу управлння проектами в проектно-ор1ентованому сусшльств1 — це Нацюнальна асоц1ац1я з управлшня проектами. Членство, сертиф|кац1я проектних менеджер1в, под1Т у св1т1 управлшня проектами та шш1 послуги надае ця оргашзац1я.
- Послуги, що надаються оргашзац1ями з1 стандартизацИ управлння проектами - це норми управлшня проектами та офщшш вимоги до управлшня проектами для вщкритих тендер1в.
12
"Управлшня проектами та розвиток виробництва", 2004, № 1(9)
Управлшня проектами i управлiння програмами е бiзнес-процесами проектно-орiентованоT компани. об'ектами розгляду е не ттьки змiст проекту, час i вартiсть, але також органiзацiйна структура, культура i контекст проекту або програми.
Процеси i методи управлiння програмою подiбнi до процеав i методiв управлiння проектом. Але крiм едино! проектноТ оргашзацшноТ структури необхщш новi органiзацiйнi структури.
Для управлшня проектами i програмами проектно-орiентована компанiя поеднуе постiйнi i тимчасовi органiзацiйнi структури. Специфiчними постiйними оргашзацшними структурами е Проектний Офiс, Групи управлшня портфелями проек^в i Групи експер^в.
Модель зрiлостi для проектно-орiентованоl компани дозволяе графiчно зобразити зртють, досягнуту компанiею у рiзних аспектах управлшня проектами. Завдяки цьому також можна легко побачити т сфери, в яких зртють управлшня проектами ще недостатня i куди найперше треба спрямувати зусилля компани.
Таблиця 2
Порiвняльна таблиця моделей зрiлостi ynравлiння проектами
\ Параметр Mодель\ зртост \ Охоплення вах шструмен^в проектного менеджменту Перенесення кращого досвщу Розвиток персоналу Oптимiзацiя бiзнес-процеав в оргаызацп Формування едино!' методологи розвитку проектного менеджменту
СMM ** * * ** *
PMMM ** ** ** ** **
OPM3 ** ** * ** **
РОС ** * ** ** *
* - представлено в меншш мiрi; ** - представлено в бтьшш мiрi
Висновки та використання результатiв. Ус розглянуп моделi зрiлостi надають органiзацiям можливють створення ефективноТ системи управлiння проектами. Вс моделi допомагають визначити поточний рiвень зрiлостi органiзацiï, провести аналiз сильних i слабких ïï бош. Вони дозволяють розробити стратегiю для подальшого розвитку органiзацiï i надають можливють для постшного удосконалення ï'ï дiяльностi.
Pозглянутi моделi зрiлостi мають багато спiльних рис, Тх поеднують цiлi, спрямованi на розвиток оргашзацш i покращення виконання проектiв в них. Але незважаючи на це, кожна модель залишаеться ушкальною i мае своУ особливостi. Кожна з них концентруе увагу на одних аспектах управлшня проектами в бтьшш мiрi, на шших - в меншш. Наступна таблиця показуе порiвняння розглянутих моделей зрiлостi.
Л1ТЕРАТУРА
1. CMMIsm for System Engineering/Software Engineering, Version 1.02. Carnegie Mellon Software Engineering Institute. - 2000.
2. Kerzner H. Strategic planning for Project Management using a project management Maturity Model, John Wiley & Sons, Inc. - 2001.
3. Organizational Project Management Maturity Model - OPM3. PMI Today. October 2003.
4. Бушуев С.Д., Бушуева Н.С. Развитие технологической зрелости в управлении проектами.// Управлшня проектами та розвиток виробництва. Збiрник наукових праць. Пщ ред. В.А. Рач. - 2003. - № 2(7).- C. 5-12.
Стаття надмшла до редакцп 26.01.2004 р. "Управлшня проектами та розвиток виробництва", 2004, № 1(9) 13
