효과적인 SAP 프로젝트 운영위원회 만들기

SAP 프로젝트 운영위원회는 프로젝트 팀이 내릴 수 없는 결정, 즉 예산, 범위 변경, 부서 간 갈등, 최종 Go/No-Go를 맡는 소수의 경영진 모임입니다. 위원들에게 실질적인 권한이 있고, 회의 자리에서 결정할 만큼 자주 모이며, 달력이 아니라 증거로 준비 상태를 판단할 때 제대로 작동합니다. 이 가이드는 위원회를 새로 구성하거나, 상황 보고를 듣는 청중으로 전락한 위원회를 바로잡으려는 스폰서와 프로그램 디렉터를 위한 글입니다. 위원회가 무엇을 결정해야 하는지, 프로젝트 규모별 위원 구성, 결정은 어떻게 이뤄져야 하는지, Go/No-Go 점검표, 그리고 RISE with SAP와 AI 도구가 바꾸는 점을 다룹니다.

운영위원회가 약한 SAP 프로젝트가 성공하는 것을 본 적이 없습니다. 어려운 결정은 위원회에서 내려집니다. 그때그때 내려지든가, 쌓이고 쌓여 컷오버에서 터지든가 둘 중 하나입니다.

한 SAP 롤아웃에서는 위원회가 한 달에 한 번 모였습니다. 프로젝트 팀은 승인 워크플로가 깨져 있고, 테스트가 불완전하며, 교육이 빠져 있다고 알렸습니다. 경영진은 "검토하겠다"고 했습니다. 끝내 검토하지 않았습니다. 프로젝트는 Go-Live 했고, 재무팀은 이후 6개월 동안 뒷수습을 했습니다.

다른 회사에서는 위원회가 매주 모여 실질적인 결정을 내렸습니다. 테스트에서 공백이 드러나자 자원을 재배치했습니다. 어떤 프로세스가 작동하지 않으면 고쳤습니다. 그 프로젝트는 매끄럽게 Go-Live 했습니다.

한 위원회는 이끌었습니다. 다른 위원회는 회의에 앉아 있었습니다.

위원회가 상황 보고만 받고 있다면 이미 실패하고 있는 것입니다. 아래 표는 실제로 어떤 차이가 나는지 보여 줍니다.

기능	좋은 위원회	약한 위원회
주요 의사결정	안건을 검토하고 그 자리에서 결정	"오프라인에서 논의합시다", 안건은 다음 달에 다시 등장
장애물 제거	HR이 테스트를 지연시키면? 의장이 부서장에게 직접 전화	문제를 인정하고 기록만 남김
범위	모든 변경 요청을 계획과 비교해 저울질	가장 큰 소리로 올라온 요청을 그대로 승인
리스크	벤더가 흔들리는 것을 보면 지연이 닥치기 전에 대체 인력 확보	저절로 해결되는지 지켜봄
예산	중단의 피해가 더 크므로 3개월 연장을 위한 추가 $2M 승인	다음 달로 미룸
Go/No-Go	테스트가 끝나지 않았다는 이유로 Go-Live를 6주 연기하고 입장을 지킴	달력에 날짜가 있다는 이유로 Go-Live 승인

마지막 행이 가장 중요합니다. 팀이 밀어붙이고 싶어 해도 위원회가 Go-Live를 미루는 것을 본 적이 있습니다. 한 제약 고객의 위원회는 테스트가 끝나지 않았다는 이유로 Go-Live를 6주 늦췄습니다. 어려운 결정이었지만 재앙을 피하게 해 주었습니다.

위원이 너무 많으면 위원회는 결정하지 못합니다. 너무 적으면 필요한 목소리가 빠집니다.

프로젝트 규모	예산과 범위	위원 수	반드시 참석해야 할 사람
소규모	$0.5M 미만, 단일 부서, 6개월 미만	3~5명	부서장, IT 리드, 재무 대표
중견 기업	$0.5M~$5M, 여러 부서, 6~18개월	5~8명	영향받는 부서의 업무 리드, IT 경영진, 재무
엔터프라이즈	$5M 초과, 전사 규모, 18개월 이상	8~12명	재무, HR, 운영, IT의 C레벨, 프로그램 매니저, 변화 관리 리드

