SAP 이해관계자 관리: 갈등이 생기기 전에 막는 법

SAP 이해관계자 관리는 프로그램이 제때 끝나는지, 마지막 분기를 논쟁으로 보내는지를 가릅니다. 네 가지 습관으로 요약됩니다. 누가 중요하고 각 그룹이 무엇을 신경 쓰는지 매핑합니다. 누가 무엇을 결정할 권한이 있는지 문서로 남깁니다. SAP Activate 단계에 맞는 소통 주기를 운영합니다. 중요한 의사결정은 대안과 함께 모두 기록합니다. 이 가이드는 S/4HANA 프로그램을 맡은 프로그램 디렉터, PMO, 임원 스폰서를 위한 것입니다. 첫 워크숍 전에 아래의 역할 표와 단계별 소통 주기로 관여 계획을 세우십시오.

한번은 IT는 엄격한 시스템 통제를 원하고 재무팀은 더 많은 유연성이 필요했던 SAP 롤아웃에 참여한 적이 있습니다. 저희가 투입되었을 때 두 팀은 이미 대화를 멈춘 상태였습니다. 재무팀은 불만이 쌓여 있었고, IT는 방어적이었습니다. 경영진은 왜 아무도 소통하지 않느냐고 물었습니다.

저희는 역할 맵을 만들고, 정기적인 조율 회의를 열고, 의사결정을 위한 단일 정보원을 만들었습니다. 이 기반을 처음부터 깔아 두었다면 몇 달간의 논쟁을 아꼈을 것입니다.

이 패턴은 그 프로그램을 훨씬 넘어서도 통합니다. 기술이 혼자 실패하는 경우는 드뭅니다. 의사결정이 내려지지 않고 기대가 한 번도 맞춰지지 않을 때 프로그램은 실패합니다. 소통이 주기가 아니라 개인적 관계에 의존할 때, 그리고 실무 수준에서 풀렸어야 할 갈등이 몇 주나 늦게 경영진에게 올라갈 때도 실패합니다.

SAP 프로그램에 참여하는 모든 사람의 관심사와 영향력이 같지는 않습니다. 하나의 청중으로 취급하면 관련 없는 업데이트를 보내게 되고 진짜 리스크를 놓칩니다.

역할	신경 쓰는 것	관여 방법
임원 스폰서(CEO, COO, 그룹 CFO)	수익, 비즈니스 리스크, 프로그램의 신뢰성	직접, 정기적으로, 짧게
운영위원회(CIO, CFO, 사업부장)	일정, 예산, 범위	의사결정이 따르는 구조화된 운영위원회 리뷰
재무 리더십(CFO, 컨트롤러)	매출 인식, 보고의 무결성, 통제	초기 설계 참여, FI/CO 범위 승인
운영 및 현업 리더	프로세스 연속성, 교육, 사용성	설계 워크숍, 사용자 인수 테스트(UAT) 책임
IT 리더십(CIO, 아키텍처 총괄)	아키텍처, 보안, 통합, 지원	기술 설계 승인
업무 프로세스 오너	프로세스 정확성, 예외, 엣지 케이스	설계 워크숍 주도, 설정 승인
최종 사용자	학습 곡선, 일상 업무, 직무 변화	교육과 변경 관리
시스템 통합업체(SI)	딜리버리 범위, 변경 요청, 인력 투입	공식 거버넌스와 범위 문서
HR과 변경 관리	사람에 미치는 영향, 역할 변화, 소통	딜리버리와 병행하는 별도 워크스트림

영향력-관심도 매트릭스는 어디에 노력을 쏟을지 알려 줍니다. CIO, CFO, 스폰서는 두 축 모두에서 높습니다. 이들은 변경을 승인하고, Go-Live를 연기하고, 인력을 배정하며, 이들이 이탈하면 프로그램은 보호막을 잃습니다. 프로세스 오너, 컨트롤러, 아키텍트는 관심도가 높고 공식적인 권한은 적지만, 업무가 실제로 어떻게 돌아가는지에 대한 지식 때문에 설계에서 필수적입니다. 이사회 구성원과 프로그램 밖의 임원에게는 주간 업데이트가 아니라 마일스톤 브리핑이 필요합니다. 최종 사용자는 영향력이 작고 노출은 가장 큽니다. Go-Live 시점에 이들이 받아들이는지가 시스템이 현실에서 작동하는지를 정합니다.

결과에 대한 영향력높음중간낮음

• 이사회, 프로그램 밖 임원

• 스폰서, CFO, CIO

