SAP 프로젝트 계획과 통제: 프로젝트를 궤도에 유지하기

대부분의 SAP 프로젝트에는 계획이 있습니다. 통제가 있는 프로젝트는 훨씬 적습니다. 계획은 범위, 일정, 예산, 리스크를 정합니다. 통제는 그 계획 대비 진행 상황을 추적하고, 의존성을 관리하고, 일찍 에스컬레이션하고, 모든 변경을 승인 전에 평가하는 주간 작업입니다. 이 가이드는 SAP 프로젝트가 흔들리고 있거나 흔들리지 않게 하고 싶은 프로그램 디렉터, PMO, 스폰서를 위한 것입니다. 통제가 어떤 모습인지, 통제가 없을 때 벌어지는 일을 보여 주는 공개된 실패 사례 세 가지, 이번 주부터 도입할 수 있는 책임자가 정해진 주간 통제 주기를 다룹니다.

처음 일을 시작했을 때, 서류상으로는 훌륭해 보이는 SAP 프로젝트에 참여했습니다. 일정, 리스크 레지스터, 변경 로그, 기대할 만한 것은 다 있었습니다. 아무도 따르지 않았습니다. 운영위원회는 거의 열리지 않았습니다. 재무는 데이터 마이그레이션을 기다리고 있었습니다. IT는 시작도 하지 않았습니다. 의존성을 추적하는 사람이 없었습니다. 모두가 다른 누군가가 궤도를 지키고 있다고 가정했습니다.

6개월이 되자 프로젝트의 절반이 일정에 뒤처졌고 우리는 우리 자신의 실수를 쫓고 있었습니다. 가장 나쁜 점은 아무도 이를 예상하지 못했다는 것입니다.

계획의 문제가 아니었습니다. 통제의 문제였습니다. 실질적인 자원 배분도, 제대로 된 리스크 완화도, 에스컬레이션 경로도 없었습니다. 계획은 한 번 만들어진 뒤 회의에 밀려 버려졌습니다.

계획은 범위, 일정, 예산, 자원, 리스크 레지스터, 마일스톤 약속을 다룹니다. 대부분의 팀이 이것은 만듭니다. 문제는 누군가 매주 그것을 쓰느냐입니다.

통제는 계획 대비 실제 진행 추적, 편차의 조기 발견, 의존성 관리, 지연 시 에스컬레이션, 범위나 일정이 공식적으로 바뀔 때의 재기준선 설정을 다룹니다. 대부분의 팀이 이것을 제대로 하지 못합니다.

1. 01진행 추적작업 패키지별 계획 대비 실적
2. 02편차 발견사흘 이상 늦은 모든 작업
3. 03의존성 확인이것이 밀리면 누가 막히는가
4. 04에스컬레이션사전에 합의된 경로로
5. 05변경 평가시간, 비용, 자원을 먼저
6. 06재기준선 설정공식 변경 이후에만

매주, 책임자를 정해서

통제가 없으면 이런 것들이 무너집니다.

통제가 없을 때 무너지는 것	원인
기한이 조용히 밀립니다	마일스톤 검토 사이에는 아무도 확인하지 않습니다
가정이 검증되지 않습니다	각 팀이 의존성을 다른 팀이 처리하리라 기대합니다
범위가 비공식적으로 늘어납니다	영향 평가 없이 회의에서 변경이 승인됩니다
리스크가 터질 때까지 무시됩니다	리스크 로그가 매주가 아니라 분기마다 업데이트됩니다
비용이 예산을 넘어섭니다	공수는 타임시트에 있지만 작업 패키지에 매핑되지 않습니다
팀이 소통을 멈춥니다	상태 회의가 조치 없는 업데이트가 됩니다

이것은 고객 이야기가 아니라 공개된 사례입니다. 근본 원인은 제가 자문 업무에서 반복해서 보는 것들입니다.

Lidl: 약 7년과 추정 5억 유로를 쓴 뒤 중단

