SAP 프로젝트 회복: 궤도를 벗어난 프로그램 구하기

SAP 프로젝트 회복이란 궤도를 벗어난 마이그레이션이나 구축을 멈추고, 그에 관해 실제로 무엇이 사실인지 밝혀내고, 그 사실에서 다시 계획하는 일입니다. 성패는 첫 주에 갈립니다. 프로그램 현황을 평가하고, 설계를 검토하고, 시스템에 실제로 배포된 것을 평가하십시오.

짧게 답하면, 그 세 가지 점검이 서로, 그리고 계획과 일치하면 프로그램에 필요한 것은 회복이 아니라 추진입니다. 일치하지 않으면 현재 계획에 아무리 노력을 더해도 고쳐지지 않으며, 새 기준선을 갖춘 공식 회복이 필요합니다.

이 글은 그 진단과 그 뒤에 오는 것을 다룹니다. 경로, 일정, 기한을 다루는 제 ECC에서 S/4HANA로의 마이그레이션 가이드의 하위 주제입니다. 여기서의 질문은 더 좁습니다. 프로그램이 곤경에 빠졌는데, 이제 어떻게 해야 합니까?

늦어진 프로그램 대부분은 구할 필요가 없습니다. 결정을 더 빨리 내리거나, 핵심 사용자의 시간을 확보하거나, 벤더가 날짜를 지키게 하면 됩니다. 그것이 추진입니다.

회복은 다릅니다. 신호는 제가 첫 주에 하는 세 가지 점검에서 나오며, 그 신호는 단순합니다. 현황, 설계, 배포된 것이 서로, 또는 계획과 일치하지 않는 것입니다.

제가 회복 신호로 볼 패턴은 다음과 같습니다.

1. 현황은 녹색인데 시스템은 아닙니다. 보고서는 빌드 대부분이 끝났다고 하지만, 테스트 시스템에서 기본적인 주문에서 수금까지(order to cash)도 돌아가지 않습니다.
2. 설계는 서명됐는데 빌드는 그것을 무시합니다. 구성은 승인된 설계가 아니라 워크숍 메모를 보고 이뤄졌습니다.
3. 계획에 Go-Live 날짜는 있는데 거기까지 가는 길을 아무도 설명하지 못합니다. 테스트, 데이터 로드, 컷오버 리허설에 현실적인 자리가 없습니다.
4. 범위가 늘기만 합니다. WRICEF 목록(보고서, 인터페이스, 전환, 개선, 양식, 워크플로)이 Explore 단계가 한참 지났는데도 계속 늘어납니다.

이 중 하나는 추진으로 고칠 수 있습니다. 둘 이상이 동시에 있으면 보통은 그렇지 못합니다.

첫 주는 무엇이 사실인지 밝혀내는 시간입니다. 고치는 시간도, 책임을 묻는 시간도, 새 계획을 쓰는 시간도 아닙니다. 저는 세 가지를 이 순서로 평가합니다. 현황, 설계, 실제로 배포된 것입니다.

각 점검이 다루는 것과, 불일치가 알려 주는 것은 다음과 같습니다.

점검	제가 보는 것	답하는 질문	다른 점검과 일치하지 않으면
프로그램 현황	계획, 현황 보고서, RAID 로그, 미결 변경 요청, 예산 대비 지출	프로그램은 스스로에 대해 무엇을 믿고 있는가?	보고가 낙관적이거나 딜리버리와 동떨어져 있음
설계	비즈니스 프로세스 설계, Fit-to-Standard 산출물, WRICEF 목록, 미결 설계 결정	현업은 무엇을 약속받았는가?	빌드가 합의된 것에서 벗어났거나, 설계가 끝난 적이 없음
배포된 것	개발 및 테스트 시스템, 구성, 이송, 커스텀 코드, 지금까지의 데이터 로드	오늘 실제로 존재하는 것은 무엇인가?	시스템에 없는 작업에 대해 진척이 보고되었음

세 번째 점검이 대부분의 검토가 건너뛰는 것입니다. 시스템에 관한 문서를 읽는 것이 아니라, 시스템 앞에 앉아 프로세스를 돌려 본다는 뜻입니다.

