SAP 구축 템플릿: 단계별 가이드

SAP Activate는 S/4HANA 프로그램의 거의 모든 산출물에 대한 템플릿을 제공합니다. SAP Activate Roadmap Viewer에서 찾을 수 있고, 클라우드 프로그램에서는 SAP Cloud ALM 안에도 있습니다. 찾는 일은 쉽습니다. 어느 것을 진지하게 다뤄야 하는지 아는 것이 어렵습니다.

이 가이드는 구축을 준비하는 프로그램 매니저, PMO 리드, 스폰서를 위한 것입니다. 단계마다 제가 반드시 요구하는 템플릿을 다루고, 각각의 실제 레이아웃을 보여 드리며, 팀들이 어디서 대충 넘어가는지 짚습니다. 킥오프까지 일주일이 남았다면 범위 정의서와 이해관계자 매트릭스부터 작성하십시오. 이후의 모든 것이 이 두 가지에 기댑니다.

제조, 유통, 금융 서비스에서 제가 맡았던 ECC와 S/4HANA 프로그램 전반에서 패턴은 일관됩니다. 템플릿을 따르는 팀은 문제를 더 일찍 잡아냅니다. 템플릿을 선택 사항인 서류 작업으로 취급하는 팀은 프로젝트 중반에야 알게 됩니다. 문서로 남기지 않은 모든 결정이 범위 분쟁으로 변해 있다는 사실을요.

제가 서명이 끝난 상태로 확인하고 싶은 템플릿 세트입니다. 각 템플릿의 담당자와 통과해야 하는 시점을 함께 적었습니다.

단계	템플릿	담당자	이 시점 전에 서명
Prepare	프로젝트 범위 정의서	프로그램 매니저(스폰서 승인)	Explore 시작 전
Prepare	비즈니스 케이스	CFO 또는 비즈니스 오너	자금 집행 전
Prepare	이해관계자 매트릭스	프로그램 매니저	Explore 워크숍 일정 확정 전
Explore	요구사항 및 Fit-Gap 시트	솔루션 아키텍트와 프로세스 오너	Realize 시작 전
Realize	구성 로그	기능 리드	각 트랜스포트가 QA로 이동하기 전
Realize	커스텀 개발 대장	개발 리드	어떤 오브젝트든 개발에 착수하기 전
Realize	테스트 전략	테스트 매니저	시스템 통합 테스트 시작 전
Realize	데이터 마이그레이션 계획	데이터 마이그레이션 리드	첫 모의 로드 전
Deploy	컷오버 계획	컷오버 매니저	최종 리허설 전
Deploy	Go-Live 준비도 평가	프로그램 디렉터(스폰서 서명)	Go/No-go 회의 전
Run	하이퍼케어 지원 모델	서비스 딜리버리 리드	Go-Live 전
Run	성능 모니터링 시트	Basis 리드	Go-Live 전

Activate는 Discover, Prepare, Explore, Realize, Deploy, Run의 여섯 단계로 이뤄집니다. SAP Best Practices 콘텐츠, 가이드형 구성, 애자일 딜리버리 방식을 결합한 방법론입니다. 대부분의 고객은 계약 서명 전에 Discover를 마치므로 아래 템플릿은 Prepare부터 시작합니다.

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

모든 템플릿이 각 게이트 전에 서명 완료

단계 순서는 선택 사항이 아닙니다. 일부를 건너뛰려던 한 유통업체와 함께 일한 적이 있는데, 결국 3개월 치 작업을 다시 했습니다. 모든 품질 게이트에는 이유가 있습니다.

템플릿을 가져다 쓸 때는 표준 구조의 약 80%를 유지하십시오. 산업 요건, 규제 통제, 지역별 특성처럼 자기 상황을 반영하는 부분만 바꿉니다. 전부 다시 쓰면 템플릿의 취지가 사라집니다.

2026년에 도구 측면에서 달라진 점

Activate의 구조는 예전과 같습니다. 그 주변의 도구가 움직였습니다.