Lidl은 2011년 SAP Retail로 eLWIS 프로젝트를 시작했습니다. Lidl의 재고 평가 관행은 SAP의 표준 모델과 달랐고, Lidl은 관행이 아니라 소프트웨어를 맞추는 쪽을 택했습니다. 2018년까지 시스템은 오스트리아, 북아일랜드, 미국에서 가동되었지만, 이사회는 원래 목표를 합리적인 비용으로 달성할 수 없다고 결론지었습니다. Lidl은 프로젝트를 중단하고 자체 시스템 개발로 돌아갔습니다. 업계 매체는 지출을 약 5억 유로로 추정했고, IT 담당 이사는 2017년에 떠났습니다. Heise가 이 결정을 보도한 것은 2018년 7월입니다. 교훈은 이렇습니다. 레거시 관행을 지키려고 수년간 커스터마이징한 것은 소프트웨어의 실패가 아니라 통제의 실패입니다.

Hershey: 약 1억 달러 규모의 할로윈 주문 미이행

Hershey의 새 SAP, Siebel, Manugistics 시스템은 제과 업계에서 한가한 달인 1999년 4월에 Go-Live하도록 계획되었습니다. 일정은 석 달 밀려 할로윈 주문이 들어오기 시작하는 7월에 Go-Live했습니다. 주문이 시스템에서 창고로 전달되지 못했습니다. CEO는 애널리스트들에게 이 문제 때문에 Hershey가 할로윈에 약 1억 달러어치 제품을 공급하지 못할 것이라고 밝혔고, 3분기 매출은 12.4% 감소했습니다. CIO 매거진의 기사는 진짜 실패의 원인을 타이밍으로 꼽습니다. 성수기를 지키는 일정 통제가 있었다면 다른 Go-Live 날짜를 강제했을 것입니다.

Revlon: 공장 혼란과 내부통제의 중요한 취약점

Revlon은 2018년 2월 최대 제조 거점인 노스캐롤라이나주 옥스퍼드 공장에서 SAP를 가동했습니다. 서비스 중단이 제조와 미국 대형 소매업체로의 출하에 타격을 주었습니다. 2019년 3월 Revlon은 이 롤아웃과 관련된 내부통제의 중요한 취약점을 공시하면서, 효과적인 지속적 리스크 평가가 없었고 영향을 받은 운영 부문에 교육받은 인력이 너무 적었다고 밝혔습니다. 투자자들이 소송을 제기했고, TechTarget이 이 소송을 보도했는데 소송은 약 6,400만 달러어치 출하가 이행되지 못했다고 주장했습니다.

이 중 어느 것도 SAP가 잘못된 선택이어서 실패한 것이 아닙니다. 수십 년 전부터 존재해 온 계획과 통제의 기본기에서 실패했습니다.

작업 분류 체계

작업 분류 체계(WBS)는 전체 범위를 명확한 책임자가 있는 산출물로 나눕니다. 이것이 없으면 작업은 늦어지기 전까지 보이지 않습니다. SAP 프로젝트에서는 프로세스 설계, 구성, 데이터 마이그레이션, 통합, 테스트, 교육, 컷오버를 다루며, 각각을 책임자와 기한이 있는 작업까지 쪼갭니다.

가치는 문서가 아닙니다. 무엇이 일어나야 하고, 누가 하고, 무엇에 의존하는지에 대한 대화를 강제한다는 점입니다. 프로젝트를 죽이는 것은 의존성입니다. 데이터 마이그레이션이 지연되면 통합 테스트가 막히고, 이는 UAT를 막고, 컷오버 기간을 압박합니다. WBS는 그 연쇄를 눈에 보이게 합니다.

일정 관리

일정이 실패하는 이유는 예측 가능합니다. 사람이 빠집니다. 추정이 틀렸습니다. 의사결정이 계획보다 오래 걸립니다. 첫날부터 우발 예비 기간을 확보하십시오. 모든 곳에 퍼진 패딩이 아니라 필요할 가능성이 가장 높은 작업 옆에 명시적인 버퍼로 두십시오.

일정은 매주 추적하십시오. 4주 차의 1주 지연은 대화로 끝납니다. 16주 차의 4주 지연은 위기입니다. 같은 문제인데 바로잡는 비용은 크게 다릅니다.

