SAP 프로젝트 리스크 평가: 실무형 가이드

SAP 프로젝트 리스크 평가는 프로그램을 탈선시킬 수 있는 것들을 목록으로 만들고, 각 리스크를 발생 가능성과 영향도로 점수화하는 일입니다. 모든 리스크에는 지정된 담당자 한 명과, 리스크가 현실이 되기 전에 합의한 대응이 있어야 하며, 목록은 매주 검토합니다. SAP 프로그램을 침몰시키는 리스크는 좀처럼 예상 밖의 일이 아닙니다. 데이터 마이그레이션, 통합, 인력 가용성, 범위 이탈, 정착이 그 주인공입니다. 이 글은 폴더에 처박혀 있는 등록부가 아니라 의사결정을 바꾸는 리스크 등록부를 원하는 프로그램 매니저와 스폰서를 위한 것입니다. 점수화한 매트릭스, 등록부 템플릿, 공개된 실패 사례 세 건, 그리고 RISE with SAP와 클린 코어가 더하는 리스크를 담았습니다. 이미 갖고 있는 모든 리스크에 지정된 담당자를 붙이는 것부터 시작하십시오.

대부분의 SAP 리스크 평가는 첫 운영위원회 전에 만들어지고, 한 번 검토된 뒤 다시는 손대지 않습니다. 그것은 리스크 관리가 아닙니다. 문서일 뿐입니다.

저는 너무 불편해서 일찍 꺼내지 못한 탓에 무시된 리스크를 보았습니다. 그 침묵은 거의 언제나 나중에 더 큰 비용으로 돌아옵니다. 자재 관리(MM)의 작은 통합 문제로 시작한 것이 갑자기 재무를 막아 세웁니다. 테스트에서는 멀쩡해 보이던 리포트가 시스템 업데이트 후에 깨집니다. 저는 그런 일이 한 번 이상 일어나는 것을 보았습니다.

그 리스크들은 예상 밖의 일이 아니었습니다. 문서에 기록되어 있었습니다. 아무도 조치하지 않았을 뿐입니다.

범위. 프로젝트는 표준 모듈로 시작합니다. 그러다 누군가 “리포트 하나만 더”를 추가하고, 이어서 대시보드, 그다음에 몇 가지 개선 사항이 붙습니다. 위험한 것은 워크숍, 이메일, 복도 대화에서 비공식적으로 들어오는 범위 변경으로, 프로젝트 매니저는 구성이 끝난 뒤에야 이를 듣게 됩니다. 범위 확대를 막는 방법에 대한 제 가이드가 그 통제 방법을 다룹니다.

리소스. 아키텍트가 운영 장애 대응에 차출됩니다. 핵심 개발자가 떠납니다. 현업 사용자는 본업이 멈추지 않기 때문에 테스트 사이클을 놓칩니다. 가용 시간은 서면으로 받으십시오. 구두 약속은 인력 압박 앞에서 증발합니다.

기술. 대상 구조에 대해 한 번도 검증하지 않은 필드 매핑. 단위 테스트는 통과했지만 실제 트랜잭션 물량에서 깨지는 인터페이스. 운영 부하가 걸리기 전까지는 멀쩡해 보이는 커스텀 코드. 어디를 봐야 하는지 안다면 이런 문제는 예측할 수 있습니다.

일정. 블루프린트가 늦어지면 테스트가 압박을 받는데, Go-Live 날짜는 그대로입니다. UAT, 교육, 데이터 준비가 서두르게 됩니다. 단계 게이트를 놓치고도 후속 계획을 옮기지 않는 거의 모든 프로그램에서 같은 패턴이 나타납니다.

정착. 사람들은 이해하지 못하는 것을 거부합니다. 부실하거나 늦은 교육은 우회책을 낳고, 우회책은 데이터를 훼손하며, 변화 관리의 실패에 대한 책임은 시스템이 뒤집어씁니다.

이 사례들은 공개되어 있고 잘 기록되어 있습니다. 같은 패턴이 어떤 규모에서도 반복됩니다.

Lidl: 7년간 약 5억 유로

Lidl은 2011년에 SAP for Retail 기반의 eLWIS 프로젝트를 시작해 일부 소규모 국가에서 가동했고, 보도된 비용 약 5억 유로를 쓴 뒤 2018년에 중단했습니다. 널리 보도된 원인 하나는, Lidl은 재고를 매입가로 평가하는 반면 SAP의 표준 유통 모델은 소매가를 쓴다는 점이었습니다. Lidl은 관행을 바꾸는 대신 커스터마이징을 택했고, 회사는 합리적인 노력으로는 애초의 목표를 달성할 수 없다고 밝혔습니다.

