SAP 구축 템플릿: 단계별 SAP Activate 템플릿 세트

SAP Activate 템플릿은 SAP가 S/4HANA 프로그램의 각 단계를 위해 공개하는 구축 템플릿과 액셀러레이터입니다. Prepare의 범위 정의서부터 Deploy의 컷오버 계획까지 포함합니다. SAP Activate Roadmap Viewer에서 찾을 수 있으며, 클라우드 프로그램에서는 SAP Cloud ALM에도 있습니다.

결론부터 말하면, 전부 필요하지는 않습니다. 필요한 것은 열두 개 정도이며, 각각에 이름 있는 담당자와 승인 시점을 정하고 SAP 표준 구조의 약 80%를 유지해야 합니다. 아래 표는 제가 이끌었거나 구해 낸 21개 SAP 프로그램에서 반드시 요구해 온 세트입니다.

템플릿을 찾는 것은 쉽습니다. 어려운 것은 어떤 템플릿을 진지하게 다룰지 아는 일입니다.

제가 승인 완료를 확인하는 SAP 구축 템플릿 세트입니다. 담당자와 각 템플릿이 통과해야 하는 시점을 함께 적었습니다.

단계	템플릿	담당자	승인 기한
Prepare	프로젝트 범위 정의서	프로그램 매니저(스폰서 승인)	Explore 시작 전
Prepare	비즈니스 케이스	CFO 또는 현업 오너	예산 집행 전
Prepare	이해관계자 매트릭스	프로그램 매니저	Explore 워크숍 일정 확정 전
Explore	요구사항 및 핏갭 시트	설계 위원회(현업과 IT)	Realize 시작 전
Realize	구성 로그	기능 리드	각 이관 요청이 QA로 넘어가기 전
Realize	커스텀 개발 대장	개발 리드	모든 오브젝트의 개발 시작 전
Realize	테스트 전략	테스트 매니저	통합 테스트 시작 전
Realize	데이터 마이그레이션 계획	데이터 마이그레이션 리드	첫 모의 로드 전
Deploy	컷오버 계획	컷오버 매니저	최종 리허설 전
Deploy	Go-Live 준비 체크리스트	프로그램 디렉터(스폰서 서명)	Go/No-Go 회의 전
Deploy	하이퍼케어 지원 모델	서비스 딜리버리 리드	Go-Live 전
Run	성능 모니터링 시트	Basis 리드	Go-Live 전

SAP Activate는 Discover, Prepare, Explore, Realize, Deploy, Run의 6단계로 구성됩니다. SAP Best Practices 콘텐츠, 방법론, 가이드 구성을 결합한 것입니다. Discover는 구속력 없는 탐색 단계이므로, 대부분의 고객에게는 계약 전에 끝나고 아래 템플릿은 Prepare부터 시작됩니다.

1. 01Discover대개 계약 체결 전
2. 02Prepare범위 정의서, 비즈니스 케이스, 이해관계자 매트릭스
3. 03Explore요구사항 및 핏갭 시트
4. 04Realize구성 로그, 개발 대장, 테스트 전략, 마이그레이션 계획
5. 05Deploy컷오버 계획, Go-Live 준비, 하이퍼케어
6. 06Run성능 모니터링

모든 템플릿을 해당 게이트 전에 승인

Roadmap Viewer에서 각 로드맵은 단계, 산출물, 태스크로 나뉩니다. 템플릿은 액셀러레이터로 분류되어 있으며, 방법 가이드, 샘플 문서, 체크리스트가 이를 필요로 하는 태스크에 연결되어 있습니다. 단계, 워크스트림, 액셀러레이터로 필터링할 수 있어서, 한 단계의 SAP Activate 산출물을 가져오는 가장 빠른 방법입니다.

자사에 맞게 조정할 때는 표준 구조의 약 80%를 유지하십시오. 바꾸는 것은 자사의 상황을 반영하는 부분뿐입니다. 업종별 요구사항, 규제상 통제, 지역별 특수성입니다. 전부 다시 쓰면 템플릿을 쓰는 이유가 사라집니다.

도구의 변화

단계 구조는 같습니다. 바뀐 것은 그 주변의 도구입니다.

