Kronopia

  As-is 분석 산출물이 한 번 다 나오면, 다음 질문은 "그래서 To-Be를 어떻게 그릴 것인가"다. 1편에서는 코어보다 주변이 먼저 흔들린다 는 것을, 2편에서는 시작 단계는 고정값이 아니라 조정 가능한 합의를 만드는 일 이라는 것을 풀었다. 3편은 그 사이에 있는 실제 작업 — As-is 산출물에서 To-Be 설계로 건너가는 결정의 트리거 — 을 정리한다. 그룹 통합 ERP를 S/4HANA Cloud PCE로 옮기는 한 그룹사 사례에서, 산출물별로 어떤 결정이 어디에서 시작됐는지 본다. RZ010 → 표준 회귀 가능성 점수 Configuration list는 자산 목록이 아니라 표준 회귀 가능성의 점수표다. RZ010(설정값 리스트)을 As-is 산출물로 그대로 출력하면, 모듈마다 수백 줄의 설정이 빈 칸 없이 나온다. 이걸 그대로 옮기는 작업 이라고 잘못 읽으면 PCE 전환은 단순 마이그레이션이 된다. 실제로는 Configuration list의 각 줄에 세 갈래의 점수 를 매기는 일이 시작 단계의 핵심이다 — 표준 그대로 회귀 가능한가, Extensibility로 변형 필요한가, 외부 위성 시스템으로 빼야 하는가. 이번 프로젝트의 As-is 산출물에서 모듈별 Configuration list가 D1로 분류되고 같은 폴더 안에 To-Be Process List가 D1로 같이 묶여 있는 건 우연이 아니다. 두 산출물은 짝이다 — Configuration의 한 줄이 To-Be 프로세스의 한 단계와 어떻게 매핑되는가 가 점수의 근거가 된다. 표준 회귀 점수는 단순히 "표준에 비슷한 기능이 있는가"가 아니라, 그 표준이 우리 To-Be 프로세스를 깨지 않는가 까지 봐야 한다. 점수가 낮은 줄은 변형(Extensibility) 후보로 넘어가고, 변형으로도 풀리지 않는 줄은 BTP 사이드카나 외부 위성으로 분리된다. 이 점수가 시작 단계에 매겨지지 않으면 To-Be 설계 회의는 매번 같은 자리에서 막힌다. ...

ERP 클라우드 전환의 시작 단계에서 무엇을 먼저 잡아야 하는가. 1편에서는 코어보다 주변이 먼저 흔들린다 는 메시지를 풀었다. 그 흔들림에 대비해 시작 단계에서 결정해두어야 하는 게 무엇인가가 다음 질문이다. 흔한 답은 "WBS를 잘 짜자"다. 그러나 WBS는 세 가지 결정 중 하나 에 불과하다. 그룹 통합 ERP를 S/4HANA Cloud 도입 프로젝트로 옮기는 한 그룹사 사례의 시작 단계에서, 잘 잡아야 했던 세 가지를 정리한다. 조직 — 누가 결정하는가 WBS보다 먼저 정해져야 할 것은 의사결정 라인이다. 조직도와 비상연락망은 보통 한 묶음의 행정 산출물로 다뤄진다. 그러나 그룹 통합 ERP 프로젝트에서 이 둘의 무게는 단순한 행정의 무게가 아니다. 본사 IT, 복수 계열사, SI 컨설팅사, SAP 본사 — 최소 네 개 주체가 동시에 결정에 관여하고, 결정 단위마다 서로 다른 권한 구조 를 갖는다. 표준 회귀 vs 변형 결정은 본사 IT의 합의가 필요하고, 모듈 단위 To-Be 설계는 계열사 현업의 동의가 필요하고, PCE 환경 설정은 SAP의 가이드를 받아야 한다. 이 프로젝트의 조직도와 비상연락망이 같은 단계에 묶여 있는 건 우연이 아니다. 비상연락망은 escalation path의 명문화 다. 누가 어디까지 결정하고, 어디서 막히면 누구로 올라가는가 — 이 라인이 시작 단계에 합의되지 않으면, 개발 단계에서 결정을 받지 못한 이슈가 누적 된다. 조직도는 박스를 그리는 일이지만, 의사결정 라인은 화살표를 그리는 일 이다. 이 화살표가 그려져 있으면 개발 단계의 모호한 이슈도 며칠 안에 결판이 난다. 그려져 있지 않으면 같은 이슈가 회의실에 일주일씩 잡혀 있다 — 누가 결정하는지 모두가 모르기 때문이다. WBS — 일정과 산출물의 짝짓기 WBS는 일정표가 아니라 산출물의 지도다. 흔한 WBS는 마일스톤과 일정만 그려놓고 끝난다. 그 결과 후반부 통합 테스트 단계에서 "이 산출물은 누가 책임지나?...

ERP 클라우드 전환 의사결정이 끝나면, IT 담당자와 PM은 곧장 "이제 뭘 먼저 바꿔야 하나"라는 질문에 부딪힌다. 흔한 오해는 코어 시스템(SAP 자체)만 갈아끼우면 된다는 가정이다. 실제로 일을 시작해보면 가장 먼저 흔들리는 건 코어가 아니라 코어 주변 이다. On-Prem SAP에서 S/4HANA Cloud PCE로 가는 한 그룹사 마이그레이션 프로젝트의 시작 단계에서, 가장 먼저 바뀐 세 가지를 정리한다. 시스템 토폴로지(시스템 간 연결 구조)가 먼저 바뀐다 코어가 바뀌는 게 아니라 코어 주변이 먼저 흔들린다. On-Prem 시절 BW(Business Warehouse)는 단순했다. SAP ERP 한 곳에서 데이터를 받아 모델링하고 리포트로 풀어내면 됐다. 소스시스템은 사실상 하나, 네트워크 경로는 사내, 권한 모델은 통합. S/4HANA Cloud PCE로 옮겨가면 이 전제가 흔들린다. BW가 PCE 환경의 데이터를 어떻게 끌어올지, 기존 On-Prem BW를 그대로 둘지 함께 옮길지, 인터페이스 계정 권한을 어떻게 재설계할지 — 이 문제들이 코어 전환 전에 결판나야 한다. 이 그룹사 프로젝트에서도 BW 분과의 초기 산출물은 "소스시스템 변경(안)" 문서였다. 실제 코어 전환보다 한 단계 앞서, 데이터가 어디서 어디로 흐르는가 의 지도를 다시 그리는 일이 시작된 셈이다. WMS와 외부 결재 시스템 같은 주변 인터페이스도 같은 줄 위에 올라온다. PCE는 사내가 아니라 SAP 데이터센터에 있기 때문에, 네트워크·권한·연결 모델 자체가 새 변수가 된다. Configuration의 자유도가 줄어든다 PCE는 클라우드 옷을 입은 On-Prem이 아니다. On-Prem SAP에서는 클라이언트가 Configuration을 비교적 자유롭게 잡았다. RZ010(설정값 리스트)을 뽑아보면, 회사마다 수년간 누적된 커스텀 설정이 수백 줄씩 나오는 게 보통이다. PCE에서는 이 자유도가 좁혀진다. SAP S...