1. 클라우드 프로그램에서는 SAP Cloud ALM이 템플릿을 보관합니다. SAP Solution Manager의 후속 제품이며, SAP Enterprise Support와 RISE with SAP 같은 클라우드 구독에 포함됩니다. 범위, 요구사항, 테스트 계획, 컷오버 작업을 그 안에 두고 서로 추적성을 확보할 수 있습니다. Solution Manager 7.2는 2027년 말에 표준 유지보수가 끝나고, 일부 기능은 2030년까지 연장 유지보수가 제공됩니다. 따라서 기존 온프레미스 환경에 남은 시간은 10년이 아니라 몇 년입니다.
2. 이제 방법론 도구 안에 Joule이 들어 있습니다. SAP는 2025년에 Activate Roadmap Viewer와 SAP Cloud ALM에서 Joule을 쓸 수 있게 했습니다. 팀은 로드맵을 바탕으로 작업 안내를 요청하거나 콘텐츠 초안을 작성할 수 있습니다. 첫 초안은 빨라집니다. 그러나 Fit-Gap에 서명하는 사람을 대신하지는 못합니다.
3. 클린 코어는 이제 레벨이 있는 설계 규칙입니다. 2025년 8월 SAP는 3단계 확장성 모델을 A에서 D까지의 네 가지 클린 코어 레벨로 대체했습니다. 레벨 A는 SAP BTP에서든 ABAP Cloud로 시스템 안에서든 공개된 API만 씁니다. 레벨 D는 전혀 클린하지 않습니다. Fit-Gap 템플릿에는 각 갭이 어디에 안착할지 적는 열이 필요합니다.
4. Public Edition은 Fit-Gap의 폭을 좁힙니다. SAP는 이제 S/4HANA Cloud Public Edition을 SAP Cloud ERP로 내놓고, 중견 규모 기업에는 SAP GROW로 판매합니다. 같은 여섯 단계가 적용되지만 산출물은 더 가볍고, 공개된 API를 통한 확장만 허용되므로 "갭" 열에 들어갈 수 있는 답이 줄어듭니다.

이 기초 작업을 건너뛴 프로젝트는 Explore와 Realize에서 대가를 치릅니다.

프로젝트 범위 템플릿

프로젝트에 포함되는 것과 포함되지 않는 것을 정의합니다. 3개월 뒤 누군가 범위를 추가하려 할 때(반드시 그럽니다) 이 문서가 기준점이 됩니다. SAP 프로젝트 차터는 이 문서 위에 놓이며 거버넌스 세부 사항을 담습니다.

항목	세부 내용
제목, 스폰서, PM	SAP S/4HANA Finance 구축; CFO; 지명된 시니어 PM
배경	현재 상태와 변화의 동인
목표	결산 주기를 14일에서 5일로 단축; 수작업 대사 제거
범위 내	FI/CO, MM/SD 통합, 데이터 마이그레이션, UAT, Go-Live
범위 외	HR 모듈, 레거시 리포트 마이그레이션, ERP 이외의 서드파티 통합
가정	경영진 스폰서가 월간 SteerCo에 참석 가능; 테스트 데이터는 6주 차까지 합의
제약	Go-Live 날짜 고정; 구성은 내부 인력만 투입
산출물	구성 완료된 시스템, 테스트 계획, 컷오버 계획, 교육 자료
일정	Prepare: 1~4주 차; Explore: 5~10주 차; Realize: 11~26주 차
승인	Explore 시작 전에 프로젝트 스폰서와 PMO 서명 필요

비즈니스 케이스 템플릿

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

제가 지키는 규칙이 하나 있습니다. 실제로 작업을 수행할 시스템 통합 업체(SI)가 이 문서를 쓰면 안 됩니다. 그쪽의 동기는 시작하는 것이고, 고객의 동기는 끝내는 것입니다. 효익 모델은 제 SAP 비즈니스 케이스 템플릿에서 더 깊이 다룹니다.

항목	세부 내용
담당자와 요약	CFO 또는 프로그램 디렉터; 왜 지금인지, 무엇이 바뀌고 무엇이 그대로인지
문제 정의	구체적인 운영상의 문제(결산 주기 길이, 수작업 우회, 시스템 노후도)
제안하는 접근 방식	Greenfield / Brownfield / Selective, 범위 요약 포함
효익	정량화: 결산 주기 단축 일수, FTE 절감, 오류율 감소, 감사 리스크 감소
비용과 재원	구축, 라이선스 또는 구독, 내부 인력 투입 시간, 예비비; 예산 출처
리스크	상위 3개, 발생 확률과 영향도 포함
권고	진행 / 조건부 진행 / 보류, 근거 포함

이해관계자 식별 매트릭스