1. 클라우드 프로그램에서는 템플릿이 SAP Cloud ALM에 있습니다. SAP Enterprise Support 고객에게 제공되며, RISE with SAP 같은 SAP 클라우드 구독에도 포함됩니다. Solution Manager 7.2의 메인스트림 유지보수는 2027년 말까지, 일부 기능의 연장 유지보수는 2030년까지입니다.
2. Joule은 방법론 도구 안에 들어와 있습니다. SAP는 2025년에 Roadmap Viewer와 SAP Cloud ALM에 Joule을 추가했습니다. 팀은 태스크 안내나 초안을 요청할 수 있습니다. 그래도 핏갭에 서명하는 사람을 대신하지는 않습니다.
3. 클린 코어에 레벨이 생겼습니다. 2025년 8월 SAP는 A부터 D까지 네 가지 클린 코어 레벨을 도입했습니다. 레벨 A는 릴리스된 API만 사용하고, 레벨 D는 클린하지 않은 상태입니다. 핏갭 시트에는 각 갭이 어느 레벨에 속할지 적는 열이 필요합니다.

이 기초 작업을 건너뛴 프로젝트는 Explore와 Realize에서 대가를 치릅니다. 아래 세 문서는 팀이 구성 작업에 빨리 들어가려고 건너뛰는 문서입니다.

프로젝트 범위 정의서

프로그램에 무엇이 포함되고 무엇이 포함되지 않는지 정의합니다. 3개월째에 누군가 범위를 추가하려 할 때(반드시 그렇게 됩니다), 이 문서가 기준점이 됩니다.

제가 기대하는 항목은 다음과 같습니다.

1. 제목, 스폰서, 프로그램 매니저.
2. 배경: 현재 상태와 변화가 필요한 이유.
3. 숫자로 된 목표. 예를 들어 "결산 주기를 14일에서 5일로".
4. 범위 내 항목: 모듈과 프로세스별(FI/CO, MM/SD 연계, 데이터 마이그레이션, UAT, Go-Live).
5. 범위 외 항목: 범위만큼 명확하게 씁니다(인사, 레거시 보고서 이관, ERP 외 인터페이스).
6. 가정과 제약: 예를 들어 월간 운영위원회에 대한 스폰서의 참석, 고정된 Go-Live 날짜.
7. 단계별 일정. Explore 시작 전에 스폰서와 PMO가 승인합니다.

일정은 현실적인 수준에 맞추십시오. 제 경험상 GROW 프로그램은 6~9개월, RISE는 9~18개월, 브라운필드 전환은 12~18개월, 그린필드는 18~24개월이 걸립니다. 단계별 세부 내용은 제 SAP 구축 일정 가이드에 정리했습니다.

비즈니스 케이스 템플릿

재무팀이 읽을 수 있는 형식으로 비용 편익 분석을 정리합니다. 이 구조를 사용해 첫 제출에서 프로그램 승인을 받은 고객이 여럿 있습니다. 숫자가 명확하고 가정이 문서로 남아 있기 때문입니다.

구조는 다음과 같습니다.

1. 담당자와 요약: 왜 지금인지, 무엇이 바뀌고 무엇이 그대로인지.
2. 문제 정의: 결산 주기의 길이, 수작업 우회 방식, 시스템의 노후도.
3. 제안 접근 방식: 그린필드, 브라운필드 또는 선택적 전환과 범위 요약.
4. 정량화한 효과: 줄어드는 결산 일수, FTE 시간, 오류율, 감사 리스크.
5. 비용과 재원: 구축, 라이선스 또는 구독, 내부 인력 시간, 예비비.
6. 상위 세 가지 리스크와 그 발생 가능성 및 영향.
7. 권고: 진행, 조건부 진행 또는 보류.

제가 지키는 원칙이 하나 있습니다. 작업을 수행할 시스템 통합업체가 이 문서를 써서는 안 됩니다. 그들의 동기는 시작하는 것입니다. 귀사의 동기는 끝내는 것입니다. 효과 모델은 제 SAP 비즈니스 케이스 템플릿에서 더 깊이 다룹니다.

이해관계자 매트릭스

구축의 영향을 받는 모든 사람과 그들의 영향력, 그리고 어떻게 관여시킬지를 정리합니다. 누구에게 주간 보고가 필요하고 누구에게 Go-Live 전 사전 공지가 필요한지 알려 줍니다.

