SAP 구축에서 범위 확장을 막는 방법

SAP 구축에서 범위 확장을 막으려면 모든 변경이 눈에 보이고, 승인하기에 부담스럽게 만들어야 합니다. 범위에 포함되는 것만큼 신중하게 범위에서 제외되는 것도 문서로 남기십시오. 모든 요청을 시간, 비용, 품질에 대한 영향 평가와 함께 변경 통제 절차에 올리십시오. 추가하는 것마다 맞교환을 요구하십시오. 경영진이 뒷받침하는 범위 동결일을 정하고, SI 계약에도 같은 규율을 적용하십시오. 이 가이드는 S/4HANA 프로그램을 이끄는 프로그램 디렉터, 스폰서, PMO를 위한 것입니다. 아래의 변경 비용 표와 계약 조항을 다음 스티어링 보고 자료에 활용하십시오.

대부분의 SAP 프로젝트는 예산과 일정을 넘기고, 범위 확장이 가장 흔한 이유입니다. 저는 SAP 프로젝트가 통제를 벗어난 수십 개 기업과 일했고, 초과가 스티어링 보고에 나타나기 전에 세 가지 신호가 먼저 보입니다. 작은 변경이 영향 평가 없이 쌓입니다. 변경 통제가 문서화된 권한이 아니라 개인적 친분으로 돌아갑니다. 그리고 스폰서가 커피를 마시며 승인한 일을 프로젝트 팀은 일주일 뒤에야 듣습니다.

한 제약 회사는 18개월이라는 분명한 일정으로 시작했습니다. 3년이 지나서도 구축은 이어지고 있었고 비용은 두 배가 되었습니다. 한 제조 회사의 CIO는 요구사항이 계속 바뀌어서 팀이 몇 달 동안 설정한 모듈을 통째로 버렸다고 말했습니다. 범위가 너무 커져서 아무도 원래 계획을 알아보지 못했습니다.

이는 예외적인 사례가 아닙니다. SAP 프로그램이 실패하는 가장 흔한 방식입니다.

시작은 순진합니다. 현업 리더가 ‘작은 변경 하나만’ 요청합니다. 그다음에 또 하나. ‘이왕 건드리는 김에, 이것만…’이라는 말은 어떤 기술적 난관보다 많은 SAP 구축을 탈선시켰습니다.

한 유통 고객과는 깔끔하게 출발했습니다. 핵심 재무와 기본 자재 관리(MM)였습니다. 6개월이 지나자 CMO가 고객 분석을 원했습니다. 이어서 COO가 고급 창고 기능을 요구했습니다. 원래의 9개월 일정이 위협받았습니다. 저는 맞섰고 두 요청을 모두 거절했습니다. 그런 규율이 제 일입니다.

모든 변경이 범위 확장은 아닙니다. 아무도 예상하지 못한 설계상의 치명적 공백을 발견할 때가 있습니다. 프로젝트 도중에 규제가 바뀔 때도 있습니다. 이런 경우는 정당하며, 일정과 예산 조정을 동반한 절차를 따릅니다. 범위 확장은 그냥 나타납니다. 대개 복도에서 나눈 대화 뒤에 말입니다.

한 제조 고객은 커스텀 리포트 10개로 시작해 47개로 끝났고, 리포트마다 설계, 구축, 테스트 시간이 더해졌습니다. 리포팅 워크스트림 하나만 예산을 200% 초과했습니다.

200%

커스텀 리포트가 10개에서 47개로 늘어난 범위 이탈 이후 리포팅 워크스트림의 예산 초과분

출처: 제조 고객 프로그램

경고 신호

제가 눈여겨보는 신호와 각각에 대한 대응입니다.

경고 신호	근본 원인	대응
‘하나만 더’가 일상적인 말이 됨	범위 경계가 불분명함	현업 리더와 함께 기준선을 다시 확정하고, 공식 변경 통제를 시행함
현업 리더가 비공식적으로 기능을 추가함	하위 영향에 대한 이해 부족	모든 요청을 영향 평가에 올리고, 비용을 보여 줌
공식적인 재계획 없이 일정이 늘어남	조용한 범위 확대	범위 점검 지점을 두고, 변경 위원회 승인 아래 재계획함
문서가 실제로 구축된 것과 맞지 않음	비공식적인 범위 처리, 버전 관리 부재	승인된 변경마다 명세서와 계획을 갱신함
예산 소진 속도가 진척을 앞지름	문서화되지 않은 변경에서 생긴 숨은 공수	작업 패키지별로 공수를 추적하고, 차이를 조사함
팀이 따라잡으려고 야근과 주말 근무를 함	범위가 역량을 초과함	변경 위원회로 에스컬레이션하고, 범위를 결정하게 함
현업, IT, 파트너 사이에 책임 공방이 벌어짐	범위가 이미 통제를 벗어남	범위를 동결하고, 근본 원인 검토를 진행하고, 기준선을 재설정함