구축의 영향을 받는 모든 사람과 그들의 영향력 수준을 정리합니다. 누구에게 주간 보고가 필요하고 누구에게는 Go-Live 전에 알려 주기만 하면 되는지 한눈에 보입니다.

이해관계자	역할	관심사	영향력	참여 방식
그룹 CFO	경영진 스폰서	프로그램 ROI, 결산 개선	높음	월간 SteerCo, 주간 서면 보고
IT 디렉터	기술 책임자	시스템 안정성, 통합, 보안	높음	주간 프로그램 보드, Realize 기간에는 매일
재무 디렉터	핵심 프로세스 오너	FI/CO 설계, 결산 프로세스	높음	Explore 워크숍, UAT 서명
공장장	영향받는 사용자	MM/PP 프로세스 변화	중간	월간 변화 커뮤니케이션, UAT 참여
최종 사용자(AP/AR)	실무 담당자	트랜잭션 수준의 변화	낮음	교육, 하이퍼케어 지원
내부 감사	거버넌스	추적성, 통제, 컴플라이언스	중간	품질 게이트에서 산출물 검토

같은 매트릭스로 부서별 상위 수준 요구사항을 수집하는 Prepare 워크숍도 계획하십시오. 그 요구사항에는 Explore에서 쓸 형식(REQ-001 등)으로 번호를 매기십시오. 그러면 나중에 번호를 다시 매길 일이 없고, 최초 요청까지 거슬러 올라가는 추적도 살아남습니다.

Explore에서 구축의 모양이 잡힙니다. 이 템플릿들은 SAP가 기본으로 제공하는 것과 현업이 필요로 하는 것 사이의 간극을 드러냅니다.

요구사항 매핑 및 Fit-Gap 템플릿

요구사항 매핑은 현업의 필요를 부서별로 정리하고, 각각을 시스템 구성 요소와 테스트 케이스까지 추적합니다. 이를 건너뛰고 아무도 쓰지 않는 시스템을 얻은 회사들을 봤습니다. 현업이 말한 내용이 아니라 컨설턴트가 가정한 내용으로 구축했기 때문입니다.

Fit-Gap 분석은 이어서 SAP 표준이 각 요구를 어디까지 충족하고 어디서 못 미치는지 보여 줍니다. 제 고객 대부분에게 눈이 번쩍 뜨이는 경험입니다. 비싼 커스텀 코드 대신 표준 기능을 쓸 수 있다는 것을 팀이 깨닫는 순간을 지켜보는 것이 좋습니다.

저는 둘을 한 시트에 두고 해결 경로를 적는 열을 하나 둡니다. S/4HANA에서는 모든 갭에 명시적인 답이 있어야 합니다. 표준 구성, 키 유저 확장, 시스템 내 개발자 확장, 또는 SAP BTP의 사이드 바이 사이드 확장입니다. SAP 코드를 직접 고치는 기존 방식의 수정은 가장 비싼 답이므로 지명된 승인자가 있어야 합니다.

Req ID	요구사항	SAP 구성 요소	Fit / Gap	해결 경로	테스트 참조
REQ-001	월 마감 분개 자동화	FI-GL, 기말 결산	Fit	반복 전표 템플릿 구성	TC-001
REQ-002	Fiori를 통한 구매 오더 승인	MM 구매, Fiori 승인 앱	Gap(ECC에는 없음)	S/4HANA 표준 앱과 워크플로 구성	TC-003
REQ-003	인터컴퍼니 청구 자동화	SD 청구, FI 연동	Gap	인터컴퍼니 청구 구성	TC-010
REQ-004	배치 잡 모니터링	Application Jobs 앱	Fit	표준 앱	TC-015
REQ-005	공급업체 셀프서비스 포털	SAP Ariba 또는 공급업체 포털	Gap	Ariba 연동	TC-020
REQ-006	GDPR을 준수하는 데이터 아카이빙	ILM, 데이터 아카이빙	Gap	ILM 정책 구성	TC-025
REQ-007	실시간 코스트 센터 리포팅	CO, 임베디드 분석 또는 SAC	Gap	임베디드 분석 또는 SAC 라이브 연결	TC-030
REQ-008	동시 사용자 500명 지원	HANA 사이징	Gap(300명으로 테스트)	사이징 검토와 인프라 증설	TC-035

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

구성 추적 템플릿

