SAP 프로젝트의 리소스 배분 계획

SAP 프로젝트의 리소스 배분 계획이란 어떤 역할이 필요한지, SAP Activate의 어느 단계에서, 주당 몇 시간이 필요한지를 정하고, 현실이 여전히 계획과 맞는지 매주 확인하는 일입니다. 막연한 인원수가 아니라 역할 기준으로 인력을 배치하십시오. 계획은 단계별 곡선에 맞추십시오. Explore에서는 기능 인력, Realize에서는 기술 인력, Deploy에서는 데이터, Basis, 변화 관리가 중심입니다. 가용 시간은 직속 관리자로부터 서면으로 확인하십시오. 이 가이드는 S/4HANA 리소스 계획을 세우거나 되살리려는 프로그램 디렉터, PMO, CIO를 위한 것입니다. 아래 FTE 표와 일 단가 범위를 출발점이 되는 기준으로 쓰십시오.

저는 수십 건의 구축 프로젝트가 같은 리소스 문제로 어려움을 겪는 것을 지켜보았습니다. 계획은 실행이 시작되면 사라지는 안정성을 전제로 합니다.

한번은 보안 책임자의 휴가와 교육이 연달아 잡혀 있다는 사실을 아무도 몰랐던 탓에 팀이 한 주를 통째로 잃는 것을 보았습니다. 표시도, 추적도 되지 않았고, 핵심 시스템 접근 권한 검토가 9일 지연되었습니다.

대부분의 SAP 계획은 깔끔한 추정치, 전일 투입 가능성, 예측 가능한 워크플로에 기댑니다. 그런 세상은 Realize 첫 달을 넘기기도 어렵습니다.

저는 세 가지를 중심으로 계획합니다. 업무가 실제로 요구하는 것, 가용 인력이 실제로 낼 수 있는 성과, 그리고 현실이 계획과 다를 때 달라지는 것입니다. 견고한 계획은 여섯 가지 차원을 다룹니다.

1. Activate 단계별, 역할별 인원. 평평한 배분이 아닙니다. Explore와 Realize는 전혀 다릅니다.
2. 직속 관리자가 확인한 주당 투입 시간. 가정이 아니라 서면으로.
3. 개인별 동시 업무. 100%로 잡혀 있으면서 운영 지원까지 맡은 사람은 훨씬 적게 해냅니다.
4. 모든 크리티컬 패스 역할의 백업. 18개월짜리 프로그램에서 교차 교육은 선택이 아닙니다.
5. 스트림 간 의존성. 각각 지정된 담당자, 기한, 에스컬레이션 경로를 두고, 지연되는 당일에 눈에 보이게 합니다.
6. 갱신 주기. 활발한 단계에서는 매주. 킥오프 때의 계획은 첫 번째 버전일 뿐입니다.

계획이 어긋나는 것은 계획자가 일반적인 IT 역할을 쓸 때입니다. SAP에는 구체적인 기능 및 기술 전문성이 필요합니다. S/4HANA 프로그램의 표준 구성은 다음과 같습니다.

프로그램 리더십. 프로그램 매니저, PMO 리더, 솔루션 아키텍트. 아키텍트는 모듈 전반의 설계 일관성에 책임을 집니다.

기능 컨설턴트. 범위에 포함된 모듈마다 리드 한 명: 재무회계(FI), 관리회계(CO), 자재 관리(MM), 판매 및 유통(SD), 생산 계획(PP), 확장 창고 관리(EWM), 그리고 범위에 들어가는 경우 인사(HCM), 설비 보전(PM), 프로젝트 시스템(PS). 아직 기존 창고 관리(WM)를 쓰고 있다면 이전을 계획하십시오. S/4HANA 온프레미스에서 WM의 호환성 팩 사용 권한은 2025년 말에 종료되었습니다.

기술 컨설턴트. 리포트, 인터페이스, 전환, 확장, 양식, 워크플로(RICEFW)와, 릴리스된 API나 SAP BTP 위의 클린 코어 확장을 맡는 ABAP 개발자. SAP Integration Suite(Cloud Integration, 이전 명칭 CPI), 아직 운영 중인 곳에서는 SAP Process Orchestration, 그리고 서드파티 미들웨어를 맡는 연동 전문가.

플랫폼. HANA, 커널 패치, 트랜스포트, 시스템 복사, 성능 튜닝을 맡는 Basis 컨설턴트. 롤 설계, 직무 분리(SoD) 분석, 범위에 포함된 경우 SAP GRC Access Control을 맡는 보안 컨설턴트.