제가 적용하는 원칙은 실질적인 의사결정 권한을 가진 사람을 넣는 것입니다. 직함은 높은데 다른 누군가에게 확인하지 않고는 아무것도 승인할 수 없어서 실패한 위원회를 본 적이 있습니다. CFO가 참석하지 못한다면 보고하러 돌아갈 사람이 아니라, 결정할 진짜 권한을 가진 사람을 보내십시오.

의장은 프로젝트 스폰서, 보통 다른 경영진에게 책임을 물을 수 있는 C레벨 임원이어야 합니다. 중간 관리자가 의장을 맡으면 CFO의 뜻을 뒤집을 수 없고, 범위나 예산을 둘러싼 갈등이 터졌을 때 바로 그 권한이 중요해집니다.

증거에 근거해서. 한 제조 고객은 IT 팀이 어떤 프로세스 변경에 3개월이 더 걸린다고 했습니다. 현업은 "간단하다"고 우겼습니다. 위원회는 공수 산정, 의존성 분석, 용량 계획을 볼 때까지 결정을 거부했습니다. IT의 말이 맞았습니다. 위원회는 목소리가 큰 쪽 편을 들지 않고 증거를 요구했기 때문에 옳은 결정을 내렸습니다.

빠르게. 2주마다 모이면서도 항상 "이건 오프라인에서 논의합시다"로 끝나는 위원회를 가진 고객을 보았습니다. 이슈가 쌓여 프로젝트는 6개월 뒤처졌습니다. 다른 고객의 위원회는 회의 자리에서 결정을 내렸고, 그 프로젝트는 일정보다 일찍, 예산 안에서 끝났습니다. 느린 위원회는 늦은 프로젝트를 만듭니다.

명시적인 권한을 가지고. 효과적인 위원회는 부서장의 뜻을 뒤집고, 계획에 없던 예산을 승인하고, 진행 중에 들어온 범위 추가를 거부할 수 있습니다. 이 권한이 문서로 정해져 있고 모두가 이해하고 있지 않으면 위원회는 자문 기구가 되며, 자문 기구는 SAP 프로젝트를 완수하지 못합니다.

범위에 대해서는 선별적으로. 제 고객 한 곳에서는 어떤 부서가 갑자기 리포트 20개를 더 요구했습니다. 위원회는 각각이 지금 필요한지, 일정을 깨뜨리지 않는지 물었습니다. 핵심 리포트 5개는 승인하고 나머지는 Go-Live 이후로 넘겼습니다. 이 결정이 Go-Live 일정을 지켜 냈을 가능성이 큽니다.

회의는 60~90분으로 유지하십시오. 상위 리스크, 필요한 구체적 결정, 담당자와 기한이 있는 조치 사항입니다. 미리 읽어 올 수 있는 기술 업데이트는 넣지 않습니다. 같은 이슈가 세 번 연속 회의에 올라오고도 해결되지 않는다면, 문제는 복잡성이 아니라 거버넌스입니다.

덱이 아니라 데이터를 쓰십시오. 한 에너지 고객은 테스트 수행, 결함 해결, 교육 이수, 예산 소진을 한눈에 보는 대시보드를 만들었습니다. 회의는 현황을 파악하는 자리에서 문제를 해결하는 자리로 바뀌었습니다.

위원회에 시스템을 보여 주십시오. 한 제약 고객의 위원회는 "하루의 일과" 시나리오를 따라가 보았습니다. 승인된 설계대로라면 흔한 프로세스 하나에 직원이 다섯 개의 서로 다른 화면을 써야 한다는 것을 깨달았습니다. 위원회는 즉시 재설계를 지시했습니다.

