SAP 구축 프로젝트 헌장 작성 방법

SAP 구축 프로젝트 헌장은 프로그램을 공식적으로 승인하는 짧은 문서입니다. 프로그램이 무엇을 전달하고 무엇을 전달하지 않는지, 누가 결정하는지, 성공을 어떻게 측정하는지, 언제까지 해야 하는지를 서면으로 확정합니다. 벤더와 작업 기술서에 서명하기 전에 작성하고, 클라이언트 스폰서가 소유하게 하며, 분쟁을 정리할 수 있을 만큼 구체적으로 쓰십시오. 항목별 개요는 아래에 있습니다.

팀은 자신 있게 SAP 킥오프 회의에 뛰어듭니다. 그러다 역할이 모호하게 정의되어 있고, 범위 경계에 합의한 적이 없으며, 성공이 어떤 모습인지 말할 수 있는 사람이 아무도 없다는 사실을 알게 됩니다. 헌장은 이를 막아야 합니다. 대부분의 헌장은 그러지 못합니다. 작업의 기준점이 아니라 거버넌스 요건을 채우려고 작성되기 때문입니다.

겉보기에는 깔끔한데 실제 계획과 연결되지 않는 프로젝트 헌장을 많이 보았습니다. 효과가 있는 헌장은 초안을 쓰는 동안 사람들이 논쟁을 벌이는 헌장입니다. 그것이 정직한 문서라는 증거입니다.

SAP 대형 프로그램에서는 세 가지 문서가 늘 혼동됩니다. 각각 하는 일이 다릅니다.

문서	목적	작성자	시점
프로젝트 제안서	프로젝트를 추진해야 하는 이유를 입증	비즈니스 스폰서	승인 전
프로젝트 헌장	프로젝트를 승인하고 범위, 목표, 지정된 책임자, 거버넌스를 확정	스폰서와 프로그램 매니저	착수 시
프로젝트 계획서	작업 수행 방법을 정의: 과업, 리소스, 의존 관계	프로그램 매니저	헌장 승인 후

헌장은 거버넌스 문서입니다. 선을 긋습니다. S/4HANA 프로그램이 여러 모듈, 여러 국가, 여러 벤더에 걸쳐 있다면, 사람들이 각자 가정을 세우기 시작하기 전에 무엇이 포함되는지 결정하는 곳이 헌장입니다.

비즈니스 성과와 연결된 목표

“시스템 현대화”는 목표가 아닙니다. 모든 목표에는 숫자가 필요합니다. 기준은 이렇습니다. 슬라이드 없이 30초 안에 이사회 구성원에게 비전을 설명할 수 있습니까?

모두가 Go-Live를 축하했지만 두 달 뒤에는 약속한 가치가 실현되었는지 아무도 말하지 못하는 SAP 프로그램에서 일한 적이 있습니다. 한 제조 고객사는 400만 달러가 넘게 쓰고도 어떤 수익도 입증하지 못했습니다. CFO가 지표를 요구했지만 아무도 갖고 있지 않았고, 이 때문에 다음 자금 조달이 지연되었습니다.

반대로 제가 지원한 한 유통 고객사는 첫날부터 KPI를 정의한 헌장을 갖고 있었습니다. 주문 처리 비용이 32% 줄었다는 것을 보여 주었고, 2단계는 즉시 승인되었습니다.

명시적인 제외 항목을 포함한 범위

가장 간과되는 항목입니다. 팀은 범위에 포함되는 항목은 자세히 적으면서 제외 항목은 빼놓는데, 논쟁이 벌어지는 곳이 바로 거기입니다.

저는 이 방식으로 SAP 롤아웃의 초점을 유지한 한 의료 기업과 일했습니다. 마케팅 책임자가 사용자 인수 테스트(UAT) 기간에 캠페인 추적용 분석 기능을 추가하고 싶어 했습니다. 헌장에는 그럴 여지가 없었고, 운영위원회가 즉시 이를 짚어 냈습니다. 이 결정 하나로 85만 달러를 아꼈고 6주 지연을 피했습니다.

부서가 아니라 사람의 이름

