SAP 프로젝트 범위 템플릿: 무엇을 정의하고 무엇을 제외할 것인가

SAP 프로젝트 범위 템플릿은 프로젝트가 무엇을 제공하고, 무엇을 의도적으로 제공하지 않으며, 각 부분을 누가 책임지고, 범위를 어떻게 바꿀 수 있는지를 정의합니다. 아래 아홉 개 섹션이 이를 모두 다룹니다. 가장 중요한 두 가지는 팀들이 흔히 건너뛰는 부분, 곧 명시적인 제외 항목과 데이터 마이그레이션 범위입니다. 구성(configuration)을 시작하기 전에 템플릿을 채우고, 스폰서와 프로세스 오너의 서명을 받으십시오.

팀이 범위 템플릿을 채운 뒤 그대로 넘어가는 경우가 있습니다. 이 단계는 쉬워 보입니다. 몇 주 뒤 설계나 구축 중에 누군가가 “범위에 포함되어 있다고 가정했던” 프로세스를 지적합니다. 대화는 불편해집니다. 아무도 그것을 문서로 남기지 않았습니다. 아무도 일부러 빼놓은 것은 아닙니다. 저는 이런 일을 너무 자주 보았습니다. 초기에 확인하지 않은 가정 몇 개가 프로젝트를 몇 주씩 조용히 궤도에서 벗어나게 합니다.

범위 문서의 역할은 회의실에서 오간 말을 기록하는 것이 아닙니다. 구성이 되돌리기 비싼 가정을 굳혀 버리기 전에 명확성을 강제하는 것입니다.

아홉 개 섹션과, 각 섹션이 답해야 할 질문입니다.

1. 목표

이 작업은 왜 하는 것이며, 끝났을 때 현업은 무엇을 보게 됩니까? 각 목표를 측정 가능한 결과에 연결하십시오. 월 마감을 3일 단축한다, 세 개 법인에 걸친 수작업 대사를 없앤다, 모든 플랜트의 재고를 한 화면에서 본다 같은 식입니다. 목표가 모호하면 성공 기준도 모호해지고, 그 의견 차이는 사용자 인수 테스트(UAT)에서 터져 나옵니다.

2. 범위 정의

모듈, 법인, 플랜트, 국가, 언어, 연계, 그리고 배포 모델입니다. 구체적으로 적으십시오. “재무”는 범위가 아닙니다. “S/4HANA Cloud Private Edition 환경의 UAE 법인에 대한 매입채무, 매출채권, 총계정원장, 코스트 센터 회계를 포괄하는 재무회계 및 관리회계(FI/CO)”는 범위입니다.

3. 제외 항목

대부분의 범위 템플릿이 실패하는 지점이 여기입니다. 제외한다고 적혀 있지 않은 것은 누군가 포함된 것으로 가정합니다. 이름을 들어 적어 두어야 할 제외 항목은 다음과 같습니다.

1. 이후 단계로 미룬 국가 또는 법인.
2. 당분간 현재 상태로 유지하는 레거시 연계.
3. 정해진 컷오프 일자 이전의 이력 데이터.
4. Go-Live 이후 개선 목록으로 넘긴 리포트.
5. 법무 확인이 나올 때까지 보류한 규제 요건.

각 제외 항목에는 옮겨 갈 단계가 있다면 그 단계를 함께 적으십시오. 서명된 제외 항목은 2주짜리 논쟁을 짧은 대화로 바꿔 줍니다.

4. 데이터 마이그레이션 범위

늘 반복되는 사각지대입니다. 세 가지 질문에 서면으로 답하십시오.

1. 무엇을 이관합니까? 미결 항목만입니까, 이력까지입니까? 모든 고객과 공급업체입니까, 활성 상태인 것만입니까? 모든 플랜트의 자재입니까, Go-Live 대상 법인의 자재만입니까?
2. 컷오프 규칙은 무엇입니까? 미결 구매 오더, 판매 오더, 작업 오더의 기준일, 그리고 컷오버 시점에 진행 중인 건을 어떻게 처리하는지입니다.
3. 대신 무엇을 아카이빙합니까? 이력에 적용되는 법적 보존 규정, 그리고 레거시 시스템을 얼마나 오래 조회 가능한 상태로 둘지입니다.

여기서 문서화하지 않은 가정은 구축 단계의 분쟁이 됩니다. 계획 수립은 제 글 SAP 데이터 마이그레이션이 실패하는 이유에서 자세히 다룹니다.

5. 비기능 범위

이 항목들은 계획 단계에서 빠졌다가 테스트 후반에 장애물로 나타납니다. 범위에 포함하십시오.

1. 가용성과 유지보수 시간대. RISE에서는 계약서의 가용성 조건을 참조하십시오.
2. 월 마감 같은 피크 부하 시의 성능.
3. 감사 로그: 어떤 트랜잭션을 기록하고 로그를 얼마나 오래 보관하는지.
4. 역할별 보안 및 접근 통제.
5. 리포팅 지연 시간: 실시간, 준실시간, 일 단위.

