변화 관리 계획: 저항이 시작되기 전에 해결하십시오

ERP 프로젝트의 변화 관리 계획은 사람들이 지금의 업무 방식에서 새 시스템이 요구하는 업무 방식으로 어떻게 넘어갈지, 그리고 그 과정을 누가 책임질지를 정리한 문서입니다. 교육이 아니라 착수 단계에서 시작합니다. 구성 요소는 일곱 가지이고 각각 담당자가 정해져 있으며, 별도 흐름으로 따로 돌리지 않고 프로젝트 헌장, 설계 워크숍, 품질 게이트에 연결해 운영합니다.

대부분의 저항은 갑자기 생기지 않습니다. 킥오프 훨씬 전부터 서서히 쌓입니다. 초기 회의에서 돌려 말하는 발언으로 드러납니다. 핵심 현업 리드들이 말수가 줄어드는 것도 눈에 띕니다. 공식적인 변화 계획서를 작성할 즈음에는 이미 피해가 상당 부분 발생한 뒤입니다.

대개 몇 군데 뻔한 곳에서 시작됩니다.

1. 핵심 사용자가 초기 설계에서 빠진 경우.
2. 부서장이 아무도 논의해 주지 않은 영향에 놀라는 경우.
3. 모호한 커뮤니케이션이 이런저런 추측을 부르는 경우.
4. 과거에 실패한 프로젝트가 남긴 조용한 불신.

이것은 커뮤니케이션만의 문제가 아니라 구조적인 문제입니다. 운영위원회가 수동적이면 마찰이 생기리라 예상하십시오. 프로젝트 헌장에 정착에 관한 내용이 없다면 이미 수단 하나를 잃은 것입니다.

1. 01착수영향력을 파악하고 비공식 이력을 수집
2. 02설계정착 KPI에 합의, 파워 유저가 공동 작성
3. 03테스트현업 사용자가 자기 프로세스를 직접 테스트
4. 04교육역할별로, 실제 데이터로, 참석할 수 있는 시간에
5. 05Go-Live 게이트기능 승인뿐 아니라 정착 기준치 확인
6. 06첫 90일로그인, 오류, 티켓, 우회 방식을 추적

우회 방식이 습관이 되기 전에 포착

변화 계획은 커뮤니케이션 일정표가 아닙니다. 일곱 가지 구성 요소와 각각을 맡아야 할 담당자는 다음과 같습니다.

구성 요소	목적	담당
역할 및 영향력 매핑	직함이 아니라 영향력을 기준으로, 영향을 받는 모든 사람	변화 리드
변화 영향 평가	각 그룹의 역할, 프로세스, 도구가 어떻게 바뀌는지	프로세스 오너와 변화 팀
커뮤니케이션 계획	대상, 메시지, 채널, 시기, 그리고 피드백 루프	커뮤니케이션 리드
교육 및 역량 지원	역할별 커리큘럼, 실습, 준비도 점검	교육 매니저
리더십 참여	방향이 맞고 충분히 공유받았으며 변화를 공개적으로 지지하는 리더	경영진 스폰서와 변화 리드
정착 KPI	설계 단계에서 합의하고 Go-Live 이후까지 추적하는 행동 지표	변화 리드
저항 모니터링	팀별로 매핑한 조기 경고 신호	모든 워크스트림 리드

대부분의 변화 계획에서 커뮤니케이션이란 뉴스레터, 이메일, 타운홀을 뜻합니다. 사람을 움직이는 것은 그런 것들이 아닙니다.

제가 겪은 한 롤아웃이 기억납니다. 모든 것을 제때 공지했지만, 프로세스가 왜 바뀌는지 설명할 수 있는 사람은 아무도 없었습니다. 양은 있었지만 명확성은 없었습니다.

대상별로 맞추십시오. 고위 경영진은 비즈니스 영향을 먼저 듣고 싶어 합니다. 현업 사용자는 만난 적 없는 프로젝트 리드가 아니라 자기 매니저에게서 들어야 합니다. 기능 리드는 메시지의 일부를 직접 맡을 때 더 잘 반응합니다.

피드백을 설계에 넣으십시오. 일방향 커뮤니케이션은 계획의 절반입니다. 저는 매주 여는 Q&A 콜이 어떤 이메일보다 효과가 컸던 팀과 일한 적이 있습니다. 들은 내용을 리스크 레지스터와 연결하면, 약한 고리가 공개적으로 터지기 전에 드러납니다.

타이밍을 맞추십시오. 너무 이르면 혼란이 생기고, 너무 늦으면 억지처럼 느껴집니다. 한 롤아웃에서는 사용자들이 자기 일자리가 대체된다고 생각했습니다. 그렇게 말한 사람은 아무도 없었습니다. 하지만 침묵이 빈틈을 메웠습니다. 두려움은 다른 누군가가 대신 이야기하기 전에, 직접 그리고 일찍 다루십시오.

