SAP 구축 팀의 핵심 역할과 책임

SAP 구축에는 이름이 분명하고 전담하는 오너가 있는 여덟 가지 역할이 필요합니다. 경영진 스폰서, 프로젝트 매니저, 기능 리드, IT 리드, 데이터 이관 리드, 변화 관리 리드, 구축 파트너, 독립적인 프로그램 어드바이저입니다. RISE with SAP는 여기에 SAP 자체의 딜리버리 담당자를 더하고 Clean Core의 소유권을 명시하게 만듭니다. 이 가이드는 팀을 꾸리거나 바로잡는 스폰서와 프로그램 디렉터를 위한 것입니다. 각 역할이 무엇을 책임지는지, 그 역할이 없으면 무엇이 무너지는지, 기업 규모별 팀 규모, Go-Live 전에 CoE(Center of Excellence)를 구축하는 방법을 다룹니다. 먼저 여덟 역할 중 본업을 따로 가진 사람이 맡고 있는 역할이 무엇인지 확인하십시오. 그것이 가장 큰 위험입니다.

저는 오랜 세월 수십 개의 SAP 팀과 일했습니다. 자금이 충분하고 경험 많은 벤더가 있어도, 핵심 역할이 비어 있거나 다른 업무가 있는 사람들에게 나뉘어 있다는 이유로 실패하는 프로젝트를 봤습니다. 반대로 자금이 부족해도 적합한 사람들이 현장에서 온전히 몰입하고 책임이 분명해서 성공한 프로젝트도 봤습니다.

제가 함께 일한 글로벌 유통업체에는 예산도, 경영진의 지원도, ERP로 선택한 SAP도 있었습니다. 그런데 구축 팀은 엉망이었습니다. 핵심 역할이 비어 있었습니다. 중요한 결정을 책임지는 사람이 없었습니다. 소통은 사방으로 오갔지만 어디에도 도달하지 못했습니다. 일정은 밀렸고, 비용은 올랐고, 신뢰는 무너졌습니다.

모든 SAP 구축에는 이 역할이 채워져 있어야 합니다. 직함은 중요하지 않습니다. 책임이 중요합니다.

1. 경영진 스폰서의사결정, 자금, 에스컬레이션
   ERP 프로그램 어드바이저독립적인 감독, 리스크, 경영진 정렬
2. 프로젝트 매니저일정, 예산, 조율

• 기능 리드와 업무 전문가프로세스 설계, 모듈 구성
• IT 리드와 팀연동, 개발, 보안
• 데이터 이관 리드데이터 품질, 적재 순서, 컷오버
• 변화 관리 리드교육, 정착, 소통
• 구축 파트너아키텍처, 연동 설계, 수행

역할	주요 책임	이 역할이 없으면 무너지는 것
경영진 스폰서	전략적 의사결정, 자금, 에스컬레이션 권한	표류, 범위 다툼, 의견이 갈릴 때 결론을 내 줄 사람이 없음
프로젝트 매니저	일정, 예산, 팀 간 조율	지연, 해결되지 않는 장애물, 비용 초과
기능 리드와 업무 전문가	비즈니스 프로세스 설계, 모듈 구성	잘못된 구성, Go-Live 이후 우회 작업
IT 리드와 팀	연동, 개발, 보안, 성능	기술 부채, 깨진 인터페이스, 불안정
데이터 이관 리드	데이터 품질, 적재 순서, 컷오버 정확도	쓸 수 없는 데이터, 실패한 Go-Live, 몇 달간의 정리 작업
변화 관리 리드	교육, 정착, 소통	사용자 저항, 병행 운영되는 스프레드시트
구축 파트너	아키텍처, 연동 설계, 수행	과잉 구축, 연동 실패
ERP 프로그램 어드바이저	독립적인 감독, 리스크, 경영진 정렬	고립된 의사결정, 피할 수 있었던 실수

경영진 스폰서

