「SAPが使いにくい…」アドオン地獄を回避する「SAPオフロード」という処方箋

Chiho Suganuma

読み終わるまで4分

世は S/4HANA への大更改時代。SAP 導入を終え、運用が始まった今、「アドオンが使いこなせない」「標準化したが使い勝手に違和感がある」といった声が聞こえていませんか。導入の成果を無駄にせず活用を定着させるには、現場が気持ちよく使えることが重要です。
本記事では、その処方箋として「SAP オフロード」の考え方と設計のポイントをご紹介します。

SAPオフロードとは何か

「SAPオフロード」とは、SAPに対し標準機能を中心に活用し、アドオンが必要な機能を周辺システムなどに切り出して複雑性を緩和する設計思想です。コスト・運用・柔軟性のバランスを改善する点に強みがあります。イメージをつかむために、具体例を見ていきましょう。

例① マスター更新

SAP上でも商品マスターやBPマスターの更新は可能です。一方、複数の関係者を含んだ承認フローを構築したい場合は、SAP上に多くのユーザーアカウントが必要です。そこでオフロードの考え方で別SaaSに切り出すとどうでしょう。SaaS上で承認フローを回し、承認後のデータをSAPへ連携します。承認に必要なユーザーはSaaS側だけでよく、SAPのユーザー数を節約できます。承認フローに特化したSaaSなら、複雑なフローも標準機能の範囲で実現できることが多いです。

▼SaaSについてもっと詳しく知りたい
⇒ SaaS（Software as a Service）｜用語集

例② 帳票

SAP上でもアドオンで帳票作成は可能です。一方、複数モジュールにまたがるデータを柔軟に参照したい場合、アドオンで作りこむと変更が難しく、特定の保守メンバーに依存しがちです。これに対しオフロードの考え方では、BIツールへデータを連携し帳票化します。SAP以外のデータも扱え、ダッシュボードの変更もユーザー側で柔軟に可能です。BIツールでは標準機能の範囲で実現できることが多いです。

SAPオフロードは、複雑化・属人化、ユーザー増に伴うコスト・運用負荷など、SAPのみで実装した場合の課題を解決します。加えて、バージョンアップが容易になること、運用に合わなくなった時に切り替えやすい（可逆性が高い）ことも、柔軟性の面でのメリットです。

TOPへ

SAPオフロードに対するよくある疑問

ここまで「SAPオフロード」について良い面を見てきましたが、そんなにうまい話があるかしら？そう思われた方もいるのではないでしょうか。ここからはSAPオフロードに寄せられがちな疑問を紹介します。

疑問① SAPの属人化が、SaaSの属人化に置き換わるだけではないか？

SAPオフロードのメリットである「アドオン増加による複雑化・属人化」の解消。しかし、周辺システムを作りこんでしまったら、SAPのアドオンと本質的なリスクは同じではないかという疑問です。確かに、使用しているシステムの数を増やすと、そのシステムごとに理解している人材を確保しなければなりませんし、複雑化・属人化そのものがSAPから分散しただけと捉えることもできてしまいます。

疑問② オフロードするとデータ連携が複雑にならないか？

SAPから周辺システムへ切り出すということは、 SAPの内部で完結していたデータのやり取りを意識しなければなりません。 SAPと周辺システムは別々のシステムとなるため、それらを接続し、データを連携する必要があります。複数の周辺システムを活用する場合、1対1だけでなく、1対N、N対Nのデータ連携も発生しえます。その複雑性は「SAPオフロード」のメリットと釣り合うのでしょうか。

▼データ連携についてもっと詳しく知りたい
⇒ データ連携 / データ連携基盤｜用語集

TOPへ

オフロードを成功させるための設計ポイント

実は…その懸念はあたっています。むやみに進めてしまうと、その不安が現実となってしまいます。SAPオフロードはあくまで処方箋であり、その活用にはコツが必要です。

コツ① 標準機能を使い切るという選択

SAPを作りこまないということは、代わりに周辺システムを作りこめばいいということではありません。なぜならその「作りこみ」こそが、複雑化・属人化の真犯人だからです。特定の人や製品に依存する運用を生み出さないよう、SAPも周辺システムも過度な作りこみを避け、標準機能を活用することを基準としましょう。

SaaSを導入するのであれば、業務特性に合う製品を選び、標準設定を中心に利用すべきです。同じ目的のSaaSであっても製品ごとに強みが異なります。例えば国産のSaaSでは日本の商習慣に合わせた機能を標準提供していることが多く、現行の運用を変えずに作りこみを減らせるケースがあります。

また、SAPとSaaSのデータ連携では、独自の連携ロジックをアドオンで構築するのではなく、SAPの標準API（OData）による連携をお勧めします。「作りこみ」を避けるためにオフロードしたのに、データ連携のために作りこんでしまっては本末転倒です。

標準機能を使うことで、複雑化・属人化を遠ざけ、組織として継続可能なシステム構成を実現しましょう。

コツ② 全体を意識したアーキテクチャ設計

複数のシステムを扱うオフロードで重要なのは、一か所を集中的にとらえるのではなく、広い視点でシステム同士の関係性を俯瞰・整備する力です。具体的には、SAPと周辺システムを「点」で捉えるのではなく、広い視野で「面」として捉えましょう。そうでなければ、システム間のデータの通り道である「データ連携」が見落とされ、SAPの外に複雑なネットワークが広がってしまいます。

オフロードに着手する際、最初は1つの業務を切り出すことから始まります。しかし、その場しのぎで1対１の個別最適化を繰り返すと、区画整理されていない下町のように道が入り組み、拡張性が乏しくなりがちです。

そこでお勧めしたいのは、データ連携基盤（iPaaS）を用いた疎結合の構成です。中心にデータ連携のハブを置くことで、1対N・N対Nへと拡張しやすくなります。iPaaSを活用すれば、データ連携を連携先に合わせて都度ゼロから開発するのではなく、パーツ化・共通化された部品を用いることで構築にかかる負担を大幅に軽減できます。SAPや周辺システムのデータ連携機能を活用しつつ、SAP業務だけでなくデータ連携においても役割分担を明確化しましょう。そうすれば、運用負荷や将来変更時の影響範囲を最小化できます。

▼疎結合についてもっと詳しく知りたい
⇒ 疎結合｜用語集

TOPへ