시즌 1의 1~9편을 한 줄로 압축하면, Clean Core를 지킨 PCE 환경을 운영에 안착시키는 9개월의 작업이다. 그러나 같은 원칙이 PCE가 닿지 않는 곳을 동시에 만든다. 10편은 그 경계가 어디인지, 그 너머에 왜 BTP가 있는지를 정리한다. 시즌 2를 여는 다리다.
PCE의 경계 Clean Core가 만든 닿을 수 없는 곳
Clean Core를 지키는 PCE는 모든 것을 풀지 않는 시스템이다.
PCE가 푸는 것은 분명하다. SAP 표준에 충실한 운영, 분기별 업그레이드와의 호환성, 통합 데이터 모델 위의 안정성. 시즌 1의 9편이 만든 결과물이 그것이다. 그러나 PCE는 의도적으로 풀지 않는 영역이 있다. 회사가 자체 정의하는 데이터 모델, SAP 표준 트랜잭션을 벗어난 화면, 외부 시스템과의 깊은 도메인 통합 이런 영역은 PCE 안에서 깨끗하게 작동하지 않는다.
이 영역들을 PCE의 한계라고 읽으면 시스템과 싸우게 된다. 그러나 같은 영역을 Clean Core가 지킨 결과로 바깥에 남은 자리라고 읽으면 다음 단계가 보인다. 경계는 결함이 아니라 설계다. 4편에서 Side-by-Side로 옮겨야 하는 경우를 셋으로 정의했을 때, 이미 그 자리는 PCE 바깥에 존재해야 한다는 것이 합의된 셈이다. 시즌 1을 마치면 이 경계가 정확히 어디에 그려졌는지 보인다.
BTP의 입구 — 별도 시스템이 아니라 역할 분담
BTP는 PCE의 확장팩이 아니라 짝패다.
BTP(Business Technology Platform)를 PCE의 플러그인으로 받아들이면 BTP의 가치를 절반쯤 놓친다. BTP는 PCE 옆에서 독립적으로 운영되는 별도 클라우드 플랫폼이고, CAP(Cloud Application Programming)·Integration Suite·BTP 위 Steampunk가 그 구성 요소다. 핵심은 기능이 아니라 역할 분담이다 PCE는 SAP 표준을 지키고, BTP는 회사 고유 영역을 자유롭게 푼다.
이 분담이 작동할 때 양면 의존이 따라온다. Clean Core가 지켜져야 BTP가 의미 있고, BTP가 있어야 Clean Core가 깨끗하게 지켜진다. PCE 안에 자체 데이터 모델을 욱여넣으면 Clean Core가 흐려지고, BTP에 표준 트랜잭션을 옮기면 BTP가 PCE의 그림자로 전락한다. 둘은 대립하지 않는다 — 같은 시스템 풍경의 두 자리일 뿐이다. 이 분담을 시작 단계에 합의하지 않으면, 어느 한쪽이 다른 한쪽의 짐을 지면서 둘 다 불안정해진다.
분담을 늦게 하면 시즌 2의 시그니처 메시지
늦은 분담은 라이센스에서 가장 먼저 무거워진다.
PCE 도입과 BTP 도입을 분리해서 결정하는 그룹사가 많다. PCE 협상이 끝나고 운영이 안착되면, 그 다음 단계에서 BTP를 다시 협상한다. 이 분리가 일견 합리적으로 보이지만, 실제로는 두 번의 라이센스 협상과 두 번의 인력 확보와 두 번의 학습 곡선을 만든다. 더 무거운 비용은 CBO에서 발생한다. 1·3·4편에서 본 CBO 분류 결정이 시작 단계에 끝나지 않은 채 PCE 운영에 들어가면, 어느 CBO를 BTP 사이드카로 옮길지가 후처리 작업이 된다.
이 두 가지, 라이센스 협상의 분리와 CBO 사이드카 전환의 후처리 — 가 시즌 2의 11편과 12편의 시그니처 메시지다. 11편은 PCE 결정 시 BTP를 함께 결정해야 하는 라이센스의 함정을, 12편은 CBO를 BTP로 옮기는 진짜 비용을 다룬다. 시즌 1에서 본 시작 단계 결정의 무게가 BTP 영역에서 한 번 더 작동한다는 사실은, 시즌 2 전체의 출발점이다.
한 줄로
PCE는 Clean Core를 지킨 SAP이고, BTP는 Clean Core 바깥에 회사를 둔 자리다. 둘이 짝패로 작동할 때 ERP 전환은 프로젝트의 종결이 아니라 그룹사 디지털 전환의 시작이 된다. 시즌 2 첫 편(11편)에서 그 시작점이 어디에서 가장 먼저 무거워지는지 본다. BTP 라이센스의 함정.
댓글
댓글 쓰기