SAP와 ServiceNow로 하는 ERP 현대화

SAP와 ServiceNow로 하는 ERP 현대화란 각 플랫폼에 가장 잘하는 일을 맡기고 둘을 제대로 연결하는 것입니다. SAP S/4HANA는 정형 트랜잭션인 재무, 구매, 재고, 급여를 맡습니다. ServiceNow는 그 주변의 워크플로인 접수, 승인, 예외, 서비스 요청을 맡습니다. SAP Integration Suite와 ServiceNow IntegrationHub가 둘을 이어 줍니다. 이 가이드는 SAP ECC나 초기 S/4HANA 시스템에서 현대화를 계획하는 CIO, CFO, 엔터프라이즈 아키텍트를 위한 것입니다. 기능별로 어떤 일이 어디에 속하는지, AI가 들어갈 자리, 단계별 로드맵, 그리고 함정을 다룹니다. 기능별 표부터 보고 로드맵으로 넘어가십시오.

ERP 현대화는 제가 맡는 거의 모든 프로젝트에 등장합니다. 여러 해 전에 퇴역했어야 할 환경에서 여전히 SAP ECC로 재무나 운영을 관리하는 기업들과 일해 왔습니다. 한 물류 고객사는 사소한 프로세스 변경 하나를 승인받으려고 수작업 인수인계를 네 번 거쳐야 했습니다. 저희는 SAP를 ServiceNow와 연결했고, 처리 시간과 가시성의 차이는 즉각 나타났습니다.

제가 자주 보는 실수는 ERP 현대화가 최신 SAP 버전으로 업그레이드하는 것이라고 가정하는 것입니다. 시스템끼리 대화하지 못한다면, 문제를 더 새로운 화면으로 옮겨 놓은 것뿐입니다. 데이터는 사일로에 갇혀 있습니다. 팀은 도구를 믿지 않게 됩니다. 사람들은 문제를 해결하는 대신 쫓아다닙니다.

많은 팀이 현대화를 마쳤다고 믿습니다. 실제로는 업그레이드를 한 것입니다. 차이는 매일의 업무에서 드러납니다.

현대화란 시스템이 10년 전에 설계된 방식이 아니라 오늘의 비즈니스를 어떻게 뒷받침하는지 다시 생각하는 것입니다. 아키텍처, 프로세스, 데이터, 통합, 사용자 경험을 모두 건드립니다.

CIO들은 제게 자주 묻습니다. "그러니까 클라우드로 옮기라는 말입니까, 아니면 ERP를 교체하라는 말입니까?" 둘 다일 때도 있지만, 한꺼번에 하는 경우는 드뭅니다. 진짜 현대화는 대개 ERP가 비즈니스와 함께 확장되지 못하고 마찰이 눈에 보이기 시작할 때 시작됩니다.

중동의 한 소비재 고객사는 여전히 SAP ECC를 쓰고 있었습니다. 재무팀은 나쁜 데이터를 정리하느라 시간을 보냈고, 보고는 운영보다 뒤처져 있었습니다. 저희는 구현 자체를 다시 평가하는 것에서 시작했습니다. 기술만이 아니라 프로세스가 여전히 비즈니스가 일하는 방식에 맞는지를 봤습니다. 그다음이 마스터 데이터였습니다. 그다음이 자동화였습니다. SAP가 내부에서 처리할 수 있는 것과 ServiceNow가 빈틈을 메울 수 있는 곳, 특히 승인, 에스컬레이션, 프로세스 추적을 가렸습니다. 그 순서 덕분에 경영진은 따라갈 수 있는 계획, 일정, 성과를 얻었습니다.

현대화가 모든 것을 뜯어내는 것을 뜻하는 경우는 드뭅니다. 대개 기업은 이미 잘 돌아가는 것을 유지하고 그 주변을 현대화합니다. SAP와 ServiceNow가 나란히 잘 맞는 지점이 바로 여기입니다.