현황 보고서와 설계 문서는 주장입니다. 시스템은 증거입니다.

누가 점검을 해야 하는가

현황 보고서를 쓴 사람이 그것을 검증하는 사람이어서는 안 됩니다. 비난이 아닙니다. 감사인이 자기 작업을 감사하지 않는 것과 같은 이유입니다.

저라면 구축 파트너와 독립된 사람에게 첫 주를 맡기고, 시스템에 대한 전체 접근 권한과 프로그램의 누구와도 이야기할 권리를 주겠습니다. 그것이 불가능하다면 최소한 파트너가 배포된 시스템을 슬라이드가 아니라 실제로 보여 주게 하십시오.

2018년에 저는 한 항공 프로그램의 회복 작업을 했습니다. 모듈은 배포되어 있었지만, 비즈니스 요구사항에 근거해 구성된 것은 하나도 없었습니다.

첫 주의 세 가지 점검은 바로 이런 상황을 드러내기 위해 있습니다. 배포된 모듈은 작동하는 설계와 같지 않으며, 그 차이는 시스템 안을 들여다봐야만 보입니다.

항공사는 정비, 구매, 재무를 긴밀하게 연결하므로, 한 영역의 공백이 다른 영역으로 번집니다. SAP가 이 산업에 어떻게 맞는지는 항공을 위한 SAP 페이지에서 다룹니다.

제가 이끌었거나 구해 낸 21개 SAP 프로그램에서 본 가장 큰 실수는 구축 초기에 계획을 제대로 세우지 않는 것입니다. 회복은 흔히 그 빠진 계획을 늦게, 압박 속에서 하는 일입니다.

다른 두 원인도 거듭 나타납니다.

1. 벤더가 범위를 통제합니다. 시스템 통합업체가 범위를 쓰면, 그 범위는 통합업체가 제공하려는 것을 기술합니다. 공백은 나중에 같은 벤더가 가격을 매긴 변경 요청으로 돌아옵니다.
2. 커스텀 코드가 초과됩니다. 제 경험상 커스텀 코드는 마이그레이션에서 가장 자주 초과되는 단계이며, 가장 많이 잊히는 숨은 비용이기도 합니다.

Explore 단계에서 왜 비용이 뛰는지를 포함한 예산 측면은 SAP 프로젝트가 예산을 초과하는 이유에 관한 제 글에서 다룹니다. 여기서 반복하지 않겠습니다.

약한 통제도 흔한 공통점입니다. 프로그램에 추적, 에스컬레이션, 변경 통제의 주간 리듬이 한 번도 없었다면, 회복 과정에서 그것을 갖춰야 합니다. 제 SAP 프로젝트 계획과 통제 가이드에서 담당자와 함께 그 주기를 설명합니다.

무엇이 사실인지 알고 나면 회복에는 분명한 순서가 있습니다. 한 단계를 건너뛰면 보통 회복을 두 번 하게 됩니다.

SAP 프로그램 회복 순서

1. 01

   진단

   현황, 설계, 배포된 것을 서로 대조해 점검합니다.

2. 02

   범위 되찾기

   고객이 소유한 범위를 동결하고, 모든 변경에 가격을 매깁니다.

3. 03

   기준선 재설정

   증거에 근거한 새 계획 하나, 예비비는 귀사 쪽에.

4. 04

   단계별 게이트

   남은 모든 단계의 끝에 품질 게이트.

5. 05

   리허설과 컷오버

   Go-Live 날짜를 확정하기 전에 전체 리허설.

1. 범위 오너십을 되찾으십시오

누군가 다시 계획하기 전에 범위를 누가 소유할지 정하십시오. 답이 여전히 벤더라면, 새 계획은 예전 계획과 같은 방식으로 실패합니다.

범위를 고객 쪽에서 작성하고, 배포된 것과 비교하고, 동결하십시오. 그때부터 모든 변경은 담당자가 있고 가격이 매겨진 결정입니다.

2. 기준선은 증거에 근거해 한 번만 다시 잡으십시오