모든 것이 연결되어 있습니다

SAP는 모든 것을 하나로 엮습니다. 재무는 공급망에 영향을 주고, HR은 급여와 맞닿고, 영업은 재고와 연결됩니다. 변경 하나가 열 가지를 깨뜨릴 수 있습니다.

한 고객은 구매 오더 프로세스에 필드 하나를 추가했습니다. 사소해 보였습니다. 그 필드가 인터페이스 세 개를 깨뜨렸고 여러 부서의 리포트를 다시 써야 했습니다. 다른 고객은 가격 결정 프로시저에 ‘아주 작은 변경’을 요청했는데, 알고 보니 가격 구조 전체를 다시 설정해야 했습니다. 아주 작은 변경 하나에 3주의 작업과 컨설팅 비용 $40,000이 들었습니다.

10년에 한 번뿐인 압박

대부분의 기업은 10년에서 15년에 한 번 SAP를 구축합니다. 모든 부서가 앞으로 10년 동안 기회가 없다는 것을 압니다. 아무도 ‘2단계’라는 말을 듣고 싶어 하지 않으며, 대부분의 조직에서 그 말은 ‘하지 않는다’는 뜻입니다. 그래서 모든 것이 이번 프로젝트로 밀려 들어오고, 범위 목록은 희망 사항 목록이 됩니다.

Clean Core가 바꾸는 것

Clean Core는 커스터마이징에 기술적 제동을 겁니다. S/4HANA Cloud Public Edition에서는 코어를 수정할 수 없습니다. 확장은 공개된 API를 통해, 온스택 또는 SAP BTP 위의 사이드 바이 사이드 방식으로 이루어집니다. Private Edition과 온프레미스에서는 수정이 여전히 가능하지만, 수정할 때마다 업그레이드 작업이 늘어나기 때문에 SAP의 가이드라인은 이를 최후의 수단으로 봅니다.

여기서 얻는 유용한 부수 효과는 범위 규율입니다. ‘표준 Order-to-Cash에 이 승인 단계만 추가해 달라’는 요청은 더 이상 가벼운 설정 대화가 아니라, 자체적인 설계, 구축, 테스트 비용이 드는 확장이 됩니다. 스티어링 위원회 아래에 승인하거나 거절할 수 있는 아키텍트 한 명을 둔 확장 검토 포럼을 두면, 이런 요청 상당수가 기준선에 들어오기 전에 멈춥니다. 이런 포럼이 없는 온프레미스 프로그램은 예전 패턴으로 되돌아갑니다. 제 Clean Core 가이드에서 포럼을 만드는 방법을 설명합니다.

1. 명시적인 제외 범위와 함께 범위를 정의하십시오. 범위에 포함되는 것만큼 신중하게 범위에서 제외되는 것도 문서로 남기고, 둘 모두에 서명을 받으십시오. 모호함이 논쟁의 출발점입니다.
2. 결과가 따르는 공식 변경 통제를 운영하십시오. 모든 변경에는 비용, 시간, 품질에 대한 영향 평가가 필요하며, 승인하는 사람에게 그 내용이 보여야 합니다.
3. 스티어링 회의마다 범위 경계를 공유하십시오. 단순한 빨강, 노랑, 초록 현황으로 범위 상태를 보여 주십시오. 범위 이탈의 상당수는 오해에서 비롯됩니다.
4. 범위 관리 계획서를 작성하십시오. 변경을 어떻게 평가하고, 승인하고, 에스컬레이션하고, 추적할지 정해 두어 모든 워크스트림이 같은 방식으로 처리하게 하십시오. 제 SAP 프로젝트 범위 템플릿이 출발점이 되는 구조를 제공합니다.
5. MoSCoW로 우선순위를 정하십시오. Must have, Should have, Could have, 이번에는 Won't have. Must Have를 짧게 유지하도록 강하게 밀어붙이십시오.
6. 모든 결정을 버전 관리하십시오. 승인된 변경은 모두 기준선을 갱신합니다. 거절된 변경은 모두 사유와 함께 기록합니다.
7. 맞교환을 요구하십시오. 새 요구사항이 들어오면 다른 무언가는 빠집니다. 필수 항목도 대가가 따르면 금세 선택 사항이 됩니다.