스폰서는 운영위원회 자료에 적힌 이름이 아닙니다. 다른 누구도 내릴 수 없는 결정을 내리는 사람입니다. 예산, 범위 변경, 부서 간 자원 투입이 그것입니다. 이 역할이 형식뿐이면 프로젝트는 표류합니다.

이 역할을 건너뛴 회사와 일한 적이 있습니다. 프로젝트는 표류했습니다. 결정도 없고 진전도 없고, 돈만 허공에 사라졌습니다.

효과적인 스폰서는 하이퍼케어까지 함께합니다. Go-Live 이후에도 월간 운영위원회에 참석하고, 몇 주째 막혀 있던 일을 풀어 주는 작은 결정을 내립니다. 제 가이드 SAP 운영위원회 구성하기가 그 회의체를 어떻게 구조화하는지 다룹니다.

프로젝트 매니저

PM은 일정, 리스크 로그, 조율, 업데이트 등 일상을 운영합니다. 대규모 SAP 프로그램에서는 해 본 경험이 있는 사람이 전담해야 하는 역할입니다.

한 고객이 구축 도중에 수석 개발자를 잃는 모습을 지켜봤습니다. 대체자를 찾느라 허둥대는 동안 프로젝트 전체가 몇 주 멈췄습니다.

반대의 문제도 똑같이 해롭습니다. 팀원이 30명이 넘는 회사와 일한 적이 있습니다. 누가 결정을 책임지는지 아무도 몰랐습니다. 단순한 변경에도 회의가 다섯 번 필요했습니다. 소통 부담만으로 일정이 12개월에서 18개월로 늘어났습니다.

기능 리드와 업무 전문가

이 사람들은 비즈니스 운영을 SAP 구성으로 옮깁니다. 나쁜 프로세스에 이의를 제기할 만큼 비즈니스를 알아야 하고, 무엇이 가능한지 알 만큼 SAP를 알아야 합니다.

기능 리드들이 프로세스를 설계하기 전에 공장 현장에서 시간을 보낸 덕분에 팀이 뛰어난 성과를 낸 제조업 고객과 일한 적이 있습니다.

업무 전문가(SME)가 반쯤만 몰입하면 언제나 빈틈이 생깁니다. 프로젝트가 그들의 관심을 받든지, 아니면 승인 서류에 이름만 올라가든지 둘 중 하나입니다. 그 둘은 같지 않습니다.

IT 리드와 팀

IT 팀은 기술 기반을 책임집니다. 개발, Basis, 보안, 연동, 성능입니다. S/4HANA에서는 Clean Core 원칙, 즉 커스텀 코드를 코어 밖에 두는 일도 맡습니다.

연동은 대부분의 팀이 과소평가하는 부분입니다. 외부 시스템과의 연결마다 설계하고, 구축하고, 테스트하고, 책임자를 두어야 합니다. 아무도 데이터 흐름을 매핑하지 않았다면 인터페이스는 UAT에서 깨집니다. IT를 결정이 내려진 뒤가 아니라 블루프린트 세션에 참여시키십시오.

데이터 이관 리드

이 역할은 늦게 배정되고 인력도 부족합니다. 데이터 문제가 드러날 즈음이면 프로그램은 이미 일정 압박을 받고 있습니다.

한 고객은 데이터 정제를 건너뛸 수 있다고 생각했습니다. 큰 실수였습니다. 시스템은 몇 달 동안 쓸모가 없었습니다. 운영 중인 시스템에서 데이터를 정리하는 데는 처음에 제대로 정제하는 것보다 비용이 더 듭니다.

전담 이관 리드는 적재마다 정합성 대조를 수행하고, 그렇게 해서 구조적 문제가 Go-Live 전에 드러납니다. 다른 워크스트림 세 개를 겸하는 사람이 이 역할을 맡으면 그런 일이 일어나지 않습니다. 제 글 SAP 데이터 이관이 실패하는 이유가 그 방법을 다룹니다.

