Clean Core 접근법 소개

클라우드 이전 세상에서 이 접근법은 대부분 SAP와 고객 모두를 위해 매우 간단하게 구현할 수 있었습니다. 어떤 면에서는 계약과 비슷했다. SAP에서 제공한 특정 사항 및 고객이 수행한 특정 단계와 절차가 있었습니다. SAP 어플리케이션의 화면에 수익과원가라는 두 개의 필드가 있는 간단한 시나리오를 가정해 보겠습니다. 최종 사용자가 디스플레이에 필드를 더 추가하도록 요청하는 것은 너무 예민하지 않을 것입니다. 수익 표시 필드를 새로 요청하여 그렇게 했다고 가정해 보겠습니다. 그리고 수익이 수익과 원가뿐만 아니라 고객이 사용하는 특수 숫자 계수도 사용하여 계산된다고 가정해 보겠습니다. 이 요소는 고객마다 다르므로 어플리케이션에서 사용 중인 기본 데이터베이스 테이블에 이를 저장할 필드가 없습니다.

이러한 유형의 시나리오를 구현하기 위해 SAP는 고객에게 Exit 라고 하는 것을 제공할 것입니다. 이러한 Exit는 "스택"의 여러 레이어에 있습니다. 가장 낮은 레이어인 데이터 레이어에서 시작하여 이러한 레이어를 하나씩 살펴보겠습니다. 이 단순한 시나리오에서는 개발자가 "테이블 APPEND"를 사용하여 앞에서 언급한 숫자 계수를 나타내는 데이터베이스 테이블에 신규 필드를 추가합니다. 활성화되면 이 필드를 읽고 저장할 수 있습니다. 테이블 APPEND는 고객에게 고유한 비즈니스 요구사항에 맞게 제공된 SAP 테이블의 정의를 조정할 수 있는 Universal Exit 개념을 효과적으로 제공했습니다.

SAP에서 제공해야 하는 다음 스택 계층이 가장 높은 시각적 계층이 될 것입니다. 여기서는 신규 필드(수익, 단순 시나리오)를 시각화합니다. 비주얼 레이어 Exit는 주로 Screen Exit와 Menu Exit의 두 가지 유형으로 구성되어 있습니다. 이 단순한 시나리오에서는 개발자가 Screen Exit를 사용하여 신규 필드를 화면에 추가하고, 메뉴 Exit를 사용하여 최종 사용자가 선택하는 신규 명령어를 추가하면 수익 계산을 수행할 수 있습니다.

출구가 필요한 최종 스택 계층은 어떤 면에서 가장 중요합니다. 스택의 데이터 레이어에 추가되고 스택의 시각적 레이어에 표시되는 새로운 필드에 잠재적으로 읽기, 사용, 업데이트 및 때때로 삭제되어야 하는 값이 포함되기 때문입니다. 이러한 작업은 ABAP 코드를 사용하여 구현해야 합니다. 따라서 데이터와 UI 사이의 중간(즉, 코드) 계층에서 구현된 코드 Exit가 SAP에 의해 생성되었습니다. 이 간단한 시나리오에서는 개발자가 먼저 필드에 필요한 작업을 수행하기 위해 Code Exit가 존재하는지 확인한 다음 필요한 고객 고유 코드를 사용하여 Exit를 구현합니다.

따라서 고객은 원하는 추가 기능을 통해 확장된 표준 기능을 어플리케이션에서 제공하게 됩니다. 이 접근법의 중요한 측면 중 하나는 Exit 활용의 전체 프로세스가 정의된 시스템 프로세스에 의해 관리되었다는 점입니다. Exit를 활성화해야 합니다. Exit의 특정 구현은 모든 관련 구문 및 일관성 테스트를 통과해야 했습니다. 전용 개발 시스템에서 Exit 개발이 발생하여 운영 시스템의 최종 사용자에게 릴리스되기 전에 테스트 시스템에서 테스트되었습니다. 이 접근법의 또 다른 중요한 측면은 일반적으로 Exit 의 개발에서 시스템의 모든 SAP 오브젝트를 제한 없이 활용할 수 있다는 점입니다. 예:

• 모든 SAP 테이블을 레코드 읽기 및 쓰기에 사용 가능
• SAP 함수 모듈을 호출할 수 있습니다.
• SAP 클래스(및 그 방법)를 사용할 수 있음

마지막 한 점(그리고 중요한 점)입니다. 고객이 출구를 사용할 수 없거나 사용할 수 없다고 판단되면 다음 두 가지 방법을 사용할 수 있습니다.

• 원하는 기능을 얻기 위해 SAP 오브젝트를 수정합니다.
• SAP 오브젝트를 복사합니다. 신규 오브젝트는 고객 소유이므로 그에 따라 변경할 수 있습니다.

