2030을 위한 ERP 이야기
2. SAP ERP의 기술적 혁신
차세대 Enterprise Sysem 논의에서 SAP를 빼고 진행할 수 없다. 국내 대기업의 상당수가 SAP를 기반으로 한 ERP를 운영하고 있고 이는 당분가 바뀌지 않을 것 같다. 한 때 Oracle ERP가 치열하게 경쟁하던 시절이 있었지만 국내에서는 이미 SAP가 대세를 이루고 있다고 평가할 수 있을 것이다. 왜 국내 대기업들이 SAP ERP를 선택하게 되었는지에 대하여는 여러 설명이 가능하겠지만 나는 수출 기반 제조업 기반의 국내 산업 환경이 가장 큰 요인이라고 생각한다. SAP가 타 경쟁 제품보다 제조업에 강점이 있었고 글로벌 시장에서 추격자로서 좋은 제품을 빨리 싸게 공급해야 하는 국내 대기업들에게는 물류 프로세스와 통합된 재무/원가 데이터 관리 및 분석 기능은 한국 기업들이 필요로 한 사업의 Speed와 원가 경쟁력 유지라는 경영 목표 달성에 SAP ERP가 더 잘 부합할 수 있게 했다고 할 수 있다.
SAP ERP는 그동안 많은 기술적 변화가 있었다. 초기 국내 시장에 도입된 SAP는 SAP R/3 2.x 버전이었고 이는 4.7 버전을 거쳐 ECC라는 이름으로 6.0까지 바뀌어 오면서 다양한 기능적, 기술적 확장을 이루어왔다. 그러한 기술적 혁신의 과정에서 SAP는 HANA DB라는 메모리 기반의 DB 기술을 확보하게 되었고 이에 기반하여 차세대 ERP로서 S/4HANA라는 ERP 제품을 시장에 내놓게 되었다. 지난 10여간의 이러한 변화과정에서는 다양한 기술적 변화/진화에 동반하여 다양한 중간 형태의 제품들이 시장에 선보이게 되었고 많은 회의적 시각들도 있었다. 아직도 기술적 혁신과 시장 정착은 계속되고 있다고 평가될 수 있겠지만 주요한 기술들은 기업들이 어느 정도 안정적으로 도입할 수 있는 단계에 진입했다고 개인적으로 평가한다.
SAP의 차세대 ERP 제품이자 SAP 제품군의 핵심인 S/4HANA는 다양한 기술적 혁신에 기반하고 있다. 과거 ERP 도입 이전 기업 시스템의 수명이 4~5년 하던 때와는 달리 ERP는 도입하면 10~20년 이상 꾸준히 사용하게 되는 중요한 기업 인프라이기 때문에 차세대 ERP 구축을 추진하면서, 변화되어 앞으로 중심이 될 새로운 기술 기반을 고려하지 않는 것은 또 다른 중복 투자를 가져 올 수 밖에 없게 만들 것이다. 그러나 요즘 국내 기업들의 S/4HANA 신규 재구축 혹은 전환을 보면 이러한 S/4HANA의 미래 기술에 대한 충분한 검토와 반영이 미흡하고 과거 익숙했던 기술/기능을 S/4HANA로 옮겨 놓는 수준으로 이루어지고 있는 경우가 많다. S/4HANA의 핵심 기술 혁신 및 기능 변화들을 적극적으로 검토하여 어떤 수준으로 우리 회사에 반영하고 향후 어떻게 회사 ERP를 진화시켜 나갈 지에 대한 고민이 필요하다. 이에 이러한 계획을 세우기 위하여 검토해야 할 핵심적인 S/4HANA ERP의 기술 혁신에 대하여 정리해 보고자 한다.
1. S/4HANA as Digital Core
2. Simplification, functional 개선 및 모듈 재구성
3. Focusing on Data Driven Transformation with Operational Analytics based on HANA In-emory DB Technology
4. 사용자 Role 기반 UI/UX transformation with Fiori
5. DX 기술 내장을 통한 Intelligent Enterprise
6. 차세대 개발 플랫폼(CDS Modelling, RAP, Fiori UI/UX)
7. Cloud ERP and BTP ABAP(Steampunk), Embedded Steampunk
1. Digital Core로서의 S/4HANA ERP
SAP라는 기업은 R/3 ERP로 부터 성장해온 회사이다. 그동안 IT의 기업 내 역할의 비약적 확대에 따라 ERP 자체의 기능적/기술적 역할 확대와 함께 다양한 각 업무 분야의 전문 솔루션들도 도입 발전하여 왔고 SAP사도 다양한 기능/기술 분야의 솔루션 제품들을 신규 개발 혹은 인수 등을 통하여 추가해 왔다. 이러한 제품군을 SAP사는 LoB(Line of Business) 솔루션이라고 한다.
또한 Cloud 기술의 도입 확산과 함께 고객의 요구에 부응하여 자사의 성장 전략을 실행하기 위하여 다양한 제품/솔루션을 Cloud화하고 Cloud 전용 솔루션을 내 놓는 등 기존의 On-Premise 제품군과 Cloud 솔루션 제품군으로 제품/솔루션의 구성이 복잡 다양해 졌다.
Digital 기술의 고도화와 이러한 Digital 기술을 활용한 기업/산업의 혁명(Transformation)이 붐을 이루면서 다양한 Digital Transformation(DX) 노력들이 추진되고 있고 확산되고 있다. SAP사도 이러한 시대적 흐름을 적극적으로 활용하기 위하여 다양한 DX 관련 기술과 제품을 선보이고 있고 이를 기존 제품/솔루션들과 연계하여 사업화하려고 노력하고 있다.
SAP사에서는 다양한 LoB 솔루션/제품군, Cloud 솔루션/서비스, DX 기술 및 솔루션들이 회사의 주력 상품으로서의 ERP와 체계적으로 연계 통합/확장되어 고객 기업의 가치를 창출하도록 하는 성장 전략을 수립하였고 기업의 근간 데이터(각종 마스터, 계정, 핵심 거래 데이터 등)를 정의, 처리, 집계/보고하는 ERP를 그 핵심 역할을 수행하는 근간 솔루션으로 위치시키고 있다. 이를 Digital Core 라고 정의하고 있는 것이다.
2. Rearchitecting: Simplification 및 기능/모듈 재편
S/4HANA는 기존 ECC 6.x 제품 대비 다양한 기술/기능적 변화를 이루었다. 이는 HANA DB 라는 혁신적 Database 기술과 Fiori라는 Consumer grade UI/UX를 위한 혁신이라는 기술 혁신과 연계되어 있다. DB Table의 단순화, 여러 기능들의 단순화 및 재편, 여러 기술 요소들의 재편, 별도의 솔루션으로 있던 제품의 S/4HANA ERP로의 통합 재구성 등 완전히 새로운 Architecture를 구성했다고 SAP는 주장하고 있다.
2.1 data table simplification
2.2 functional simplification
2.3 Technical element simplification
2.4 Functionality restructuring
2.5 Solution module restructuring into ERP
이상을 요약적으로 이해하는 좋은 방법은 S/4HANA를 Application Architecture 관점에서 구성하여 살펴 보는 것일 것이다. 그러나 아직은 몇가지 관점의 다른 설명이 가능하여 혼란스러운 면이 있지만 각 목적을 가지고 이해해 볼 수는 있다.
Areas in S/4HANA : SAP는 기능/업무 관점의 Area를 아래 그림과 같이 구성하고 기존 모듈/기능을 재편하여 설명하고 있다.
[그림 2-1] Areas in S/4HANA[Source: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE]그러나 기술적으로는 기존의 모듈 개념을 아직도 유지하고 있다.
[그림 2-2] S/4HANA S/W Component in ADT3. Focusing on Data Driven Transformation with Operational Analytics based on HANA In-emory DB Technology
OLTP와 OLAP를 통합하여 단일 플랫폼/시스템에서 데이터 처리와 활용을 수행할 수 있도록 하는 시스템 아키텍쳐에 대하여 SAP는 초창기 R/3 ERP 시절부터 열망이 있었다. R/3의 각 모듈이나 서브 모듈 단위로 Information System이라는 메뉴를 통해 실시간 운영에 필요한 reporting(Operational reporting)을 제공했다. 재무/원가 쪽 모듈에서는 Report Writer/Report Painter라는 기술을, Logistics 모듈에서는 Logistics information System이라는 기술을 사용하였지만 근본적으로는 Transaction Data를 저장하는 Table과 별도로 축약된 data를 저장할 수 있는 Table를 정의하고 활용할 수 있었다.
SAP HANA DB가 SAP ERP 시스템의 주 Database가 되면서 SAP의 이러한 열망을 실현할 수 있는 더 좋은 기술적 기반을 확보하게 되었고 SAP는 이를 새로운 ERP 제품인 S/4HANA의 중요한 마케팅 메시지 중의 하나로 주장하였다. 과거 R/3 시절부터 써 오던 ERP 내의 Reporting을 위한 별도의 Table이 아니라 Transaction을 저장하는 Table을 Operational Reporting에도 바로 활용할 수 있게 한 것이 핵심적인 변화였고 이는 SAP HANA DB의 강력한 In-Memory DB기술의 성능에 기인한 것이었다.
이러한 기술적 진보는 기업 및 사회 전반에서 확산된 데이터 혹은 데이터 분석을 통한 기업 가치 창출/확대라는 디지털 기반 기술 혁신의 중요한 흐름 중의 하나를 ERP에서도 실현할 수 있는 중요한 도구가 되었다. 기업의 ERP 사용자가 거래나 전표를 처리하는 단순한 처리자에서 각 거래의 상황에 적합한 판단과 의사결정을 통하여 거래의 적합성/적시성/효율성을 달성할 수 있도록 하는 운영의사결정자로서의 역할의 변화를 가져다 준 것이다. 이러한 역할의 변화는 기업의 업무 효율화/효과성 추구라는 요구와 자동화 지능화 등을 통하여 데이터의 원천 포착과 처리에 있어 기계(POS 단말기, Scanner, 각종 센서 등)의 역할이 증가하고, Value chain 전후방의 연결을 통하여 기업의 공급자나 고객 시스템과의 연계에 기반하여 partner 시스템들을 통하여 이루어 질 수 있게 되었기 때문이기도 하다.
데이터 분석 활용 기반 의사결정을 활성/지원하는 Business Intelligence 기술들의 성숙도 이러한 ERP 운영 데이터의 실시간 활용이라는 방향에 기여한 중요한 축이 하나이다. 데이터 시각화, 최종 데이터 활용자의 직접 데이터 처리/분석(End User Computing의 강화) 등을 지원하는 다양한 기술들이 원천 Data의 취합, 저장, 처리 기술들과 함께 ERP 사용자가 현장에서 그 상황에 필요한 운영 의사결정을 할 수 있도록 하는 data driven operational decision making이 가능한 ERP의 가능성을 넓혀준 것이다.
4. 사용자 Role 기반 UI/UX transformation with Fiori
SAP GUI 화면은 R/3 초창기 시절 많은 기업 시스템의 대세였던 텍스트 기반의 UI화면에 비하면 혁신적인 것이었다. 그러나 많은 거래 관련 Data를 여러 기업들이 사용할 수 있게 범용적으로 만들다 보니 많은 탭 화면과 많은 데이터 필드 그룹 및 데이터 필드들로 구성될 수 밖에 없었고 이는 아주 복잡한 UI라는 오명을 얻기 이유가 되었다. 필드 카타로그 등 시스템 Configuration을 통하여 일부 복잡성을 단순화시킬 수 있는 방법을 제공하기도 했고, Enjoy SAP, Easy SAP 등 다양한 노력들이 있었으나 다른 시장의 UI 기술 진보에 근거한 혁신적인 소비자 지향적인 UI/UX 경험을 제공하는 데에는 한계가 명확했다.
이러한 Web 환경 대세의 시장 요구사항에 대한 SAP의 다양한 시도는 많은 SAP UI 기술 기반의 제품/솔루션들을 나았고 이는 더욱더 사용자들이 SAP가 어렵게 느껴지게 만들었다. 2000년 초반의 Business HTML, BSP 등에서부터 ITS 기반의 WebGUI, Web Dynpro ABAP, Web Dynpro ABAP 기반의 Floor Plan Manager, Web Client 등 전통적인 SAP GUI(for Windows, for HTML) 이외에도 다양한 기술에 기반한 기능들을 사용자들이 경험하게 만들었다.
SAP가 S/4HANA로 R/3의 다음 버전의 전혀 다른 제품을 구상하면서 가장 크게 신경 쓴 것 중의 하나가 UI/UX 전략이었을 것이라는 것은 충분히 예상할 수 있었다. 시장에서의 SAP 제품 UI/UX에 대한 평가, 시장의 Consumer Grade UI/UX 흐름과의 괴리, 사용자 경험을 통한 성과 창출에 집중하는 Digital Transformation의 시대적 흐름 등에 부응하기 위하여 어떻게든 사용자 경험을 강화하는 제품 전략을 만들 수 밖에 없다고 생각한다.
2000년대 초반 인터넷 .com 버블 시대에 나는 SAP가 ABAP에 기초한 기존의 Client/Server 방식의 개발 플랫폼에서 새로운 시스템 개발 플랫폼 및 UI로의 도전을 시도할 것이라고 예측했던 적이 있다. 그러나 SAP는 기존 ABAP 기반의 기술혁신/제품혁신이라는 전략을 아직까지도 계속 유지하고 있고 오히려 Database에서의 혁신을 더 강력하게 추구해 왔다. 이는 시장/고객에 널리 확산되어 확보하고 있는 고객 기반을 쉽게 다른 것으로 바꾸기 어려운 현실적인 한계도 중요하게 작용했을 것이라고 개인적으로 평가한다.
다양한 사용자 Device 환경에서 적용 가능한 소비자 등급의 사용자 경험을 시장의 대세인 Web UI 기술로 제공하기 위한 SAP의 선택이 Fiori였다고 생각한다. 이를 통해 SAP는 Backend의 업무 로직은 ABAP의 축적된 지적 자산과 경험을 기반으로 하고 Front End의 사용자 경험은 Web 3.0 기술 기반의 HTML5 기반 SAP의 자체 기술 UI5와 이에 근간한 Fiori UI/UX로 제공하는 전략을 수립한 것이라 이해한다.
SAP의 Fiori UI/UX의 전략 및 기술에 대하여는 이후 설명할 기회가 있을 것이다. 그러나 SAP가 향상 그렇듯이 기존 기술을 활용한 고객를 고려하면서 점진적인 혁신을 만들어 가는 과정 속에 통일된 UI/UX가 모든 제품에 적용되어 가는 중이라고 이해해야 할 것이다. 그러나 나는 SAP가 Fiori를 자사의 미래 표준 UI/UX 기반으로 설정하고 점진적인 전환을 이루어 가고 있다고 이해하고 있으며 그 전환의 기간 동안에서는 기존의 기술이 병해하여 사용될 수 밖에 없을 것이다. 그렇지만 나는 Fiori와 SAP GUI(for Window, for HTML)가 당분간의 주요 UI/UX 기술로 사용될 것으로 생각한다.
현재 S/4HANA 제품을 보면 주요한 기능에는 Fiori App을 제공하고 있고 보조적으로 기존의 GUI App들을 제공하고 있다. 물론 기존 거의 모든 T-Code들을 Web GUI로 사용할 수도 있기는 하다. 그러나 SAP가 S/4HANA에서 기능을 개선하거나 추가하는 경우에는 Fiori UI/UX로만 기능을 제공하고 있어 Fiori로의 전환은 대세가 될 수 밖에 없을 것이다.
따라서 S/4HANA의 UI/UX 표준을 Web UI/UX(Fiori + SAP GUI for HTML)로 이해하고 프로세스를 설계하고 시스템을 구현하여 사용자에게 제공하는 것이 미래를 위한 합리적인 선택이라고 확신한다.
5. DX 기술 내장을 통한 Intelligent Enterprise
AI/ML, Chatbot(Conversational AI), RPA, Workflow, IoT, Digital Twin, LCNC, Mobile,
Intelligent workflow
6. 차세대 개발 플랫폼(CDS Modelling, RAP, Fiori UI/UX)
이러한 기술적 혁신의 근간에는 이를 가능하게 하는 SAP HANA Database에 기반한 ABAP Platform의 혁신이 있었다. 이 혁신중에 중요한 요소가 새로운 방식의 데이터 모델링 도구인 ABAP CDS이고 다른 하나는 개발 언어인 ABAP program의 기술적 혁신이다. HANA DB의 CDS의 활용성을 높이고 Web program 개발에 최적화된 개발 모델인 RAP(ABAP Restful Programming Model)이 ABAP Program 언어 혁신의 핵심이다. Fiori UI/UX을 실현하는 Front End 개발 기술도 차세대 ERP를 구현하기 위한 핵심 기술 기반의 하나로 추가할 수 있다.
6.1 ABAP CDS
6.2 RAP(ABAP Resuful Programming Model)
6.3 FIori UI/UX with UI5
7. Cloud ERP, BTP ABAP 개발환경(Steampunk), Embedded Steampunk
Cloud를 빼고 SAP S/4HANA의 기술 혁신을 이야기 할 수는 없을 것이다. Enterprise 시스템의 핵심 시스템으로 데이터 분량이나 사용의 일관성 등에서 큰 변화가 없는 ERP 시스템이 Cloud로 전환되어야 하는지에 대하여는 국내에서는 소규모 비제조 기업들을 빼고는 부정적인 기류가 강한 것 같다. 이는 Global SAP 고객들도 크게 다르지 않아 보인다. 그러나 SAP S/4HANA의 Cloud 전략과 솔루션, 기술을 이해하고 차세대 ERP Architecture를 결정해야 할 것이다.
7.1 S/4HANA Cloud 솔루션/제품
SAP의 Cloud 전략에 있서 SAP사의 핵심 제품군인 S/4HANA ERP는 핵심이 될 수 밖에 없다. 이에 따라 기존 R/3(혹은 ECC) 제품을 SAP HANA DB 기반 및 제반 미래 지향 혁신 기술을 통하여 S/4HANA라는 차세대 ERP를 만들면서, 기존의 On-Premise 방식과 함께 Cloud ERP로서 Solution License 판매 방식이 아닌 구독 서비스 방식의 서비스 솔루션을 만들고 이를 회사의 미래 ERP 솔루션/서비스 전략으로 강력하게 추진하고 있다. 회사의 대 시장 메시지를 보면 기존 On-Premise 제품보다 Cloud ERP 서비스를 더 우선하고 강조하고 있음을 누구나 알 수 있다. 그러나 전 세계 많은 고객들이 아직은 이러한 전략에 대하여 적극적으로 공감하고 수용하고 있다고 보기는 어려운 것 같고 이는 시장의 평가도 마찬가지이다. 한국 시장과 기업은 더 보수적으로 반응하고 있다. SAP의 Cloud ERP 전략에 대하여는 별도의 평가를 해 볼 기회가 있을 것이다.
다양한 변형이 가능하여 실제로는 더 많이 분류할 수 있겠지만 S/4HANA 제품은 아래와 같이 크게 3가지로 분류할 수 있을 것이다.
1) S/4HANA On-Premise
2) S/4HANA Cloud Essential(Private) Edition
3) S/4HANA Cloud Extended(Public) Edition
Cloud ERP 제품은 좀 더 상세한 다양한 변이가 있으나 단순화하면 완전한 SaaS Application 서비스인 S/4HANA Public Cloud와 Application 자체는 On-Premise와 거의 동일하지만 Insfrastructue를 Cloud를 활용하여 서비스하는 S/4HANA Private Cloud(PCE)로 나눌 수 있다. 이 오퍼링들은 계속 진화하고 있거 최신의 몇가지 update가 빠져 있기는 하지만 다음 SAP Blog 를 참조하길 바란다. https://blogs.sap.com/2020/07/09/difference-between-sap-s-4hana-any-premise-sap-s-4hana-cloud-essentials-and-sap-s-4hana-cloud-extended/
현재 국내 시장에서 SAP는 License 정책 관점에서 On-Premise 오퍼링보다 PCE(Private Cloud Edition)를 강력하고 밀고 있으나 두 제품 중 어떤 것이 각 회사에 부합하는 것인지에 대한 평가는 각사별로 신중하게 평가되어야 할 것으로 보인다.
7.2 BTP ABAP Environment
SAP Cloud 전략을 이야기 할 때 빼놓을 수 없는 또 한가지 요소는 SAP BTP(Business Technology Platform)이다. BTP는 Intelligent 기업을 위한 SAP사의 솔루션 오퍼링의 집합체로서 4가지 핵심 기술(DATABASE & DATA MANAGEMENT, ANALYTICS, APPLICATION DEVELOPMENT & INTEGRATION, INTELLIGENT TECHNOLOGIES)에 기반하여 3가지 Business 목표를 지향하는 3개 제품군으로 구성되어 있다. Interated entperise을 지향하는 Integration suite, Data to value를 지향하는 Analytics Suite, 유연한 솔루션 확장을 지향하는 Extension Suite이 그것이다.
[그림 2-3]SAP BTP Product & Solution다음 Blog도 개요을 이해하는데 도움이 될 것이다. https://blogs.sap.com/2021/12/01/sap-business-technology-platform/
BTP는 S/4HANA ERP와 다양한 관점에서 논의가 필요하지만 BTP ABAP Environment를 빼놓을 수 없을 것 같다. 이는 BTP에서도 ABAP 개발이 가능하도록 만든 것이다. 원래 SAP의 내부 project 이름인 Steampunk를 통용하기도 한다. BTP에서는 Cloud Application Programming Model(CAP)을 통한 JAVA 개발 등 다양한 개발 환경을 제공하지만 ABAP 개발 환경을 추가로 제공하는 것은 특별한 의미가 있다고 본다.
SAP가 Cloud 전략을 강력하게 추진하고 있고 S/4HANA ERP도 그 전략의 핵심에 있다고 이야기 했다. Cloud ERP 추진에 있어서 중요한 고려 요소 중 하나가 솔루션 확장성이었을 것이라고 생각한다. 다른 cloud 서비스들과 달리 ERP를 Cloud로 제공하기 위하여는 각 산업 및 기업마다 차별적으로 요구되는 추가 기능들을 개발 할 수 있는 확장성이 아주 중요하다. ERP는 범용적인 기업 프로세스/데이터 관리 기능을 제공하는 것을 넘어 기업 경쟁력을 갖도록 하는 차별적인 프로세스/데이터 관리 기능이 핵심적으로 요구되기 때문이다.
S/4HANA Public Cloud 서비스가 In-App Extensibility 라는 솔루션 확장 기능을 제공하기는 하지만 기존 On-Premise ABAP 환경에서 제공하는 확장성과는 비교할 수가 없었다. 따라서 이 부족함을 메워 줄 수 있는 전략이 필요했고 이에 BTP ABAP Environment(Steampunk)가 탄생했다고 이해한다. 이를 통하여 S/4HANA Public Cloud core 솔루션 영역 밖 별도의 BTP환경에서 ABAP 개발을 통하여 솔루션을 확장하고 이를 S/4HANA와 연계하여 활용하도록 한다는 전략이 완성된 것이고 이를 SAP는 Side by Side Exntesibility라고 한다. 이렇게 되면 S/4HANA Core 시스템은 표준 기능 그대로 유지되어 향후 지속적인 Upgrade가 수월하게 될 것이라는 생각이다. 이를 SAP는 Clean Core ERP 전략으로 설정하고 있다.
그러나 이 Side by Side Extensibility 전략이 기존 On-Premise ERP를 사용하고 있던 고객이 S/4HANA Public Cloud로 옮겨 가고 In-App Extensibility가 제공하지 못하는 복잡한 개발을 Side by Side Extensibility를 통하여 BTP에서 개발하여 기존 기업의 차별적 프로세스/데이터 확장을 완성할 수 있었는지는 의문이다. 많은 고객들이 여기에서 여러 고민이 있었을 것이라고 생각한다.
BTP ABAP Environment(Steampunk)는 제품의 Architecture상 S/4HANA와 Tight하게 연계된 Application를 만들기에는 부적합하다. 따라서 SAP사도 loosely coupled Application에 사용할 것을 권고하고 있다. In-App Extensibility로 개발하기에는 복잡하고 S/4HANA Core와 많은 프로세스, 데이터 연계를 가지고 있는 추가 개발 요구는 Side by Side로는 권고하지 않는다면 어디에서 개발하는 것이 최적이라 말인가?
7.3 Embedded Steampunk in S/4HANA Public Cloud
이러한 갭을 메우기 위한 SAP사의 다음 수순은 이러한 Cloud ABAP Environment를 S/4HANA Public Cloud 제품안에서도 제공하는 것이었고 이는 Embedded Steampunk로 불리워진다. 이를 통해 SaaS ERP를 사용하는 고객도 기존 전통적인 자유로운 확장 개발을 수행하여 기업의 차별적 요구를 충족할 수 있게 되었다.
그러나 S/4HANA ERP 제품을 3개월 주기로 기능 개선을 수행하고 이를 통하여 지속적 혁신이 가능한 Enterprise solution 제품군을 서비스한다는 SAP사의 Cloud 전략에 부합하는 ABAP 개발을 하는 것은 당연히 몇 가지 제약이 생길 수 밖에 없었다.
그 중 핵심적인 것이 기존 SAP S/4HANA의 Technical Object(Data element, function module 등)를 추가 ABAP 개발에 재활용하는 것을 오직 Released Object로 한정한 것이다. 전통적인 ABAP 개발에서는 고객의 자체 개발 Obejct 뿐 아니라 SAP의 표준 개발 Object도 재사용하여 개발의 생산성을 높이는 방법을 즐겨 썼다.
그러나 SAP가 보기에는 이는 제품 Upgrade시에 여러가지 문제를 발생시켰다. SAP가 내부적인 혁신을 위하여 이러한 Object들을 변경시켰을 경우 이를 재활용한 고객 프로그램에 문제를 만들 수 있었고 이러한 문제들이 upgrade시에 많은 시간과 노력을 들게 만들었다. 따라서 Cloud에서의 Upgrade에 안정적인 고객의 ABAP 개발이 되게 하기 위하여는 안정적으로 사용할 수 있도록 Released 된 것들만 사용할 수 있도록 제한을 둔 것이다.
7.4 Embedded Steampunk in S/4HANA On-Premise and S/4HANA Private Cloud
2022년 10월 SAP는 Embedded Steampunk 환경을 S/4HANA On-Premise와 S/4HANA Private Cloud에서는 제공하도록 제품을 출시했다. 이미 ABAP 개발 환경을 가지고 있던 이 제품군들에 이러한 새로운 기능을 추가한 것은 어떤 의미를 가지고 있을까?
S/4HANA On-Premise 및 S/4HANA Private Cloud에서는 기본적으로 고객이 Upgrade 책임을 가지고 있다. 따라서 Upgrade에 제약을 가하는 기존 ABAP의 관행들도 고객의 책임이기 때문에 기술적으로는 굳이 이러한 새로운 기능이 필요 없었을 수도 있다.
그러나 S/4HANA Private Cloud에서도 SAP의 Upgrade 책임이 증가하는 option들이 생기고 S/4HANA On-Premise에서도 지속적인 Upgrade를 통하여 SAP의 새로운 혁신 기능들을 쉽게 고객들이 적용할 수 있도록 하기 위하여 Upgrade 제약을 줄이고 싶은 SAP사의 욕구가 이러한 제품 전략 방향 수립에 기여했다고 평가할 수 있을 것이다.
SAP는 Upgrade Stable 혹은 Safe라는 목표외에 Cloud Ready라는 목표도 제시하고 있다. 즉 향후 모든 혹은 많은 고객들이 Cloud ERP로 전환하도록 바라는 SAP의 사전 준비와도 같다고 이해할 수 있을 것이다. 고객들이 Cloud ERP에서도 쉽게 구현될 수 있는 방식의 ABAP 개발이 되어 있으면 쉽게 Cloud 전환이 이루어지겠지만 전통적인 ABAP 개발로 되어 있는 프로그램들을 Cloud로 전환하는 것인 또 하나의 장애 요소가 될 것이기 때문에 이 Cloud 개발 플랫폼이 S/4HANA안으로 Embedded된 것이라고 이해한다.
이러한 Embedded Steampunk 환경에서의 개발을 On-Stack Developer Exnensibility라고 한다. 이는 기존 ABAP 개발자들의 전통적인 ABAP 개발에, 개발 분리와 같은 Clean Core 개념과 기술이 적용된 개발 환경이라고 이해하면 된다.
7.5 SAP사의 Clean Core ERP 개념
SAP의 Clean Core라는 개념/용어는 단순화하면 기업의 차별적 경쟁 우위 달성 수단으로서의 ABAP 추가 개발을 S/4HANA ERP Core 시스템과 분리한다는 것이다. 개발 분리는 BTP와 같이 물리적으로 분리하는 방법에서 Embedded Steampunk에서와 같이 논리적으로 분리하는 방법까지 제품 플랫폼 유형에 따라 다를 것이다.
개발을 분리하기 위하여는 SAP 제품/솔루션 및 기능을 최대한 활용하는 것이 필요하다고 SAP는 생각한다. 이를 Fit to Standard라고 한다. Fit to Standard Approach를 통하여 기업이 필요로 하는 요구사항을 충족하는 SAP사의 솔루션 제품(LoB Product) 및 S/4HANA 표준 기능에서 먼저 찾아 잘 활용하고 이로도 충족할 없는 기능 요구사항은 개발 분리를 통하여 Core ERP를 원래 출시된 형태로 Simple하게 유지하여 Upgrade 안정성을 높이고 Cloud 지향성을 높인다는 것이다.
Clean Core를 달성해 가기 위해 Fit to Standard 노력 이외에도 S/4HANA 기능을 확장하여 활용할 수 있도록 하는 In-App Key User Extensibility의 적극적 활용, S/4HANA와의 데이터, 프로세스 연계가 덜한(loosely coupled) 기능 요구 사항의 개발 분리 방법인 Side by Side Extensibility 활용, S/4HANA Core와의 연계가 강화지만 In-App Extensibility로 대응하기에는 복잡한 개발 요구사항은 Clean Core 원칙을 지키는 On-Stack Developer Extensibility 적용 등이 권고된다. 이러한 개발 option의 적용 이외에도 아래와 같은 Clean Core 구현 guide line이 제시될 수 있다. (참조: https://blogs.sap.com/2022/09/14/realizing-a-clean-sap-core-a-pragmatic-approach-towards-digital-transformation/)
1) Zero Core Modifications : 표준 수정을 하지 말라. 많은 한국 기업들이 그 동안 이 원칙은 준수해 왔다고 평가하여 새로운 원칙이라고 볼 수는 없다. 예외적인 경우를 제외하고는 표준 수정의 위험성을 알고 있었기 때문에 다들 피하도록 권고되고 지켜져 왔다.
2) Fit-to-standard business processes as much as possible
되도록 이면 표준 프로세스를 활용하자는 것이다. 국내에서는 이를 위하여 PI(Process Innovation)라는 활동이 업계 표준이 되었다. 물론 PI가 프로세스 혁신을 통한 성과 창출을 지향하는 활동이기는 했으나 Global 표준 기반 패키지 기능의 활용을 통한 혁신이라는 ERP 도입의 한 흐름에서 생기 것이기 때문에 PI는 되도록 표준 기능에 맞추도록 프로세스를 변경/조정하는 것도 포함되어 왔다. 물론 이는 기준정보 정의도 포함된다.
3) Handling Indirect Modifications to SAP Standard
SAP 표준 기능을 검토하다 중요한 기능은 충족이 되지만 이 기능이 부족하거나 새로운 기능이 요구되는 경우에는 표준 Modification을 피하는 방법으로 이 표준 프로그램을 복사하여 Custom Object를 만든 다음 이 프로그램을 원하는 내용으로 수정하여 활용하는 방법을 사용하기도 했다. 이를 Clone 프로그램이라고 한다.
이 clone 프로그램은 SAP의 기능 향상을 반영할 수 없기 때문에 SAP가 권고하지 않는 방식이다.
국내에서는 초창기에 이 방법을 일부 사용하기도 했으나 개발 기술이 향상 되면서 이렇게 복잡하게 변경하느니 새로운 프로그램을 만들어서 요구사항에 대응하는 방식으로 바뀌어서 이러한 유형은 별로 없을 것으로 생각한다. 단 여러 표준 프로그램을 엮어서 순차적인 기능을 자동으로 처리하도록 하는 기능을 BDC라는 방식으로 구현한 프로그램들은 아직도 광범위하게 사용되고 있는데 SAP는 이도 Clone 프로그램으로 보고 지양을 권고하고 있다. 이는 SAP가 기능이나 화면 UI를 변경했을 경우 upgrad시 에러를 유발할 수 있는 대표적인 경우이기 때문이다.
4) Analyze Usage data and Retire unused objects
사용되지 않는 프로그램을 폐기하자고 하는 것이다. 사용하지 않는 것을 새로운 시스템으로 옮기는 것도 비용 드는 불필요한 작업이기도 하지만 이들 프로그램들을 이해하는 사람들이 없는 경우가 많아 회사의 핵심 업무 자산인 이러한 프로그램이들이 Back box화 되어 다른 기능들까지도 손 볼 수 없도록 영향을 미치지 경우가 많기 때문에 반드시 고려되어야 한다.
5) Lean and Upgrade-proof Data-models
S/4HANA의 기술 혁신 중 가장 기반이 되는 것 중 하나가 HANA DB의 기능을 최대한 활용하기 위한 새로운 데이터 모델링 기술인 CDS이다. 이를 적극 활용하도록 하자는 것이다. 기존 프로그램이 ABAP 테이블을 직접 읽어서 처리하는 방식이었고 S/4HANA에서 테이블들에 많은 변화가 있었지만 S/4HANA는 Compatability view라는 구조를 통하여 기존 테이블 이름이로 만든 프로그램들도 여전히 오류 없이 기능하도록 지원하고 있다. 그러나 이 방식은 HANA DB의 강점을 활용할 수 없고 성능상의 이슈를 만들 수 있기 때문에 CDS를 활용하는 방식으로 프로그램이 변경되어야 한다.
6) Compare and Consolidate Custom objects based on Functional Commonality
기존 프로그램들은 시간 순서에 따라 다양하게 요구 사항에 대응해 왔기 때문에 비숫한 기능을 가진 것들이 다수 있을 수 있었다. 이는 Data model의 활용, function 모듈의 활용 등에서 확인할 수 있다. 이들을 찾아서 합치는 것도 필요한 노력 중의 하나이다.
7) Realize full potential of Key-User (In-App) Extensibility modes
SAP는 기존에 다양한 확장 방법을 가지고 있었다. 이런 확장 방법들은 S/4HANA 신기술 버전이 In-App Key User Extensibility라고 할 수 있다. 새로운 ABAP과 Fiori Front End 기술은 기존의 확장 보다 훨씬 광범위한 표준 확장 기능을 제공한다. 이들을 활용한다면 표준 기능의 일부 부족한 기능을 보완하여 표준의 활용도를 높일 수 있을 것이다.
8) Re-platforming decoupled custom developments (side-by-side) outside core to SAP BTP
독립성이 강한 기능 요구사항은 BTP에서 Side by Side Extensibility을 통하여 개발하자는 것이다.
9) Usage of released or whitelisted APIs
Released Obejct와 whitelisted APIs를 사용하자는 것이다. On-Stack Development와 Side by Side 개발에서는 핵심적인 요구사항 중의 하나이다. 이슈는 이렇게 released 된 것들이 요구에 미치지 못할 경우이다. SAP는 이를 위한 임시적인 기술 대안도 갖추고 있어 적극적으로 검토 활용할 수 있을 것이다.
10) Using Developer (on-stack) Extensibility
추가적인 ABAP 개발의 핵심 수단으로 Classic ABAP 개발은 지양하거나 최소화하고 Upgrade atable Cloud Ready 개발 도구인 ABAP Cloud를 사용하자는 것이다.
11) Re-think, Diversify, Be Aware and Ready
ABAP 개발에는 다양한 필요 Obejct에 대한 요구 대응이 필요하고 이는 각 요소별로 최적의 대안이 검토되어야 한다. WRICEF 각 개발 Object 유형별로 다음과 같은 대안으로의 변경을 검토해야 한다.
(1) Workflows : S/4HANA Flexible Worklow, BTP Workflow management
(2) Reports: Fiori App inlcuding Analytical Table, Embedded Analytics based Analytical Fiori App
(3) Interfaces : OData API, SOAP API, SAP AIF(S/4HANA), Custom RESTful API, SAP Event Mesh
(4) Conversions : S/4HANA Migration cockpit(LTMC)
(5) Enhancements : In-App Extensibility
(6) Forms : S/4HANA Output Management, SAP Form Service by Adobe(BTP)
7.6 한국 기업을 위한 Clean Core ERP 개념의 재정립
SAP의 Fit to Standard 기반 Clean Core 개념과 기술은 각 회사가 차세대 ERP 구축시에 적용할 ERP의 비전 달성 및 적용 기술 아키텍쳐 표준을 결정할 수 있는 기술적 기반을 제공한다. Clean Core ERP를 통하여 Upgrade 유연성을 확보하고 미래 Cloud로의 전환을 준비하여 솔루션 벤더의 기술 혁신을 수용하여 기업 환경 변화에 대응하고 구축과 유지보수의 효율성을 달성하며, 미래의 대세 기술 환경이 될 Cloud 환경으로서 전환시에 용이한 기반을 제공할 수 있을 것이다.
그러나 이러한 기술 기반 혁신을 지속하기 위하여는 여러가지 사전 준비가 필요하며 지금 당장의 차세대 전환의 과정에서는 모든 것을 한꺼번에 할 수는 없을 것이다.
1) Cloud ERP as SaaS Application
제조 중심 대기업 중심의 차세대 ERP 구축에 있어 SaaS 기반의 Cloud ERP(S/4HANA Public Cloud)가 한국 기업의 지향점이 되어야 하는지에 대하여는 논쟁의 여지가 많다. 국내 제조 대기업 중 이 지향을 선택한 회사가 아직까지는 거의 없다. 비단 한국 회사들뿐만 아니라 Global SAP 고객들도 대세는 다르지 않은 것 같다. 최근 SAP는 S/4HANA PCE 를 전략적으로 밀고 있으나 이 제품은 성격상 SaaS로 보기 어렵기 때문에 SasS Cloud ERP라고 보기 어렵고 따라서 SAP도 아직까지는 본격적인 SaaS Cloud ERP를 기업의 미래 Enterprise System To-Be 모습이라고 강조하고 있다고 보이지는 않는다.
이런 상황에서 Cloud Ready라는 Clean Core 지향점은 다소 힘을 잃게 된다. 물론 PCE의 경우에도 Upgrade 책임을 SAP가 일부 가져가서 고객이 SAP의 기술 혁신을 활용할 수 있도록 하는 option이 있기는 하고 따라서 이러한 관점에서 Cloud Ready가 Clean Core의 지향점 중의 하나가 될 수는 있으나 핵심 요인이 되기는 어려워 보인다.
2) Upgrade에 따른 지속적인 혁신 도입
SAP는 지속적으로 새로운 기술을 도입하고 경험을 반영하여 프로세스를 혁신하는 기능들을 제품에 반영하고 있다. S/4HANA Public Cloud에서는 3개월에 한 번씩, S/4HANA On-Premise에서는 1년에 한 번씩 이 기능 추가가 배포되고 Cloud에서는 당연적으로, On-Premise는 고객의 의지로 시스템에 포함된다.
그러나 이러한 새로운 기능이 적용되는 것은 또 다른 문제이다.
첫째, 차세대 구축 과정에서 아직 구현되지 않았지만 향후 버전에서 출시될 것이기 때문에 기다려서 출시된 이후에 구축하자고 하는 Wait 전략을 권고하기도 하지만 현실적으로 이렇게 작동되는 것을 본적이 없다. 고객은 바로 필요한 기능이 ERP에 구현되어 업무에 적용되어야 하고 따라서 ERP에 기능이 없으면 Custom 개발을 통하여 구현하게 된다. 물론 나중에 이런 Custom 개발 프로그램을 신규 출시된 기능으로 대체하는 작업을 할 수도 있겟으나 굳이 그래야 할 가치가 크지는 않아 보인다.
둘째, 구축 이후 운영 단계에서 새로운 사용자 요구가 도출 되었고 구축 이후 출시된 기능 혹은 곧 출시될 기능 중에 이러하 요구를 지원하는 것들이 있을 수 있어 이를 적용하여 요구에 대응할 수도 있을 것이다. 그러나 지금까지의 유지보수 관행으로는 이러한 대응은 불가능해 보인다. 유지보수 인력들이 SAP의 기능들을 잘 파악하고 있어서 SAP 표준 기능과 새로이 출시된 기능 중심으로 요구사항에 대응하려면 구축 프로젝트에 참여한 컨설턴트 수준으로 전체 프로세스 및 SAP 기능에 전문적이어야 하나 국내 유지보수 생태계 생리상 이러한 인력 운용은 이루어지지 않는 것으로 평가한다.
셋째, 물론 그때마다 외부 전문가를 활용하여 적극적으로 SAP 출시 신 기능 중심으로 요구사항에 대응하는 체계를 만들 수도 있겠으나 ERP 투자의 특성상 이러한 예산을 확보하기 어렵고 내부 유지보수 인력이 외부 전문가 수준의 기술 역량을 가지고 있지 못하다는 것을 예산 승인자에게 설득하는 것이 어려워 보인다.
결론적으로 상시적인(필요 시점마다의) Upgrade를 통한 지속적인 혁신 기술/기능 도입은 지금의 SAP 구축, 유지보수 생태계로서는 쉽지 않을 것 같고 이러한 노력의 가치를 입증하고 새로운 체계를 만들어야 가능할 것이다.
3) Web UI/UX로의 전환 요구와 실행 역량
SAP는 S/4HANA를 출시하면서 기본적인 UI/UX 전략을 Web/Fiori 기반으로 수립하였다. SAP의 오랜 전통상 기존 고객의 투자를 보호하기 위하여 전통적인 Windows GUI도 계속 쓸 수 있도록 지원하고 있고 이를 Web에서 쓸 수 있도록 WebGUI(SAP GUI for HTML) 기술도 고도화하였으나 기본적으로는 Web UI/UX를 미래 방향으로 선언하고 있다.
특히 Cloud ERP에서는 전통적인 Windows GUI는 지원하지 않고 Fiori와 WebGUI 를 조합한 Web UI/UX만 가능하도록 제품이 구성되어 있다. Clean Core ERP는 Cloud 및 On-Premise에서 같이 적용되는 개념과 기술이고 따라서 당연히 Web UI/UX 기술에 기반하고 있다. 전통적인 Windows GUI 개발은 Clean Core 기술로는 지원되지 않는다.
그러나 전통적인 Windows GUI에 익숙한 일부 사용자 그룹과 이 UI/UX에서 자신들의 경력을 쌓아온 많은 컨설턴트들은 새로운 UI/UX로의 전환을 꺼려하고 있는 것이 현실이다. 따라서 Clean Core ERP 를 논하기 전에 차세대 ERP의 UI/UX가 어떤 방향으로 나아가야 하는지에 대한 전략이 수립되어야 하고 이는 UI/UX를 통하여 사용자들의 Enterprise 경험을 통한 효율성/효과성 달성 같은 가치가 우선 고려되어야 한다.
4) 차세대 S/4HANA 기술(CDS, RAP, Fiori) 역량 확보
SAP HANA DB와 Fiori UI/UX 전략과 같은 기술 혁신 기반 및 가치 지향을 달성하기 위하여 S/4HANA는 크게 세가지 기술 혁신에 기반하고 있고 Clean Core ERP 논의는 이러한 S/4HANA 기반 기술의 진정한 활용이라는 작업이 선행되어야 할 것이다. 이 각각의 기술에 대하여는 향후 상세하게 설명하기로 하고 여기서는 이러한 기술 방향을 수용하고 적용하기로 결정한 상황에서 과연 이런 기술을 구현할 경험있는 전문가들을 시장에서 확보할 수 있느냐라는 현실적인 고민을 해 보고 싶다.
CDS의 탄생과 진화는 SAP HANA DB와 같이 이루워졌으니 벌써 10여년의 역사를 가지고 있고 S/4HANA의 도입과 함께 ABAP에서도 CDS가 본격적으로 활용될 있도록 진화하였다. 국내에서도 일부 선행 프로젝트들에서 경험들이 싸여 가고 있다.
Fiori기술도 여러 회사들에 적용되어 어느 정도의 기술 인력 pool을 확보하고 있다. 하지만 UI5 기반 Free Style 개발 인력 중심으로 경험이 쌓여 있고 Fiori Element와 Fiori Tool등을 통한 UI/UX 일관성, 개발 생산성 등을 확보할 수 있도록 훈련된 개발자들은 아직은 많지 않은 것 같다.
Fiori Front End 개발을 위한 Backend 개발 도구로서의 ABAP에도 그동안 기술적 진보가 이루워졌고 RAP(ABAP Restful Prgramming Model)로 완성되어 가고 있다. 이 새로운 ABAP의 기능은 CDS의 개발을 최대한 활용하면서 Fiori UI/UX에 특화, Cloud 최적화된 App을 개발할 수 있는 개발 모델을 제공한다.
이러한 핵심 요소기술 역량 확보는 Clean Core ERP 전략을 실행해 나가는 핵심 선행 조건이 될 것이다.
5) ECC ERP의 S/4HANA 전환 방식에서의 대규모 기존 ABAP 프로그램 재개발 이슈
국내 기업들이 기존 ECC ERP를 S/4HANA로 전환해 가는 방식에는 크게 신규 재구축 방식(Green Field) 및 Technical Conversion방식(Brown Field)으로 나눌 수 있다. 신규 재구축은 새로운 기술 기반하에 기존의 프로세스를 재점검하여 새로운 기업 환경에 필요한 새로운 프로세스들을 재구축하기 위한 전략으로 선호된다. 그러나 이러한 프로세스 설계의 요구가 강하지 않고 예산의 제약을 받는 회사들은 Converion방식으로 진행하면서 필요한 프로세스 변화를 반영하는 형태로 재구축이 이루어진다.
신규 재구축을 하던 Conversion 방식을 선택하던 기존에 수천 이상 만 단위까지 추가 프로그램이 개발되어 ERP의 중요한 축으로 사용되고 있다. 물론 경험상 대부분의 회사들이 50%이상의 프로그램을 전혀 사용하지 않고 있어 활용도의 평가에 따라 선택적으로 이관 전략을 수립해야 하지만 이 많은 프로그램들을 새로운 기술에 기반하여 재구축하는 것은 현실적으로 불가능하다. 필요에 따라 여러가지 대응 전략을 수립할 수 있겠지만 이들 프로그램들은 완전한 Clean Core 전략을 수립하는데 있어 최대의 장애가 될 것이다.
결론적으로 이러한 국내 환경을 고려한 Clean Core 전략을 제시해 보면 다음과 같다.
1) Fit to Standard Architecting : PI통한 프로세스 Steamlining, SAP LoB 솔루션 및 업계의 Best of Breed 솔루션 검토를 통한 최적의 Application Architecture 구성, Simple ERP Architecture 구성
2) Fit to Standard S/4HANA 표준 확장 활용 통한 표준 활용 확대 및 개발 최소화
- 표준 Fiori App 활용 확대
- In-App extensibility 및 enhancement 활용 확대
- Embedded Analytics 활용을 통한 Operational Reporting 개발 대체
3) Clean Core 개발 (3 Tier 개발 전략 + 기존 Code Migration)
- Clean Core ABAP 개발
- API enablement: Released 되지 않은 Object를 Release하여 Clean Core 개발에서 쓸 수 있도록 하는 잠정 조치 실행
- Classic ABAP 개발 with Clean Core rule applied
- CCM
2023.01.17 DNX Seon