Go-Live 시점은 별도의 의사결정으로 다루십시오. 비즈니스 성수기에는 절대 Go-Live하지 마십시오. Hershey의 교훈은 모든 기업에 적용됩니다.

예산 통제

예산이 깨지는 이유는 세 가지입니다. 관리되지 않는 범위 변경, 과소 추정된 데이터 마이그레이션, 초기 추정을 넘어서는 하이퍼케어 비용입니다. 첫 주부터 계획 대비 실제 지출을 추적하십시오. 편차가 운영위원회에 올라갈 즈음에는 혼란 없이 바로잡기에 대개 너무 늦습니다.

변경 통제가 예산을 지키는 핵심 수단입니다. 모든 범위 변경은 승인 전에 시간, 비용, 자원에 대한 영향 평가를 받습니다. 평가가 승인 뒤에 오면 그 변경은 예산을 우회한 것입니다. 변경 위원회에 대해서는 제 SAP 구현에서 범위 확대를 피하는 방법 가이드가 더 깊이 다룹니다.

리스크 관리

분기마다 관리하는 리스크 레지스터는 연극입니다. 리스크는 매주 검토하고, 책임자를 정하고, 대응 계획이 있어야 합니다. 모든 SAP 프로젝트에서 다음을 명시하십시오. 뒤늦게 발견되는 데이터 품질 문제, 통합 지연, 자원 가용성 공백, 컷오버 기간 압축, 낮은 사용자 정착입니다.

한 고객사는 데이터 마이그레이션 벤더가 기한을 계속 놓치는 바람에 석 달을 잃었습니다. ‘2주만 더’라는 말을 계속 들었고, 예산을 날리지 않고서는 벤더를 바꾸기엔 너무 늦어져 버렸습니다. 책임자와 트리거 날짜가 있는 리스크였다면 그 결정을 몇 달 일찍 강제했을 것입니다. 제 SAP 리스크 평가 매트릭스에 이런 리스크를 점수화하고 책임자를 정하는 템플릿이 있습니다.

커뮤니케이션과 에스컬레이션

경영진에게는 헤드라인이 필요합니다. 딜리버리 팀에게는 구체적인 내용이 필요합니다. 프로젝트 매니저에게는 편차 데이터가 필요합니다. 모두에게 같은 업데이트를 보내면 아무에게도 도움이 되지 않습니다.

에스컬레이션 경로는 위기가 오기 전에 문서화하고 리허설하십시오. 한 SAP 구현에서는 IT는 재무가 구성을 검토한다고 가정했고 재무는 IT가 한다고 가정했습니다. Go-Live를 석 달 앞두고 핵심 승인이 빠져 있다는 것이 드러나기까지 아무도 이를 제기하지 않았습니다. 수습은 막판 부랴부랴 해결하는 일이 되었고, 추가 비용과 롤아웃 지연을 낳았습니다. 다른 회사는 제대로 했습니다. 보고가 구조화되어 있고 조치와 연결되어 있었기 때문에 이슈가 생기면 모두가 누가 책임지는지, 영향이 무엇인지, 어떻게 해결될지 알았습니다.

범위는 에스컬레이션이 제값을 하는 곳입니다. 단순한 예약 업그레이드로 시작한 항공사와 일한 적이 있습니다. 6개월이 지나자 로열티 변경, 승무원 스케줄링, 재무 모듈이 추가되어 있었습니다. 긴급한 것은 하나도 없었습니다. 아무도 안 된다고 말하지 않았습니다. 일정은 두 배가 되었고 비용은 70% 늘었습니다.

온프레미스 시절의 방식은 RISE with SAP에서 그대로 통하지 않습니다. 달라지는 점이 세 가지 있습니다.

RISE는 에스컬레이션 대상을 바꿉니다

RISE with SAP에서는 SAP가 인프라와 기술 운영을 맡고, 도입 정착을 추적하는 고객 성공 팀을 제공합니다. 통제 구조에 이들을 포함해야 합니다. 플랫폼 이슈(시스템 성능, 하이퍼스케일러 리전, SAP 서비스 수준)에 대해서는 프로그램 매니저에게 구현 파트너를 거치지 않는 SAP로의 문서화된 에스컬레이션 경로가 필요합니다. 필요해지기 전에 적어 두십시오.

