Як розробити програму управління змінами в ІТ
"Потрібно враховувати, що немає більш важкою для виконання, сумнівною для успіху і найбільш близькою до провалу завдання, ніж встановлення нового порядку речей."
Макіавеллі (1446-1507)
Програма управління змінами (ПУИ) більш відома як процес управління змінами або ж контроль над процесом з управління змінами - це формальний процес, який використовується для того, щоб усі зміни в роботі над виробом або в системі велися скоординовано і підконтрольний (опис цього є в стандарті ISO-20000). ПУИ - це не управління організаційними змінами, не варто їх плутати. Уои управляє результатами бізнес-процесів, включаючи і створювані завдяки ІТ-ініціативам, змінами в організаційній структурі, а також в корпоративній культурі підприємства. По суті, Оуї управляє змінами в частини персоналу.
Мета ПУИ - це максимальне скорочення можливих негативних моментів у процесі зміни ІТ-складової компанії, що досягається за допомогою стандартизації процесу управління. Деякі зміни в системі просто не можуть залишитися без уваги - наприклад, якщо змінюється стандарт штрихового коду, необхідна реакція адаптації до цих ізмененіям- якщо змінюється порядок оподаткування - ви теж повинні стежити за змінами. Саме тому всіма цими змінами потрібно управляти.
Ніколи не варто робити відповідні зміни без якого або нагляду в системі. Будь-які ідеї по зміні роботи повинні не тільки узгоджуватися з вищим керівництвом, але і оголошуватися всьому колективу компанії. Без обговорення дій на вищому рівні ПУИ - це просто втрата часу і коштів, але, якщо правильно поєднати всі кошти, то дана програма вбереже вас від багатьох серйозних помилок.
Кроки
1
Розробіть запит на зміни (ЗІ). Це означає, що необхідно створити спеціальну форму, яка буде заповнюватися і надаватися при наявності питання, серії питань та ідей з даного приводу для запобігання майбутніх негативних наслідків. ЗИ буде корисний і в тому випадку, коли будуть з`являтися нові бізнес-рішення, здатні впливати на основний курс компанії. Також ЗІ необхідний за умови зовнішніх впливів (постанова влади, зміни ведення справ партнерами і т.д.).
2
Створіть умови для зміни бізнесу. Внесення змін до ведення справ - це бізнес-рішення, для прийняття якого необхідно зіставити прибуток з витратами. Навіть у ситуації змін виключно інфраструктури (в силу виходу з ладу ІТ-системи або її компонентів), витрати понесе бізнес, а не ІТ-відділ. Були випадки, коли розроблялися спеціальні процедури по резерву коштів на аварійне обслуговування системи - але основне рішення все одно лежить на керівництві компанії.
3
Створіть проект підтримки змін. Розвиток змін (і їх тестування) входить до функціонал ІТ-відділу. Якщо трапляється аварійна ситуація, начебто поломки сервера, функції ІТ, як правило, прописані, в той час як при розробці нової системи потрібна спільна робота ІТ-команди і бізнес-користувачів. Систему розробляє ІТ, вона затверджується керівництвом бізнесу, впроваджується ІТ, тестується представниками ІТ і користувачами і остаточний продукт затверджується і тими, і другімі.Особое увагу потрібно приділяти впливу нововведень на існуючі системи.
4
Перевіряйте управління зміни спеціальним відділом - для цього потрібно створити комітет щодо змін (КПІ). КПІ аналізує всі зміни перед їх впровадженням в систему, в цей комітет повинні входити люди з різними точками зору і великими знаннями. Функція такого відділу проста - перевірити, що зміни в процесі роботи пройдуть максимально безболісно, а на випадок будь-яких ексцесів перевірити наявність технологій, що дозволяють компенсувати недоліки нової системи. Перед тим, як ввести якісь зміни, команда розробників передає свій проект в КПІ, де його ретельно перевірять на можливі ризики. Стратегія впровадження в систему, комунікації із зацікавленими особами, контроль результатів та умови відновлення можливих помилок - все це ті чинники, над якими має працювати КПІ. До слова, комітет по змінах НЕ відповідає за визначення доречності змін - це вирішують за нього. Також КПІ не повинен відповідати за економічну ефективність нововведення - це рішення виключно за керівництвом бізнесу.
5
Впровадити зміни. Якщо КПІ висловив незгоду з приводу змін і видав ряд причин, по яких нововведення буде ризикованим (це буває досить часто, так як не всі ризики можна прорахувати наперед або не всі комунікації були заздалегідь сплановані), команді розробників змін дається час на перепланування дій та надання нового плану КПІ. Якщо комітет схвалить, то можна реалізовувати проект. Звичайно, не завжди потрібно, щоб КПІ стежило за реалізацією нововведень, але часто у консультантів комітету є великий досвід, який стане в нагоді в процесі впровадження змін - хоча знову ж таки, ці люди будуть швидше експертами з конкретних питань (ЕКВ), а не представниками КПІ. Коли відбувається зміна, то всі кроки щодо його реалізації повинні бути задокументовані і підтверджені КПІ. Весь процес повинен бути ретельно задокументований, а затверджений процес повинен неухильно дотримуватися.
6
Повідомте про результати. Незалежно від того, чи успішно було введено зміна, чи були деякі проблеми по ходу реалізації проекту або, гірше за все, зміни спровокували збій у роботі і не можуть бути швидко виправлені - все повинно бути передано в КПІ і документально оформлено. КПІ, в свою чергу, відповідає за передачу інформації зацікавленим сторонам і збереження документів укупі з підтримкою результатів в системі управління змінами (і неважливо, автоматизована чи це база даних, або ж все є тільки на папері, так чи інакше, всі дані повинні бути доступні для аудиту).
7
Контролюйте виникнення проблем внаслідок змін. Будь-які виникаючі питання слід зіставляти з документацією КПІ щоб уникнути непередбачених проблем і побічних ефектів. Найчастіше небажані наслідки не видно відразу і проявляються лише в процесі користування системою при реєстрації проблеми у відповідних системах. Так, наприклад, додавання нових полів до бази даних може не мати прямого негативного впливу на систему, але можуть очевидним чином вплинути на роботу в мережі інших користувачів, що не мають доступу до роботи з модифікацією системи.
8
Необхідно періодично проводити аудит ПУИ. Принаймні, необхідно хоча б раз на рік проводити аудит ПУИ, щоб гарантувати доступність і заповнення документації. Всі документи повинні бути попередньо розглянуті і мати відповідні підписи і печатки. Результати змін також повинні бути задокументовані і оформлені.
Поради
- Спеціальне обладнання повинно відповідати регламенту ПУИ. Так, в приміщенні з обладнанням повинні бути перевірені системи пожежогасіння, очищений чорнову підлогу в дата-центрі, повинна проводиться постійна вентиляція і навіть проводитися боротьба з шкідниками. Відомі випадки, коли ЗІ надходив навіть з приводу поломки лампочки в центрі обробки даних (наприклад, сходи впала і пошкодила мережу).
- Стандартні профілактичні роботи повинні затверджуватися заздалегідь. Так, якщо час перезавантаження сервера - 2 годині ночі в неділю, то не варто подавати ЗІ кожен раз, а просто затвердити регулярність цих робіт.
- Всі процедури повинні розглядатися ПУИ. Якщо навіть в резервній системі планування є зміни, вони повинні пройти через управління змінами. Аналізуйте будь-які зміни (у системі або процесах), щоб визначити наявність пов`язаних з ними ризиків.
Попередження
- Будь-які рішення повинні передаватися в КПІ. Звичайно, запит «це зміна потрібно» може бути і обгрунтованим, але також він може бути і особистої амбіцією одного з керівників. КПІ повинні перевіряти всі рішення і аналізувати ризики впровадження того чи іншого зміни.
- Періодично міняйте складу КПІ. Одні й ті ж члени комітету можуть, зрештою, почати приймати одні й ті ж рішення, що викличе застій розвитку компанії. Тому грамотною політикою буде періодична ротація КПІ, що дозволить вам мати під рукою надійний аналітичний інструмент.
Citations
International Standards Organization
COBIT
ITIL
Wikipedia Reference
