サイト内検索

MendixはローコードだからSAPのような基幹システムには向かないのでは」「エンタープライズ領域のシステム開発に本当に対応できるのか」——IT部門でMendixの導入を検討していると、こうした疑問に突き当たることが少なくありません。

結論から言うと、MendixSAPをはじめとする基幹システムの機能を損なうことなく、その上に現場向けのアプリケーションを拡張する「サイド・バイ・サイド拡張」に対応できます。本記事では、海外のMendix導入事例に見られる代表的なアーキテクチャパターンをもとに、SAPMendixを連携させる仕組みを技術的な観点から解説します。

なぜ「SAPを拡張する」という発想が必要なのか

製造業でSAPを導入している企業の多くは、生産管理モジュール(PP)を用いて製造指図やBOM(部品表)、生産実績を管理するケースがあります。しかし、SAP標準の画面は業務全体を網羅する設計になっている分、工場現場の担当者が使うには操作項目が多く、現場の作業導線に最適化されているとは言えません。

かといって、現場の使い勝手を良くするためにSAP自体をカスタマイズしていくと、変更のたびに検証工数がかかり、将来のバージョンアップ(S/4HANAへの移行など)の妨げにもなります。SAPは堅牢性と標準化を重視したシステムであるがゆえに、現場の細かな要望に迅速に対応することが構造的に難しい、というジレンマがあります。

海外のMendix活用事例では、このジレンマに対して「SAPのコアには手を入れず、その外側に現場向けのアプリケーション層を追加する」というアプローチが取られています。この考え方の中心にあるのが、Mendixによるサイド・バイ・サイド拡張です。

実際、この発想はSAP自身の方向性とも一致しています。SAPは近年、内部を直接カスタマイズする従来型の開発(ABAPによる改修など)を非推奨とし、外部からAPI経由でアプリケーションを拡張する「クリーンコア」という方針を強く推奨しています。Mendixはこのクリーンコアの考え方に沿ったアプリ拡張が得意なプラットフォームであり、SAPのオフィシャルパートナーとしても認定されています。

MendixによるSAP拡張の基本アーキテクチャ

海外の製造業事例に見られる代表的な構成は、SAPとMendixを次の三つの役割に分けて連携させるというものです。

1. SAP:システム・オブ・レコード
在庫管理、会計処理、品質検査結果の記録など、企業の基幹データを扱う領域は引き続きSAPが担います。SAPの標準機能・標準データモデルは変更せず、そのまま「正」のデータソースとして維持します。

2. Mendix:業務ロジックとUIのレイヤー
現場のワークフロー管理、画面表示、入力チェックといった、変化しやすい業務ロジックとユーザーインターフェースをMendix側に切り出します。SAPを直接操作させる代わりに、現場担当者はMendix上で構築されたアプリを使って作業を進めます。

3. API連携:両者をつなぐ疎結合の接点
MendixとSAPの間は、OData APIをベースにした疎結合の連携で結びます。SAP側の内部構造を変更することなく、必要なデータだけをやり取りする形になるため、SAPのアップグレードやパッチ適用の影響を受けにくいのが特徴です。

この「コアは変えず、外側で拡張する」という考え方こそが、MendixがSAPの「Add-on(アドオン)」として機能する仕組みの本質です。

この3層構成は、机上の理論ではありません。マクニカ自身も、社内のSAP受発注データをMendixに連携し、お客様への納期回答データを自動作成する社内アプリケーションを、まさにこの構成で構築し、運用しています。

データ連携の具体例

実際にどのようなデータがやり取りされるのか、海外のMendix導入支援会社が紹介している代表的な連携ポイントを整理すると、次のようになります。

連携ポイント データの流れ
製造指図の取得 SAP(PPモジュール)で発行された製造指図を、Mendix側がAPI経由で自動取得。現場担当者はSAPにログインせずに指図内容を確認できる
BOM(部品表)の連携 製造指図に紐づくBOM情報をSAPから取得し、Mendix側で作業手順やチェックリストを自動生成
品質検査データの登録 現場で記録した検査結果をMendix上で入力し、SAPの品質管理(QM)モジュールへ自動反映
生産実績・入庫の反映 Mendix上での完了報告をトリガーに、SAP側で製造指図の完了処理と入庫(Goods Receipt)を自動更新

いずれのケースも、Mendix側の業務イベントをきっかけにSAPAPIコールが行われる形になっており、現場での操作がリアルタイムにSAPの基幹データへ反映される設計です。

導入形態と連携技術

Mendixはホスティングの自由度が高く、Mendix Cloudのようなパブリッククラウドはもちろん、オンプレミスやプライベートクラウド環境への構築にも対応します。SAPとの通信は基本的にHTTPS/OData APIで行われ、環境によって次のように接続方式を使い分けます。

SAP S/4HANA
SAP標準で公開されているOData APIを利用し、比較的少ない工数で連携を構築できる
SAP ECCなどOData APIが未整備の環境
RFC/BAPIやSOAP Webサービスを使った連携になるが、Mendixには SAP連携用のコネクタが用意されており、スクラッチ実装に比べ統合工数を抑えられる
より複雑な統合シナリオ
SAP Integration Suite(BTP)を介したメッセージ連携や、イベント駆動型の連携にも対応可能

認証・セキュリティ面では、Active Directory/LDAPとの連携やSAMLOpenID ConnectOIDC)によるシングルサインオン、ユーザーロール単位でのアクセス制御など、エンタープライズ環境で求められる水準の仕組みが標準で備わっています。SAPとのインターフェース部分も、認証トークンや資格情報によって保護される設計です。

「コアを変えない拡張」がもたらすメリット

このアーキテクチャを採用することで、海外のMendix導入支援会社は次のようなメリットを挙げています。

開発サイクルの短縮
ローコード開発により、現場の要望に応じたアプリの追加・変更を、フルスクラッチのABAP開発に比べて短いサイクルで行える
SAPコアの安定運用
SAP標準モジュールをカスタマイズしないため、S/4HANAへの移行やバージョンアップ時の影響を抑えられる
現場の生産性向上
ペーパーレスの作業手順や電子データ入力により、現場担当者がSAPの煩雑な操作から解放される
段階的な拡張のしやすさ
疎結合の構成のため、新しい工場・新しい業務プロセスへの横展開や、将来的な新技術(AIエージェントなど)の追加も比較的低リスクで進めやすい

このアーキテクチャのもう一つの利点は、SAP自体の将来のバージョンアップに対する耐性です。ODataという標準APIを介して連携している限り、SAP側がS/4HANAへ移行しても、Mendix側の業務ロジックやUIはほぼそのまま使い続けられます。作り直しが必要になるのは、SAP側のOData接続部分のみです。「SAPを拡張する」という選択は、今の開発を楽にするだけでなく、将来のSAPバージョンアップに対する投資保護にもなります。

Mendixは「SAPを置き換える」のではなく「SAPを活かす」選択肢

MendixによるSAP拡張は、既存のSAP環境を刷新するものではなく、SAPの堅牢なコアはそのままに、現場が本当に必要とする機能を素早く追加していくためのアプローチです。エンタープライズシステムの開発実績という観点でも、Mendixはこうした基幹システムとの連携を前提に設計されたプラットフォームであり、IT部門が抱く「本当にエンタープライズ領域で通用するのか」という疑問に対する一つの答えがここにあります。

自社のSAP環境でどのような拡張が可能か、具体的な構成を相談したい場合は、Mendixの製品ページから問い合わせが可能です。