그룹마다 역할, 관심, 영향력, 관여 방식을 기록합니다. 전형적인 구성은 스폰서인 CFO(월간 운영위원회), 기술 책임자인 IT 이사, 핵심 프로세스 오너인 재무 이사, 영향을 받는 사용자인 공장장과 AP/AR 담당자, 그리고 품질 게이트의 내부 감사입니다.

같은 매트릭스로 상위 수준 요구사항을 수집하는 Prepare 워크숍을 계획합니다. 요구사항 번호는 Explore에서 쓸 형식(REQ-001 등)으로 지금 매겨 두어야 원래 요청까지 거슬러 올라가는 추적이 유지됩니다.

Explore는 SAP Best Practices를 기준으로 한 Fit-to-Standard 워크숍에서 설계를 확정하는 단계입니다. SAP 예산이 초과되는 곳도 여기입니다. WRICEF(워크플로, 보고서, 인터페이스, 전환, 개선, 양식) 건수가 이 단계에서 늘어나기 때문입니다.

단계 순서가 무너지게 두지 마십시오. 2023년 유럽 유통 프로젝트에서 고객이 Explore를 건너뛰려 했고, 불완전한 요구사항을 기준으로 3개월 동안 개발했습니다. 이런 재작업이 어떻게 예산으로 이어지는지는 제 SAP 구축 비용 분석에서 보여 드립니다.

요구사항 및 핏갭 시트

요구사항 매핑은 각 비즈니스 요구를 시스템 구성 요소와 테스트 케이스에 연결합니다. 이어서 핏갭 분석이 표준 SAP가 요구를 충족하는 곳과 그렇지 못한 곳을 보여 줍니다.

저는 두 가지를 한 시트에 두고 해결 방식 열을 둡니다. S/4HANA에서는 모든 갭에 명시적인 답이 필요합니다. 표준 구성, 키 유저 확장, 시스템 내 개발자 확장, 또는 SAP BTP 기반의 사이드바이사이드 확장입니다.

요구사항 ID	요구사항	SAP 구성 요소	핏 / 갭	해결 방식	테스트 참조
REQ-001	월 마감 분개 자동화	FI-GL 기간 마감	핏	반복 전표 구성	TC-001
REQ-002	모바일 구매오더 승인	MM 구매, Fiori 승인 앱	S/4HANA에서 핏	표준 앱과 워크플로 구성	TC-003
REQ-003	회사 간 청구 자동화	SD 청구, FI 연계	핏	회사 간 청구 구성	TC-010
REQ-004	개인정보 규정에 따른 데이터 보관	Information Lifecycle Management	갭	ILM 정책 구성	TC-025
REQ-005	실시간 코스트 센터 보고	CO, 임베디드 분석 또는 SAC	갭	임베디드 분석 또는 SAC 라이브 연결	TC-030
REQ-006	공급업체 셀프서비스 포털	SAP Ariba 또는 공급업체 포털	갭	Ariba 연계	TC-020

비용을 아끼는 곳이 바로 여기입니다. 2023년 유럽 제조업체의 ECC에서 S/4HANA로의 마이그레이션에서 핏갭 워크숍으로 계획된 개선 개발이 35% 줄었고, 절감액은 수십만 달러 규모에 달했습니다.

이 시트가 제대로 작동하려면 두 가지 원칙이 필요합니다. 벤더가 범위를 통제해서는 안 됩니다. 벤더가 개발로 표시하는 모든 갭은 벤더에게 청구 가능한 작업이기 때문입니다. 현업과 IT로 구성된 설계 위원회가 클린 코어 결정을 맡고, SAP 코드 수정에는 이름 있는 승인자가 필요합니다. 레벨에 대해서는 제 SAP 클린 코어 전략에서 설명합니다.

구축 단계입니다. 이 템플릿들은 모든 구성 결정, 모든 개발, 모든 테스트 결과의 감사 추적이 됩니다.

구성 로그

모든 시스템 변경을 기록합니다. 누가, 왜 변경했고 어떤 이관 요청에 포함했는지입니다. 나중에 무언가 고장 나면 원인을 며칠이 아니라 몇 분 만에 추적할 수 있습니다.

각 항목에 필요한 내용은 다음과 같습니다.