데이터. SAP S/4HANA Migration Cockpit의 “Migrate Your Data” 앱(이전의 LTMC 트랜잭션은 사용 중단 상태입니다), 커스텀 오브젝트용 Migration Object Modeler, 복잡한 변환용 SAP Data Services를 쓰는 마이그레이션 전문가. 제 가이드 SAP 데이터 마이그레이션이 실패하는 이유는 이 팀이 대부분의 계획이 허용하는 것보다 일찍 시작해야 하는 이유를 설명합니다.

변화 관리. 변화 관리 리드, 교육 리드, 업무 준비도 책임자. 필요성이 Deploy에 와서야 보이기 때문에 대개 인력이 부족합니다.

고객사 측. 업무 분석가(주요 모듈당 한 명), 프로세스 오너(프로세스 영역당 한 명), UAT를 위해 현업에서 차출한 테스터.

이 역할들을 서로 바꿔 쓸 수 있는 자리처럼 취급하는 것이 가장 흔한 계획 오류입니다. 시니어 FI 컨설턴트는 SD 설계 세션을 이끌 수 없습니다. 주니어 ABAP 개발자는 연동 아키텍처를 설계할 수 없습니다. 역할별 책임은 제가 정리한 SAP 구축 팀의 핵심 역할 목록을 참고하십시오.

리소스 수요는 평평하지 않습니다. Activate 단계는 예측 가능한 곡선을 만들며, 평평한 배분은 이를 놓칩니다.

Prepare(보통 1~4주차). 가볍습니다. 프로그램 매니저, 아키텍트, 범위 확정을 위한 모듈별 리드. 현업 사용자는 범위를 확인합니다. Basis와 보안은 환경 구축을 시작합니다.

Explore(보통 2~5개월차). 기능 컨설턴트와 현업 사용자의 부하가 크고, 설계 워크숍이 일정을 좌우합니다. 설계 결정이 나오기 전까지 ABAP과 연동은 가볍습니다. Basis는 샌드박스와 품질 시스템을 준비합니다.

Realize(보통 5~12개월차). 기술 인력의 부하가 큽니다. 구성, 개발, 단위 테스트와 통합 테스트가 이어집니다. ABAP 부하가 정점을 찍습니다. 현업 사용자는 테스트 사이클에 합류합니다. 데이터 팀은 마이그레이션 오브젝트를 만들고 드라이 런을 수행합니다.

Deploy(보통 12~14개월차). 데이터 마이그레이션, Basis, 보안, 변화 관리, 교육의 부하가 큽니다. UAT가 현업의 여력을 소모합니다. 컷오버 리허설에는 한 장소에 모인 팀이 필요합니다. 하이퍼케어 계획이 시작됩니다.

Run(14개월차부터, 하이퍼케어는 보통 30~90일). 소규모 핵심 팀과 두터운 지원 체계. 컨설턴트가 줄어드는 동안 Basis와 애플리케이션 운영 인력이 늘어납니다.

이 단계들을 같은 수요의 구간으로 취급하면 Prepare는 과잉 배치되고, Realize는 인력이 모자라고, Deploy에서는 데이터 마이그레이션 인력이 달리게 됩니다. 단계별 곡선이 계획에서 가장 중요한 모양입니다.

1. Prepare약 11 FTE1~4주차. 리드가 범위를 확정하고 Basis가 환경을 구축합니다
2. Explore약 36 FTE2~5개월차. 기능 인력과 현업 사용자
3. Realize약 56 FTE, 정점5~12개월차. 구축, ABAP 부하가 정점
4. Deploy약 42 FTE12~14개월차. 데이터, Basis, 보안, 변화 관리
5. Run약 12 FTE14개월차부터. 하이퍼케어는 보통 30~90일

끊이지 않는 긴급 상황. 팀이 늘 불을 끄고 있다면, 계획이 현실을 예측하지 못하게 된 것입니다. 한 사람의 결근이 워크스트림 전체를 흔들어서는 안 됩니다.

필요할 때 현업 사용자가 사라집니다. 현업 사용자가 시간을 낼 수 없어 설계 세션과 UAT가 멈춥니다. 일정 지연의 가장 흔한 원인 중 하나입니다. 원인은 거의 늘 같습니다. 시간이 공식적으로 확약된 것이 아니라 가정되었기 때문입니다. 확약이 공식화되지 않으면 운영상의 압박이 언제나 이깁니다.