모든 시스템 변경을 기록합니다. 누가, 왜, 어느 트랜스포트에 담아 변경했는지입니다. 나중에 무언가 깨졌을 때 며칠이 아니라 몇 분 만에 원인을 추적할 수 있습니다.

1. 구성 ID와 모듈: [예: MM-CONF-001, MM]
2. IMG 경로와 구성 오브젝트: [예: 테이블 T161, PO 문서 유형]
3. 목적과 영향을 받는 비즈니스 프로세스
4. 구성 담당자와 날짜
5. 트랜스포트 요청 번호: [예: DEVK900123]
6. 주요 값: 변경 전과 변경 후
7. 연결된 테스트 케이스
8. 검증 및 승인 상태

커스텀 개발 대장

모든 커스텀 오브젝트는 누가 코드를 쓰기 전에 한 행을 갖습니다. 제 고객 한 곳은 표준 SAP로 충분한 부분이 대장에 드러난 덕분에 커스텀 코드를 30% 줄였습니다.

Dev ID	오브젝트	설명	개발자	공수(시간)	상태	확장 유형
CD-001	Fiori 타일: 코스트 센터 개요	재무팀용 실시간 CO 리포팅 타일	Fiori 개발자	12	완료	개발자 확장
CD-002	인터컴퍼니 청구 리포트	IC 대사용 리포트	ABAP 개발자	20	진행 중	개발자 확장
CD-004	공급업체 지급 상태 앱	AP 지급 조회용 Fiori 앱	BTP 개발자	10	QA 대기	BTP 사이드 바이 사이드
CD-005	입고 알림	입고 전기 시 이메일 트리거	통합 개발자	24	계획됨	이벤트 기반, BTP

테스트 전략 템플릿

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

항목	세부 내용
범위	범위 내 모듈 전반의 기능, 통합, 회귀, 성능, UAT(침투 테스트는 정보보안팀 담당)
환경	DEV, QA, UAT(운영 이전 환경), 최종 검증용 스테이징
도구	SAP Cloud ALM 또는 Jira/Xray의 테스트 관리; Tricentis Tosca 등을 이용한 자동화; JMeter 또는 LoadRunner를 이용한 성능 테스트
결함 수명 주기	신규, 진행 중, 해결, 검증, 종결; 심각도와 우선순위는 분류 시점에 지정
종료 기준	모든 치명적 결함 종결; UAT 서명 수령; 회귀 테스트 통과율 95% 이상; 성능 기준 충족

데이터 마이그레이션 계획 템플릿

데이터 마이그레이션은 가장 크게 다칠 수 있는 워크스트림입니다. 이 템플릿은 데이터 품질 문제가 컷오버 도중이 아니라 그 전에 드러나도록 작업을 단계로 나눕니다. 이를 건너뛰면 무엇이 잘못되는지는 데이터 마이그레이션 실패 패턴 글에서 다룹니다.

항목	세부 내용
범위	고객 마스터, 공급업체 마스터, 미결 항목, 자재 마스터, 재고 잔액, 코스트 센터 계층
원천 시스템	ECC 6.0 EHP 7(주 시스템); 레거시 HR 시스템(직원 코스트 센터 배정)
대상 시스템	S/4HANA(현재 릴리스)
매핑과 규칙	고객과 공급업체는 Business Partner로; 코스트 센터는 새 계층으로; 유효하지 않은 은행 정보 제거; 중복 병합
마이그레이션 도구	SAP S/4HANA Migration Cockpit(주 도구); 커스텀 오브젝트용 Migration Object Modeler; 사전 처리용 스크립트
로드 전략	QA에서 모의 로드; 델타 마이그레이션과 대사; 운영 컷오버
검증 방식	원천에서 대상까지 레코드 건수 대조; 10% 무작위 샘플링; 잔액 대사 리포트
롤백 계획	컷오버 전 백업; 레거시 시스템은 48시간 대기

Deploy 단계는 가동에 들어가는 때입니다. 이 템플릿들은 혼란스러운 주말을 관리되는 이벤트로 바꿉니다.

컷오버 계획 템플릿

블랙아웃 윈도를 시간 단위로 그립니다. 모든 작업, 모든 담당자, 모든 시작 시각입니다. 새벽 2시에 팀원들이 다음에 무엇을 해야 할지 몰라 서성이는 일은 없어야 합니다.

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

