글

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는 회사 고유 영역을 자유롭게 푼다. ...
댓글 쓰기
자세한 내용 보기

SAP Go-Live 안정화 — Hyper Care 3가지 원칙

이미지
8편에서 Cutover의 5일이 끝나는 지점이 D+1이라는 시작점 이라고 짚었다. 그 시작점부터 약 30일이 Hyper Care다. 이 30일은 시스템이 안정화되는 기간이라기보다는 조직이 새 시스템에 적응하는 기간이다. 한 그룹사 PCE 전환 사례에서, 운영 개시 직후 한 달이 어떻게 세 가지 원칙 으로 굴러갔는지 본다. 변경 최소화 — 지루함이 안전이다 오픈 직후의 안전은 새로운 일을 하지 않는 것 에서 온다. Hyper Care 기간의 가장 흔한 실수는 작은 개선 요청에 즉시 반응 하는 것이다. 사용자가 "이 화면에 항목 하나만 추가하면 좋겠다"고 보내면, 운영팀은 별로 큰 일이 아니라고 생각해서 빠르게 반영한다. 그러나 PCE 같은 통합 시스템에서 작은 변경 한 건 은 잠재적으로 미식별 의존성 을 건드린다. 7편에서 본 Role-Catalog-Tile-매뉴얼의 4단 매핑이 그 예다 — Tile 하나를 바꾸면 그 Tile을 보는 Role이, 그 Role을 가진 사용자가, 그 사용자에게 배포된 매뉴얼이 조용히 어긋난다. 원칙은 단순하다 — 비상 변경(Critical/Hotfix)만 허용 . 신규 기능 배포는 일단 멈추고, 사용자 요청은 목록 에만 쌓아둔다. 작은 수정 한 건이 미식별 의존 을 깨뜨려 다른 기능을 멈추게 할 수 있다는 가능성을 늘 의식해야 한다. 이 원칙이 지루하게 느껴진다면 그것이 정확히 원하는 상태 다 — Hyper Care 기간의 지루함 은 안정 운영이 작동하고 있다는 신호다. 시스템 자체에 변화가 적을수록, 사용자가 새 시스템에 적응할 시간을 얻는다. 모니터링 최대화 — 보는 것을 늘리기 변경을 줄이는 만큼 보는 것 을 늘린다. Hyper Care의 모니터링은 네 갈래 로 작동한다. 첫째, SXI_MONITOR — 인터페이스 송수신 로그. 6편 일탈 사례에서 LIMS 인터페이스 차단의 검증에 쓰인 도구다. 둘째, MB51 — 재고 이동 이력. 품질재고 → 가용재고 같은 상태 전환이 정상 범위...
댓글 쓰기
자세한 내용 보기

SAP Cutover & Go-Live — 마지막 24시간의 시퀀스

이미지
시즌 1의 1~7편이 결정과 설계 에 관한 이야기였다면, 8편은 그 결정이 시간 위에서 작동하는 순간 에 관한 이야기다. PCE Cutover & Go-Live는 흔히 D-Day 24시간 으로 압축되어 이야기되지만, 실제 작업은 D-3에서 D+1까지의 5일 위에서 분 단위로 굴러간다. 한 그룹사 PCE 전환 사례에서, 마지막 5일이 어떻게 시간 단위 로 조각나서 진행됐는지 본다. D-3 ~ D-1 — 사전 작업: 환경 조건을 운영에 일치시키기 오픈 직전 3일은 운영 환경의 조건 을 마지막으로 맞추는 시간이다. D-Day에 시스템을 옮기는 일은 그 자체로는 짧다. 길고 위험한 것은 옮길 수 있는 상태 를 만드는 사전 작업이다. 본 프로젝트의 오픈 시나리오에서 D-3(12.29)에 Migration CTS 반영 과 DataSource 활성 프로그램 실행 이 잡혀 있다. CTS(Change and Transport System)는 SAP 객체 이관의 표준 채널이고, Request List 에 잡힌 객체들이 순서대로 운영 시스템에 반영된다. 7편의 Fiori Role·Tile 설정도 이 시점에 마지막 점검 이 이뤄진다 — DW Fiori 초기 Setting 가이드 와 Fiori Role Tile Check List 가 별도 산출물로 잡혀 있는 이유다. D-2(12.30)는 SAP 표준 Setting 점검의 날이다 — LO Cockpit Setting 점검 , CO-PA Setting 점검 , DataSource 활성화 점검 . 이 점검은 코드 검증 이 아니라 Configuration 상태 검증 이다. 6편의 일탈 사례에서 본 것처럼, 환경 조건 이 운영과 다르면 코드는 통과해도 시스템은 깨진다. 이 3일 동안의 점검은 D-Day 작업의 입력값을 보장하는 일이다 — D-Day가 잘 굴러갈지의 90%는 D-3에서 결정된다. D-Day — 24시간의 시퀀스: BWP 백업 → 소스시스템 변경 → 데이터 추출 D-Day는 분 단위로 잡힌 일정표 위...
댓글 쓰기
자세한 내용 보기

