2030을 위한 ERP 이야기
3. 차세대 ERP를 위한 추진 방법론
1장에서 논의했던 차세대 ERP Vision을 2장에서 논의했던 SAP S/4HAHA ERP의 기술 혁신에 기반하여 차세대 ERP를 추진하기 위하여는 각 차세대 구축 프로젝트별로 회사의 ERP vision과 Mission을 재정의하고 이를 달성할 방안으로서 추진 방법론을 정교화해야 할 것이다. 이때에는 앞장의 마지막 부분에서 이야기했던 여러 현실적인 상황들이 고려되어야 할 것이다.
이 장에서는 미래 지향적인 차세대 ERP 비전을 적극적으로 지향하면서도 현실적인 여건을 고려한 차세대 ERP의 모습을 정의해 보고 이를 추진하기 위하여 기존의 차세대 ERP 방법론에 어떤 요소들이 강조 혹은 추가되어야 할 지에 대하여 논의해 보겠다.
현재의 제반 여건을 고려하면서 막대한 Enterprise System 투자가 미래 지향적이면서 향후 지속적인 혁신활동을 통하여 기업의 경영 요구를 충족하는 차세대 시스템을 만들어 내기 위하여는 다음과 같은 목표를 차세대 시스템에 부여하는 것을 생각해 볼 수 있다.
S/4 HANA의 재구조화되고 개선된 기능들을 적극적으로 검토하여 To-Be 프로세스 설계 구축
Any Device, Consumer grade Web UI/UX 지향 - Fiori App 및 Web GUI 기반 시스템 (제한적으로 Windows GUI 사용)
Embedded Analytics 기능을 적극 활용하여 Operational Analytics 데이터 활용을 강화하고 전사 Data Platform 전략하의 Data Driven Management 구현
In-App Extensibility 및 Developer Exensibility 통한 표준 확장 및 UI5 Flexibility Serivce 기반 표준 확장 적극 사용을 통한 Fit to Standard 강화
SAP HANA DB 기술 혁신의 장점을 충분히 누릴 수 있도록 하는 CDS 및 Code Pushdown 기능 적극 활용하여 기능 및 성능 최적화 달성
CDS와 Fiori UI/UX 와 최적 연동된 RAP(ABAP RESTful Programming Model)을 활용한 Clean Core 개발 기반 구축
개발자 역량 및 인력 조달의 한계를 고려하여 Classic ABAP을 활용한 WebGUI 개발 병행 수용. 이 경우에도 Clean Core 개발 원칙의 수립 적용
3 tier 개발 모델 기반의 Embedded Steampunk 활용 개발 분리(On-Stack Development) Clean Core 전략의 실행
기존 Custom ABAP Code의 Clean Core Migration 수행 확대
Clean Core ABAP으로 개발 분리되지 않은 기존 ABAP 프로그램 및 신규 ABAP 프로그램 최소화 및 별도 특별 관리를 통한 지속적인 Clean Core 활동 수행
나열해 놓고 나니 너무 기술 플랫폼의 관점에서 목표와 방향을 정의한 것 같다. 그러나 프로세스 혁신과 같은 보다 본원적인 ERP 추진의 핵심 활동은 이미 업계에 표준으로 널리 퍼져 있고(물론 여기에도 이슈도 있고 변화도 필요하다.), DX 추진을 위한 다양한 비전과 목표도 있을 것이고, 전사 시스템 관점에서의 최적의 Architecture 구성에 대한 목표도 있을 수 있다. 이러한 주제들은 따로 논의할 수 있을 것이다.
지금까지 축적된 프로세스 혁신 기반의 ERP 구축 방법론은 (1) PI(프로세스 혁신)라는 과정을 통하여 프로세스의 비전과 상위 차원의 프로세스 설계를 수행하고, (2) 프로토타이핑이라는 과정을 통하여 이러한 설계를 ERP 시스템에서 테스트해 봄으로서 표준 ERP가 제공하는 기능과의 Gap을 도출하고(Fit & Gap 수행), (3) Gap으로 도출된 항목들에 대하여 다시 PI 활동을 거쳐 프로세스를 변경하던, 표준 ERP를 보완하던, 아니면 추가로 프로세스 요구에 맞게 추가 개발을 수행하던 하였다.
이러한 일반적인 절차는 많은 방법론들이 유사하게 적용하고 있는 패키지 기반 설루션 적용의 절차들일 것이다. 그러나 초기 ERP 구축이 경영혁신의 한 도구로 인식되고 경영진의 참여로 Top Down 방식으로 진행될 때와는 달리 최근에는 기술적이고 실무적인 시스템 구축 프로젝트로 인식되면서, 프로세스 혁신은 형식적인 절차가 되어 가고 있고, ERP 표준을 적극 활용하려는 노력은 줄어들고, 표준 ERP가 사용자 요구에 정확하게 부합하지 못하는 프로세스 요구는 당연하게 추가 개발로 문제를 해결하는 것이 일반적인 관행이 되었다.
이런 관행은 경영진의 참여가 줄여 들면서 투자 예산 배정의 목적인 가치 창출이라는 원래 목표는 시스템 구현의 단계가 진행되면서 개별 사용자들의 오래된 관행과 취향에 맞는 업무 방식 및 사용자 UI 등에 대한 요구의 충족이 되어 버리는 경향이 강화된 것 같다. 이러한 관행은 업계에서 일하고 있는 ERP 전문가들(컨설턴트)들에게도 책임이 아주 많다고 생각한다. 오랫동안 숙련된 전문가들은 기업 가치에 기여하는 새로운 일하는 방식과 기술의 적용이라는 머리 아픈 숙제보다는 매일 같이 일하는 사용자의 요구에 수동적으로 대응하고, 또 본인들이 가지고 있는 과거의 경험에 기반한 지적 자산들을 갱신하지 않고 그대로 활용하는 것이 편하기 때문일 것이다. 요즘 현장에서 살펴보면 가장 변화시키기 어려운 그룹이 이들 전문가 집단인 경우가 많다.
이러한 관행의 결과 국내 많은 기업들이 엄청나게 많은 추가 프로그램의 개발을 해 왔다. SAP사는 글로벌 기업들의 조사를 통하여 추가 개발 프로그램의 상당 부분(50% 이상)이 실제로 쓰이지 않고 방치되고 있다는 조사 결과를 발표한 적이 있다. 그러나 최근에 ERP 진단 프로젝트 경험들에 의하면 국내 기업들은 매출액 10조 규모의 경우 수천 개의 추가 개발 프로그램을 가지고 있고 이 추가 개발 프로그램들의 60%~70%는 실제로 사용되지 않고 있는 것으로 조사되었다. 20% 미만의 사용 현황을 보인 기업도 본 적이 있다.
이러한 현상은 기업의 업의 변화에 기인한 프로세스의 변화, 기업의 성장에 따른 전문 프로세스/시스템으로의 분리에 따른 사용 중지 등 여러 가지 어쩔 수 없는 이유들도 있을 것이나, 더 많은 경우 사용자 취향의 변화, 지속적인 보완 및 활용 노력의 부족, 유사한 요구에 대하여 매번 새로운 프로그램을 개발하는 관행 등 여러 가지 이유가 더 크게 작용한 것이라고 본다. 이러한 사용되지 않는 추가 개발 프로그램들은 개발과 유지보수에 엄청난 비용을 지불한 것들이다. 이러한 TCO 관점의 문제 보다 더 심각한 것은 이들 추가 개발 프로그램들은 관리가 되지 않게 되기 때문에 그 내용을 파악하고 있는 직원들이 없게 되고 그래서 Block Box화 되고 아무도 어쩔 수 없는 상황에 놓이게 된다. 그래서 최근 S/4HANA로 Migration 하는 회사들을 보면 사용하지 않는 프로그램들도 모두 Migration을 하는 경우들도 경험했다. 이렇게 방치된 프로그램은 Upgrade/개선등의 과정에서 더 많은 시간과 노력을 들이게 만들고 사용자들의 새로운 요구에 대응하기 어렵게 만들어서 결과적으로 더 많은 프로그램을 개발하게 만드는 악순환을 가져온다.
이러한 Dirty Core의 부작용을 줄이고 Simple하고 관리되는 Core ERP Enterprise 시스템 구축을 통하여 관리 비용을 줄이고 경영 환경의 변화에 유연하게 대응할 수 있는 차세대 시스템을 만들지 않으면 '뒷방 늙은이 시스템'으로 취급되는 SAP ERP의 오명을 벗기 어려울 것이다.
이러한 상황이 Upgrade Stable, Cloud Reay라는 SAP의 Clean Core 전략에는 적극적인 공감을 표시하기 쉽지 않더라도 이를 잘 활용하여 비용 투입을 줄이고 변화 대응에 유연한 ERP를 만들어 가야 한다는 방향성의 관점에서 한국적 Clean Core 노력을 주장하게 만드는 이유이다.
이를 위하여 기존의 차세대 ERP 구축 방법론에서 핵심적으로 변화가 필요한 부분은 프로토타이핑과 Fit & Gap 수행 과정에 있다고 본다. 표준 S/4HANA 표준을 적극적으로 활용하고 개발을 최소화하며 추가되는 개발도 향후 Upgrade와 Cloud 전환에 장애가 되지 않는 방향으로의 개발을 위하여는 다음과 같이 것들이 고려되어야 할 것이다.
1. S/4HANA 표준의 재인식
S/4HANA는 많은 기술적, 기능적 변화에 기반한 전혀 다른 ERP 제품이라고 SAP는 주장한다. 따라서 향후 10~20년 이상을 보고 만드는 차세대 ERP 시스템은 이러한 변화를 충분히 이해하고 이 변화의 장점을 적극 활용해야 할 것이다.
1) Data 기반의 변화 : SAP HANA DB에 기반한 CDS 데이터 모델링, HANA DB 성능 활용을 극대화 하기 위한 Code Push Down을 위한 CDS 개발 및 SQL 활용, 이를 위한 기존 ABAP 개발 관행 및 개발된 프로그램의 전환, HANA DB에 최적한 한 각 모듈 Data Table의 Simplification 등의 변화를 충분히 검토하고 To-Be 설계와 개발/구축에 반영하여야 한다. 이러한 변화를 반영하지 않고 compatitive view를 통해 기존 프로그램들을 그대로 재활용하는 것은 엄청난 낭비와 성능 저하를 가져올 것이다.
2) 프로세스/기능의 변화 : 프로세스와 기능은 ERP 사용의 핵심 동인이기 때문에 변화된 기능은 적극적으로 검토 반영되어야 한다. 자세한 변화 항목들은 다음 장에서 다루어 보도록 하겠다.
2-1) 모듈 솔루션의 재구조화: S/4HANA는 기존 SAP 제품군의 여러 솔루션들을 재구조화하면서 Core 제품으로서의 위상을 강화하고 LoB 솔루션 제품들과의 통합을 설계하였다. 이에 따라 많은 독립 솔루션들이 S/4HANA 제품 안에 포함되었다. aATP, PPDS, Embedded TMS/WMS 등이 그러한 예들이다.
2-2) 신규 기능의 제공 : 새로운 개념의 기능들이 신설되었다. 예를 들어 제품의 수익성 분석을 제공하던 CO-PA의 기능과 다른 새로운 방식의 손익 분석 기능을 제공하는 Margin Analysis 등과 같은 예를 들 수 있다.
2-3) 기능의 혁신적 변화 : 기존 있던 기능들의 일부는 완전히 새로운 기능으로 바뀌어 제공되고 있다. 예를 들어 Material Ledger는 이제는 반드시 사용해야 하는 표준이 되었고 기존에 MM-IM과 나뉘어 있던 재고 평가 기능은 M/L로 통합되었다.
2-4) 기능의 변경: 많은 단위 기능들의 변화도 있었다. 예를 들어 고객마스터/벤더 마스터 등은 Business Partner 관리로 통합되어 변경되었다. 이 기능은 전에는 CRM 등 SAP 다른 제품군에서 이미 사용되고 있던 것인데 S/4HANA의 표준으로 재정립되었다. 또한 여신과리, Rebate 관리 같은 기능들은 기존의 기능을 폐기하고 새로운 기능을 사용해야 한다.
2-5) 신규 기능의 추가 : 많은 신규 기능들이 추가되고 있다. MRP Live 등 S/4HANA HANA DB의 강점을 충분히 누릴 수 있도록 하는 기능들이 추가되었고 추가되어가고 있다.
3) UI/UX의 변화
사용자는 각종 스크린 장비를 통하여 시스템을 활용한다. 프로세스와 기능이 사용자에 의하여 효과적으로 활용되지 않으면 그 강점이 줄어든다. 따라서 사용자 경험 중심의 UI/UX는 ERP 제품/솔루션의 핵심적인 오퍼링 중의 하나이다.
SAP는 S/4HANA 도입과 함께 적극적인 Any Device, Consumer grade Web UI/UX를 제품 전략으로 추진하고 있다. 이를 위하여 Fiori UI/UX를 기본으로 많은 기능과 기술을 선보이고 있다. 물론 기존 제품 기능의 연속성을 강조하는 SAP 입장에서 기존 GUI를 Web 환경에서 활용할 수 있도록 하는 WebGUI(SAP GUI for HTML)도 같이 활용할 수 있게 하고 있다.
4) More Focus on Data
SAP는 ERP가 단순히 기업의 업무를 처리하고 기록하는 시스템을 넘어 기업 가치를 창출하는 핵심 시스템으로 자리 잡도록 하고 싶어 한다. 직원들의 생산성을 높이고 직원들의 업무를 데이터의 처리에서 데이터의 활용으로 전환하게 하고 싶어 한다. 이제는 단순한 데이터의 입력을 원천 장비(바코드, 터치 스크린, 센서 등), 원천 시스템(각종 사내 Front End 시스템, 고객/벤더 시스템, 다양한 외부 주체의 시스템, chatbot, RPA 등) 및 외부 주체(고객, 벤더, 각 개인 등)으로 분산시키고 ERP의 사용자는 정보를 취합하고 분석/평가하고 판단하는 역할로 전환함으로써 보다 생산적인 업무로 전환시키고 싶어 하는 것이다.
전사 Dataplatform 전략과 함께 ERP 차원에서는 SAP Embedded Analytics를 통하여 Operational 사용자의 데이터 활용을 강화하는 도구를 제공하고 있다.
2. S/4HANA 표준 기반 Fit & Gap - 특히 Web UI/UX 표준 기반
최근 국내에서 주요 선도 대기업들 중심으로 대규모 S/4HANA 전환(신규 구축 혹은 Conversion) 프로젝트들이 여럿 진행되고 있다. 그러나 지금까지 설명해 왔던 S/4HANA의 새로운 기술, 제품 전략, 비전을 반영한 차세대 ERP 구축이 이루어지고 있는지는 다분히 회의적이다. 우선 대표적으로 Fit & Gap을 수행할 때 대상이 되는 표준 ERP 프로세스들의 확인이 전통적인 SAP GUI(for Windows)로 이루어지는 곳이 대부분으로 파악된다. Fiori 같은 새로운 기술과 가능은 아주 제한적으로 검토되고 추진되고 있어 보인다. 예를 들면 Firoi의 Overview Page처럼 여러 가지 Chart와 같은 BI tool 기능들을 활용한 디자인 요소와 요약된 KPI data를 보여주는 정도를 통하여 ERP 투자를 통한 새로운 가치를 일부라도 보여주고 싶어 하는 것 같다.
그러나 SAP는 GUI로는 더 이상의 기술 혁신도 새로운 기능의 출시도 하지 않고 있고 이미 많은 새로운 기능들이 Fiori UX로 구현되고 있기 때문에 이러한 방식의 Fit& Gap 수행은 미래를 위한 차세대 ERP 구축을 달성하기 어렵다고 본다. 따라서 일단은 Web UI/UX를 S/4HANA의 표준 사용자 경험으로 삼고 컨설턴트 및 S/4HANA 프로젝트 수행자들부터 이 새로운 환경에서의 표준을 검토해 보고 Gap이 있으면 찾고 대안을 탐색할 필요가 있다고 본다. Web UI/UX는 새로운 표준 Fiori App 뿐만 아니라 기존 Windows GUI기반 T-Code들도 WebGUI 형태로 실행하고 테스트할 수 있기 때문에 Fiori App의 신규 기능과 기존 GUI의 기능들을 비교 평가하면서 최적의 조합을 찾을 수 있을 것이다.
이러한 Web UI/UX 표준에 의한 Fit & Gap의 수행을 포함하여 차세대 ERP 구축이라는 비전과 목표에 부합하는 To-Be 설계를 위한 원칙을 아래와 같이 제시해 보고자 한다.
2.1 차세대 ERP To-Be 설계 원칙
Process, Data, UI/UX를 통합적으로 고려한 To-Be 설계를 통하여 회사와 사용자에게 최적으로 프로세스와 데이터를 제공하는 차세대 시스템을 목표로 하면서 S/4HANA의 표준 활용을 높이고 개발을 최소화하며 불가피한 개발도 향후 업무 환경 및 요구의 변화에 유연하게 대응할 수 있도록 Clean Core 개발원칙을 준수하여 전체적인 TCO의 절감과 업무 생산성 향상, 미래 대응력을 강화할 수 있는 Digital Core를 구축함을 설계 원칙으로 제시하고자 한다.
1) Process, Data, UI/UX의 통합적 설계
지금까지의 차세대 ERP 설계 관행들을 보면 대체적으로 프로세스/기능 중심의 요구사항 파악 및 설계에 초점을 맞추고 진행되었다. 이는 국내 ERP가 프로세스 혁신(PI) 도구로 인식되고 정착되면서 이어져온 전통이라고 이해할 수 있다. 기준 정보가 프로세스와 함께 초기부터 분석되고 설계되기는 했지만 어떤 transaction들이 분석/활용되어야 하기 때문에 프로세스상에서 어떤 데이터들이 관리되어야 하는지는 상대적으로 소홀하게 취급되었다. 또한 데이터 활용과 분석은 프로세스 설계가 마무리 되는 시점에 추가적으로 별도의 팀들이 별도의 분석과 설계를 통하여(통상 BW팀이) 구축하였다.
지금까지 사용자의 ERP 활용 경험은 거의 무시되어 왔다. SAP GUI는 오래전부터 글로벌하게 악명이 높았다. 많은 국가, 많은 산업, 많은 프로세스를 포함해야 하는 SAP의 프로세스 특성상 하나의 화면에 여러 개의 tab으로 화면을 분할하고 여러 section으로 나눠서 많은 데이터 필드들을 제공하였다. 개별 사용자 입장에서는 본인과 상관도 없고 회사에서 쓰이지는 않는 SAP의 표준 필드들을 봐야 했고 자신이 처리/확인해야 하는 필드를 찾아 탭을 이동하고 페이지를 스크롤해야 했다. 일부 필드 control 설정을 할 수 있는 기능이 있었으나 크게 사용자 환경을 개선하기에는 역부족이었다.
또한 사용자가 본인의 직무에 필요한 역할을 수행하기 위하여 필요한 T-code를 메뉴를 통해 찾아가야 하는 기능 중심의 시스템이었다. 사용자 Role에 따른 메뉴를 제공하기도 하였지만 많이 활성화되지는 못한 것 같다. 역시 많은 메뉴들이 메뉴 트리로 제공되고 필요한 T-code를 찾아가야 했기 때문이라고 생각한다. 또한 사용자 Role을 정의하고 메뉴를 구성하는 작업은 프로세스 설계의 일부분이라기보다는 프로세스 설계가 완료되는 시점에 사용자에게 권한을 부여하기 위한 방법으로 인식되어 설계 단계의 주요 활동이 아니었다.
차세대 ERP에서는 설계 단계에서부터 프로세스는 데이터를 생성/활용하기 위하여 수행되는 것으로 이해하고 이는 사용자의 경험을 통하여 성과를 만들어 낸다는 점을 인식하여 프로세스 설계, 데이터 설계, UI/UX 설계가 사용자의 직무별 역할에 적합하도록 통합 설계되어야 할 것이다. 물론 기존에 별도의 주체에 의하서 수행되던 이러한 일들이 누구에 의하여 어떻게 수행되어야 하는지에 대한 현실적인 숙제는 풀어 나가야 한다.
이러한 사용자 직무 역할에 따른 경험 최적화 관점의 설계에서 운영 사용자의 데이터 분석 요구, 즉 Operational Reporting 요구를 각 프로세스 단계 속에서 확인하고 설계해야 한다.
또한 자동화/지능화 등 전통적인 프로세스 혁신 설계에 최신의 Digital 기술을 활용한 프로세스 효율/효과를 위한 설계 노력도 강화되어야 한다. RPA, Chatbot 등을 활용한 프로세스의 자동화, AI/ML 등의 기술의 각 프로세스에서 어떻게 활용할 수 있을지에 대한 검토(SAP 제시 표준 적용 시나리오 참조) 등이 추가되어야 한다. 또한 사용자들을 단순한 데이터 입력 주체로 보는 시각에서 이러한 데이터 Capture 기능은 고객/파트너내외부 시스템, Data Capture 장비 등에 분산하고 사용자는 데이터 분석/의사결정을 통한 프로세스 성과에 집중하도록 하는 것이 설계 단계의 중요한 Task 중의 하나가 되어야 한다.
2) S/4HANA 표준 활용 극대화
S/4HANA에서는 기능 구성을 업무 영역 관점에서 Finance, Sales, Sourcing & Procurement, Manufacturing, Supply Chain 등으로 재구성하고 여기에 기존 모듈들을 재구조화하고 여러 독립적인 솔루션 모듈들을 포함시키고 기능들을 개선하였다. 기술적으로는 FI, CO, SD, MM, PP와 같은 기존의 솔루션 component(모듈)의 개념을 그대로 유지하고 있다.
[그림 3-1] S/4HANA Area & Applicaton Component(Module)최근의 차세대 ERP 구축 프로젝트 현장을 보면 과거 계속 사용하여 오던 모듈 단위로 거의 모든 논의들이 이루어지고 있다. S/4HANA에서 확장된 모듈/기능들의 검토가 많이 되지 않고 써 오던 것, 익숙한 것 중심으로 재구축이 이루어지고 있다고 혹평할 수도 있다.
시각을 넓혀 고객 사용자의 요구를 E2E 프로세스 전체로 이해하면서 S/4HANA 솔루션을 업무 영역(Area) 관점에서 포괄적으로 기존 모듈 외에 새로 추가된 모듈, 솔루션, 기능, 프로세스를 검토하여 적용 가능성, 기존 프로세스의 변경 가능성, 프로세스의 혁신 가능성을 평가하고 설계하여야 할 것이다.
이 과정에서는 여러 가지 새로운 기능 및 프로세스에 대하여 검토하고 테스트하여 적극적으로 수용함으로써 기존 ECC의 한계나 제한된 기능 때문에 추가로 개발을 했던 기능이나 ERP에서 구현하지 못했던 기능/프로세스들을 설계할 것을 권하고 싶다. 예를 들어 보면 기존의 CO-PA를 통한 수익성 분석 대신 혹은 병행하여 Margin Analysis 사용, MM의 재고의 재고 수불부와 CO의 원가 수불부로 나뉘어 있던 것을 ML 기반 통합 수불부로 재구현, 운송관리/창고관리 등의 영역에서 한 단계 진화한 SAP 기능들인 TM, EWM 등이 S/4HANA 안으로 내장되어 들어오게 된 Embedded TM/EWM 등을 활용하여 향후 기능이 중단될 LE Shipment 나 LE WM 등을 대체 구현하는 것 등을 들 수 있을 것이다.
사용자 UI/UX 관점에서는 Fiori Launchpad 기반의 Fiori App 및 WebGUI(SAP GUI for HTML) App 등의 Web UI/UX를 표준으로 설정하고 이 App들을 프로토타이핑 과정에서 적극적으로 검토 사용하여 기존의 SAP Windows GUI의 한계를 극복하는 방법을 찾아야 할 것이다.
이 과정에서는 이전의 T-Code 사용하던 것과 같이 개별 기능 단위의 UI/UX 검토를 넘어 사용자의 직무별 업무 흐름을 분석하여 사용자가 어떤 흐름으로 Data들을 취합 평가(대상 업무 탐색)하여 업무를 수행하고(해당 기능 수행), 필요시 결재를 받거나 필요한 Reporting을 수행하는지에 대한 이해를 바탕으로 프로세스의 설계를 Data 설계, UI/UX 설계와 병행하여야 할 것이다.
S/4HANA는 각 업무 영역에 표준 직무(Role)를 정의하고 각 role에 필요한 S/4HANA의 표준 기능(App)들을 메뉴로 구성하여 두었다. 이러한 표준 Role Template을 기반으로 사용자의 직무에 기반하여 프로세스 및 사용자 업무 흐름에 적합한 프로토타이핑이 수행되어야 한다.
S/4HANA의 표준 활용을 최대화하려면 Enterprise System Architecture 설계를 통하여 최적의 S/4HANA ERP 및 영역 시스템들을 구성하고, 글로벌 표준에 부합하도록 프로세스를 재설계(PI)하는 것뿐만 아니라 일차 Gap이 발생했을 때 Gap의 경중에 따라 Gap이 크지 않고 일부 기능/데이터/UI을 조정을 통하여 표준을 사용할 수 있는 것이라면 S/4HANA의 표준을 Enhance 하여 추가 개발 양을 줄이는 것도 중요하다. S/4HANA는 기존의 ECC 제품군보다 표준을 Enhance 할 수 있는 다양한 기술적 Option을 가지고 있어 유사한 요구사항이지만 기능/data/UI의 부족 때문에 표준을 사용하지 못하고 추가로 개발해야 하는 부담을 줄일 수 있다. S/4HANA의 다양한 표준 Enhancement 방법들은 추가로 다루겠다.
3) Clean Core 개발을 위한 설계
아무리 Fit to Standard 철학에 기반하여 프로세스를 글로벌 표준에 맞춰 재설계하고 표준을 확장하여 사용하더라도 모든 사용자의 요구를 충족할 수는 없다. 이러한 경우에는 향후 유지보수 부담이 덜하고 미래지향적인 clean core 개발 원칙을 수립하고 이를 적용하여야 한다.
한국 기업들이 다른 국가의 기업들보다 추가 개발이 많은 이유는 사용자들이 일하는 방식과 시스템을 사용하는 방식이 달라서 일 것이다. 그러나 이것이 잘못되었다고 이야기할 수만은 없을 것이다. 이러한 일하는 방식이 우리가 그동안 급격하게 우리 기업들을 성장시켜 온 밑바탕의 하나가 된 것이라고 이해할 수도 있다.
그러나 산업화 시대/민주화 시대 우리가 일했던 방식이 2030 MZ 세대에게 그대로 적용될 수 없는 것을 우리는 현장에서 느끼고 있다. 많은 시간 집약하여 일하던 방식에서 주어진 시간 내에 효율적으로 일 할길 원하는 다음 세대 사용자에게 우리가 그동안 일하는 방식에 최적화된 일하는 방식/시스템을 물려줄 수는 없을 것이다.
Clean Core 개발이 되기 위하여는 이러한 관점에서의 설계가 되어야 한다. clean core 개발을 기술적으로 단순한 coding을 하자는 것이 아니라 단순하고 통합된 업무를 위한 개발만 하자는 것이기 때문이다.
이를 위하여는 먼저 앞에서 이야기했던 대로 표준 활용을 늘리기 위하여 표준 확장 방안이 적극 검토되어야 한다. S/4HANA의 새로운 표준 확장(Enhancement) 방법은 In-App Extenion을 통하여 기존의 User Exit 등 제한적으로 활용된 표준 확장 방법을 적극적으로 검토하고 Fit & Gap을 수행하여 Gap을 줄여 가야 한다. 이를 통해 유사한 기능이 있는 데에도 비슷한 것을 추가로 개발하는 것을 지양해 나가야 한다.
추가로 개발해야 하는 Gap에 대하여도 SAP의 새로운 Extensibility에 따른 Clean Core 개발 전략을 따를 것을 권고한다. 이에 대하여도 이후 자세히 다루겠다. 간단하게 이야기하면 (Embedded) Steampunk를 통하여 물리적 혹은 논리적으로 개발을 분리하는 On-Stack Extension 혹은 Side by Side Extension을 채택하는 것이 우선이다.
이러한 개발 분리에 의한 Clean Core 개발은 아직까지는 여러 현실적인 제약이 있는 것이 사실이고 이럴 경우에는 Classic ABAP으로 지금까지와 같은 방식으로 개발을 진행할 수밖에 없을 것이다. 그러나 이러한 경우에도 Clean Core 개발의 원칙을 수용할 수 있는 여지들은 많기 때문에 우선순위를 정하고 개발을 진행한다면 좀 더 Clean 한 추가 개발을 수행할 수 있을 것이다.
2.2 Web UI/UX 기반 Fit & Gap 수행 방안
이러한 프로세스 설계 원칙들을 준수하는 출발은 Fit & Gap에서부터 출발한다. 기존의 잘 정의된 프로토타이핑 Fit & Gap 방법론에 몇 가지 Clean Core 원칙들을 추가하면 된다. 프로토타이핑에 기반한 To-Be 프로세스 설계는 그것이 개별 프로세스 단위이던 시나리오 프로세스 단위이건 최하단의 Activity/Task 단위에서 사용자의 시스템 활용을 시뮬레이션해보고 원하는 데이터/기능/사용자 경험과 어떻게 다른지 점검하여 Gap을 도출하고 Gap이 없는 영역은 표준의 설정을 통하여, Gap이 발생한 부분에 대하여는 Gap을 해결하기 위한 여러 가지 대책들이 강구되도록 진행된다.
1) 사용자 직무(Role) 기반 사용자 경험을 중심으로 시스템 활용을 점검하고 Web UI(Fiori App, WebGUI) 표준과의 프로세스 Gap, Data Gap, 사용자 경험 Gap을 도출하도록 해야 한다. 이를 위하여 S/4HANA가 제공하는 표준 직무(Role) 템플릿을 출발로 설정하면 도움이 될 것이다. 프로토타이핑 단계에서는 아직 직무 기반 Role 설계가 되어 있지 않을 것이기 때문에 SAP가 각 업무 영역별로 미리 설정해 둔 Role Template을 활용하면 좋을 것이다.
S/4HANA는 수백 개의 Role Template를 제공하고 있는데 국가별 Variant를 제외하면 주요 모듈만을 범위로 했을 때 Business Role은 100개를 넘지 않는다. 이를 각 모듈 혹은 업무 영역으로 나누면 10여 개 정도, 최대 20개를 넘지 않을 것이다. 이 직무 role template들은 해당 직무를 수행하기 위하여 필요한 연관 업무 혹은 모듈의 기능/App도 포함하고 있기 때문에 다른 모듈들과의 연관을 위하여 굳이 다른 모듈의 표준 Role template을 추가할 필요는 없다.
이 Role template들은 각 업무에 필요한 표준 Fiori App과 WebGUI App으로 구성되어 있다. S/4HANA의 해당 업무 영역의 모든 App들이 포함되어 있기 것은 아니기 때문에 특정한 App이 없을 수도 있다. 이러한 경우에는 해당 App을 찾아서 추가하고 테스트를 진행하면 된다. 초기에 새로운 표준을 이해하고 기초 프로토타이핑을 수행하기 위한 정도의 충분한 App들을 이 직무 Role들이 포함하고 있기 때문에 시작점으로서는 적절할 것이다.
2) 사용자 프로세스 요구 사항 파악 시의 추가 항목
프로세스 혁신을 넘어 Digital 혁신의 도구이자 핵심 기반으로서의 차세대 ERP 구축이 되어야 한다고 이야기하였다. 또한 차세대 To-Be의 설계에서는 프로세스와 Data, UI/UX(사용자 경험)이 통합적으로 고려되어야 한다고 주장하였다. 이를 위하여는 기존의 프로세스 중심의 사용자 요구 기능 파악에 기반한 To-Be 설계에 추가적인 요구사항들이 설계의 초반부터 포함되어야 한다.
먼저 해당 직무의 업무를 수행하기 위하여 어떤 업무를 대상으로 하고 집중할 것인지 결정하기 위하여 필요한 정보 수집, 즉 대상 업무 리스트(Worklist) 성격의 필요 데이터 파악이 필요하다. 또한 업무의 처리 과정에서 핵심적으로 수집 처리되어야 하는 데이터도도 명확히 해야 한다. 그리고 업무의 완료 후에 이를 집계 취합하여 보고하고 공유하기 위한 데이터의 필요도 파악하여야 한다.
이러한 프로세스와 데이터의 요구가 어떤 사용자의 환경에서 어떤 사용자 경험을 제공하는 것이 일의 효과와 효율을 극대화할 수 있는지도 파악되어야 한다. 사용자에 따라 PC 화면상에서 업무를 처리할 수도 있지만 태블릿, 모바일, 기타 여러 Device에서 업무가 처리되어야 하고 일의 성격에 따라 화면에 제공되는 데이터의 양, 종류, 제공 방식 등도 정교하게 설계되어야 한다.
또한 자동화, 지능화를 위한 사용자 요구에도 집중해야 한다. 자동화는 Data Capture의 자동화부터 가능성을 탐색해야 한다. 사용자가 단순한 데이터 처리자가 아니라 자동화된 방법(데이터 input 장비나 내 외부 단위 시스템 등)으로 데이터를 처리하고 사용자는 이를 기반으로 판단 결정할 수 있도록 하는 것이 중요하다. 또한 데이터/프로세스 처리 과정에 있어서도 RPA, Chatbot, workflow 등 Digital 기술을 활용한 프로세스 자동화 방법들에 한 검토가 필요하다.
마지막으로 누적된 Operational Data를 기반으로 프로세스를 지능화할 수 있도록 AI/ML 기법들의 도입 가능성에 대한 검토도 고려해 볼 수 있다. S/4HANA는 몇 가지 영역에서 사례들을 제공하고 있기 때문에 이를 참조하고 이를 기반으로 다양한 가능성들을 탐색해 보는 것도 이 단계에서 수행되어야 한다.
3) 표준 T-Code 및 표준 Fiori App 명시/점검
아직은 차세대 ERP 프로젝트 현장에서 새로운 Web UI/UX 및 기술에 기반한 전혀 새로운 S/4HANA를 경험하고 이해하고 있는 수행 주체들(컨설턴트, 개발자, PI, 프로젝트 leadership 등)이 부족하 것이 현실이고 따라서 별도의 강조가 없으면 지금까지 해 오던 방식대로 Windows GUI 기반 기능들을 표준으로 삼고 프로젝트를 진행한다. 당분간의 어쩔 수 없는 현실일 것이다. 그러나 점차 이러한 제약들은 극복해 가야 하고 첫출발은 프로토타이핑 계획 및 실행 템플릿에 해당 프로세스의 Task를 어떤 S/4HANA의 기능으로 시뮬레이션해 봤는지 기록하도록 해야 한다. 지금까지는 Windows GUI의 T-Code가 기록되었다. 여기에 어떤 Fiori App, WebGUI App이 같이 점검되었는지 기록하도록 하여 전통적인 표준과 새로운 표준을 같이 검토하고 최적의 To-Be 조합을 선택하고 설계하도록 의도적으로 강조하여야 할 것이다.
4) Gap 해결 방안의 상세화 통한 표준 활용 확대 및 Clean Core 개발 설계 탐색의 조기 실시
프로토타이핑 과정에서 Gap이 발생하면 이를 기록하고 대체를 수립하게 하는 것이 지금까지 축적된 경험이다. 첫 번째 출발은 프로세스 요구사항을 재 검토하여 프로세스를 재설계할 방법을 찾거나, 마스터 데이터를 재정의하여 프로세스 변경을 유도하거나 사용자의 R&R를 조정하고 프로세스의 처리 순서를 변경하는 등의 노력, 우리는 이러한 것들을 프로세스 혁신(PI) 활동이라 해 왔다.
이러한 PI 활동 외에 몇 가지 더 추가돼야 한다. 먼저는 새로운 S/4HANA의 모듈/솔루션/기능들을 검토하여 이들이 이러한 Gap을 메꿀 수 있는지 확인해야 한다.
그다음 단계는 Gap의 폭에 따라 일정 부분만의 표준 확장(Enhancement)을 통하면 표준 기능을 쓸 수 있는 Gap인 경우에는 표준 확장을 통하여 Gap을 해결하는 것을 우선 고려하도록 해야 한다. 기존의 ECC 보다 훨씬 많은 다양한 방법으로 기능, Data, UI의 확장이 가능해졌기 때문에 적극적으로 이러한 확장을 통한 표준 활용을 검토해야 한다
마지막으로 이러한 모든 방법으로도 해결이 불가능하고 우리 회사만의 차별적인 경쟁력을 제공해 주는 요구사항이라면 S/4HANA의 개발 기능을 활용하여 추가 개발을 설계하고 개발해야 한다. 이러한 경우에도 개발을 최소화하고 향후 관리와 Upgrade에 유리하도록 Clean Core 개발이 될 수 있도록 관리되어야 하고 프로세스의 설계 단계에서 부터 이를 고려해야 한다..
먼저 WRICEF(Workflow, Reports, Interface, Conversion, Enhancement/Extension, Form) 유형으로 구분하고 명확한 회사의 Clean Core WRICEF 방법에 따라 Gap을 해결하도록 대안을 찾아야 한다. 특히 Report 요구 사항의 개발은 Embedded Analytics 기능의 활용으로 대체해 줄이 수 있을 것이고, Extension 즉 추가 개발(기존 통상 CBO라고 한 것)은 좀 더 구체적으로 Clean Core 개발 방법을 개발 방안으로 검토하고 계획하여야 할 것이다. 이를 위하여는 Fit & Gap Template의 보완도 필요할 것이다. 각 유형별 Clean Core 개발을 위한 설계 방안에 대하여는 다시 설명하도록 하겠다.
2.3 Web UI/UX 기반 Fit & Gap 수행을 위한 컨설턴트 준비 항목
Web UI/UX 기반 Fit & Gap 수행이 활성화되기 위하여는 프로세스 설계자(컨설턴트)들이 준비되어 있어야 한다. 이를 위해 S/4HANA Fiori Launchpap 환경이 설정되고 최적화되어야 하고 각 업무 영역 혹은 모듈별로 S/4HANA Role Template을 지정하여 App들을 테스트할 수 있게 해야 하며 Fiori Launchpad와 Fiori App에 대한 교육을 통하여 이해를 높이고 거부감을 줄일 수 있도록 해야 한다.
1) Role 지정
아직 사용자별 직무 설계가 시작되기 전 단계에기 때문에 S/4HANA가 제공하는 Business Role template를 활용하여 각 사용자의 역할을 잠정적으로 설정하고 해당 역할에 필요한 App들을 테스트 환경에 설정하고 이를 프로토타이핑 시나리오에 포함하고 Fit&Gap을 수행하는 것이 출발일 것이다.
[그림 3-2] Business Role Template delivered by SAP참조 : https://blogs.sap.com/2020/07/08/sap-fiori-for-sap-s-4hana-understanding-sap-business-roles/
이때 이 모든 role들을 한꺼번에 모든 프로젝트 수행요원들에게 지정하지 말고 해당 영역에 필요한 것들만을 잘 골라서 지정하고 테스트하는 것이 도움이 될 것이다. 너무 많은 Role을 지정하게 되면 실제 사용자가 접하게 될 환경과 달리 너무 복잡한 메뉴 체계로 인하여 복잡한 시스템으로 보이게 될 것이고 시스템의 성능도 저하될 것이다.
각 Business role template 들은 SAP 가 생각하는 각 직무의 역할 수행을 위해 필요한 S/4HANA의 기능들의 활용 흐름을 고려하여 메뉴 구성을 해 둔 것들이다. 이 것들을 참조하여 프로토타이핑을 수행하면서 향후 해당 업무의 사용자 직무 구성을 어떻게 구성할 것인지 생각해 보는 것이 도움이 될 것이다.
[그림 3-3] S/4HANA Role Template의 fiori app navigation flow 설계사용자에게 S/4HANA의 Role을 지정할 때에는 SAP_BR_*라고 검색해 보면 위의 Role에 대하여 생성해 둔 Role Template를 찾을 수 있다. 각 국가별 variant가 많아서 전체 Role 수는 많아 보이나 이를 제외하면 각 모듈별 20여 개를 넘지 않을 것이다.
[그림 3-4] 사용자 Role 지정
[그림 3-5] 사용자 Role 지정에 따른 FLP 상의 사용자별 메뉴
2) Fiori Launchpad 환경 설정
Fiori Launchpad는 프로젝트 수행자들이 S/4HANA의 새로운 UI/UX를 경험하게 되는 통로이다. 대부분의 프로젝트 수행자들은 기존의 Windows GUI에 익숙하고 Easy Access Menu가 아주 편한 사람들이다. 따라서 UI가 달라 보이면 아주 다른 시스템으로 느껴질 것이고 이 새로운 UI에 익숙해지는 데에는 시간이 필요하다. 일반 사용자뿐만 아니라 IT 전문가들도 변화 관리가 필요한 부분이다.
이때 아주 중요하지만 놓치는 것 중 하나가 Fiori Launchpad의 환경이 프로젝트 수행자들에게 불편을 느끼지 않도록 최적화되어야 한다는 것이다. 대부분 Fiori 및 Firoi Launchpad(FLP)에 대하여 부정적 이미지를 가지고 있는 사람들은 초기에 Fiori Launchpad 사용 시 성능이 너무 느려서 한참을 기다려야 뭔가를 처리할 수 있었던 경험 때문이 경우를 많이 봤다.
FLP와 Fiori는 Web 환경의 UI이고 Web 환경은 Windows GUI와 같은 전용 Application보다 성능 관리 면에서 여러 가지를 고려하여야 한다. 당연히 FLP도 여러 가지 설정과 Parameter 조정을 통하여 성능을 최적화하도록 하고 있다. 그러나 사용자가 경험하는 성능 이슈는 Go-Live 전에나 고민하던 기존의 관행으로 별도의 성능 관련 설정을 하지 않고 FLP를 프로젝트 수행자들에게 제공하게 되면 너무 느린 FLP 때문에 그렇지 않아도 바뀐 UI/UX 때문에 거부감이 생길 수 있는 사람들이 Fiori UI/UX에 대하여 부정적인 경험을 가지게 만들게 될 것이다.
3) Fiori Launchpad 활용 방안 및 Fiori app 개요에 대한 컨설턴트 교육
Role을 잘 지정해 주고 성능이 특별히 문제가 되지 않도록 설정해 준다고 해도 알아야 빨리 새로운 UI에 익숙해질 것이다. FLP와 Fiori App의 특성과 유형에 대하여 익숙해질 수 있도록 프로젝트 참여자들에게 교육 기회를 제공해야 한다. 어떤 내용을 교육해야 할 것인지에 대하여는 이후 상세히 다루어 보도록 하겠다.
4) 컨설턴트 대상 S/4HANA 표준 확장 방법 및 Clean Core 개발 방안 교육
새로운 Fiori UI/UX에 익숙해지고 Fiori App을 기존 GUI App들과 함께 표준으로 고려하고 Fit & Gap을 진행할 수 있도록 프로젝트 참여자들을 교육하고 방법론을 공유하여 프로토타이핑 단계가 진행될 수 있게 한 다음에는 해야 할 일이 더 있다. 프로젝트 참여자들은 Fit & Gap 과정에서 도출된 Gap 들을 표준 확장 방법으로 해결하던지 아니면 추가 개발 항목으로 리스트 하던지 할 것인데 S/4HANA의 새로운 표준 확장 방법, 새로운 개발 방법을 이해해야 이들을 활용하여 Gap의 해결책을 찾고 정의하고 개발자들에게 전달할 설계를 만들 것이기 때문이다. 이것들에 대하여도 이후 상세히 다루겠다.
2.4 Web UI/UX 기반 Fit & Gap 수행을 위한 기술 지원팀 준비
S/4HANA의 새로운 기술 플랫폼, 새로운 ERP 비전을 구현하기 위한 차세대 ERP 구축을 목표로 첫 단계로 Web UI/UX 기반(즉 Fiori App + Web GUI App) 프로토타이핑 및 Fit & Gap 수행을 강조하였다. 그러나 아직 프로젝트 참여자들이 이러한 새로운 기술과 비전을 충분히 숙지하고 있다고 보기 어려울 것이다. 아무리 앞에서 강조했던 교육이 이루어지더라도 새로운 기술을 새로운 방식으로 적용하는 것이 전문가들에게는 특히 쉽지 않은 변화이고 따라서 이들이 포기하지 않고 새로운 방식을 적용해 볼 수 있도록 기술적으로 조언하고 지원할 전문가 그룹을 프로젝트 팀 내 혹은 외부 지원 조직으로 구성하여 운영하는 것을 권고하고 싶다.
이 모든 전문가들이 Full time일 필요는 없으며 한 사람이 여러 역할을 수행할 수도 있을 것이다.
1) UI/UX Expert 및 Fioir Launchpad Expert
고객 경험, 사용자 경험의 시대에 기업 내에서도 직무 역할에 따른 업무 흐름 중심의 사용자 경험을 설계하는 것은 ERP의 효과성과 효율성을 높이는 중요한 활동이다. 기존 ECC 프로젝트의 관행을 살펴보면 각 기능을 구현하는 프로그램 차원에서 화면 구성을 어떻게 하여 사용자가 필요한 data와 기능이 제공되게 할 것인지의 측면에서 UI를 설계하고 구현하여 왔다. 그러나 해당 사용자가 어떤 환경에서 어떤 업무 단계를 처리하기 위하여 어떤 사전 data를 확인해야 하고 어떻게 App을 사용해서 업무를 처리하는 것이 좋을지, 업무를 종료한 후에는 결과를 어떻게 확인하고 reporting 하는지에 대한 종합적인 고려/설계가 부족하였다. 이러한 활동이 프로세스 설계 초기 단계부터 수행되어야 한다.
누가 할 것인가? 기본적으로는 모듈 컨설턴트가 수행하는 것이 최적일 것이다. 프로세스, 데이터, 사용자 경험을 통합해서 고려할 수 있는 최적의 역할이기 때문이다. 그러나 아직은 모듈 컨설턴트들이 이 역할을 수행하기 위한 기술에 대한 이해도 부족하고 또한 아직까지 프로세스 설계 중심의 관행에서 벗어나지 못했기 때문에 누군가의 도움이 필요할 것이다.
SAP는 UX lead라는 역할이 프로젝트 팀에 구성되어 있어야 하고 이 역할이 모듈 컨설턴트와의 협업을 통하여 사용자 경험이 To-Be 설계의 한 축으로 자리 잡도록 권고하고 있다. 그렇다면 어떤 사람이 이 역할을 맡아야 할 것인가? 아직 최적의 후보군을 이야기하기 쉽지 않다. 차세대 ERP 프로젝트에 Web Designer나 Web 개발자들이 참여하여 일부 Web Program의 화면 설계나 CSS 적용 등을 담당해 오기는 했다. 하지만 이 역할들이 여기서 이야기하는 UX Lead의 역할을 수행하기는 어렵다. UX Lead는 기업의 직무 역할을 이해해야 하고 사용자들의 일하는 방식에 대한 통찰을 바탕으로 업무 흐름, 시스템 사용의 흐름, 화면의 구성 등에 대하여 방향을 정하고 모듈들과 논의할 수 있어야 한다. 이를 위하여는 기술적으로도 Fiori Design System, Fiori Launchpad, Embedded Analytics 등에 대한 이해도 필요하다.
적절한 후보군을 찾을 수 없다면 육성해야 할 것이다. 기존의 모듈 컨설턴트나 UX 관련 경험이 있는 후보군을 선택하여 프로젝트를 수행하면서 경험을 축적해 가야 할 것이다.
Fiori Launchpad 전문가도 필요하다. UX Lead가 이 역할을 수행할 수 도 있을 것이다. 다만 기술적인 요소가 필요한 업무는 고민이 필요하다. 통상 Web 프로그램은 사용자 성능을 위하여 다양한 변수 설정과 시스템 구조에 대한 고민이 필요하고 이러한 역할을 통상 Basis(BC) 컨설턴트의 역할 일 수 있다. 그러한 BC 컨설턴트 중에 Fiori Launchpad에 대한 경험을 가진 사람이 많지 않아 전담 BC를 두어야 할 수도 있으나 프로젝트 예산 등을 고려하면 현실적으로 그렇게 자원이 배치되지 않는다. 이렇게 되면 정말 필요한 역할에 공백이 생기게 되는 것이다. Fiori Launchpad의 기능적인 역할은 UX lead가 담당하고 기술적인 역할은 프로젝트 BC 혹은 전담 BC(part time이라도)를 확보하는 것이 필요하다.
2) Extensibility Specialist(표준 Enhancement)
S/4HANA에서는 Programming Model의 변화와 함께 다양한 기술을 기반으로 표준 이외의 사용자 요구 사항 대응을 Extensibility라는 용어로 정의하고 있다. 표준에 없는 기능을 새롭게 개발하는 추가 개발(Developer Extensibility)과 함께 표준의 기능을 S/4HANA 가 허용한 방법으로 확장(Enhancement)하는 것을 In-App Key User Extensiblity라고 명명하고 Extensiblity Model의 한 부분으로 구성하고 있다.
표준 확장은 In-App Key User Extensibility로만 수행할 수 있는 것은 아니다. Data Model, Backend logic, Frontend 화면 구성 등 다양한 영역에서 다양한 기술을 활용하여 표준을 수정하지 않고 표준을 확장하여 사용할 수 있는 방법을 제공하고 있고 이는 ECC와 비교하여 엄청나게 표준활용의 가능성을 넓혀 주고 있다.
기존 ECC에서도 모듈 컨설턴트들이 상당 부분 본인이 맡은 프로세스 내의 표준 확장 방법을 이해하고 찾아서 개발자와 함께 테스트해 보고 설계에 반영하여 왔다. 따라서 앞으로도 표준 확장 방법을 이해하고 탐색하여 설계에 반영하는 주요 임무는 모듈 컨설턴트가 수행하여야 할 것이다. 다만 아직 새로운 표준 확장 기술에 대한 이해가 정착되지 못한 상황에서는 전문적인 Guide와 지원을 수행할 수 있는 역할이 필요하다.
3) Embedded Analytics Specialist
실시간 운영 Reporting을 위하여 제공되고 있는 Embedded Analytics 기능을 활용하여 실시간 Reporint에 대한 설계가 필요하다고 주장했다. 물론 이는 회사 전체의 Data 전략에 기반한 Data Platform, Enterprise system의 Dataware 등 전사적 Data/BI 전략 하에서 수행되어야 한다.
이를 위해 운영 Reporting을 위한 설계자의 역할을 필요하다. 모듈 컨설턴트가 가장 훌륭하고 적절한 후보자일 것이다. 그러나 여기도 아직까지는 Skill의 문제가 있다. 따라서 초반기에는 전담 Expert가 Guide 하고 지원하는 체계로 프로젝트를 운영하는 것이 새로운 방식의 확산에 긍정적으로 작동할 것이다.
이 역할을 잘 수행할 수 있는 후보는 BW 컨설턴트이다. 기술적으로는 BW 기술의 상당 부분을 활용하고 있고 BW 컨설턴트들이 여러 모듈에 걸친 Data context를 이해하고 있기 때문이다. 또한 실시간 운영 Reporting과 Enterprise BI 관점의 설계의 균형을 맞추어 갈 수 있을 것이기 때문이다.
4) Fiori 개발 전문가: RAP ABAP 및 CDS 이해하는 UI5 기술 기반 Fiori Expert
Fiori 개발 전문가 그룹이 필요하다. 국내에 Fiori가 본격적으로 도입되기 시작한 것도 5~6년 정도 되었 다. 따라서 UI5 기술을 활용한 Fiori 개발자의 pool은 어느 정도 확보되어 있다고 볼 수 있다. 그러나 이 개발자들은 주로 Free Style UI5 App 개발 중심의 경험을 가지고 있다. Fiori Tool을 활용한 Fiori Element활용에 대하여는 부정적인 경험과 태도를 가지고 있는 것들을 경험했다. 이는 그동안 기술의 진화, 도입 과정에서의 시행착오와 좋지 않은 경험의 결과일 것이다.
또한 ABAP 개발자들이 Fiori 기술을 읽혀 영역을 확대한 그룹도 있다. 그러나 이들 그룹의 분위기도 유사하다. 그리고 그동안 Fiori 개발 방법도 몇 단계의 진화를 거쳐왔다. 초창기 SEGW 기반 Fiori App 개발이 현재 국내 Fiori 개발 경험자들의 대부분이 이해하는 방법인 것 같다. 그러나 그 후에도 BOPF 기반 App 개발을 거쳐 RAP기반 Fiori App 개발로 기술이 정착하기까지의 변화를 이해하고 준비된 개발자 그룹은 많지 않은 것 같다.
따라서 RAP 개발 모델을 이해하고 Fiori tool 기반의 Fiori Element App 개발을 수행할 수 있는 개발자 그룹을 확보하는 것이 중요하다. 이를 위한 선도 개발자 그룹을 구성하여 활용하는 것을 적극 검토해 볼 필요가 있다.
5) RAP ABAP Expert: CDS 기반 RAP model 개발 Expert
S/4HANA에서는 사용자의 기본 UI/UX를 Web 기반의 Fiori로 전략적으로 선택하면서 Web programming에 최적화된 새로운 ABAP 및 Programming Model을 정립하였다. Clean Core ABAP 개발을 위해서도 이 새로운 ABAP은 아주 중요한 역할을 할 것이다.
기존 ABAP에서 OO 기반 Programing 위주로 경험을 축적한 개발자라면 새로운 개념과 Syntax의 Programming model과 ABAP은 그렇게 어려운 기술 습득 과정을 필요치 않을 것이다. CDS를 생성하기 위한 DDl/DCL 등의 문법과 Code Push Down을 위한 New Open SQL, AMDP 및 Business Object를 처리할 수 있는 EML(Entity Manifuration Language) 등 신규 기능에 대한 이해가 필요하다.
초기에는 이를 Guide 하고 지원할 수 있는 Core 개발자 그룹의 운영도 생각해 볼 수 있다.
3. 표준 활용 최대화를 위한 UI/UX Action
3.1 UI/UX 계획 수립
전사의 Design 경영팀, 혹은 전사 시스템 디자인 관련 팀, 혹은 차세대 ERP 팀 내의 디자인 관련 전략 수립 및 실행을 담당하는 역할을 통하여 차세대 ERP의 UI/UX 전략이 전사 디자인 경영과 고객/사용자 경험관리 측면에서 수립되어야 한다. 앞에서 이야기한 UX lead가 차세대 ERP 관점에서의 UI/UX 설계와 실행의 중심 역할을 해야 할 것이다.
전사의 UI/UX 전략에 기초하여 차세대 ERP의 UI/UX 계획을 수립하고 기본 개념을 설계하고 전체 프로젝트 요원들에게 Guide 하는 역할을 수행해야 한다.
기술적으로는 Fiori Launchpad를 설정하고 이를 최적화하여 성능상의 이슈를 방지하여 프로젝트 수행 팀 차원에서부터 신기술 도입에 따른 부담을 줄이고 부정적 분위기를 줄이기 위하여 노력해야 한다. 전담 Fiori Launchpad 전문가 혹은 BC 컨설턴트가 이러한 기술적 환경을 조성해야 하고 Fiori Launchpad Designer 등의 Firio Launchpad Tool을 활용하여 프로젝트 수행 환경을 조성해야 한다.
이와 함께 Fiori Launchpad 전문가 혹은 UX Lead 주도하에 사용자(이 단계에서는 프로젝트 수행자)의 경험 강화를 위한 공통의 기능에 대한 계획 수립 및 설정도 수행되어야 한다. 전체적인 기능 및 App 간의 navigation 전략, Page 및 Space 등 사용자가 접하게 될 메뉴 구성 체계, Fiori Launchpad의 강력한 기능이자 ERP 사용 경험을 강화시켜 줄 Enterprise Search 활용 및 설정 전략, Fiori Launchad상에서의 App 및 프로세스/기능에 대한 Help 제공 전략, 사용자와 ERP 시스템과의 상호 소통을 위한 Notification 설정 및 활용 전략 등을 수립하고 실행해 나가야 한다.
3.2 Adapting UI
이러한 사용자 경험 강화를 위한 UI/UX 전략하의 각종 계획들이 준비되고 제반 환경이 갖추어지면 각 프로젝트 단계에서 이의 실행을 위한 노력들이 각 업무/기능/프로세스 영역에서 수행되어야 한다. UX Lead는 전 과정에서 계획 대로 실행되도록 조율하고 지원해야 한다.
기본적인 활동은 표준 Fiori App을 사용자들이 업무에 쉽게 활용하도록 Adapt 하는 것이다. 가장 쉬운 방법은 UI Personalization 기능의 활용 준비이다. 이는 시스템이 가동된 후 최종 사용자들이 직접 각자의 상황에 필요한 화면의 구성을 지원하는 방법이다. 따라서 표준 화면을 조정하는 방법이 아주 강력하지는 않지만 여러 가지 조정은 가능하다. 프로젝트팀은 이를 숙지하고 사용자들이 이를 활용할 수 있도록 교육하고 지원할 체계를 준비해야 것이다.
Personalization이 최종 사용자 수준에서의 화면 Adapt 방법이라면 프로젝트 수행자(컨설턴트, PI 요원 등)들이 최종 사용자들을 위하여 표준 화면을 Adap 하여 제공할 수 있도록 하는 도구가 Adapt UI라는 기능이다. 이는 Key User(컨설턴트, PI 요원)들에게 필요한 Role/권한이 부여되어야 쓸 수 있는 기능으로 Fiori Launchpad의 User Action에서 실행할 수 있다.
이를 통하여 화면 필드의 추가/삭제/이동, 필드 그룹의 추가 삭제/이동, 표준 Tab 화면(Section)의 추가/삭제/이동, 필드/필드그룹/Tab의 이름(Label) 변경, 필드를 합쳐서 하나의 필드로 표시, 신규 테이블 필터 및 Variant 추가, App Variant 추가 저장, 외부 Content 추가 등의 다양한 화면 단위의 조정이 가능하다. 당연히 이러한 조정은 표준 수정은 아니다.
Fiori App과 함께 WebGUI(SAP GUI for HTML) App도 Web UI/UX 전략에 있어서 중요한 부분이다. 더욱이 지금처럼 기술의 변혁 과정 속에서 기존 개발된 전통적 GUI 화면들을 Web 환경에서 활용할 수 있게 해주는 기능은 모든 과거 투자를 한꺼번에 Fiori로 전환해야 하는 부담을 줄여준다.
이러한 전통적인 WebGUI app을 활용해야 하고 이 화면이 사용자 요구에 부합하지 않으면 이를 해결할 수 있는 도구로 Screen Persona라는 도구를 제공한다. WebGUI는 Windows GUI를 Web에서 활용할 수 있도록 해 주는 방법이어서 Windows GUI의 전통적 특징들을 그대로 가지고 있기 때문에 화면 구성이 복잡하고 여러 화면 단계를 거쳐야 단위 업무를 처리할 수 있는 등의 불편함이 있다. Screen Persona을 통하여 이러한 이슈를 해결할 수 있다. 이 기능은 전에는 별도의 license로 제공되었으나 이제는 S/4HANA의 기본 기능으로 포함되어 제공된다.
프로젝트 팀에서는 UX Lead 중심으로 프로세스 설계자(컨설턴트, PI요원)들이 이러한 표준 화면 Adapt 방법들을 숙지하고 활용할 있도록 필요한 Guide를 만들고 교육 기회를 제공해야 할 것이다. Screen Persona 같이 특정의 기술과 경험이 필요한 경우에는 프로세스 설계자들의 부담을 줄여주기 위하여 전담자를 배치하는 것도 도움이 될 수 있다.
3.3 In-App Key User Extensibility를 이용한 표준 확장
단순히 표준 화면을 사용자의 요구에 부합하도록 Adapt 하는 수준을 넘어서는 표준에 없는 필드와 로직을 추가하거나, 없는 Tap(Section) 화면을 추가하거나, 추가 기능을 수행하는 Action button을 추가하는 등의 기능/화면 보완 요구는 In-App Key User Extensibility 도구를 활용하여 해결할 수 있다.
필드와 로직을 추가할 수 있도록 주는 Custom Field & Logic App, 새로운 App을 만들 수 있는 기본 Object를 생성할 있도록 해주는 Custom Business Object App, CDS view를 추가할 수 있도록 해주는 Custom CDS View App, Analytics App을 만들 수 있도록 해주는 Custom Analytica Query App 등 다양한 In-App Key User Extensibility 기능들을 활용할 수 있도록 컨설턴트와 PI 요원들에게 Guide를 제공하고 교육 기회를 제공하여 적극 활용할 수 있도록 해야 한다.
3.4 Developer Extensibility & 도구를 활용한 표준 Fiori App Enhancement
전문적인 Coding 기술 없이 표준을 확장(Enhancement)할 수 있는 이러한 방법으로 해결할 수 없는 복잡한 사용자 요구사항은 개발자 도구를 활용할 수 있는 다양한 방법이 있다. UI/UX 관점에 국한해서 보더라도 UI5 Flexibility라는 기능을 통하여 표준 화면에 다양한 확장을 제공하는 Adaptation Project라는 방법을 사용할 수 있다.
이러한 다양한 방법들에 대하여 Guide를 준비하고 컨설턴트들이 이해할 수 있도록 하여 사용자 요구의 Gap 발생 시 완전한 Custom 개발 대신 표준을 확장할 수 있는 방법을 선택하여 개발을 줄이고 표준 활용을 늘일 수 있도록 해야 할 것이다.
UI/UX를 포함한 개발자 도구를 활용한 다양한 표준 확장(enhancement) 방법에 대하여는 이후 상세히 다루도록 하겠다.
4. 표준 활용 최대화 및 Data Driven을 위한 Embedded Analytic Action
Embedded Analytics는 Transaction처리와 실시간 Operational reporting 및 Analytics를 위한 S/4하나의 전략적 선택이라고 설명한 바 있다. 따라서 이 기능을 적극 활용하여 ERP의 역할을 단순 거래 기록용이 아니라 실무 책임자들이 각 업무의 최고 산출물을 만들어 내기 위하여 데이터에 기반하여 업무를 처리하고 분석하는 형태로 일하는 방식의 변화를 유도해 나갈 수 있을 것으로 생각한다.
이러한 Data Driven Operational Decision Making에서의 적극적 활용에 대하여는 계속 이야기해 왔기 때문에 표준 활용을 최대화하고 Reporting 프로그램의 추가 개발을 줄이는 도구로서의 활용에 대하여 강조해 보고자 한다.
지금까지의 SAP ERP 프로젝트를 보면 정말 많은 수의 추가 개발이 이루어져 왔다. 각 기업의 차별적 경쟁력을 위한 핵심 프로세스/데이터 처리를 위한 것도 물론 다수일 것이다. 그러나 해외의 많은 기업들과 비교해 봤다 한국 기업들의 추가 개발 건수는 거의 10배에 달한다는 것이 관찰의 결과이다. 이렇게 개발이 많은 이유는 많은 경우 사용자의 일하는 방법과 스타일을 맞추기 위하여 표준에 있는 유사한 기능을 사용하지 않고 이를 재구성하여 개발 사용하는 것 때문인 것도 한 가지이다. 이 경우 표준 프로그램은 개발 프로그램 속에 포함되어 처리되고 사용자는 재구성된 UI를 통하여 업무를 처리하게 된다.
이럴 때 많이 사용하는 방식 중의 하나가 ALV를 사용하여해야 할 일의 목록을 보여 주고 여기에서 여러 가지 가 기능들이 처리토록 메뉴나 아이콘으로 기능을 구현하는 경우이다. 즉 Worklist 혹은 Due list 형태의 리스트 형태의 리포트이다. 물론 표준에도 유사한 기능이 대개는 있으나 리스트 되는 데이터의 양(특히 추가 필드 등)이 적거나 후속 업무와 연결하는 기능들이 부족한 경우가 많아 재구성하여 추가 개발하게 된 경우가 많았다.
이러한 Transaction 처리를 위하여 필요한 대상을 나열하고 찾고 해당 건에 대하여 처리를 위한 필요한 관련 데이터를 확인하고 이를 바탕으로 거래 처리하거나 후속 업무를 진행하는 형태의 기능 구현은 S/4HANA에서는 많은 경우 Embedded Analytics 기능과 결합된 Fiori Element App을 활용할 수 있다. 표준 App들이 이렇게 구현되어 있는 경우가 많다. 물론 필요 데이터의 부족, 연계된 기능의 부족 등이 있을 수 있으나 다양한 표준 확장(Enhancement) 방법을 제공하고 있기 때문에 이를 적절히 활용하면 추가 개발하지 않고도 표준 기능의 활용도를 높일 수 있을 것이다.
1) List Report나 Anlaytical List Report, Worklist 등의 Fiori Element App들이 검토될 수 있다.
2) Embedded Analytics 전용 App들인 KPI & Report, Multidimensional Report, Analytical Path Framework App 들을 적극 활용할 수 있다.
3) 이러한 App들의 데이터, 기능이 부족할 경우에는 표준 CDS View를 확장하거나 Custome CDS View를 만들어서 연결하여 보완할 수 있다. 기능은 Enhancement 방법들을 활용하여 보완할 수 있다.
4) 표준 Embedded Analytics App들이 부족할 경우에는 Customm Analytical Query를 만들어 새로운 App을 만들어서 사용자에게 제공할 수 있다.
5. S/4HANA 표준 확장 기법의 적극 활용을 통한 Gap 대응 및 최소화
설계 단계에서 프로토타이핑이라는 과정을 통하여 사용자의 요구가 S/4HANA 표준 기능으로 얼마나 어떻게 충족되고 사용자의 요구를 어떤 형태로 변형하여 있는 기능을 사용하게 만들지, 혹은 Gap이라고 인식되는 부분을 어떤 방법을 통하여 해결할지 대안을 탐색하는 과정을 거치게 된다.
아무리 표준 활용을 목표로 하더라도 S/4HANA의 기능이 개별 기업, 모든 사용자의 요구를 충족시키는 것은 불가능하고 Gap이 발생하는 영역이 생길 수밖에 없다. 이러한 Gap은 단위 업무 영역/시스템 수준, 단위 기능 수준, 단위 업무 로직, 화면 구성 등 다양한 형태로 나타난다.
표준 S/4HANA가 대부분의 기능을 충족하지만 일부 데이터 항목, 일부 로직, 화면의 구성과 표현되는 방식 등이 부족한 경우에는 적극적으로 표준 확장(Enhancement)을 통한 표준 기능의 보완을 통하여 표준을 활용할 수 있도록 노력해야 한다.
이러한 노력은 기존 프로젝트에서도 어느 정도 정착된 것이기도 하다. 그러나 S/4HANA의 도입과 함께 이전 버전의 ERP보다 훨씬 다양한 표준 보완 방법이 도입되었기 때문에 이러한 방법들을 숙지하고 범위를 확대할 필요가 있다.
먼저 표준 확장의 정책을 수립하고 정책에 반영하기로 한 방법들을 정리하여 프로젝트팀과 공유해야 한다. 기존 버전에는 표준 확장 방법(User Exit, Customer Exit, Classic BAdi, BAdi) 통하여 메뉴 exit, Screen Exit, 기능 Exit 등 여러 경우에 적용하여 왔다.
S/4HANA 도입과 함께 새로운 Extensibility 체계의 도입과 함께 보다 광범위한 표준 확장 방법과 기술이 소개되었고 BAdi를 제외한 기존 표준 확장 방법의 대부분은 S/4HANA에서는 Clean Core 지향을 위해 권고하지 않는 방식으로 분류되었다. 따라서 새로운 Extensibility 방법과 함께 기존 방법을 어디까지 프로젝트에서 적용할 것인지에 정책을 세우고 guide 해야 한다.
새로운 Extensibility에서는 CDS를 통한 데이터 확장, BAdi를 통한 기능 확장, Fiori UI5 Flexibility의 Adaptation Project를 통한 UI 확장이 핵심일 텐데 모든 프로세스 설계자, 개발자들을 위한 지침과 Guide가 필요할 것이고 새로운 기술에 익숙해지기 전까지는 소수의 전담팀 혹은 지원팀을 운영하는 것도 검토해 볼 수 있다.
Extensibility 모델의 적용에 있어서도 개발자 수준의 표준 확장도 준비해야 하지만 설계 단계에서는 특히 Key User(컨설턴트, PI요원)의 표준 확장 도구인 In-App Key User Extensibility 도구에 대한 교육과 적용을 적극 권장하고 지원해야 한다.
마지막으로 기존 개발 유형 분류 체계인 WRICEF관점에서 각 개발 유형별 개발 정책을 재검토하고 권고하는 기술로 Clean Core에 부합하는 개발이 되도록 해야 한다. 데이터, 기능, UI의 차이에 의한 Gap 대응에 표준 활용을 늘이는 것도 중요하지만 이러한 WRICEF에서의 표준적인 방법을 적용하는 것도 역시 중요하다. 이는 아래에서 좀 더 구체적으로 살펴보겠다.
6. Clean Core 개발을 위한 Gap 대응 설계(개발 Option 탐색 및 설계)
표준 활용을 아무리 늘이더라도 차별적 경쟁력을 위하여 꼭 필요한 추가 개발은 발생할 수밖에 없다. 꼭 필요한 것만 추가 개발하여 전체적인 개발 건수를 줄여 보자는 것이다. 이렇게 추가 개발을 하는 상황에서도 향후 유연한 업무 대응과 Upgrade 유연성 확보를 위한 Clean Core 지향 개발을 중요하다.
이를 위해서는 개발 표준 및 정책 수립 단계에서 이러한 지향점을 기반으로 새로운 기술의 적용을 포함한 표준이 정립되어야 한다.
6.1 Extension 유형별 Clean Core 원칙 정립 - WRICEF 정책 포함
데이터, 기능, UI Gap 대응을 위한 표준 확장 및 추가 개발뿐만 아니라 여러 유형의 개발에 대한 기술 표준 정책을 수립해야 한다. Workflow, I/F, Conversion, Form 등은 gap이 아니라 반드시 발생하는 유형의 개발이고 줄일 수 없는 것이다. 각 영역에 있어서도 기술적 변화가 많이 있기 때문에 미래 지향, Clean Core 지향의 기술 표준 정립이 필요하다.
[그림 3- 6] WRICEF - Traditional and Modern Technologies(참조: Custom Extensions in SAP S/4HANA Implementations - A Practical Guide for Senior IT Leadership)
6.2 신기술 표준 및 적용 정책, Guide 준비
다양한 신기술 활용에 대한 정책과 표준 및 실행을 위한 Guide 가 준비되어야 한다. 각각의 기술 요소에 대하여는 이후 자세하게 다루겠다. 중요한 것은 이러한 기술들이 기존의 기술 기반을 계승하고 혁신하여 새로운 S/4HANA의 비전을 달성하기 위한 새로운 플랫폼을 구성하고 있다. 이를 체계적으로 이해하고 적용할 수 있는 준비가 전체 프로젝트 요원들에게 될 수 있도록 준비하는 것이 중요하다.
1) CDS 기반의 Fiori App 개발을 위한 S/4HANA의 차세대 개발 방법인 RAP(ABAP RESTful Programming Model)
RAP는 CDS기반, Fiori App 등의 개발에 최적화된 SAP의 차세대 ABAP Programming 모델이다. RAP를 구성하는 Building Block은 CDS, moderned & extended ABAP 언어, Stateless Web 프로그램 개발을 위한 OData protocol, Transaction App 개발을 위한 Business Object(BO) 개념, 서비스를 정의하기 위한 Business Service 개념 등이다. 이에 대하여는 이후 자세히 다루겠다.
[그림 3-7] RAP Overview2) RAP 내 핵심중의 하나인 ABAP Cloud
RAP를 구성하고 있는 주요 요소 중 하나인 프로그램 언어로서의 ABAP Cloud는 Clean Core 개발을 지향하는 Cloud Ready 개발 도구의 핵심으로 기존 ABAP에 여러 가지 새로운 Syntax와 개념, 도구들이 포함되어 있다.
[그림 3-7] ABAP Cloud에서의 주요 변화3) CDS View의 설계 원칙 및 Guide
CDS는 HANA DB의 장점을 활용하기 위한 S/4HANA의 데이터 모델링 Framework으로 Code Push Down 개발 지향을 위한 가장 유용한 도구이며 S/4HANA 표준 데이터 모델(VDM: Virtual Data Model)을 구성하는 핵심 개념, 기술이다.
[그림 3-8] ABAP CDS View Entiry 예시(참조 : https://www.sap.com/documents/2022/01/96489f20-157e-0010-bca6-c68f7e60039b.html)
4) Fiori Element, Fiori tool, Fori Adapatation Project 등 UI/UX 관련 기술 표준 및 Guide
Fiori App은 이제 국내 시장에서도 어느 정도의 경험과 역량이 축적된 기술이 되어 가고 있다고 보인다. 하지만 지금까지는 주로 HTMP5 기반 SAP 기술인 UI5로 Free Style Fiori App을 개발하는 것이 대세인 것 같고 이는 사용자 요구에 부합하는 최적의 UI를 만들 수는 있지만 개발 비용은 증가하게 만들고 있다. S/4HANA는 일관된 사용자 경험과 개발 생산성 등을 제공하기 위하여 Fiori Element, Fioir Tool 등 다양한 기술과 표준 Fioi App을 확장할 수 있는 도구인 Adaptation Project 수행을 위한 Visual editor 등 다양한 기능을 제공한다. 그러나 아직까지는 이러한 도구를 본격적으로 활용한 개발은 현장에 정착되지 않은 것 같다. 따라서 이러한 기술과 도구를 통하여 개발 생산성과 일관된 사용자 경험을 위한 개발 표준과 Guide를 제공하는 것이 중요하다.
[그림 3-9] Fiori Tool을 활용한 Fiori App 개발 프로세스5) ADT, BAS 등 개발 도구
새로운 기술들을 위한 새로운 개발자 도구들도 소개되고 있으므로 이러한 도구에 빨리 익숙해지도록 하는 것이 중요하다. ABAP 개발자들은 기존의 GUI 환경의 개발 도구와 새로운 개발 도구인 Eclipse 기반의 ADT(ABAP Development Tool)을 현재는 같이 쓸 수 있지만 일정 기능(예를 들어 CDS의 개발)은 ADT에서만 가능하다.
[그림 3-10] ADT에서의 View 개발 예시또한 Fiori App 개발자들은 지금까지 주로 SAP Web IDE를 사용해 왔으나 BTP상의 Business Application Studio 혹은 VS Code의 plug-in을 사용하여 Fiori Element 포함 Fioi App을 개발할 수 있다.
[그림 3-11] BTP 상의 Business Application Studio를 활용한 Fiori Tool 활용 Fiori App 개발 예시6.3 Embedded Steampunk 기반 On-Stack Developer Extensibility를 통한 개발 분리
Clean Core 차세대 ERP 구축에 필수적인 사항은 아니지만 적극적 검토 고려한 필요한 것이 Steampunk 혹은 Embedded Steampunk 관련 정책과 기술의 도입 여부이다. 기술적인 내용에 대하여는 이후 자세히 다루겠지만 SAP가 S/4HANA의 SaaS 버전들을 만들면서 Cloud ready, Upgrade Free Extension을 중요한 기술적 지향점으로 삼고 있고 On-Presmise S/4HANA에서도 필수는 아니지만 권고 사항으로 이들 기술들을 적용할 것을 권하고 있다.
기본적으로는 개발 분리를 통하여 Core S/4HANA ERP를 Custom Extension 프로그램들과 분리하여 필요할 경우 upgrade 적용이 가능하도록 하자는 것으로 첫 번째 시도는 BTP(Business Technology Platform)에서 다양한 개발 도구 및 Digita 도구들을 활용하여 Custom Extension을 할 수 있게 하였다. 그러나 많은 고객들이 S/4HANA의 Extension은 ABAP으로 해왔고 하고 싶어 하기 때문에 BPT에서도 ABAP platform이 가능한 제품을 만들었고 그 프로젝트 이름이 Steampunk라 그렇게 불리고 있다.
그러나 물리적으로 분리된 BTP상에서의 개발은 S/4HANA와의 integration 강도 등 여러 고려 요소들 때문에 S/4HANA와의 데이터 및 기능 상의 통합성이 적은 단위 독립 Appliation, 혹은 파트너 솔루션의 개발에 적절하다는 권고을 내놓았다.
많은 고객들이 S/4HANA 데이터, 기능, UI와 연계된 Custom Extension이 필요하게 되어 Steampunk가 적절한 대응이 되기에는 충분치 않다고 판단한 SAP는 이 Steampunk 기능/솔루션을 SaaS Public S/4HANA에 먼저 Embedded 시켰고 2022년도 10월에는 S/4HANA On-Premise 버전에도 포함시켜 출시하였다.
원래 물리적 개발의 분리라는 개념에서 시작했기 때문에 Embedded 시킨 것이 어떤 의미를 갖게 될 지에 대하여는 다양한 평가가 가능하겠지만 기존의 Custom Package 혹은 Custom namespace(Z으로 시작하는 개발 Object 생성/관리) 같은 개발 분리 방법보다 강화된 구분 관리 방법과 다양한 Code Clean을 위한 개발자 권한/역할 관리, Systax 체크 등의 ABAP의 기능 추가 등을 통하여 On-Premise에서도 의미 있게 Clean Core에 적용할 수 있는 가능성이 증대되었다는 것은 장점으로 활용될 수 있을 것 같다.
Embedded Steampunk 기반 Developer Exensibility를 도입하게 되면 이 개발을 담당하는 ABAP 개발자는 Clean Core를 지향하기 위한 여러 가지 제약하에 프로그램을 개발해야 한다. 따라서 기존의 Classic ABAP 없이 이 방법만으로 Custom Extension을 할 수 있을지는 평가가 필요하다.
Green Field구축의 경우에는 훨씬 가능성이 높겠지만 기존에 수많은 Classic ABAP으로 개발된 프로그램들을 이관하여 활용하고 싶은 Grown Field 구축의 경우에는 전적으로 Embedded Steampunk 상에서의 Developer Extensibility 만으로 Custom Extension을 수행하는 것은 상당한 추가 비용을 수반해야 할 것이다.
그러나 미래를 위한 차세대 구축에서 새로운 기술 기반의 시스템 구축이라는 비전을 가지고 이러한 Risk와 비용을 감당하겠다고 하는 고객들도 있을 수 있다. 이러한 경우에도 개발자들의 역할을 Classic ABAP과 Developer Extensibility상의 ABAP Cloud 개발로 어떻게 나누고 어떻게 기존 프로그램들을 Migraton 해 갈 것인지 등에 대한 정교한 정책과 기술적 준비가 필요하다. 향후 상세히 다루도록 하고 여기서는 SAP가 제시한 개괄적인 개념만 제시하도록 하겠다.
[그림 3-12] Clean Core 개발을 위한 3 tier 개발 전략
6.4 Release 되지 않는 기술 요소 재활용에 대한 대안 수행
ABAP Cloud 언어 기반 Embedded Steampunk에서의 Developer Extensibility의 Upgrade free 개발의 핵심 생각 중의 하나는 Released 된 S/4HANA의 Object 만을 추가 개발에 재사용하라는 것이다. 기존에 추가개발을 진행하면서 고객들이 SAP의 다양한 표준 Object들을 custom 개발에 재사용했었다. SAP사용의 장점이기도 하고 생산성을 높여주기도 하였다.
그러나 이러한 방식은 SAP가 제품의 기능을 개선하여 Verion을 높여갈 때 생길 수 있는 표준 Object들의 변화 때문에 Upgrade시에 문제를 만들었다. 이러한 과거 경험을 극복하기 위하여 SAP는 Released 된 Object들만을 사용하도록 강력하고 권고하고 있다.
그러나 아직 필요한 모든 표준 Object들이 충분히 새로운 버전에서 released 되었다고 보기 어렵고 모든 표준 Object들을 release 하기도 어려울 것이기 때문에 한계가 있을 수 있다. 이러한 한계를 극복하기 위하여 Workaround를 제공하기 있기 때문에 이러한 방식을 사용하여 임시적인 대안을 찾고 SAP가 향후 해당 Object를 release 하게 되면 교체해 나가는 전략을 택할 수도 있다. 어쨌든 release 되지 않은 Object를 사용한 경우를 관리할 수 있는 방법은 될 것이다.
6.5 Classic ABAP 개발 최소화 및 최소한의 Clean Core 원칙 수립 적용
기존 투자에 의해 확보한 다량의 기존 프로그램들을 재활용하기 위해서도 그렇고 ABAP Cloud의 clean core 개발 방법에서의 제약에 의해서도 그렇고, 시장의 개발자 조달 상황 등 기술 외적인 요수들 때문이라도 상당 기간 동안에는 Classic ABAP를 병행하여 사용할 수밖에 없을 것이다. 이러한 경우에도 가능한 최대한 clean core 개발 원칙을 수립하고 적용하는 것이 유용할 것이다.
예를 들면 다음과 같이 항목들이 검토 대상이 될 수 있을 것이다.
- DB table 직접 Access 금지 및 CDS 기반 데이터 설계/활용
- Call Screen, Call Transaction 같은 전통적 GUI 전용 Syntax 사용 제한
- BDC program 사용 지양
- BAPI Function 대신 Business Object interface 사용
- User Exit, Customer Exit, Classic BAdi 사용 지양, New BAdi 만 사용
- ALV Program 지양, Embedded Analytics Report 혹은 Fiori Table UI Element 활용
- Flexible Workflow 등 검토
- API 기반 Interface 표준 사용
- BDC, LSWM 지양 Conversion Cockpit 활용
- Adobe 등 새로운 Form 개발 도구 활용 등
6.6 기존 ABAP 프로그램의 Clean Core Migration 강화
기존 ABAP 프로그램을 Clean Core 지향에 부합하도록 Migration 해 나가는 것도 중요한 활동이 될 것이다. 단순히 Migration을 위해서라도 HANA DB에 최적환된 점검과 수정이 필요한 systax들이 있고 이 작업은 필수적인 활동이 될 것이다.
그러나 이러한 필수적인 Migration 점검/수행 이외에도 다양한 Clean Core를 위한 기술을 적용할 계획을 수립하고 적용하는 것이 필요하다.
