저는 Novartis에서 AI 및 ERP 전환(Transformation)을 이끌어 왔으며, 벤더(Vendor)들이 절대 말해주지 않는 사실을 말씀드리고자 합니다. 기술은 거의 결코 가장 어려운 부분이 아닙니다. 대략 전환 프로그램의 70%가 목표 달성에 실패하며, 실패의 내부를 들여다보면 소프트웨어는 보통 제대로 작동하고 있었습니다. 그 주변의 사람들이 조용히 참여를 거부했을 뿐입니다.

이 수치는 너무 자주 인용되어 배경 소음처럼 들릴 정도입니다. 하지만 그래서는 안 됩니다. 그 이면에는 낭비된 예산, 상실된 신뢰성, 그리고 "변화"란 그저 자신들에게 "가해지는" 무언가라고 결론 내린 유능한 팀들이 있습니다. 좋은 소식은 실패 패턴은 예측 가능하다는 것이며, 이는 곧 해결 가능하다는 것을 의미합니다.

진짜 실패 지점은 플랫폼이 아니다

시스템 가동(Go-live)이 실망스러울 때, 사후 분석(Post-mortem)은 거의 항상 범위(Scope), 데이터 품질, 또는 통합(Integration)을 탓합니다. 그것들은 증상일 뿐입니다. 근본 원인은 채택(Adoption)을 처음부터 설계 제약 조건(Design constraint)으로 다룬 것이 아니라, 마지막 단계의 교육 이벤트로 취급했다는 점에 있습니다.

여기 불편한 수학적 사실이 있습니다. 도구가 기술적으로 완벽하더라도 사람들이 그것을 우회한다면 가치는 여전히 제로(Zero)일 수 있습니다. 저는 완벽한 모듈이 출시 6개월 후에도 **실제 사용률 30%**에 머물러 있는 동안, 기존의 스프레드시트가 조용히 비즈니스를 운영하는 것을 보았습니다. 시스템은 작동했습니다. 변화는 작동하지 않았습니다.

당신은 구매한 소프트웨어의 ROI(투자 대비 수익)를 얻는 것이 아닙니다. 사람들이 실제로 사용하는 소프트웨어의 ROI를 얻는 것입니다.

사람들이 참여를 거부하는 이유 — 그리고 그것은 합리적이다

사람들이 변화에 저항하는 이유는 게으르거나 기술을 두려워하기 때문인 경우가 드뭅니다. 그들이 저항하는 이유는, 그들의 입장에서 볼 때 변화가 나쁜 거래이기 때문입니다. 즉, 더 많은 리스크, 더 많은 감시, 그리고 개인적으로 얻을 수 있는 명확한 이점이 없는 것입니다.

빠져 있는 핵심 요소는 **심리적 안전감 (Psychological safety)**입니다. 즉, 무능해 보이지 않으면서도 "아직 이것을 이해하지 못했습니다"라거나 "이 새로운 프로세스는 잘못되었습니다"라고 인정할 수 있다는 믿음입니다. 그러한 안전감이 없을 때, 사람들은 혼란을 숨깁니다. 숨겨진 혼란은 조용한 우회책(Workarounds)이 됩니다. 조용한 우회책은 당신의 70% 통계치가 됩니다.

사람 중심의 해결책 (People-First Fix): 제가 실제로 사용하는 프레임워크

이것은 이론이 아닙니다. 제가 모든 프로그램에서 실행하는 일련의 과정이며, 단 한 페이지로 요약됩니다.

1. 인간의 관점에서 "from → to"를 정의하기

어떤 설정 (config)을 하기 전에, 저는 영향을 받는 각 역할(role)별로 한 문장씩 작성합니다. 즉, 그들의 오늘 일과가 어떠한지, 그리고 변화 후의 일과는 어떠할지를 적습니다. 만약 그 사람에게 돌아갈 구체적인 이득 (win)을 명확히 설명할 수 없다면, 그것은 아직 변화 (change)가 아니라 단순한 배포 (rollout)일 뿐입니다. 일정을 조정하기 전에 트레이드오프 (trade-off)부터 해결하십시오.

2. 챔피언이 아닌 회의론자를 포섭하기

