Mendix 및 SAP 파트너십 | Mendix

Mendix 2017년부터 SAP의 로우코드 애플리케이션 개발 주요 파트너였으며, 로우코드 공급업체 중 유일하게 SAP 인증 앱 파트너 그리고 통과했다 SAP 프리미엄 인증. 즉, SAP가 공식적으로 인증을 받았고 사용을 승인했다는 의미입니다. Mendix SAP 솔루션과 함께

SAP Build는 로우코드를 기존 SAP 개발을 보완하는 유용한 추가 기능으로 보는 고객에게 시작점으로 적합하지만, 그 이상은 아닙니다. Mendix 고객의 야망이 SAP뿐만 아니라 비 SAP 시스템 및 기술(Oracle, Salesforce, Java, .Net 등)에 대해서도 기존 개발의 대부분을 로우코드 작업 방식으로 대체하려는 경우 더욱 합리적입니다.

Mendix 는 애플리케이션 개발에만 집중하는 단일 플랫폼인 반면 SAP Build는 RPA(Robotic Process Automation)와 같이 다른 작업도 수행하는 4가지 제품으로 구성되어 있습니다. 따라서 다음과 같은 상황이 발생할 수 있습니다. Mendix 그리고 SAP Build의 일부도 함께 사용할 수 있습니다. 직접 비교하기는 어렵지만 SAP와 Mendix 두 회사 모두 두 제품 간의 명확한 차이점을 알고 있으며, 지속적인 파트너십을 통해 고객은 요구 사항에 가장 적합한 제품을 선택할 수 있습니다. Mendix, SAP Build 또는 이 둘의 조합.

고객 사례

Mendix SAP 고객을 위한 스위스 군용 칼과 같습니다. SAP에 특정 기능이 없을 때 사용할 수 있지만, 표준 SAP 솔루션이 해결하려는 문제에 비해 너무 클 때 SAP에 대한 가벼운 대안으로 사용할 수도 있습니다.

물론 SAP Build를 포함한 SAP BTP를 사용하여 이러한 격차를 메울 수 있지만, 로우코드와 함께 또는 로우코드 대신 기존의 하이코드를 사용해야 할 수도 있습니다. Mendix특히 다음 기준 중 하나 이상을 충족하는 경우:

1. SAP 및 비 SAP 시스템의 데이터와 기능 결합: 마케팅, 영업 및 서비스 사용자를 위한 다른 ERP 시스템이나 Salesforce와 같습니다. Mendix 강력한 SAP 통합이 있지만 SAP에 대한 의견이 없습니다. SAP 브랜드가 아니라는 사실로 인해 다른 시스템과 기술을 사용하는 사람들이 기업 전체 플랫폼으로 수용할 가능성이 높습니다.
2. 표준 워크플로 기능과 목적에 맞게 구축된 앱 경험 결합: 예를 들어, 금융, 조달, 마스터 데이터 관리 및 산업별 프로세스에서. 워크플로 관리와 로우코드 개발이 별도의 도구로 제공되는 SAP Build와 달리, Mendix 두 가지 장점을 모두 제공하는 단일 플랫폼의 내장 워크플로 엔진이 탑재되어 있습니다.
3. 사용자 정의형 사용자 경험: 예를 들어, 회사 브랜딩과 소비자 등급 경험이 필요한 고객 및 파트너 셀프 서비스 앱입니다. 또한 표준 SAP 사용자 경험으로 인해 생산성이 제한되는 영업, 서비스 및 기타 부서의 내부 사용자를 위한 앱입니다.
4. 모바일 사용자 경험: 예를 들어, 유지 관리 및 현장 서비스, 창고 스캐닝 및 배달 증명 앱에서의 작업 주문 실행. 많은 고객이 전통적으로 모바일 기기에서 SAP를 활성화하는 데 어려움을 겪었지만, 이는 강점 분야입니다. Mendix. Mendix 앱은 기본적으로 반응형이지만, iOS 및 Android용 Progressive Web Apps(PWA) 및 네이티브 모바일 앱으로 변환할 수도 있습니다. 오프라인에서도 작동할 수 있으며, 이는 위에 나열된 사용 사례에 종종 중요합니다.

사용 사례가 이러한 기준을 많이 충족할수록 더 적합합니다. Mendix.

고객 시나리오

"핵심을 깨끗하게 유지하십시오"는 SAP가 4년 S/2015HANA를 출시한 이래로 사용자 정의 코드에 대한 모토였습니다. 우리는 고객이 다양한 정도로 이를 수행하는 것을 봅니다. Mendix그리고 대체적으로 4가지 범주 또는 시나리오로 나뉩니다.