회복에는 작은 지연이 이어지는 것이 아니라 새 기준선 하나가 필요합니다. 예전 계획이 바랐던 것이 아니라 시스템이 보여 주는 것으로 세우십시오.

커스텀 코드를 가장 먼저 다시 추정하십시오. 초과가 가장 자주 나오는 곳이기 때문입니다. 그다음은 데이터입니다. 데이터 마이그레이션은 공수의 30~40%이며, 곤경에 빠진 프로그램에서는 보통 뒤처져 있습니다.

10~20%의 예비비를 귀사 쪽에서 보유하고, 이름 붙은 위험에 대해서만 집행하십시오. 자매 글인 S/4HANA 마이그레이션 비용에서 그 숫자를 좌우하는 요인을 설명합니다.

3. 모든 단계의 끝에 품질 게이트를 두십시오

곤경에 빠진 프로그램은 대개 증거가 아니라 날짜에 따라 단계를 넘어왔습니다. 그것을 바로잡으십시오.

SAP Activate에서 Explore 단계는 Fit-to-Standard 워크숍을 진행하며, 승인된 델타 요구사항은 Realize를 위한 제품 백로그에 들어갑니다. 프로그램이 설계를 끝내지 않은 채 Explore를 떠났다면, 돌아가서 끝내십시오. SAP Cloud ALM은 체크리스트가 있는 점검 지점으로서의 품질 게이트를 지원하고 이를 프로젝트 개요에 표시하므로, 게이트를 스프레드시트에 둘 필요가 없습니다.

4. 날짜를 약속하기 전에 리허설하십시오

브라운필드 전환에서는 컷오버 전에 모의 전환을 세 번 계획합니다. 곤경에 빠진 프로그램은 시간을 아끼려고 리허설을 줄이는 경우가 많은데, 그러면 위험이 Go-Live 주말로 옮겨 갑니다.

제가 본 컷오버 다운타임은 주말 하루에서 일주일까지였습니다. 회복된 프로그램은 그 숫자를 추정이 아니라 리허설에서 알아야 합니다.

5. 실제로 맞춰야 할 기한을 확인하십시오

인핸스먼트 패키지 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 끝나며, 2%p의 추가 비용으로 2030년 말까지 선택적 연장 유지보수를 받을 수 있습니다(SAP News). ECC 마이그레이션을 2027년 이후로 미루는 회복이라면 연장 유지보수를 공개적으로 예산에 넣어야 합니다.

리허설이 뒷받침하지 않는 Go-Live를 2027년이라는 날짜가 강요하게 두지 마십시오. 늦은 Go-Live는 유지보수 비용이 듭니다. 실패한 Go-Live는 훨씬 더 많이 듭니다.

회복은 흔히 현재 시스템 통합업체를 유지할지라는 질문을 낳습니다. 파트너 교체가 맞을 때도 있습니다. 하지만 더 큰 문제가 프로그램을 세팅한 방식인 경우가 많고, 새 파트너는 그것을 물려받습니다.

결정하기 전에 제가 할 질문은 다음과 같습니다.

1. 서명된 설계에 비춰 배포된 시스템을 실제로 보여 줄 수 있습니까? 데모 환경도 슬라이드도 아닙니다.
2. 어떤 WRICEF 오브젝트가 빌드, 테스트, 이송까지 끝났으며, 어떤 것이 완료로 보고만 되었습니까?
3. 마무리를 위한 상위 수준 설계는 무엇이며, 우리와 비슷한 프로그램을 회복시킨 레퍼런스 중 어디에 전화할 수 있습니까? 레퍼런스와 상위 수준 설계는 제가 서명 전에 어느 파트너에게나 요구하는 두 가지입니다.
4. 우리에게서 필요한데 받지 못하는 것은 무엇입니까? 빠진 결정과 파트타임 핵심 사용자가 이야기의 절반인 경우가 많습니다.
5. RISE with SAP 고객의 경우: 어떤 문제가 파트너가 아니라 SAP의 몫이며, 누가 에스컬레이션합니까?

