оцеси і політики компанії. Що потрібно зробити, щоб вивести управління ризиками бізнесу на новий рівень?
Постановка в компанії системи ризик-менеджменту (ERM 1 ) вимагає комплексного підходу. Це рішення і дії в області структури, регламентів, IT-інфраструктури та навчання. Але перш ніж приступати до змін, необхідно розуміти, з якими ризиками стикається ваше підприємство.
Види ризиків
Ризик - Характеристика ситуації, що має невизначеність результату, при обов'язковій наявності несприятливих наслідків. У бізнесі поняття ризику охоплює також невизначені події з можливим успішним результатом.
Управління ризиком націлене на те, щоб визначити якомога більше можливих негативних подій (того, що може піти не так), мінімізувати їх вплив, постаратися впоратися з реакцією на ті події, які все ж відбудуться (спланувати дії в надзвичайних обставинах), і забезпечити кошти на покриття непередбачених витрат.
У літературі та Інтернеті ви знайдете чимало класифікацій ризиків (за джерелом виникнення, за характером і масштабами впливу і т.п.), але з точки зору побудови в компанії системи ризик-менеджменту корисно ділити ризики на 3 категорії:
стратегічні ризики;
програмні і проектні ризики;
операційні ризики.
Таке поділ обумовлено принциповою різницею в способах управління кожної з виділених категорій ризиків. Спроба усунути операційний ризик (хай і що впливає на цілі проекту) за допомогою проектної методології не вирішує проблему. Зусилля з управління стратегічним ризиком в рамках одного окремо взятого проекту також не увінчаються успіхом.
Розглянемо застосування невідповідних методів управління ризиками на конкретних прикладах.
Приклад 1
У інжинірингової компанії команда управління проектом ідентифікувала групу ризиків, пов'язаних з помилками інженеровконструкторов і програмістів на етапі розробки технічно складного продукту. Для зниження ймовірності цих ризиків команда прийняла 2 рішення:
передбачити планом проекту додаткові процедури контролю якості;
залучити до розробки найбільш досвідчених програмістів і конструкторів.
Реалізувати рішення на практиці виявилося неможливо. Інженерні підрозділи і відділ контролю якості дотримувалися процесів, обумовлених системою менеджменту якості компанії, і не збиралися змінювати способи організації роботи заради одного проекту. Крім того, керівники відділів розробки та програмування не змогли виділити когось із своїх співробітників як більш досвідченого в розробці цього конкретного продукту і вважали за краще направити на проект вільних на даний момент фахівців.
Очевидно, що усунення або зниження ризиків помилок розробників вимагає змін на рівні структури і процесів. Це операційні ризики, і хоча вони можуть надати негативний вплив на цілі проекту, їх слід розглядати, не пов'язуючи з певним проектом.
Приклад 2
Команда управлінн...
