© 2021. SAP SE or an SAP affiliate company. All rights reserved.

製品拡張サービスを提供する”SAP IBSO イノベーションサービス&ソリューション”のご紹介

日本の大企業が本格的にコンピューターを導入しはじめた1960年代から1980年代までの企業情報システムの中心は部門最適型のシステムでしたが、1990年代前半の欧米でのBPRブーム、メインフレームから「ダウンサイジング」にむけたオープンシステムへの移行の潮流により、「2000年問題」もあいまって、部門最適型の業務プロセスから脱却，全社レベルの抜本的なプロセス再構築を推進するようになり、同時に，標準化された業務プロセスを大規模に展開し生産性を向上させるための新たなIT基盤が必要とされ、企業情報システム刷新のニーズが高まった日本を含む世界中の多くの企業でERPパッケージが本格的に採用されるようになってきました。

しかし、実際の開発現場では、オープン化に際して種々の課題に突き当っている企業も少なくありません。もちろん、どの企業もBPRを掲げて最大限に業務標準化・スリム化を推進するものの、個々企業の業務独自性や優位性、差別化要因がもちろん存在し、特にこういった領域の実現は得てしてプロセス・機能が複雑、且つERPパッケージが製品標準の機能と密に連携が必要な場合が非常に多いです。従って、拡張作業そのものに多大な工数が必要になるのはもちろんですが、稼働後のパッケージ製品のバージョンアップに伴って、拡張した機能の影響分析や改修作業にも多大な工数を要することになり、中長期的な安定したシステム運用を行っていくうえでの大きな懸念点の１つとなっています。

SAPでは、こういったシステム稼働後の運用課題を解決する支援策として、特に製品標準プロセスと密に関連する機能拡張開発について、製品ベンダーであるSAP自らが実施し、準製品として製品と同等のサポートを提供するサービスを展開しています。本記事ではそのサービスの概要についてご紹介します。

 

 

SAP IBSOが提供する機能拡張の特徴とは？

IBSO（Innovative Business Solutions Organization）は「拡張開発」を通じて、イノベーティブなソリューションをお客様に提供するグローバル組織になります。以前はCDP（Custom Development Project）と呼ばれていました。では、IBSOの「拡張開発」は通常のアドオン開発とどう違うのか？についてですが、通常のアドオンは、例えば、製品の外部接続用インターフェース口を利用したインターフェース開発や、ユーザー拡張口を利用したレポート、移行ツール、User-Exitなど、SAP標準機能にはない機能を一つ一つ単体機能を補完する為に開発を行いますが、IBSOが実施する拡張開発は、アドオン開発ではありますが、単体機能を補完するための開発というよりかは、標準プロセスと蜜連携する全くの新機能を大きな括りとして拡張する開発になります。

Snavi_IBSO01
図１：通常のアドオンとSAP機能拡張の違い

例えば、法定要件を満たす機能やプロセスが必要な場合です。SAPはグローバル標準システムであるがゆえに、各国のすべての法定要件に沿った機能やプロセスを標準で提供しているわけではなく、法定要件を満たすために、単体の機能ではなく、標準プロセスと蜜連携させた一連のプロセスや新機能が必要な場合、IBSOによる拡張開発を提案するケースが多いです。法改正などで機能修正が必要になる場合などにおいても、開発後の保守サービスも提供可能なので、そういったケースにも、IBSOで対応した機能であれば、保守サービスの範囲で機能修正を提供することができるのも特徴の一つです。もう一つは、SAP標準プロセスにはないが、お客様特有の競争力の維持や業務効率化などに貢献する、一連の業務プロセスを実現する場合です。国や業界独自の商習慣を実現するためのプロセス実現もこれにあたります。例えば、標準プロセスに並行してお客様特有のサブプロセスが必要な場合、標準プロセスのいたるところと蜜に連携させる必要があります。こういった場合に、IBSOの拡張開発によって、将来の保守性を考慮し、標準機能のチームと連携しながら、出来るだけ既存の標準機能のコード修正（モディフケーション）を行わずに、お客様要件を実現する方法を第一に考えてサービスを提供します。

 

 

SAP機能拡張のアプローチ – スクラッチ開発とIBSO製品