SAP S/4HANA는 통제와 일관성을 위해 만들어진 정형 코어, 즉 트랜잭션, 재무, 구매, 재고를 맡습니다. ServiceNow는 SAP가 직접 하도록 설계되지 않은 일, 즉 접수, 승인, 부서 간 워크플로, 예외 처리를 맡습니다. 클린 코어가 이 분담을 강화합니다. SAP 코어에 속하지 않는 워크플로 로직은 어딘가에 있어야 하며, 현실적인 자리는 SAP BTP의 사이드 바이 사이드 확장이나 ServiceNow입니다. 제 클린 코어 가이드에서 확장 옵션을 설명합니다.

연결은 SAP BTP의 SAP Integration Suite, ServiceNow IntegrationHub, 그리고 오픈 API를 통해 이뤄지므로, 흐름이 덧붙인 것이 아니라 원래부터 있던 것처럼 느껴집니다. 제가 아는 한 글로벌 기업은 구매에 SAP를, 구매 요청 관리에 ServiceNow를 써서 맞춤형 포털이 필요 없게 했고, 이후에는 같은 구조를 협력업체 온보딩에도 썼습니다. 아직 SAP Process Orchestration(PI/PO)을 운영 중이라면 이전을 계획하십시오. PI/PO가 구동되는 SAP NetWeaver 7.5는 2027년 말에 표준 유지보수가 끝나며, 선택적 연장 유지보수는 2030년까지입니다. 제 SAP Cloud Integration 가이드에서 이전 대상 플랫폼을 다룹니다.

1. 04ServiceNow팀 간 접수, 승인, 예외, 서비스 요청
2. 03통합BTP의 SAP Integration Suite와 ServiceNow IntegrationHub, 오픈 API 기반
3. 02확장코어에 속하지 않는 로직을 위한 SAP BTP의 사이드 바이 사이드
4. 01SAP S/4HANA 코어재무, 구매, 재고, 급여를 표준에 가깝게 유지

기능별 활용 사례

HR. SAP(또는 SuccessFactors)는 직원 마스터 데이터, 역할, 급여, 복리후생을 관리합니다. ServiceNow는 IT, HR, 재무, 보안 전반에 걸쳐 온보딩 업무, 접근 권한 부여, 승진 승인, 오프보딩을 조율합니다.

재무. SAP는 송장을 처리하고, 원장을 관리하고, 마감을 실행하고, 법정 보고서를 생산합니다. ServiceNow는 워크플로 계층을 운영합니다.

재무 프로세스	SAP의 역할	ServiceNow의 역할
매입채무	송장 처리, PO 매칭, 지급 관리	송장 접수, 예외 라우팅, SLA 추적
매출채권	고객 송장과 수금 추적	청구 분쟁과 여신 보류 요청 라우팅
재무 마감	기간 마감, 내부거래 제거, 보고	마감 체크리스트, 업무 배정, 미결 항목 알림
경비 관리	입력 수집, 정책 적용, 환급 실행	승인을 위한 보고서 라우팅, 예외 표시
구매에서 지급까지	구매 요청, PO, 입고, 공급업체 정산	접수 양식, 승인 라우팅, 예외 처리

구매. SAP는 공급업체 마스터 데이터, 구매 오더, 입고, 3-way 매칭을 관리합니다. ServiceNow는 접수, 공급업체 온보딩 점검, 입고 이슈, 구매 헬프데스크를 처리합니다.

시설 및 운영. SAP는 고정자산, 유지보수 비용, 공간을 추적합니다. ServiceNow는 업무 공간 요청, 유지보수 작업 지시, 기술자 배정, 출입 요청, 인시던트 라우팅을 처리합니다.