기술 인력이 너무 얇게 퍼져 있습니다. 소프트웨어 관리에 관한 Gerald Weinberg의 연구는 세 프로젝트에 나뉜 사람이 전체 역량의 약 60%만 내고 나머지는 전환 과정에서 사라진다고 추정했습니다. 미국심리학회(APA)의 작업 전환 연구 요약도 같은 규모의 손실을 보고합니다. 작업 사이를 오가며 생기는 짧은 정신적 차단이 생산 시간의 최대 40%를 앗아갈 수 있다는 것입니다. 계획은 효율적으로 보입니다. 성과는 그렇지 않습니다.

크리티컬 패스가 매주 바뀝니다. 끊임없는 재편성, 늦게 시작하는 워크스트림, 매주 바뀌는 우선순위는 대개 불분명한 범위나 순서가 잘못 잡힌 의존성에서 비롯됩니다. 리소스 계획을 고치기 전에 범위부터 고치십시오.

1. 가짜 가용성. 100%로 잡혀 있는 사람이 월 마감과 운영 지원도 합니다. 주당 몇 시간인지, 달리 무슨 일을 하는지, 직속 관리자가 서면으로 확인했는지 물으십시오.
2. 경계 없는 공유 역할. 한 사람이 솔루션 설계, 테스트, 변화 관리를 동시에 합니다. 직함이 아니라 업무 기준으로 책임을 나누고, 한 사람이 동시에 두 곳에서 핵심이 되게 하지 마십시오.
3. 빠진 현업 사용자 시간. 워크숍이 밀리고 UAT 승인에 몇 주가 더 걸립니다. 시간을 서면으로 확약받아 부서장이 서명하게 하고, 참석을 추적하고, 패턴이 보이면 일찍 에스컬레이션하십시오.
4. 여유 부재. 한 사람의 결근이 워크스트림을 멈춥니다. 단계 수준이 아니라 태스크 수준에서 여유를 두고, 핵심 역할마다 최소 한 명을 교차 교육하십시오.
5. 갱신되지 않는 계획. 킥오프 때 만들고 한 번도 고치지 않습니다. 활발한 딜리버리 중에는 매주 검토하고, 단계 게이트와 연계하며, 현실이 바뀌면 갱신하십시오.

확인된 가용성에서 시작하십시오. 프로젝트가 시작되기 전에 직속 관리자를 찾아가십시오. 주당 시간과 다른 업무를 확인하고 문서로 남기십시오. 프로젝트 도중 가용성이 달라지면 그 기준선이 에스컬레이션의 근거가 됩니다.

단계별로 모양을 잡으십시오. ABAP 개발자의 부하는 Explore와 Realize에서 다릅니다. 현업 사용자는 설계를 위한 Explore와 UAT를 위한 Deploy에서 정점입니다. 평평한 배분은 서류상으로는 균형 잡혀 보이지만 현장에서는 실패합니다.

의존성을 명시적으로 매핑하십시오. 데이터 마이그레이션은 통합 테스트로 이어지고, 통합 테스트는 UAT로, UAT는 컷오버로 이어집니다. 모든 의존성에 담당자, 날짜, 플래그를 두어 지연이 당일에 눈에 보이게 하십시오.

현업 사용자의 시간은 운영위원회 차원에서 지키십시오. 그들의 본업은 계속됩니다. 주당 시간에 대한 소속 부서 경영진의 명시적 승인이 없으면, 운영상의 압박이 닥칠 때 프로젝트를 놓아 버립니다. 부서장에게 그 시간을 요청하는 것은 프로젝트 매니저가 아니라 스폰서여야 합니다.

계획을 매주 갱신하십시오. 2주간 손대지 않은 계획은 아마 틀렸을 것입니다. 계획 대비 실제 가동률을 추적하십시오. 누군가 2주 연속 120%라면, 그 사람이 과부하이거나 계획이 틀렸다는 신호입니다.

이 값들은 출발점으로 쓸 참고용 인원 및 단가 범위입니다. 산업, 범위, 지역, 파트너에 따라 달라집니다. 표는 견적이 아니라 타당성 점검용으로 사용하십시오.

중견 기업 브라운필드(500만~1,500만 달러, 약 12개월)

전형적인 범위: 단일 법인 또는 소규모 그룹, 모듈 서너 개(보통 FI, CO, MM, SD), 표준 프로세스, 제한적인 커스텀 개발.