변화 관리 리드

이 역할은 일관되게 인력이 가장 부족합니다. 수백만 달러짜리 시스템이 아무도 일하는 방식을 바꾸고 싶어 하지 않아서 방치되는 모습을 봤습니다.

기술적으로는 완벽한 구축이 사용자들이 싫어해서 실패하는 것을 봤습니다. 구성은 정확했고 프로세스 설계도 탄탄했습니다. 그러나 매일 그것을 쓰는 사람들은 설계에 참여하지 않았습니다. 왜 달라졌는지 이해하지 못했고, 계속 예전 Excel 파일을 썼습니다.

한 유통 고객은 계산원들이 새 시스템에 대해 제기한 우려에 귀를 기울이고 접근 방식을 조정한 덕분에 성공했습니다.

엔터프라이즈 프로그램의 최소 기준은 전담 변화 관리 인력 두 명입니다. 한 사람이 교육 설계, 소통, 저항 관리, 정착 추적을 한꺼번에 감당할 수는 없습니다.

ERP 프로그램 어드바이저

독립 어드바이저는 구축 파트너가 아닙니다. 하는 일은 감독과 방향 수정입니다. 방향이 여전히 타당한지 확인하고, 수행 팀이 너무 가까워서 보지 못하는 리스크를 짚어 내고, 경영진이 생각하는 상황과 실제 상황 사이의 간격을 메웁니다.

수행 팀은 탄탄하지만 독립적인 목소리가 없던 고객을 위해 이 역할을 맡았습니다. 성장 전략을 SAP 로드맵과 연결해 본 사람이 없어서 하마터면 엉뚱한 모듈을 구축할 뻔한 제조업 고객과 일한 적이 있습니다.

문제를 일찍 발견하는 것이 나머지 절반입니다. 한번은 고객의 데이터 팀에서 Go-Live를 지연시켰을 핵심 역량 공백을 석 달 앞서 찾아냈습니다. 위기가 되기 전에 바로잡았습니다.

여덟 가지 역할 모델은 여전히 유효합니다. 2026년에는 세 가지를 여기에 연결해 넣어야 합니다.

RISE에서 SAP 자체의 딜리버리 담당자

RISE with SAP 프라이빗 클라우드에서는 SAP가 인프라와 기술 운영을 맡습니다. SAP의 역할 및 책임 문서에 따르면 고객은 SAP Cloud Architect Advisor, Client Delivery Manager 또는 SAP의 프라이빗 클라우드 고객 센터 팀과 서비스를 합의합니다. SAP가 지정한 담당자를 파트너 팀 옆에 명단으로 올리고, 고객 측에서 그 관계를 책임지는 사람을 지정하십시오. 온프레미스에서는 SAP가 소프트웨어 벤더일 뿐이므로 해당되지 않습니다.

Clean Core와 확장의 소유권

S/4HANA Cloud Public Edition에서는 Clean Core가 설계상 강제됩니다. 확장은 공개된 API, 키 유저 도구 또는 SAP BTP를 통해 이루어집니다. 프라이빗 클라우드와 온프레미스에서는 수정이 여전히 가능하지만, 수정 하나하나가 업그레이드를 더 어렵게 만듭니다. 그 선을 지키는 책임자가 있어야 합니다.

규모가 큰 프로그램에서는 솔루션 아키텍트에게 보고하는 전담 Clean Core 아키텍트나 BTP 확장 리드가 이 일을 맡습니다. 중견기업 프로그램에서는 보통 솔루션 아키텍트가 겸하지만, 책임은 문서로 남겨야 합니다. 파트너를 평가할 때는 BTP 확장을 몇 건 수행했는지 묻고 사례를 보여 달라고 요청하십시오.

AI는 생산성을 바꾸지, 책임을 바꾸지 않습니다