“재무팀: 보고 요건에 의견 제공”은 누구에게도 책임을 지우지 못합니다. “재무 리드 [이름]: 보고 요건을 정의하고, FI/CO 구성을 최종 승인하며, 데이터 마이그레이션 준비 상태를 승인”은 책임을 지웁니다.

약속으로서의 마일스톤

한 유통 고객사는 Go-Live를 4개월 늦췄습니다. 최초의 지연은 아무도 일정에 반영하지 않은 요구사항 수집 3주 지연이었습니다. 이후 단계에서 만회할 수 있다고 가정했지만, 결국 180만 달러의 초과 비용을 썼습니다.

반대 경우도 있습니다. 한 제조 프로젝트에서 팀은 공표된 계획을 지켰습니다. 데이터 마이그레이션 팀이 지연을 알리자, 헌장 덕분에 마일스톤이 눈에 보였기 때문에 운영위원회가 곧바로 인력 지원을 승인했습니다. 이 결정으로 시간과 60만 달러를 모두 아꼈습니다.

예산, 리스크, 의존 관계

개략적인 예산, 프로그램을 탈선시킬 수 있는 서너 가지 리스크, 같은 인력과 자금을 두고 경쟁하는 다른 프로그램을 적습니다. 한 유통 고객사는 끝내 Go-Live하지 못한 구축에 320만 달러를 썼습니다. 재무 재설계와 SAP 프로젝트가 같은 리소스와 같은 예산 시기를 두고 병행되었는데, 두 헌장 어디에도 서로에 대한 언급이 없었습니다. 경영진이 알아차렸을 때는 너무 늦었습니다.

제가 출발점으로 삼는 구조입니다. 각 항목은 한 페이지 이내여야 합니다.

1. 목적과 배경: 왜 지금인지, 무엇이 문제인지, 아무것도 하지 않으면 어떻게 되는지.
2. 목표와 성공 지표: 각 목표에 기준선, 목표치, 기한을 붙입니다.
3. 범위: 범위에 포함되는 모듈, 프로세스, 법인, 국가, 사이트, 연계, 데이터.
4. 범위 제외: 범위만큼 신중하게 작성하고, 제외한 항목마다 이월되는 단계를 적습니다.
5. 배포 모델과 확장 규칙: S/4HANA Cloud Public Edition, RISE 하의 Private Edition, 또는 온프레미스, 그리고 커스텀 개발을 승인하는 방식.
6. 거버넌스: 스폰서, 운영위원회, 설계 심의 기구, 변경 통제, 에스컬레이션 경로를 실명으로.
7. 역할과 책임: 프로세스 영역, 데이터, 테스트, 변화 관리, 컷오버별 책임자의 실명.
8. 마일스톤: 날짜와 통과 기준을 갖춘 단계별 게이트. 제 품질 게이트 가이드에 예시가 있습니다.
9. 예산과 예비비: 총액, 예비비, 집행 권한자.
10. 리스크, 가정, 의존 관계: 병행 프로그램과 규제 기한 포함.
11. 컴플라이언스 요건: 예를 들어 미국 의료의 HIPAA, 제약의 GxP, 미국 상장사의 SOX.
12. 서명: 스폰서와 비즈니스 리드, 버전 번호와 날짜 포함.

1. 01업무를 아는 사람들에게 묻기스폰서, 비즈니스 리드, 최종 사용자
2. 02필수와 있으면 좋은 것 구분하기Go-Live 필수, 2단계, 또는 이번 프로젝트 제외
3. 03템플릿에서 시작하기그다음 연계, 데이터, 컴플라이언스를 추가
4. 04논쟁을 정리할 만큼 구체적으로 쓰기각 목표가 달성되었음을 입증할 수 있습니까?
5. 05실질적인 서명 받기항목별로 읽고, 이의를 제기하고, 수용

3개월 차에 범위가 다투어질 때 가리킬 수 있는 헌장

1. 업무를 아는 사람들에게 묻기