정치에 대비하십시오. 가장 흔한 실패는 무능이 아닙니다. 영역을 지키려는 부서들, 연말 업무를 핑계로 테스트를 미루는 팀들입니다. 한 프로젝트에서 HR은 연말 업무로 바쁘다며 급여 테스트를 계속 미뤘습니다. 위원회는 업무 우선순위를 다시 정하고 백업 테스터를 배정했고, 프로젝트는 몇 달씩 밀리는 대신 궤도를 유지했습니다.

주요 게이트에서는 독립적인 점검을 쓰십시오. 한 제조 고객은 Go-Live 승인 전에 외부 검토자들에게 준비 상태를 평가받았습니다. 검토에서 프로젝트 팀이 놓쳤거나 축소해 두었던 심각한 문제 여러 건이 나왔습니다. SAP 품질 게이트 가이드가 이런 점검 지점을 구성하는 방법을 보여 줍니다.

달력의 압박은 Go-Live를 승인하는 근거로 잘못된 것입니다. 표결 전에 위원회는 다음 각 항목에 대한 증거를 보아야 합니다.

1. 통합 테스트와 사용자 인수 테스트 완료, 미해결 치명적 결함 없음
2. 최종 모의 데이터 이관이 대사되고 재무팀이 서명함
3. 계획된 시간 안에 컷오버 리허설 완료
4. 핵심 사용자 교육 완료, 현장 지원과 업무 보조 자료 준비
5. 각 프로세스 오너가 서면으로 업무 준비 상태를 확인
6. 롤백 계획이 테스트되고 합의됨
7. 하이퍼케어 팀, 에스컬레이션 경로, 첫 결산 지원 체계 마련

하나라도 빨간색이면 강한 위원회는 No라고 말합니다. 6주 지연은 만회할 수 있습니다. 운영이나 재무 결산을 흔드는 Go-Live 실패는 안정화에 몇 달이 걸릴 수 있습니다. 날짜가 움직일 수 없는 것처럼 느껴져서 승인된 Go-Live를 너무 많이 수습해 보았습니다. 이 항목들이 일찍 드러나도록 위원회 안건을 실시간 리스크 레지스터에서 가져오십시오.

RISE는 SAP를 거버넌스 모델 안으로 들여옵니다. RISE with SAP에서는 SAP가 인프라와 기술 운영을 맡습니다. SAP의 RISE 역할 및 책임 문서에 따르면 고객은 SAP Cloud Architect Advisor, Client Delivery Manager 또는 SAP의 프라이빗 클라우드 고객 센터와 일합니다. 성능, 가용성, 서비스 수준 같은 플랫폼 이슈에 대해서는 위원회가 구축 파트너를 거치지 않고 이 담당자들에게 닿는 경로를 가져야 합니다. 상시 위원이 아니라 해당 안건이 있을 때 초청하십시오.

클린 코어 포럼은 위원회 아래에 두어야 합니다. RISE 프로그램에서는 클린 코어 원칙에 비추어 커스터마이징 요청을 승인하거나 거부하는 설계 권한 조직(design authority)을 세우십시오. 비즈니스상 핵심적인 요청이 막혔을 때만 위원회로 올립니다. 이 층이 없으면 모든 커스터마이징이 위원회의 싸움이 됩니다. 온프레미스에서는 전통적인 모델이 그대로 적용되며 SAP는 참여자가 아니라 벤더입니다.

1. 운영위원회스폰서가 의장. 예산, 범위, 갈등, Go/No-Go
   SAP 딜리버리 담당자플랫폼 안건이 있을 때 초청, 파트너를 거치지 않음

• 프로그램 관리 조직(PMO)일상 실행, 리스크 로그, 조율
• 클린 코어 설계 권한 조직커스터마이징 판정, 막힌 핵심 요청만 에스컬레이션

AI는 문서 작업 시간을 줄여 줍니다. Microsoft 365 Copilot은 녹화된 회의에서 회의록 초안을 작성합니다. 처음부터 쓰는 대신 초안을 검토하는 일이 되고, 결정 사항은 녹취록에서 나옵니다. Atlassian의 Rovo는 템플릿만 만들어 두면 회의 노트를 구조화된 의사결정 로그 항목으로 바꿀 수 있습니다. SAP Cloud ALM의 Joule 기반 어시스턴트는 범위 변경 요청에 대한 첫 영향 평가를 초안으로 작성할 수 있어서, 위원회가 결정을 미루지 않고 회의 자리에서 내릴 수 있습니다.

