SAP S/4HANA: 정교한 설계에 기반한 선별적이면서 간결한 스마트한 접근

Labs_Coloured_blocks
 


596790_KR_How_did_we_get_to_this_technical_and_functional_split-__

당사는 SAP® HANA®와 그 이후 S/4HANA®에 대해 오랫동안 다루어왔습니다.

최초로 2010년에 HANA가 출시되었습니다.

HANA 데이터베이스는 혁신적인 첫걸음으로 2010년에 등장하였습니다. SAP 는 ERP 시스템을 위해 존재하는 방대한 데이터를 인식하였으며, SAP는 보다 현대적인 ERP 애플리케이션 환경을 지원할 수 있는 기술 플랫폼에 집중적으로 투자하였으며, 이 플랫폼은 점점 더 복잡해지고 디지털화되며 연결된 업무로 인해 빠른 처리를 요구하는 현대 비즈니스를 충족시킬 수 있는 ERP 환경을 마련하게 되었습니다. 오늘날 비즈니스는 수십억 줄의 데이터를 사용하면서 운영되고 있습니다.

이렇게 해서 HANA와 관련된 논의는 처음에 기술적, 데이터베이스적인 것으로 시작되었습니다. S/4HANA가 2015년에 출시되었을 때, 사람들의 인식에는 이미 이러한 생각이 자리잡고 있었습니다. HANA로 전환하면 리소스와 시간 비용을 절약할 수 있으며, HANA 데이터베이스의 성능을 활용하여 비즈니스 효율성과 반응성을 높일 수 있습니다. 그러나 HANA는 고성능이었지만 고가의 시스템이었기 때문에 비용 대비 효과를 얻을 수 있는 경우에만 도입되었습니다. S/4HANA 라이선스도 추가 비용이 드는 일이 었기 때문에 논의는 혼란스러워졌습니다.

  • 새로운 프로세스를 HANA에서 실행할것인지?
  • 아니면, 아주 빠른 실행속도로 기존 프로세스를 반으로 줄일 수 있는 일에만 필요로 하여 사용할 것인지?

고성능이지만 비용이 많이 드는 데이터베이스는 데이터 저장 위치를 어디에 두어야 하는지와 같은 분석 트렌드를 증가시키기 시작했습니다.

  • 고성능 애플리케이션 내에서 저장해야 할 데이터와 분석에만 참조하거나 사용할 데이터는 무엇인가?
  • HANA에서 테스트 및 개발 환경으로 데이터 복제하는 데 드는 비용은 얼마나 되는가?

우리는 이제 13년이 지나고 나서도 여전히 많은 고객들이 HANA 또는 S/4HANA로 전환하지 않았음을 알 수 있습니다. 그들은 여전히 ORACLE, MySQL, DB2/6 및 Sybase ASE 데이터베이스(SAP가 인수한 IQ 등 기술을 포함한 임시 기술)를 사용하고 있습니다.

또한, HANA 및 S/4HANA로 전환한 SAP 유저고객도 많지만, 전체 고객의 약 80%가 아직 이동하지 않았습니다.

많은 사람들의 마음에 두 가지가 있었습니다:

  • 첫째, 더 복잡한 비즈니스의 요구가 없다면, HANA에 투자할 만한 가치가 없다는 것이었습니다.
  • 둘째, 이제 ERP 시스템에 20-45년 동안 데이터를 보유하게 된 회사들은(30년 전은 1994년이며, SAP는 1972년에 설립되었기 때문에, 가끔 1970년대까지 거슬러 올라가는 데이터를 시스템에서 발견할 수 있습니다) 모든 데이터를 HANA 데이터베이스에 저장할 필요가 없다는 것을 깨달았습니다. 이는 신중한 계획이 필요한 결정임이 분명했습니다.
따라서, 우리들은 데이터베이스와 그 이점, 거대한 규모의 기술 및 데이터, 조합가능한 ERP와 Clean Core 에 대한 큰 논의를 벌였습니다. 새로운 비즈니스 프로세스는 가능했지만, SAP가 그것을 만들어 주기 때문에 가능했던 것이 아니라, 비즈니스 프로세스를 가능하게 하는 이전에 없던 새로운 플랫폼을 제공했기 때문에 가능했습니다. 이것은 주로 ECC 뒤에 있는 ERP 플랫폼의 성능에 대한 IT 부서의 고려 사항이었습니다.