지난 프로젝트의 인물 지도를 재활용하지 마십시오. 영향력은 프로젝트마다 달라집니다. 지도는 처음부터 새로 만들고 매달 갱신하십시오.

사람마다 세 가지를 추적하십시오. 변화가 그 사람에게 얼마나 영향을 주는지, 지금 어느 입장에 서 있는지(지지, 중립, 저항), 다른 사람들에게 얼마나 영향력이 있는지입니다. 따르는 팀이 있는 저항하는 중간 관리자는 저항하는 개별 사용자보다 더 중요합니다.

비공식 이력도 수집하십시오. 과거에 실패한 프로젝트는 교훈 정리 문서에 절대 남지 않는 방식으로 사람들의 행동을 좌우합니다. 사람들이 기억하는 이야기를 몇 시간 들어 보면 실제로 무엇을 상대하고 있는지 알 수 있습니다. 매핑 방법은 제 이해관계자 관리 가이드에서 더 자세히 다룹니다.

교육은 변화 관리의 일부일 뿐, 전부가 아닙니다. 흔한 실패는 교육이 너무 늦게, 맞지 않는 형식으로 진행되고, 사람들이 자신감을 갖기 전에 끝나는 것입니다. Go-Live 2주 전의 하루짜리 과정은 준비 완료가 아닙니다.

효과가 있는 방법은 다음과 같습니다.

1. 역할별 콘텐츠. 시스템 투어가 아니라, 각 그룹이 자기 업무에 필요한 내용을 가르치십시오.
2. 실제 데이터로 실습. 데모 시나리오가 아니라 현업의 실제 데이터와 트랜잭션을 사용하십시오.
3. 파워 유저를 강사로. 사람들은 신뢰하는 동료에게서 더 잘 배웁니다. 파워 유저를 단순한 테스터가 아니라 설계의 공동 저자로 대하십시오.
4. 알맞은 시기의 교육. 제가 함께 일한 한 재무팀은 맞지 않는 시간에 잡힌 세션을 건너뛰었습니다. 시간을 옮기자 해결되었습니다.
5. Go-Live 이후 지원. 자신감은 Go-Live 이전이 아니라 이후에 떨어집니다. 하이퍼케어에는 실제 질문에 빠르게 답할 수 있는 사람을 배치하십시오.

사용자 인수 테스트(UAT)도 정착의 일부입니다. UAT 세션에서 가격 산정 로직의 작은 실수가 잘못된 청구서 발행으로 이어질 뻔했던 일이 기억납니다. 팀 리드 한 명이 그것을 잡아냈습니다. 다른 누구도 알아채지 못했습니다. 그 한 번의 발견으로 몇 주치 뒷정리를 아꼈고, 그것은 현업 사용자가 시스템을 어느 정도 자기 것이라고 느꼈기 때문에 가능했습니다.

정착 기준치를 품질 게이트에 넣으십시오. “시스템이 작동한다”는 기능 승인입니다. “사용자가 그 안에서 일할 준비가 되었다”는 전혀 다른 승인인데, 대부분의 프로젝트는 앞의 것만 묻습니다. 교육 계획은 SAP 교육 전략에 관한 제 가이드에서 더 깊이 다룹니다.

Go-Live 전에 합의해 둘 정착 KPI

설계 단계에서 정해 두면 측정할 기준선이 생깁니다.

1. 처음 90일 동안의 사용자 그룹별 로그인율.
2. 핵심 트랜잭션의 오류율을 레거시 기준선과 비교한 값.
3. 건수와 유형별 지원 티켓.
4. 우회 방식의 빈도: 스프레드시트로 내보내기, 병행 기록, 시스템 밖에서 이뤄지는 수동 승인.
5. 짧은 펄스 설문으로 파악한 매니저 보고 기준 자신감.

기회의 시간은 짧습니다. 사용자들이 몇 주 만에 슬그머니 스프레드시트로 돌아가는 모습을 본 적이 있습니다. 시스템이 고장 나서가 아니라, 변화를 거치는 동안 아무도 도와주지 않았기 때문입니다. Go-Live 몇 달 뒤면 우회 방식은 습관이 됩니다.

디지털 정착 도구

SAP는 2024년 9월 WalkMe 인수를 완료했으며, 지분 가치는 약 15억 달러였습니다. 당시 SAP는 WalkMe의 AI 기능이 업무 흐름 전반에서 Joule에 맥락을 인식하는 도움말을 더하게 될 것이라고 밝혔습니다. 즉 SAP는 이제 강점이 서로 다른 두 가지 정착 도구를 보유하고 있습니다.

