ERP는 업무 프로세스를 안정적으로 운영하는 기반 시스템이고, SAC는 그 위에 올라가는 전략적 의사결정 플랫폼입니다. SAC는 IT 개발이 아닌 비즈니스 중심의 빠르고 유연한 계획 수립을 가능하게 합니다. 따라서 개발 방식도 ERP와는 전혀 다르며, 고객의 참여와 협업이 핵심입니다.
🟦 ERP와 SAC의 본질적 차이
- ERP: 업무 프로세스를 실행하는 시스템
- SAC: 데이터를 기반으로 계획과 분석을 수행하는 플랫폼
- 핵심 차이: ERP는 “정해진 흐름”, SAC는 “설계 중심”
🟦 ERP의 표준 프로세스란?
- 산업별 Best Practice 기반
- SAP에서 사전 정의된 흐름 제공
- 예: 구매 요청 → 승인 → 발주 → 입고 → 회계 처리
- 사용자: 프로세스 실행자
🟦 SAC에는 왜 표준 프로세스가 없는가?
- SAC는 업무 실행이 아닌 계획 수립을 위한 도구
- 고객의 조직 구조, 계획 방식, KPI에 따라 모델을 직접 설계
- “빈 캔버스”를 제공하고, 고객이 그 위에 계획 시나리오를 구성
🌍 고객마다 계획 방식이 다르기 때문
- 제조, 유통, 서비스 등 산업별로 계획 수립 방식이 천차만별
- 같은 산업 내에서도 기업마다 조직 구조, KPI, 예산 방식, 승인 절차가 다름
- SAP는 “하나의 정형화된 프로세스”를 제공하기보다, 유연한 설계 도구(SAC)를 통해 고객이 직접 모델링하도록 유도
즉, SAP는 “정답을 주는” 대신 “도구를 주고 고객이 정답을 만들게” 합니다.
🧩 ERP와 SAC의 역할이 본질적으로 다름
시스템 | 역할 | 설계 철학 |
|---|---|---|
ERP (S/4HANA) | 업무 실행, 원가 계산, 트랜잭션 관리 | 안정성과 표준화 중심 |
SAC | 계획 수립, 분석, 시뮬레이션 | 유연성과 사용자 중심의 설계 |
- ERP는 “실행 중심”, SAC는 “계획 중심”
- ERP는 표준 프로세스를 내장하지만, SAC는 모델링 플랫폼이기 때문에 사전 정의된 흐름을 제공하지 않음
🛠 기술적 통합은 이미 가능하지만, 프로세스는 고객이 정의해야 함
- SAP는 ERP와 SAC 간의 데이터 통합 기능은 이미 제공 (예: Live Connection, Data Import, Data Action)
- 하지만 계획 흐름(예: 예산 수립 → 승인 → 확정)은 고객마다 다르므로, 프로세스 템플릿을 강제하지 않음
- 대신, Best Practice Reference Content를 통해 참고 모델은 제공
🧠 SAP의 전략: 고객 중심의 설계 유도
- SAP는 “모든 고객에게 맞는 하나의 계획 프로세스”는 존재하지 않는다는 철학을 가지고 있음
- SAC는 Low-code/No-code 방식으로 고객이 직접 설계할 수 있도록 설계됨
- 이는 고객의 자율성과 확장성을 극대화하기 위한 전략
✅ Best Practice Reference Content란?
- SAP에서 제공하는 산업별, 기능별 사전 구성된 계획 모델, 스토리, 데이터 액션, 시나리오 템플릿
- SAC 또는 Integrated Planning(SAP S/4HANA) 환경에서 활용 가능
- 예산, 수익성 분석, 인력 계획, 자본 지출 계획 등 다양한 영역 포함
⚙️ “Best Practice Reference Content”의 특징
항목 | 설명 |
|---|---|
기술적 완성도 | SAP에서 검증된 구성 요소로, 설치 후 바로 실행 가능 |
구성 요소 | Planning Model, Story, Data Action, Calendar, Version 등 포함 |
연동 가능성 | S/4HANA, BW/4HANA, DWC 등과 연계 가능 |
유지보수 | SAP에서 지속적으로 업데이트 및 개선 |
⚠️ 실무 적용 시의 한계와 고려사항
🧩 고객의 조직 구조와 맞지 않을 수 있음
- Reference Content는 범용적인 구조로 설계되어 있어, 실제 고객의 조직, 계정 체계, KPI와 다를 수 있음
- 예: 고객은 제품별 계획을 원하지만 템플릿은 부서별 중심일 수 있음
🛠 커스터마이징이 필수
- 실제 적용을 위해서는 모델 구조, 계정 매핑, 데이터 흐름 등을 고객 환경에 맞게 수정해야 함
- 특히 ERP와의 연동 시, 데이터 소스 구조와 계획 모델 간의 매핑 작업이 필요
📊 데이터 품질과 연결성 이슈
- Reference Content는 샘플 데이터 기반으로 구성되어 있어, 실제 데이터와 연결 시 오류 발생 가능
- 예: ERP에서 가져온 원가 데이터가 SAC 모델과 구조가 다를 경우, 계산 로직 수정 필요
🧠 사용자 교육이 필요
- 고객이 Reference Content를 그대로 사용할 경우, 이해 부족으로 오용될 수 있음
- 계획 흐름, 승인 절차, 시나리오 구성 등은 고객이 직접 정의해야 함
💡 어떻게 활용하면 좋은가?
- Reference Content는 출발점(Start Point)으로 활용
- 고객의 요구사항에 맞게 모델을 확장하거나 축소
- 프로젝트 초기 단계에서 워크샵을 통해 고객 요구사항과 Reference Content를 비교 분석
- SAP 또는 파트너사의 Best Practice 전문가의 지원을 받는 것이 효과적
✍️ 고려해야 할 시사점
“SAP의 Reference Content는 기술적으로 잘 작동하며, 빠른 시작을 위한 훌륭한 출발점입니다. 하지만 고객의 조직 구조와 계획 방식에 맞게 커스터마이징이 필수이며, 단순히 ‘적용’하는 것이 아니라 ‘설계 기반으로 활용’하는 것이 중요합니다.”
🟦 고객이 흔히 하는 오해
❌ “SAC에서 예산 수립 프로세스가 어떻게 되어 있나요?”
✅ “우리 회사의 예산 수립 방식에 맞춰 SAC에서 어떤 모델을 설계할 수 있나요?”
🟦 SAC의 구성 요소
- Planning Model: 계정, 버전, 시간, 조직 등 정의
- Story: 시각화 및 입력 화면 구성
- Data Action: 계산, 배분, 시나리오 전환
- 협업 기능: 댓글, 알림, 공유
🟦 고객의 역할 변화
구분 | ERP 프로젝트 | SAC 프로젝트 |
|---|---|---|
IT 역할 | 개발 및 유지보수 | 데이터 연결, 보안 설정 |
비즈니스 역할 | 요구사항 전달 | 모델 설계, 시나리오 작성 |
협업 방식 | 일방향 | 양방향 공동 설계 |
🟦 핵심 메시지
“SAC는 ERP처럼 정해진 프로세스를 따르는 시스템이 아닙니다. 고객의 비즈니스 목적과 조직 구조에 따라 계획 모델을 직접 설계해야 하며, 그 과정에서 고객의 참여가 필수적입니다.”