워크스트림	Prepare	Explore	Realize	Deploy	Run
프로그램 매니저	1	1	1	1	0.5
솔루션 아키텍트	1	1	1	0.5	0
기능 컨설턴트(FI/CO, MM, SD에 한 명 추가)	1	4	4	2	1
ABAP 및 기술	0	1	3	1	0.5
연동	0	0.5	2	1	0.5
Basis	0.5	0.5	1	2	1
보안 및 권한	0	0.5	1	1.5	0.5
데이터 마이그레이션	0	1	2	3	0
테스트 리드	0	0.5	1	1	0
변화 관리 및 교육	0.5	1	1	2	0.5
고객사 업무 분석가	1	4	3	2	1
최대 합계 FTE	5	14	20	17	5

엔터프라이즈 브라운필드(3,000만~8,000만 달러, 15~18개월)

전형적인 범위: 복수 법인, 모듈 여섯에서 아홉 개, 복잡한 연동, 상당한 규모의 커스텀 개발, 여러 국가 롤아웃.

워크스트림	Prepare	Explore	Realize	Deploy	Run
프로그램 매니저 및 PMO	2	2	3	3	1
솔루션 아키텍트(리드와 모듈별)	2	3	3	1.5	0.5
기능 컨설턴트(범위 내 전 모듈)	2	10	12	5	2
ABAP 및 기술	0	3	8	3	1
연동 및 미들웨어	0.5	2	5	2	1
Fiori 및 UI5	0	1	3	1	0.5
Basis	1	1	2	4	2
보안 및 GRC	0.5	1.5	2	3	1
데이터 마이그레이션	0	2	5	6	0.5
테스트	0.5	1	3	4	0
변화 관리 및 교육	1	2	3	5	1
고객사 업무 분석가	2	8	7	5	2
최대 합계 FTE	11	36	56	42	12

역할 및 지역별 일 단가(2024~2025년)

이 값은 급여가 아니라 파트너가 청구하는 전문가별 단가입니다. 대부분의 프로그램이 온쇼어 아키텍트와 오프쇼어 딜리버리를 섞기 때문에, 프로그램 전체의 혼합 단가는 대개 온쇼어 시니어 단가보다 30~50% 낮게 나옵니다.

역할	온쇼어 미국/영국/독일	GCC(UAE/KSA)	니어쇼어(중남미/동유럽)	오프쇼어(인도)
솔루션 아키텍트(시니어)	$2,000~$3,500	$1,500~$2,500	$900~$1,500	$500~$1,000
기능 컨설턴트(시니어)	$1,500~$2,800	$1,200~$2,000	$700~$1,400	$300~$700
기능 컨설턴트(미들)	$1,000~$1,800	$800~$1,400	$500~$900	$200~$500
ABAP 및 기술(시니어)	$1,400~$2,500	$1,000~$1,800	$600~$1,200	$300~$700
연동 전문가	$1,500~$2,800	$1,100~$1,900	$700~$1,300	$350~$800
Basis	$1,400~$2,200	$1,000~$1,800	$600~$1,100	$300~$700
보안 및 GRC	$1,500~$2,500	$1,100~$1,900	$700~$1,300	$350~$800
데이터 마이그레이션	$1,300~$2,200	$1,000~$1,700	$600~$1,100	$300~$700
변화 관리 및 교육 리드	$1,200~$2,000	$900~$1,500	$500~$1,000	$250~$600
주니어 컨설턴트(전 역할)	$800~$1,400	$500~$900	$400~$700	$150~$350

온쇼어, 니어쇼어, 오프쇼어 배분

대부분의 SAP 프로그램은 지역을 섞습니다. 이것은 이분법이 아니라 비용 대 속도의 결정입니다.

미국 민간 부문 프로그램은 보통 FTE 기준으로 30~60%가 온쇼어입니다. 온쇼어는 업무 현장과의 근접성이 중요한 아키텍처, 변화 관리, 업무 분석, 시니어 기능 역할에 집중됩니다. 오프쇼어는 명세하기 쉬운 ABAP, 연동 구축, 데이터 마이그레이션 실행에 집중됩니다. 미국 연방 정부 프로그램은 업무에 따라 미국인(US-person) 제한 때문에 전부 온쇼어인 경우가 많습니다.

GCC 프로그램은 현지 채용 규정과 아랍어 요건 때문에 비중이 올라가 보통 60~70%가 온쇼어입니다. 오프쇼어 업무는 시간대가 겹치는 남아시아 센터 쪽으로 기웁니다. 유럽 프로그램은 다양합니다. 제조업은 온쇼어가 약 50%인 경우가 많고, 공공 부문과 규제 산업은 데이터 상주 요건 때문에 더 높습니다.

