
목차
SAP 비즈니스 케이스는 의사결정자가 문제, 비용, 수익, 리스크를 자신의 언어로 한 쪽에서 볼 수 있을 때 승인됩니다. 아래의 일곱 개 섹션 구조를 사용하고, 최소 5년 치의 모든 비용을 포함하며, 효과 가정은 보수적으로 잡고, CFO와 IT와 현업을 위한 대목을 따로 쓰십시오. 승인이 멈추는 케이스 대부분은 아이디어가 아니라 전달 방식에서 실패합니다.
저는 아이디어가 탄탄한데도 승인이 몇 주, 때로는 몇 달씩 늘어지는 것을 보았습니다. 첫 제안이 실패했던 S/4HANA 마이그레이션이 기억납니다. 제안서는 시스템 아키텍처 다이어그램으로 가득했고 운영상의 이점에 관한 내용은 거의 없었습니다. 저희는 도입부를 배송 지연 감소, 재고 비용 절감, 팀이 어떻게 수행할 것인가에 맞춰 다시 썼습니다. CFO는 한 번의 회의에서 승인했습니다.
템플릿에 들어가기 전에 한 가지만 더 말씀드립니다. 구축 파트너가 여러분의 비즈니스 케이스를 써서는 안 됩니다. 파트너의 인센티브는 프로그램을 시작하는 것입니다. 여러분의 인센티브는 끝내는 것입니다. 이렇게 해서 4,000만 달러짜리 프로그램이 어느새 9,000만 달러짜리가 됩니다.
경영진 요약이 승패를 가릅니다
한 쪽으로 제한하십시오. 경영진은 이것만 읽을 수도 있습니다.
숫자로 표현한 문제에서 시작하십시오. 제안은 기술 세부 사항 없이 한두 문장으로 밝히십시오. 그다음 수치를 곁들인 주요 효과, 간단한 일정, 총 투자액, 핵심 리스크와 그 완화 방안을 제시하십시오.
예전에 지원한 한 회사에서는 요약이 “기술 오브젝트”, “Embedded HANA” 같은 용어로 시작했습니다. CFO는 첫 문단을 읽고 문서를 내려놓았습니다. 저희는 “재고 감축으로 연간 250만 달러 비용 절감”, “주문 처리 40% 단축”으로 시작하도록 다시 썼습니다. 같은 CFO가 한 쪽 전체를 읽었고, 그 주에 프로젝트를 승인했습니다.
요약이 끝나면 프로젝트 밖의 사람에게 건네십시오. 그 사람이 내용을 되짚어 설명할 수 있다면 제 기능을 하는 것입니다.
독자 세 부류를 위해 쓰십시오
모두를 위한 한 가지 버전은 통하지 않습니다. 저는 독자를 잘못 짚은 탓에 좋은 제안이 죽는 것을 보았습니다.
CFO와 이사회는 메모 없이 되풀이해 말할 수 있는 숫자를 원합니다. “연간 200만 달러 절감, 18개월 만에 회수.” 리스크는 솔직하게 적어 주기를 바랍니다. 이 독자에게는 낙관보다 솔직함이 이깁니다.
IT는 현재 시스템에 대비해 정리한 통합 범위, Go-Live 이후의 지원 모델, 그리고 유사한 프로젝트가 어디서 잘못되었는지 안다는 근거를 원합니다.
현업 사용자는 업무별로 본 변경 전후의 한 주 모습과 교육 시간에 대한 솔직한 수치를 원합니다. 작은 클릭 하나가 늘어도 일주일에 수천 번 반복되면 실제 문제가 됩니다.
한번은 CFO가 자신의 질문에 하나도 답하지 않는다며 회의 도중에 비즈니스 케이스를 반려한 적이 있습니다. 저희는 독자별로 하나씩, 세 개 섹션으로 다시 만들고 각각을 측정 가능한 KPI에 연결했습니다. 기술 계획은 달라지지 않았습니다. 달라진 것은 그 계획을 이야기하는 방식뿐이었습니다.
제가 쓰는 일곱 개 섹션이며, 이 순서를 따릅니다. 기억에 남는 제조업체가 있습니다. CFO는 비용 세부 내역이 23쪽에 묻혀 있다는 것을 알게 되었고, CIO는 기술 리스크를 아예 찾지 못했습니다. 승인은 6개월 미뤄졌습니다. 구조를 갖춘 버전으로 바꾸자 승인에는 2주가 걸렸고, 내용은 거의 달라지지 않았습니다.
| 섹션 | 반드시 담아야 할 내용 |
|---|---|
| 경영진 요약 | 숫자로 표현한 문제, 제안, 효과, 총 투자액, 일정, 주요 리스크 |
| 현재 상황 | 문제점, 현재 드는 비용, 아무것도 하지 않을 때의 비용 |
| 제안하는 접근 방식 | 범위, 모듈, 배포 모델(RISE, GROW 또는 온프레미스), 주요 통합 |
| 재무 분석 | 5년간의 비용과 효과, ROI, 회수 기간, 대규모 프로그램의 경우 NPV |
| 구축 계획 | 단계, 마일스톤, 팀, 의존 관계 |
| 리스크 | 담당자와 완화 방안을 갖춘 구체적인 리스크 |
| 거버넌스 | 스폰서, 운영위원회, 변경 통제, 연장 승인 규칙 |
아키텍처 다이어그램과 구성 세부 사항은 부록에 두십시오.
재무 책임자가 찾아볼 비용
비용이 빠져 있어서 무산되는 비즈니스 케이스가 효과가 약해서 무산되는 케이스보다 많습니다. 다음을 모두 포함하십시오.
- 소프트웨어: 온프레미스는 라이선스와 연간 지원비, RISE와 GROW는 구독료.
- 구축 파트너 비용.
- 인프라(직접 운영하는 경우). RISE에서는 SAP가 구독에 포함해 운영합니다.
- 내부 인력 투입 시간. 가장 자주 빠지는 항목입니다.
- 교육과 변화 관리.
- 데이터 마이그레이션과 데이터 정제.
- 반복되는 지원비. 온프레미스 SAP Enterprise Support는 오랫동안 연간 라이선스 가치의 약 22%였습니다. RISE와 GROW는 계약 기간 매년의 구독료를 보여 주십시오.
- Go-Live 이후의 하이퍼케어.
7번은 많은 재무 책임자가 가장 먼저 확인하는 항목입니다. 2년 차부터 5년 차까지 빠져 있으면 신뢰도가 곧바로 떨어집니다. 저의 SAP 구축 비용 가이드에는 항목별 일반적인 범위가 있고, CFO를 위한 계약 검토 가이드는 파트너 측면을 다룹니다.
CFO가 믿을 만한 ROI, 회수 기간, 효과
ROI는 순효과를 총 투자액으로 나눈 값입니다. 5년간 효과 350만 달러에 비용 200만 달러라면 순효과는 150만 달러이고, ROI는 75%입니다.
회수 기간은 투자액을 연간 순현금 효과로 나눈 값입니다. 120만 달러가 드는 프로젝트가 연 40만 달러를 돌려주면 3년 만에 회수됩니다.
NPV는 미래 현금흐름을 현재 가치로 할인한 값입니다. 이사회가 요구하면 재무팀을 회의에 데려가십시오.
효과는 계산 과정을 보여 주며 수치로 나타내십시오.
- 재고: 1,000만 달러의 재고를 15% 줄이고 보유 비용이 20%라면 연간 30만 달러를 절감합니다.
- 처리 시간: 하루 200번 수행하는 45분짜리 업무를 15분으로 줄이고 시간당 30달러를 적용하면, 연 250 근무일 기준으로 연간 약 75만 달러를 절감합니다.
효과가 점진적으로 늘어나는 모습을 보여 주십시오. Go-Live 후 첫해의 효과는 보통 안정 단계보다 낮습니다. 수치로 나타낼 수 없는 효과는 별도 목록에 두어, 수치로 나타낼 수 있는 효과를 희석하지 않도록 하십시오.
보수적으로 잡으십시오. 저는 비용에는 냉정할 만큼 솔직하고 효과에는 보수적이었던 기업이 까다로운 SAP 프로젝트의 승인을 얻는 모습을 보았습니다. 한 제조업 고객사는 처음에 S/4HANA 프로젝트의 ROI를 30%로 제시했습니다. 반박을 받자 더 현실적인 18%로 케이스를 수정했습니다. CFO는 그 솔직함을 높이 평가하며 승인했습니다.
기술 계획은 달라지지 않았습니다. 달라진 것은 그 계획을 이야기하는 방식뿐이었습니다.
구독이 라이선스와 지원을 대체합니다. RISE와 GROW는 구독이므로 1년 차 비용은 온프레미스 라이선스를 구매할 때보다 적습니다. 5년 총액은 사용자 수, 범위, 계약 기간에 따라 달라집니다. 1년 차, 3년 차, 5년 차를 나란히 보여 주십시오.
바뀌는 것은 현금만이 아니라 회계 처리입니다. IFRS에서 클라우드 계약은 흔히 여러분이 통제하는 소프트웨어 자산이 아니라 소프트웨어에 대한 접근권을 제공합니다. 이 경우 IFRS 해석위원회의 2021년 아젠다 결정에 따라 구성 및 커스터마이징 비용은 대체로 자본화하지 않고 서비스를 제공받는 시점에 비용으로 처리합니다. 그러면 프로그램 비용의 상당 부분이 재무상태표에서 손익계산서로 옮겨 갈 수 있습니다. 재무 분석이 이사회에 올라가기 전에 RISE 또는 GROW 계약의 회계 처리를 감사인과 합의하십시오.
클린 코어는 장기 비용을 바꿉니다. 릴리스된 인터페이스 위에 만든 확장은 설계에 더 많은 비용이 들지만 업그레이드 후에도 살아남습니다. 수정은 지금은 저렴하지만 그 뒤 모든 업그레이드에서 비용이 듭니다. 5년 모델은 이 차이를 보여 주어야 하며, 코어를 여전히 수정할 수 있는 Private Edition에서는 특히 그렇습니다.
AI는 업무 흐름 단위의 가정이 있을 때만 케이스에 넣으십시오. Joule을 비롯한 AI 기능은 특정 업무에서 시간을 줄여 줄 수 있습니다. 모든 AI 효과를 이름이 분명한 업무 흐름, 사용자 수, 방어할 수 있는 도입률에 연결하십시오. CFO는 “AI가 비즈니스를 바꿀 것이다”라는 제안을 매주 보며, 크게 에누리해서 받아들입니다.
아무것도 하지 않을 때의 비용을 빼먹는 것. 현재 시스템 때문에 재작업으로 연간 50만 달러가 든다면 그 금액도 케이스에 들어가야 합니다. 때로는 SAP 투자액보다 클 때도 있습니다.
업무 차질을 무시하는 것. 교육 시간, 컷오버 중단 시간, Go-Live 후 더딘 첫 달은 모두 수익을 줄입니다.
모호한 리스크. “데이터 문제”는 리스크가 아닙니다. “마스터 데이터 불일치로 첫 30일 동안 송장이 반려되는 것”이 리스크입니다.
세부 내용 없이 Go-Live 날짜 하나만 제시하는 것. 지연은 대개 인계 지점에서 시작됩니다. 요구사항에서 구성으로, 테스트에서 승인으로, 교육에서 준비 완료로 넘어가는 지점입니다. 그 지점을 보여 주십시오.
회사 규모를 무시하는 것. 제가 참여한 한 프로젝트에서는 소규모 유통업체가 대기업의 거버넌스 프로세스를 그대로 가져다 썼습니다. 매주 열리는 운영위원회 회의는 프로세스를 줄이기 전까지 몇 시간씩 생산성을 잠식했습니다. 직원이 200명 미만이라면 8~10쪽이면 충분합니다. 대기업은 완전한 재무 모델링과 상세한 거버넌스 섹션을 기대합니다.
승인을 받는 데 6개월을 쓴 제조업 팀과 일한 적이 있습니다. 그 팀은 케이스를 네 번 고쳤는데, 버전마다 승인자 한 명에게만 답하고 나머지는 외면했기 때문입니다. 처음부터 세 부류의 독자 모두를 위해 썼다면 그 시간의 대부분을 아꼈을 것입니다. 승인이 나면 다음 문서는 프로젝트 헌장입니다.
SAP 비즈니스 케이스에는 무엇이 들어가야 합니까?
일곱 개 섹션입니다. 경영진 요약, 현재 상황과 아무것도 하지 않을 때의 비용, 제안하는 접근 방식과 배포 모델, ROI와 회수 기간을 담은 5년 재무 분석, 구축 계획, 담당자가 있는 구체적인 리스크, 거버넌스 모델입니다. 기술적인 세부 사항은 부록에 두십시오.
SAP 비즈니스 케이스는 왜 반려됩니까?
대개 효과가 모호하거나 비용이 빠져 있기 때문이며, 특히 반복되는 지원비나 구독 후반 연도가 빠져 있는 경우입니다. 다른 흔한 원인은 리스크를 얼버무린 경우, 그리고 재무, IT, 운영을 모두 설득해야 하는데 한 부류의 독자만을 위해 쓴 문서입니다.
SAP 구축의 ROI는 어떻게 계산합니까?
해당 기간(보통 5년)의 순효과를 총 투자액으로 나눕니다. 소프트웨어 또는 구독료, 파트너 비용, 내부 인력 시간, 교육, 데이터 마이그레이션, 반복되는 지원비, 하이퍼케어까지 모든 비용을 포함하십시오. Go-Live 이후 효과가 점진적으로 늘어나는 것을 반영해 보수적인 효과를 사용하십시오. 현실적인 18%가 낙관적인 35%보다 더 빨리 승인됩니다.
RISE with SAP는 비즈니스 케이스를 어떻게 바꿉니까?
구독이 라이선스와 연간 지원을 대체하므로, 케이스에는 계약 기간 매년의 비용 관점이 필요합니다. SAP가 인프라를 운영하므로 하드웨어 지출이 사라집니다. IFRS에서는 클라우드 서비스의 구성 비용을 대체로 자본화하지 않고 비용으로 처리하므로, 회계 처리는 감사인과 일찍 합의하십시오.
SAP 비즈니스 케이스는 얼마나 길어야 합니까?
경영진 요약은 한 쪽으로 하고, 이어지는 본문은 중견 기업 프로그램이라면 대략 15~25쪽, 대기업이라면 최대 40쪽입니다. 그보다 길어지는 내용은 부록에 두십시오. 스폰서가 이 문서로 브리핑을 준비하는 데 한 시간이 걸린다면 너무 긴 것입니다.
SAP 비즈니스 케이스에서 아무것도 하지 않을 때의 비용이란 무엇입니까?
현재 시스템을 계속 쓰면서 비즈니스가 계속 잃는 것입니다. 수작업 우회, 대사 작업, 리포팅 지연, 노후 시스템 지원, 신뢰할 수 없는 데이터에 기반한 의사결정이 그 예입니다. ECC를 쓰고 있다면 2027년 이후의 연장 유지보수 비용을 포함하십시오.
다음 단계
지금 ERP 프로젝트를 진행 중이십니까?
이 글이 지금 진행 중인 프로젝트와 맞닿아 있다면, 30분 대화가 일주일간의 내부 분석보다 대개 더 많은 진전을 가져옵니다.