교훈: 여러분의 데이터 모델과 SAP 표준 사이의 불일치는 첫 주의 리스크이지, 5년 차에 발견할 일이 아닙니다.

HP: 약 4억 달러의 매출 손실

2004년에 HP는 서버 사업의 일부를 SAP 기반으로 통합한 주문 및 공급망 시스템으로 마이그레이션했습니다. 주문이 기존 프런트엔드와 SAP 사이에서 빠져나와 수작업 처리가 필요해졌고, 적체는 두 배가 되었습니다. HP의 CEO는 이 문제 때문에 서버 및 스토리지 사업부가 약 4억 달러의 매출과 2억 7,500만 달러의 영업이익을 잃었고, 1억 2,000만 달러의 적체가 남았다고 말했습니다. HP의 CIO는 나중에 팀이 3주의 차질을 예상하고 계획했지만 4주에서 6주에 대한 비상 대책을 갖췄어야 했다고 말했습니다.

교훈: 비상 대책은 평균적인 컷오버가 아니라 나쁜 컷오버를 기준으로 잡고, 전환 전에 재고나 유통 채널 버퍼를 확보하십시오.

Nike: 1억 달러가 넘는 매출 손실

2000년에 Nike는 SAP ERP 프로그램에 앞서 i2 수요 계획 소프트웨어를 가동했습니다. 이 소프트웨어는 Nike의 레거시 시스템과 연동하도록 대폭 커스터마이징되어 있었고, 속도가 느렸으며 제품 물량 앞에서 다운되었습니다. 어떤 신발은 너무 많이, 어떤 신발은 너무 적게 주문했습니다. Nike는 1억 달러가 넘는 매출을 잃었고 주가는 약 20% 하락했습니다. Nike는 이후 단기 및 중기 계획을 SAP로 옮겼습니다.

교훈: 통합이 운영 물량에서 실제 데이터로 돌아가 보기 전에는 작동한다고 가정하지 마십시오.

가정 위에 세운 평가는 없는 것보다 나쁩니다. 거짓 확신을 만들어 내기 때문입니다. 여섯 가지 입력 자료가 중요합니다.

1. 범위 문서: 헌장, 승인된 범위, 서명된 요구사항. 이것이 없다면 범위 리스크는 이미 높은 것입니다.
2. 리소스 약속: 부서장의 서면 약속, 핵심 역할의 스킬 매트릭스, 모든 핵심 직책의 지정된 대체 인력.
3. 예산과 일정: 예비비가 포함된 승인된 예산, 유사 프로그램과 대조해 점검한 일정. 전면 롤아웃에 6개월과 최소한의 자금만 잡았다면 그것은 지금 짚어야 할 리스크입니다.
4. 벤더 약속: 서비스 수준과 페널티가 명시된 계약. RISE에서는 SAP의 책임과 에스컬레이션 경로.
5. 기술 환경: 레거시 호환성, 데이터 마이그레이션의 복잡성, 배포 모델, 커스텀 작업이 있다면 클린 코어 계획.
6. 과거 프로젝트 기록: 이전 SAP 또는 ERP 프로그램의 리스크 등록부, 이슈 로그, 사후 분석. 대부분의 리스크는 새로운 것이 아닙니다.

각 리스크를 발생 가능성과 영향도로 1에서 5까지 점수화하고 곱하십시오. 아래 예시는 S/4HANA 프로그램의 전형적인 출발점이며, 여러분의 점수는 다를 것입니다.

리스크	발생 가능성(1~5)	영향도(1~5)	점수	우선순위
데이터 마이그레이션 실패	4	5	20	높음
통합 지연	4	4	16	높음
리소스 부족	4	4	16	높음
예산 초과	3	5	15	중간
코어의 커스텀 코드가 업그레이드를 막음	3	5	15	중간
범위 확대	4	3	12	중간
테스트 커버리지 공백	3	4	12	중간
피크 부하 시 성능	3	4	12	중간
컴플라이언스 공백	2	5	10	중간
SAP로의 에스컬레이션 경로 부재(RISE)	2	5	10	중간
낮은 사용자 정착률	3	3	9	중간
구독 또는 라이선스 비용 노출	2	4	8	중간
KPI 미추적	3	2	6	낮음

16점 이상은 지정된 담당자와 즉각적인 조치가 필요합니다. 8점에서 15점은 정해 둔 에스컬레이션 트리거를 두고 모니터링해야 합니다. 8점 미만은 우선순위 시간을 쓰지 않고 등록부에 남겨 두십시오. 점수는 출발점이지 판결이 아닙니다. 10점으로 매긴 컴플라이언스 공백이 규제 산업에서는 25점이 될 수 있습니다.

