BPC와 Group Reporting, 연결 엔진은 무엇이 다른가 ① 비교의 틀
연재: SAP BPC vs Group Reporting 연결 엔진 비교 (1/5) ① 비교의 틀 · ② 아키텍처 · ③ 데이터 모델 · ④ 프로세스 · ⑤ 시사점과 용어 대응표
연결결산 시스템을 다루는 컨설턴트는 대개 둘 중 하나의 엔진에 익숙합니다. 오랫동안 SAP BPC 프로젝트를 수행해 온 사람이 있고, S/4HANA 도입과 함께 Group Reporting(이하 GR)으로 연결을 시작한 사람이 있습니다.
문제는 한쪽 엔진에 익숙한 사람이 다른 엔진을 처음 볼 때 생깁니다. 용어가 비슷해 보여서 같은 것이라고 생각하고 설계했다가, 나중에 구조가 전혀 다르다는 사실을 발견하는 경우가 많습니다.
이 연재는 BPC 또는 GR 중 한쪽만 경험한 컨설턴트를 위해 썼습니다. 두 엔진 중 어느 쪽도 기준으로 삼지 않고, 연결회계 기능을 기준점으로 두 엔진을 나란히 놓고 비교합니다.
한 문장으로 요약하면
연재 전체의 결론부터 말씀드리겠습니다.
BPC는 유연성을 제공하는 대신 정합성 책임을 사용자·Excel·커스텀 로직에 두고, GR은 정합성을 시스템 구조로 강제하는 대신 유연성이 필요한 영역을 확장으로 분리한 엔진입니다.
이 차이는 어느 쪽이 더 낫다는 우열의 문제가 아닙니다. 연결 엔진을 어떻게 설계할 것인가에 대한 서로 다른 선택입니다. 그리고 이 선택은 아키텍처, 데이터 모델, 프로세스 전반에서 같은 모양으로 반복해서 나타납니다.
비교 축 | BPC: 유연성 (사용자 책임) | GR: 정합성 (시스템 강제) |
|---|---|---|
데이터 모델 | 사용자 정의 Dimension | 사전 정의 Master Data |
저장 방식 | YTD 독립 저장 | Periodic 연속 저장 |
확장 방식 | 플랫폼 내부에 Model·로직 추가 | Clean Core 밖에서 확장 후 API로 연동 |
보고 방식 | Excel 셀 단위 자유 레이아웃 | 계층구조·쿼리 기반 보고 |
세 가지 관점
이 연재는 두 엔진을 세 가지 관점에서 비교합니다. 세 관점은 원인에서 결과로 이어지는 순서로 배치했습니다.
아키텍처: 어디서, 무엇으로 실행되는가 BPC는 ERP 외부의 BW 위에서 동작하는 EPM 애플리케이션입니다. GR은 S/4HANA 안에 내장되어 Universal Journal 위에서 동작합니다. 연결 엔진이 회계 원장과 같은 시스템에 있는지 여부가 이후 모든 차이의 출발점이 됩니다.
데이터 모델: 무엇을 어떻게 표현하는가 BPC는 컨설턴트가 Dimension을 조합해 모델을 직접 설계합니다. GR은 SAP가 정의한 데이터 모델에 값을 설정합니다. 이 차이는 저장 방식, 감사 추적, 지분 관리, 확장성에까지 이어집니다.
프로세스: 언제, 어떤 순서로 처리하는가 연결결산의 단계 자체는 두 엔진이 같습니다. 데이터 수집, 환산, 내부거래 대사·제거, 투자자본 상계, 마감 통제, 보고 순서입니다. 다만 BPC는 실행 순서와 통제를 사용자의 설계와 운영 절차가 맡고, GR은 Task 순서와 상태로 시스템이 맡습니다.
비교 기준
비교 범위를 명확히 하기 위해 다음 전제를 두었습니다.
항목 | 기준 |
|---|---|
비교 대상 | BPC Standard(Classic) 모델과 GR Public Cloud |
비교 기준점 | 연결회계 기능 (어느 엔진도 기준으로 삼지 않음) |
GR 확장 경로 | on-stack RAP (S/4HANA Public 테넌트 안의 Developer Extensibility) |
BPC Embedded 모델과 GR Private Edition 및 On-Premise는 기능과 확장 방식에 차이가 있어 이번 비교에서는 제외했습니다.
두 엔진의 구성요소 한눈에 보기
상대 엔진의 용어를 모르면 비교를 시작할 수 없습니다. 그래서 본격적인 비교에 앞서 두 엔진의 구성요소를 같은 네 개의 층위에 놓아 보았습니다.
층위 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
데이터 구조 | Environment, Model, Dimension(Account, Entity, Flow, IntCo, AuditTrail 등), Property | Consolidation Unit·Group, FS Item, Subitem, Version, Document Type, Partner Unit |
연결 로직 | Business Rule(환산, IC Booking, US Elim, 연결), Script Logic, BAdI | Method·Rule(환산, 제거, 재분류, 투자자본 상계)을 구성해 Task에 할당 |
실행·통제 | Data Manager Package, BPF, Work Status, Consolidation Monitor | Data Monitor, Consolidation Monitor, ICMR, Validation |
사용자 접점 | EPM Add-in (Excel) | Fiori 앱, CDS 기반 분석 쿼리, SAC 등 표현 도구 |
이 표를 읽을 때 기억해 두면 좋은 포인트가 네 가지 있습니다.
데이터 구조: BPC는 Dimension을 조합해 모델을 '설계'하고, GR은 사전 정의된 객체에 값을 '설정'합니다.
연결 로직: BPC는 규칙 테이블과 스크립트를 '작성'하고, GR은 Method와 Rule을 '구성'합니다.
실행·통제: 두 엔진 모두 Consolidation Monitor라는 이름의 화면을 갖고 있습니다. 이름은 같아도 GR에서는 Task의 순서와 상태가 실행 통제의 중심이라는 점이 다릅니다.
사용자 접점: BPC는 Excel이 데이터 조회와 레이아웃을 함께 담당하고, GR은 데이터 계층과 표현 계층이 분리되어 있습니다.
연재 순서
회차 | 주제 | 다루는 내용 |
|---|---|---|
① | 비교의 틀 | 연재 전체의 결론과 비교 기준, 구성요소 개요 |
② | 아키텍처 | 플랫폼 위치, 데이터 흐름, 로직 실행 엔진, UI·리포팅 계층, 확장 구조 |
③ | 데이터 모델 | 모델링 철학, Dimension과 Master Data 매핑, 저장 방식, 감사 추적, 지분, 환산, 확장성 |
④ | 프로세스 | 결산 전체 흐름, 수집·검증, 내부거래, 투자자본 상계, 기초 잔액, 마감 통제, 보고 |
⑤ | 시사점 | 양방향 오해 영역, 핵심 정리, 용어 대응표, 참고 자료 |
각 회차에서는 같은 기능을 BPC와 GR이 어떻게 처리하는지 나란히 설명합니다. 그리고 마지막에 "BPC 경험자가 GR을 볼 때"와 "GR 경험자가 BPC를 볼 때" 주의할 점을 양방향으로 정리합니다. 어느 쪽 경험자든 자신에게 해당하는 부분을 바로 찾아 읽을 수 있도록 하기 위해서입니다.
다음 회차에서는 모든 차이의 출발점인 아키텍처를 살펴보겠습니다.