…그리고 2015년에 S/4HANA 등장

HANA가 출시된 지 5년 후인 2015년에 SAP는 새로운 ERP 플랫폼인 SAP S/4HANA를 출시하여 R/3와 NetWeaver를 완전히 대체하려 했습니다. 하지만 R/2에서 R/3로의 전환과는 달리, 완전히 새로운 시스템은 아니었습니다. ABAP 코드 코어는 여전히 남아 있었고, 클라이언트/서버 모델도 여전히 존재했습니다(더 많은 클라우드 연결이 있었음에도 불구하고). 업그레이드는 주로 Central Finance(통합 재무 운영)을 변경했습니다(그리고 CFIN은 ECC에서도 설치할 수 있다는 점이 주목할 만합니다).

이 시점에서 S/4HANA는 Finance Core 을 변혁했지만, 항상 통합되어 있던 다른 운영들(공급업체 및 조달, 공급망, 대형 고객 관계 시스템 등)은 다른 기술로 이전되기 시작했습니다. SAP는 외부 회사를 인수하고 HANA 기반을 활용할 기회를 모색했습니다. 그러나 기술이 깊이 있게 통합되지 못했고, SuccessFactors(새로운 HCM이지만 급여 기능이 없었음), C4C(새로운 CRM이지만 HubSpot이나 Salesforce는 아니었음), Ariba 등을 구매한 고객들은 한 회사의 라이선스 구조 안에 속해 있지만, 실제로는 하나의 기술이 아닌 조립형 모델로 전환하는 데 큰 어려움을 겪었습니다. 이는 모두 HANA 기반의 기술도 아니었고, 확실히 통합된 시스템도 아니었습니다.

결국 메시지는 혼란스러웠습니다. 그러나 BTP와 함께 S/4HANA를 Clean Core 로 전환하고, 점진적으로 인수한 클라우드 기능과 경쟁사들의 최고 기술과 맞추기 위해 DevOps 클라우드 모델로 이동하는 로드맵을 통해, SAP는 기술을 최대한 활용할 수 있는 방향으로 나아가고 있습니다.

596790_KR_Every_S-4HANA_project_should_be_selective_with_data__

S/4HANA로 전환할 때 사람들이 고려하는 다양한 ‘field’ 접근 방식은 다양하게 논의되지만, 대부분은 꽤 간단합니다. Greenfield 또는 Brownfield, 그리고 선택적인 프로세스 전환입니다. 오랜 기간 업계에서 논의하여 대부분의 사람들이 이제 알다시피, 두 가지 기본 경로는 다음과 같습니다:

  • 그린필드(Greenfield): 완전히 새로운 시스템과 프로세스로 시작 – 과거 데이터 없이 마스터 데이터와 ERP를 완전히 재설계하는 데 필요한 주요 정보만 포함. 즉, 급진적으로 변화를 시도하는 것입니다.
  • 브라운필드(Brownfield): 데이터를 포함한 과거 데이터를 유지하며, 새로운 플랫폼에서 점진적으로 변화를 구현하는 방식입니다.

그리고 여기서 EPI-USE Labs의 우리의 전문성이 드러납니다. 사람들은 종종 Greenfield가 과거 데이터를 포함하지 않으며, Brownfield 는 모든 데이터를 포함한다고 생각하지만, 이는 사실이 아닙니다.

SAP는 선택적 데이터 전환(Selective Data Transitions, SDT)과 변환된 시스템 환경(LT / SAP LT / SLO / SLT)에 대해 오랫동안 이야기해 왔습니다. 고객들이 S/4HANA 도입과 관련된 데이터에 대한 우려를 분리할 수 있도록 것이 충분히 가능합니다. 이는 결국 S/4HANA로의 이동 방식과 상관없이 모든 전환이 선별적일 수 있음을 의미합니다. 이는 투자 수익을 극대화하고 2010년부터 비용적 측면에서 논란이 많았던 고성능 데이터베이스의 효율적인 활용을 보장하는 데 중요한 요소입니다.

596790_KR_SDT_Approach_Updated_V5

그럼 어디서 시작해야 할까요?