점수만으로는 아무것도 바뀌지 않습니다. 모든 리스크에는 다음 필드가 채워져 있어야 합니다.

필드	작성할 내용	예시
리스크	한 문장으로 쓴 사건	모의 로드 2 전에 벤더 마스터 데이터가 정제되지 않음
담당자	지정된 한 사람	매입채무 담당 리드
점수	발생 가능성 × 영향도	4 × 5 = 20
트리거	조치에 들어가는 측정 가능한 시점	모의 로드 1 추출 데이터의 중복률이 5% 초과
대응	회피, 완화, 전가 또는 수용과 그 조치	완화: 매입채무 애널리스트 두 명이 3주간 정제 작업
다음 검토	날짜	다음 월요일의 리스크 검토
상태	열림, 조치 중, 종료	조치 중

가능하면 비용을 실제 금액으로 표현하십시오. “높은 리스크”는 모호합니다. “UAT가 1주일 지연되면 팀 투입 시간 기준으로 약 여섯 자리 금액이 들고 Go-Live가 3주 밀릴 수 있다”는 주목을 끕니다.

커스텀 코드는 그 자체로 하나의 리스크 범주입니다. S/4HANA Cloud Public Edition에서는 코어에 커스텀 코드를 넣을 수 없습니다. 확장은 SAP BTP, 릴리스된 API, 키 유저 도구를 거칩니다. 프라이빗 클라우드와 온프레미스에서는 여전히 코어를 수정할 수 있고, 그렇게 하는 데 익숙한 파트너는 그렇게 할 것입니다. 그 기술 부채는 첫 대규모 업그레이드 때 수면 위로 올라옵니다. 식별된 커스터마이징 중 합의된 클린 코어 접근 방식이 있는 것이 몇 건인지 추적하고, 파트너의 BTP 확장 경험을 점검하고, Explore 단계가 끝날 때까지 검토 포럼을 세우십시오.

RISE는 가용성의 책임 주체를 바꿉니다. SAP가 인프라를 운영하므로 리스크는 “우리 팀이 가용성을 책임진다”에서 “SAP가 책임지고, 문제가 생기면 우리가 SAP에 빠르게 접근할 방법이 있어야 한다”로 옮겨 갑니다. SAP의 지정 담당자, 에스컬레이션 경로와 서비스 수준, 그리고 Go-Live 전에 합의한 장애 대응 계획을 기록하십시오. 이것이 없으면 SAP로 가야 할 문제가 프로젝트 팀 안에 너무 오래 머뭅니다.

AI는 서류 작업을 도울 뿐, 판단을 대신하지 않습니다. SAP Cloud ALM의 Joule 기반 어시스턴트와 Microsoft Copilot 같은 도구는 상태 보고서, 결함 로그, 회의록으로부터 등록부 항목과 운영위원회 보고 자료를 초안으로 작성할 수 있습니다. 원천 데이터가 깨끗한 프로그램에서는 등록부 유지 관리가 빨라집니다. 이런 도구는 데이터에 이미 보이는 리스크를 찾아냅니다. 어떤 리스크가 조치할 가치가 있는지 결정하지도, 담당자가 움직이게 하지도, 경영진이 외면하고 싶어 하는 리스크를 에스컬레이션하지도 않습니다.

1. 다섯 범주 전반에서 리스크를 식별하십시오. IT, 현업, 벤더와 함께 워크숍을 여십시오. 각자 보는 리스크가 다릅니다. RISE에서는 적어도 한 번은 SAP의 담당자를 포함시키십시오. 팀이 흔히 놓치는 리스크는 IT와 현업이 서로 다른 것을 기대하는 경우, 외부 통합이 제대로 정의되지 않은 경우, 시간을 낼 수 없는 UAT 담당자, 비공식적인 범위 변경입니다.
2. 각 리스크를 점수화하십시오. 발생 가능성과 영향도로, 가능하면 실제 숫자를 넣어서 매깁니다.
3. 리스크마다 담당자를 한 명씩 지정하십시오. 팀이 아니라 사람입니다. 담당자가 없으면 추적도 해결도 없습니다.
4. 리스크가 닥치기 전에 대응을 정의하십시오. 회피, 완화, 전가 또는 수용입니다. “모니터링하고 대응한다”는 계획이 아닙니다. 결정을 뒤로 미룬 것일 뿐입니다.
5. 매주 검토하십시오. 열려 있는 리스크를 확인하고, 새 리스크를 추가하고, 조건이 바뀐 곳은 다시 점수를 매기고, 트리거에 가까워진 것은 에스컬레이션하십시오. 핵심 리스크는 색깔 대신 제안하는 결정을 갖고 운영위원회에 올리십시오.