클린 코어는 범위 통제에 기술적 안전장치를 줍니다

이제 모든 갭에는 결정이 필요합니다. 구성할 것인가, 릴리스된 API를 통해 확장할 것인가(ABAP Cloud 기반 온스택 또는 SAP BTP 기반 사이드 바이 사이드), 아니면 거부할 것인가입니다. S/4HANA Cloud Public Edition에서는 코어를 수정하는 것이 선택지가 아닙니다. 프라이빗 에디션과 온프레미스에서는 가능하지만, 모든 수정이 업그레이드 작업을 늘리기 때문에 SAP의 클린 코어 가이드는 이를 최후의 수단으로 봅니다.

이것은 범위 통제에 도움이 됩니다. ‘표준 주문-수금 프로세스를 그냥 조금만 손보자’는 요청은 더 이상 가벼운 구성 대화가 아니라 설계, 개발, 테스트 공수가 드는 확장이 됩니다. 운영위원회 아래에 승인 또는 거부 권한을 가진 아키텍트 한 명이 있는 작은 확장 검토 포럼을 두십시오. 그것이 없으면 모든 커스터마이징 논쟁이 운영위원회까지 올라옵니다.

AI가 보고서를 작성하고, 결정은 사람이 합니다

AI는 이제 통제의 서류 작업을 돕습니다. SAP의 애플리케이션 라이프사이클 도구인 SAP Cloud ALM은 프로젝트 작업, 요구사항, 테스트 상태를 보관하며 워크숍 녹취록에서 요구사항 초안을 생성할 수 있습니다. Microsoft Copilot은 대시보드와 상태 보고서로 운영위원회 자료용 편차 요약 초안을 작성합니다. Power BI나 SAP Analytics Cloud의 이상 징후 탐지는 평소 패턴에서 벗어나는 KPI를 표시합니다. 자원 사용, 변경 요청 건수, 지원 티켓에는 유용하지만, 자연스럽게 크게 오르내리는 지표에는 덜 유용합니다.

AI가 하지 않는 것은 행동입니다. 대시보드는 일정 지연을 6주 동안 빨간색으로 보여 줄 수 있습니다. 운영위원회가 아무것도 하지 않으면 지연은 계속됩니다.

이것은 활발히 진행 중인 프로젝트를 위한 최소한의 리듬입니다. 빠진 행이 있다면 무엇보다 먼저 추가하십시오.

통제	최소 실무	책임자	주기
작업 분류 체계	모든 작업에 책임자, 기한, 의존성이 있습니다	PMO 리드	매주 업데이트
일정 검토	사흘 넘게 늦은 모든 작업을 표시하고 크리티컬 패스를 확인합니다	프로그램 매니저	매주
예산 추적	작업 패키지별 계획 대비 실적	프로그램 재무 리드	매주 추적, 매월 보고
리스크 검토	모든 활성 리스크에 책임자, 트리거, 대응이 있습니다	워크스트림 리드	매주
변경 통제	승인 전에 시간, 비용, 자원에 대한 영향 평가	변경 위원회 의장	매주 또는 요청이 올 때
확장 검토(RISE와 GROW)	모든 갭에 대해 구성, 확장, 거부 결정	솔루션 아키텍트	격주
운영위원회	상태가 아니라 결정, 자료는 사전 배포	경영진 스폰서	격주. 컷오버와 하이퍼케어에는 매주

계획과 통제가 실패하는 것은 대부분 방법이 틀려서가 아니라 4개월 차쯤 규율이 무너지기 때문입니다. 14개월 차에도 팀이 계속 돌릴 수 있을 만큼 주기를 작게 유지하십시오. 운영위원회 자체에 대해서는 제 효과적인 SAP 프로젝트 운영위원회 만들기 가이드를 보십시오.

프로젝트 계획과 프로젝트 통제는 무엇이 다릅니까?

계획은 로드맵을 만듭니다. 범위, 일정, 예산, 자원, 리스크입니다. 시작할 때 방향을 정합니다.