1. 구성 ID와 모듈(예: MM-CONF-001).
2. 구성 경로와 변경한 오브젝트.
3. 영향을 받는 비즈니스 프로세스와 변경 이유.
4. 구성한 사람과 일시.
5. 이관 요청 번호.
6. 주요 값의 변경 전과 변경 후.
7. 연결된 테스트 케이스와 승인 상태.

커스텀 개발 대장

모든 커스텀 오브젝트는 누군가 코드를 쓰기 전에 한 행을 받습니다. ID, 설명, 개발자 역할, 공수, 상태, 확장 유형입니다. 클린 코어를 지키게 하는 것은 확장 유형 열입니다.

2024년 유럽 유통 기업의 S/4HANA 구축에서 이 대장으로 계획된 커스텀 코드가 30% 줄었습니다. 표준 SAP로 충분한 부분이 어디인지 드러났기 때문입니다.

테스트 전략

모든 테스트를 한곳에 모읍니다. 누가 무엇을, 언제, 어떤 환경에서, 어떤 기준으로 테스트하는지입니다.

1. 범위: 대상 모듈 전반의 기능, 통합, 회귀, 성능 테스트와 UAT.
2. 환경: 개발, QA, UAT, 운영 전 환경.
3. 도구: SAP Cloud ALM 또는 기존 도구의 테스트 관리와 자동화 및 성능 테스트 도구 명시.
4. 결함 수명 주기. 심각도와 우선순위는 분류 단계에서 정합니다.
5. 종료 기준: 모든 치명적 결함 해결, UAT 승인, 사전에 합의한 회귀 테스트 통과율.

SAP Activate의 Realize는 통합 테스트와 사용자 인수 테스트로 끝납니다. 종료 기준은 결과가 나올 때가 아니라 테스트 시작 전에 쓰십시오.

데이터 마이그레이션 계획

데이터 마이그레이션은 가장 큰 상처를 남기기 쉬운 워크스트림입니다. 계획에는 범위(비즈니스 파트너, 자재, 미결 항목, 잔액), 원천 시스템, 매핑 규칙, 도구(SAP S/4HANA 마이그레이션 콕핏), 모의 로드, 검증, 롤백이 들어갑니다.

팀이 계획을 소홀히 하는 부분은 검증입니다. 첫 모의 로드 전에 레코드 건수, 샘플링, 잔액 대사 방식을 합의하십시오.

SAP Activate에서 Deploy는 운영 환경 준비, 컷오버, Go-Live, 하이퍼케어를 다룹니다. 이 템플릿들이 혼란스러운 주말을 관리되는 이벤트로 바꿉니다.

SAP 컷오버 계획 템플릿

컷오버 계획은 시스템 중단 시간대를 시간 단위로 짭니다. 모든 태스크에 담당자, 시작 시각, 선후 관계가 있습니다. 새벽 2시에 다음에 무엇을 해야 할지 몰라 서 있는 사람이 있어서는 안 됩니다.

태스크 목록을 쓰기 전에 네 가지를 합의하십시오. 시간대(예: 금요일 22:00부터 토요일 06:00까지), 롤백 기준, 레거시 시스템을 얼마나 빨리 재가동할 수 있는지, 그리고 새 시스템이 작동함을 증명하는 스모크 테스트입니다. 그다음 순서는 다음과 같습니다.

단계	태스크	담당자	시작	상태
1	레거시 시스템 동결(전기 중지)	Basis	22:00	대기
2	최종 데이터 추출과 대사	데이터 마이그레이션 리드	22:30	대기
3	운영 마이그레이션 로드	데이터 마이그레이션 리드	23:00	대기
4	남은 이관 요청 반입	Basis	00:30	대기
5	인터페이스와 네트워크 경로 전환	통합 리드	01:30	대기
6	스모크 테스트: FI 전기, 입고, 판매오더	QA 리드	02:00	대기
7	현업 확인과 Go/No-Go	프로그램 디렉터	03:00	대기
8	현업 사용자에게 시스템 개방	Basis	06:00	대기

Go-Live 준비 체크리스트

실제로 전환할 준비가 되었는지 판단합니다. 모든 항목에 증거와 함께 예 또는 아니요로 답합니다.