중요한 점은 모든 사람이 비즈니스 프로세스를 개선하고자 하지만, ERP 환경이 매우 작지 않은 것이 아니라면, 처음부터 새로 시작하는 데 드는 비용은 실익이 없을 가능성이 큽니다. 왜냐하면 모든 프로세스에 걸쳐진 집중으로 효과가 분산되기 때문입니다. 특히, S/4HANA에서 크게 개선할 수 있는 프로세스에만 집중할 수 있는 것이 아니기 때문이죠. 반면, 브라운필드(Brownfield) 접근 방식으로 점진적인 선별적 전환을 따르더라도 여전히 몇 가지 중요한 비즈니스 구성과 프로세스를 변화시킬 수 있습니다.

따라서, 제 권장 사항은 파일럿(시범) 브라운필드 코어와 주요 프로세스를 선별하여 테스트 해보는 것입니다(데이터는 여전히 선별적일 수 있습니다!). 표준 프로세스에서 부가가치 효과를 내는 곳에서만 점진적으로 이동하는 방식을 채택하십시오.

또한, 병렬적으로 두가지 방식 모두의 파일럿(시범)을 실행하는 것도 좋은 단계가 될 수 있습니다 – 소규모 데이터 일부를 선택하여 그린필드 및 브라운필드 파일럿(시범) 시스템에서 실행하십시오. 나무를 베기 전에 도끼를 날카롭게 다듬는 것이 중요하니까요!

요약하자면:

(물론 이 주제에 대한 제 생각은 제 경험에 크게 영향을 받았으며, 여러분의 의견과 토론을 환영합니다!)

ECC에서 SAP S/4HANA로 전환하려는 모든 기업고객은:

  • 선별적 데이터 전환 접근 방식을 취해야 하며, 이는 그들이 설정하려는 필드의 색상과 무관합니다.
  • 클린코어를 목표로 해야 하지만, 고객별 맞춤을 위한 CBO 는 여전히 존재할 것이라는 점을 이해해야 합니다. BTP 및 유사한 플랫폼에서 말이죠. 따라서ㅡ SAP를 운영할 정도로 복잡한 비즈니스를 운영하는 경우라면, 1회성으로 순수한 그린필드 설정으로 이동하고 싶지는 않을 것입니다. 이런 경우, 브라운필드 접근 방식이 여전히 선택적이고 변화를 줄 수 있지만, 변화 비용이 더 낮다면, 왜 고민할 필요도 없이 그 경로를 선택하지 않겠습니까? 그린필드 접근 방식에서 명확한 비즈니스 이점을 확인하지 않는 한, 이것이 제가 제안하는 가이드라인입니다.
  • 핵심 데이터의 부분적 데이터를 가지고 병렬적으로 두가지 방안 브라운필드 및 그린필드 모두 파일럿(시범)을 실행하여 정보에 근거한 결정을 내리는 것을 고려하십시오.

596790_KR_Don_t_forget_the_full_landscape_view

이러한 유형의 프로젝트(예: 클라우드 마이그레이션 및 구형 시스템 업그레이드)는 유일한 변화이자 고유한 기회입니다. 이때 잠시 동안 두 개의 병렬 시스템을 가질 수 있으며, 이를 통해 ERP에서 비즈니스 구성(사용자 정의)을 재설계하고, 개발 시스템에서 운영시스템까지의 데이터를 재설계 할 수 있습니다. 또한, 비운영시스템이 항상 익명화 또는 난독화되도록 설정하여 데이터를 보호할 수 있습니다.

많은 기업들이 비즈니스 프로세스 개선에 집중하면서도 DevOps 환경 최적화를 잊는 경우가 많습니다. 이로 인해 S/4HANA 환경에 대해 매우 큰 플랫폼 비용을 지불하는 경우가 흔합니다. 특히, 전체 시스템을 살펴보지 않으면(Dev, QA, Pre-Prod, Project Tracks, Prod 까지) 데이터를 놓치는 경우가 많습니다. 하지만, 이전하기 전에 전체 시스템을 신중하게 설계하지 않으면 나중에 최적화하는 데 몇 년이 걸릴 수 있으며, 그때까지 관련된 비용을 지불하게 됩니다.

 

KR_SDT Data Migration

EPI-USE Labs의 Data Sync Manager와 같은 전문 소프트웨어를 사용하여 S/4HANA로의 전환을 최적화하고 'Lean Secure' SAP 환경을 보장하세요.
(우리말 번역 : Lean Secure,  "간결하고 데이터가 보호된"  )