IBSOの開発アプローチには、スクラッチから行う方法と、すでに製品化されているものをベースとして差分開発する方法の２つが存在します。お客様特有のプロセスを実現させる場合など、スクラッチ開発として一から組み立てることも可能であり、一方で、すでに製品化されたソリューションや、法定要件や業界標準プロセスなどの再利用可能なアセットも多く持ち合わせています。製品化されたソリューションやアセットをベースに開発を行う場合には、実証済みのプロセスの上に最小限の調整で済むのが大きなメリットになります。製品化されたソリューションや再利用可能なアセットは、現在、大小含め約130のソリューションが製品化されており、毎年、新ソリューションの追加や製品機能のアップグレードがグローバルで行われています。

Snavi_IBSO02
図２：グローバルで展開されているIBSO製品の一例

例えば、「資産除去債務管理」を簡単に紹介すると、こちらのアセットでは、資産除去債務のライフサイクル全体をサポートするプロセス全般をカバーし、IFRS等の主要な会計原則に準拠した形で資産除去債務の監視・評価・会計処理およびレポーティングが可能となっています。もちろん、SAP会計コンポーネントとシームレスに統合されているので親和性も確保されており、また、資産除去債務の履歴や、引当金や利息費用の金額をユーザビリティの高い拡張画面で会計規則毎に確認することも可能です。このアセット利活用によるビジネス上のメリットは以下の通りです。

  • プロセス自動化により、データ入力をより少リソースで短時間に実施することで資産除去債務労力を大幅に削減
  • IFRS等の会計規則やSAPソリューションを使用するその他規制報告要件に準拠
  • データ共有・分析を部門や監査人と共有し、管理・運用を効率化

Snavi_IBSO03
図３：IBSO製品「資産除去債務管理」の機能概要イメージ

最終的に資産除去債務の財務ライフサイクル全体をカバーしてSAPへの投資を最大化することが可能になります。すぐに使える標準ソリューションとしてパッケージ化された実績のあるソリューションの一例になります。

 

 

標準プロセスと蜜連携する機能拡張開発の事例

ここで、IBSOが実際に拡張開発を実施した事例を３つご紹介します。

まずは「法定要件」に関する事例です。電気事業会計規則への対応として、会計規則にもとづいて払出価額を算定し払出品への原価差額を調整する機能や、建設工事間工事原価振替仕訳の一括計上機能、建設仮勘定からの固定資産振替規則登録機能、除却予定も含めたB/S予想値算定機能等々、電気事業法が要求する工事管理や資産管理が実現できる機能をSAP標準機能ベースに構築し提供しました。

Snavi_IBSO04
図４：（事例１）法定要件 – 電気事業会計規則への対応

この場合、資産管理や工事管理、会計、在庫、購買と、業務領域が多岐にわたった一連の機能やプロセスが対象となりました。この電気事業会計規則対応では、標準機能の拡張や蜜連携を行いながら、必要な新機能やプロセスを実現しています。また将来的な電気事業法改正で発生する変更へできるだけ柔軟に迅速に対応できるよう機能設計・配置を行いました。

 

次に、「SAP標準外のプロセスを実現」した事例です。日本の保険業界で必要とされる、業界標準プロセスを実現した例で、オンラインからのデータ取り込み、見積作成、更新、契約、会社確認、団体契約 に関わる業務プロセスおよび必要な帳票を整備しました。こちらも標準の契約や見積といった機能に蜜連携させた一連のプロセスの開発ということになります。定期的な保険内容見直しや、各種変更手続き、また補償設定も複雑で幾つものパターンが存在するので見積作成にも時間と労力が必要、契約者との確認作業、契約書変更作業等々、関連するプロセスも多岐にわたります。且つ、契約者ごとに頻繁に発生するものなので、業務プロセスの自動化やデータ入力作業軽減による生産性の向上は必須課題でした。

Snavi_IBSO05
図５：（事例２）SAP標準外プロセス実現 -コアインシュランス日本業界対応

 