모두가 열성적인 지지자들을 내세웁니다. 저는 반대로 합니다. 가장 목소리가 큰 회의론자를 설계 단계부터 일찍 참여시킵니다. 회의론자들은 해결 비용이 저렴할 때 실제 반대 의견들을 수면 위로 끌어올려 주며, 알려진 회의론자가 설득되었을 때 그들은 그 어떤 경영진의 메모보다 동료들을 더 잘 설득합니다.

3. "혼란 예산 (confusion budget)"으로 안전을 가시화하기

• 리더가 먼저 나섭니다: 저는 스폰서(sponsors)들에게 공개적으로 이렇게 말해달라고 요청합니다. "지난번에 제가 틀렸습니다. 그래서 이번에는 이렇게 바꿨습니다." 리더의 솔직한 인정 한 번은 수십 개의 설문조사보다 더 많은 솔직함을 이끌어냅니다.
• 침묵이 아닌 문제를 제기한 사람에게 보상하십시오: 잘못된 단계를 보고하는 사람은 무료로 품질 관리 (quality control)를 해주고 있는 것입니다. 그들의 이름을 불러 고마움을 표하십시오.
• "아직"을 정상화하십시오: "이것을 아직 어떻게 해야 할지 모르겠습니다"는 상태 업데이트이지, 실패가 아닙니다.

4. 가동 시간 (uptime)을 측정하듯 채택률 (adoption)을 측정하기

대부분의 프로그램은 가동 (go-live) 날짜와 예산을 추적합니다. 저는 첫 주부터 다음과 같은 소수의 선행 지표 (leading indicators)를 추적합니다: 활성 사용률 (active-usage rate), 우회 방법 (workaround) 사용 빈도, 그리고 역할별 숙련 시간 (time-to-competence). 사용량이 정체되면, 저는 분기 단위가 아니라 며칠 내로 이를 파악합니다. 측정하지 않는 것은 구조할 수 없습니다.

5. 피드백 루프를 공개적으로 닫기

누군가 문제를 제기하고 제가 이를 해결했을 때, 저는 해결 내용을 방송하듯 알리고 그 출처(제보자)에게 공을 돌립니다. 목소리를 내는 것이 시스템을 바꾼다는 증거만큼 채택 (adoption)을 가속화하는 것은 없습니다. 이는 수동적인 청중을 공동 소유자 (co-owners)로 변화시킵니다.

이런 방식으로 리드할 때 변하는 것들

플랫폼 (platform)보다 사람을 우선순위에 두었던 프로그램들에서 변화는 구체적이었습니다. 수개월 동안 정체되던 채택 곡선 (adoption curves)은 **몇 주 만에 실사용률 80%**를 돌파했고, 문제가 조기에 표면화되면서 지원 티켓 (support tickets)은 감소했으며, — 경영진이 가장 크게 체감하는 부분인데 — 비즈니스가 병행하여 운영하던 그림자 프로세스 (shadow process)가 중단되었습니다.

이 중 어느 것도 더 나은 소프트웨어를 필요로 하지 않았습니다. 이는 신뢰 (trust)를 인프라 (infrastructure)로 취급할 것을 요구했습니다. 즉, 기술 스택 (tech stack)과 정확히 마찬가지로 설계하고, 예산을 책정하며, 유지 관리해야 하는 대상으로 보는 것입니다.

리더를 위한 핵심 요약

만약 귀하의 다음 전환 (transformation)이 위기에 처해 있다면, 아키텍처 (architecture)를 감사하는 것부터 시작하지 마십시오. 팀원들에게 더 간단한 질문을 던지고 그 답변에 실제로 귀를 기울이는 것부터 시작하십시오: "무엇이 이것을 당신에게 진정으로 더 낫게 만들까요? 그리고 당신이 나에게 말하기 두려워하는 것은 무엇인가요?" 그 답변을 들을 수 있는 조직이 승리하는 30%에 속합니다.

그러므로 다음 시스템 가동 (go-live) 전에 스스로에게 물어보십시오: 당신은 기술을 설계했습니까, 아니면 신뢰를 설계했습니까?

원문은 cedricbignet.com에 게시되었습니다. 저는 Novartis의 AI & ERP 변화 관리 (Change Management) 전문가이자 AInspire의 설립자인 Cédric Bignet입니다.