요약: SAP S/4HANA 전환 프로그램은 기업이 해당 전환의 기능적·데이터적 영향에 대해 충분히 이해하기 전에, 비즈니스 마감 기한이나 유지보수 종료 시점에 맞춰 계획되는 경우가 많습니다. 데이터 전문가의 관점에서 보면, 이는 특히 주요 아키텍처 및 마이그레이션 결정이 충분히 검토되기 전에 일정이 정의될 경우 상당한 전달 리스크를 초래할 수 있습니다.
이 블로그에서 EPI-USE Labs PRISM Transformation Global Service Line의 Managing Director인 Jamie Neilan은 S/4HANA 프로젝트에서 데이터 전환과 기능 변화가 왜 밀접하게 얽혀 있는지에 대한 자신의 관점을 공유합니다. 그는 20년 이상의 SAP 경험을 바탕으로 조직이 전환 프로그램을 시작하기 전에 고려해야 할 준비 단계와, 다양한 S/4HANA 시나리오가 데이터 마이그레이션의 복잡성과 자동화 가능성에 어떤 영향을 미치는지를 설명합니다.
요약: SAP S/4HANA 전환 프로그램은 기업이 해당 전환의 기능적·데이터적 영향에 대해 충분히 이해하기 전에, 비즈니스 마감 기한이나 유지보수 종료 시점에 맞춰 계획되는 경우가 많습니다. 데이터 전문가의 관점에서 보면, 이는 특히 주요 아키텍처 및 마이그레이션 결정이 충분히 검토되기 전에 일정이 정의될 경우 상당한 전달 리스크를 초래할 수 있습니다.
이 블로그에서 EPI-USE Labs PRISM Transformation Global Service Line의 Managing Director인 Jamie Neilan은 S/4HANA 프로젝트에서 데이터 전환과 기능 변화가 왜 밀접하게 얽혀 있는지에 대한 자신의 관점을 공유합니다. 그는 20년 이상의 SAP 경험을 바탕으로 조직이 전환 프로그램을 시작하기 전에 고려해야 할 준비 단계와, 다양한 S/4HANA 시나리오가 데이터 마이그레이션의 복잡성과 자동화 가능성에 어떤 영향을 미치는지를 설명합니다.
SAP S/4HANA 프로젝트는 매우 다양한 형태를 가집니다. 소스 시스템은 서로 다르고, 데이터베이스 변경 방식도 다양하며, 커스텀 코드는 거의 없는 수준부터 사실상 무한에 가까운 수준까지 존재할 수 있습니다. 또한, 기업이 SAP를 사용하는 방식 역시 매우 다양합니다. 이러한 복잡성에도 불구하고 프로젝트 일정은 종종 매우 이른 단계에서 정의되며, 이는 충분한 인사이트 없이 비즈니스 요구사항이나 재무 모델링에 기반해 결정되는 경우가 많습니다.
데이터 전문가의 관점에서 보면, 바로 이 지점에서 많은 프로젝트가 어려움을 겪기 시작합니다.
EPI-USE Labs에서는 다양한 S/4HANA 전환 프로젝트를 수행하며 여러 접근 방식을 접하고 있습니다. 어떤 조직은 Selective Data Transition(SDT)을 선택하고, 다른 기업은 전체 시스템 마이그레이션을 계획합니다. 어떤 경우에는 단계적으로 진행하고, 또 어떤 경우에는 단일 대규모 전환 또는 업그레이드를 시도합니다. 이러한 모든 시나리오에서 우리는 유사한 질문들을 검토합니다:
SAP는 여전히 매우 뛰어난 기술입니다. 전 세계 금융, 물류, 급여, 제조, 프로젝트 관리 시스템의 상당 부분이 SAP 위에서 운영되고 있습니다. 따라서, S/4HANA로의 전환은 단순한 기술 업그레이드 이상의 의미를 갖습니다. 이는 기업 내 가장 중요한 시스템 중 하나에 대한 전환입니다.
이 때문에 기업들은 종종 전환 과정에서 즉각적인 가치를 얻으려 합니다. S/4HANA로의 전환은 클라우드 아키텍처, 향상된 보안, 현대적인 데이터 기능, AI 준비성 등의 이점을 제공할 것으로 기대됩니다. 그러나 제가 자주 관찰하는 것은 이러한 프로그램의 요구 사항이 여전히 모호하거나 충분히 조사되지 않았다는 점입니다. 이러한 긴급성은 주로 유지 보수 종료 기한과 레거시 플랫폼에서 벗어나야 한다는 압박에서 비롯됩니다.
이러한 긴급성은 이해할 수 있습니다. 하지만 너무 빠르게, 너무 이른 시점에 밀어붙이면 불필요한 리스크를 초래하는 경우가 많습니다.
대부분의 사람들은 토끼와 거북이 이야기를 알고 있습니다. 느리고 꾸준한 쪽이 경주에서 승리한다는 이야기입니다. 핵심 메시지는 간단합니다. 앞길을 신중하게 고려하지 않고 너무 빠르게 움직이면 결국 실패할 수 있다는 것입니다.
저는 아일랜드 게일계(Gaelic) 혈통을 가지고 있어 주로이런 이야기들의 기원에 늘 관심이 있었습니다. 스코틀랜드 게일어 설화 중에는 ‘Maol a’ Chreachainn’이라는 유사한 이야기가 있는데, 흔히 ‘털 없는 여우(The Bare-Skinned Fox)’로 번역됩니다.
이 이야기에서 초라한 여우는 자신보다 크고 강한 동물들을 만나게 됩니다. 그 동물들은 힘과 속도에 의존합니다. 반면 여우는 인내, 관찰, 전략에 의존합니다. 끈기와 신중한 사고를 통해 여우는 반복적으로 상황을 자신에게 유리하게 바꿉니다. 속도나 힘에만 의존한 강한 동물들은 결국 패배하게 됩니다.
스코틀랜드 및 게일 신화는 대부분 구전으로 전해졌기 때문에 원본 텍스트를 직접 인용할 수는 없지만, 온라인에서 사례를 찾을 수 있습니다. 가장 초기의 기록 중 하나는 19세기 J. F. Campbell에 의해 수집되었습니다. 이러한 이야기들은 오래되었지만, 그 교훈은 여전히 중요하며 S/4HANA 프로젝트 맥락에서도 (제 생각에는) 충분히 적용됩니다. 많은 S/4HANA 프로그램이 이러한 교훈을 기억할 필요가 있습니다.
ERP 전환에서 가장 흔한 오해 중 하나는 기능 변화와 데이터 전환을 독립적으로 계획할 수 있다는 생각입니다. 실제로는 이 둘은 매우 밀접하게 얽혀 있습니다.
이로 인해 비즈니스 이해관계자와 기술 팀 간의 긴장이 발생하기도 합니다. 그러나 이 시점에서 대부분의 기업은 IT가 단순한 지원 기능이 아니라, 비즈니스 운영의 핵심이라는 점을 인식하고 있습니다.
S/4HANA 전환을 고려하거나 이미 진행 중인 기업이라면, 프로젝트가 본격적으로 가속화되기 전에 반드시 명확히 이해해야 할 여러 영역이 있습니다. 이러한 요소들이 아직 정의되지 않았다면, 단순히 마감 기한을 맞추기 위해 서두르기보다는 잠시 멈추고 제대로 정리하는 것이 더 바람직합니다.
철저한 준비는 전환 비용을 줄이고 성공적인 go-live 가능성을 크게 높입니다. 다시 말해, 토끼보다 거북이의 접근 방식이 더 성공적인 경우가 많습니다. 초기에는 준비 과정이 느리게 느껴질 수 있지만, 결국 훨씬 안정적인 전환 여정을 만들어냅니다.
Customer and Vendor Integration은 Business Partner 모델을 도입하는 것으로, 데이터 관점에서 매우 중요한 준비 단계입니다. SAP는 CVI cockpit을 포함한 명확한 가이드와 도구를 제공합니다. 그러나 기술적 프로세스를 시작하기 전에 기능적인 의사결정이 선행되어야 합니다.
SAP는 오랫동안 S/4HANA 전환 이전에 CVI를 사전 작업으로 수행할 것을 권장해 왔습니다. 프로젝트 중에 수행할 수도 있지만, 그렇게 하면 복잡성과 리스크가 증가합니다.
프로그램 초기 단계에서 이해해야 할 다른 기능 변화들도 있습니다. S/4HANA에서는 Asset Accounting이 변경되며, 기업은 새로운 모델을 어떻게 도입하고 기존 구조를 어떻게 전환할지 명확히 이해해야 합니다.
New General Ledger는 단순한 선택적 기능이 아닙니다. 이는 S/4HANA 아키텍처의 핵심 구성 요소이므로 신중한 계획이 필요합니다.
Simplification items와 관련된 비즈니스 프로세스 변화 역시 중요한 역할을 합니다. 이러한 변화는 S/4HANA에서 기존 기능이 어떻게 변화하거나 사라지는지를 결정합니다. 이를 조기에 이해하면 Greenfield, Brownfield 또는 Hybrid 전환 방식 중 어떤 접근이 적절한지 판단하는 데 도움이 됩니다.
많은 조직이 S/4HANA 전환을 기업 구조를 재설계할 기회로 활용합니다. Company code가 재구성되거나 시스템이 통합되고, 리포팅 구조가 단순화될 수 있습니다. 그러나 실제로는 목표 아키텍처에 대한 명확한 정의 없이 프로젝트가 시작되는 경우가 많습니다.
구조적 변화가 포함되어 있다면, 엔터프라이즈 아키텍처 전문 인력이 초기부터 참여해야 합니다. 현재 상태, 전환 상태, 목표 아키텍처를 명확히 정의해야 하며, 이러한 결정은 기능 설계와 데이터 전환 전략 모두에 영향을 미칩니다.
데이터 관점에서 S/4HANA 전환은 일반적으로 몇 가지 범주로 나뉩니다. 각 범주는 어떤 마이그레이션 기법과 자동화 방식이 가능한지를 결정합니다. 이러한 차이를 초기에 이해하려면 인내와 전략적 사고가 필요합니다. 자신의 시스템 환경을 충분히 이해하는 데 시간을 투자한 조직이 가장 큰 비용 손실을 피하는 경우가 많습니다.
이 시나리오는 데이터 관점에서는 비교적 단순하지만, 여전히 필수적인 기능 변화는 존재합니다. 많은 경우 고도로 자동화된 SDT 접근 방식이 사용될 수 있으며, 데이터는 높은 수준의 자동화로 point-to-point 이동이 가능합니다.
Greenfield 전환은 훨씬 더 많은 비즈니스 프로세스 변화를 포함합니다. 그 결과 데이터 마이그레이션은 기능 중심이 되며, 일부 데이터는 새로 생성될 수 있습니다.
SAP의 Data Migration Cockpit이 주요 적재 메커니즘으로 사용되며, 다른 인증 도구도 활용될 수 있습니다. 선택적 추출 파이프라인도 자동화할 수 있지만, 일반적으로 더 많은 수작업과 기능 검증이 필요합니다.
S/4HANA 환경에서는 하나의 ECC 시스템이 더 유연한 composable 아키텍처로 발전할 수 있습니다. Finance와 Logistics는 S/4HANA에 남고, HCM, Payroll, Customer engagement, Contract accounting 등은 전문 플랫폼으로 이동할 수 있습니다.
타겟 시스템이 ABAP 기반이라면 자동화 수준을 높게 유지할 수 있습니다. SaaS나 API 기반 시스템이 포함되면 일반적으로 반자동 마이그레이션 접근이 필요합니다.
여러 레거시 시스템을 하나의 S/4HANA 환경으로 통합하는 경우도 흔합니다. 이는 비용 절감이나 라이선스 단순화를 위한 경우가 많지만, 기술적으로는 가장 복잡한 시나리오 중 하나입니다.
초기 데이터 적재는 자동화가 가능하지만, 여러 시스템을 병합하거나 단계적 go-live를 관리하려면 반자동 접근과 철저한 검증이 필요합니다.
우리가 자주 목격하는 패턴 중 하나는 명확한 데이터 전략 없이 S/4HANA 프로젝트가 실행 단계로 들어가는 것입니다. 일부 조직은 데이터 전문가와 상의하지 않은 채 기능 중심 RFP를 발행하거나 일정부터 확정합니다.
이 경우 보통 두 가지 결과 중 하나로 이어집니다:
이 두 경우 모두 피할 수 있는 리스크를 초래합니다.
S/4HANA 전환은 앞으로도 오랜 기간 지속될 것입니다. 이는 기업이 수행하는 가장 크고 복잡한 핵심 시스템 변화 중 하나입니다.
오래된 우화의 교훈은 여전히 유효합니다. 토끼는 속도와 자신감에 의존했고 실패했습니다. 게일의 여우는 인내와 전략에 의존했고 성공했습니다.
S/4HANA 전환에서도 철저한 준비와 현실적인 계획이 성급한 일정 추진보다 거의 항상 더 나은 결과를 만들어냅니다.
데이터 전환은 SAP S/4HANA 프로그램에서 가장 복잡하면서도 과소평가되는 영역 중 하나입니다.
다가오는 웨비나, ‘Automating data transition in SAP S/4HANA’, 에서는 다양한 전환 시나리오가 데이터 전략에 어떤 영향을 미치는지, 그리고 자동화 기술이 전달 리스크를 어떻게 줄일 수 있는지를 다룹니다.
지금 등록하여 논의에 참여하시거나, EPI-USE Labs와 EPI-USE 전문가들이 실제 프로젝트 경험을 바탕으로 인사이트를 공유하는 De-risking SAP transformations 웨비나 시리즈 전체를 확인해 보세요.