시나리오 1: 코어에 연결

이 시나리오에서 고객은 아직 "핵심을 깨끗하게 유지"하기 위한 전략을 구체적으로 표현하지는 않았지만 구축하고 있습니다. Mendix SAP 통합이 가능한 애플리케이션.

시작하기에 좋은 곳은 "SAP 사전 처리" 애플리케이션입니다. 여기서는 완전하고 승인된 객체나 거래가 SAP에 입력되기 전에 다양한 사용자가 데이터를 수집 및/또는 승인해야 합니다.

예로는 자본 지출 요청, 구매 요청, 마스터 데이터 변경 등이 있으며, 이는 종종 이메일, Excel, Lotus Notes와 같은 섀도 IT를 통해 수행됩니다. Mendix 이러한 사용 사례를 자동화하는 이상적인 방법이며, 특히 SAP 이외의 통합이 필요하거나 SAP Build Process Automation과 같은 표준 워크플로 도구가 아닌 전용 앱의 사용자 경험이 필요한 경우에 그렇습니다.

시간이 지나면서 고객은 "핵심을 깨끗하게 유지"하려고 명시적으로 노력하지 않더라도 SAP 통합을 통해 많은 앱을 빌드할 수 있습니다. 좋은 예는 다음과 같습니다. Siemens, 많은 SAP 인스턴스와 800개 이상을 보유하고 있습니다. Mendix 프로덕션 단계의 앱.

시나리오 2: 핵심을 포함하다

이 시나리오에서 고객은 SAP를 어느 정도 레거시 시스템으로 취급하면서, 미래의 어느 시점에 S/4HANA나 다른 ERP 시스템으로 마이그레이션할 의도를 가지고 있습니다.

이러한 고객은 보안 패치 및 법적 업데이트와 같은 필수적인 사항을 제외한 모든 변경 사항에 대해 "SAP를 억제", "SAP를 상자에 넣음" 또는 "SAP를 동결"하려고 시도합니다. 새로운 개발은 거의 항상 Mendix하지만 기존 사용자 정의 코드를 향상시키고 확장하는 것은 변경의 규모와 범위, 그리고 고객 정책에 따라 달라집니다.

핵심 부분에서는 더 작은 변경을 할 수 있지만 더 큰 변경은 전체 기능을 이동할 수 있는 기회가 될 수 있습니다. Mendix. 이 범주의 고객에는 건강, 미용 및 영양 회사가 포함됩니다. DSM-Firmenich 그리고 에너지 소매업체 에넥 시스.

시나리오 3: 코어 청소

이 시나리오에서 고객은 핵심에서 사용자 정의 코드를 체계적으로 제거하고 이를 다시 빌드합니다. Mendix.

동일한 기능을 그대로 재구축한다는 오해가 있지만, 물론 그들은 새로운 기능과 더 나은 사용자 경험으로 현대화할 기회도 잡습니다. 예를 들어, 전체 모바일 지원이 포함됩니다. 이런 의미에서 핵심을 정리하는 것은 단순히 기술 부채를 줄이기 위한 IT 프로젝트가 아니라 비즈니스에 실질적인 가치를 제공합니다.

SAP는 "SAP S/4HANA 구현의 사용자 정의 확장 - 고위 IT 리더십을 위한 실용 가이드"라는 문서에서 핵심을 정리하는 방법에 대한 자세한 지침을 제공했습니다. 이 문서는 2021년에 작성되었지만 여전히 SAP가 제공한 가장 자세한 지침이며 SAP ECC를 계속 사용하는 고객과 S/4HANA로 마이그레이션하는 고객에게 관련이 있습니다. 단계별 가이드는 아니지만 수행해야 할 주요 단계를 설명합니다.