앞에서 언급했듯이, 고객 조정의 이점을 설계의 일부로 제공하는 시스템은 특정 이점과 특정 비용의 균형을 유지해야 합니다. 즉, 패치를 적용하거나 시스템을 업그레이드할 때가 되면 소프트웨어 벤더의 신규 또는 업데이트된 코드가 확장이 불안정하거나 불필요하게 될 수 있기 때문에 구현된 모든 확장이 이론적으로 문제가 될 수 있습니다. 이 경우가 아니었는지 확인하기 위해 테스트가 필요합니다. 그럼에도 불구하고 이를 고려하더라도 해당 테스트 프로세스를 관리하는 비용은 확장의 이점과 유연성에 비해 합리적이었다. 일반적으로, Exit 의 존재를 SAP가 알고 있기 때문에, Exit 의 구현으로 수행된 고객 조정은 업그레이드에 덜 문제가 있었고 이를 설명할 수 있었습니다. SAP 오브젝트 및/또는 SAP 오브젝트 복사본의 수정은 잠재적으로 훨씬 더 문제가 될 수 있으며 패치가 적용되거나 업그레이드가 이루어진 후 철저히 테스트되어야 합니다.

이러한 접근법은 수십 년 동안 SAP와 고객을 유지해 왔습니다. 서비스 팩과 인핸스먼트 팩을 통해 SAP Business Suite에 이르는 모든 버전의 SAP R/3부터 그러나 이러한 접근 방식이 성공적인 이유 중 하나는 시스템이 거의 항상 고객 데이터 센터에 위치해 고객이 100% 관리했기 때문입니다. 한 고객이 시스템에서 수행한 작업은 다른 고객이 시스템에서 수행한 작업과 완전히 별개입니다. 그러나 "게임 체인저"가 일어났다. 이러한 변화는 SAP ERP에서 SAP S/4HANA로의 전환이었습니다.

SAP S/4HANA Cloud는 클라우드에서 실행되며 클라우드 제품은 다릅니다. 모든 고객은 동일한 기본 코드 라인을 사용하며 변경사항은 모든 고객에게 동시에 적용됩니다. 따라서 각 개별 고객이 이전 온프레미스 환경에서와 동일한 방식으로 인핸스먼트를 구현할 수 있는 현실적인 방법은 없습니다. 고객 인핸스먼트는 여전히 필요하지만, 고객이 수행하는 규칙과 프로세스는 클라우드 환경을 위해 완전히 다시 생각하고 재설계해야 합니다. SAP에 또 다른 과제를 입력하십시오. 이전의 당면과제와 마찬가지로 이 문제 역시 SAP가 수용했습니다.​

이 솔루션은 클라우드를 위해 명확하게 지향하는 확장 철학을 설계하는 것입니다. Clean Core 라는 신규 용어를 입력합니다. 자세히 살펴보겠습니다.​

코어​

이 코어는 SAP S/4HANA Cloud의 주요 측면을 설명합니다. 이러한 측면은 차원 또는 구성 요소로 생각할 수 있으며 다음을 중심으로 합니다.​

• 프로세스: SAP S/4HANA Cloud 내에서 수행된 일련의 액션 또는 단계로, 결과를 제공하거나 결과를 달성하는 엔드 투 엔드(E2E) 경험을 다룹니다.​
• 데이터: SAP S/4HANA Cloud 프로세스에 포함되어 있고 SAP S/4HANA Cloud 프로세스에 사용되는 데이터입니다. 일반적으로 구성, 마스터 및 트랜잭션으로 범주화됩니다.​
• 통합: 프로세스 실행을 지원하기 위해 데이터를 전송하고 수신하기 위한 목적으로 SAP S/4HANA Cloud를 다른 솔루션에 연결합니다.​
• 운영: SAP S/4HANA Cloud에서 수행되는 필수 유지보수 액티비티(예: 릴리스 관리, 백그라운드 작업 관리, 권한 관리, 모니터링, 경보)​
• 확장성: 표준 프로세스에서 충족되지 않는 조직 요구사항을 해결하기 위해 SAP S/4HANA Cloud에 추가된 기능.​

정리​

Clean 은 앞에서 언급한 각 측면에 대해 해당 측면에 따라 최신, 클라우드 준수, 최적화 및 완벽성을 제공하는 데 필요한 접근 방식을 취한다는 것을 의미합니다.​

Clean Core​

Clean Core는 현대적이고 유연하며 클라우드 호환 SAP S/4HANA Cloud를 구현하기 위한 개념과 접근법입니다. Clean Core는 최적의 마스터 데이터 품질과 완벽한 비즈니스 프로세스 거버넌스를 통해 클라우드 호환 방식으로 SAP S/4HANA Cloud를 통합하고 확장함으로써 달성됩니다. Clean Core를 통해 고객은 SAP S/4HANA Cloud의 총 소유 비용(TCO, Total Cost of Ownership)을 낮추고 유지보수 능력을 향상할 수 있습니다.​