이 전략들이 자리 잡게 한 세 가지 기법이 있습니다.

서명 규율. 현업 리더가 승인된 요구사항에 서명하게 하십시오. 한 프로그램에서 현업 리더가 특정 프로세스 흐름을 승인한 적이 없다고 장담했습니다. 그의 서명이 담긴 문서를 꺼내자 논쟁이 끝났습니다. 서명은 관료주의가 아닙니다. 같은 논쟁이 6개월 뒤에 다시 시작되는 것을 막아 줍니다.

파급 효과를 보여 주십시오. 저는 한 고객에게, 판매 오더의 필드 하나를 바꾸면 리포팅부터 인터페이스, 보안 롤까지 14개 영역에 어떤 영향이 가는지 보여 주는 시연을 만들어 보였습니다. 행동이 달라졌습니다. 교육에는 몇 시간이 듭니다. 파급 효과를 이해하지 못하면 몇 달이 듭니다.

변경 비용을 보여 주십시오. 설계 단계의 변경은 $5,000이 들 수 있습니다. 같은 변경이 테스트 단계에서는 $50,000이 들 수 있습니다. 이를 단순한 차트로 사람들 앞에 놓으면 가벼운 요청이 줄어듭니다.

다음은 미국 시장의 S/4HANA 프로그램에 대한 변경 비용 범위의 지표 값입니다. 복잡도와 파트너에 따라 달라집니다. 견적이 아니라 기준점으로 쓰십시오.

단계	소규모 변경의 일반적인 비용	중규모 변경의 일반적인 비용
Explore(설계)	$2K~$10K	$10K~$30K
초기 Realize	$5K~$20K	$20K~$80K
중기 Realize(구축)	$15K~$50K	$50K~$200K
후기 Realize(테스트)	$30K~$100K	$100K~$400K
Deploy 및 컷오버	$80K~$300K	$300K~$1M 이상
Hypercare(가동 후)	$150K~$500K	$500K~$2M 이상

이 패턴은 수십 년간의 연구 결과와 일치합니다. 오류 비용 상승에 관한 NASA 연구에 따르면, 통합 및 테스트 단계에서 잡은 요구사항 오류는 요구사항 단계에서 잡은 오류보다 수정 비용이 21배에서 78배 들었고, 시스템이 운영에 들어간 뒤에는 훨씬 더 많이 들었습니다. 범위 거버넌스는 변경을 이 곡선의 값싼 쪽에 붙잡아 두기 위해 존재합니다.

중요한 계약 조항

모호한 계약은 비용이 큰 문제를 낳습니다. 계약서에 ‘S/4HANA 구축’이라고만 적힌 것에 서명한 고객을 본 적이 있습니다. 파트너는 나중에 특정 프로세스는 추가 비용이 드는 애드온이라고 주장했고, 고객은 결국 두 배를 냈습니다. 다음 조항들이 이를 막습니다.

조항	목적
명시적 제외 범위를 포함한 범위	고정 가격이 포괄하는 범위를 제한하고, 애드온에 대한 모호함을 없앱니다
자주 발생하는 변경에 대해 사전에 합의한 요율	압박이 오기 전에 리포트, 인터페이스, 설정 변경의 가격을 고정합니다
컨설턴트 연속성	새로 투입된 컨설턴트가 확정된 결정을 다시 열어 범위를 넓히는 것을 막습니다
양측의 승인 권한	주니어 컨설턴트가 아무도 승인하지 않은 기능을 약속하는 것을 막습니다
마일스톤 기반 청구	경과 시간이 아니라 서명이 끝난 산출물에 대금을 연동합니다
산출물별 인수 기준	누군가 논쟁하기 전에 ‘완료’를 정의합니다
Clean Core 확장 조항	확장이 공개된 API 또는 SAP BTP를 사용하도록 요구하며, 첫 번째 대규모 업그레이드 때의 재작업을 줄입니다

제 ERP 계약 협상에 관한 글은 이 조항들에 합의를 얻는 방법을 다룹니다.

변경 통제 위원회

변경 위원회는 적합한 사람들이 있을 때 작동합니다. 저는 세 가지 역할로 위원회를 꾸립니다. 기능을 중시하는 현업 의사결정자, 일정을 중시하는 프로젝트 매니저, 예산을 중시하는 재무 리드입니다. 이 균형이 어느 한 가지 우선순위가 지배하는 것을 막습니다.