단계	설명	담당	시작 시각	상태
1	ECC 시스템 동결(전기 금지)	Basis	22:00	대기
2	최종 데이터 추출 및 대사	데이터 마이그레이션 리드	22:30	대기
3	운영 마이그레이션 로드 실행	DBA	23:00	대기
4	나머지 트랜스포트를 운영에 임포트	Basis	00:30	대기
5	DNS와 로드 밸런서를 S/4HANA로 전환	네트워크	01:30	대기
6	스모크 테스트: FI 전기, 입고, 판매 오더	QA 리드	02:00	대기
7	현업 확인 및 Go/No-go 결정	프로그램 디렉터	03:00	대기
8	현업 사용자에게 시스템 개방	Basis	06:00	대기

Go-Live 준비도 평가

실제로 전환할 준비가 되었는지 판단합니다. 이 평가를 근거로 Go-Live를 미룬 고객이 있었고, 그들은 나중에 고마워했습니다.

영역	점검 항목(각 항목은 증빙과 함께 예 또는 아니요로 답변)
기능	핵심 프로세스 테스트 완료; 모듈 간 시나리오 완료; 미결 P1/P2 결함 목록화; 키 유저의 준비 완료 확인
데이터	마스터 데이터 로드 완료; 트랜잭션 데이터 검증; 대사 리포트 승인; 레거시 동결 확인
기술	컷오버 계획 승인; 트랜스포트 운영 반영; 배치 잡 일정 등록; 모니터링 구성
인력	교육 이수율(%); 접근 역할 검증; 하이퍼케어 팀 배치 완료; 지원 계획 공지
의사결정	중대 리스크와 완화 조치 목록화; Go / No-go / 조건부; 이름, 역할, 날짜와 함께 승인

Go-Live 이후에는 일의 모양이 바뀝니다. 이 템플릿들은 하이퍼케어를 거쳐 안정 운영 상태에 이르기까지 시스템과 팀을 이끕니다.

구축 후 지원 템플릿

가동 후 이슈를 처리하는 방식을 정리합니다. 이것이 없으면 모든 문제가 P1이 됩니다.

항목	세부 내용
하이퍼케어 기간	Go-Live 후 1~4주 차: 24/7 대응
지원 채널	ServiceNow 인시던트 큐(주 채널); 전용 채팅 채널; P1 이슈용 전화 브리지
지원 단계	1: 서비스 데스크(비밀번호, 화면 탐색, 알려진 이슈); 2: 기능 컨설턴트(프로세스 문의, 소규모 구성); 3: Basis와 개발(시스템 오류, 성능, 인터페이스)
SLA(응답 / 해결)	치명 15분 / 2시간; 높음 30분 / 4시간; 보통 4시간 / 1일; 낮음 1일 / 3일
모니터링	SAP Cloud ALM 또는 Solution Manager; 일일 오류 로그 검토
종료 기준	미결 P1/P2 이슈 없음; 모든 인시던트 문서화; 최종 인수인계 서명

성능 모니터링 템플릿

시스템 상태를 날마다 지켜보고, 사용자가 불평하기 전에 느려짐을 포착하게 해 줍니다. 최근 한 회사가 이 방법으로 데이터베이스 문제를 잡아내도록 도왔는데, 월 마감 중에 시스템을 다운시켰을 문제였습니다.

지표	목표	도구	경보 임계값	담당
다이얼로그 응답 시간(95번째 백분위수)	1초 미만	ST03 / SAP Cloud ALM	2초	Basis 팀
백그라운드 잡 완료	일정 대비 100%	SM37 / Application Jobs	실패한 잡 하나라도	운영 리드
데이터베이스 쿼리 시간	200ms 미만	SAP HANA cockpit	500ms	DBA
시스템 가용성	99.5% 초과	SAP Cloud ALM	99% 미만	인프라
인터페이스 오류율	1% 미만	SAP Integration Suite 모니터링	2%	미들웨어 리드
로그인 성공률	98% 초과	보안 감사 로그	95% 미만	보안 리드
월 마감 잡 실행 시간	합의된 윈도 이내	잡 스케줄러	기준선 대비 30% 초과	재무 운영

품질 게이트는 한 단계의 문제가 다음 단계에서 값비싼 재작업으로 번지는 것을 막습니다. 설정 방법은 제 SAP 품질 게이트 가이드에서 다룹니다. 여기서는 왜 중요한지를 말씀드립니다.