そして、「医薬品・製薬業界」の事例です。この業界では、様々な業界特有の法定要件や業界標準の商習慣プロセスがあります。特に、「特薬管理」「JD-NETデータ交換」「リベート計算」は日本特有の法定要件や商習慣によるプロセスの実現が必要になります。この業界ではグローバル導入が進んでいるグローバルテンプレート導入が一般的で、グローバルで定義されたテンプレートを損なわずに、こういった日本特有のプロセスを実装することはとても難易度が高い開発となります。JD-NETデータ交換を例にとってみると、日本の医薬品・製薬業界では、製造業と卸業者の間で、JD-NETという業界標準のEDIを介して取引が行われます。受注や出荷、請求プロセスといった販売管理モジュール全体のプロセスを実現するためにインターフェースとマスターデータの拡張が必要になります。受注や請求、各マスタ情報をJD-NETに連携する為に、各情報を変換させてインターフェースが随所に必要です。これを実現する為には、グローバルで定義された標準部分の伝票やマスタの項目を拡張することも必要になります。グローバル導入の場合、この標準部分は既に他国で本番稼働していたり、並行して導入プロジェクトが進行しているケースが多いです。従って、各国での自由な開発に制限があったり、他国でも同じプロセスを共有しているので、標準機能との蜜連携をさせた開発をする為には細やかな設計や連携が必要となります。例えば受注伝票の項目拡張をするにあたり、本番稼働している国に障害が出ないようにしなければなりません。また、並行で導入している国との開発とオブジェクトが重複することも稀ではありませんので、開発の内容や順番は常に綿密な連携が必要とされます。通常の開発はグローバル側で集約させて開発ケースが多いですが、こういった日本特有の機能やプロセスはアセットを保有しているIBSOが担当し、グローバルの開発部隊と蜜に連携して導入を行いました。

Snavi_IBSO06
図６：（事例３）業界固有要件 -コアインシュランス日本業界対応（SAP JD-Net Connector機能拡張）

 

こういった開発は最初スクラッチ開発になりますが、次からはアセットとしてベースを流用して有効活用でき、一度、スクラッチ開発した拡張機能は、将来同様の要件が他プロジェクトで発生した場合に再利用可能なソリューションとして適用可能です。ソリューション再利用による拡張開発は、一から積み上げて機能を設計・構築するのではなく、既存ソリューションを土台に要件を出し入れするので、製品と同様に開発・導入における工数削減・時間短縮はもちろんのこと、ソリューション済機能とお客様要件を照らしあわせて、要件の必要性や妥当性、不足要件の気づきなど、要件検討においても一つのベースラインとして利用することも可能です。

 

 

パートナーとのコラボレーションによる柔軟な役割分担と共同でのシームレスなプロジェクト推進

IBSOサービスは、もちろんパートナー様企業が主導されるプロジェクトでも活用していただくことが可能です。IBSOサービスはパートナー様との協業で提供することが可能です。SAP単体での導入をご支援するプロジェクトより、パートナー様との協業でご支援するケースが多いです。そういった場合、導入をリードされるお客様やパートナー様のプロジェクトプランに合わせて開発が進められます。お客様やパートナー様の取り組みスケジュールやタスクに柔軟にあわせて、整合性を保つような進め方をしています。開発対象の中には、オブジェクトが重複するものも出てきます。そういった際にも、不整合が起きないように綿密な計画や調整をもとに、常に連携して進めます。例えば、要件定義フェーズでは、お客様あるいはパートナー様から連携いただいた概要要件をもとに、過去の類似するIBSO製品やソリューション事例を国内だけでなくグローバルレベルで有無を確認して、適用・流用可能なものがあるかどうかを調査します。事例の有無に関わらず、製品開発元からの製品ロードマップ情報に従って標準機能を最大限活用した概要ソリューション案をグローバルのExpertメンバーとともに検討して提示します。

Snavi_IBSO07
図７：パートナーとのコラボレーションによるプロジェクト推進

要件詳細化・設計フェーズでは、お客様およびパートナー様と常に連携を取りながら、ソリューションの軌道修正やブラッシュアップを行い、標準開発ガイドラインにしたがって仕様を最終的に固めていきます。開発機能外との結合テストや統合テストについても、プロジェクトタイムラインにあわせて支援することも可能です。実際の開発および単体テストの作業自体は、SAPの海外オフショア拠点で実施する場合が基本ですが、お客様およびパートナー様との要件すりあわせや仕様確認、QA対応等、プロジェクトコミュニケーションは日本にコンサルタントを配置するので、お客様およびパートナー様は基本的にオフショアメンバーと直接コンタクトする必要はありません。もちろん日本語でのコミュニケーションや日本語成果物も対応可能で、常にOne Teamとして連携して進めていきます。

 

 

SAP拡張開発のメリット – 準製品とサブスクリプションモデル