1. 기능: 핵심 프로세스와 모듈 간 시나리오 테스트 완료, 미해결 P1·P2 결함 목록화, 키 유저의 준비 완료 확인.
2. 데이터: 마스터 데이터와 트랜잭션 데이터 로드 및 대사 완료, 대사 보고서 승인, 레거시 동결 확인.
3. 재무: 모든 회사 코드와 법인에 대해 기간 마감 구성 테스트 완료.
4. 기술: 컷오버 계획 승인, 이관 요청 운영 반영, 배치 작업 일정 등록, 모니터링 구성.
5. 사람: 교육 범위, 접근 역할 검증, 하이퍼케어 인력 배치.
6. 의사결정: 치명적 리스크와 완화 방안, Go / No-Go / 조건부, 이름과 역할과 날짜로 승인.

재무 항목이 있는 데는 이유가 있습니다. 2024년 GCC 유통 프로그램에서 Go-Live 검토 중에 25개 전체 법인에 걸친 재무 마감 구성 문제가 Go-Live 이틀 전에 발견되었습니다. 그대로 갔다면 수십만 달러 규모의 복구 작업이 필요했을 것입니다.

저는 이 평가를 근거로 두 프로그램에서 2주 연기를 권고했습니다. 이 평가는 바로 그런 용도입니다.

하이퍼케어 지원 모델

가동 후 이슈를 어떻게 처리할지 정리합니다. 이것이 없으면 모든 문제가 P1이 됩니다.

1. 하이퍼케어 기간과 지원 범위. 예를 들어 4주, 연장 근무 시간 포함.
2. 지원 채널: 인시던트 대기열, 채팅 채널, P1용 전화 회의.
3. 지원 계층: 서비스 데스크, 기능 컨설턴트, 그다음 Basis와 개발.
4. 심각도별 응답 및 해결 시간.
5. 종료 기준: 미해결 P1·P2 이슈 없음, 운영 지원 조직으로의 인수인계 서명 완료.

Run은 가동 중인 시스템의 지원과 관리입니다. 대부분의 팀이 너무 일찍 내려놓는 템플릿은 성능을 지켜보는 템플릿입니다.

성능 모니터링 시트

시스템 상태를 매일 추적해 사용자가 불만을 제기하기 전에 속도 저하를 발견합니다. 2024년 유럽 금융 서비스 프로그램에서 이 시트가 하이퍼케어 3주 차에 데이터베이스 문제를 잡아냈습니다. 그대로 두었다면 월 마감 중에 시스템이 멈췄을 것입니다.

제가 추적하는 지표입니다. 각각 목표, 경보 임계값, 담당자를 둡니다.

1. 대화 응답 시간(95번째 백분위수): 목표 1초 미만, 2초에서 경보, Basis.
2. 백그라운드 작업: 100% 일정대로 완료, 실패 시 즉시 경보, 운영 리드.
3. 데이터베이스 쿼리 시간: 목표 200ms 미만, 500ms에서 경보, 데이터베이스 관리자.
4. 인터페이스 오류율: 1% 미만, 2%에서 경보, 통합 리드.
5. 월 마감 작업 실행 시간: 합의된 시간 내, 기준선 대비 30% 초과 시 경보, 재무 운영.

SAP Activate는 단계별 체크포인트로 품질 게이트를 로드맵에 넣어 두었습니다. 설정 방법은 제 SAP 품질 게이트 가이드에서 다룹니다. 여기서는 게이트에 왜 실질적인 힘이 있어야 하는지 설명합니다.

각 게이트에 통과와 실패 기준을 정하십시오. "회귀 테스트의 95% 통과." "모든 FI 통합 시나리오가 녹색." 이런 기준이 있어야 품질과 상관없이 날짜에 맞춰 가동하려는 현업의 요구 앞에서 선을 지킬 수 있습니다.

2024년 유럽 제조업 프로그램에서 통합 테스트 통과율이 74%일 때 품질 게이트가 우리를 멈춰 세웠습니다. 우리는 버텼고, 문제를 고쳤고, 2주 뒤에 가동했습니다. 가동 후 첫 달의 지원 티켓은 비슷한 프로그램에서 흔히 보는 수준의 절반이었습니다.

경영진 승인도 형식적인 절차가 되어서는 안 됩니다. 앞서 말한 GCC 유통의 재무 마감 문제는 바로 그 검토에서 발견되었습니다. 스폰서가 전화 한 통으로 뒤집을 수 있는 게이트는 게이트가 아닙니다. 게이트를 면제할 수 있는 사람이 누구인지 필요해지기 전에 적어 두십시오.