저는 EPI-USE Labs에서 ‘Lean Secure SAP’ 패러다임을 오랫동안 제안해왔습니다. 이 개념은 운영시스템에서 모든 비운영 DevOps 시스템에 이르는 데이터를 중점적으로 다룹니다. 여전히 유효한 개념이며, S/4HANA로 이전하는 모든 이들에게 전체 시스템에 대한 데이터 설계를 권장합니다. 목표는 효율적인 데이터, 간소화된 시스템, 그리고 데이터 프라이버시가 내재된 운영을 구현하는 것입니다.

이와 관련해 필드의 색상을 걱정할 필요는 없습니다. 클린코어와 스탠다드 코드, 프로세스, 더 나은 비즈니스 설정으로의 이동이 데이터 접근 방식을 변경할 수 있지만, 반드시 정의될 필요는 없습니다.

여러분이 사전 준비를 철저히 하고 – 특히 비즈니스 파트너(Busines Partner)와 재무 부문 –  코드, 프로세스, 데이터에 대한 접근 방식을 신중하게 계획하면, 투자 수익률을 최적화하고 향후 5년 동안 총 소유 비용(TCO)을 크게 줄일 수 있습니다. 이렇게 좋은 기획을 통해 투자 대비 가치를 훨씬 초과하는 혜택을 누릴 수 있습니다. HANA 및 S/4HANA 기술은 정말 탁월합니다. 라이선스 비용 및 접근 방식을 주의 깊게 검토해야 하지만, 이 세계적 수준의 ERP 플랫폼은 비즈니스 방식을 변화시킬 수 있는 기술적 및 기능적 기능을 가지고 있습니다.

596790_KR_In_summary-_the_best_approach

저는 브라운필드에 가까운 선별적 접근 방식을 시작하고 이를 파일럿(시범)으로 실행할 것을 권장합니다. 또한, 비즈니스에 가장 적합한 접근 방식을 입증하기 위해 작은 새 시스템(a green system)을 설정하는 것도 고려하십시오.

그런 다음 Lean Secure SDT 접근 방식을 옹호하고, 그린에서 브라운필드로의 스펙트럼을 코드와 프로세스에 대한 접근 방식으로만 생각하십시오. 데이터에 구별을 위한 점선이 그려지고, 필요한 것만 가져가야하는 것이 무엇인지 물어보세요.

히스토리가 몇 년 밖에 없고 시스템이 작다면 데이터를 모두 유지하는 것도 괜찮지만, 그렇지 않다면 모든 사람이 데이터를 어떻게 관리할지 본능적으로도 선별적으로 채택해야 할 것을 한다고 주장하고 싶습니다. 운영에서 DevOps, QA 및 Sandbox 시스템에 이르는 과정에서 말이죠.

이 프로젝트는 주요 전환 중에 시스템을 최적화할 수 있는 마지막 유일한 기회일 수 있습니다. 이제 SAP는 더 규칙적인 클라우드 기반 릴리스 일정과 모든 이들이 궁극적으로 다가가야 할 클린 코어 개념을 추구하고 있으므로, 앞으로 이러한 종류의 또 다른 중요한 전환의 계기가 있을까요? 그렇다면, 그런 기회가 다시 찾아오려면 매우 오랜 시간이 걸릴 것입니다. 그러니 도끼를 휘두르기 전에 날을 갈아 두세요!

596790_KR_SAP_S4HANA_Migration_CTA

 

Jamie Neilan

Jamie는 EPI-USE Labs 유럽 지역 담당의 전문 서비스 디렉터로, SAP를 사용하는 기업을 주로 대상으로 하는 IT 서비스 업계에서 20년의 경력을 보유하고 있습니다. 그의 경력은 SAP 테크니컬 컨설턴트로 시작하여, 이후 SAP 데이터 프로젝트, BASIS, RunSAP, 프리세일즈/솔루션 아키텍처를 전문으로 다루게 되었습니다. 다양한 SAP 인증을 보유하고 있으며, 프로그래밍, DBA 업무, 웹 디자인, SAP 기술 작업 등의 배경을 갖추고 있습니다. Jamie는 여러 플랫폼에서 폭넓은 경험을 보유하고 있으며, SAP 기술을 활용해 고객에게 가치를 제공하는 데 열정을 가지고 있습니다.

이전의 홈페이지 다음 맨 위로 돌아가기

태그:

추천: