FMCG 기업의 ERP 복구: SAP Analytics Cloud로 리포팅 통합

이 사례 연구는 ERP를 둘 이상 운영하면서 하나로 통일된 숫자를 얻지 못하는 CFO와 IT 리더를 위한 것입니다. 요약하면 이렇습니다. 싱가포르의 Oracle과 영국의 SAP 사이에서 멈춰 섰던 국경 간 리포팅 프로젝트를 6개월 만에 되살렸습니다. 다섯 가지가 해냈습니다. 실질적인 권한을 가진 더 작은 운영위원회. 의사결정을 이끄는 보고서로 줄인 범위. 두 시스템에 걸쳐 합의한 정의. 단일 리포팅 계층으로서의 SAP Analytics Cloud. 그리고 집합 교육 대신 현지 챔피언. 같은 처지에 있다면 도구 논쟁이 아니라 거버넌스와 정의부터 시작하십시오.

이야기는 싱가포르에 본사를 둔 유명 FMCG 그룹에서 멈춰 선 ERP 분석 프로젝트에서 시작합니다. 이 그룹은 영국 에너지 드링크 사업체의 지분 26%를 보유하고 있었습니다. 소수 지분이었지만 경영 통제권은 싱가포르에 있었기 때문에, 아시아 이사회의 전략이 유럽의 일상 리포팅과 계획을 좌우했습니다.

기술이 상황을 더 어렵게 했습니다. 싱가포르는 Oracle ERP를, 영국은 SAP ERP를 운영했습니다. 각각은 따로 잘 돌아갔지만, 합치면 이미 몇 달의 노력을 삼킨 리포팅 문제가 생겼습니다.

숫자는 좀처럼 맞지 않았습니다. 대사는 며칠씩 늘어졌습니다. 기본적인 매출 보고조차 어느 시스템을 보느냐에 따라 다르게 나왔습니다.

복구 프로젝트를 시작한 지 6개월 만에, 실패한 이니셔티브처럼 보이던 것이 재무와 운영이 모두 신뢰하는 국경 간 리포팅 모델이 되었습니다.

복구 이전재가동 시점

거버넌스복구 이전큰 규모의 운영위원회, 미뤄지는 의사결정재가동 시점실제 의사결정자만 참여, 회의 중에 결정

범위복구 이전요청으로 빼곡한 화이트보드재가동 시점의사결정을 이끄는 보고서

정의복구 이전같은 레이블, ERP마다 다른 의미재가동 시점합의된 매출, 원가, 마진

리포팅복구 이전며칠 걸리던 Excel 대사재가동 시점SAP Analytics Cloud의 하나의 모델 안에 Oracle과 SAP 데이터

도입복구 이전집합 교육 후 다시 Excel로재가동 시점현지 챔피언, 한 번에 한 팀씩

표는 출발 상황과 각 문제가 어떻게 해결되었는지를 요약합니다.

과제	영향	SAP Analytics Cloud를 통한 해결
두 개의 ERP: 싱가포르는 Oracle, 영국은 SAP	숫자가 맞지 않았고 대사에 며칠이 걸림	둘 다 하나의 리포팅 모델로 입력됨
국경을 넘는 리포팅 책임 소재 불분명	아시아의 전략이 유럽의 운영 데이터와 충돌	표준 KPI로 두 법인이 같은 지표를 보고
더딘 매출 보고	원천 시스템에 따라 수치가 달라 의사결정이 지연	통합된 계획과 리포팅이 주기를 단축
계획 불일치	싱가포르가 전략을 정하고 영국은 다른 가정으로 실행	공유 계획 모델이 두 사업을 정렬

두 ERP에 걸친 리포팅

싱가포르는 Oracle, 영국은 SAP를 쓰다 보니 리포팅은 두 개의 별개 사업을 운영하는 것과 같았습니다. 재무팀이 두 시스템에서 같은 지표를 뽑으면 답이 서로 달랐습니다. 어느 월간 검토에서는 싱가포르가 매출 수치를 제시하자 영국이 곧바로 다른 수치로 반박했습니다. 논쟁이 검토 회의보다 더 오래 이어졌습니다.

사람들은 더 안전하게 느껴져서 Excel로 되돌아갔습니다. 몇 시간씩 내보내고, 대사하고, 자기만의 진실 버전을 만들었습니다. 단기적으로는 통했지만 그룹 리포팅에 만성적인 지연을 낳았습니다. 이 패턴은 CFO가 여전히 Excel을 찾는 이유를 다룬 제 글에서 더 폭넓게 설명합니다.

월말 연결 결산

월말이 가장 힘든 부분이었습니다. 한 ERP에서 "운영" 아래 있던 비용이 다른 ERP에서는 "관리" 아래로 들어가는 일이 있었습니다. 같은 비용이 서로 다른 항목 아래 두 번 나타난 연결 결산 초안을 본 적도 있습니다. 그 일로 숫자에 대한 신뢰가 무너졌습니다. 결과가 늦어지는 것이 일상이 되었고, 그룹이 발표하고 나면 대개 수정이 뒤따랐습니다.

운영 리포팅

문제는 재무에만 있지 않았습니다. Oracle은 출하를, SAP는 재고를 추적했고 단일 원천은 없었습니다. 한 창고 매니저는 한 주 동안 서로 다른 재고 보고서를 세 건 받았고 잔량이 전부 달랐다고 말했습니다. 그는 웃으면서 말했지만, 그것은 실제 의사결정을 늦추고 있었습니다. 보충이 지연되었고, 운영 부서가 대시보드를 신뢰하지 않았기 때문에 배송 지연은 설명하기가 더 어려웠습니다.

도구 논쟁

리포팅 도구를 고르는 일이 그 자체로 하나의 프로젝트가 되었습니다. 어떤 매니저들은 Power BI의 비용 구조를 좋아했고, 다른 이들은 더 긴 로드맵 때문에 SAP를 밀었습니다. 저는 워크숍 시간의 절반이 리포팅 요구 사항이 아니라 "왜 Power BI가 아니라 SAC인가"에 쓰이는 자리에 앉아 있었습니다. 논쟁은 몇 달 이어졌고 추진력을 갉아먹었습니다.

사용자 저항

첫 대시보드가 가동된 뒤에도 도입률은 낮은 채로 남았습니다. 재무 회의에서 어떤 사람이 대시보드를 열어 힐끗 보고는 닫은 뒤 다시 자기 Excel 시트로 돌아가던 모습이 기억납니다. 아무도 그것을 문제 삼지 않았습니다. 사람들은 아는 것을 믿었고, 대시보드는 아직 그 신뢰를 얻지 못했습니다.

거버넌스 재설정. 회의는 끝이 없는 것처럼 느껴졌고, 사람들은 누가 결정을 내렸는지 모른 채 회의장을 떠났습니다. 경영진은 운영위원회를 실제 의사결정자로만 줄였습니다. 세션은 더 짧고 단호해졌고, 에스컬레이션은 적임자에게 빠르게 닿았습니다. 완벽하지는 않았지만 일이 움직이기 시작했습니다. 같은 원칙은 SAP 운영위원회 운영 가이드에 정리되어 있습니다.

범위 통제. 사람들은 어떤 숫자가 그룹 뷰에 들어가야 하는지를 두고 끊임없이 다투었고, 요구 사항 목록은 감당할 수 없게 불어나 있었습니다. 워크숍 화이트보드가 끝에서 끝까지 요청으로 뒤덮여 있었고, 그중 절반은 실제 의사결정과 무관했던 것이 기억납니다. 통했던 프레임은 이것이었습니다. 리포팅은 의사결정을 이끄는 것만 다루면 된다. 이에 합의하자 납품 속도가 붙었습니다.

와닿는 커뮤니케이션. 이전의 업데이트는 일반적이어서 재무, 운영, IT가 각자 다르게 해석했습니다. 저희는 맞춤형 업데이트로 바꾸었습니다. 재무에는 리포팅 일정, 운영에는 물류 프로세스 변경, IT에는 기술 로드맵을 전했습니다. 업데이트가 각자의 언어로 말하자 사람들은 더 나은 질문을 하기 시작했습니다.

현지 챔피언. 교육만으로는 효과가 없었습니다. 사람들은 세션을 듣고 나서 다음 날 아침이면 Excel로 돌아갔습니다. 변화는 현지 챔피언에게서 왔습니다. 팀 안에서 이미 신뢰를 얻고 있던 동료들이 자기 말로 대시보드를 비공식적으로 설명해 준 것입니다. 저는 그런 세션 하나에 참석했는데 차이가 놀라웠습니다. 사람들은 강의실에서는 결코 하지 않았을 질문을 했습니다. 도입은 한 번에 한 팀씩 나아졌습니다.

표는 무엇이 달라졌고 왜 효과가 있었는지를 요약합니다.

중점 영역	달라진 점	영향
거버넌스 재설정	운영위원회를 실제 의사결정자로 축소. 더 짧고 날카로운 세션	회의 중에 결정이 내려지고 에스컬레이션이 빠르게 진행
범위 통제	요구 사항을 의사결정을 이끄는 리포팅으로 압축	논쟁 감소, 더 명확한 데이터 모델, 움직이는 목표 감소
맞춤형 커뮤니케이션	재무, 운영, IT에 각각 별도 업데이트	각 팀이 자신에게 중요한 것을 이해했고 신뢰가 돌아옴
현지 챔피언	정식 강의 대신 소규모 그룹의 동료 코칭	팀별로 도입이 개선되고 Excel 의존도 하락

도구 선정이 마침내 마무리되었을 때 SAC가 선택되었습니다. 큰 맞춤 개발 없이 Oracle과 SAP 데이터를 하나의 모델로 가져올 수 있다는 점이 한 이유였습니다. 그 덕분에 논의의 열기가 어느 정도 가라앉았습니다. 보고서는 예전의 내보내기 주기보다 훨씬 빠르게 변경 사항을 반영했습니다. 한 재무 컨트롤러는 하루를 시작하려고 밤사이 데이터 새로고침을 기다릴 필요가 없었던 것은 처음이라고 말했습니다.

재무 매니저가 Oracle 데이터와 SAP 데이터를 하나의 대시보드에서 나란히 본 순간, 짐이 내려졌습니다. 그 순간이 논쟁을 끝냈습니다.

SAC는 재무 이상을 다루었습니다. 운영 부서는 물류와 창고를 한눈에 보기를 원했고, HR은 인력 계획을 원했습니다. 계획, 리포팅, 시각화를 하나의 플랫폼에 두었다는 점이 단기 임시방편과 장기적인 기반을 가르는 차이를 만들었습니다. 사전 구축된 템플릿은 일부가 평범하게 느껴졌더라도 팀에 앞선 출발을 주었고, 첫 납품의 속도는 몇 달간의 지연 끝에 신뢰를 회복시켰습니다.

이 설계를 그대로 따르려는 분을 위한 기술적 포인트가 하나 있습니다. SAC 라이브 데이터 연결은 SAP HANA, BW, S/4HANA, BPC embedded, BusinessObjects 유니버스, SAP Datasphere 같은 SAP 소스로 제한됩니다. Oracle ERP 같은 비SAP 데이터는 보통 가져오기(import) 연결이나 유니버스, 또는 중간의 데이터 계층을 통해 들어옵니다. 이 아키텍처는 일찍 정하십시오. 양쪽 숫자가 얼마나 최신 상태일 수 있는지를 좌우하기 때문입니다.

첫 마일스톤은 데이터 모델이었습니다. Oracle과 SAP가 하나의 구조에 함께 데이터를 공급해야 했는데, 보기보다 어려웠습니다. 필드는 같은 레이블을 달고 있어도 시스템마다 의미가 달랐습니다. 매출, 원가, 마진이 실제로 무엇을 뜻하는지 재무가 합의하기까지 정의를 매핑하는 데 몇 주가 걸렸습니다.

대시보드는 단계적으로 배포했습니다. 재무가 먼저였고, 그다음 영업과 운영이 이어졌으며, 각자의 실제 업무를 중심으로 보고서를 만들었습니다. 초기 버전은 지나치게 경직되어 있었습니다. 사용자들이 그렇게 말했고, 맞는 말이었습니다. 대시보드는 개선되었고, 합의된 KPI가 매달 되풀이되던 논쟁을 대체했습니다.

재가동은 6개월 안에 완료되었습니다. 처음으로 Oracle과 SAP 데이터가 SAC 안의 하나의 모델에 담겼습니다. 대사를 둘러싼 논쟁이 줄었고, 경영진은 Excel 파일이 돌기를 기다리지 않고 숫자를 검토했습니다.

몇 주 걸리던 계획 주기가 며칠로 줄었습니다. 계획 담당자들은 시나리오를 모델링하고 실적과 비교할 수 있었습니다. 대시보드가 주는 것보다 더 많은 세부 정보를 원하는 매니저도 있었지만, 숫자를 신뢰한다는 사실만으로도 이미 의미가 컸습니다.

한 창고 매니저는 처음으로 자기 보고서의 재고 수준이 재무가 보여 주는 수치와 일치했다고 말했습니다. 부서들 사이의 그 조용한 일치가 진짜 지표였습니다. 옛 프로세스로 돌아가자고 요구한 사람은 아무도 없었습니다.

표는 프로젝트를 멈추게 한 실수와 각각에서 얻은 교훈을 정리한 것입니다.

실수	초래한 결과	교훈
불분명한 거버넌스	끝없는 회의, 결정 부재, 쌓여 가는 지연	역할과 의사결정 권한을 일찍 재설정하십시오
범위 이탈	리포팅 목표가 계속 바뀜	범위를 좁게, 의사결정에 묶어 유지하십시오
사용자 무시	사용자가 신뢰를 잃고 도입이 더뎌짐	사용자를 일찍 참여시키고 맥락을 제공하십시오
과도한 커스터마이징	보고서를 다시 만드느라 시간 낭비	템플릿과 표준 커넥터로 시작하고 커스터마이징은 나중에 하십시오
취약한 변화 관리	교육이 겉돌고 옛 습관이 남음	현지 챔피언과 동료 코칭을 일찍 도입하십시오

세 가지 교훈이 나머지보다 앞섭니다. 거버넌스가 도구보다 중요합니다. 멀티 ERP 환경에서 책임 소재가 분명하지 않으면 어떤 플랫폼이든 리포팅은 무너집니다. 도구를 고르기 전에 데이터 정의를 정렬하십시오. Power BI 대 SAC 논쟁은 핵심을 놓쳤습니다. 어떤 도구도 맞지 않는 정의를 고쳐 주지 않기 때문입니다. 그리고 도입 여부는 변화 관리가 결정합니다. 챔피언과 맞춤형 커뮤니케이션이 없었다면 대시보드는 쓰이지 않은 채 남았을 것입니다.

같은 작업을 지금 시작한다면 세 가지가 달라질 것입니다.

SAC와 소스 사이에 데이터 계층이 들어갈 것입니다. 이제 SAP Business Data Cloud의 일부인 SAP Datasphere는 SAP와 비SAP 소스에 대한 연합 접근을 시맨틱 모델과 함께 제공합니다. 이 사례처럼 ERP가 두 개인 경우, Oracle과 SAP 데이터를 SAC 스토리마다 처리하기보다 그 계층에서 정합화하는 편이 더 깔끔합니다. 또한 SAC가 정합화된 모델에 라이브 연결을 가질 수 있게 됩니다.

자연어 질문이 일부 대시보드 구축을 대체할 것입니다. SAC의 자연어 질의와 Joule을 쓰면 재무팀이 가령 이번 분기의 지역별 매출을 싱가포르와 영국 대비로 요청할 수 있습니다. 먼저 스토리를 만들 필요가 없습니다. 데이터가 정합화된 뒤에는 작업이 빨라집니다. 정의의 간극을 메워 주지는 않습니다.