• 프로세스 오너
• 컨트롤러, 아키텍트

• 최종 사용자

낮음중간높음프로그램이 미치는 영향의 크기

가장 효과적인 관여는 아무도 불만을 제기하기 전에 이루어집니다. 킥오프에서 세 가지를 확정하십시오.

의사결정 권한

범위 변경은 누가 승인합니까? UAT는 누가 서명합니까? Go-Live 연기를 운영위원회에 올릴 수 있는 사람은 누구입니까? 문서로 남기고, 서명을 받고, 프로젝트 헌장에 넣으십시오. 프로젝트 중간에 의사결정이 다투어지면 그 문서가 근거가 됩니다.

문서가 없으면 다투어지는 의사결정은 목소리가 가장 큰 사람이나 스폰서의 귀를 잡은 사람에게 갑니다. 둘 다 거버넌스가 아니고 둘 다 불만을 키웁니다. SAP 프로젝트 헌장 작성법 가이드에서 의사결정 권한 섹션에 무엇이 들어가야 하는지 다룹니다.

소통 주기

킥오프에서 프로그램이 얼마나 자주, 어떤 채널로, 어떤 내용을 소통할지 정하십시오. 운영위원회는 격주로. 워크스트림 리드는 매주. 최종 사용자는 마일스톤마다, 교육 안내와 함께. 프로그램에서 소식이 올 때가 문제가 생겼을 때뿐이라면 사람들은 프로그램이 늘 곤경에 처해 있다고 생각할 것입니다.

범위 기준선

무엇이 범위에 포함되고 무엇이 명시적으로 제외되는지 적으십시오. 제외 항목은 포함 항목만큼 중요합니다. 정의되지 않은 경계는 모두 미래의 갈등이기 때문입니다. 경비 관리가 범위에 있다고 가정했다가 Realize 단계에서 그렇지 않다는 사실을 알게 된 재무 리드를 생각해 보십시오. 그 사람은 프로그램 내내 까다롭게 굴 것입니다. 원래 까다로운 사람이어서가 아니라, 프로그램이 암묵적인 약속을 깼기 때문입니다.

프로그램이 SAP Activate 단계를 거치면서 관여의 필요도 달라집니다. Explore에서 통하는 방법은 Deploy에서는 통하지 않습니다. 이것을 관여 계획의 뼈대로 쓰십시오.

단계	관여의 초점	주기	주도자
Discover and Prepare	역할 맵, 거버넌스 구조, 스폰서 브리핑, 재무, 운영, IT와의 첫 조율 세션	시작 시 스폰서 브리핑, 운영위원회 구성	프로그램 디렉터
Explore	현업 리더 및 프로세스 오너와의 Fit-to-Standard 워크숍, 승인 전 Fit-Gap 의사결정 검토	주간 실무 세션, 단계 종료 시 운영위원회	솔루션 아키텍트와 프로세스 오너
Realize	UAT 준비, 테스트를 위한 현업 리더의 시간 확보, 결함과 데이터 마이그레이션 현황	운영위원회 격주, 워크스트림 리드 주간	프로그램 매니저
Deploy	컷오버 준비 상태, 컷오버 시작 전에 합의한 Go/No-Go 기준	매일 컷오버 스탠드업, 임원 Go/No-Go 브리핑	IT와 SI가 지원하는 현업 운영 리드
Run	하이퍼케어 소통, 이슈 채널, 안정화 리뷰	2주간 매일, 이후 매주, 30일, 60일, 90일 시점에 리뷰	지원 리드와 프로세스 오너

두 단계에서 문제가 가장 많이 생깁니다. Explore에서는 엉뚱한 사람이 회의실에 있으면 설정이 시작된 뒤인 Realize에서 의사결정이 다시 열립니다. Realize에서는 UAT 오너가 시간을 낼 수 없거나 준비가 안 된 경우가 흔한 패턴입니다. 테스트가 시작되기 2주 전이 아니라 Explore 단계에서 계획으로 바로잡으십시오.

전통적인 모델에는 세 주체가 있었습니다. 고객, SI, 스폰서입니다. RISE with SAP에서는 SAP가 딜리버리 참여자로 합류합니다. 인프라와 기술 운영을 맡고, 고객 성공 팀이 도입과 가치를 추적합니다. 이에 따라 거버넌스가 세 가지 바뀝니다.