감성 분석은 당분간 건너뛰십시오. 일부 벤더는 프로그램 커뮤니케이션의 감성 분석을 위원회의 입력 자료로 내세웁니다. 대부분의 프로그램에서는 쇼에 불과합니다. 신호가 약하고, 오탐이 흔하며, 감성을 감시하는 모습으로 비치는 데에는 정치적 비용이 따릅니다. 아주 큰 프로그램에서만 이탈하는 그룹을 일찍 포착해 줄 수 있습니다. 대부분의 위원회에게는 AI 예산을 쓸 곳이 아닙니다.

SAP 프로젝트에서 운영위원회의 역할은 무엇입니까?

프로젝트 팀이 내릴 수 없는 결정을 내립니다. 예산 승인, 범위 변경, 자원 에스컬레이션, 최종 Go/No-Go입니다. 부서 간 갈등을 해결하고 부서장들이 테스트와 교육에 대한 약속을 지키도록 합니다. 상황 보고만 받고 있다면 제 역할을 하지 못하는 것입니다. 가치는 참석한 회의가 아니라 내린 결정에 있습니다.

SAP 운영위원회는 몇 명으로 구성해야 합니까?

단일 부서의 소규모 프로젝트는 3~5명, 중견 기업은 5~8명, 엔터프라이즈 프로그램은 8~12명입니다. 흔한 실패는 사람이 너무 많은 것입니다. 20명이 되면 위원회는 발표를 듣는 청중이 됩니다. 모든 위원은 무언가에 대해 실질적인 의사결정 권한을 가져야 합니다. RISE에서는 SAP의 딜리버리 담당자를 상시 위원이 아니라 플랫폼 안건이 있을 때 불러오십시오.

RISE with SAP는 운영위원회를 어떻게 바꿉니까?

SAP가 인프라와 기술 운영의 딜리버리 참여자가 되므로, 위원회에는 구축 파트너를 거치지 않고 SAP가 지정한 담당자에게 닿는 직접 경로가 필요합니다. 또한 그 아래에 커스터마이징 요청을 다루는 클린 코어 설계 권한 조직이 필요하며, 막힌 핵심 요청만 위원회로 올립니다. 온프레미스에서는 SAP가 여전히 벤더입니다.

운영위원회와 PMO는 어떻게 다릅니까?

프로젝트 관리 조직(PMO)은 일상 실행을 맡습니다. 과제, 리스크 로그, 워크스트림 간 조율입니다. 운영위원회는 PMO가 내릴 수 없는 결정, 즉 예산 이동, 범위 변경, Go/No-Go를 내립니다. 더 큰 조직에서는 포트폴리오 차원의 위원회가 여러 프로젝트 위에 있으면서 프로젝트 간 자원을 배분합니다.

운영위원회 안건에는 무엇이 들어가야 합니까?

업데이트가 아니라 결정입니다. 상위 3~5개 리스크로 시작해, 승인이 필요한 구체적 결정, 해결해야 할 부서 간 이슈, 담당자와 기한이 있는 지난 회의의 조치 사항 순으로 진행합니다. 어떤 항목이 해결 없이 세 번 올라오면, 같은 논의를 반복하지 말고 그 안건을 다루는 방식 자체를 에스컬레이션하십시오.

운영위원회는 언제 Go-Live를 연기해야 합니까?

테스트가 끝나지 않았을 때, 핵심 사용자 교육이 되지 않았을 때, 데이터 이관이 대사되지 않았을 때, 핵심 연동이 불안정할 때, 롤백 계획이 테스트되지 않았을 때입니다. 연기는 거의 항상 Go-Live 이후의 뒷수습보다 비용이 적게 듭니다. 6주 지연은 만회할 수 있지만, 공급망이나 재무 결산을 흔드는 Go-Live 실패는 안정화에 몇 달이 걸릴 수 있습니다.