SAP Fiori Role 설정 — 권한 설계와 사용자 교육의 짝패

이미지
5편에서 데이터소스의 동기화 전략을, 6편에서 운영 직후 일탈 사례를 봤다. 7편의 질문은 다르다 — 그래서 누가 그 시스템을 어떻게 쓰는가 . PCE 전환 프로젝트에서 Fiori Role 설계와 사용자 교육은 서로 다른 작업 처럼 보이지만, 실제로는 같은 결정의 두 얼굴 이다. 한 그룹사 PCE 전환 사례에서, RZ040부터 사용자 매뉴얼까지 4단 매핑이 어떻게 변화관리 자체가 되었는지 본다. RZ040 — Role 설계가 변화관리의 출발점이다 Role은 권한의 명단이 아니라 변화관리 대상자의 명단이다. RZ040(사용자 Role 정의서)은 SAP에서 누가 무엇을 할 수 있는가 를 모듈 단위로 정리한 산출물이다. 본 프로젝트의 As-is 분석 폴더에는 RZ040이 FI·MM·SD·CO·PP·QM·IM·EX 8개 모듈로 각각 잡혀 있다. 8개 파일이 따로 분리된 것은 우연이 아니다 — 모듈마다 권한 단위가 다르고, 변화관리 강도도 다르다 . FI(재무)의 Role 한 줄과 PP(생산)의 Role 한 줄은 같은 무게로 다뤄질 수 없다 . Role은 본질적으로 한 사람의 하루 를 정의한다. SD Role을 받은 영업담당자는 그 안에서만 화면을 본다. PP Role을 받은 생산담당자는 다른 화면을 본다. 그러니까 Role 정의서가 모듈별로 완성되는 순간 , 그 모듈을 쓰는 사용자 명단도 함께 고정 된다. Role 정의가 끝나는 순간 변화관리 대상자 명단이 함께 끝난다 — Role 한 줄 옆에 어떤 부서, 어떤 역할의 사용자 가 따라붙는지 채워두면 변화관리 부서는 그 명단으로 교육 계획을 짜기 시작한다. Catalog Group → Tile — Role을 화면 위에 펼치기 Catalog Group은 Role과 Tile의 다리다. Fiori 환경에서 사용자가 실제로 보는 것은 Tile이다. Tile은 SAP 트랜잭션이나 앱을 화면 위 작은 카드 로 펼친 단위다. Role이 정의됐어도, 그 Role에 어떤 Tile이 붙는가 가 따로 매핑되어야 한다...
댓글 쓰기
자세한 내용 보기

SAP QM 검사로트 일괄합격 일탈 — CSV가 놓친 한 가지

