SAP Cloud ERP
표준을 기준선으로 두고, 확장은 코어 밖에서 해결합니다.
SAP Cloud ERP는 SAP이 사전 구성한 프로세스와 연 2회 주요 업그레이드를 전제로 운영되는 SaaS ERP입니다. 도입 판단의 핵심은 기능이 충분한가가 아니라, 조직이 표준을 기준선으로 받아들일 준비가 되어 있는가입니다.
표준을 받아들이면 업그레이드 부담과 운영 비용이 구조적으로 줄어듭니다. 대신 지금까지 시스템이 흡수해 온 예외 처리를 업무 규칙 차원에서 정리해야 합니다. 아래는 그 판단에 필요한 기준과 실제 적용 방식입니다.
SAP Cloud ERP 도입 적합성을 가르는 세 가지 조건
조건 1. 표준 수용
프로세스를 표준에 맞출 결정 권한현업 예외를 정리하고 표준 프로세스를 채택할 권한이 프로젝트 조직에 부여되어 있는가.
- 예외 처리 목록
- 승인 권한
- 변화관리 계획
조건 2. 업데이트 수용
반기 릴리즈를 상시 운영으로연 2회 제공되는 업데이트를 정기 운영 업무로 편성하고 회귀 테스트를 감당할 수 있는가.
- 릴리즈 캘린더
- 테스트 자동화 수준
- 운영 인력
조건 3. 확장 전략
고유 요건을 코어 밖에서반드시 필요한 고유 기능을 BTP 기반 확장으로 구현할 설계·개발 역량이 확보되어 있는가.
- 확장 요건 분류
- Public API 존재 여부
- 개발 체계
SAP 표준 코어와 한국 업무의 연결 구조
모듈은 업무 영역을 뜻합니다. 한국 대응 항목은 검토 대상이며 에코아이티 보유·수행 범위는 [확인 필요]입니다.
사전 구성된 프로세스가 설계의 출발점입니다
SAP Cloud ERP에는 산업과 업무 영역별로 검증된 프로세스가 이미 구성되어 있습니다. 프로젝트는 백지에서 설계를 시작하는 대신, 이 구성된 프로세스를 기준으로 현재 업무와의 차이를 확인하는 방식으로 진행됩니다. 설계 기간이 짧아지는 이유는 인력을 더 투입해서가 아니라 결정해야 할 항목의 수가 줄어들기 때문입니다.
Fit-to-Standard는 요구사항 수집이 아닙니다
일반적인 요구사항 정의는 현업이 원하는 기능을 모아 목록을 만드는 작업입니다. Fit-to-Standard는 반대 방향으로 진행됩니다. 표준 프로세스를 먼저 시연하고, 그 흐름으로 처리되지 않는 지점만 갭으로 기록합니다. 기록된 갭은 다시 세 가지로 분류합니다. 업무 규칙을 조정해 해소할 항목, 설정으로 해결할 항목, 확장 개발이 필요한 항목입니다.
에코아이티는 이 분류 결과를 갭 목록과 확장 요건서로 분리해 관리합니다. 두 문서를 분리하는 이유는, 갭의 상당수가 개발이 아니라 업무 합의로 종료되기 때문입니다. 이 구분을 하지 않으면 초기 갭 개수가 그대로 개발 물량으로 잘못 산정됩니다.
범위는 Scope Item 단위로 확정합니다
SAP Cloud ERP의 범위는 기능 목록이 아니라 SAP이 정의한 Scope Item 단위로 관리합니다. 어떤 Scope Item을 활성화할지, 각 항목이 어떤 조직 구조와 마스터 데이터를 전제로 하는지를 확인하면 구축 범위와 데이터 준비 범위가 동시에 확정됩니다. 범위 변경 요청도 같은 단위로 기록해 일정과 비용의 영향도를 즉시 확인할 수 있게 합니다.
Record-to-Report
Source-to-Pay
Order-to-Cash
Plan-to-Produce
범위 확정 조건 — 법인 · 회계기준 · 현지화 확인
적용 가능 범위와 Scope Item ID는 선택한 릴리즈·국가·계약 범위에서 확인합니다.
표준으로 시작하고, 업데이트에도 Clean Core를 유지합니다
SAP Cloud ERP(Public)는 신규 구축을 통해 SAP 표준 프로세스를 채택하고, 운영 중에도 그 구조를 유지하는 데 초점을 둡니다. ERP 코어를 직접 수정하지 않고 지원되는 확장 방식과 공개 API를 활용하므로, SAP의 정기 업데이트에 맞춰 업무와 확장을 더 안정적으로 검증할 수 있습니다.
SAP Cloud ERP의 세 가지 확장 계층
첫째, Key User Extensibility는 화면 필드 추가, 사용자 정의 항목, 간단한 로직처럼 업무 담당자가 도구 안에서 처리할 수 있는 범위입니다. 둘째, Developer Extensibility는 ERP 내부에서 SAP이 공개한 오브젝트만 사용해 업그레이드에 안전한 ABAP 확장을 구현하며, 3-시스템 랜드스케이프를 쓰는 SAP Cloud ERP에서만 제공됩니다. SAP Cloud ERP Private은 코어를 직접 수정하는 기존(Legacy) 방식을 쓰게 되므로 SAP이 권장하지 않습니다. 셋째, Side-by-Side Extensibility는 SAP BTP에 별도 애플리케이션을 두고 공개 API로 ERP와 통신하는 방식으로, 복잡한 고유 업무에 적합합니다.
해결 순서는 Key User → Side-by-Side → Developer이며, 코어를 직접 고치는 기존 방식은 마지막까지 피합니다. 코어와의 접점은 공개 API로 유지해 업데이트 영향 범위를 줄입니다.
Key user extensibility
Developer extensibility · Public 전용
Side-by-side / SAP BTP
정기 업데이트에 맞춰 API와 확장을 함께 검증합니다
Public에서는 SAP가 관리하는 정기 업데이트에 맞춰 확장의 호환성을 확인해야 합니다. 에코아이티는 요건 접수 시 대상 API, 지원 범위, 호출 제약과 릴리스 영향을 먼저 확인하고 기록합니다. 필요한 API가 없다면 개발에 착수하기 전에 표준 기능, 프로세스 조정, SAP BTP 대안을 함께 검토합니다.
Public 적용 범위와 API는 선택한 릴리스·국가·Scope Item에서 확인합니다.
자주 묻는 질문
제품·도입·운영의 판단 기준을 먼저 확인하세요.
Fit-to-Standard에서 업무 변경, 표준 설정, 확장을 구분합니다. 핵심 업무의 갭이 크면 에디션 적합성부터 다시 검토합니다.
SAP 개요 보기표준 프로세스를 채택하는 신규 구축은 Public, 기존 ECC 자산과 업무 연속성이 중요한 경우에는 Private를 우선 검토합니다. 에디션 선택은 현재 시스템 진단과 조직의 표준 수용도에 따라 결정합니다.
SAP 개요 보기현재 시스템·업무 범위·목표 일정과 조직의 제약을 먼저 정리합니다. 검토 가이드의 준비 항목을 확인하고, 확정되지 않은 사항은 상담에서 함께 구체화할 수 있습니다.
SAP 개요 보기현재 시스템·업무 범위·목표 일정과 조직의 제약을 먼저 정리합니다. 검토 가이드의 준비 항목을 확인하고, 확정되지 않은 사항은 상담에서 함께 구체화할 수 있습니다.
SAP 개요 보기커스텀 코드의 실제 사용 이력과 영향도를 분석해 유지·대체·폐기로 구분합니다. 표준 코어를 보호하고 필요한 확장은 BTP 등 코어 외부의 확장 방식으로 검토합니다.
SAP 개요 보기지원 종료 시점은 현재 사용 중인 제품과 계약 조건을 함께 확인해야 합니다. 시스템 버전과 전환 제약을 정리한 뒤 SAP Cloud ERP Private 검토에서 전환 일정을 확인하세요.
SAP 개요 보기사용자 역할, 업무 범위, 인터페이스, 데이터 이관 범위와 운영 조건을 먼저 확인합니다. 라이선스뿐 아니라 구축·전환·운영 비용을 동일한 범위와 기간으로 비교해야 합니다.
SAP 개요 보기현재 시스템·업무 범위·목표 일정과 조직의 제약을 먼저 정리합니다. 검토 가이드의 준비 항목을 확인하고, 확정되지 않은 사항은 상담에서 함께 구체화할 수 있습니다.
SAP 개요 보기표준화 수용도를 기준으로 다음 검토를 이어가세요
SAP Cloud ERP 적합성을 진단하거나 기존 자산 중심의 SAP Cloud ERP Private을 비교합니다.