SAP Joule for Consultants(2025년부터 정식 출시)는 SAP 자체의 지식 베이스를 바탕으로 구성 관련 질문에 답하고 ABAP 코드를 설명합니다. SAP Build Code는 SAP BTP에서 Java와 JavaScript 확장 코드를 생성합니다. Microsoft Copilot은 운영위원회 보고서와 상태 보고서의 초안을 작성합니다.

효과는 요구사항 분석, 상태 보고, 커스텀 개발처럼 워크플로 비중이 큰 역할에서, 그리고 사람들이 도구를 꾸준히 쓸 때만 나타납니다. 누군가 제시하는 생산성 수치는 모두 자신의 프로그램에서 검증해 볼 주장으로 취급하십시오.

같은 범위를 이런 도구 없이 수행하던 때보다 팀은 다소 작아지지만, 극적으로 작아지지는 않습니다. 도구를 부수적인 활동으로 취급하지 말고 역할 정의에 포함시키십시오. AI는 초안을 더 빨리 씁니다. 그 초안이 말하는 내용은 여전히 사람이 책임집니다.

표는 기업 규모별로 각 역할의 일반적인 인력 규모를 보여 줍니다. 출발점으로 삼고, 범위와 지역에 맞게 조정하십시오. SAP 밖의 같은 질문은 제 ERP 구축 팀 가이드를 보십시오.

역할	소규모 기업	중견기업	대기업
경영진 스폰서	선임 이사	CIO 또는 CFO	운영위원회를 둔 C레벨
프로젝트 매니저	전담 1명	전담 1~2명	프로그램 매니저와 워크스트림 PM
기능 리드	모듈당 1~2명	모듈별 전담	모듈당 여러 명
IT 팀	2~3명(겸임)	4~6명(전담)	전문가 8명 이상
데이터 이관	리드 1명	리드 1명과 분석가	전담 워크스트림
변화 관리	최소 1명	최소 2명	전담 3~5명
Clean Core 또는 BTP 확장 리드	솔루션 아키텍트	솔루션 아키텍트	전담 역할
SAP 담당자(RISE)	지정 담당자	지정 담당자	분기별 검토를 하는 지정 담당자들
구축 파트너	컨설턴트 5~10명	컨설턴트 15~25명	프로그램 디렉터를 둔 30명 이상

기술 역량은 시스템을 만들게 합니다. 감성 지능은 사람들이 그것을 쓸지 말지를 결정합니다.

창고 관리자가 회의에서는 웃으면서 뒤에서는 프로젝트를 흔들던 제조업체와 일한 적이 있습니다. 눈치 빠른 변화 관리자가 조짐을 일찍 알아채고 그를 지지자로 바꿔 놓았습니다. Go-Live 때 발견했다면 훨씬 수습하기 어려웠을 것입니다.

한 고객의 프로젝트 매니저는 기술적으로 뛰어났지만 메시지를 상대에 맞게 바꾸지 못했습니다. CFO에게는 창고 직원과 다른 소통이 필요합니다. 그 결과 조직 전반에서 지지를 얻지 못했고 Go-Live는 고통스러웠습니다.

"직원이냐 컨설턴트냐"라는 질문의 답은 거의 언제나 둘 다입니다.

직원은 비즈니스를 압니다. 프로세스, 사내 정치, 아무도 문서화하지 않은 우회 방법입니다. 외부 컨설턴트가 완전히 놓친 구축 이슈를 직원이 찾아낸 제조업체와 일한 적이 있습니다. 그 통찰 덕분에 창고 구성이 참담하게 잘못되는 일을 피했습니다.

직원에게는 구축 경험이 없는 경우가 많습니다. 한 유통 고객은 내부 인력만으로 팀을 꾸리겠다고 고집했습니다. 6개월이 지났을 때, SAP를 배우면서 구축하고 있었기에 희망이 없을 만큼 뒤처져 있었습니다.

컨설턴트는 패턴 인식을 가져옵니다. 한 고객을 위해 컨설턴트를 투입했더니, Go-Live를 무너뜨렸을 데이터 이관 방식을 즉시 짚어 냈습니다.

