Меню

Підручник з управління змінами | Що таке управління змінами

  • Головна
  • Інший
  • Підручник з управління змінами | Що таке управління змінами

change management tutorial what is change management

Спробуйте Наш Інструмент Для Усунення Проблем

Цей всеосяжний посібник з управління змінами детально пояснює процес управління змінами, моделі, переваги та 7R:

Управління змінами (англ. Change Management, CM) - це набір інструментів, процесів та методів, що використовуються для допомоги особам у переході з існуючого стану в організації в новий.

СМ можна розуміти як:

  • Управління конфігурацією для управління кодом та вимогами.
  • Впровадження організаційних змін.
  • Відстеження будь-яких змін, що відбуваються в ІТ-інфраструктурі - Управління ІТ-послугами (ITSM).

Підручник з управління змінами

Що ви дізнаєтесь:

Огляд управління змінами

Мета CM полягає у застосуванні стратегій для зміни цілей, процесів чи технологій організації, нагляду за запитами на зміни та допомоги працівникам у здійсненні запропонованих змін.

Це означає, що обов’язковим є наявність:

  • Процедура, дуже добре організована для вирішення змін.
  • Добре підготовлений набір процедур підготовки відповіді на запити.
  • Механізм подальшого спостереження за виконанням запиту.

Щоб розпочати процес управління змінами, організація повинна врахувати вплив, який всі змінені процеси, системи матимуть в організації.

Повинні існувати такі процеси:

  • Сплануйте зміни
  • Перевірте зміну
  • Повідомте про зміни
  • Заплануйте зміни
  • Внесіть зміни
  • Документуйте зміну
  • Оцініть результати

Документація є важливим аспектом СМ, оскільки ми маємо підтримувати процес, а також відкат у разі необхідності такої дії.

Визначення управління змінами

Виходячи з різних точок зору, СМ можна визначити наступним чином:

  • З точки зору спеціаліста з інфраструктури, це систематичний підхід до апробації, випробування та встановлення нового обладнання або нового випуску.
  • З точки зору проекту, це процес, який використовується для отримання дозволу на зміни обсягу, термінів або бюджету проекту.
  • З методологій - PMP, Prince2, ITIL, перспектива ISO20000, це процес отримання апробації та внесення змін до проекту або робочого середовища.
  • З точки зору PROSCI, Асоціації фахівців з управління змінами (ACMP), Інституту управління інноваціями та організаційними змінами (IOCMI), це процес надання допомоги організаціям у використанні СМ на кожному рівні.
  • З точки зору розробки програмного забезпечення, це процес, що включає відстеження та управління змінами, вимогами та кодом.

Процеси управління змінами також відповідають за відстеження будь-яких змін, що відбуваються в ІТ-інфраструктурі. ISO 20000 - це стандарт, який визначає мету управління змінами. Для належного відстеження та обробки використовується кожна зміна, внесена до набору стандартизованих методів та процедур.

З точки зору змін документації, назва, що використовується для такої зміни, є управлінням конфігурацією, і для належної обробки контролю версій обов’язково використовувати інструмент управління змінами.

Інструмент СМ виконує такі дії:

  • Відстежуйте всі внесені зміни.
  • Обґрунтуйте внесені зміни на випадок, якщо це буде потрібно.
  • Переконайтеся, що доступні кілька шляхів для можливості одночасної розробки різних версій одного продукту.
  • Переконайтеся, що виправлення коду або вдосконалення коду пов’язані з дефектами, збірками та випусками.

Беручи до уваги вступ, має бути зрозуміло, що для визначення терміну управління змінами нам доведеться зрозуміти контекст, в якому ми хотіли б його визначити.

Типи організаційних змін

Це частина управління, що використовується для управління багатьма типами організаційних змін. Найважливіші типи організаційних змін такі:

  1. Зміни у розвитку: Це означає будь-які зміни на організаційному рівні, що стосуються вдосконалення раніше встановлених процесів та процедур.
  2. Перехідні зміни: Це зміна, пов’язана з переходом організації з існуючого стану в інший абсолютно новий стан, припускаючи, що організація має проблему, яку можна вирішити, змінивши поточний стан.
  3. Трансформаційні зміни: Він має справу зі змінами, корінно змінює культуру та діяльність організації.

7R’s Of Change Management

ITIL “Перспективи бізнесу, том II” містить контрольний перелік із семи простих запитань у розділі про безперервність бізнесу, який окреслює кроки у визначенні зміни ризику змін та вивченні ефективності процесу управління змінами.

Нижче розглянуто сім питань:

# 1) 'Хто ПІДВИТАЛ зміни?'

Є багато точок входу та зацікавлені сторони, визначені джерелом змін. Це наводить на думку, що обов’язковою є наявність системи збору всіх змін. Така система повинна включати прийнятний контроль для вирішення питань, що стосуються внесення змін до цільових областей.

№2) “ЯКА ПРИЧИНА змін?”

Перш за все, ми повинні зрозуміти, чи може зміна спричинити ризик без будь-яких вигод для бізнесу. Кожна велика зміна повинна бути проаналізована на основі узгоджених критеріїв аналізу портфеля.

як виглядає модем

№3) 'Який ПОВЕРНЕННЯ вимагається від зміни?'

Обов’язковим є розуміння того, чи генерує зміна фінансову окупність.

№4) 'Які РИЗИКИ втягують зміни?'

Ризики класифікуються на ризики, які можуть бути прийняті, або ризики, які слід пом'якшити. Вирішальним кроком у визначенні небезпеки є аналіз впливу змін на існуючу інфраструктуру. ITIL використовує концепцію 'тяжкості' для потенційних ризиків та реальних проблем.

№5) “Які РЕСУРСИ потрібні для здійснення змін?”

Коли ми обговорюємо ресурси, ми думаємо про людей та ІТ-активи, необхідні для впровадження змін. З точки зору людей, ми повинні розуміти, які є навички, необхідні для впровадження змін. Після того, як ми зрозуміли необхідні навички, ми повинні бути впевнені, що ці навички доступні.

№6) 'Хто ВІДПОВІДАЛЬНИЙ за частину змін' побудувати, протестувати та впровадити '?'

Відповідальність за створення, тестування та впровадження змін програми повинна бути розподілена відповідно до вимог відповідності та аудиту. Розподіл відповідальності повинен бути простежуваним, забезпеченим виконанням та діяти протягом усього процесу управління змінами та звільненнями.

# 7) 'Який ВІДНОСИН між цією зміною та іншими змінами?'

Аналіз взаємозв'язку змін потрібно проводити зсередини та за межами функціональних меж. Планування запланованих змін має бути спільним, і таким чином аналіз впливу змін і взаємозв'язок, відображення можуть бути частиною інтегрованої бази даних управління конфігурацією (CMDB).

Відповідь на ці сім питань дає деякі важливі переваги:

  • Послуги є більш надійними та доступними для споживачів, оскільки організації повинні використовувати набір показників, що забезпечує більш об'єктивний засіб вимірювання ризику змін.
  • Ми можемо зрозуміти, наскільки наш процес управління змінами відповідає існуючому, та визначити їх у нових методах.
  • Наявність процесу управління змінами, що підлягає аудиту, є дуже важливою, оскільки існує залежність між бізнесом від ІТ-послуг та новими вимогами.

Моделі управління змінами

Метою моделей управління змінами є надання керівних принципів, що допомагають менеджерам узгодити сферу пропонованих змін із існуючими інструментами.

# 1) ADKAR (Prosci)

Модель ADKAR є послідовною цільовою моделлю управління змінами. Його створив Джефф Хаят, засновник компанії Prosci.

ADKAR (Prosci)

(зображення джерело )

Поінформованість та бажана мета полягають у зміні поточного стану, в якому ми усвідомлюємо, що зміни потрібні, але процес змін ще не розпочався.

На фазі переходу з’являються знання та вміння. А в майбутньому з’явиться підкріплення.

ЦІЛЬ 1: Поінформованість

Іноді зміни неминучі в організації і виводять людей із зони комфорту. Якщо ми пояснимо причину змін заздалегідь, то у працівників буде достатньо часу, щоб прийняти зміни та підготуватися до них.

ЦІЛЬ 2: Бажання

Якщо співробітники зрозуміють необхідність змін та вигоди, що входять до них, ми побачимо захоплене ставлення та бажання взяти участь у впровадженні змін.

Якщо ми не розуміємо почуттів працівника щодо змін, і ми не розглядаємо належним чином їхні страхи і не показуємо їм, як зміна приносить їм користь особисто, тоді вони не будуть повністю підтримувати зміни і не матимуть бажання брати участь у впровадженні змін.

ЦІЛЬ 3: Знання

Для впровадження нових процедур нам доведеться навчити команду та надати їй найкращі практики, щоб вони могли зрозуміти, як впровадити зміни.

ЦІЛЬ 4: Здатність

тестування запитань та відповідей веб-служб

Потрібна практика, щоб перевести знання на вміння. Краще мати якесь моделювання, щоб проаналізувати результати та внести корективи. Ми повинні контролювати співробітників, коли вони починають впровадження змін, і на основі конструктивних відгуків ми можемо вдосконалити процес.

ЦІЛЬ 5: Підкріплення

Ідея цієї мети полягає в тому, що ми повинні заохочувати працівників продовжувати стежити за змінами з часом.

# 2) Модель переходу мостів

Модель переходу мостів була розроблена Вільямом Бриджесом. Це модель, орієнтована на людей. Головна мета - керувати переходом досвіду людей до змін. Сила цієї моделі полягає в тому, що вона орієнтована на перехід, а не на зміни.

Ідея 'Мостів' полягає в тому, що люди будуть стежити за етапами у своєму власному темпі. Модель визначає 3 етапи переходу:

  • Етап 1: Закінчення, програш і відпускання

Коли співробітники вперше представлять зміни, вони вступлять на цей початковий етап переходу. Вони будуть стійкими, бо їх якось змушують робити щось, з чим вони не відповідають. Співробітники повинні зрозуміти і прийняти, що щось закінчується, перш ніж вони приймуть нову ідею.

  • Етап 2: невизначеність або нейтральна зона

Цей етап є ніби мостом між старою державою та новою державою. Співробітники все ще прив'язані до старого, але вони намагаються адаптуватися до нового стану. Це ідеальний момент для того, щоб працівників спонукали спробувати новий спосіб роботи. На цьому етапі відгук дійсно важливий.

  • Етап 3: Прийняття або новий початок

Це час, коли працівники починають приймати ініціативу щодо змін. Співробітники формують навички, необхідні для нових процедур.

# 3) Бібліотека ІТ-інфраструктури (ITIL)

Це структура, що містить детальні вказівки щодо управління змінами в ІТ-інфраструктурі та ІТ-операціях.

ITIL 4 був випущений в 2019 році, і в ньому основні ключові моменти зосереджені на автоматизації процесів, вдосконаленні управління послугами та інтеграції ІТ-відділу в бізнес.

ITIL 4 містить дев'ять керівних принципів і представлені на малюнку нижче:

Бібліотека ІТ-інфраструктури (ITIL)

(зображення джерело )

Перш ніж впроваджувати ITIL в організації, обов’язково потрібно відповісти на деякі запитання, пов’язані з подібним, які проблеми в організації намагаються вирішити та який шлях до постійного вдосконалення сервісу.

# 4) Коттерова 8-ступінчаста модель зміни

Джон Коттер представив 8-ступінчасту модель змін, яку він розробив на основі досліджень 100 організацій, які перебували в процесі змін.

Коттер пропонує, що нам слід наполегливо попрацювати над першим кроком, перш ніж переходити до наступних кроків.

На малюнку нижче пояснюється 8-ступінчаста модель Коттера:

8-ступінчаста модель зміни Коттера

Він окреслив модель зміни 8 кроків, щоб продемонструвати, що зміни не є простим і швидким процесом. Щоб змінити бізнес, нам слід бути обережними, оскільки це величезні інвестиції та великі витрати.

Процес управління змінами

Кожна сфера бізнесу має певні інструменти та програми для CM. Ми представимо тут приклад, який допоможе нам з’ясувати, як CM працює над ІТ-інфраструктурою, розробкою програмного забезпечення та координацією проектів.

Для управління проектами

Управління змінами відіграє важливу роль у діяльності, що виконується для управління проектами. Особа, яка керує проектом, повинна ретельно аналізувати запити на зміни та визначати ефект, який створюється зміною для проекту.

Областями проекту, на які може вплинути зміна, є:

  • Обсяг проекту: Як запит на зміну вплине на обсяг проекту?
  • Графік проекту: Як запити на зміни внесуть зміни до графіка?
  • Вартість проекту: Як запит на зміну змінить вартість проекту?
  • Якість : Як запит на зміну вплине на якість кінцевого проекту?
  • Людські ресурси : Визначте, чи потрібні додаткові або спеціалізовані людські ресурси.
  • Зв'язок: Після затвердження запитів на внесення змін про це слід належним чином повідомити відповідні зацікавлені сторони.
  • Ризик : Визначте ризики, породжені запитами на зміни: логістичні, фінансові або ризики безпеки.
  • Закупівлі : Запит на зміну може вплинути на зусилля щодо закупівель матеріалів та контрактної праці.
  • Зацікавлені сторони : Запити на зміни можуть спричинити втрату зацікавленої сторони та можуть вплинути на підтримку зацікавлених сторін проекту.

Керівник проекту повинен задокументувати схвалені запити на зміни, а також відхилені запити на зміни.

Запитання щодо інтерв’ю у веб-службі в Java

Для розробки програмного забезпечення

Зміна - це запит на щось інше, ніж те, про що було погоджено на початку проекту, спринт, фаза (це залежить від договору клієнта).

Ми введемо тут новий термін: Змінити порядок. Порядок змін - це частина роботи, яку слід додати до або видалити з початкової сфери дії контракту.

Ми запитуємо, що це означає під зміною у розробці програмного забезпечення:

  • Зміна технічних характеристик, вимог бізнесу
  • Зміна вимог
  • Зміна дизайну програми
  • Зміна коду
  • Зміна тестування
  • Зміни можуть бути спричинені:
    • Клієнти
    • Користувачі
    • Команда проекту
    • Тестова група

Agile методологія надихає на зміни у вимогах, зміни в процесі розробки програмного забезпечення, а також зміни в інтерфейсі користувача (UI). Історії використовуються для відстеження запитів на зміну.

Після того, як клієнт, керівник проекту або інші зацікавлені сторони визнали, що порядок змін цінний, слід виконати такі грубі кроки:

  1. Виконайте аналіз впливу
  2. Створіть чіткий список того, що вплине на зміни для:
    • Графік проекту (його можна продовжити)
    • Ціноутворення (слід повідомляти зацікавленим сторонам)
    • Сфера дії (можна мати функції, які можна вилучити, щоб включити нову)

Залежно від типу проекту та галузі можна також здійснити додаткові кроки після затвердження замовлення на зміну.

Одним із ключових моментів у процесі замовлення змін є процес затвердження. Запит на зміну потрібно затвердити. Для цього процесу затвердження обов’язковим є введення запиту на зміну з детальною документацією.

Детальна документація повинна містити інформацію про ціну запиту на зміну, обсяг запиту на зміну, час, необхідний для вирішення запиту на зміну, та детальний аналіз впливу запиту на зміну на систему.

Зміни походять із різних джерел, включаючи замовників, кінцевих користувачів, команду проекту або тестову групу.

Зміни від споживачів та кінцевих споживачів, як правило, є зміною вимог. Зміни, що надходять від проектних команд, як правило, розробляють зміни. Зміни, що надходять від групи тестувань, можуть вимагати зміни коду. Про зміни слід повідомляти менеджеру програмного забезпечення (SPM). Слід використовувати форму запиту на зміну (CR).

Запит на зміну (CR) повинен містити щонайменше такі записи:

  1. Серійний номер, що використовується для унікальної ідентифікації запиту на зміну.
  2. Чіткий опис запиту на зміну.
  3. Дата підняття запиту на зміну.
  4. Зазвичай запит на зміну повинен бути переданий комусь для аналізу. Обов’язковим є наявність списку з деякими вхідними даними, пов’язаними з деталями розподілу. Цей список містить:
    • Дата розподілу
    • Дата Виконання
    • Особи, яким направлено запит на зміну для аналізу
  5. Запит на зміну повинен бути переданий комусь для затвердження. Отже, нам доведеться відстежувати вхідні дані щодо затвердження:
    • Дата виділення для затвердження
    • Дата Виконання
    • Особа, відповідальна за затвердження
  6. Запит на зміну також повинен бути призначений для вирішення. Тож нам доведеться відстежувати такі вхідні дані для роздільної здатності:
    • Дата виділення для вирішення
    • Дата Виконання
    • Відповідальна за резолюцію
  7. Запит на зміну також повинен бути призначений для експертної перевірки. S o нам доведеться відстежувати такі вхідні дані для експертної перевірки:
    • Дата розподілу для експертної перевірки.
    • Дата завершення експертної перевірки.
    • Особа, яка відповідає за експертну перевірку.
  8. Запит на зміну повинен бути призначений також для регресійного тестування. Тож нам доведеться відстежувати такі вхідні дані для регресійного тестування:
    • Дата призначення для регресійного тестування.
    • Дата завершення регресійного тестування.
    • Особа, яка відповідає за регресійне тестування.
  9. Запит на зміну повинен мати чіткий статус. Статус може мати одне значення з наступного набору (відкритий, закритий або на аналізі, затвердження, вирішення, експертна перевірка, регресійне тестування)
  10. Коли ми закриваємо запит на зміну, нам доведеться вказати дату закриття.

Для кращої організації, після отримання CR, це слід зареєструвати в інструменті.

Потім слід провести аналіз, щоб зрозуміти, чи реалізація здійсненна чи ні, графік та зусилля, необхідні для реалізації, та вплив КР на графік проекту та вартість.

Про стан впровадження та прогрес у вирішенні CR повідомляється у Щотижневих звітах про стан відповідних керівників.

Для ІТ-інфраструктури

Інструменти управління змінами використовуються для відстеження змін, внесених в апаратну інфраструктуру ІТ-відділу. Кожне внесення змін до інфраструктури повинно оцінюватися, затверджуватися, документуватися, впроваджуватися та переглядатись систематично. Зміни, внесені до налаштувань обладнання, називаються управлінням конфігурацією (CM).

Труднощі в управлінні змінами

Існує багато труднощів в управлінні змінами, оскільки багато працівників не приймають змін. Важко змінитись, якщо ми не розуміли, що нам потрібно змінити своє мислення. Завдяки стратегічному підходу до змін прийняття нових процесів може бути простим. Для прийняття змін необхідно чітке спілкування.