경고 신호는 제가 선정 단계에서 파트너에게서 돌아서게 만드는 것과 같습니다. 일반론적인 답입니다. 회복 계획이 어느 회사에나 적용될 수 있다면, 귀사를 위해 쓴 것이 아닙니다. 제 S/4HANA 마이그레이션 파트너 선택 가이드에서 선정 측면을 다룹니다.

프로그램이 소스 시스템을 제대로 평가한 적이 없다면 지금 하십시오. SAP Readiness Check는 기존 시스템을 분석하며, SAP는 실제 사용 현황을 정확히 파악하려면 운영 시스템에서 실행할 것을 권장합니다. SAP Readiness Check와 마이그레이션 평가에 관한 제 글에서 커스텀 오브젝트를 시작으로 그것이 놓치는 것을 설명합니다.

프로그램 디렉터와 SAP 리더와 반나절을 잡고, 세 가지를 나란히 보여 달라고 하십시오. 최신 현황 보고서, 서명된 설계, 그리고 하나의 완전한 비즈니스 프로세스를 돌리는 테스트 시스템입니다. 셋이 같은 이야기를 하면 추진하십시오. 그렇지 않으면 다음 운영위원회 전에 공식 회복을 시작하십시오.

궤도를 벗어난 프로그램에 대해 독립적인 시각이 필요하다면, 저는 바로 이런 진단을 돕습니다. 저와 상담을 예약하실 수 있습니다.

SAP 프로젝트 회복이란 무엇입니까?

SAP 프로젝트 회복은 궤도를 벗어난 SAP 구축이나 마이그레이션을 다시 통제 아래로 가져오는 일입니다. 프로그램 현황, 설계, 실제로 배포된 것에 대한 진단에서 시작해, 범위 오너십을 되찾고, 새 기준선 하나를 정하고, 남은 단계에 품질 게이트를 더합니다.

SAP 프로젝트에 회복이 필요한지 어떻게 압니까?

세 가지를 비교하십시오. 현황 보고서가 말하는 것, 서명된 설계가 말하는 것, 시스템에 실제로 배포된 것입니다. 서로, 그리고 계획과 일치하면 프로그램에 필요한 것은 추진입니다. 일치하지 않으면 현재 계획에 노력을 더해도 고쳐지지 않으며, 공식 회복이 필요합니다.

SAP 구축 회복의 첫 주에는 무엇을 해야 합니까?

진단만 합니다. 프로그램 현황을 평가하고, 설계를 검토하고, 실제로 배포된 것을 평가하며, 가급적 구축 파트너와 독립된 사람이 이끕니다. 세 가지 점검이 끝날 때까지 새 계획을 쓰지 마십시오.

회복 중에 SAP 구축 파트너를 교체해야 합니까?

자동으로 그래야 하는 것은 아닙니다. 파트너에게 서명된 설계에 비춰 배포된 시스템을 보여 달라고 하고, 비슷한 회복 사례의 레퍼런스와 함께 마무리를 위한 상위 수준 설계를 달라고 하십시오.

답이 일반론이라면 교체해야 한다는 강한 신호입니다. 진짜 문제가 귀사 쪽의 범위 오너십이나 빠진 결정이라면, 새 파트너가 그것을 물려받습니다.

SAP S/4HANA 마이그레이션은 왜 궤도를 벗어납니까?

제가 보는 가장 흔한 근본 원인은 구축 초기에 계획을 제대로 세우지 않는 것입니다. 벤더에게 범위 통제를 맡기는 것이 또 하나이며, 커스텀 코드는 가장 자주 초과되는 단계입니다. 공수의 30~40%를 차지하는 데이터 마이그레이션도 보통 뒤처져 있습니다.

회복 때문에 ECC 마이그레이션이 2027년 기한을 넘기게 됩니까?

그럴 수 있습니다. 인핸스먼트 패키지 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 끝나고, 선택적 연장 유지보수는 2%p의 추가 비용으로 2030년 말까지 이어집니다. 리허설이 뒷받침하지 않는 Go-Live를 강행하기보다 연장 유지보수를 예산에 넣으십시오.