1. 01요청 접수커피 한 잔 사이가 아니라 서면으로
2. 02영향 평가누군가 승인하기 전에 시간, 비용, 품질 기준으로
3. 03맞교환 명시자리를 만들기 위해 다른 무언가가 빠짐
4. 04변경 위원회 결정현업, 프로젝트, 재무가 함께 자리함
5. 05기준선 갱신거절된 변경은 사유와 함께 기록함

범위는 위원회를 거쳐서만 움직입니다

위원회에는 실제 권한이 있어야 합니다. 한 프로그램에서는 위원회의 승인 없이는 어떤 범위 변경도 일어나지 않았습니다. 단 하나도요. 복도에서 하던 합의가 사라졌습니다. 영업 담당 VP가 새 요구사항을 슬쩍 끼워 넣으려 했을 때, 팀에는 내보일 수 있는 문서화된 승인 매트릭스가 있었습니다.

대부분의 결정은 위원회 수준에서 끝나야 합니다. 실제 분쟁만 스폰서에게 올라가며, 그래야 스폰서가 지치지 않으면서 계속 관여합니다. 2주마다 워크스트림 리드와 범위 검토를 열고, 접수, 승인, 거절된 요청 건수를 보고하십시오. 상태 보고서에 ‘이번 달 범위 15% 증가’가 보이면 행동이 달라집니다.

필요한 변경도 있습니다. 제 고객인 한 제약 회사는 구축 도중에 새로운 FDA 규정의 영향을 받았습니다. 반영해야 했습니다. 그것은 범위 확장이 아닙니다. 현실입니다.

정당한 변경이 들어오면 두 가지를 물으십시오. 효과가 있는 가장 작은 수정은 무엇인가? 그리고 요청한 사람에게, 자리를 만들기 위해 무엇을 뺄 수 있는가? 요청에 대가가 따르면 긴급성은 빠르게 떨어집니다.

선택지는 일정 연장, 예산 추가, 다른 요구사항 삭제, 인력 추가, 또는 이들의 조합입니다. 무엇을 택하든 문서로 남기고 모든 기준선 문서를 한꺼번에 갱신하십시오. 오래된 문서는 다음 범위 문제를 낳습니다.

이제는 AI가 문서 작업을 돕습니다. Microsoft Copilot 같은 어시스턴트는 긴 변경 요청 스레드를 위원회가 바로 결정할 수 있는 요약으로 정리해 주고, SAP Cloud ALM은 요구사항, 변경, 테스트를 서로 연결해 두어 변경의 영향을 추적하기 쉽게 합니다. AI는 변경이 14개 영역에 닿는다는 것을 보여 줄 수 있습니다. 하지만 COO에게 그녀의 요청이 곧 CFO의 요청은 이루어지지 않는다는 뜻이라고 말해 주지는 못합니다. 그 대화는 여전히 여러분의 몫입니다.

제가 함께 일한 한 제조 회사는 SAP 프로젝트를 제때 마쳤습니다. 마땅히 흔해야 할 일인데 드뭅니다. 범위 동결일을 일찍 정했고, 그 이후의 변경은 CEO의 직접 승인이 필요했습니다. 프로젝트는 예산이 남은 채 마무리되었고, 가동 시점에 주말에 일하는 사람이 없었습니다.

다른 고객은 토큰 제도를 썼습니다. 각 부서가 프로젝트 전체에 걸쳐 변경 토큰 세 개를 받았습니다. 변경을 원합니까? 토큰을 쓰십시오. 사람들은 무엇이 중요한지 깊이 고민했고, ‘필수’였던 항목은 한정된 화폐가 들게 되자 다시 검토되었습니다.

두 방식 모두 복잡하지 않습니다. 둘 다 규율과 리더십의 지원이 필요합니다. 범위 프로세스의 시험대는 COO가 ‘작은 변경 하나만’이라는 말을 들고 프로젝트 룸에 들어서는 날입니다. 그날을 위해 만드십시오.

SAP 프로젝트에서 범위 확장이란 무엇입니까?

일정, 예산, 인력의 그에 걸맞은 변경 없이 요구사항이 점진적으로, 통제 없이 늘어나는 현상입니다. SAP에서는 보통 작은 추가에서 시작합니다. 리포트 추가, 필드 추가, ‘워크플로 하나만 빠르게 바꿔 달라’는 요청 같은 것입니다. 하나하나는 해롭지 않아 보입니다. 모두 합치면 몇 달이 늘어납니다.