AI는 점점 더 많은 현대화 논의에 등장하고, 기대가 결과보다 앞서 달리는 경우도 있습니다. 실제로 AI는 예외 사례를 처리하고, 반복 업무를 자동화하고, 사람들이 놓치는 것을 드러냅니다. SAP 쪽에서는 SAP의 AI 어시스턴트인 Joule이 S/4HANA, SuccessFactors, Ariba, SAP Build 전반에서 동작합니다. ServiceNow 쪽에서는 Now Assist가 IT, HR, 고객 서비스 워크플로에 생성형 AI를 가져옵니다.

업무는 보통 이렇게 나뉩니다.

AI 활용 사례	SAP의 역할	ServiceNow의 역할
송장 매칭	PO, 입고, 송장을 매칭하고 이상 징후를 표시	예외를 라우팅하고 위험이 높은 불일치를 우선 처리
예지 정비	설비 데이터에서 사용 및 고장 패턴을 분석	정비 티켓을 발행하고 기술자 일정을 배정
현금 흐름 알림	이력을 기반으로 현금 포지션을 예측	유동성 임계값을 넘으면 알림과 워크플로를 실행
가상 에이전트	Joule이 SAP 애플리케이션 전반의 자연어 질문에 답변	가상 에이전트와 Now Assist가 요청을 처리하고 SAP 백엔드를 호출
이상 탐지	SAP BTP의 모델이나 내장 분석이 트랜잭션의 이상치를 표시	워크플로와 승인의 이상 징후를 감사 검토용으로 표시
요청 분류	구매 흐름에서 카테고리를 제안	Predictive Intelligence가 케이스를 분류하고 적합한 그룹으로 라우팅

저희가 함께 일한 한 IT 팀은 비밀번호 재설정과 SAP 데이터 조회를 할 수 있는 가상 에이전트를 도입한 뒤 한 분기 만에 저가치 지원 티켓이 30% 줄었습니다. SAP 쪽에서도 같은 패턴이 성립합니다. AI는 프로세스가 안정적이고, 이력이 깨끗하고, 문제가 초점이 분명할 때 가장 잘 작동합니다. 그럴 때도 AI는 팀을 대체하는 것이 아니라 지원합니다.

현대화는 첫걸음이 너무 크게 느껴져서 멈추는 경우가 많습니다. 시급하지 않아서가 아니라 "어디서 시작합니까?"라는 질문에 아무도 답하지 못해서 수년간 미룬 고객사들과 일해 보았습니다. 이 순서가 대체로 통합니다.

1. 평가와 합리화. 플랫폼을 옮기기 전에 기반부터 정리하십시오. SAP Readiness Check를 실행해 커스텀 코드와 호환성의 규모를 파악하십시오. 마스터 데이터는 마이그레이션 후가 아니라 전에 정리하십시오. 어떤 시스템, 리포트, 프로세스를 남길지 정하십시오. 배포 경로(RISE with SAP, GROW with SAP 또는 온프레미스)를 정하고, SAP Solution Manager가 2027년 말에 표준 유지보수에서 빠지므로 SAP Cloud ALM을 라이프사이클 도구로 계획하십시오. 무엇이 무엇과 연결되어 있는지 그려 보는 짧은 기술 탐색 스프린트가 대개 진짜 리스크가 숨은 곳을 보여 줍니다.
2. ServiceNow부터 시작합니다. 접수, 승인, 워크플로를 먼저 구축하십시오. 이것들은 ERP 주변에 있고 불만도 가장 많이 만들어 냅니다. 한 고객사는 S/4HANA 마이그레이션 6개월 전에 ServiceNow로 변경 통제를 관리하여 장애를 40% 줄였습니다. SAP 코어를 건드리기 전에 규율이 만들어집니다.
3. 클린 코어로 SAP 코어를 옮깁니다. 커스텀 코드를 최소화하며 트랜잭션을 S/4HANA로 옮기십시오. 표준에 가깝게 유지하면 업그레이드가 단순해지고 유지보수가 줄어듭니다. 커스텀 로직은 코어가 아니라 사이드 바이 사이드 확장이나 ServiceNow에 두십시오. 그리고 단순히 마이그레이션하는 데서 그치지 말고, 앞으로 5년간 ERP가 무엇을 가능하게 해야 하는지 물으십시오.
4. 최적화하고 확장합니다. SAP BTP에 분석과 확장을 추가하고, 맞는 곳에 Joule을 적용하고, ServiceNow 쪽에서는 Now Assist, 가상 에이전트, 로우코드 워크플로를 더하십시오.

