запланованих змін. З іншого боку, якщо певні завдання включені в річний план, а на їх рішення виділені деякі кошти в бюджеті, то виходить, що в разі відхилення зміни CAB починає скасовувати рішення, прийняті топ-менеджментом компанії. І тут відразу виникає питання про права CAB і про готовність його членів брати на себе відповідальність.
речі кажучи, сама завдання кооптірованія до складу CAB представників замовників і груп користувачів представляється вельми нетривіальним. З причин, викладених вище, замовникам (навіть якщо вони розуміють, що вони - замовники) участь у CAB НЕ дає можливостей серйозно впливати на ситуацію. А ось додаткові обов'язки і відповідальність у них при участі в CAB з'являються.
У стандартній ситуації CAB (якщо він є) складається із співробітників ІТ і працює виключно всередині корпоративної ІТ-служби. У цьому випадку CAB може тільки підвищити ефективність підготовки змін і більш грамотно здійснювати календарне планування змін.
Зміни в прикладному ПЗ
Ще один істотний аспект: класичний ITIL, взагалі кажучи, однозначно не включає в управління змінами доопрацювання та/або розробку прикладного ПЗ. Адже для більшості замовників оперативне та своєчасне виправлення помилок, зміна функціональності внаслідок змін у бізнес-процесах, розширення функціональності прикладного ПЗ мають значно більшу цінність, ніж стійкий доступ до бізнес-додатком і якісне обслуговування. І нікуди не дінешся - процедури обробки запитів на доопрацювання/розробку прикладного ПЗ доводиться вибудовувати.
Причому подібність між В«КласичнимВ» процесом управління змінами ITIL і підготовкою і внесенням змін до прикладне ПЗ дуже велике:
В· одні й ті ж учасники (service manager, менеджери систем та експерти з прикладного ПЗ, представники замовника, фінансові служби);
В· схожі потенційні ризики (недоступність системи, втрата даних) і подібні шляху боротьби з ними (тестування, резервне копіювання, планування відкату);
В· потенційний перехід у формат проектної діяльності;
В· часто - одні й ті ж джерела фінансування;
В· неминучий перерву в наданні ІТ-послуг при реалізації і необхідність його оптимально спланувати.
Деякі випадки взагалі складно класифікувати. Наприклад, якщо мова йде про доопрацювання системи обміну даними в розподіленої прикладної системі. З одного боку, це доробка прикладного ПЗ, а з іншого - змінюються функції, не видимі кінцевим споживачам, і стосуються радше до платформи, ніж до додатка.
Якщо ж говорити про етап реалізації, то з точки зору кінцевих споживачів немає ніякої різниці, через чого стався планову перерву в наданні послуги: проводиться заміна апаратної частини системи, відключили на профілактику телекомунікації або встановлюють новий реліз ПЗ.
Пропонована модель
Можливий варіант моделі, за якою можна відбудувати управління змінами, виглядає наступним чин...
