이 블로그에 대하여

Kronopia는 SAP S/4HANA Cloud 전환 프로젝트를 직접 경험하며 쌓은 실무 인사이트를 기록하는 블로그입니다.

대기업 그룹사의 ERP 통합 전환 프로젝트에 참여하면서, 시작 단계 설계부터 Go-live까지의 과정에서 겪은 실제 의사결정과 사례를 공유합니다. 교과서에 나오지 않는 것들 — As-is 산출물을 어떻게 읽을 것인가, CBO를 어느 시점에 정리해야 하는가, 변화관리는 언제부터 시작해야 하는가 — 을 다룹니다.

SAP S/4HANA Cloud PCE 전환을 맡고 있는 컨설턴트, PM, 현업 PI, IT 담당자에게 실질적인 도움이 되길 바랍니다.

---

■ 다루는 주제
- SAP S/4HANA Cloud PCE 전환 방법론
- As-is 분석과 To-Be 설계의 연결 고리
- CBO/Extensibility 결정 기준
- BTP 사이드카 설계
- Fiori Role 설계와 사용자 교육
- 변화관리와 Go-live 준비
- PI 에서 FDE의 방법론 전환
■ 블로그 운영자
SAP ERP 전환 프로젝트 실무 경험을 가진 PM/컨설턴트가 직접 작성합니다.

문의: [Jeong790505@gmail.com]

이 블로그의 인기 게시물

S/4HANA Cloud PCE 전환 시작 단계, 가장 먼저 바뀌는 3가지

ERP 클라우드 전환 의사결정이 끝나면, IT 담당자와 PM은 곧장 "이제 뭘 먼저 바꿔야 하나"라는 질문에 부딪힌다. 대부분의 현장에서는 '코어만 바꾸면 되죠.'라는 가정으로 시작한다. 이러한 가정이 이 글을 쓰게 된 이유다. 실제로 일을 시작해보면 가장 먼저 흔들리는 건 코어가 아니라 코어 주변 이다. 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(설정값 리스트)을 뽑아보면, 회사마다 수년간 누적된 커스텀 설정이 수백 줄씩 나오는 게 보통이...

자세한 내용 보기

S/4HANA Cloud CBO 개발 3단계 — 어디까지 위에서 끝내는가

1·2·3편을 거쳐 As-is 산출물의 결정 트리거가 작동했다고 치자. CBO List는 BTP / 표준 흡수 / 폐기 로 분류되었고, RZ010은 표준 회귀 / 변형 / 위성 으로 점수가 매겨졌다. 그 다음 질문 — 변형으로 가야 할 항목을 어떻게 개발하는가. PCE는 On-Prem이 아니다. 자유롭게 ABAP을 수정하던 시절의 도구는 일부만 남았다. PCE 전환 사례에서, CBO 개발 결정이 어떻게 3단계 위계로 정리됐는지 본다. Key User Extension으로 끝내도 되는 경우 가장 안전한 출발점은 가장 가벼운 도구다. PCE에서 새로 추가하거나 변형해야 할 항목을 받으면, 첫 번째 질문은 항상 같다 — 이걸 Key User Extension으로 풀 수 있는가 . Key User Extension은 비개발자(현업 키 유저)가 UI 도구로 필드를 추가하고, 양식을 바꾸고, 작은 룰을 거는 SAP 공식 확장 방식이다. 화면 하나에 필드 두 개 추가, 송장 양식 마스킹 변경, 사용자 정의 데이터 캡처 — 이런 작은 변형 의 대부분은 여기서 끝나야 한다. 이걸 건너뛰는 것 이 흔한 함정이다. 구관(舊官) ABAP 개발자가 보면 Key User Extension은 권한이 부족한 도구 처럼 보인다. 그래서 일단 Embedded Steampunk나 BTP로 직행한다. 결과는 작은 일에 큰 도구 를 쓴 것 — 변경관리도 무거워지고, 운영도 무거워진다. Key User로 끝낼 수 있는 일을 Embedded로 가져가면, SAP 표준 업그레이드마다 회귀 테스트 부담이 따라온다. PCE의 Clean Core 원칙은 여기서 시작된다. Embedded Steampunk가 필요한 경우 표준 동작을 비틀어야 할 때, 같은 시스템 안에서 푸는 옵션. Embedded Steampunk(in-app extensibility)는 PCE 안에서 ABAP for Cloud로 직접 코드를 작성하는 방식이다. 기존 ABAP 개발자가 가장 적응하기 쉬운 영역 — 익...

자세한 내용 보기

SAP PCE에서 BTP로 — Clean Core의 두 자리

시즌 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는 회사 고유 영역을 자유롭게 푼다. ...

자세한 내용 보기

Kronopia

이 블로그 검색