단계는 겹칠 수 있습니다. SAP 준비 작업과 ServiceNow 안정화를 병행하면 무리하지 않고도 일정이 단축됩니다. S/4HANA 부분은 제 ECC to S/4HANA 마이그레이션 가이드가 경로와 일정을 다룹니다.

재무팀은 비용을 일찍 묻고, 결정은 IT에서 시작되더라도 대개 CFO에게서 확정됩니다.

직접 비용이 먼저 나옵니다. 인프라, 호스팅, 스토리지, 통합 도구입니다. 라이선스와 지원 비용은 누군가 합리화하지 않으면 그대로 유지되며, 많은 팀이 사용하지 않거나 중복된 라이선스를 찾아보지 않습니다. RISE with SAP에서는 Full User Equivalent(FUE) 과금 기준으로 전체 계약 기간에 걸친 사용자 증가를 모델링하십시오. 3년 차 구독료가 1년 차 견적과 같은 경우는 드뭅니다.

간접 비용은 보기 어렵습니다. 느린 승인, 놓친 SLA, IT에 대한 신뢰를 갉아먹는 통합 실패입니다. 한 예산 항목에 나타나지는 않지만 운영 성과에는 드러납니다.

투자 수익을 보여 주려면 무언가를 바꾸기 전에 측정하십시오. 송장 승인, 온보딩, 구매 요청의 사이클 타임, 오류율, 통합 지연 시간입니다. 불완전한 기준선이라도 수익을 이야기가 아니라 숫자로 바꿔 줍니다.

이 함정들은 두 플랫폼 모두에서 나타납니다.

함정	SAP의 실수	ServiceNow의 실수
프로세스 평가 건너뛰기	프로세스 갭을 검토하지 않고 레거시 문제를 그대로 마이그레이션	실제 병목을 이해하지 못한 채 요청 양식을 배포
도구를 만병통치약으로 여기기	아무도 재설계하지 않은 프로세스를 S/4HANA가 고쳐 줄 것이라고 가정	자동화가 비효율적인 요청 설계를 고쳐 줄 것이라고 가정
마스터 데이터 방치	중복되거나 일관되지 않은 데이터를 마이그레이션	신뢰할 수 없는 데이터에서 승인을 트리거
너무 일찍 과도하게 커스터마이징	코어 프로세스가 안정되기 전에 확장을 구축	사용자 행동을 이해하기 전에 복잡한 플로를 구축
거버넌스 부재	비즈니스 오너 없이 결정을 IT나 벤더에게 맡김	규칙과 SLA의 오너 없이 워크플로를 배포
변화관리 무시	새 SAP 프로세스에 대한 교육에 소홀	새 요청 유형을 언제 어떻게 써야 하는지 사용자에게 가르치지 않음

ERP가 문제라고 생각하던 제조업 고객사가 기억납니다. 진짜 걸림돌은 다섯 팀에 걸친 수작업 승인 경로였습니다. ServiceNow 계층을 도입하고 SAP에 다시 연결하자 병목이 사라졌습니다.

현대화를 한꺼번에 할 필요는 없습니다. 어떤 시스템은 남고, 어떤 시스템은 바뀝니다. 가치는 더 많은 부분이 연결되고 우회에 의존하는 부분이 줄어들수록 쌓입니다.

한꺼번에 모두 현대화해야 합니까?