• SAP Enable Now는 구조화된 교육 콘텐츠에 적합합니다. 프로세스를 한 번 녹화하면 그로부터 문서, 시뮬레이션, 테스트 스크립트를 만들어 낼 수 있습니다.
• WalkMe는 사용하는 순간에 애플리케이션 안에서 안내하는 데 적합하며, SAP와 비SAP 애플리케이션을 넘나들 수 있습니다.

두 도구를 함께 평가하십시오. SAP에 묶이지 않는 정착 도구를 원한다면 Whatfix가 주된 독립 대안입니다. 이 가운데 어떤 도구도 변화가 왜 중요한지 설명해 주는 매니저를 대신하지는 못합니다.

준비를 잘해도 새로운 마찰은 생깁니다. 지나치게 통제하려 하면 대개 역효과가 납니다. 목표는 그것을 일찍 보는 것입니다.

경고 신호는 불참한 워크숍, 회의 중의 침묵, 테스트에서의 모호한 피드백, 핵심 사용자가 만드는 비공식 우회 방식입니다. 신호마다 그것이 나온 팀과 연결해 매핑하십시오. 그러면 운영위원회에 닿기 전에 조치할 수 있습니다.

효과가 있는 방법 하나는 단계별로 변화 리드를 교체하는 것입니다. 2년짜리 프로젝트 내내 한 사람이 변화를 맡으면 대개 지치고 시야를 잃습니다. 저항의 성격이 바뀌는 만큼, 그것을 다루는 사람도 바뀌어야 합니다.

무엇보다 변화 관리를 프로젝트 구조 안에 두십시오. 행동 변화 성과는 프로젝트 헌장에 들어가야 합니다. 팀 과부하나 레거시에 대한 불신 같은 사람 관련 리스크는 기술 리스크 옆, 리스크 레지스터에 들어가야 합니다. 변화 관리가 일반적인 PMO 업데이트에 묻혀 보고되면, 형식적인 체크박스 절차가 됩니다.

변화 관리 계획에는 무엇이 들어가야 합니까?

일곱 가지입니다. 영향력 매핑, 변화 영향 평가, 피드백 루프를 갖춘 커뮤니케이션 계획, 역할별 교육, 리더십 참여, 정착 KPI, 저항 모니터링입니다. 각각 담당자가 지정되어야 하며, 계획은 헌장, 설계 워크숍, 품질 게이트와 연결되어야 합니다.

변화 관리의 5C는 무엇입니까?

여러 버전이 있습니다. 제가 쓰는 것은 명확성(Clarity, 자신에게 무엇이 바뀌는지 사람들이 압니다), 일관성(Consistency, 리더들이 같은 말을 합니다), 헌신(Commitment, 스폰서가 계속 눈에 보입니다), 커뮤니케이션(Communication, 관련성 있고 시의적절하며 쌍방향입니다), 역량(Capability, 교육, 지원, 적응할 시간)입니다. 하나라도 빠지면 사람들은 옛 습관으로 돌아갑니다.

변화 관리의 7R은 무엇입니까?

IT 서비스 관리에서 나온 것으로, 변경 요청을 실행에 옮기기 전에 평가하는 데 쓰입니다. 누가 요청했는지, 이유, 기대 수익, 리스크, 필요한 자원, 책임자, 그리고 다른 변경과의 관계입니다. 프로젝트의 사람 측면이 아니라 기술적 변경 통제에 적용됩니다.

조직 변화 관리와 기술적 변경 관리는 무엇이 다릅니까?

조직 변화 관리는 사람을 준비시킵니다. 업무 방식이 바뀌는 동안의 커뮤니케이션, 교육, 지원입니다. 기술적 변경 관리는 트랜스포트, 승인, 테스트, 롤백을 통해 SAP 시스템에 어떤 변경이 들어가는지 통제합니다. ERP 프로젝트는 대개 기술 쪽은 잘 관리합니다. 정착 실패는 조직 쪽에서 나옵니다. 기술 쪽은 SAP 기술적 변경 관리 도구에 관한 제 가이드에서 다룹니다.

WalkMe와 SAP Enable Now 중 무엇을 써야 합니까?

대개 둘 다입니다. SAP Enable Now는 Go-Live 전에 구조화된 교육 콘텐츠를 만드는 데 더 강합니다. WalkMe는 Go-Live 후 애플리케이션 안에서 안내하는 데 더 강하며, 특히 사용자가 SAP와 다른 애플리케이션을 오갈 때 그렇습니다. SAP가 둘 다 보유하고 있으므로 함께 평가하십시오. Whatfix가 주된 독립 대안입니다.

ERP 프로젝트에서 변화 관리는 언제 시작해야 합니까?

착수 단계에서, 첫 설계 워크숍 전에 시작합니다. 초기에 가장 중요한 조치는 영향력 매핑, 과거 프로젝트의 비공식 이력 수집, 행동 변화 성과를 헌장에 넣는 것, 그리고 스폰서의 커뮤니케이션 리듬을 정하는 것입니다.