컨설턴트의 위험은 지식 이전입니다. 내부에서 시스템을 배우는 사람이 없으면 컨설팅 비용은 출시 후에도 오래 계속됩니다.

효과가 있는 모델은 섀도 페어입니다. 한 제약 고객은 컨설턴트마다 Go-Live 이후 해당 영역을 책임질 내부 카운터파트를 붙였습니다. 컨설턴트는 수행하고, 카운터파트는 배우고, 지식은 남습니다. 이 모델을 둘러싸고 여섯 가지 실천이 차이를 만듭니다.

1. 소프트웨어를 고르기 전에 팀을 만드십시오. 한 고객은 팀이 유지할 수 없는 모듈을 샀고, 6개월 동안 혼란이 이어졌습니다.
2. 사람을 온전히 전담시키십시오. 겸임이면 압박이 올 때 본업이 이깁니다. 누군가 너무 바빠서 핵심 구성 작업이 몇 주씩 기다리는 것을 봤습니다.
3. 가능하면 같은 공간에 모이십시오. 한 제조업 고객은 팀을 주 3일 같은 방에 모아 몇 주치의 주고받기를 줄였습니다.
4. 에스컬레이션 경로를 일찍 정의하십시오. 한 유통 고객은 의사결정이 어떻게 상위로 올라가는지 정확히 보여 주는 한 장짜리 문서를 갖고 있었습니다. 수많은 지연을 막아 주었습니다.
5. 결정은 근거와 함께 기록하십시오. 무엇을 왜 결정했는지 기록해 둔 회사와 일한 적이 있습니다. 프로젝트 도중에 새 임원이 합류했을 때 끝없는 되풀이 논의를 막아 주었습니다.
6. 진행 중에 이정표를 기념하십시오. 한 제조업 고객은 매달 인정 행사를 열었습니다. 사소한 일이지만 힘겨운 18개월 구축 내내 사기를 지켜 주었습니다.

Go-Live 이후 기업들이 저지르는 실수는 구축 팀을 해체하는 것입니다. 바로 그때 CoE가 개선 작업, 업그레이드, 거버넌스, 신규 사용자 교육, 그리고 구성이 비즈니스가 실제로 돌아가는 방식과 계속 맞도록 유지하는 일을 넘겨받아야 합니다.

구축 중에 계획하십시오. 이 조언을 무시한 제조업 고객이 있었습니다. Go-Live 석 달 뒤에 핵심 구성 전문가들이 떠났습니다. 구축된 것을 어떻게 유지하는지 아는 사람이 없었고, 시스템은 곧바로 악화되기 시작했습니다.

구축 첫 몇 달부터 계획해야 하는 CoE 역할은 다음과 같습니다.

CoE 역할	주요 책임
CoE 디렉터	SAP 전략, 비즈니스 목표와의 정렬, CoE 운영
솔루션 아키텍트	아키텍처, 연동 설계, Clean Core 거버넌스
Clean Core 또는 BTP 확장 리드	확장 카탈로그, 업그레이드 영향 분석
기능 컨설턴트	모듈 최적화, 프로세스 개선
기술 컨설턴트	개발, Basis, 성능, 보안
변화 및 교육 리드	정착, 교육, 역량 강화
데이터 거버넌스 리드	마스터 데이터 품질과 표준
연동 리드	미들웨어, API, 시스템 간 데이터 흐름
지원 리드	이슈 해결, 지속적 개선
SAP 관계 오너(RISE)	SAP로의 에스컬레이션, 서비스 검토, 로드맵 정렬

한 제약 회사는 자기 영역에 영향을 줄 수 있는 변경을 승인해야 하는 모듈 오너를 지정했습니다. 그 거버넌스는 2~3년이 지나면 시스템을 쓰기 어렵게 만드는 조율되지 않은 변경을 막아 주었습니다.