통제는 계획 대비 진행 상황을 추적하고, 편차를 드러내고, 의존성을 관리하고, 공식 변경이 생기면 재기준선을 설정하는 지속적인 작업입니다. 프로젝트가 이어지는 동안 매주 이루어집니다.

대부분의 SAP 프로젝트는 계획에는 많이 투자하고 통제에는 너무 적게 투자합니다. 편차가 운영위원회에 나타날 즈음에는 수 주에서 수 개월 치 복구 비용이 쌓여 있습니다.

프로젝트 계획이 있는데도 SAP 프로젝트가 실패하는 이유는 무엇입니까?

아무도 계획대로 일하지 않기 때문입니다. 의존성이 추적되지 않으니 한 워크스트림의 지연이 조용히 다른 워크스트림을 막습니다. 리스크 로그는 분기마다 업데이트됩니다. 범위 변경은 비공식적으로 승인됩니다. 운영위원회는 월 1회 열리고 현장에서 벌어지는 일을 가리는 마일스톤 요약만 봅니다.

Lidl, Hershey, Revlon 모두 계획은 있었습니다. 없었던 것은 능동적인 통제였습니다. 정직한 추적, 이른 에스컬레이션, 경고 신호가 나타났을 때의 실질적인 대응입니다.

긴 SAP 프로젝트에서 범위 확대는 어떻게 관리합니까?

모든 범위 변경에 승인 전 서면 영향 평가를 요구하십시오. 시간, 비용, 자원입니다. 그것이 없으면 변경을 승인하는 것은 알 수 없는 것을 승인하는 것입니다.

가장 효과적인 규칙은 이것입니다. 무엇을 추가하려면 다른 무언가를 빼야 합니다. 이 제약 하나가 현업 책임자들이 솔직하게 우선순위를 정하게 만듭니다.

경영진이 뒷받침해야 합니다. CFO나 COO가 공개적으로 변경 통제를 지지하면 비공식 요청이 빠르게 줄어듭니다. RISE와 GROW 프로젝트에서는 모든 갭에 대한 확장 결정이 기술적 점검을 하나 더합니다.

작업 분류 체계란 무엇이며 SAP에서 왜 중요합니까?

WBS는 전체 범위를 각각 책임자와 기한이 있는 산출물로 나눕니다. SAP 프로젝트에서는 프로세스 설계, 구성, 데이터 마이그레이션, 통합, 테스트, 교육, 컷오버를 의미하며, 모두 작업 단위까지 쪼갭니다.

실질적인 가치는 의존성 매핑입니다. 데이터 마이그레이션은 통합 테스트로, 통합 테스트는 UAT로, UAT는 컷오버로 이어집니다. 하나가 밀리면 하류 영향이 즉시 보입니다.

RISE with SAP는 프로젝트 계획과 통제를 어떻게 바꿉니까?

SAP가 딜리버리의 참여자가 됩니다. 인프라와 기술 운영을 맡고, 고객 성공 팀은 도입 정착과 가치에 대해 자체 주기를 운영합니다.

세 가지 변화가 따릅니다. 파트너를 거치지 않고 플랫폼 이슈를 SAP로 올리는 문서화된 에스컬레이션 경로가 필요합니다. 클린 코어 아래에서 모든 갭을 어떻게 처리할지 결정하는 확장 검토 포럼이 운영위원회 아래에 필요합니다. 그리고 SAP의 고객 성공 주기를 별도로 돌리지 말고 거버넌스에 통합해야 합니다.

SAP 프로젝트에서 운영위원회는 무엇을 해야 합니까?

결정을 내립니다. 운영위원회의 역할은 프로젝트 팀이 해결할 수 없는 것을 푸는 것입니다. 자원 충돌, 범위 분쟁, 예산 변경, 부서 간 권한이 필요한 모든 것입니다. 결정 없이 끝나는 운영위원회 회의는 상태 업데이트였습니다.

대형 프로젝트에서 월 1회 운영위원회는 이슈를 최대 4주 동안 기다리게 합니다. 활발한 딜리버리 중에는 격주가 최소이고, 컷오버와 하이퍼케어 중에는 매주여야 합니다. 진행 보고서는 미리 보내고 회의는 거기서 제기되는 결정에 쓰십시오.