이미지
  3편에서 As-is 산출물의 결정 트리거를 정리했고, 4편에서 CBO 개발의 3단계 위계를 다뤘다. 그러나 자료를 결정으로 읽지 못하고 문서로 쌓아둔 결과가 어떻게 나타나는지는 별개의 이야기다. 한 그룹사 PCE 전환 프로젝트가 운영 개시 직후 2026년 1월 초 에 마주한 품질재고 일괄 합격 일탈 사례를 본다. 사건은 GMP 사이트 9곳을 포함한 10개 플랜트에서 동시에 발생했고, 그 원인은 CSV 테스트 단계에서 놓친 한 가지 에 있었다. 일탈의 모습 — 생산오더 빈값에서 시작된 일괄 합격 검사로트 한 건이 전체 플랜트의 검사대기 재고를 끌고 갔다. LIMS(외부 품질관리 시스템)에서 SAP로 시험 결과를 보내면, SAP는 해당 검사로트를 합격으로 판정하고 재고 상태를 품질재고 → 가용재고 로 전환한다. 정상은 해당 검사로트에 대해서만 판정이 적용되어야 한다. 그러나 운영 개시 직후 발생한 일탈은 3~4초 간격으로 동일 시점 검사대기 재고가 일괄 가용으로 전환 되는 현상이었다. 원인의 출발점은 한 가지였다 — 생산오더 값이 빈값(blank)으로 산출된 검사로트 . PCE 마이그레이션 시 생산입고 검사유형(코드 04)의 검사로트는 생산오더와 함께 정상 이관되었다. 그러나 LIMS에서 판정 결과를 수신할 때, 검사로트와 생산오더를 매핑하는 마이그레이션 매핑 테이블 조회에서 일부 로트의 생산오더가 빈값으로 반환됐다. 이 빈값이 다음 단계의 SQL 조회 조건으로 들어가면서, 생산오더가 빈값인 모든 검사로트 가 일괄 합격 처리 대상으로 포함됐다. 한 검사로트의 빈값이 플랜트와 무관하게 전사 검사대기 재고를 끌고 가는 구조가 그 짧은 순간에 작동한 것이다. CSV 테스트가 놓친 한 가지 — 운영 환경 조건 미반영 테스트는 운영의 마이그레이션 상태를 그대로 재현하지 못했다. PCE 전환의 CSV(Computer System Validation) 단계는 2차·3차 테스트로 구성된다. 이 단계의 핵심은 운영에서 발생할 모든 시나리오를 ...
댓글 쓰기
자세한 내용 보기

S/4HANA Cloud BW 데이터 연계 — 데이터소스 3분류 동기화

이미지
1편에서 PCE 전환 시 BW가 가장 먼저 흔들린다는 점을 짚었다. 5편은 그 흔들림이 어디서 어떻게 작동하는지를 본다. PCE 마이그레이션의 기본 전제 하나 — PCE에는 Open Item만 이관된다 . 과거 데이터는 BW에 남거나 별도 백업으로 보관된다. 이 전제가 BW 데이터 연계를 단순 마이그레이션이 아니라 데이터소스 성격에 따른 동기화 전략 분기 문제로 만든다. 한 그룹사 BW 분과의 PCE 연계 작업에서, 데이터소스 80여 개 CBO와 100여 개 STD가 어떻게 세 갈래로 갈라졌는지 본다. CBO 데이터소스 — 기간 기준 동기화가 가능한 영역 회사가 직접 만든 데이터소스는 가장 다루기 쉬운 영역이다. CBO 데이터소스(ZBIF_KNA1_001, ZSD_A701_001 같은 Z 접두사로 시작하는 generic D/S)는 회사가 직접 정의했기 때문에 추출 시점, 추출 키, 데이터 적재 기간을 직접 통제 할 수 있다. 본 프로젝트의 데이터소스 현황 산출물에서 CBO 데이터소스는 80여 개가 잡혀 있고, 대부분 SDI 기반 (SDIEABA100, SDIBABA100)이다. SDI(Smart Data Integration)는 HANA에서 외부 시스템 데이터를 가상 또는 복제 방식으로 연결하는 방식이고, 이 위에서 만든 generic D/S는 추출 로직이 회사 손 안에 있다 . 이 영역의 동기화 전략은 단순하다 — PCE의 데이터 적재 기간을 고려하여 기간 기준으로 동기화 . "이 시점부터 이 시점까지의 데이터를 가져와라"는 명령이 그대로 통한다. 여기서 막히는 일은 거의 없다. 기간만 정확히 잡으면 데이터는 원하는 대로 들어온다. CBO 데이터소스의 정의 자체가 동기화 가능성의 첫 번째 자산이다 — 회사가 자기가 만든 것은 자기가 끌어올 수 있다. PCE 전환 직전 80여 개 CBO 데이터소스 중 무엇을 살리고 무엇을 폐기할지 가 시작 단계에 정리돼 있어야 이 동기화가 실제로 가볍게 끝난다. STD-FCM 데이터소스 — ...
댓글 쓰기
자세한 내용 보기

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 개발자가 가장 적응하기 쉬운 영역 — ...
댓글 쓰기
자세한 내용 보기

As-is 산출물에서 To-Be 설계로, 결정 트리거 3가지

이미지
  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 설계 회의는 매번 같은 자리에서 막힌다. ...
댓글 쓰기
자세한 내용 보기

S/4HANA Cloud 도입 프로젝트 시작, 잘 잡아야 할 3가지

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

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

이미지
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...
댓글 쓰기
자세한 내용 보기