정당한 범위 변경은 절차를 따르고 일정과 예산 조정이 함께 따라옵니다. 범위 확장은 비공식적으로 들어와 변경 통제를 우회합니다.

SAP 프로젝트에서 범위 확장의 가장 흔한 원인은 무엇입니까?

일관되게 나오는 원인은 세 가지입니다. 초기 요구사항이 모호해서 무엇이든 범위 안이라고 주장할 수 있는 것, 공식 변경 통제가 없어서 모든 단계에서 변경이 슬쩍 들어오는 것, 그리고 모든 부서가 이번 프로젝트에서 수년간 쌓인 문제를 한꺼번에 해결하려 하는 10년에 한 번이라는 마음가짐입니다.

SAP의 상호 연결성이 이 세 가지를 모두 증폭합니다. 변경 하나가 연결된 프로세스 열 개를 깨뜨릴 수 있고, 현업 리더가 그 연결을 보지 못하면 영향은 테스트 단계에서 드러나며, 그때는 비용이 몇 배로 듭니다.

Clean Core는 범위 확장 리스크를 어떻게 바꿉니까?

기술적 제동을 추가합니다. S/4HANA Cloud Public Edition에서는 코어를 수정할 수 없으므로 모든 갭이 자체적인 설계, 구축, 테스트 비용이 드는 확장이 됩니다. Private Edition과 온프레미스에서는 수정이 가능하지만 업그레이드 작업이 늘어나므로 SAP의 가이드라인은 이를 권하지 않습니다.

결정 권한을 가진 아키텍트 한 명을 둔 확장 검토 포럼은 많은 요청이 기준선에 들어오기 전에 멈추게 합니다. 이 포럼이 없으면 온프레미스 프로그램은 옛 습관으로 되돌아갑니다.

범위 확장과 골드 플레이팅은 어떻게 다릅니까?

범위 확장은 현업에서 나옵니다. 합의한 범위를 넘어서는 요청입니다. 골드 플레이팅은 수행팀에서 나옵니다. 아무도 요청하지 않은 복잡성입니다.

SAP 용어로 골드 플레이팅은 단순한 라우팅으로 충분한 곳에 컨설턴트가 정교한 워크플로 로직을 만드는 것입니다. 범위 확장은 기본 MM으로 범위를 잡은 프로젝트에서 6개월이 지난 뒤 COO가 고급 창고 기능을 요구하는 것입니다. 둘 다 비용과 시간을 부풀리며, 같은 규율이 필요합니다.

실제로 작동하는 변경 통제 프로세스는 어떻게 구성합니까?

세 가지 요소입니다. 모든 요청에는 일정, 예산, 인력에 대한 영향 평가가 따릅니다. 승인 위원회에는 이 세 가지를 각각 중시하는 사람이 있어야 하며, 무엇이든 승인해 버리는 현업 리더만으로 구성해서는 안 됩니다. 그리고 모든 추가에는 맞교환이 필요합니다. 다른 무언가가 빠져야 합니다.

마지막 규칙 하나만으로도 정말 중요하지 않은 요청이 걸러집니다.

범위 확장을 완전히 피할 수 있습니까?

아닙니다. 몇 달을 넘는 프로그램에서는 비즈니스 여건이 바뀌고, 규제가 달라지고, 설계 과정에서 공백이 드러납니다.

목표는 제거가 아니라 통제입니다. 통제된 변경은 문서화된 절차를 따르고, 영향이 평가되고, 기준선을 갱신합니다. 통제되지 않은 변경은 절차를 우회하고, 테스트 단계나 가동 이후에 아무도 계획하지 않은 비용으로 드러납니다.

긴 SAP 프로그램에서 범위 동결을 다루는 가장 좋은 방법은 무엇입니까?

결과를 따르게 하고 경영진이 눈에 보이게 뒷받침하게 하십시오. 제가 써 본 가장 효과적인 방식은 이렇습니다. 동결일을 첫날부터 프로젝트 헌장에 넣고, 변경 프로세스에서 ‘동결’이 실제로 무엇을 뜻하는지 정의하고, 날짜가 오기 전에 스폰서가 스티어링 회의에서 공개적으로 이를 강조합니다.

동결 이후의 모든 변경을 CEO가 직접 승인해야 하면, 목록은 아주 짧게 유지됩니다.