아닙니다. 현대화는 단계적으로 할 때 가장 잘 됩니다. 많은 조직이 SAP 코어를 건드리기 전에 ServiceNow 워크플로로 운영을 안정시키는 것에서 시작하고, 나머지는 마찰이 큰 순서대로 풀어 갑니다.

한 고객사는 S/4HANA가 배포되기 전에 ServiceNow 접수 워크플로를 가동했습니다. 직원들이 점진적으로 적응하면서 채택률이 높아지고 저항이 줄었습니다.

S/4HANA 마이그레이션에서 레거시 커스터마이징은 어떻게 됩니까?

비즈니스 가치에 따라 다릅니다. SAP Readiness Check는 커스텀 코드의 규모와 호환성 문제를 초기에 보여 줍니다. 대부분의 시스템에는 아무도 모르는 커스텀 코드가 훨씬 많고, 그중 상당수는 더 이상 쓰이지 않습니다.

클린 코어는 시스템을 표준으로 유지하고, 확장은 SAP BTP에, 워크플로는 ServiceNow에 두는 쪽을 선호합니다. S/4HANA Cloud Public Edition에서는 코어를 전혀 수정할 수 없습니다. Private Edition과 온프레미스에서는 수정할 수 있지만, 수정 하나하나가 업그레이드 작업을 늘립니다. 실제 비즈니스 목적에 쓰이는 것은 유지하고 나머지는 폐기하십시오.

ERP 현대화에는 시간이 얼마나 걸립니까?

ServiceNow에서 접수 워크플로로 시작하면 보통 두세 달이 걸립니다. S/4HANA로의 이전은 복잡도에 따라 9개월에서 18개월이 걸리는 경우가 많고, 커스터마이징이 많은 대규모 다법인 기업은 더 오래 걸립니다.

단계가 차례로 이어질 필요는 없습니다. SAP 준비 작업과 ServiceNow 안정화를 병행하면 전체 일정이 단축됩니다.

SAP와 ServiceNow 현대화의 현실적인 ROI 시점은 언제입니까?

대부분의 조직은 3개월에서 6개월 사이에 소프트한 효과를 봅니다. 사이클 타임 단축, 수작업 인수인계 감소, 가시성 개선입니다. 측정 가능한 비용 절감과 효율 향상 같은 유형의 효과는 12개월에서 18개월 안에 나타나는 경향이 있으며, 두 플랫폼이 모두 기여하기 시작하면 특히 그렇습니다.

시작하기 전에 사이클 타임, 오류율, SLA 준수율을 추적하십시오. 기준선이 없으면 수익은 숫자가 아니라 이야기입니다.

ERP 현대화가 늦어졌다는 것을 어떻게 알 수 있습니까?

흔한 신호는 이렇습니다. 해결 시간이 길어지며 늘어나는 지원 티켓, 반복해서 미뤄지는 업그레이드와 패치, 같은 데이터에 대한 여러 개의 진실 공급원, ERP가 메우기로 했던 빈틈을 채우는 섀도 IT입니다.

SAP ECC를 운영하던 한 헬스케어 고객사는 한 분기에 여러 건의 SLA를 놓쳤습니다. 문제는 노력이 아니라 기술 부채였습니다. 수년간 쌓인 작은 수정들이 겹겹이 얹혔고, 인시던트는 누구도 분류할 수 있는 속도보다 빨리 접수되었습니다.

SAP와 ServiceNow는 다른 서드파티 시스템과도 연동할 수 있습니까?

예. SAP는 외부 시스템과의 API 기반 연결에 SAP BTP의 SAP Integration Suite를 씁니다. ServiceNow는 Workday, Salesforce, Coupa를 포함한 대부분의 엔터프라이즈 플랫폼용 사전 구축 커넥터를 갖춘 IntegrationHub를 제공합니다.

통합을 처음부터 하나의 워크스트림으로 다루십시오. 늦게 범위를 정한 인터페이스가 Go-Live 후 가장 큰 마찰을 만들므로, 통합 설계는 블루프린트 단계에서 시작하십시오.