1. 확장 검토 포럼. 모든 갭에는 의사결정이 필요합니다. 설정으로 해결하거나, 공개된 API를 통해 확장하거나(ABAP Cloud를 사용하는 온스택, 또는 SAP BTP의 사이드 바이 사이드), 거부합니다. S/4HANA Cloud Public Edition에서는 코어 수정이 불가능합니다. Private Edition에서는 가능하지만 수정할 때마다 업그레이드 작업이 늘어납니다. 운영위원회 아래에 결정 권한이 있는 아키텍트 한 명을 둔 작은 포럼을 두면 모든 커스터마이징 논쟁이 운영위원회로 올라가는 일을 막을 수 있습니다. 이를 건너뛰면 기술 부채가 첫 대규모 업그레이드 때 드러납니다.
2. SAP와의 고객 성공 주기. SAP 팀은 도입, BTP 사용, 로드맵에 관여합니다. 구축 거버넌스와 병행해서 돌아가고 Go-Live 이후에도 이어집니다. 따로 운영하지 말고 거버넌스에 통합하십시오.
3. SAP로 이어지는 에스컬레이션 경로. 플랫폼 수준에서 장애가 나면 CIO는 파트너뿐 아니라 SAP의 누구에게 전화해야 하는지 알아야 합니다. 계약서에 서명하기 전에 연락처와 서비스 수준을 확인하십시오.

Public Edition의 GROW with SAP 프로그램에도 같은 세 가지가 필요하지만 무게는 가볍습니다. 확장할 여지가 적으니 확장 의사결정이 적고, 고객 성공 주기는 더 표준화되어 있으며, 에스컬레이션은 대개 파트너를 먼저 거칩니다. 온프레미스 프로그램은 SAP가 참여자가 아니라 벤더인 전통적인 모델을 유지합니다.

AI 도구는 관여에 따르는 서류 작업에는 도움이 되지만 관계에는 도움이 되지 않습니다.

회의 요약이 가장 분명한 이득입니다. Microsoft Copilot은 녹화된 운영위원회 회의를 회의록 초안으로 바꿔 주고, 긴 작성 작업 대신 짧은 검토만 하면 됩니다. 기억이 아니라 녹취록을 바탕으로 하기 때문에 포착한 의사결정은 대체로 맞습니다.

의사결정 로그가 두 번째입니다. 지금은 Atlassian의 Rovo 브랜드 아래 있는 Confluence의 AI 기능은 템플릿을 만들어 두면 회의 메모를 구조화된 의사결정 로그 항목으로 바꿔 줄 수 있습니다.

요구사항 초안 작성은 Explore에서 도움이 됩니다. SAP Cloud ALM은 Fit-to-Standard 워크숍 녹취록에서 요구사항 초안을 작성할 수 있습니다. 모든 줄을 사람이 검증해야 합니다.

감정 분석은 대부분 보여 주기용입니다. 100명 미만의 프로그램에서는 신호가 약하고, 오탐이 흔하고, 감정을 감시하는 모습으로 비치면 정치적 비용이 실제로 큽니다. 아주 큰 프로그램에서는 이탈하는 그룹을 일찍 포착할 수 있을지도 모릅니다. 대부분의 프로그램은 AI 예산을 다른 곳에 쓰십시오.

SAP에 대한 저항에는 거의 항상 합리적인 근거가 있습니다. 반대하는 사람은 대개 무언가를 지키려는 것입니다. 기존 시스템의 갭을 메우는 우회 방법, 표준 프로세스에는 드러나지 않는 수작업 점검, 또는 팀이 변화를 감당할 여력에 대한 걱정입니다. 반응하기 전에 그 근거를 찾으십시오. 근본적인 우려를 다루면 대개 대립 없이 저항이 사라집니다.

"이 커스터마이징이 필요합니다"

대개는 오늘 잘 돌아가는 프로세스를 지키려는 것이고, 표준 SAP가 그것을 처리해 줄 거라는 믿음이 없는 것입니다. 표준 프로세스를 함께 따라가 보며 정확히 어디서 안 되는지 물어보십시오. 우려가 설정으로 처리할 수 있는 엣지 케이스인 경우가 많습니다. 정당한 경우도 있습니다. 대화를 나눠 봐야만 알 수 있고, 클린 코어에서는 그 답이 확장을 만들고 유지할지를 정하므로 걸린 것이 더 큽니다.

"아직 Go-Live할 준비가 안 되었습니다"

이 말은 진지하게 받아들이십시오. 현업 리더가 준비가 안 되었다고 하면 대개 이유가 있습니다. 데이터 품질, 끝나지 않은 교육, 테스트하지 않은 프로세스입니다. 구체적인 우려를 찾으십시오. 타당하다면 Go-Live를 연기해야 합니다. 증거가 아니라 불안이라면, 새 날짜가 아니라 집중적인 준비로 답하십시오.