흔한 실수는 비용만 기준으로 배분을 최적화하는 것입니다. 80%가 오프쇼어이고 온쇼어 아키텍트가 20%인 팀은 스프레드시트에서는 저렴해 보입니다. 숨은 비용은 매일 반복되는 인수인계 주기와 업무 맥락이 없는 탓에 느려지는 설계 워크숍입니다. 가장 저렴한 팀이 가장 저렴한 프로그램을 만드는 경우는 드뭅니다. 파트너를 비교할 때는 제 SAP 구축 파트너 등급별 가이드에서 단가와 팀 구성이 파트너마다 어떻게 다른지 다룹니다.

한 번 만들고 다시 들여다보지 않는 계획은 계획이 아닙니다. 계획의 모든 가정을 가설로 취급해 실행 첫 주에, 그리고 그 이후 매주 검증하십시오.

SAP 프로젝트에서 리소스 배분 계획이란 무엇이며 왜 중요합니까?

프로젝트에 어떤 사람이 필요한지, 언제, 근무 시간의 얼마만큼 필요한지를 정하고, 그것이 현실과 맞는지 추적하는 일입니다.

SAP 프로젝트는 특정한 개인에게 달려 있습니다. 계정과목표를 이해하는 FI/CO 리드, 레거시 데이터를 아는 마이그레이션 전문가, 현업에 관계망이 있는 변화 관리 리드가 그렇습니다. 이들이 결정적인 순간에 자리를 비우면 작업이 멈추거나 잘못 수행됩니다. 기술적으로 보이는 지연의 상당수는 사실 리소스 문제입니다.

리소스 배분이 부실하면 SAP 프로젝트 지연이 왜 생깁니까?

의존성 때문입니다. 구성 리드가 Realize 도중에 다른 프로젝트로 차출됩니다. 그 사람의 작업이 멈추면 통합 테스트가 지연되고, 이어서 UAT, 컷오버 준비가 지연됩니다. 8주차의 2주 부재가 Go-Live 시점에는 6주 지연이 될 수 있습니다.

초기의 작은 공백이 후반의 큰 지연이 됩니다. 영향이 눈에 보일 즈음에는 복구 비용이 일찍 고쳤을 때의 몇 배가 됩니다.

본업이 있는 현업 사용자가 SAP 프로젝트에 참여하도록 하려면 어떻게 합니까?

프로젝트가 시작되기 전에 직속 관리자로부터 서면 확약을 받으십시오. 주당 시간, 어느 단계에서 가장 필요한지, 가용성이 달라질 때 어떤 승인이 필요한지를 담습니다.

참석 여부는 다른 리소스와 똑같이 추적하십시오. 떨어지면 운영위원회 차원에서 에스컬레이션하십시오. 확약을 집행할 수 있는 것은 부서장이지 프로젝트 팀이 아닙니다.

핵심 인력이 프로젝트 도중에 떠나면 어떻게 대응합니까?

애초에 단일 장애점을 피하십시오. 각 핵심 워크스트림을 계속 굴러가게 할 만큼 이해하는 사람이 최소 한 명 더 있어야 합니다.

누군가 떠나면 그가 아는 것, 즉 문서화되지 않은 결정과 구성의 근거를 즉시 확보하십시오. 대체 인력을 찾는 것보다 이쪽이 더 어려운 경우가 많습니다. 충원 시에는 인수인계 문서, 녹화한 세션, 1주일의 중복 근무가 최소 요건입니다.

리소스 문제는 언제 에스컬레이션해야 합니까?

마음이 편한 시점보다 일찍 하십시오. 지정된 의존성 담당자가 1주일 넘게 연락이 닿지 않을 때, 현업 사용자가 세션을 계속 놓칠 때, 기술 인력의 가동률이 2주간 120%를 넘을 때, 미뤄진 리소스 결정으로 워크스트림이 막혔을 때입니다.

너무 일찍 에스컬레이션하는 비용은 어색한 대화입니다. 너무 늦게 하는 비용은 몇 주의 지연입니다.

여러 프로젝트에 걸친 공유 리소스는 어떻게 다뤄야 합니까?

공유 인력은 압박이 닥치면 다른 일을 우선할 것이라고 가정하십시오. 주 관리자와 구체적인 주당 시간을 합의하고, 그들에게 의존하는 작업에는 여유를 두고, 대체 수단이 없다면 크리티컬 패스에서 빼십시오.

공유 현업 사용자는 요청이 스폰서에게서 나와야 합니다. 프로젝트 매니저가 부서장에게 시간을 요청하면 운영 우선순위에 언제나 밀립니다.