상업 협의는 ERP 계약에서 출발할 것입니다. SAC를 협상하기 전에 클라우드 ERP 계약에 어떤 분석 기능이 이미 포함되어 있는지 확인하십시오. SAC의 전체 계획 기능은 별도로 라이선스되며, 한 법인은 클라우드 ERP를 쓰고 다른 법인은 쓰지 않는 하이브리드 환경은 여전히 신중한 라이선스 검토가 필요합니다.

거버넌스 재설정, 범위 규율, 현지 챔피언, 맞춤형 커뮤니케이션은 달라지지 않을 것입니다. 이 패턴들은 기술이 무엇이든 유효합니다. 두 ERP가 같은 숫자를 보고하게 만드는 사람의 일은 자동화되지 않습니다. SAC 자체에 관해서는 SAP Analytics Cloud 가이드를 참고하십시오.

이 FMCG 그룹의 ERP 리포팅 프로젝트는 왜 멈춰 섰습니까?

싱가포르는 Oracle을, 영국은 SAP를 운영했고, 매달 재무팀이 숫자를 손으로 이어 붙였습니다. 며칠이 걸렸고 아무도 결과를 완전히 신뢰하지 못했습니다. 싱가포르가 한 수치를 제시하고 영국이 다른 수치로 반박하면 검토가 멈췄습니다. 운영위원회도 너무 커서 아무도 결정을 내리지 못했습니다. 비용은 늘고 신뢰는 떨어졌으며 프로젝트는 표류했습니다.

복구의 방향을 바꾼 것은 무엇입니까?

경영진이 프로젝트가 막혔음을 인정하고 복구 계획에 합의했습니다. 운영위원회를 실제 의사결정자로 이루어진 소규모 그룹으로 줄이고, 우선순위를 정하고, SAP Analytics Cloud를 단일 리포팅 도구로 선택했으며, 커뮤니케이션은 대상별로 달라졌습니다. 회의는 책임 공방에서 다음에 무엇을 할지로 옮겨 갔고, 사람들은 프로젝트가 결과를 낼 수 있다고 믿기 시작했습니다.

SAP Analytics Cloud는 Oracle과 SAP를 어떻게 함께 처리했습니까?

SAC가 Oracle과 SAP 데이터를 하나의 리포팅 모델로 가져와서, 수작업 대사 파일 없이 하나의 대시보드에 둘을 나란히 보여 주었습니다. 두 시스템을 한 화면에서 본 순간이 도구 논쟁을 끝냈습니다. 참고로 SAC의 라이브 연결은 SAP 소스만 지원합니다. Oracle 데이터는 보통 가져오기 연결, BusinessObjects 유니버스, 또는 SAP Datasphere 같은 데이터 계층을 통해 들어옵니다.

사용자들은 처음에 왜 대시보드를 꺼렸습니까?

대시보드가 충분한 비즈니스 맥락 없이 출시되었기 때문입니다. 사용자들은 SAC를 쓰라는 말을 들었지만 그것이 자기 일상 업무에 어떻게 적용되는지 보여 주는 사람은 없었고, 교육도 일반적이었습니다. 사람들은 아는 것을 믿는데, 대시보드는 아직 그 신뢰를 얻지 못했습니다. 현지 챔피언이 자기 말로 대시보드를 설명하면서 그것이 달라졌습니다.

성공적인 ERP 리포팅 복구는 어떤 모습입니까?

하나의 요인인 경우는 드뭅니다. 이 사례에서는 거버넌스 재설정, 범위 축소, 합의된 정의, 맞춤형 커뮤니케이션, 동료 챔피언이 함께 작동했습니다. SAC가 도움이 된 것은 큰 맞춤 개발 없이 두 ERP를 하나의 모델로 가져왔기 때문이지만, 기술만으로는 프로젝트를 살리지 못했을 것입니다. 6개월이 지났을 때, 프로젝트가 무너지기를 기다리던 사람들이 직접 만든 대시보드를 발표하고 있었습니다.