SAP拡張開発のメリットはどこにあるのでしょう。まずは、SAP準製品として拡張開発物を扱うことが可能です。SAP自らが拡張開発した場合、標準製品と同等のサポートサービスを提供することが可能となっています。具体的には、標準製品のアップグレードに伴う拡張機能の齟齬をSAPが回避するので、お客様は標準製品と同様に何も意識せずにシステム運用を行っていくことができます。もう一つはサブスクリプションモデルが適用可能であることです。お客様にとっての開発費の費用負担についてもオプションがあり、費用の持ち方について選択していただけます。通常、開発費用はプロジェクトの進行基準に従って、要件定義、設計、開発、テスト、受入といったプロジェクトの各マイルストーンのタイミングでそれぞれ請求・支払が発生し、原則、受入完了をもって開発費用のすべてを請求・支払完了させることになります。サポート費用についてはオプションとはなりますが、開発費用とは別に、サポートフェーズに定期サイクルで請求・支払を行っていくかと思います。もちろん、SAPでも同様の契約モデルを適用することも可能ですが、もう一つ、クラウド環境上で拡張開発する場合に、アプリケーション利用料(サブスクリプション方式)でお支払いいただくSaaS型クラウドサービスというのも提供しています。

サブスクリプション方式のメリットは以下の通りです。

  • 拡張開発したアプリケーションの利用開始から支払となり構築フェーズの段階では費用が発生しない
  • キャッシュアウトの観点でも費用の平準化が狙え、柔軟なIT投資が可能
  • アプリケーション利用料にはもちろん保守サポートが含まれるので、煩雑なメンテナンス作業から解放され、またシステムのバージョンアップ・アップグレードによる影響も意識する必要がない

Snavi_IBSO08
図８：IBSO拡張開発の契約モデル

この契約モデルは、利用料払いになることで、ある意味、設備投資を経費に、ソフトウェア資産（CAPEX）をシステム利用料（OPEX）にする新しいフレームワークです。サブスクリプションに含まれる保守サポートは、通常の障害対応や、各種問い合わせ対応、コードアセスメント、アップグレードに伴う構築機能のコンフリクト解消以外に、小規模な機能改善（仕様変更）についてもサポート範囲に含まれているので、こういったところも有効活用しながら、後続フェーズの機能拡張等を効率よく進めていくことが可能です。

 

 

SAP拡張開発によるイノベーションの実現 – Enabling Customers to Make Innovation Real

IBSOでは、これまでの長きにわたるグローバルにおける各業界実績・経験に基づく知見とビジネス/テクノロジー専門家、そしてグローバル組織力を活かし、お客様との共同開発アプローチによるテクノロジーおよびビジネスイノベーションへの取り組みをグローバルで積極的に推進しています。お客様の変革実現に貢献する真のパートナーとして、お客様と共同でビジネス全体をイノベーションすることにより、ビジネスオペレーションとカスタマーエクスペリエンスの融合をスピーディーに実現し、お客様の競争優位性を最大限に高めます。

  • User Experience Innovation – 顧客体験と従業員生産性を向上
  • Process Innovation – ビジネスプロセス変革のための高価値領域を特定し、新しい顧客価値を提供
  • Business Model Innovation – 新しいビジネスチャンスを特定し、新しいビジネスモデルを構築
  • Innovation Culture – お客様企業でイノベーション文化を確立

 

下記にIBSOが取り組んだグローバルでのイノベーション事例がいくつか公開されておりますのでご参考いただければ幸いです。

 

 

まとめ

まとめになりますが、IBSOが拡張開発を実施することによるメリットは何でしょうか。まず、お伝えした通り、製品やソリューションの再利用が可能です。これにより、要件定義・仕様決め・開発の各タスクにおける対応工数が削減されます。もちろん私共は製品を提供しているベンダーですので製品を熟知しています。プロセス全体をシームレスに整合性を担保した開発を提供します。お客様やパートナー様が担当する部分との連携ポイントにおいて、代替案やアドバイスなども提供できます。そして、開発・稼働後のサポートも製品・拡張部分と分けることなく、あくまでも製品と同様にお客様はサポートを教授することができる、というのがポイントになります。

本記事ではお伝えできなかったグローバル事例も多数ございます。もしIBSOサービスにご興味がございましたら、あるいは本記事に関してご質問やご不明な点ございましたら、お気軽にお問合せ下さい。

是非、IBSOサービスをご活用いただき、製品ベンダーであるSAPを使い倒していただければ幸いです。

関連記事