Agentic Order-to-Cash: Mondelez가 새 클라우드 ERP 위에 에이전트를 얹어 주문부터 수금까지 잇는다
Mondelez는 Accenture와 함께 연 수백만 건의 주문-수금(O2C) 흐름을 새 글로벌 클라우드 ERP와 프로세스 인텔리전스 계층 위의 에이전트로 다시 짭니다. 고객 서비스, 공급망, 재무를 한 흐름으로 묶는 것이 목표이며 정량 목표와 일정은 공개하지 않았습니다.
Mondelez는 ERP를 바꾸는 중에 그 위에 프로세스 인텔리전스 계층과 에이전트를 얹어 주문에서 수금까지 부서별로 끊겨 있던 흐름을 하나로 잇겠다고 발표했습니다. 따라 하려면 ERP 기록에서 O2C 이벤트 로그를 먼저 뽑고 돈이 새는 단계를 숫자로 찾은 뒤 그 단계부터 에이전트를 붙여야 합니다.
요약
Consumer Goods Technology(CGT)의 Liz Dominguez가 2026년 11월 6일 전한 소식입니다. 과자 회사 Mondelez International은 Accenture와 함께 Order-to-Cash(O2C, 주문을 받아 대금을 받기까지의 전 과정)를 바꾸는 작업에 들어갔습니다. 범위는 주문 접수부터 신용 확인(credit check), 이행(fulfillment), 청구(invoicing), 수금(collections)까지이고 고객 서비스, 공급망, 재무 세 기능에 걸쳐 있습니다. 거래량은 고객, 시장, 유통망을 합쳐 한 해 수백만 건입니다. 하루 전 나온 Accenture 보도자료는 이 작업을 Agentic AI(스스로 판단하고 작업을 이어 가는 AI 에이전트)로 세 기능을 잇는 일로 설명합니다.
에이전트는 두 층 위에서 움직입니다. 아래층은 Mondelez가 새로 깔고 있는 글로벌 클라우드 ERP입니다. 그 위에 process intelligence layer(업무가 실제로 어떻게 흘러가는지 데이터로 보여 주는 층)가 놓입니다. 회사가 밝힌 기대 효과는 빠른 수금과 운전자본 개선, 고객 대응 팀의 빠른 문제 해결, 재무 팀의 실적 가시성, 리더의 빠른 결정입니다. 최고정보디지털책임자(CIDO) Filippo Catalano는 O2C를 “customer demand becomes revenue”라고 표현하며 매출이 생기는 지점으로 봤습니다. 성공은 결과로 재겠다고 했지만 절감액, 비율, 일정 같은 정량 목표는 발표하지 않았습니다. 아래에서 네 가지 작동 원리와 앞서 공개된 두 사례를 함께 보고 실제로 돌릴 때 필요한 기술·현업 디테일을 붙입니다.
핵심 메커니즘
End-to-End O2C: 세 기능에 흩어진 주문-수금을 한 흐름으로 본다
O2C는 주문 한 건이 돈이 되기까지 거치는 단계 전체입니다. 보통은 고객 서비스가 주문을 받으면 재무가 신용을 확인하고 공급망이 물건을 보낸 뒤 다시 재무가 청구하고 수금합니다. 각 기능이 자기 단계만 보면 단계 사이에서 기다리는 시간과 재입력이 생기고 앞 단계의 실수는 뒤 단계에서야 드러납니다. Mondelez는 이 단계들을 한 흐름으로 묶고 기능 사이의 연결을 에이전트에게 맡기겠다고 했습니다. 단계마다 담당이 다르고 넘기는 지점이 많은 곳에서 효과가 큽니다. 거래가 적고 한 부서가 끝까지 처리하는 업무라면 이 구조는 과합니다. 가상 예시로, 주문 단계에서 신용 한도가 모자란 고객이 걸리면 청구 단계까지 가서 막히기 전에 여신 담당자에게 바로 알리고 출하 일정을 함께 조정하는 식입니다.
Global Cloud ERP: 에이전트가 읽고 쓸 공통 기록을 먼저 깐다
기사는 새 글로벌 클라우드 ERP를 이 작업의 디지털 기반이라고 부릅니다. 이번 기사는 ERP 제품을 밝히지 않았지만 CGT는 2024년 7월 Mondelez가 12억 달러를 들여 ERP와 공급망을 바꾸는 다년 프로그램을 시작했다고 보도했습니다. 당시 보도에 따르면 SAP와 Accenture가 구축을 돕고 18개월 준비 뒤 지역 하나씩 SAP 모듈 단위로 단계 도입해 2028년 말 마치는 계획이었습니다. 에이전트가 신용 확인부터 수금까지 오가려면 주문, 출하, 청구, 입금이 같은 기준의 기록으로 남아 있어야 합니다. ERP가 지역마다 다르면 같은 고객의 미수금도 지역마다 다른 코드로 쌓여 에이전트가 판단할 근거가 흩어집니다. 실제로 돌린다면 ERP 전환이 끝난 지역부터 에이전트를 붙이는 편이 자연스럽습니다.
Process Intelligence Layer: ERP 기록으로 업무 흐름을 재현하고 새는 곳을 찾는다
Process intelligence는 ERP에 남은 이벤트 기록(주문 생성, 출하, 청구서 발행, 입금 같은 시각과 상태)을 이어 붙여 업무가 실제로 어떻게 흘렀는지 다시 그리는 기술입니다. 프로세스 마이닝이 그 출발점입니다. 이번 기사와 Accenture 보도자료는 이 계층의 제품을 밝히지 않았습니다. 다만 Mondelez는 2026년 7월 Celonis를 전략 파트너로 골랐고 Celonis 보도자료는 Source-to-Pay, O2C, Hire-to-Retire를 들여다보며 ERP 전환이 측정 가능한 가치를 내게 하는 데 쓴다고 밝혔습니다. Celonis는 Context Model(프로세스 데이터와 업무 지식을 묶어 AI가 읽을 수 있게 만든 회사 운영의 digital twin)을 바탕으로 둡니다. 이 층이 있으면 에이전트를 어디에 둘지 감으로 고르지 않고 지연과 누수가 큰 단계부터 고를 수 있습니다.
Agent Monitoring: 에이전트가 낸 결과의 하류 영향과 비용을 함께 잰다
이번 발표는 개별 에이전트가 무엇을 하는지 밝히지 않았습니다. 앞선 Celonis 보도자료가 에이전트 운영 계획을 세 가지로 적었습니다. 먼저 ROI가 큰 사용처를 고릅니다. 에이전트가 한 조치가 다른 시스템에 어떤 영향을 주는지 지켜보며 설정을 다듬습니다. 같은 일을 사람이 할 때와 에이전트가 할 때의 운영비(Total Cost of Service)도 비교합니다. O2C는 앞 단계의 조치가 뒤 단계 결과를 바꾸는 흐름이라 이 감시가 특히 필요합니다. 가상 예시로, 수금 에이전트가 독촉을 앞당기면 회수 기간은 줄지만 고객 문의가 늘어 고객 서비스 부담이 커질 수 있습니다. 두 숫자를 함께 봐야 에이전트 범위를 넓힐지 판단할 수 있습니다.
통념과 다른 주장
흔히 이렇게 봅니다ERP 전환이 끝나고 시스템이 안정된 뒤에야 AI를 붙일 수 있다.
저자는 이렇게 봅니다Mondelez는 ERP를 바꾸는 도중에 프로세스 인텔리전스로 흐름을 보고 새 ERP 위에 에이전트를 바로 얹습니다. ERP 전환 자체를 가치로 재는 일로 다룹니다.
근거2028년 말 완료 목표인 ERP 전환이 진행되는 2026년에 Celonis 선정(7월)과 O2C 에이전트 작업(11월)이 함께 발표됐습니다. Celonis 보도자료에서 Mondelez CIDO 조직 책임자 Rossana Rizzotto는 ERP 현대화를 가치 중심 전환으로 자리 잡게 하는 데 Celonis를 쓴다고 밝혔습니다.
저자가 든 사례
Mondelez × Accenture O2C 전환: 연 수백만 건 거래를 한 흐름으로
- 상황: 고객, 시장, 유통망에 걸친 연 수백만 건의 O2C 거래가 고객 서비스, 공급망, 재무로 나뉘어 처리됩니다.
- 한 일: Accenture와 함께 새 글로벌 클라우드 ERP와 프로세스 인텔리전스 계층 위에 Agentic AI를 얹어 신용 확인, 이행, 청구, 수금을 잇기로 했습니다.
- 결과: 빠른 수금, 운전자본 개선, 정확도 향상, 비용 절감을 기대 효과로 밝혔습니다. 정량 목표, 일정, 에이전트별 역할은 원문에서 밝히지 않았습니다.
- 연결: End-to-End O2C, Global Cloud ERP.
Celonis 도입: credit memo 누수를 막아 90일에 600만 달러 이상
- 상황: Mondelez는 진행 중인 ERP 전환이 측정 가능한 가치를 내도록 업무 흐름을 들여다볼 수단을 찾았습니다.
- 한 일: Celonis를 전 세계 사업장에 배치해 운영 digital twin을 만들고 Source-to-Pay, O2C, Hire-to-Retire를 들여다봤습니다.
- 결과: 18개월 동안 손익에 직접 잡힌 가치 1,000만 달러를 회수했다고 합니다. credit memo(고객에게 대금을 깎아 주는 대변 메모) 누수를 막아서는 90일 만에 600만 달러 이상을 되찾았다고 합니다(벤더 설명). 누수의 원인과 산정 방식은 원문에서 밝히지 않았습니다.
- 연결: Process Intelligence Layer, Agent Monitoring.
12억 달러 ERP·공급망 전환: 지역과 모듈 단위로 나눠 바꾼다
- 상황: Mondelez는 ERP와 공급망 운영의 효율을 높이려 했고 한 번에 전부 바꾸는 방식은 피했습니다.
- 한 일: 12억 달러 규모의 다년 프로그램으로 18개월 준비 뒤 지역 하나씩 SAP 모듈을 도입하고 수요·공급 계획에는 o9을 붙였습니다. 구축은 SAP와 Accenture가 돕습니다.
- 결과: 2028년 말 완료가 목표입니다(2024년 발표 기준). 지역별 진행 상황은 이번 기사에서 밝히지 않았습니다.
- 연결: Global Cloud ERP.
기술 디테일: O2C 에이전트를 직접 붙인다면
아래 필드명, 설정값, 구성은 실행 제안이자 가상 예시입니다. 발표에 없는 내용입니다.
O2C 이벤트 로그를 먼저 만듭니다(Process Intelligence Layer). 주문 라인 하나를 case로 두고 단계가 바뀔 때마다 이벤트 한 줄을 남깁니다. SAP라면 판매 오더, 출하, 청구 문서, 고객 미결 항목 테이블에서 시각과 상태를 뽑아 이을 수 있습니다. 처음 3주 동안은 이 로그 하나가 산출물의 전부여도 됩니다.
{
"case_id": "SO-4500123-10",
"activity": "invoice_posted",
"timestamp": "2026-11-03T09:14:00Z",
"region": "EU-West",
"customer_id": "C-20981",
"amount": 18420.00,
"currency": "EUR",
"credit_block": false,
"dispute_flag": false,
"source_system": "cloud_erp"
}
로그가 생기면 단계 사이 대기 시간, 신용 보류 건수, 청구 후 분쟁 비율, 매출채권 회수 기간(DSO)을 단계별로 계산합니다. 에이전트를 붙일 첫 단계는 이 숫자 가운데 금액이 가장 크게 묶이는 곳으로 고릅니다. Mondelez 사례의 credit memo처럼 대금 차감이 반복되는 지점이 흔한 후보입니다.
에이전트는 단계별로 좁게 나눕니다(End-to-End O2C). 신용 확인 에이전트, 청구 불일치 에이전트, 수금 우선순위 에이전트처럼 단계 하나에 하나씩 두고 단계 사이의 넘김은 이벤트로 처리합니다. 에이전트의 출력은 자유 문장이 아니라 구조화된 조치 초안으로 받습니다.
{
"agent": "credit_check",
"case_id": "SO-4500123-10",
"proposed_action": "release_with_partial_shipment",
"evidence": ["open_ar=42000", "credit_limit=50000", "order_value=18420"],
"confidence": 0.82,
"needs_approval": true,
"approval_rule": "amount > 10000 OR limit_overrun",
"explanation": "한도 내 잔여 8,000으로 부분 출하 후 잔량 보류 제안"
}
계산(한도 잔여, 연체 일수, 금액)은 ERP 값을 그대로 쓰는 규칙 코드가 맡고 LLM은 근거 조회 요약, 분쟁 메일 분류, 설명 문장 작성에 씁니다. 같은 입력에 같은 판단이 나와야 하므로 temperature는 0으로 두고 같은 건을 3회 돌려 proposed_action이 갈리면 사람에게 넘깁니다. 설명 문장의 숫자가 evidence 값과 다르면 문장을 버리고 템플릿 문장을 씁니다. 분쟁 메일 분류처럼 건수가 많은 일은 작은 모델로 돌리고 월 1회 200건 표본을 담당자가 채점해 정확도가 90% 아래로 내려가면 큰 모델로 바꿉니다. 이벤트 로그는 하루 한 번이 아니라 15분 간격으로 증분 적재해야 신용 보류 같은 당일 판단에 쓸 수 있습니다.
쓰기 권한은 단계적으로 엽니다(Global Cloud ERP). 처음에는 조회와 초안만 허용하고 ERP 반영은 사람이 누릅니다. 병행 운영에서 사람이 초안을 그대로 승인한 비율이 충분히 높아진 조치 유형만 자동 반영으로 옮깁니다. 금액 상한, 고객 등급, 지역별 규정을 approval_rule에 명시하고 ERP 전환이 끝나지 않은 지역은 읽기 전용으로 둡니다.
하류 영향과 비용을 함께 기록합니다(Agent Monitoring). 조치 한 건마다 downstream 필드에 다음 단계에서 생긴 일(분쟁 발생, 고객 문의, 재청구)을 7일·30일 시점에 붙입니다. 같은 기간 사람 처리 건의 처리 시간과 인건비를 함께 남겨 건당 처리 비용을 비교합니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 지역마다 ERP가 다름 | 같은 고객이 두 개의 ID로 잡혀 미수금이 갈림 | 고객 마스터 매핑 테이블을 먼저 만들고 전환 끝난 지역만 대상 |
| 이벤트 시각 누락 | 단계 사이 대기 시간이 0이나 음수로 계산됨 | 상태 변경 이력 테이블에서 시각 보강, 보강 못 한 건은 분석 제외 |
| 에이전트가 앞 단계 문제를 뒤로 미룸 | 신용 보류는 줄었는데 연체가 늘어남 | 30일 하류 지표를 판정에 포함, 연체 증가 시 자동 반영 중지 |
| 설명 문장이 숫자를 틀림 | 승인자가 설명과 화면 값이 다르다고 반려 | evidence 대조 검사, 불일치 시 템플릿 문장 |
| 승인 대기열이 쌓임 | 사람 승인이 병목이 되어 처리 시간이 늘어남 | 금액 기준을 조정하고 저위험 조치 유형부터 자동 반영 |
현업 실행 디테일: 누가, 언제, 무엇을
기사는 고객 서비스, 공급망, 재무가 이 흐름에 함께 걸려 있다고 전합니다. 아래 역할, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| O2C 프로세스 오너(재무 임원) | 시범 범위와 목표 지표 확정, 진행 판정, 부서 간 조정 |
| 프로세스 분석가 1~2명 | 이벤트 로그 추출, 단계별 지연·누수 진단, 병행 운영 측정 |
| 여신·수금 담당자 3~5명 | 판단 규칙 정리, 에이전트 초안 검토와 반려 사유 기록 |
| 고객 서비스 리더 | 고객 문의·분쟁 유형 제공, 에이전트 조치가 고객에게 주는 영향 확인 |
| ERP·IT 담당 | 데이터 연결, 쓰기 권한과 승인 규칙 설계, 로그 보관 |
준비물. 시범 지역의 최근 6개월 주문, 출하, 청구, 입금 기록, 신용 한도 변경 이력, 분쟁·credit memo 발행 내역과 사유 코드, 고객 마스터, 여신·수금 담당자가 쓰는 스프레드시트와 메일 템플릿이 필요합니다. 담당자 머릿속에 있는 규칙(예: “대형 유통사는 월말 독촉 금지”)을 꺼내는 일이 가장 오래 걸리므로 첫 주에 인터뷰로 시작합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~3주 | 시범 지역 1곳 선정, 이벤트 로그 추출, 담당자 인터뷰 | O2C 이벤트 로그, 단계별 기준선(DSO, 신용 보류 건수, 분쟁률) |
| 4~6주 | 누수 진단, 에이전트 대상 단계 1~2개 선정, 승인 규칙 설계 | 누수 금액 순위표, 에이전트 조치 정의서 |
| 7~11주 | 병행 운영(사람 처리와 에이전트 초안 비교) | 초안 그대로 승인 비율, 처리 시간, 하류 지표 |
| 12주 | 판정 회의, 확대 단계·지역 결정 | 진행·보완·중단 결정서 |
현장에 물을 것.
- 주문 한 건이 수금까지 가는 동안 가장 오래 멈춰 있는 단계는 어디이고 왜 멈추나요?
- 신용 보류를 풀 때 실제로 보는 숫자는 무엇이고 어느 화면에서 보나요?
- credit memo나 대금 차감은 어떤 사유로 가장 많이 나가고 누가 승인하나요?
- 수금 독촉 순서를 정할 때 금액 말고 무엇을 고려하나요?
- 에이전트 초안을 반려한다면 그 이유를 어디에 남기고 누가 보나요?
진행 판정 기준(예시). 병행 운영에서 에이전트 초안을 그대로 승인한 비율이 80% 이상이고 대상 단계의 처리 시간이 기준선보다 30% 이상 줄며 30일 하류 지표(분쟁률, 연체 금액)가 기준선보다 나빠지지 않으면 다음 단계와 다음 지역으로 넓힙니다. 승인 비율이 60% 아래면 규칙과 근거 데이터를 고쳐 4주 더 봅니다. 처리 시간은 줄었는데 하류 지표가 나빠지면 자동 반영을 멈추고 대상 단계를 다시 고릅니다.
AX 적용 제언. ERP 전환을 진행 중인 회사라면 이 순서를 그대로 쓸 수 있습니다. 전환이 끝난 지역의 O2C 이벤트 로그를 먼저 뽑아 돈이 묶이는 단계를 숫자로 찾고 그 단계 하나에 에이전트를 붙여 병행 운영으로 효과를 잰 뒤 다음 단계로 넓힙니다. 첫 대상은 credit memo, 신용 보류, 청구 분쟁처럼 금액이 바로 보이는 단계가 좋습니다. 스폰서는 CFO가 맡아야 고객 서비스와 공급망이 같은 지표를 받아들입니다. ERP 전환 예산을 심사할 때도 이 로그로 단계별 효과를 재면 전환 비용을 가치로 설명하기 쉬워집니다. 같은 구조는 Source-to-Pay(구매-지급)에도 옮길 수 있습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | Consumer Goods Technology, 2026.11.6, Liz Dominguez |
| 1차 발표 | Accenture 보도자료, 2026.11.5(뉴욕·시카고) |
| 대상 | Mondelez International의 Order-to-Cash, 고객 서비스·공급망·재무 |
| 범위 | 주문 접수부터 신용 확인, 이행, 청구, 수금까지. 연 수백만 건 거래 |
| 기반 | 새 글로벌 클라우드 ERP, 프로세스 인텔리전스 계층, 그 위의 Agentic AI |
| 파트너 | Accenture |
| 기대 효과 | 빠른 수금과 운전자본, 정확도·비용, 고객 대응 속도, 재무 가시성, 빠른 결정 |
| 발언 | Filippo Catalano(CIDO), Sanjay Gurbuxani(디지털 공급망 글로벌 VP), Marco Ziegler(Accenture) |
| 공개 안 된 것 | 정량 목표, 일정, 에이전트별 역할, 계층 제품명 |
| 배경 1 | Celonis 보도자료(2026.7.28): 18개월 1,000만 달러, credit memo 누수 차단 90일 600만 달러 이상 |
| 배경 2 | CGT(2024.7.31): 12억 달러 ERP·공급망 전환, SAP·Accenture, o9, 2028년 말 완료 목표 |
핵심 개념
- Order-to-Cash (O2C)
- 주문을 받아 출하하고 청구해 대금을 받기까지의 업무 전체입니다. 매출과 현금 흐름이 여기서 정해집니다.
- Credit memo
- 반품, 가격 조정, 프로모션 정산 등으로 고객에게 받을 금액을 줄여 주는 문서입니다. 근거 없이 나가면 그대로 손실이 됩니다.
- DSO
- Days Sales Outstanding. 매출이 현금으로 들어오기까지 평균 며칠 걸리는지 보여 주는 지표입니다.
- 프로세스 마이닝
- 시스템 이벤트 기록을 이어 업무가 실제로 흐른 경로와 지연을 찾아내는 분석입니다.
- Digital Twin of the Organization
- 회사 운영을 데이터로 재현한 모형입니다. 바꾸기 전에 영향을 재 볼 수 있습니다.
- Total Cost of Service
- 업무 한 건을 처리하는 데 드는 전체 운영비입니다. 여기서는 사람 처리와 에이전트 처리를 비교하는 기준으로 쓰입니다.
내 메모
TODO: 내 생각 추가
원문은 Consumer Goods Technology의 「Mondelez Connects Cloud ERP With AI Agents to Streamline Millions of Global Transactions」(Liz Dominguez, 2026.11.6)입니다. 같은 사건의 1차 자료인 Accenture 보도자료(2026.11.5)를 함께 읽었고 배경으로 Celonis 보도자료(2026.7.28)와 CGT의 2024년 7월 기사 「Mondelez Launching $1.2 Billion ERP and Supply Chain Transformation」를 참고했습니다. 이번 발표는 프로세스 인텔리전스 계층의 제품명을 밝히지 않았으며 Celonis 관련 내용은 별도 발표에서 온 것입니다. 1,000만 달러와 600만 달러 수치는 Celonis 측 설명입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 이 자료들을 AX Review가 다시 정리했습니다. JSON 예시, 에이전트 구성, 권한 설계, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.