ERP 시스템은 대부분 안정화되어 있다.
재무 프로세스는 자동화되고 물류는 체계화되며 기업의 핵심 트랜잭션은 ERP를 중심으로 운영된다.
하지만 실제 현장에서는 여전히 이런 일이 발생한다.
구매 요청은 이메일이나 메신저로 들어오고
견적서는 PDF로 전달되며
담당자는 엑셀로 다시 정리한다.
ERP가 있는데도 현업은 다시 엑셀로 돌아간다.
왜 이런 일이 반복될까?
ERP는 기록과 통제의 시스템이기 때문이다.
하지만 구매 업무의 본질은 판단과 의사결정이다.
이 지점에서 SAP BTP 기반 확장 아키텍처가 필요해진다.
ERP와 BTP는 어떻게 연결되어야 하는가
ERP는 안정성을 중심으로 설계된다.
반면 BTP는 확장성과 연결성을 중심으로 설계된다.
따라서 두 시스템의 역할은 명확히 나뉜다.
ERP는
- 트랜잭션 처리
- 재무 기록
- 자재 및 공급망 관리
- 권한 및 통제
를 담당한다.
BTP는
- 시스템 통합
- 데이터 분석
- 프로세스 자동화
- AI 기반 의사결정
을 담당한다.
즉,
ERP = Core System
BTP = Extension Platform
이다.
왜 구매 프로세스는 다시 엑셀로 돌아갈까
기업의 구매 프로세스를 실제로 보면 다음과 같은 흐름이 반복된다.
예를 들어 한 부서에서 요청한다.
“모니터 10대가 필요합니다.”
그 다음 단계는 보통 다음과 같다.
- 요청이 이메일이나 메신저로 전달된다
- 구매팀이 공급업체에 견적을 요청한다
- 업체가 PDF 견적서를 보낸다
- 구매 담당자가 내용을 확인한다
- 계정과 코스트센터를 경험으로 선택한다
- ERP에 데이터를 입력한다
- 엑셀로 별도 관리한다
ERP 시스템은 존재하지만 실제 판단은 전부 사람이 한다.
그래서 다음과 같은 문제가 발생한다.
- 동일 품목이 다른 품목군으로 등록
- 계약되지 않은 공급업체 발주
- 단가 상승 인지 실패
- 정책 위반 승인
- 승인 지연
구매 품질이 개선되지 않는 이유는 명확하다.
구매 업무는 입력이 아니라 판단이기 때문이다.
LLM 기반 구매 데이터 Life Cycle
AI 기반 구매 자동화는 단순히 LLM을 붙인다고 해결되지 않는다.
성공 여부는 데이터 흐름 설계에서 결정된다.
구조는 다음과 같이 구성된다.
데이터 수집
AI가 판단하려면 사람이 참고하던 자료를 모두 수집해야 한다.
예
- 과거 구매 이력
- PR / PO / 입고 / 송장 데이터
- 계약 단가
- 회사 구매 정책
- 공급업체 정보
- 견적서 PDF
즉 사람의 경험을 구성하던 모든 데이터를 수집한다.
데이터 분석
다음 단계는 사람의 경험을 규칙과 패턴으로 변환하는 것이다.
예
회사 규정
“300만원 이상 구매는 경쟁 견적 2건 필요”
AI 규칙
금액 ≥ 3,000,000원 → 경쟁 견적 필수
또 과거 데이터를 분석하면 이런 패턴이 발견된다.
- IT팀은 특정 공급업체를 선호한다
- 평균 단가는 일정 범위에 존재한다
- 특정 품목은 특정 계정으로 처리된다
이런 경험을 데이터 모델로 구조화한다.
데이터 생성
다음 단계에서는 두 가지 기준이 생성된다.
개인화 기준
- 특정 부서의 구매 패턴
- 담당자의 공급업체 선호
전사 기준
- 표준 품목
- 계정 매핑 규칙
- 금액 정책
즉 개인 경험과 기업 정책을 동시에 모델링한다.
AI 질의 및 추천
이제 사용자가 요청을 입력한다.
“모니터 10대 필요”
AI는 다음과 같은 과정을 수행한다.
- 요청 부서 분석
- 과거 구매 패턴 확인
- 평균 단가 비교
- 정책 검증
그리고 다음 정보를 자동 생성한다.
- 자재 코드
- 품목군
- 공급업체 추천
- 코스트센터
- 정책 위반 여부
이 단계가 추천 + 검증이다.
결과 데이터
구매 담당자의 역할도 바뀐다.
기존
입력 중심 업무
변경
검토 중심 업무
담당자는 AI 초안을 확인하고 승인하거나 수정한다.
이때부터 자동화의 체감이 발생한다.
Execution AI 구조
구매 자동화 시스템은 반드시 다음 세 가지 구조로 나뉘어야 한다.
Interpreter
요청을 해석한다.
예
- 자재 구매인지
- 서비스 구매인지
- IT 장비인지
Decision Engine
정책과 과거 데이터를 기반으로 판단한다.
예
- 공급업체 추천
- 단가 검증
- 정책 위반 여부
Executor
확정된 데이터를 ERP API로 전달한다.
여기서 중요한 원칙이 있다.
AI는 ERP를 직접 수정하지 않는다.
AI는 추천과 판단을 수행하고
최종 실행은 ERP API를 통해 수행된다.
이 구조가 바로 Clean Core 전략이다.
SAP BTP 기반 구매 프로세스 Pipeline
구매 자동화 구조는 단순해야 한다.
전체 흐름은 다음과 같다.
수집 → 추천 → 검토 → 실행
수집
- 포털 입력
- 이메일
- 견적서 PDF
- 협력사 문서
추천
- 자재 코드
- 공급업체 후보
- 코스트센터
- 납기 정보
검토
- 정책 위반 여부
- 단가 이상치
- 중복 구매 여부
실행
- PR 생성
- 승인 워크플로우
- PO 생성
- GR / IV 연동
SAP BTP의 역할
이 구조에서 SAP BTP는 오케스트레이션 계층이다.
대표 기능
- Integration Suite (시스템 연결)
- Process Automation (승인 흐름)
- Document Extraction (PDF 데이터 처리)
- RPA (보조 자동화)
반면 S/4HANA는 트랜잭션 처리 엔진이다.
정리하면 다음과 같다.
ERP = 기록과 실행
BTP = 판단과 연결
왜 S/4HANA와 BTP는 분리되어야 하는가
구매 자동화는 자주 변화한다.
- 정책 변화
- 승인 기준 변경
- 입력 채널 증가
- AI 모델 업데이트
하지만 ERP 코어는 자주 변경되면 안 된다.
그래서 아키텍처는 다음 원칙을 따른다.
확장은 BTP에서
트랜잭션은 S/4HANA에서
즉
Clean Core Architecture
이다.
Clean Core 기반 Conversion 전략
ECC에서 S/4HANA로 전환할 때 가장 고민되는 부분은 커스터마이징이다.
특히 다음 영역은 코어에서 분리하는 것이 좋다.
- 다양한 입력 채널
- 정책 변화가 잦은 프로세스
- 비정형 문서 처리
- AI 적용 가능 영역
이러한 영역은 BTP로 이동하는 것이 장기적으로 유지보수에 유리하다.
SAP BTP 도입 실패 패턴
많은 프로젝트에서 다음과 같은 문제가 발생한다.
- AI와 Rule 기반 로직을 구분하지 않는다
- 추천 시스템만 구축하고 실행 자동화를 하지 않는다
- Integration 거버넌스가 없다
- 플랫폼 전략 없이 PoC만 반복한다
- 로그와 피드백 구조가 없다
SAP BTP는 단순 기능이 아니라 아키텍처 전략이다.
ERP는 이미 안정화된 시스템이다.
하지만 디지털 전환이 체감되려면 다음 단계가 필요하다.
- 판단을 데이터로 구조화하고
- 추천을 자동 생성하고
- 정책 검증을 자동화하고
- 실행을 API로 연결하는 것
이 구조가 만들어질 때 현업은 엑셀을 내려놓는다.
정리하면 다음과 같다.
ERP = Core
BTP = Extension + Integration + Data + AI
이제 질문은 하나다.
당신의 ERP는 안정화되었는가?
그렇다면 판단은 어디에서 설계할 것인가?
여기서부터가 진짜 기업 IT 아키텍처 전략이다.
'IT 인사이트' 카테고리의 다른 글
| 신제품 일정이 계속 밀리는 이유: NPD 포트폴리오 관리가 필요한 진짜 원인 (0) | 2026.03.04 |
|---|---|
| ChatGPT Enterprise 운영 가이드: 개인폰 허용 환경에서 보안 아키텍처 설계하기 (0) | 2026.03.04 |
| SAP BTP란 무엇인가: ERP 이후 기업 아키텍처를 바꾸는 확장 플랫폼 (0) | 2026.03.04 |
| ERP PI 컨설팅은 왜 먼저 할까? ERP를 ‘다시 설계’하는 진짜 이유 (0) | 2026.02.27 |
| 정비 AI는 챗봇이 아니다: RAG + Workflow로 ‘정비 프로세스’를 자동화하는 설계 (0) | 2026.02.26 |