이것들은 기능이 아닙니다. 시스템이 충족해야 하는 제약 조건입니다. 범위에 없으면 아무도 이를 염두에 두고 설계하지 않습니다.

6. 역할과 책임

모든 워크스트림에는 컨설턴트 리드와, 의사결정 권한을 가진 현업 카운터파트가 필요하며, 둘 다 실명으로 지정해야 합니다. 제가 가장 자주 보는 공백은 UAT 책임자입니다. 프로세스가 테스트를 마치고 인수되었다고 서명할 수 있는 사람은 누구입니까? 이는 Go-Live 2주 전이 아니라 구축을 시작하기 전에 정하십시오.

7. 변경 관리

“변경에는 공식 승인이 필요하다” 수준이 아닙니다. 구체적인 절차여야 합니다. 무엇이 변경 요청을 촉발하는지, 일정과 예산에 미치는 영향을 누가 평가하는지, 누가 승인하는지, 무엇을 기록하는지를 담아야 합니다. 이것이 없으면 “이것도 추가할 수 있습니까?”는 “포함되어 있는 줄 알았는데요”가 되고, 그다음에는 아무도 계획하지 않은 3주 연장으로 이어집니다.

8. 확장 규칙

커스텀 개발을 어떻게 승인할지 정합니다. SAP는 이제 확장을 레벨 A(릴리스된 API만 사용)부터 레벨 D(코어 수정)까지로 분류합니다(SAP News, 2025년 8월). GROW의 Public Edition에서는 시스템이 릴리스된 인터페이스만 허용합니다. RISE의 Private Edition과 온프레미스에서는 코어를 여전히 수정할 수 있으므로, 범위에 목표 레벨과 예외 승인자를 명시해야 합니다. 제 Clean Core 가이드에서 각 레벨을 설명합니다.

9. 가정과 제약 사항

범위의 바탕이 된 가정을 나열해, 누군가는 반드시 그것을 확인하게 만드십시오. 그다음 제약 사항을 적습니다. Go-Live 일자를 고정시키는 규제 기한, 예산 상한, 파트타임으로만 투입되는 인력, 레거시 폐기 일자입니다.

커스터마이징은 모습을 드러내기까지 가장 오래 걸리는 형태의 스코프 크리프입니다. 승인한 커스텀 리포트 하나가 다섯 개가 됩니다. 워크플로 예외 하나가 이후 모든 요청의 선례가 됩니다.

무엇이든 승인하기 전에 모든 요청을 분류하십시오.

분류	판단 기준	조치
필수	이것 없이는 프로세스가 법적으로나 운영상 작동할 수 없음	승인하되, 업그레이드에 안전한 가장 저렴한 확장 방식을 선택
중요하지만 치명적이지는 않음	효율은 높이지만 진행을 막는 요소는 아님	비용 대비 효과가 분명한 경우에만 승인
불필요	선호이거나, 레거시 시스템의 방식을 그대로 복제한 것	이의를 제기한 뒤 반려하거나 보류

불필요한 커스터마이징 대부분은 SAP가 해당 프로세스를 지원하지 못해서가 아니라, 누군가 자기 업무 방식을 바꾸고 싶지 않아서 생깁니다. 게다가 구축 비용은 시작일 뿐입니다. 커스텀 오브젝트는 존재하는 동안 내내 테스트, 교육, 문서화, 업그레이드 작업을 추가로 만들어 냅니다.

변경 동결 시점을 정하십시오. 보통 Go-Live 4~6주 전으로 날짜를 정하고, 그 이후에는 해당 릴리스에 대한 새 요청을 받지 않습니다. 그 이후의 요청은 모두 Go-Live 이후 백로그로 보냅니다. 동결에는 운영위원회의 서명이 뒷받침되어야 합니다. 프로젝트 매니저 혼자 공지한 날짜는 부서장이 처음 밀어붙이는 순간 뒤집힙니다.

1. 01요청 제기무엇이 변경인지 사전에 정의
2. 02분류필수, 중요 또는 불필요
3. 03영향 평가일정과 예산, 지정된 평가자가 수행
4. 04결정지정된 승인자가 승인, 반려 또는 보류
5. 05범위 버전 관리새 버전 번호와 변경 내역 목록

변경 동결 이후의 새 요청은 Go-Live 이후 백로그로 이동

분석은 범위 논의가 가장 뜨거워지는 곳입니다. 모두가 리포트를 원하지만 몇 개인지는 아무도 말하지 않습니다.

