S/4HANA SI-CHECK은 Readiness Check와 달리 Simplification Item 단위로 FI/TR 전환 영향과 Blocking 요소를 상세 점검하는 도구입니다. FI-AA, CVI, Universal Journal, Cash Management, TRM을 반드시 확인해야 하며, Warning 항목도 무시하면 안 됩니다. 결과는 기능별 영향도 리스트로 재분류해 Task Breakdown과 Conversion Plan에 연결해야 하며, Customizing·Data·Custom Code 정합성을 함께 검증해야 안정적인 전환이 가능합니다.
- SI-CHECK의 본질 — Simplification Item이란 무엇인가
- Readiness Check vs SI-CHECK — 뭐가 다른가요?
- IMG 설정 경로 및 실행 단계 — 직접 돌려보려면
- 주요 포인트 / 실무 팁 — 현장에서 배운 것들
- SAP Error Code 해결 — 자주 마주치는 오류들
- 마무리 — 3줄 요약과 다음 단계
- 참고 출처
- 메타 디스크립션 제안
도입부 — “Readiness Check만 돌리면 되지 않나요?”
S/4HANA SI-CHECK 무엇인가를 처음 접하면, Readiness Check만 돌리면 충분한 것 아닌가라는 의문이 대부분 생깁니다. 저도 초기에 이 질문을 수없이 받았고, 솔직히 처음엔 저 자신도 ‘그렇지 않을까?’ 싶었던 순간이 있었습니다. 그런데 막상 Prepare Phase에서 SI-CHECK 결과를 까보면, 전혀 다른 이야기가 펼쳐집니다.
실제 프로젝트에서 이런 케이스가 있었는데요. Readiness Check 결과는 “큰 문제 없음”으로 나왔는데, 나중에 SI-CHECK을 돌려보니 CVI(Customer/Vendor Integration) 관련 마스터 정합성 이슈, New Asset Accounting 전환 선행 조건 미충족, Classic Cash Management 구조 변경 영향이 무더기로 나왔습니다. 당연히 일정이 늦어졌고, FI/AA 설계를 다시 하는 상황이 발생했습니다. 아찔한 경험이었죠.
이 글은 아래 분들께 특히 도움이 됩니다.
- S/4 전환 프로젝트에 투입된 FI/TR 컨설턴트
- 사전 영향도 분석을 수행해야 하는 시니어·리드 컨설턴트
- 운영 시스템에서 사전 점검을 준비하는 담당자
SI-CHECK의 본질 — Simplification Item이란 무엇인가
S/4HANA SI-CHECK 무엇인가, 한 문장으로 정의하면
S/4HANA SI-CHECK은 SAP가 S/4HANA로 오면서 제거·대체·통합·구조 변경한 기능 목록(Simplification Item Catalog)을 기준으로, 현재 ECC 시스템이 어떤 영향을 받는지 기술적으로 점검하는 리포트입니다. 단순한 설정 일관성 검사가 아니라 “전환 시 무엇이 바뀌어야 하는가”를 체계적으로 식별하는 도구라고 보면 됩니다.
SAP가 S/4HANA를 설계할 때 기존 ECC의 수많은 기능을 재구조화했습니다. 예를 들면 BKPF/BSEG 중심의 FI 테이블 구조는 ACDOCA(Universal Journal) 로 통합되었고, Classic Asset Accounting은 New Asset Accounting 으로 전환되었습니다. Cash Management도 One Exposure from Operations 구조로 바뀌었죠. 이런 변경사항 하나하나가 “Simplification Item”으로 관리되고, SI-CHECK은 이 목록을 내 시스템에 대입해 어떤 항목이 영향을 받는지 검사합니다.
Simplification Item Catalog 구조
각 Simplification Item은 아래 구성 요소를 가집니다.
| 구성 요소 | 내용 |
|---|---|
| ID | 항목 식별자 (예: FIN_AA_PARALLEL_VAL) |
| Business Impact | 업무적으로 어떤 변화가 발생하는지 |
| Technical Impact | 테이블, 프로그램, 설정, T-code 측면의 변경 사항 |
| Check Class / Check ID | 시스템에서 실제 점검을 수행하는 기술적 식별자 |
이 Catalog는 고정된 문서가 아닙니다. SAP는 SPS, Feature Pack, 신규 버전에 따라 지속적으로 업데이트하기 때문에, SI-CHECK 실행 전에 반드시 최신 SAP Note 및 Catalog 반영 여부를 확인해야 합니다. 대표 참조 Note로는 SAP Note 2185390이 널리 언급되며, 대상 S/4 릴리스에 맞는 추가 Note를 반드시 병행 확인하세요.
FI/TR에서 걸리는 주요 Simplification Item 묶음
FI/TR 관점에서 아래 영역별로 묶어 접근하면 실무에서 분석이 훨씬 수월합니다.
| 영역 | 주요 Simplification Item 예시 |
|---|---|
| FI-GL | New GL, Universal Journal, Document Splitting, Ledger 구조 |
| FI-AA | New Asset Accounting 필수화, 병렬평가/감가상각 영역 영향 |
| AP/AR | Customer/Vendor → Business Partner 전환(CVI) |
| TR/Cash | Classic Cash Management → One Exposure, BCM, IHC 구조 변경 |
| TRM | Flow/Position 관리 구조, 평가·회계 연계 로직 변경 |
Readiness Check vs SI-CHECK — 뭐가 다른가요?
두 도구의 성격 비교
이 비교는 Prepare Phase 킥오프 때마다 반복됩니다. 결론부터 말씀드리면, 두 도구는 경쟁 관계가 아니라 초기 진단과 상세 분석으로 연결되는 관계입니다.
| 구분 | Readiness Check | SI-CHECK |
|---|---|---|
| 형태 | 대시보드 기반 요약 리포트 | Simplification Item 단위 상세 점검 |
| 주 사용자 | 경영진, PM, 아키텍트 | FI/TR 컨설턴트, Basis, ABAP 개발자 |
| 목적 | 초기 진단·보고 | Conversion Blocking 요소 식별 |
| 기술 깊이 | 넓고 얕음 | 좁고 깊음 (ABAP, Table, Config 수준) |
| 결과 활용 | 방향성 결정, 경영층 보고 | Task Breakdown, Conversion Plan 입력 |
핵심 관계는 이것입니다. Readiness Check의 일부 항목은 SI-CHECK 결과를 집계해서 보여주는 형태입니다. 즉, Readiness Check가 “빨간불”을 켜줬다면, 왜 빨간불이 켜졌는지는 SI-CHECK에서 파야 합니다.
S/4HANA 변경사항을 보면 S/4HANA 2020 이후로 SAP Readiness Check가 클라우드 기반 서비스로 개선되면서, Custom Code 분석과 SI-CHECK 결과 연계 범위가 더욱 강화되었습니다. SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.
IMG 설정 경로 및 실행 단계 — 직접 돌려보려면
사전 준비 — 이것부터 챙겨야 합니다
SI-CHECK은 그냥 T-code 치고 실행한다고 끝나는 게 아닙니다. 현장에서 자주 마주치는 상황이에요. 아무런 사전 준비 없이 돌렸다가 결과가 불완전하거나, 최신 Catalog가 반영 안 된 채로 분석해서 항목을 놓치는 케이스입니다.
반드시 챙겨야 할 선행 작업:
| 선행 항목 | 내용 |
|---|---|
| SAP Note 최신화 | SAP Note 2185390 및 대상 릴리스 관련 Note 적용 |
| ST-PI / ST-A/PI 업데이트 | 버전이 오래되면 체크 결과 누락 가능 |
| Add-on 호환성 확인 | 비호환 Add-on 존재 시 전환 자체가 Block될 수 있음 |
| Business Function 활성화 상태 점검 | 활성화 상태에 따라 SI 영향 범위가 달라짐 |
| 커스텀 코드 현황 파악 | Z 프로그램 분포 사전 파악 (ATC 연계 준비) |
핵심 T-code
SYCM: Simplification Item Catalog Management — Catalog 관리 및 영향 분석 결과 조회RC_S4_PRE_TRANSITION_CHECKS: 사전 전환 점검 리포트 실행
과거에는
/SDF/RC_START_CHECK로 많이 실행했지만, 릴리스에 따라 실행 방식이 다를 수 있습니다. SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.
SPRO 경로 (간접 관련)
SPRO → SAP Reference IMG
→ Cross-Application Components
→ General Application Functions
→ Simplification Item
모든 작업이 IMG에서 직접 이루어지는 건 아니지만, 프로젝트 문서화나 설정 검토 시 이 경로를 알고 있으면 도움이 됩니다.
실행 단계 흐름
[사전 준비]
SAP Note 최신화 → ST-PI/ST-A/PI 업데이트 → Add-on 호환 확인
↓
[Catalog 활성화]
SYCM → Simplification Item Catalog 다운로드 및 활성화
↓
[Check Variant 선택]
FI/TR 관련 항목 포함 여부 확인 (FI-AA, CVI, Cash, TRM 등)
↓
[Background Job 실행]
RC_S4_PRE_TRANSITION_CHECKS → 백그라운드 실행 (시스템 부하 고려)
↓
[결과 조회 및 분류]
SYCM → Simplification Database → Impact Level별 분류
▲ 이 흐름대로 실행하면, Catalog 미반영이나 Variant 누락으로 인한 분석 오류를 줄일 수 있습니다.
결과 Impact Level 해석
| Impact Level | 의미 | 실무 대응 |
|---|---|---|
| Error (Must Fix) | 전환 전 반드시 조치 필요 | 즉시 Task 등록, 담당자 배정 |
| Warning | Blocking은 아니나 실제 영향 큰 경우 많음 | 반드시 세부 분석 필요, 무시 금지 |
| Information | 참고 정보, 후속 분석 필요할 수 있음 | 설계 단계에서 반영 여부 검토 |
후행 작업 — 결과가 나온 후가 진짜 시작입니다
SI-CHECK은 진단 리포트이지, 그 자체가 목적이 아닙니다. 결과가 나오면 반드시 아래로 연결해야 합니다.
- CVI 프로젝트 착수 (Business Partner 전환 준비)
- Data Cleansing 작업 (마스터/전표 정합성 정비)
- Customizing 정비 (FI-AA, New GL, Special Ledger 등)
- Custom Code 영향 분석 (ATC 연계)
- Task Breakdown 작성 → Conversion Plan 반영
주요 포인트 / 실무 팁 — 현장에서 배운 것들
프로젝트에서 반드시 확인하는 4가지
FI/TR 중심 Brownfield 프로젝트라면 아래 네 가지는 Prepare Phase 시작과 동시에 점검해야 합니다. 늦게 발견하면 반드시 일정에 영향을 줍니다.
| 필수 확인 항목 | 왜 중요한가 |
|---|---|
| FI-AA (New Asset Accounting) | S/4에서 사실상 필수화, 감가상각 영역 재구성 필요 |
| Business Partner 전환 (CVI) | 고객·거래처 마스터 구조 전면 변경, 선행 정합성 점검 필수 |
| Classic Cash Management 사용 여부 | One Exposure 구조로 전환 시 유동성 관리 데이터 구조 자체가 변경 |
| Special Ledger 사용 여부 | S/4 Ledger 구조와 충돌 가능성 및 데이터 이관 영향 |
FI/TR 핵심 영향 포인트 상세
Universal Journal (ACDOCA)
S/4HANA에서 FI/CO 데이터 구조가 ACDOCA 중심으로 통합됩니다. 이건 단순 테이블 이름 변경이 아닙니다. Z 리포트, 인터페이스, CO/FI Reconciliation 로직, 전표 Enhancement까지 모두 재검토 대상입니다. 현장에서 이걸 과소평가했다가 테스트 단계에서 Z 리포트가 줄줄이 오류나는 경험을 하는 경우가 많습니다.
TRM (Treasury) 영향
TRM에서는 Flow 관리 방식, Position 구조, Market Data 연계, Deal-to-Posting 로직에 영향이 있을 수 있습니다. 특히 시장 리스크 관리, 헤지 회계 영역은 S/4 버전에 따라 지원 방식 차이가 있으니 반드시 세부 확인이 필요합니다.
BCM / In-House Cash
현행 ECC에서 BCM, IHC를 사용 중이라면 S/4에서의 지원 구조 변경을 반드시 확인해야 합니다. 단순 화면 변경이 아니라 은행 커뮤니케이션, 내부 결제 구조 자체에 영향이 올 수 있습니다.
One Exposure from Operations
Classic Cash Management에서 One Exposure로 전환 시 유동성 관리 데이터가 생성되는 방식 자체가 바뀝니다. 구성 요소 단위로 영향도를 정리하지 않으면 나중에 유동성 예측 리포트에서 데이터가 맞지 않는 문제가 발생할 수 있습니다.
실무 팁 3가지
팁 1. SI-CHECK 결과를 반드시 기능별로 재분류하라
표준 SI-CHECK 결과는 Simplification Item 단위라 현업이나 기능팀과 바로 소통하기 어렵습니다. 결과를 받으면 아래처럼 재분류해서 워크숍 자료로 만드는 습관을 들이세요.
FI-GL / FI-AA / AP / AR / TR(Cash/TRM/BCM/IHC) / CVI·BP / Basis·ABAP
이렇게 하면 각 팀별 담당 항목 배분도 명확해지고, Task Breakdown 작성이 훨씬 빠릅니다.
팁 2. Error만 보는 실수를 절대 하지 마라
현장에서 가장 많이 보는 실수입니다. Warning은 지금 당장 Blocking이 아니라고 넘어갔다가, 설계·테스트·마이그레이션 단계에서 범위가 폭발적으로 늘어나는 원인이 됩니다. Warning = “나중에 더 크게 돌아오는 이슈”로 취급하세요.
팁 3. Custom Z Program 영향 분석을 반드시 병행하라
SI-CHECK은 표준 변경 영향 중심입니다. 하지만 프로젝트에서 더 많은 공수가 드는 건 대부분 Z 프로그램 수정입니다. ATC(ABAP Test Cockpit) 기반 Custom Code 분석을 SI-CHECK과 동시에 착수하고, ACDOCA, Business Partner, MATDOC 등 S/4 핵심 구조 변경과 Z 오브젝트의 연계를 반드시 점검하세요.
수행중인 프로젝트에서 SI-CHECK 결과가 100개 넘게 나왔을 때, Error 15개는 빠르게 정리됐는데 Warning 60개가 실제 프로젝트 범위를 두 배 이상 늘린 경험이 있습니다. Warning의 무게감을 초기에 팀 전체가 공유하는 것이 핵심입니다.
Best Practice — SI-CHECK에서 Conversion Plan까지
SI-CHECK 결과를 프로젝트 계획에 연결하는 흐름은 아래가 가장 안정적입니다.
SI-CHECK 실행
↓
영향도 리스트 작성 (기능별 재분류)
↓
Task Breakdown 작성 (담당 컨설턴트·팀 배정)
↓
Conversion Plan 반영 (일정·리소스·의존성)
이 흐름을 지키면 SI-CHECK이 단순 기술 리포트로 끝나지 않고, 실제 프로젝트 일정과 리소스 계획의 기반이 됩니다.
자주 하는 오해 — “SI-CHECK 통과 = 전환 가능?”
이건 틀린 판단입니다. SI-CHECK 통과는 어디까지나 현재 알려진 Simplification Item 기준에서 치명적 설정 문제를 크게 줄였다는 의미에 가깝습니다. 전환에는 아래 변수가 여전히 남습니다.
- 데이터 품질 문제 (마스터 중복, 불완전 데이터)
- 마이그레이션 오류
- 인터페이스·배치잡 영향
- Custom Code 실패
- 테스트 시나리오 누락
SI-CHECK은 필요조건에 가깝지만, 충분조건은 아닙니다. 이 문장을 팀 전체가 공유하는 것이 중요합니다.
“SI-CHECK 다 통과했으니 괜찮다”고 보고한 뒤, UAT 단계에서 FI-AA 자산 마이그레이션 오류가 대량 발생한 프로젝트를 옆에서 지켜본 경험이 있습니다. Customizing 정합성만큼이나 데이터 정합성 검증을 병행하는 것이 얼마나 중요한지 그때 확실히 배웠습니다.
SAP Error Code 해결 — 자주 마주치는 오류들
대표 에러 유형과 해결 방법
| Error / Message | 주요 발생 원인 | 해결 방법 |
|---|---|---|
FIN_CUST_CONS_CHECK |
FI Customizing 정합성 불일치 (New GL 미활성, FI-AA 설정 불완전 등) | IMG에서 New GL 활성화 여부 확인, FI-AA Depreciation Area 재구성, Ledger 설정 정합성 점검 |
FI_CUSTOMIZING_INCONSISTENT |
FI 설정이 S/4 전환 선행조건 미충족 상태 | Business Function 활성화 상태 점검, 관련 Note 적용, CVI Precheck 실행 |
New GL 미활성 관련 오류 |
Classic GL 상태에서 S/4 전환 시도 | New GL 활성화 진행, Document Splitting 요구사항 분석, CO/FI 통합 리포팅 영향 검토 |
CVI 관련 정합성 오류 |
Customer/Vendor 마스터 중복 또는 BP 전환 선행조건 미충족 | CVI Precheck 실행, 번호 범위·그룹핑·역할 매핑 점검, 중복 마스터 정비 |
FI-AA Depreciation Area 관련 오류 |
감가상각 영역과 회계원칙·원장 매핑 불일치 | New Asset Accounting 기준 재설계, 병렬평가 요구사항 재검토 |
실무 사례로 보는 중요한 주의점
현장에서 자주 있는 케이스를 하나 공유합니다. SI-CHECK Error를 전부 해결하고 “준비 완료”로 판단했는데, 실제 Data Migration 단계에서 FI-AA 자산 데이터가 대량 실패하는 상황이 발생합니다. 이유는 하나입니다.
Customizing 정합성 + Data 정합성 + Custom Code 정합성, 이 세 가지가 함께 맞아야 전환이 안정적으로 진행됩니다.
SI-CHECK은 주로 구조적·설정적 영향을 확인합니다. 예를 들어 CVI 매핑은 설정상 맞는데 마스터 데이터가 중복되어 있거나, FI-AA 설정은 맞는데 자산 데이터 자체가 불완전한 경우는 SI-CHECK만으로 완전히 커버되지 않습니다. 따라서 SI-CHECK 결과를 받으면 데이터 품질 점검(Data Quality Assessment)을 반드시 병행해야 합니다.
마무리 — 3줄 요약과 다음 단계
핵심 3줄 요약:
- SI-CHECK은 “전환 가능 여부 판정 도구”가 아니라 “무엇을 바꿔야 하는지 알려주는 도구”입니다. Readiness Check보다 훨씬 기술적이고 실무적이며, 실제 작업 항목으로 연결하기 좋은 분석 수단입니다.
- FI/TR에서는 CVI, FI-AA(New Asset Accounting), Universal Journal, Classic Cash Management(One Exposure), TRM을 반드시 집중 점검해야 하며, Warning 항목을 절대 무시해선 안 됩니다.
- SI-CHECK 결과는 반드시 기능별 영향도 리스트 → Task Breakdown → Conversion Plan으로 연결되어야 하고, Customizing·Data·Custom Code 정합성 세 가지를 함께 검증해야 안정적인 전환이 가능합니다.
비슷한 이슈를 겪으셨거나, 특정 Simplification Item 영향 분석에서 막히신 부분이 있다면 댓글로 공유해주세요. 같은 상황을 겪은 분들끼리 실마리를 찾는 경우가 꽤 많거든요.
다음 글에서는 FI 영역에서 가장 영향이 큰 Universal Journal 전환과 SI Item을 연결해서 설명드리겠습니다. 구체적으로 ACDOCA 구조 변경이 Z 리포트와 인터페이스에 어떤 영향을 주는지, Ledger 설계와 어떻게 연결되는지 다룰 예정입니다.
앞으로 이 시리즈는 아래 흐름으로 이어집니다.
- 1편: SI-CHECK 구조와 Readiness Check 차이 (현재 글)
- 2편: FI 주요 Simplification Item 분석 — Universal Journal, New G/L, FI-AA 중심
- 3편: TRM / Cash Management 영향 분석 — One Exposure, BCM, IHC
- 4편: 실제 Conversion 프로젝트 체크리스트
참고 출처
- SAP Note 2185390 — Simplification Item Check 관련 대표 Note
- SAP Help Portal: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE — Simplification Item Catalog 및 System Conversion 가이드
- SAP Readiness Check 공식 가이드: SAP Support Portal → SAP Readiness Check for SAP S/4HANA