지난 몇 주간 저는 S/4에 대한 학습을 꾸준히 이어왔습니다. 바르셀로나에서 열린 TechEd는 예상대로 S/4 관련 콘텐츠가 중심이었고, 자매 회사 G3G의 Vibe 행사에서도 S/4 주제가 전면에 다뤄졌습니다. 이어 맨체스터와 네덜란드에서 열린 당사 User Group 행사까지 참석했습니다. 여기에 더해, 당사의 S/4 역량과 IP 및 기술이 어떻게 기여할 수 있는지에 대해 내부 동료들과 논의하면서, 저는 한 가지 사실을 깨달았습니다. 아마도 많은 SAP 사용자 조직에서도 동일하게 나타나고 있을 현상입니다.
지난 몇 주간 저는 S/4에 대한 학습을 꾸준히 이어왔습니다. 바르셀로나에서 열린 TechEd는 예상대로 S/4 관련 콘텐츠가 중심이었고, 자매 회사 G3G의 Vibe 행사에서도 S/4 주제가 전면에 다뤄졌습니다. 이어 맨체스터와 네덜란드에서 열린 당사 User Group 행사까지 참석했습니다. 여기에 더해, 당사의 S/4 역량과 IP 및 기술이 어떻게 기여할 수 있는지에 대해 내부 동료들과 논의하면서, 저는 한 가지 사실을 깨달았습니다. 아마도 많은 SAP 사용자 조직에서도 동일하게 나타나고 있을 현상입니다.
프로젝트 유형은 보는 관점에 달려 있다
모듈중심의 기능적 관점에서 보면
모듈컨설턴트와 같이 기능(functional) 배경을 가진 사람들은 필요한 비즈니스 프로세스 변화에 초점을 맞추는 경향이 있습니다. 가장 단순하고 빠르며 비용 효율적인 S/4 프로젝트를 추진하려는 조직이라 하더라도, 지원 기능의 변화로 인해 상당한 작업이 필요할 수 있습니다. 비즈니스와 밀접하게 일하는 기능 담당자라면, 실제로 수행해야 할 업무에 초점을 맞추게 됩니다. 사전에 처리해야 할 여러 단계가 있습니다. 예를 들어, 시스템에 존재하는 모든 Customer 또는 Vendor 마스터에 대해 Business Partner 레코드를 생성해야 하는 Customer Vendor Integration(CVI) 작업이 있습니다. 또한 SAP Readiness Check와 Simplification List는 필요한 비즈니스 프로세스 변경 사항을 강조합니다. 저희 그룹내 모듈중심의 컨설팅사(G3G)의 경험으로 보면, 그들이 사용하던 SD Revenue Recognition 기능은 최신 S/4 버전에서 더 이상 제공되지 않습니다. 따라서, 프로젝트의 일환으로 Accounting에서 매출 인식을 구현해야 합니다. 또한 GTS, EWM, 일부 SRM, CRM, Analytics 기능이 S/4로 통합되면서, 기존 일부 기능은 중단되고 흡수된 프로세스로 대체됩니다. 기능적 관점에서 보면 이는 단순 전환이 아니라, 새로운 기능을 도입하여 시스템을 개선할 기회이기도 합니다. G3G 세션에서 CEO Chris Gunther는 점점 더 치열해지는 시장 환경 속에서 이 기회를 혁신의 발판으로 삼아 비즈니스를 전진시켜야 한다고 강조했습니다.
데이터 품질 작업도 상당히 필요합니다. 한 파트너는 코스트 센터가 존재하지 않음에도 이를 참조하는 문서 문제를 해결해야 했다고 말했습니다. 기능적 관점에서는 이를 단순 수정이 아니라 데이터 정비와 품질 개선, 더 나아가 데이터 거버넌스 도입의 기회로 볼 수 있습니다.
그리고 UI가 있습니다. SAP GUI는 오랫동안 단점으로 지적되어 왔으며, 이제는 Fiori로 전환이 가속화되고 있습니다. 사용자는 대형 트랜잭션 코드 대신 역할 기반의 소규모 Fiori 앱을 사용하게 되므로, 비즈니스 프로세스와 문서 역시 변경이 필요합니다. G3G의 CTO Andrew Borressen으로부터 ‘Lighthouse Fiori Apps’라는 개념을 알게 되었는데, 이는 SAP가 특히 유용하고 중요하다고 보는 Fiori 앱들로, 방대한 Fiori 앱 중에서 핵심을 구분할 수 있도록 돕습니다.
테크니컬한 관점에서 보면
EPI-USE Labs의 많은 시니어 동료들은 Basis/Platform 배경을 가지고 있습니다. 실제로 여러 S/4 Brownfield 프로젝트에서 기술적 작업을 수행해왔습니다. 이들의 관점에서 S/4는 과거 여러 업그레이드와 마찬가지로 필수적인 기술 프로젝트입니다. 대부분의 고객은 Linux와 HANA DB 위에서 현재 시스템을 운영하고 있지 않기 때문에 OS/DB 교체가 필수입니다. 또한, 대부분의 고객 하드웨어는 HANA를 실행하기에 충분하지 않거나, TDI 인증을 받을 수 있는 구성 조건을 충족하지 못합니다. 따라서, 클라우드 도입(완전 또는 하이브리드) 여부가 핵심 이슈가 됩니다. 이후에는 Private Cloud vs Hyperscaler 선택 문제가 이어집니다. 하지만 이는 단순히 Oracle에서 MS-SQL로 이동하는 수준의 전환이 아닙니다. 데이터베이스 아키텍처 자체가 근본적으로 달라지므로, 사이징은 훨씬 복잡한 논의가 됩니다.
TechEd의 일부 세션에서는 이 중요한 하드웨어 마이그레이션 부분이 다소 축소되거나 빠르게 넘어가는 듯 보였습니다. 기능적 관점에서 과소평가되는 이 부분이, 기술적 관점에서는 오히려 다른 요소를 가릴 정도로 중요하게 보입니다.
진실은? 그 중간 어딘가에 있다
이처럼 S/4에 대한 상이한 인식이 고객의 여정을 지연시키고 있을지도 모릅니다. 모듈중심의 기능 부서가 비즈니스 케이스를 준비하는 동안 IT 팀은 하드웨어 및 교체 논의에 초대받지 못해 혼란스러워할 수 있습니다. “Hyperscaler로 가는 건가? 온프레미스형태로 가는건가?”라는 질문이 뒤늦게 등장합니다.
반대로 IT 부서가 주도하면 모듈별로 사용하는 현업부서가 비즈니스 영향 때문에 이를 막을 수 있습니다. 대규모 프로세스 변경은 다른 비즈니스 이벤트와 충돌하지 않도록 신중히 계획되어야 합니다.
DSAG와 ASUG의 보고서 ‘Mapping Your Journey to SAP S/4HANA® A Practical Guide for Senior IT Leadership’에서는 일반적으로 Greenfield는 비즈니스 주도, Brownfield는 IT 주도로 진행된다고 언급합니다. 그러나 저는 Brownfield라 하더라도 초기부터 비즈니스의 참여와 동의가 필요하다고 생각합니다. Greenfield와 Brownfield를 결정하는 초기 단계부터 기능 부서가 참여해야 합니다.
SAP 라이선스 역시 핵심 요소입니다. S/4는 새로운 라이선스 체계이므로, 기능 변경 사항과 기술적 하드웨어 결정에 따라 필요한 라이선스가 달라집니다.
PRISM을 통해 전체를 명확히 보다
저는 동료들에게 고객 조직 내 모든 이해관계자가 가능한 한 빠르게 같은 페이지에 설 수 있도록 우리가 어떻게 도울 수 있을지 고민해보자고 제안했습니다. 당사의 S/4 Assessment Report는 특정 시스템의 주요 기능적 장애 요소를 조기에 경고하고, 기반기술의 교체 영향과 클라우드 또는 온프레미스 선택에 따른 사이징 옵션까지 함께 제공합니다. 이를 통해 PRISM 플랫폼 상에서 단일 관점(single vantage point)을 제공함으로써, 조직 전체가 서로의 노력 수준을 이해하고 열린 협업을 할 수 있습니다. 이는 SAP Readiness Check를 대체하려는 것이 아니라, 실제 투자 전에 과제의 규모를 파악하고 다른 SAP 고객과 벤치마킹할 수 있도록 돕는 것입니다.
그리고 물론, 기술적 지름길에 대해서도 도움을 드릴 수 있습니다… 그 이야기는 다음에 이어가겠습니다.