한 고객은 CoE 예산의 10%를 지속적인 학습에 투자했습니다. 3년 뒤 이 회사는 경쟁사가 손도 대지 못하는 신기능을 구현하고 있었습니다. 제대로 작동하는 CoE는 그런 모습입니다.

계획이 탄탄해 보이는데도 SAP 구축 팀이 실패하는 이유는 무엇입니까?

대개 계획이 기술은 다루면서 사람은 무시하기 때문입니다. 흔한 패턴은 핵심 역할을 다른 업무가 있는 사람이 맡는 것, 프로젝트 도중에 업무 전문가가 현업으로 복귀하는 것, 변화 관리를 교육 기능으로만 취급하는 것입니다. 아무도 결정을 책임지지 않고 에스컬레이션 경로도 없으면 장애물이 몇 주씩 방치되고, 프로젝트는 기술이 아니라 조율에서 실패합니다.

어떤 SAP 구축에서든 반드시 있어야 하는 역할은 무엇입니까?

여섯 가지 역할에는 전담하고 책임지는 사람이 필요합니다. 경영진 스폰서, 프로젝트 매니저, 주요 모듈마다 최소 한 명의 기능 리드, IT 리드, 데이터 이관 리드, 변화 관리 리드입니다. 하나라도 빠지면 Go-Live 직전 몇 주에 그 공백이 드러납니다. 인력이 가장 부족한 곳은 변화 관리입니다. RISE에서는 확장과, SAP 딜리버리 담당자와의 관계를 책임지는 명확한 오너를 추가하십시오.

RISE with SAP에서는 팀 설계가 어떻게 달라집니까?

SAP가 인프라와 기술 운영을 맡으므로, Client Delivery Manager나 Cloud Architect Advisor 같은 SAP 지정 담당자와 일하게 됩니다. 그들을 명단에 올리고 고객 측의 관계 오너를 지정하십시오. Clean Core의 소유권도 명시해야 합니다. 대규모 프로그램에서는 전담 아키텍트, 중견기업 프로그램에서는 솔루션 아키텍트가 맡습니다.

SAP 프로젝트 팀은 직원으로 구성해야 합니까, 컨설턴트로 구성해야 합니까?

둘 다입니다. 직원은 컨설턴트가 단기간에 따라잡을 수 없는 비즈니스 맥락을 가져옵니다. 컨설턴트는 직원에게 대개 없는 구축 패턴 인식을 가져옵니다. 컨설턴트마다 Go-Live 이후 해당 영역을 책임질 내부 카운터파트를 짝지어, 컨설턴트가 떠난 뒤에도 지식이 남게 하십시오. 이를 건너뛴 기업은 내부에서 처리했어야 할 지원 비용을 몇 년씩 지불하는 경우가 많습니다.

SAP CoE는 언제부터 만들어야 합니까?

구축 중에, 가급적 첫 몇 달부터 시작하십시오. 최고의 CoE 구성원은 대개 구축에서 가장 크게 기여한 사람들이고, Go-Live까지 기다리면 그들을 찾아내기도 전에 떠납니다. 기다렸던 한 제조업 고객은 Go-Live 석 달 뒤에 핵심 구성 전문가들을 잃었고, 구축된 것을 어떻게 유지하는지 아는 사람이 없었습니다.

2026년에 AI는 SAP 팀 설계를 어떻게 바꿉니까?

SAP Joule for Consultants, SAP Build Code, Microsoft Copilot 같은 도구는 사람들이 꾸준히 쓸 때 워크플로 비중이 큰 역할의 생산성을 높입니다. 같은 범위를 이런 도구 없이 수행하던 때보다 팀은 다소 작아지지만, 극적으로 작아지지는 않습니다. 도구를 역할 정의에 포함시키고, 책임은 사람에게 두십시오. AI는 초안을 더 빨리 쓰지만, 그 초안이 말하는 내용은 여전히 사람이 책임집니다.