가장 흔한 형태는 UAT에서 드러난 문제가 아직 해결되지 않은 경우입니다. 밀어붙이면 문제가 UAT에서 운영으로 넘어갑니다. 2주 지연은 대개 Go-Live 전에 이미 알려진 이슈에 쓰는 하이퍼케어 기간보다 훨씬 적게 듭니다.

"이 변경에 대해 아무도 말해 주지 않았습니다"

소통의 실패입니다. 그 사람은 배포 목록에는 있었지만 설계 세션에는 없었거나, 변경 사항이 그가 읽지 않은 문서에 들어 있었습니다. 누가 무엇을 전달했는지 다투지 마십시오. 사과하고, 변경 사항을 함께 짚어 주고, 앞으로 그 영역의 설계 리뷰에 추가하고, 관여 계획의 공백을 고치십시오.

갈등이 실무 수준을 넘어서면 세 가지가 중요합니다.

거버넌스 안에서 다루십시오. 시스템 접근을 둘러싼 재무팀과 IT의 분쟁은 더 끈질긴 쪽이 비공식적으로 해결할 일이 아니라 운영위원회에서 다룰 일입니다. 구조적 갈등을 비공식적으로 해결하면 불만이 쌓이고 의사결정이 다시 열립니다.

비즈니스의 언어로 풀어 말하십시오. 재무팀과 IT가 접근 통제를 두고 다투는 것은 정치입니다. 재무팀과 IT가 보안 리스크와 운영 비용을 함께 제시하는 것은 비즈니스 의사결정이고, 운영위원회가 내릴 수 있습니다. 하나를 다른 하나로 옮기는 일은 계약에 따라 프로그램 매니저나 SI 리드의 몫입니다.

중요한 의사결정은 모두 기록하십시오. 무엇이, 누구에 의해, 언제 결정되었고 어떤 대안을 검토했는지입니다. 6개월 뒤 누군가 "우리는 그렇게 합의한 적이 없다"고 말할 것입니다. 운영위원회가 왜 그 설정을 선택했는지 묻거나 새로 온 사람이 과거의 결정에 의문을 제기할 때, 기억을 되살려 재구성하는 것이 아니라 기록이 있어야 합니다. 매주 업데이트하고 운영위원회에서 검토하는 공유 의사결정 로그는 비용이 거의 들지 않고 많은 것을 아낍니다.

프로그램 매니저의 받은편지함이 긴급 에스컬레이션으로 가득하다면 계획이 작동하지 않는 것입니다. 건강한 프로그램은 매일의 소방 활동이 아니라 구조화된 의사결정으로 돌아갑니다.

건강한 신호: 운영위원회 회의가 미루기가 아니라 의사결정을 만들어 냅니다. 현업 리더가 쫓아다니지 않아도 워크숍과 UAT에 참석합니다. 범위 변경이 변경 프로세스를 통해 들어옵니다. Go-Live 이후의 이슈가 정해진 채널로 들어옵니다. 의사결정 로그가 최신이고 운영위원회에서 참조됩니다.

경고 신호: 사람들이 거버넌스 구조 밖에서 프로그램 매니저에게 연락합니다. 현업 리더가 산출물을 읽지도 않고 승인했다가 나중에 이의를 제기합니다. 스폰서가 운영위원회 사이에 사라집니다. 설계에 빠졌던 사람들이 변경 동결에 이의를 제기합니다. 같은 갈등이 운영위원회 회의 세 번 연속으로 나옵니다.

경고 신호가 나타나면 기존 계획을 더 세게 밀어붙이지 마십시오. 어느 요소가 실패하고 있는지 찾으십시오. 주기, 권한, 소통, 문서화 중 하나입니다. 그리고 그것 하나를 고치십시오. 이메일과 회의를 늘리면 오히려 나빠집니다. 운영위원회 자체에 대해서는 효과적인 SAP 운영위원회 만들기 가이드를, Go-Live의 사람 쪽 문제에 대해서는 SAP 변경 관리 노트를 참고하십시오.

SAP 구축에서 이해관계자 관리란 무엇입니까?

프로그램에 영향력이나 관심이 있는 사람이 누구인지 파악하고, 그들의 우려를 이해하고, 소통과 의사결정 체계를 세우고, 킥오프부터 하이퍼케어까지 이들을 계속 관여시키는 체계적인 일입니다.