무엇이든 쓰기 전에 스폰서, 비즈니스 리드, 최종 사용자와 마주 앉으십시오. 무엇이 문제이고 전에는 무엇을 시도했는지 물으십시오. 예전에 함께 일한 한 제조 고객사는 현장이 무엇을 필요로 하는지 안다고 가정한 탓에 SAP 구축에 180만 달러를 낭비했습니다. 6개월이 지나서야 실제 업무 흐름의 문제가 해결되지 않고 있다는 사실을 알았습니다.

제가 참여한 재무 혁신 프로젝트에서 IT는 효율 문제를 해결하겠다며 SAP 롤아웃을 계획했습니다. 재무 부서와 대화해 보니 진짜 문제는 낮은 데이터 품질이었습니다. 묻지 않았다면 엉뚱한 문제를 고치느라 수백만 달러를 썼을 것입니다.

2. 범위를 쓰기 전에 필수와 있으면 좋은 것을 구분하기

모든 입력을 Go-Live에 필요한 것, 2단계, 이번 프로젝트 제외 중 하나로 분류하십시오. 제가 맡았던 한 전문 서비스업 고객사는 요구사항이 세 곳에 흩어져 있었고 프로젝트가 몇 달 진행된 뒤에도 계속 “재발견”되는 바람에 예산을 40% 초과했습니다. 제 범위 템플릿 가이드가 이 단계에 도움이 됩니다.

3. 템플릿에서 시작하고 SAP 고유 사항을 더하기

일반 템플릿은 SAP 프로그램을 비싸게 만드는 요소를 놓칩니다. 연계 지점, 데이터 마이그레이션과 데이터 정제의 책임 소재, 모듈 가정, 컴플라이언스 요건, 커스텀 개발 규칙입니다. 데이터 정리를 한 번도 언급하지 않은 일반 헌장으로 시작한 SAP 프로젝트 이야기를 들은 적이 있습니다. 6개월이 지나자 레거시 데이터가 엉망이라는 사실이 드러났고, 75만 달러와 3개월이 추가되었습니다.

4. 논쟁을 정리할 만큼 구체적으로 쓰기

저는 싱가포르 유통 고객사의 구축을 이끌었는데, 이 회사의 헌장에는 “재고 관리 현대화”라고만 적혀 있었습니다. 팀의 절반은 더 빠른 처리를 뜻한다고 생각했습니다. 나머지 절반은 수요 예측에 집중했습니다. 결과는 180만 달러 지출에, 성공이 무엇인지에 대한 합의는 없었습니다. 모든 목표에 대해 물으십시오. 이것이 완료되었음을 입증할 수 있습니까?

5. 실질적인 서명 받기

헌장은 서명하는 사람들이 읽고, 이의를 제기하고, 그 약속을 수용했을 때 완성됩니다. 스폰서와 비즈니스 리드와 함께 항목별로 훑으십시오. 유통 고객사들이 헌장 합의에 꼬박 3일을 쓰는 것을 보았습니다. 덕분에 나중에 몇 달 치 논쟁과 범위 변경을 피했습니다.

실수	초래하는 결과	대신 할 일
모호한 목표(“효율 개선”)	팀이 서로 다른 방향으로 움직임	모든 목표에 숫자를 붙임
제외 항목 없음	범위가 조용히 커짐	제외 목록을 범위만큼 신중하게 작성
직함이나 부서로만 지정한 책임자	결정이 미뤄짐	개인의 이름을 지정
성공 지표 없음	Go-Live는 축하하지만 가치는 입증되지 않음	킥오프 전에 KPI를 정의
병행 프로그램 미반영	리소스와 예산 충돌	양쪽 헌장에 의존 관계를 기록
구축 파트너가 작성한 헌장	범위가 파트너가 전달하고 싶은 것을 반영	클라이언트가 소유하고, 파트너는 세부 사항을 제공

마지막 항목에 대해서는 제 입장이 확고합니다. 구축 파트너가 헌장을 써서는 안 됩니다. 파트너의 동기는 프로젝트를 시작하는 것입니다. 여러분의 동기는 범위를 정하는 것입니다.