이 템플릿들을 둘러싼 전체 프로세스는 제 단계별 SAP 구축 가이드를 참고하십시오.

이 가이드는 비즈니스 케이스부터 가동까지 모든 주제를 연결한 SAP 구축 가이드의 일부입니다.

SAP Activate 템플릿은 어디에서 다운로드할 수 있습니까?

me.sap.com/roadmapviewer의 SAP Activate Roadmap Viewer에서 받을 수 있습니다. 귀사의 배포 방식에 맞는 로드맵을 연 다음 단계나 액셀러레이터로 필터링하면 각 태스크의 템플릿, 가이드, 체크리스트를 볼 수 있습니다.

클라우드 프로그램에서는 같은 콘텐츠를 SAP Cloud ALM에서도 쓸 수 있으며, 태스크와 산출물을 프로젝트 기준으로 추적할 수 있습니다.

SAP Activate 각 단계의 산출물은 무엇입니까?

Prepare는 범위, 계획, 거버넌스, 비즈니스 케이스를 산출합니다. Explore는 Fit-to-Standard 결과, 요구사항과 핏갭 백로그, 솔루션 설계를 산출합니다. Realize는 통합 테스트와 사용자 인수 테스트를 포함해 구성과 테스트를 마친 시스템을 산출합니다.

Deploy는 컷오버, Go-Live, 하이퍼케어를 수행합니다. Run은 가동 중인 시스템의 지원과 개선을 다룹니다.

가장 중요한 템플릿은 SAP Activate의 어느 단계에 있습니까?

Prepare입니다. 범위 정의서, 비즈니스 케이스, 이해관계자 매트릭스가 이후의 모든 결정을 정하며, 팀이 구성 작업에 빨리 들어가려고 건너뛰는 것도 이 문서들입니다.

Explore가 바로 뒤를 잇습니다. 핏갭 시트가 WRICEF 건수를 정하고, 예산이 초과되는 곳이 바로 거기이기 때문입니다.

SAP Activate 템플릿을 맞춤화할 수 있습니까?

예. 표준 구조의 약 80%를 유지하고 귀사에 고유한 부분만 바꾸십시오. 제약 업계의 검증 규칙, 공공 부문 조달, SOX 통제 같은 것입니다. 이런 변경은 Deploy가 아니라 Prepare 초기에 하십시오.

맞춤화로 단계 순서, 품질 게이트, Go-Live 준비 평가를 없애서는 안 됩니다.

SAP 컷오버 계획 템플릿에는 무엇이 들어가야 합니까?

시스템 중단 시간대의 시간별 태스크 목록입니다. 모든 태스크에 담당자, 시작 시각, 선후 관계가 있어야 합니다. 태스크 목록보다 먼저 시간대, 롤백 기준, 레거시 시스템 재가동에 필요한 시간, 스모크 테스트를 합의하십시오.

컷오버가 시작되기 전에 누가 언제까지 롤백을 결정할지 합의하십시오. 합의된 기준 없이 새벽 4시에 내리는 롤백 결정이 가동 후 문제의 시작입니다.

SAP Go-Live 준비 체크리스트에는 무엇이 있습니까?

기능, 데이터, 재무, 기술, 사람의 준비 상태입니다. 각각 증거와 함께 예 또는 아니요로 답하고, 이름과 날짜가 기록된 Go / No-Go 결정을 더합니다.

Go-Live 전에 모든 법인의 기간 마감 구성을 테스트하십시오. 수십만 달러 규모의 복구 작업을 막아 줄 가능성이 가장 큰 점검입니다.

SAP Activate 템플릿은 그린필드와 브라운필드 모두에 쓸 수 있습니까?

예. 차이는 주로 Explore에 있습니다. 브라운필드 전환은 구성을 그대로 가져가므로, 핏갭은 바꿔야 할 것과 표준 S/4HANA가 이제 대체할 수 있는 커스텀 코드에 집중합니다. 그린필드 프로그램은 SAP Best Practices에서 시작합니다.

컷오버 계획도 다릅니다. 시스템 전환은 그린필드 데이터 로드와 다른 기술적 순서를 따르기 때문입니다.