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 설계 회의는 매번 같은 자리에서 막힌다.
평가의 기준을 제시하고, 컨설턴트 와 현업 PI의 의견을 조화롭게 적용하는 것이 PM의 가장 큰 책무이고 프로젝트 성공을 좌우하는 Key가 될 것이다. 이번 프로젝트도 초기 컨설턴트의 주도에 PI 의견은 여전히 부족했고, 그걸 해결하기 위해 우리는 모듈별 합숙을 일주일 정도 수행했어야 했다. 당장의 비용은 큰 지출로 보이지만, 이런 투자가 이후 단계의 비용을 감소 시켜 줄 것이라 믿었다.
CBO List → BTP / 표준 흡수 / 폐기 3분류
CBO 인벤토리는 코드 목록이 아니라 분류 의사결정의 작업장이다.
CBO Program List(D2)가 모듈별로 별도 산출물로 잡혀 있다는 건 프로그램별로 분류 결정이 필요하다는 뜻이다. 이번 프로젝트의 As-is 시스템 분석 폴더에는 모듈별 CBO List 외에 그룹사 통합 SAP_CBO 사용현황_Detail까지 따로 잡혀 있다. 사용 빈도와 사용자 풀이 분류의 두 번째 입력이 된다. 매일 쓰이는 CBO와 분기에 한 번 쓰이는 CBO는 같은 무게로 결정될 수 없다. 이유는 간단하다, 사용자는 실행 빈도와 관계 없이, 실제 프로세스와 관계 없이 현재 시스템에 녹아 있기 때문이다.
분류는 세 갈래다. 첫째, PCE 표준 기능에 흡수되는 CBO 폐기. 둘째, 표준에 없지만 업무 본질에 가까운 CBO BTP 사이드카 (또는 Embedded Steampunk)로 옮긴다. 셋째, 표준에도 없고 BTP로 옮길 가치도 없는 역사적 잔재 사용자 합의 후 폐기. 이 결정의 80%는 시작 단계에 끝나야 한다. 나머지 20%는 통합 테스트(CSV) 단계에서 사용자 반응을 보고 보정한다. 순서가 뒤집히면 분류를 미루고 개발에 들어가면 CSV 단계에서 누군가의 매일 업무가 끊기는 사고가 난다. 이 부분의 실제 사례는 시리즈 6편에서 따로 다룬다.
To-Be Process List → 변화관리 범위
To-Be Process List는 프로세스 정의가 아니라 변화관리 범위의 정의다.
To-Be Process List(D1)는 어떻게 일할 것인가의 그림처럼 보이지만, 실은 누군가의 혁신에 대한 열망, 본인 업무에 대한 깊이다. 같은 프로세스를 As-is와 To-Be로 그려놓고 차이가 작은 줄은 변화관리 부담이 적고, 차이가 큰 줄은 변화관리 부담이 크다. 이번 프로젝트의 To-Be Process List를 모듈별로 본다는 것은 모듈별로 변화관리 강도를 달리 가져가야 한다는 뜻이다.
여기서 자주 빠지는 결정이 변화관리 범위다. To-Be 프로세스 정의는 끝났는데, 그 정의가 누구의 일상을 어떻게 바꾸는가가 시작 단계에 잡히지 않으면, 사용자 매뉴얼 단계와 사용자 교육 단계에 가서야 폭발한다. 이번 프로젝트의 산출물에 사용자 메뉴얼 폴더가 As-is 분석 폴더 안에 같이 묶여 있는 건 우연이 아니다. As-is 분석부터 바뀔 사용자의 명단을 함께 잡아야 한다는 뜻이다. To-Be Process List의 한 줄마다 영향을 받는 역할(Role)과 부서를 같이 채워두면, 7편의 Fiori Role 설계와 사용자 교육이 자연스럽게 연결된다.
한 줄로
As-is 산출물은 결정을 위한 입력이고, To-Be 설계는 그 결정의 출력이다. RZ010·CBO·To-Be Process 세 산출물은 각각 표준 회귀 점수·분류 결정·변화관리 범위라는 결정 트리거를 작동시킨다. 산출물을 문서로 쌓아두면 폴더만 늘어나고, 결정 트리거로 읽으면 본격 개발 단계의 비용이 줄어든다. 이 결정 트리거 중 BTP 사이드카 분류는 라이센스와 동시에 결정되어야 한다 그 이유는 시리즈 11~12편에서 다룬다.
댓글
댓글 쓰기