1. 01식별다섯 범주 모두
2. 02점수화발생 가능성 × 영향도, 1에서 5까지
3. 03담당자 지정팀이 아니라 한 사람
4. 04대응 정의회피, 완화, 전가 또는 수용
5. 05매주 검토재점수화, 트리거 근접 시 에스컬레이션

16점 이상: 지정된 담당자와 이번 주 안의 조치

SAP 프로젝트에서 리스크 평가란 무엇입니까?

무엇이 잘못될 수 있는지 식별하고, 각 리스크를 발생 가능성과 영향도로 점수화하고, 각각에 담당자를 지정하고, 일이 터지기 전에 대응을 합의하는 과정입니다. SAP 프로그램은 여러 모듈, 통합, 데이터 마이그레이션, 변화 프로그램, 고정된 Go-Live를 동시에 운영하므로 비공식적인 리스크 관리로는 버티지 못합니다. 담당자가 있는 실제 리스크 몇 개의 짧은 목록이 아무도 읽지 않는 긴 문서보다 낫습니다.

SAP 프로젝트의 리스크 매트릭스는 어떻게 만듭니까?

범위, 리소스, 기술, 일정, 정착 전반의 리스크에 더해 RISE의 클린 코어와 SAP 에스컬레이션까지 목록으로 만드십시오. 각각을 발생 가능성과 영향도로 1에서 5까지 점수화하고 곱합니다. 16점 이상은 높음, 8점에서 15점은 중간, 8점 미만은 낮음으로 봅니다. 중간 이상의 모든 리스크에 담당자와 측정 가능한 트리거를 부여하십시오. 예를 들어 “16주 차까지 UAT 완료율이 80% 미만이면 Go-Live 날짜를 재검토한다”와 같은 것입니다. 매주, 그리고 단계 게이트마다 점수를 다시 매기십시오.

SAP 구축에서 가장 흔한 리스크는 무엇입니까?

데이터 마이그레이션 실패입니다. 레거시 데이터는 거의 언제나 예상보다 지저분하기 때문입니다. 통합 지연, 특히 문서화되지 않은 레거시 인터페이스와 서드파티 벤더와의 통합이 그렇습니다. 테스트와 교육을 압박하는 범위 확대. 핵심 인력이 차출되거나 월말 UAT 기간에 사용자가 시간을 내지 못하는 것과 같은 리소스 부족. 실제 업무를 시뮬레이션하지 않고 화면만 보여 주는 교육에서 비롯되는 낮은 정착률. RISE에서는 코어의 커스텀 코드와 SAP로 가는 에스컬레이션 경로의 부재를 더하십시오.

SAP 프로젝트에서는 리스크 평가를 언제 해야 합니까?

프로젝트가 시작되기 전입니다. 데이터 모델 불일치나 비현실적인 일정 같은 구조적 리스크는 이때 고치는 비용이 가장 적습니다. SAP Activate의 모든 단계 게이트 전에도 해야 합니다. 단계마다 리스크 프로필이 바뀌기 때문입니다. 범위, 예산, 리소스가 바뀔 때마다, 그리고 리스크가 문제로 바뀌었을 때 다른 무엇에 영향을 주는지 점검하기 위해서도 합니다. 그 사이에는 매주 검토하십시오.

SAP 프로그램에서 리스크는 누가 책임져야 합니까?

그 리스크에 조치를 취할 수 있는 사람입니다. 데이터 리드가 데이터 마이그레이션 리스크를, 기술 아키텍트가 통합 리스크를, 변화 리드가 정착 리스크를, 솔루션 아키텍트가 클린 코어 리스크를 맡습니다. RISE에서는 CIO 또는 프로그램 디렉터가 SAP로 가는 에스컬레이션 경로를 맡습니다. 프로그램 매니저는 등록부의 건전성을 추적하지만 모든 리스크를 책임지지는 않습니다.

ERP 리스크 평가를 건너뛰면 어떻게 됩니까?

큰 규모에서는 Lidl 같은 사례가 나옵니다. Lidl은 약 5억 유로를 쓰고 2018년에 SAP 유통 프로젝트를 중단했습니다. 또는 HP처럼, 2004년 SAP 주문 시스템 마이그레이션으로 서버 사업부가 약 4억 달러의 매출을 잃었습니다. 더 작은 규모에서도 메커니즘은 같습니다. 늦게 발견한 데이터 모델 불일치, 운영 물량에서 실패하는 통합, 부실한 교육으로 인한 정착 실패입니다. 그 리스크들은 문제가 되기 전에 식별할 수 있었습니다.