• SAP 아키텍트의 기술 향상을 시작하세요 그리고 아직 사용하지 않았다면 가능한 한 빨리 사용하고 싶은 새로운 기술에 대한 개발팀을 만드십시오. 이 문서에서는 SAP BTP 기술을 사용한다고 가정하지만 Mendix 단일 플랫폼, 기술, 스킬셋이기 때문에 이런 측면에서 훨씬 간단합니다.
• 모든 오래된 코드를 제거하세요 ERP 시스템에서. SAP는 이것이 일반적으로 전체의 30%이고 때로는 최대 50%라고 말합니다. 어떤 코드가 더 이상 사용되지 않는지 알아내려면 문서에 설명된 대로 사용자 정의 코드 사용 모니터링을 위한 기본 제공 SAP 기능을 활성화할 수 있습니다.
• 더 이상 사용되지 않을 코드는 무시하세요. S/4HANA로 전환하는 경우 표준 기능으로 대체될 수 있으므로 다시 빌드하는 것이 의미가 없습니다. 이 단계에는 기능적 및 기술적 SAP 지식이 필요하므로 SAP 파트너와 협력하여 이를 수행해야 할 수 있습니다. SAP는 이 단계 이후에는 원래 사용자 지정 코드의 10%만 코어에서 정리할 수 있다고 말합니다.
• SAP Custom Code Analyzer라는 도구를 사용하세요 나머지 코드의 복잡성을 분석하고 정리 및 재구축을 위해 우선순위를 정합니다. SAP는 비즈니스 우선순위 외에도 고객에게 복잡한 코드와 "고아 코드"를 우선 순위로 정하도록 조언합니다. 복잡한 코드는 가장 많은 문제와 변경으로 이어지고 따라서 가장 높은 유지 관리 비용이 드는 반면 "고아 코드"는 적절한 문서의 소유자가 없으므로 비즈니스에 위험이 됩니다.

다시 빌드해야 하는 각 수정 사항에 대해 문서의 섹션 4에 있는 자세한 지침을 사용하여 선호도 순서대로 옵션을 평가하세요.

• 앱 내 확장 기능(S/4HANA에서만 사용 가능)
• 새로운 플랫폼에서의 병렬 확장
• 온스택 확장(S/4HANA에서만 사용 가능)
• 아무것도 하지 마십시오(현재 ABAP 코드(이제 "클래식 확장"으로 알려짐)를 고수하십시오)

SAP ECC 시스템의 핵심을 체계적으로 정리한 고객의 좋은 예는 농업 사업입니다. 코선 비트 컴퍼니. 그들은 ECC 시스템을 정리하고 기존 ABAP 및 Fiori 개발자에게 재교육을 제공하기 위해 "SAP 2 Standard"라는 프로그램을 시작했습니다. Mendix그 결과, 그들은 개발 역량을 두 배로 늘리고, 이전보다 7배 더 많은 성과를 거두었으며, 심지어 회사의 작물 수확량을 연간 1.8만 유로 늘리는 데도 기여했습니다.

시나리오 4: 핵심을 깨끗하게 유지하세요

"핵심을 깨끗하게 유지하세요"는 핵심이 처음부터 깨끗해야 한다는 것을 의미합니다. 즉, 핵심을 정리했거나, 그린필드 재구현을 진행 중이거나, SAP를 전혀 사용하지 않는 경우 모두 해당됩니다.

어떤 의미에서 SAP를 처음 사용하는 경우 아키텍트와 개발자를 직접 온보딩할 수 있기 때문에 더 쉽습니다. Mendix 먼저 오래된 SAP 기술을 끊을 필요 없이. 그러한 고객의 좋은 예는 광산 회사입니다. 시벨코 그리고 HVAC, 욕실, 주방 도매업체 반 마르케.

고객이 사용하는 더 많은 예는 다음과 같습니다. Mendix SAP와 함께 사용하여 다음을 참조하세요. SAP를 특징으로 하는 고객 사례.

공동 파트너

Mendix 앱을 구축하는 데 도움을 줄 수 있는 컨설턴트가 있지만 SAP 컨설턴트는 아닙니다. SAP 도메인 전문 지식도 필요한 경우 두 가지 모두를 갖춘 파트너를 찾는 데 도움을 드릴 수 있습니다. Mendix 및 SAP 경험. 이는 다음을 모두 갖춘 글로벌 시스템 통합자가 될 수 있습니다. Mendix 실무 및 SAP 실무 또는 두 가지를 결합한 전문 분야를 갖춘 소규모 파트너가 될 수 있습니다. Mendix 그리고 SAP. 저희는 이런 것들을 많이 가지고 있으며, 귀하의 지역에서 하나를 찾는 데 도움을 드리겠습니다.

지원 전략 사이 Mendix 그리고 SAP BTP

Mendix 애플리케이션은 SAP BTP를 사용하여 실행되도록 개발 및 배포됩니다. Mendix Cloud Foundry 빌드 팩. 당사 고객은 때때로 부당한 문제에 부딪힐 수 있습니다. SAP의 일부로서Mendix 파트너십을 통해 우리는 우리의 세부 정보에 자세히 설명된 바와 같이 명확하게 구성된 지원 전략을 갖고 있습니다. 지원 가이드.