change management tutorial what is change management
이 포괄적 인 변경 관리 가이드에서는 변경 관리 프로세스, 모델, 이점 및 7R에 대해 자세히 설명합니다.
CM (Change Management)은 개인이 조직의 기존 상태에서 새로운 상태로 전환하는 데 사용되는 도구, 프로세스 및 기술의 집합입니다.
CM은 다음과 같이 이해할 수 있습니다.
- 코드 및 요구 사항 관리를위한 구성 관리.
- 조직 변화를 구현합니다.
- IT 인프라에서 발생하는 모든 변경 추적 – ITSM (IT Service Management).
학습 내용 :
변경 관리 개요
CM의 목표는 조직의 목표, 프로세스 또는 기술 변경을 수행하고 변경 요청을 감독하며 직원이 제안 된 변경 사항을 수용하도록 지원하기위한 전략을 적용하는 것입니다.
이는 다음이 필수임을 의미합니다.
- 변화를 해결하기 위해 매우 잘 구성된 절차.
- 요청에 대한 응답을 준비하기 위해 잘 준비된 절차 세트입니다.
- 요청 구현에 대한 후속 조치를위한 메커니즘입니다.
변경 관리 프로세스를 시작하려면 조직은 모든 변경된 프로세스, 시스템이 조직 내에서 미칠 영향을 고려해야합니다.
다음 프로세스가 있어야합니다.
- 변경 계획
- 변경 사항 테스트
- 변경 사항 전달
- 변경 예약
- 변경 구현
- 변경 사항 문서화
- 결과 평가
프로세스를 유지하고 그러한 조치가 필요한 경우 롤백해야하므로 문서화는 CM의 중요한 측면입니다.
변경 관리 정의
다양한 관점에서 CM은 다음과 같이 정의 할 수 있습니다.
- 인프라 전문가의 관점에서 보면 승인, 테스트 및 새 장비 또는 새 릴리스 배치를위한 체계적인 접근 방식입니다.
- 프로젝트 관점에서 보면 프로젝트의 범위, 일정 또는 예산 변경에 대한 승인을 얻는 데 사용되는 프로세스입니다.
- 방법론에서 – PMP, Prince2, ITIL, ISO20000 관점, 승인을 얻고 프로젝트 또는 운영 환경에 대한 변경 사항을 구현하는 프로세스입니다.
- PROSCI, ACMP (Association of Change Management Professionals), IOCMI (Innovation and Organizational Change Management Institute) 관점에서, 조직이 각 단계에서 CM을 사용하도록 지원하는 프로세스입니다.
- 소프트웨어 개발 관점에서 보면 변경 요구 사항 및 코드를 추적하고 관리하는 프로세스입니다.
변경 관리 프로세스는 또한 IT 인프라에서 발생하는 모든 변경 사항을 추적 할 책임이 있습니다. ISO 20000은 변경 관리의 목표를 정의하는 표준입니다. 이를 올바르게 추적하고 처리하기 위해 일련의 표준화 된 방법 및 절차에서 변경된 모든 사항이 사용됩니다.
문서 변경 측면에서 이러한 변경에 사용되는 이름은 구성 관리이며 버전 제어를 올바르게 처리하려면 변경 관리 도구를 사용해야합니다.
CM 도구는 다음 작업을 수행합니다.
- 수행 된 모든 변경 사항을 추적합니다.
- 필요한 경우 수행 된 변경 사항에 대한 근거를 제공하십시오.
- 동일한 제품의 다른 버전을 동시에 개발할 수있는 가능성을 위해 여러 경로를 사용할 수 있는지 확인하십시오.
- 코드 수정 또는 코드 개선이 결함, 빌드 및 릴리스와 관련되어 있는지 확인합니다.
도입을 고려할 때 변경 관리라는 용어를 정의하려면 정의하려는 컨텍스트를 이해해야합니다.
조직 변경 유형
여러 유형의 조직 변화를 관리하는 데 사용되는 관리의 일부입니다. 가장 중요한 조직 변경 유형은 다음과 같습니다.
- 발달 변화 : 이는 이전에 확립 된 프로세스 및 절차의 개선을 다루는 조직 수준의 모든 변경을 의미합니다.
- 과도기적 변경 : 조직이 현재 상태를 변경하여 해결할 수있는 문제가 있다는 가정하에 조직을 기존 상태에서 완전히 새로운 상태로 이동시키는 것을 다루는 변경입니다.
- 변혁 적 변화 : 조직의 문화와 운영을 근본적으로 바꾸는 변화를 다루고 있습니다.
7R의 변경 관리
ITIL 'Business Perspectives Volume II'에는 변경 위험 변경을 결정하고 변경 관리 프로세스의 효과를 조사하는 단계를 설명하는 비즈니스 연속성 장에있는 7 개의 간단한 질문이있는 체크리스트가 포함되어 있습니다.
7 가지 질문이 아래에 설명되어 있습니다.
#1) '누가 변화를 일으켰습니까?'
변화의 원인으로 확인 된 많은 진입 점과 이해 관계자가 있습니다. 이는 모든 변경 사항을 수집하기위한 시스템을 갖추는 것이 필수라는 생각으로 이어집니다. 그러한 시스템은 목적이있는 영역에서 수정 핸드 오프를 처리하기 위해 수용 가능한 통제를 통합해야합니다.
# 2)“변경 이유는 무엇입니까?”
우선, 비즈니스 이점없이 변화가 위험을 초래할 수 있는지 이해해야합니다. 모든 주요 변경 사항은 합의 된 포트폴리오 분석 기준에 따라 분석되어야합니다.
C ++ 유형의 함수
# 3)“변경 후 어떤 RETURN이 필요합니까?”
변경으로 인해 재정적 보상이 발생하는지 이해하는 것이 필수적입니다.
# 4) '변경에 관련된 위험은 무엇입니까?'
위험은 허용 될 수있는 위험 또는 완화되어야하는 위험으로 분류됩니다. 관련된 위험을 정의하는 중요한 단계는 현재 인프라에 대한 변화의 영향을 분석하는 것입니다. ITIL은 잠재적 인 위험과 실제 문제에 대해 '심각도'개념을 사용하고 있습니다.
# 5)“변경 사항을 전달하려면 어떤 리소스가 필요합니까?”
리소스를 논의 할 때 우리는 변화를 구현하는 데 필요한 사람과 IT 자산을 생각하고 있습니다. 사람들의 관점에서 우리는 변화를 구현하는 데 필요한 기술이 무엇인지 이해해야합니다. 필요한 기술을 이해 한 후에는 해당 기술을 사용할 수 있는지 확인해야합니다.
# 6) '변경의 '구축, 테스트 및 구현'부분에 대한 책임은 누구에게 있습니까?'
애플리케이션 변경을 빌드, 테스트 및 구현하는 책임은 규정 준수 및 감사 요구 사항에 따라 구분되어야합니다. 책임 분리는 전체 변경 및 릴리스 관리 프로세스에서 추적 가능하고 실행 가능하며 실행 가능해야합니다.
# 7) '이 변경 사항과 다른 변경 사항 간의 관계는 무엇입니까?'
변경 관계에 대한 분석은 기능적 경계 내에서 수행되어야합니다. 계획된 변경의 일정을 공유해야하며 이러한 방식으로 변경 영향 분석 및 관계 매핑이 통합 CMDB (구성 관리 데이터베이스)의 일부가 될 수 있습니다.
이 7 가지 질문에 답하면 몇 가지 중요한 이점이 있습니다.
- 조직은 변경 위험을 측정하는보다 객관적인 수단을 제공하는 일련의 메트릭을 사용해야하므로 서비스가보다 안정적이고 고객에게 제공됩니다.
- 변경 관리 프로세스가 기존 프로세스를 얼마나 잘 준수하는지 이해하고 새로운 기술에서이를 식별 할 수 있습니다.
- 감사 가능한 변경 관리 프로세스는 IT 서비스에 대한 비즈니스와 새로운 요구 사항간에 의존성이 있기 때문에 필수적입니다.
변경 관리를위한 모델
변경 관리 모델의 목적은 관리자가 제안 된 변경 범위를 기존 도구와 일치시킬 수 있도록 안내 원칙을 제공하는 것입니다.
# 1) ADKAR (프로시)
ADKAR 모델은 순차적 인 목표 지향적 변경 관리 모델입니다. Prosci의 설립자 인 Jeff Hiatt가 만들었습니다.
(영상 출처 )
인식과 원하는 목적은 변화가 필요하지만 변화의 과정이 아직 시작되지 않았다는 것을 깨닫고있는 현재 상태를 바꾸는 것입니다.
전환 단계에서 지식과 능력이 나타납니다. 그리고 미래에는 강화가 나타날 것입니다.
목표 1 : 인식
때로는 조직에서 변화가 불가피하며 사람들을 안락한 영역에서 벗어날 수 있습니다. 변화의 이유를 미리 설명해 주시면 직원들은 그 변화를 받아들이고 준비 할 충분한 시간을 갖게 될 것입니다.
목표 2 : 욕망
직원들이 변화의 필요성과 그에 따른 혜택을 이해한다면, 우리는 변화 실행에 참여하려는 열정과 열망을 보게 될 것입니다.
변화에 대한 직원의 감정을 이해하지 못하고 그들의 두려움을 제대로 해결하지 못하고 변화가 개인적으로 어떤 혜택을 받는지 보여주지 않으면, 그들은 변화를 전적으로 지원하지 않고 변화 구현에 참여하고 싶은 마음도 갖지 못할 것입니다.
목표 3 : 지식
새로운 절차를 구현하려면 팀을 교육하고 변경 사항을 구현하는 방법을 이해할 수 있도록 모범 사례를 제공해야합니다.
목표 4 : 능력
지식을 능력으로 바꾸려면 연습이 필요합니다. 결과를 분석하고 조정하기 위해 시뮬레이션을하는 것이 좋습니다. 우리는 직원이 변경 사항을 구현하기 시작할 때 모니터링해야하며 건설적인 피드백을 기반으로 프로세스를 개선 할 수 있습니다.
목표 5 : 강화
이 목표의이면에있는 아이디어는 직원들이 시간이 지남에 따라 변화를 계속 따르도록 권장해야한다는 것입니다.
# 2) 브리지 전환 모델
Bridges Transition Model은 William Bridges가 개발했습니다. 사람 중심의 모델입니다. 주요 목적은 변화에 대한 사람들의 경험 전환을 관리하는 것입니다. 이 모델의 강점은 변화가 아니라 전환에 초점을 맞추고 있다는 것입니다.
Bridges의 아이디어는 사람들이 자신의 속도로 무대를 따라갈 것이라는 것입니다. 이 모델은 전환의 3 단계를 식별합니다.
- 1 단계 : 결말, 패배, 놓아주기
직원이 변경 사항을 처음으로 발표하면이 전환의 초기 단계에 들어갑니다. 그들은 자신이 준수 할 수없는 일을하도록 강요 받기 때문에 저항 할 것입니다. 직원들은 새로운 아이디어를 받아들이 기 전에 무언가 끝나고 있음을 이해하고 받아 들여야합니다.
- 2 단계 : 불확실성 또는 중립 영역
이 단계는 이전 상태와 새 상태를 연결하는 다리와 같습니다. 직원들은 여전히 낡은 것에 집착하고 있지만 새로운 주에 적응하려고 노력하고 있습니다. 직원들이 새로운 업무 방식을 시도하도록 장려하기에 완벽한 순간입니다. 피드백은이 단계에서 정말 중요합니다.
- 3 단계 : 수용 또는 새로운 시작
이것은 직원들이 변화 이니셔티브를 받아들이 기 시작할 때입니다. 직원들은 새로운 절차에 필요한 기술을 구축하고 있습니다.
# 3) ITIL (IT 인프라 라이브러리)
이는 IT 인프라 및 IT 운영의 변경 사항을 관리하기위한 세부 지침이 포함 된 프레임 워크입니다.
ITIL 4는 2019 년에 출시되었으며 프로세스 자동화, 서비스 관리 개선, IT 부서를 비즈니스에 통합하는 데 중점을 둔 주요 핵심 포인트가 있습니다.
ITIL 4는 9 가지 기본 원칙을 포함하며 아래 그림에 나와 있습니다.
최고의 휴대폰 스파이 앱
(영상 출처 )
조직에서 ITIL을 구현하기 전에 다음과 관련된 몇 가지 질문, 조직에서 해결하려는 문제, 지속적인 서비스 개선을위한 경로가 무엇인지에 대해 반드시 응답해야합니다.
# 4) Kotter의 8 단계 변경 모델
John Kotter는 변화 과정에있는 100 개 조직의 연구를 기반으로 개발 한 8 단계 변화 모델을 소개했습니다.
Kotter는 다음 단계로 넘어 가기 전에 1 단계에서 열심히 노력해야한다고 제안합니다.
아래 그림은 Kotter의 8 단계 모델을 설명했습니다.
그는 변경이 간단하고 빠른 프로세스가 아님을 보여주기 위해 8 단계 변경 모델을 설명했습니다. 비즈니스 변경을 수행하려면 막대한 투자와 막대한 비용이 소요되므로주의해야합니다.
변경 관리 프로세스
각 사업 영역에는 CM을위한 몇 가지 특정 도구와 응용 프로그램이 있습니다. 여기에서는 CM이 IT 인프라, 소프트웨어 개발 및 프로젝트 조정을 위해 어떻게 작동하는지 파악하는 데 도움이되는 몇 가지 예를 제시합니다.
프로젝트 관리 용
변경 관리는 프로젝트 관리를 위해 수행되는 활동에서 중요한 역할을합니다. 프로젝트를 관리하는 사람은 변경 요청을주의 깊게 분석하고 변경으로 인해 프로젝트에 미치는 영향을 결정해야합니다.
변경의 영향을받을 수있는 프로젝트 영역은 다음과 같습니다.
- 프로젝트의 범위 : 변경 요청이 프로젝트 범위에 어떤 영향을 미칩니 까?
- 프로젝트 일정 : 변경 요청이 일정을 어떻게 수정합니까?
- 프로젝트 비용 : 변경 요청이 프로젝트 비용을 어떻게 수정합니까?
- 품질 : 변경 요청이 최종 프로젝트의 품질에 어떤 영향을 미칩니 까?
- 인적 자원 : 추가 또는 전문 인력이 필요한지 결정합니다.
- 연락: 변경 요청을 승인 한 후 적절한시기에 적절한 이해 관계자에게이를 전달해야합니다.
- 위험 : 변경 요청으로 인해 생성되는 위험 (물류, 재무 또는 보안 위험)을 결정합니다.
- 획득 : 변경 요청은 자재 및 계약 인력에 대한 조달 노력에 영향을 미칠 수 있습니다.
- 이해 관계자 : 변경 요청은 이해 관계자의 손실을 초래할 수 있으며 이해 관계자의 프로젝트 지원에 영향을 미칠 수 있습니다.
프로젝트 관리자는 승인 된 변경 요청과 거부 된 변경 요청을 문서화해야합니다.
소프트웨어 개발 용
변경은 프로젝트 시작, 스프린트, 단계 (고객 계약에 따라 다름)에서 합의 된 것과 다른 요청입니다.
여기서 새로운 용어를 소개합니다. 주문 변경. 변경 지시는 계약의 원래 범위에서 추가하거나 삭제해야하는 작업입니다.
우리는 소프트웨어 개발의 변화가 무엇을 의미하는지 묻습니다.
- 사양, 비즈니스 요구 사항 변경
- 요구 사항 변경
- 응용 프로그램 디자인 변경
- 코드 변경
- 테스트 변경
- 변경의 원인은 다음과 같습니다.
- 고객
- 사용자
- 프로젝트 팀
- 테스트 팀
애자일 방법론은 요구 사항의 변경, 소프트웨어 개발 프로세스 동안의 변경 및 UI (사용자 인터페이스)의 변경을 유도합니다. 스토리는 변경 요청을 추적하는 데 사용됩니다.
클라이언트, 프로젝트 관리자 또는 기타 이해 관계자가 변경 순서가 중요하다고 결정한 후 다음과 같은 대략적인 단계를 수행해야합니다.
- 영향 분석 수행
- 다음에 대한 변경의 영향에 대한 명확한 목록을 작성하십시오.
-
- 프로젝트 타임 라인 (연장 될 수 있습니다)
- 가격 (이해 관계자에게 전달되어야 함)
- 범위 (새 기능을 포함하기 위해 제거 할 수있는 기능을 가질 수 있음)
프로젝트 유형 및 산업에 따라 변경 주문 승인 후 추가 단계를 수행 할 수도 있습니다.
변경 주문 프로세스의 핵심 포인트 중 하나는 승인 프로세스입니다. 변경 요청을 승인해야합니다. 이 승인 프로세스의 경우 세부 문서와 함께 변경 요청을 입력해야합니다.
자세한 문서에는 변경 요청 가격, 변경 요청 범위, 변경 요청을 해결하는 데 필요한 시간 및 변경 요청이 시스템에 미치는 세부 영향 분석에 대한 정보가 포함되어야합니다.
변경 사항은 고객, 최종 사용자, 프로젝트 팀 또는 테스트 팀을 포함한 다양한 소스에서 발생합니다.
고객 및 최종 사용자의 변경은 일반적으로 요구 사항의 변경입니다. 프로젝트 팀에서 발생하는 변경 사항은 일반적으로 변경 사항을 설계하는 것입니다. 테스트 팀의 변경 사항은 코드 변경을 요청할 수 있습니다. 변경 사항은 SPM (Software Project Manager)에 전달해야합니다. 변경 요청 (CR) 양식을 사용해야합니다.
변경 요청 (CR)에는 최소한 다음 항목이 포함되어야합니다.
- 변경 요청 고유 식별에 사용되는 일련 번호입니다.
- 변경 요청에 대한 명확한 설명.
- 변경 요청이 발생한 날짜입니다.
- 일반적으로 변경 요청은 분석을 위해 누군가에게 할당되어야합니다. 할당 세부 사항과 관련된 일부 입력 목록이 있어야합니다. 이 목록에는 다음이 포함됩니다.
- 할당 날짜
- 완료 날짜
- 분석을 위해 변경 요청이 할당 된 사람
- 승인을 위해 누군가에게 변경 요청을 할당해야합니다. 따라서 승인 입력을 추적해야합니다.
- 승인 할당 일
- 완료 날짜
- 승인 담당자
- 해결을 위해 변경 요청도 할당해야합니다. 따라서 해결을 위해 다음 입력을 추적해야합니다.
- 해결 할당 일
- 완료 날짜
- 해결 책임자
- 동료 검토를 위해 변경 요청도 할당해야합니다. 에스 o 우리는 피어 리뷰를 위해 다음 입력을 추적해야합니다.
- 피어 리뷰 할당 날짜.
- 피어 리뷰 완료 날짜입니다.
- 피어 리뷰를 담당하는 사람입니다.
- 회귀 테스트에도 변경 요청을 할당해야합니다. 따라서 회귀 테스트를 위해 다음 입력을 추적해야합니다.
- 회귀 테스트 할당 날짜입니다.
- 회귀 테스트 완료 날짜입니다.
- 회귀 테스트를 담당하는 사람입니다.
- 변경 요청은 명확한 상태 여야합니다. 상태는 다음 집합에서 하나의 값을 가질 수 있습니다 (공개, 종료 또는 분석 중, 승인, 해결, 피어 검토, 회귀 테스트).
- 변경 요청을 마감 할 때 마감 날짜를 언급해야합니다.
더 나은 조직을 위해 CR을받은 후 도구에 등록해야합니다.
그런 다음 구현이 가능한지 여부, 구현에 필요한 일정 및 노력, 프로젝트 일정 및 비용에 대한 CR의 영향을 이해하기 위해 분석을 수행해야합니다.
이행 현황, CR 해결의 진행 상황은 주간 현황 보고서를 통해 관계 임원에게보고하고 있습니다.
IT 인프라 용
변경 관리 도구는 IT 부서의 하드웨어 인프라에 대한 변경 사항을 추적하는 데 사용됩니다. 인프라에 대한 모든 변경 사항은 체계적으로 평가, 승인, 문서화, 구현 및 검토되어야합니다. 하드웨어 설정에 대한 변경 사항을 구성 관리 (CM)라고합니다.
변경 관리의 어려움
많은 직원이 변경 사항을 받아들이지 않아 변경 관리에 많은 어려움이 있습니다. 우리가 생각을 바꿔야한다는 것을 이해하지 못하면 바꾸기가 어렵습니다. 변화에 대한 전략적 접근 방식을 사용하면 새로운 프로세스를 쉽게 채택 할 수 있습니다. 변경 사항을 적용하려면 명확한 의사 소통이 필요합니다.
다음은 도전과 어려움의 목록입니다.
- 충돌 : 변화는 혼란과 걱정과 같은 감정을 나타낼 수 있습니다. 갈등은 혼란과 우려의 전형적인 의도하지 않은 반응입니다. 리더는 팀이 어려움을 극복하도록 도와야합니다. 갈등은 우리의 일정을 방해 할 것입니다. 이것이 우리가 문제를 완화하기 위해 조치를 취해야하는 이유입니다.
- 계획: 변경 사항은 올바른 계획없이 구현에 변경 사항이 없습니다. 체계적인 절차의 이점을 명확하게 설명해야합니다.
- 의사 소통의 부족: 의사 소통이 좋지 않으면 추측과 소문이 조직의 일부가 될 것이며 신뢰가 부족하면 직원이 변화를 수용하기가 어려워집니다.
- 저항: 저항은 해결되어야합니다. 그렇지 않으면 변화해야 할 많은 문제가 발생할 것입니다.
변경 관리 프로세스 이점
CM의 핵심 요소 중 하나는 변경을 구현하는 사람, 프로세스 및 조직에 대한 개념적 발판을 제공한다는 것입니다.
혜택 조직 :
- 변경은 계획되고 관리되는 프로세스입니다. 변경의 이점은 구현 전에 알려져 있으며 전체 프로세스의 동기로 작용합니다.
- 조직은 고객의 요구에 신속하게 대응할 수 있습니다.
- 리소스는 조직의 목표에 맞출 수 있습니다.
- 직원이 지원을 받고 변경 프로세스를 이해하면 성과가 향상됩니다.
- 일상적인 비즈니스에 부정적인 영향을주지 않고 변경을 구현할 수 있습니다.
- 조직이 변경의 전반적인 영향을 평가할 수 있도록합니다.
- 조직의 효율성이 향상됩니다.
- 조직 효율성이 유지됩니다.
- 변화를 구현하는 데 필요한 시간 단축.
- 실패한 변경 가능성이 줄어 듭니다.
- 고객 서비스가 증가하고 고객에 대한 서비스는 자신감 있고 지식이 풍부한 직원에게서 나옵니다.
- 투자 수익 (ROI) 증가
- 유용한 커뮤니케이션 전략을 계획하는 데 도움이됩니다.
직원 혜택 :
- 변화가 잘 관리된다면 변화에 대한 저항을 최소화 할 수 있습니다.
- 효과적인 변경 관리는 기존에서 새로운 것으로의 신속한 전환을 지원하고 생산성을 유지할 수 있습니다.
- 직원들에게 변경 사항에 대한 우려를 지원합니다.
- 효율적인 CM 프로세스는 직원과 대중을 위해 변경 사항에 대한 올바른 이해를 생성합니다.
- 효율적인 커뮤니케이션 전략을 계획하는 데 도움이됩니다.
- 작업의 질을 향상시킵니다.
- 협업 및 커뮤니케이션을 개선합니다.
자주 묻는 질문
Q # 1) 변경 관리 란 무엇입니까?
대답: CM은 개인이 조직의 기존 상태에서 새로운 상태로 전환하는 데 사용되는 도구, 프로세스 및 기술의 집합입니다.
휴대폰을위한 최고의 스파이웨어는 무엇입니까
몇 가지 중요한 측면이 있습니다.
- 구성 관리 : 코드 및 요구 사항 관리.
- 조직 변화를 구현합니다.
- IT 인프라에서 발생하는 모든 변경 추적 – ITSM (IT Service Management).
Q # 2) 소프트웨어 변경 관리 프로세스는 무엇입니까?
대답: 소프트웨어 변경 관리는 일정 및 비용과 같은 프로젝트 기준에 따라 변경 사항을 분류하는 프로세스입니다.
Q # 3) 변경 제어와 변경 관리의 차이점은 무엇입니까?
대답: CM은 조직 전환 후 새로운 정상 상태를 이해, 조정 및 적응하는 한 형태입니다. 변경 제어는 요구 사항의 변경 사항이 로드맵 및 구현 일정에 저장, 분석, 관리되고 포함되는 방식입니다.
Q # 4) 3 가지 변화는 무엇인가요?
대답: 이후의 변화에는 발달 적 변화, 과도기적 변화 및 변형 적 변화가 포함됩니다.
결론
변경 관리는 구조화 된 도구를 적용하고 여러 방법을 구현하며 명확한 프로세스를 설계함으로써 조직과 프로젝트의 성공을 높일 수 있습니다. 최고 경영진은 직원들이 변화가 그들에게 긍정적 인 결과를 가져다 줄 것이라고 느끼도록 변화를 구현할 계획을 세워야합니다.
변경 관리를위한 다양한 모델이 있습니다. 계획하는 동안 이러한 모델을 고려해야합니다.
CM의 핵심 포인트 중 하나는 변화 과정에 사람들을 참여시키는 것입니다. 직원과 경영진의 지원 없이는 조직의 변화를 이룰 수 없습니다. CM에 대한 올바른 계획은 적절한 사람이 적시에 변경 프로세스를 시작하고 관리하는 데 도움이됩니다.