RISE with SAP(Private Edition)에서는 거버넌스 항목에 두 가지를 추가하십시오. 첫째, Clean Core 승인 포럼입니다. SAP는 이제 확장을 레벨 A(릴리스된 API만)부터 레벨 D(수정)까지 분류합니다(SAP News, 2025년 8월). Private Edition은 여전히 코어 수정을 허용하므로, 기술 부채가 쌓이는 것을 막는 것은 이 포럼입니다. 둘째, SAP로 연결되는 에스컬레이션 경로입니다. RISE에서는 SAP가 인프라와 기술 운영을 맡습니다. CIO는 파트너만이 아니라 플랫폼 수준에서 장애가 났을 때 SAP의 누구에게 연락해야 하는지 알아야 합니다.

GROW with SAP(Public Edition)에서는 헌장이 더 작아집니다. 확장이 릴리스된 인터페이스로 제한되므로 플랫폼이 Clean Core를 대신 강제하고, 연계 옵션도 더 좁습니다. 비전, 성공 지표, 지정된 책임자, 제외 항목은 그만큼 중요합니다.

AI 도구는 인터뷰 메모를 초안으로 더 빨리 바꿔 줄 수 있습니다. 하지만 헌장의 정치적인 작업, 곧 스폰서들이 각자 무엇을 책임지는지 합의하게 만드는 일은 하지 못합니다.

SAP 구축에서 프로젝트 헌장이란 무엇입니까?

SAP 프로그램을 공식적으로 승인하는 문서입니다. 범위와 제외 항목을 정하고, 스폰서와 책임자를 지정하며, 성공 지표를 정의하고, 마일스톤과 거버넌스를 설정하고, 주요 리스크를 나열합니다. 유용한 헌장은 범위나 책임을 둘러싼 의견 차이를 정리할 수 있을 만큼 구체적입니다.

SAP 프로젝트 헌장에는 무엇이 들어가야 합니까?

목적, 측정 가능한 목표치를 갖춘 목표, 범위, 명시적 제외 항목, 배포 모델과 확장 규칙, 실명이 지정된 거버넌스, 역할, 게이트 기준을 갖춘 마일스톤, 예산과 예비비, 리스크와 의존 관계, 컴플라이언스 요건, 서명입니다. 위 개요에 각 항목이 나와 있습니다.

프로젝트 헌장과 프로젝트 계획서는 어떻게 다릅니까?

헌장은 승인하고 정의합니다. 범위, 스폰서, 거버넌스, 개략적인 마일스톤입니다. 계획서는 실행합니다. 과업, 의존 관계, 리소스, 순서입니다. 헌장 없는 계획서는 범위에 합의된 적이 없어 표류합니다. 계획서의 모든 약속은 헌장으로 거슬러 올라갈 수 있어야 합니다.

SAP 프로젝트 헌장은 누가 작성해야 합니까?

클라이언트 스폰서가 소유하고, 프로그램 매니저가 초안을 쓰며, 재무, IT, 운영 리드가 세부 내용을 제공합니다. 구축 파트너가 쓰게 두는 것은 권하지 않습니다. 파트너의 동기는 프로젝트를 시작하는 것이지, 불필요한 범위로부터 여러분을 지키는 것이 아닙니다.

RISE with SAP는 프로젝트 헌장을 어떻게 바꿉니까?

어떤 확장을 어느 레벨까지 허용할지 결정하는 Clean Core 승인 포럼을 추가하십시오. RISE에서는 SAP가 인프라를 운영하므로 플랫폼 이슈를 위한 SAP 에스컬레이션 경로도 추가하십시오. GROW with SAP에서는 Public Edition이 Clean Core를 기술적으로 강제하므로 헌장이 더 가볍습니다.

구축 중에 프로젝트 헌장을 변경할 수 있습니까?

예, 변경 통제를 통해서입니다. 헌장을 기준선으로 취급하십시오. 범위, 스폰서, 예산 또는 주요 마일스톤이 바뀌면 버전 번호, 무엇이 왜 바뀌었는지에 대한 기록, 새로운 서명과 함께 갱신하십시오. 프로젝트가 표류할 때마다 조용히 수정되게 두지 마십시오.