설계 단계에서 확정된 리포트 목록에 합의하십시오. 사람들에게 갖고 싶을 만한 것이 아니라 필요한 것을 물으십시오. 각 리포트를 SAP 표준 출력물인지 커스텀 개발인지 구분해 표시하고, 이 목록을 나머지 범위와 함께 서명받으십시오. 표준 리포트의 비용은 커스텀 리포트의 일부에 불과합니다. 같은 시점에 각 리포트의 데이터 소스도 파악하십시오. 세 개 시스템에서 데이터를 끌어오는 리포트는 곧 연계 요건입니다. 대시보드와 플래닝이 범위에 들어간다면, 제 SAP Analytics Cloud 가이드에서 무엇부터 정해야 하는지 다룹니다.

실수	초래하는 결과	피하는 방법
목표를 측정할 수 없음	“작동한다”의 의미를 두고 벌어지는 UAT 분쟁	처음부터 측정 가능한 성과를 설정
제외 항목을 문서화하지 않음	승인 없이 작업이 흡수됨	범위 밖인 것을 이름을 들어 나열
데이터 마이그레이션 범위가 모호함	잘못된 물량, 컷오버 지연, 재작업	이관 대상, 컷오프, 아카이빙을 정의
비기능 요건이 빠짐	Go-Live 시점의 감사 및 성능 문제	가용성, 성능, 로깅, 보안을 범위에 포함
UAT 책임자가 지정되지 않음	테스트가 늘어지고 아무도 서명하지 못함	권한을 가진 개인을 실명으로 지정
변경 관리가 없음	비공식적인 추가, 압축된 테스트	변경 절차를 범위에 명문화
서명이 없음	나중에 책임 소재 없이 범위가 도전받음	스폰서와 프로세스 오너가 서명
분석을 나중으로 미룸	Go-Live 2주 전의 리포트 요청	설계 단계에서 리포트 목록에 합의
배포 모델이나 확장 규칙이 미정	논쟁이 구축 단계까지 이어짐	범위에 서명하기 전에 둘 다 결정

SAP Activate의 모든 단계 게이트마다, 그리고 승인된 변경이 있을 때마다 범위를 검토하고, 버전 번호와 변경 내역 목록을 남기십시오. 범위는 프로젝트 헌장에도 참조 형태로 들어가야 두 문서가 같은 이야기를 합니다.

SAP 프로젝트 범위 템플릿에는 무엇이 들어가야 합니까?

아홉 개 섹션입니다. 측정 가능한 성과를 담은 목표, 범위 정의(모듈, 법인, 국가, 연계, 배포 모델), 명시적인 제외 항목, 데이터 마이그레이션 범위, 비기능 요건, 실명으로 지정한 역할, 변경 관리, 확장 규칙, 그리고 가정과 제약 사항입니다. 가장 자주 빠지는 섹션은 제외 항목입니다.

SAP 프로젝트에서 스코프 크리프를 어떻게 방지합니까?

제외 항목을 명시적으로 적고, 모든 변경을 영향 평가와 지정된 승인자가 있는 공식 요청으로 처리하고, 커스터마이징은 승인하기 전에 분류하며, Go-Live 4~6주 전에 서명된 변경 동결을 설정합니다. 목적은 모든 변경을 거절하는 것이 아닙니다. 변경이 눈에 보이고, 평가되고, 승인되도록 만드는 것입니다.

SAP 프로젝트에서 데이터 마이그레이션 범위란 무엇입니까?

어떤 데이터를 어떤 규칙으로 SAP로 이관할지에 대한 정의입니다. 어떤 오브젝트(고객, 공급업체, 자재, 미결 오더, 이력)를 옮기는지, 컷오프 일자, 그리고 이관하지 않고 아카이빙할 대상을 포함합니다. 이것이 공수와 일정을 좌우하고, 레거시 시스템을 얼마나 오래 조회 가능하게 유지해야 하는지도 결정합니다.

SAP 프로젝트에서 비기능 범위란 무엇입니까?

시스템이 지원하는 프로세스가 아니라 시스템이 충족해야 하는 제약 조건입니다. 가용성, 피크 부하 시의 성능, 감사 로깅, 보안과 접근 통제, 리포팅 지연 시간이 여기에 속합니다. 이런 항목은 범위에서 빠졌다가 테스트 단계에서 발견되는 일이 많습니다. 규제 산업에서는 감사 로깅이 법적 의무입니다.

범위에서 커스터마이징은 어떻게 다뤄야 합니까?

각 요청을 필수, 중요, 불필요로 분류합니다. 승인한 건마다 요건, 표준 SAP로 충족되지 않는 이유, 공수, 테스트에 미치는 영향, 유지보수 비용, 확장 방식을 기록합니다. Private Edition과 온프레미스에서는 목표 Clean Core 레벨과 예외 승인자를 명시합니다.

SAP 프로젝트 범위는 언제 검토해야 합니까?

SAP Activate의 각 단계 게이트마다, 승인된 변경 요청이 있을 때마다, 그리고 예산, 자원, 일정이 바뀔 때마다 검토합니다. 모든 버전을 날짜, 버전 번호, 변경 요약과 함께 보관하십시오. 그 이력이 나중에 범위가 도전받을 때 팀을 보호합니다.