аті введення Управління змінами, а також виміряти швидкість і ефективність, з якою ІТ-інфраструктура реагує на ідентифіковані потреби бізнесу.
Вимірювання повинні бути пов'язані з цілями бізнесу скрізь, де це практично, а також з вартістю, доступністю і надійністю послуг. Будь-які прогнози повинні порівнюватися з реальними показниками.
Погоджений графік змін і моделі змін.
Одна область Управління змінами розвивається значно швидше інших.
концепція побудови моделей Змін до початку впровадження. Ці моделі в основному застосовні до невеликих стандартним Змінам, таким як установка нового або модернізованого ПК. Управління потужностями також може допомогти в побудові великих моделей складних Змін, щоб оцінити можливий вплив до того, як ці Зміни увійдуть в силу. Загалом, побудова моделі для оцінки потужностей відбувається для Змін, які не є стандартними з погляду складності та/або масштабу.
Слід приділяти увагу питанням, пов'язаним з визначенням відповідальності за оцінку впливу великого Зміни. Це не є питанням використання кращих практичних методів, оскільки організації настільки різні за розмірами, структурі і складності, що не існує рішення, єдиного для всіх. Тим не менш, рекомендується, щоб великі Зміни спочатку обговорювалися з усіма залученими сторонами (з тими, хто займається управлінням програмами/проектами та Управлінням змінами), щоб прийти до розумних кордонів відповідальності та покращити комунікації. Незважаючи на те, що Управління змінами несе відповідальність за оцінку Змін та, у випадку їх затвердження, за їх розробку, тестування, впровадження та аналіз, зрозуміло, що кінцева відповідальність за ІТ-послугу, включаючи проведені в ній Зміни, лежить на ІТ-директора , Менеджері ІТ-послуг і Замовників, які контролюють фінансування. САВ може рекомендувати прийняття (або відхилення) більш значних Змін, але їх вплив має обговорюватися в досить великому масштабі, що може перенести кінцеву відповідальність за межі Управління послугами або навіть за межі ІТ та процесу Змін. «Відповідальність» тут розглядається в рамках процесу Управління змінами, а також пов'язаних з ним ризиків і бюджетних обмежень.
З іншого боку, невеликі Зміни можуть бути проведені з використанням «стандартних» моделей Змін - наприклад, обмін ПК або регулярне оновлення ПЗ. До тих пір поки дотримується приписаний графік разом з усіма критеріями (можливо, критеріями, пов'язаними, наприклад, з процесами побудови та тестування), Менеджери процесу Управління змінами можуть авторизувати подібні Зміни без задіяння всього процесу Управління змінами. Малюнок 2.8 показує, як процес використання стандартних моделей Змін, визначений Менеджерами процесу Управління змінами при згоді інших менеджерів процесів підтримки послуг, може бути інтегрований в рамки звичайних процесів Змін. Слід зауважити, що визначення масштабу або складності Змін, пов'язаних з використанням моделей, індивідуальні для кожної організації.
Концепція графіку впровадження Змін залишається незмінною, хоча настійно рекомендується, щоб інсталяція Змін проходила відповідно до графіка, відповідним для бізнесу, а не тільки для ІТ. Для мінімізації простою у наданні послуг ІТ-управління нерідко намічає великі Зміни під час вихідних, але ймовірно, що ті ж самі менеджери планують простий під час робочого дня для необхідного супроводу. Зараз більшість менеджерів активно уникають будь-якого планованого простою під час годин обслуговування і забезпечують призначення більшої частини Змін таким чином, що при цьому передбачають місце для можливої ??появи великих Проблем, які можуть виникнути через затримки у впровадженні або через дуже термінових Змін.
Для того щоб поліпшити цей процес, Менеджери процесу Управління змінами повинні координувати розробку та розповсюдження «Узгодженого графіка змін» (FSC) і «Очікуваної доступності послуги» (PSA, або Projected Service Availability). Новітні версії цих документів повинні бути доступні кожному співробітнику в рамках організації. Переважно, щоб ці версії перебували на загальнодоступному інтернет або інтранет - сервері. FSC містить відомості про всіх змін, затверджених до впровадження, і пропоновані дати їх впровадження. PSA містить відомості про Зміни в узгоджених SLA і про доступність послуг унаслідок планованого FSC. Ці документи повинні бути погоджені з Замовниками з бізнесу, з Управлінням рівнем обслуговування, зі Службою Service Desk і з Управлінням доступністю. Після узгодження Служба Service Desk повинна повідомити всьому співтовариству користувачів про будь додатково планованих простоях найбільш ефективним з доступних способів.
Якщо організація описала моделі процесів для процесу Управління змінами та інтегрувала ці моделі в рамки загальної моделі Підтримки послуг, то залишається просте завдання по оцінці результату Зміни без ризиків і витрат, пов'язаних зі зміною процесу в робочому режимі. При побудові моделі крупного Зміни, ви можете...
