변경 관리에는 조직에서 잘못 적용할 경우 일상적인 작업을 잠재적으로 중단할 수 있는 프로세스에 변경 사항을 적용하는 기술이 포함됩니다.
기술 다운타임의 80% 이상이 변경 후 발생할 수 있기에, 조직의 성공은 변경 관리의 성공과 변경을 얼마나 잘 관리하여 다운타임을 피할 수 있느냐에 달려 있습니다. 변경 관리가 적절하게 실행되면 구현 중에 엔터프라이즈가 프로세스를 거부하거나 프로세스가 실패할 위험을 줄일 수 있습니다.
기업은 조직적 관점에서 위에서 아래로 변경을 진행해야 한다고 생각하는 경향이 있습니다. 그러나 가장 광범위한 조직 변화도 한 번에 한 사람 단위로 이루어집니다. 새로운 접근 방식 채택은 각 직원이 스스로 결정해야 하는 개인적인 선택에 달려 있습니다. 엔터프라이즈 변경 관리를 사용하면 조직 전체에 변경을 더 쉽게 장려할 수 있으므로, 전사적인 채택을 가로막는 방해 요소와 실망스러운 경험을 방지할 수 있습니다.
기한을 놓치거나, 직원이 연장 근무를 하거나, 예산이 초과될 수 있습니다. 개인 수준에서 변경 관리가 적절하게 관리되지 않으면 조직의 상태와 동기 부여에 실질적인 영향을 미칠 수 있습니다.
성공적인 변경 관리가 프로젝트 목표를 달성할 가능성을 높인다는 사실이 데이터에 나타나고 있습니다.
변경 관리가 효과적으로 구현되면 변경 및 기타 시스템이 엔터프라이즈에서 거부될 위험이 감소합니다. 팀워크와 직원의 의욕이 높아지고, 생산성이 증대되며, 운영이 보다 효율적으로 작동할 수 있습니다.
사람은 예측 불가능합니다. 한 그룹에서는 잘 작용하는 변경 관리가 다른 그룹에서는 잘 작용하지 않을 수 있으며 메시징이 모든 사람에게 맞지는 않을 수 있습니다.
변경 관리는 대부분 쉽지 않습니다. 변화를 대하는 태도를 바꾸고 새로운 변화에 맞게 행동을 달리하려면 시간이 걸립니다. 변경 관리에는 다음과 같은 여러 어려움이 있을 수 있습니다.
사람은 예측 불가능합니다. 한 그룹에서는 잘 작용하는 변경 관리가 다른 그룹에서는 잘 작용하지 않을 수 있으며 메시징이 모든 사람에게 맞지는 않을 수 있습니다.
개인 사이의 상호작용이 필요합니다. 이메일과 대량 커뮤니케이션 방법을 사용하여 변화가 생길 때 메시지를 만들고 보강할 수 있지만, 개인적으로는 큰 울림이 없을 수도 있습니다. 많은 개인이 직접 듣고 이해하고 싶어 합니다. 이 때문에 개별 연락 옵션이 중요합니다.
프로그램의 효율은 중간급 직원 및 프론트라인 직원에게 달려 있습니다. 이들은 현재의 운영 및 프로세스 세부 사항을 알고 있으며, 발생 가능한 문제를 예측할 수 있습니다. 초기 단계에서 중간급 직원 및 프론트라인 직원과 함께 의논하고 의사 결정을 내려 동의를 얻는 데 도움이 되도록 해야 합니다.
문화는 국가마다, 지역마다, 심지어 도시마다 다를 수 있습니다. 변경 관리를 시행할 때는 문화적 차이를 고려하고 차이에 세심한 주의를 기울여야 합니다. 의사소통 방식, 시간관념, 평등주의를 고려하세요.
변경 관리를 위한 노력은 프로그램과 동시에 시작되어야 하며 프로젝트 팀과 그들의 IT 노동도 그때 같이 시작해야 합니다.
변경 관리를 위한 활동은 프로그램의 나머지 부분과 맞물려 이루어져야 합니다. 세부 사항이 확정되기도 전에 변경하기 시작하면 프로그램의 방향성과 달라질 수 있습니다. 변경 관리 팀은 가시적인 정보 없이 새로운 시스템을 모호하게 설명하기 시작할 수도 있으며, 이 때문에 직원이 변경을 꺼리고 혼란스러워할 수도 있습니다.
사람이라면 당연히 이성적이지 않을 때도 있기에, 감정까지 고려해야 합니다. 변경을 실행하는 사람들은 자신의 케이스를 논리적으로 전달해야 합니다. 하지만 개인이 조직에 소속감을 느낄 수 있게 호소할 줄도 알아야 합니다.
변경 관리는 대부분 쉽지 않습니다. 변화를 대하는 태도를 바꾸고 새로운 변화에 맞게 행동을 달리하려면 시간이 걸립니다. 변경 관리에는 다음과 같은 여러 어려움이 있을 수 있습니다.
사람은 예측 불가능합니다. 한 그룹에서는 잘 작용하는 변경 관리가 다른 그룹에서는 잘 작용하지 않을 수 있으며 메시징이 모든 사람에게 맞지는 않을 수 있습니다.
개인 사이의 상호작용이 필요합니다. 이메일과 대량 커뮤니케이션 방법을 사용하여 변화가 생길 때 메시지를 만들고 보강할 수 있지만, 개인적으로는 큰 울림이 없을 수도 있습니다. 많은 개인이 직접 듣고 이해하고 싶어 합니다. 이 때문에 개별 연락 옵션이 중요합니다.
프로그램의 효율은 중간급 직원 및 프론트라인 직원에게 달려 있습니다. 이들은 현재의 운영 및 프로세스 세부 사항을 알고 있으며, 발생 가능한 문제를 예측할 수 있습니다. 초기 단계에서 중간급 직원 및 프론트라인 직원과 함께 의논하고 의사 결정을 내려 동의를 얻는 데 도움이 되도록 해야 합니다.
문화는 국가마다, 지역마다, 심지어 도시마다 다를 수 있습니다. 변경 관리를 시행할 때는 문화적 차이를 고려하고 차이에 세심한 주의를 기울여야 합니다. 의사소통 방식, 시간관념, 평등주의를 고려하세요.
변경 관리를 위한 노력은 프로그램과 동시에 시작되어야 하며 프로젝트 팀과 그들의 IT 노동도 그때 같이 시작해야 합니다.
변경 관리를 위한 활동은 프로그램의 나머지 부분과 맞물려 이루어져야 합니다. 세부 사항이 확정되기도 전에 변경하기 시작하면 프로그램의 방향성과 달라질 수 있습니다. 변경 관리 팀은 가시적인 정보 없이 새로운 시스템을 모호하게 설명하기 시작할 수도 있으며, 이 때문에 직원이 변경을 꺼리고 혼란스러워할 수도 있습니다.
사람이라면 당연히 이성적이지 않을 때도 있기에, 감정까지 고려해야 합니다. 변경을 실행하는 사람들은 자신의 케이스를 논리적으로 전달해야 합니다. 하지만 개인이 조직에 소속감을 느낄 수 있게 호소할 줄도 알아야 합니다.
- 변경 정의.
- 변경 팀 선택.
- 지지 확인 및 약속받기.
- 구현 계획 발전.
- 단계적 변경 구현.
- 데이터 수집 및 분석.
- 격차 확인 및 저항 분석.
- 필요에 따른 계획 수정.
- 필요한 경우 구현 단계로 돌아가기.
문제는 인시던트로 이어질 수 있는 근본 원인입니다. 문제 관리는 문제의 영향을 최소화하고 문제가 인시던트로 커지는 상황을 방지하려고 하며, 통상 근본 원인을 식별하여 근본적인 문제를 파악합니다. 이러한 관리의 목표는 미래에 문제가 발생하거나 문제가 심화되지 않도록 하는 데 있습니다.
변경 관리는 인프라 또는 프로세스를 체계적으로 수정하는 작업으로, 일반적으로 여러 스테이지, 프로세스, 상태를 포함합니다. 변경 관리는 문제 관리의 결과로 발생할 수 있으나, 이 둘이 반드시 상관관계가 있지는 않습니다.
변경 이니셔티브 및 소프트웨어 배포를 처리하는 프로세스로, 릴리스를 실행하는 데 필요한 자원을 식별하고 할당합니다. 프로세스는 일반적으로 릴리스에 포함될 내용 계획, 새 릴리스를 빌드할 소프트웨어 관리, 테스트, 배포로 시작됩니다.
조직이 반복되는 인시던트를 방지하기 위해 발생하는 위험 요소를 식별, 분석 및 수정하는 프로세스입니다. 적절하게 관리되지 않은 인시던트는 운영, 작업, 보안에 지장이 될 수 있으며, 고객에게 부정적인 경험을 줄 수 있습니다.
ServiceNow의 변경 및 릴리스 관리는 변경 관리자가 변경 실행자로 탈바꿈하는 데 도움이 될 수 있습니다. 자동 상충 탐지 및 위험 평가를 사용하여 변경 실패를 최소화하고 변경당 비용을 절감할 수 있습니다. DevOps 변경 프로세스는 자동화된 변경 승인 및 거버넌스를 통해 활성화됩니다.
조직은 프로세스 효율성을 높이기 위해 위험도가 낮은 변경 승인을 자동화할 수 있습니다. 더 복잡한 변경은 CAB(변경심의위원회) 워크벤치를 단일 위치로 활용하여 CAB 회의를 자동으로 계획 및 예약하고, 효과적으로 실행할 수 있습니다.
내장 변경 성공 점수는 위험도가 낮은 변경을 자동으로 승인합니다.
자동화된 변경 프레임워크를 활용하여 DevOps와 비즈니스 관리 팀 간의 마찰을 줄입니다.
CAB 워크벤치를 사용하는 모든 계획된 변경의 감사 가능한 단일 리포지토리입니다.