Go-Live 전 경영진 서명은 형식적인 도장이 되어서는 안 됩니다. 제가 참여했던 한 프로젝트에서는 CEO가 Go-Live 검토 중에 재무팀의 업무를 마비시켰을 큰 문제를 잡아냈습니다.

게이트마다 통과/실패 기준을 정하십시오. "회귀 테스트의 95%가 통과해야 한다." "모든 FI 통합 시나리오가 녹색이다." 이런 기준이 있으면 품질과 상관없이 정해진 날짜에 가동하자고 현업이 밀어붙일 때 선을 지킬 근거가 생깁니다.

제 프로젝트 중 하나에서는 통합 테스트의 75%만 통과한 상태에서 품질 게이트가 우리를 멈춰 세웠습니다. 서둘러 앞으로 가는 대신 문제부터 고쳤습니다. 덕분에 고객은 가동 후 긴급 수정 비용으로 약 10만 유로를 아꼈습니다.

스폰서가 전화 한 통으로 뒤집을 수 있는 게이트는 게이트가 아닙니다. 필요해지기 전에 누가 면제할 수 있는지 적어 두십시오.

SAP Activate 방법론이란 무엇입니까?

SAP Activate는 S/4HANA와 SAP의 다른 클라우드 제품을 위한 SAP의 구축 방법론입니다. 여섯 단계(Discover, Prepare, Explore, Realize, Deploy, Run)로 진행되며 SAP Best Practices 콘텐츠, 가이드형 구성, 애자일 딜리버리를 결합합니다.

배포 시나리오별 작업 목록과 산출물 템플릿은 SAP Activate Roadmap Viewer에 게시되어 있습니다.

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

Prepare입니다. 범위 정의서, 비즈니스 케이스, 이해관계자 매트릭스는 이후 모든 결정의 토대가 되는데, 팀들이 구성 작업에 빨리 들어가려고 가장 많이 건너뛰는 것이 바로 이들입니다. 그 지름길이 Realize에서 벌어지는 범위 분쟁의 가장 흔한 원인입니다.

Explore가 두 번째입니다. Fit-Gap과 요구사항 매핑 문서의 빈틈은 몇 달 뒤 UAT 결함으로 불거지는데, 그때 고치는 비용은 Explore 3주 차에 고쳤을 때보다 훨씬 큽니다.

SAP Activate 템플릿을 커스터마이징할 수 있습니까?

네. 표준 구조의 약 80%를 유지하고, 제약 산업 검증, 공공 부문 조달 규정, SOX 통제처럼 자기 상황에 고유한 부분만 바꾸십시오. 이런 항목은 Deploy가 아니라 Prepare 초반에 추가하십시오.

품질 게이트 구조, 단계 순서, 필수 산출물(범위 정의서, 비즈니스 케이스, Go-Live 준비도 평가)은 커스터마이징하지 마십시오.

SAP Activate 템플릿은 Greenfield와 Brownfield 모두에 쓸 수 있습니까?

네. 주된 차이는 Explore에 있습니다. Brownfield 전환은 기존 구성을 그대로 가져가므로 Fit-Gap은 무엇을 바꿔야 하는지, 표준 S/4HANA가 이제 대체할 수 있는 커스텀 코드는 무엇인지, 전환 전에 어떤 데이터 정리가 필요한지에 집중합니다. Greenfield 프로그램은 SAP Best Practices에서 출발해 어떤 표준 프로세스가 맞는지 확인합니다.

컷오버 계획도 다릅니다. Brownfield 시스템 전환은 전체 데이터 마이그레이션을 수반하는 Greenfield Go-Live와 순서가 다릅니다.

컷오버 계획은 얼마나 상세해야 합니까?

최소한 시간 단위이고, 블랙아웃 윈도는 그보다 더 촘촘해야 합니다. 모든 작업에는 시작 시각, 담당자, 선행 의존 관계가 있어야 합니다.

컷오버가 시작되기 전에 롤백 기준에 합의하십시오. 어떤 조건에서 레거시 시스템으로 되돌아가는지, 누가 그 결정을 내리는지, 몇 시까지 결정하는지입니다. 사전에 합의한 기준 없이 새벽 4시에 내리는 롤백 결정에서 Go-Live 후의 참사가 시작됩니다.