Нижче наведено перелік викликів та труднощів:

  1. Конфлікти: Зміни можуть показати такі емоції, як розгубленість і занепокоєння. Конфлікт - типова ненавмисна реакція розгубленості та занепокоєння. Керівник повинен допомогти команді подолати труднощі. Конфлікти порушать наш графік. Це причина, з якої ми повинні вжити заходів для пом’якшення проблем.
  2. Планування: Зміни не матимуть змін до впровадження без правильного плану. Слід чітко пояснити переваги систематичної процедури.
  3. Відсутність зв'язку: Якщо спілкування буде невдалим, тоді спекуляції та чутки будуть частиною організації, а відсутність довіри ускладнить для працівників прийняття змін.
  4. Опір: Потрібно вирішити проблему опору, інакше це створить багато питань для зміни.

Переваги процесу управління змінами

Одним із ключових факторів СМ є те, що він забезпечує концептуальні риштування для людей, процесу та організації, що впроваджує зміни.

Переваги для Організації:

  • Зміни - це запланований та керований процес. Переваги змін відомі ще до впровадження та слугують мотивацією для всього процесу.
  • Організація може швидко реагувати на запити клієнтів.
  • Ресурси можна узгодити з цілями організації.
  • Ефективність праці співробітників зростає, коли вони відчувають підтримку та розуміють процес змін.
  • Зміни можуть бути здійснені без негативного впливу на повсякденний бізнес.
  • Дозволяє організації оцінювати загальний вплив змін.
  • Підвищується організаційна ефективність.
  • Підтримується організаційна ефективність.
  • Скорочення часу, необхідного для здійснення змін.
  • Можливість невдалої зміни зменшується.
  • Обслуговування клієнтів збільшується, а обслуговування клієнтів отримують впевнені та обізнані працівники.
  • Збільшена рентабельність інвестицій (ROI)
  • Допомагає спланувати корисні стратегії спілкування

Переваги для працівників:

  • У випадку, якщо зміною вдається добре керувати, це може мінімізувати опір змінам.
  • Ефективне управління змінами підтримує швидкий перехід від старого до нового і може підтримувати продуктивність.
  • Надає співробітникам підтримку щодо занепокоєння щодо змін.
  • Ефективний процес СМ створює правильне розуміння змін для персоналу та громадськості.
  • Допомагає спланувати ефективні комунікативні стратегії.
  • Покращує якість роботи.
  • Покращує співпрацю та спілкування.

Часті запитання

Q # 1) Що таке управління змінами?

Відповідь: СМ - це сукупність інструментів, процесів та методів, що використовуються для допомоги особам у переході з існуючого стану в організації в новий.

Є кілька важливих аспектів:

  • Управління конфігурацією: управління кодом та вимогами.
  • Впровадження організаційних змін.
  • Відстеження будь-яких змін, що відбуваються в ІТ-інфраструктурі - Управління ІТ-послугами (ITSM).

Q # 2) Що таке процес управління змінами програмного забезпечення?

Відповідь: Управління змінами програмного забезпечення - це процес класифікації змін відповідно до критеріїв проекту, таких як графік та вартість.

Запитання №3) Яка різниця між контролем змін та управлінням змінами?

Відповідь: СМ - це форма розуміння, пристосування та адаптації до нового нормального стану після перетворення організації. Контроль змін - це процес того, як зміни вимог зберігаються, аналізуються, управляються та включаються в дорожню карту та графік реалізації.

Q # 4) Які 3 види змін?

Відповідь: Подальші види змін включають зміни у розвитку, перехідні зміни та трансформаційні зміни.

Висновок

Управління змінами може збільшити успіх організацій та проектів, застосовуючи структуровані інструменти, застосовуючи кілька методів та розробляючи чіткі процеси. Вище керівництво повинно планувати реалізацію змін таким чином, щоб працівники відчували, що ці зміни принесуть для них певні позитивні результати.

Існують різні моделі управління змінами. При плануванні ці моделі слід враховувати.

Одним із ключових моментів у КМ є залучення людей до процесу змін. Зміни в організації неможливо досягти без підтримки працівників та керівництва. Правильний план КМ допомагає забезпечити, щоб процес змін розпочався та керувався потрібними людьми в потрібний час.

Рекомендована література

^