SAP는 재무, HR, 구매, 운영, IT에 동시에 영향을 미치고, 각각 우선순위와 영향력이 다릅니다. 이들을 하나의 청중으로 관리하면 일반적인 업데이트만 나가고 저항을 일으키는 우려를 놓칩니다. SAP Activate는 이를 모든 단계에 녹여 두었습니다. Explore의 워크숍, Realize의 UAT 책임, Deploy의 준비 상태 리뷰는 모두 준비된 현업 참여자에 달려 있습니다.

SAP 프로젝트에서 역할 맵은 어떻게 만듭니까?

각 사람이나 그룹을 두 축에 배치하십시오. 결과에 대한 영향력과 프로그램이 그들에게 미치는 영향의 크기입니다. 스폰서, CFO, CIO는 두 축 모두 높아서 직접적이고 정기적인 접촉이 필요합니다. 컨트롤러, 프로세스 오너, 아키텍트는 관심도가 높아서 설계에 참여해야 합니다. 프로그램 밖의 임원에게는 마일스톤 브리핑이 필요합니다. 최종 사용자에게는 무엇이 바뀌는지, 교육은 언제인지, 도움은 어디서 받는지에 대한 맞춤형 소통이 필요합니다.

맵은 최신으로 유지하십시오. 사람들의 역할이 바뀌고, 프로그램이 눈에 띄게 되면서 영향력이 이동하고, 범위가 커지면서 새 참여자가 들어옵니다.

SAP 관여 계획에는 무엇이 들어가야 합니까?

역할 대장(이름, 기능, 영향력, 관심도, 주요 우려), 소통 계획(그룹별 채널, 빈도, 내용), 범위 변경, 설계 의사결정, Go-Live 준비 상태에 대한 의사결정 권한, Activate 단계별 활동, 다투어지는 의사결정을 위한 에스컬레이션 경로, 그리고 우려를 공식적으로 제기할 방법입니다.

단계 게이트마다 업데이트하십시오. 프로그램 매니저가 모든 상호작용을 직접 처리하지 않아도 팀이 운영할 수 있을 만큼 문서화하십시오. 그 방식은 이름이 거론되는 참여자가 30명을 넘으면 확장되지 않기 때문입니다.

현업 리더의 SAP 저항은 어떻게 관리합니까?

먼저 원인을 찾으십시오. 흔한 것은 새 프로세스가 중요한 엣지 케이스를 놓칠 거라는 걱정, 생산성 손실에 대한 두려움, 의사결정에서 소외되었다는 느낌입니다. 프로세스 우려는 설계 세션에서 다룰 일입니다. 생산성 두려움에는 현실적인 교육과 분명한 하이퍼케어 지원이 필요합니다. 소외는 다툴 일이 아니라 고쳐야 할 소통의 실패입니다.

합리적 근거가 없는 저항은 더 어렵습니다. 지렛대는 대개 스폰서로, 프로그램에 경영진의 의지가 있음을 분명히 해야 합니다. 저항을 다루지 않고 밀어붙이는 것이 최악의 선택입니다. 우려는 UAT에서 다시 나타납니다.

SAP 프로그램에서 재무팀과 IT 사이의 갈등은 어떻게 다룹니까?

대부분 세 가지 긴장 중 하나로 압축됩니다. 접근 대 업무 분장, 보고의 유연성 대 데이터 거버넌스, 통합 속도 대 보안 검토입니다.

긴장을 정확히 명명하십시오. "재무팀은 컨트롤러가 보고를 위해 생산 오더에 읽기 권한을 갖기를 원하고, IT는 그것이 업무 분장을 깬다고 봅니다"는 해결할 수 있습니다. "재무팀은 유연성을 원합니다"는 해결할 수 없습니다. 선택지와 리스크를 갖고 운영위원회에 올리십시오. 그런 다음 의사결정과 대안을 기록하십시오. 사람이 바뀌면 이런 분쟁은 되돌아오기 때문입니다. 운영위원회가 해결하지 못하면 스폰서에게 갑니다. 그것이 거버넌스가 설계대로 작동하는 모습입니다.

RISE with SAP는 이해관계자 관리를 어떻게 바꿉니까?

SAP가 단순한 벤더가 아니라 참여자가 됩니다. 클린 코어에서 각 갭을 어떻게 처리할지 결정하는 확장 검토 포럼, SAP의 고객 성공 주기를 위한 거버넌스상의 자리, 파트너에 의존하지 않는 플랫폼 이슈용 SAP로 이어지는 문서화된 에스컬레이션 경로가 필요합니다. 서명하기 전에 에스컬레이션 연락처와 서비스 수준을 확인하십시오.