SAP Cloud ALMによるビジネスプロセス監視の重要性

[SaoriNishimura]

はじめに

本番稼働後のSAPシステムの監視では、システム全体のリソース・パフォーマンス・ショートダンプなどの障害など、ベーシス観点の項目を対象することが一般的です。しかし、これらの監視項目が正常な値を示していたとしても、システムに実装されているビジネスプロセスが滞りなく行われているかどうかは評価できません。

例えば、システムリソースに十分な余裕があり、また、エラーなどが発生していない状況でも、想定される件数の伝票が登録されていない、処理が未完了のまま滞留している伝票が多い、などといった業務観点での問題が発生している場合があります。

このためSAPでは、ベーシス観点での監視に加え、業務視点での監視を行う事を推奨しております。

本ブログでは、運用向け SAP Cloud ALM の機能のひとつである、ビジネスプロセス監視(Business Process Monitoring、以下BPMon) を利用した、ビジネスプロセス監視の重要性についてご紹介します。

SAP Cloud ALM については、以下の SAP Blog を参照下さい。
　SAP Cloud ALM概要とユーザ/システムランドスケープの登録
　SAP Cloud ALM運用機能概要とSAPオンプレミスとの接続方法

ビジネスプロセス監視(BPMon) in SAP Cloud ALM

ビジネスプロセス監視(BPMon) は、SAPシステム上で実装されているお客様のビジネスプロセスフローにおける問題の検出から修正までのライフサイクルを支援します。

 複数のSAPソリューションを横断した監視ストラクチャが事前定義されており、技術的な有効化設定を行うだけで、ビジネスプロセス全体の健全性を評価するための可視化が行われ、原因分析・修正アクション検討の準備が整います。ます。これにより、業務部門のユーザとIT部門のユーザの両方が、プロセスの異常を直接特定し、深刻な状況になる前に対応することが可能になります。

また、ユーザの責任範囲に応じて関連する監視項目・内容のみを表示するダッシュボードを作成したり、監視項目に任意の閾値を設定しアラート通知を行うことで、迅速な問題解決アクションの実行を支援します。

事前定義済みの監視ストラクチャ

エンドツーエンドプロセス

以下のエンドツーエンドプロセスが監視対象として定義されています。

• 採用から退職(Recruit to Retire)
• リードから入金(Lead to Cash)
• ソーシングから支払(Source to Pay)
• 設計から運用(Design to Operate)

エンドツーエンドプロセスには、それを構成するサブエンドツーエンドプロセスが紐づいています。
例として、エンドツーエンドプロセス「リードから入金(Lead to Cash)」の構成を記載します。

• リードから入金(Lead to Cash)
  　1. リードから案件(Lead to Opportunity)
  　2. 案件から見積もり(Opportunity to Quote)
  　3. 見積から受注(Quote to Order)
  　4. 受注から入金(Order to Cash)

1.～3.では SAP Cloud for Customer、4.では SAP S/4HANA が監視対象システムとなります。
このように、複数ソリューションを横断した監視を行うことが可能です。

プロセス

さらにサブエンドツーエンドプロセスは、複数のプロセスにより構成されています。
例として、「リードから入金(Lead to Cash) > 受注から入金(Order to Cash)」に紐づくプロセスを以下に記載します。

• リードから入金(Lead to Cash)
  　4. 受注から入金(Order to Cash)
  　　i. 受注管理
  　　ii. 受注履行
  　　iii. 請求管理
  　　iv. 支払回収
  　　v. 債権管理

主要業績指標(KPI)

プロセスには、多くの主要業績指標(Key Performance Indicator、以下KPI)が提供されています。KPI は、監視対象システムからデータを取得する単位でもあり、取得されたデータ内容に応じて、プロセスパフォーマンスを評価します。

以下は「受注から入金(Order to Cash)」プロセスの KPI の一部を表示しています。

 各パネルの左のアイコンは、KPIカテゴリを示しています。KPIカテゴリは、スループット(Thoughput)、バックログ(Backlog)、リードタイム(Leadtime)、例外(Exception)の4つがあり、KPIの性質により分類されています。

「受注から入金(Order to Cash)」プロセスのKPIをいくつかピックアップし説明します。
図中のKPIパネルについては、実機のKPI名称のままではなく、KPI内容を理解しやすい文言に一部変更しています。

スループット(Throughput)

スループット(Throughput) では、指定した期間内に登録された業務プロセス上重要なオブジェクト(販売伝票、出庫伝票など)の件数をカウントします。
期間は【過去1時間】【今日】【昨日】【今週】【本四半期】などの事前定義済みのものを選択することが出来る上に、要件に応じたカスタム時間枠を作成し選択することも可能です。
プロセス全体のスループットを確認することで、それぞれの業務処理のシステム上のボリュームを把握することが出来ます。

登録件数が想定件数よりも極端に少ない場合、登録処理に問題が発生している可能性が懸念されます。別システムからのインターフェースファイルの取り込みに失敗している、カスタマイズ不備により予期せぬエラーが発生し登録処理が完了していない、など、様々な問題が考えられるため、即座に状況を把握し、原因を究明、対応を行うことで、業務への影響を最小限に抑えることが重要です。特に本稼働直後や、追加コンポーネントの後続稼働や利用ソリューションの変更などシステム上の大きな変更を行った直後は、これらの問題が発生しやすくなります。

逆に、登録件数が継続的に想定件数を大幅に上回る場合、データボリュームのサイジングが正確でないことが懸念されます。これにより、稼働前のテスト時には発生しなかったパフォーマンス問題が発生したり、想定より早くメモリ容量の上限に達したり、HANA DBの制限である20億レコード/テーブルを超過する可能性が浮上する懸念があります。これらの懸念について、早めに対応を検討する必要があります。

さらに、それぞれのオブジェクトに関連する項目で件数比較を行うことも可能です。
例えば、「販売伝票」であれば【販売伝票タイプ】【販売組織】【流通チャネル】【得意先】などの項目ごとの件数分布を確認したり、これらの項目でフィルタリングをすることで特定条件の販売伝票に絞り込んで件数を把握することが出来ます。

バックログ(Backlog)

 バックログ(Backlog) では、期日までに処理が行われていない伝票や不完全な伝票、ブロックされている伝票など、業務プロセス上の滞留を示します。

例えば、「不完全な販売伝票数」は、必須項目が未入力の販売伝票の数を表示します。販売伝票が不完全な場合、エラーが表示されるものの、保存することが可能です。しかし、マニュアルで必須項目に入力を行いエラーを解消の上保存するまで、後続の出荷、出庫処理に進むことが出来ません。特に件数が多い場合などはマニュアルでの修正作業が間に合わず、得意先への納入が遅延する可能性があります。
どの項目が未入力で「不完全」状態となってしまっているのかを分析し、未入力となる原因を究明する必要があります。外部システムから渡されるデータに不備がある、マスタ設定に不備がある、入力担当者へのスキトラが不十分でオペレーションミスがある、など、様々な原因が考えられますが、それに応じた対応策を検討することで、マニュアル作業を減らし、ビジネスプロセスの効率化を目指すことが推奨されます。

次に、「支払期日を超過した未消込債権数」は、FIに転記された得意先債権(FI-AR)のうち、設定された支払期日を過ぎているにも関わらず未入金(＝未消込)のものの件数を表示します。この数字が非常に大きい場合は、業務的な問題、システム上の問題、その両方があることが考えられます。
業務的な問題：得意先が実際に支払期日までに入金を行っていない場合は、稼働資金不足に陥る可能性があるだけでなく、重要な経営指標であるDSO(売掛債権回転日数)やCCC(キャッシュコンバージョンサイクル)に多大な影響をあたえます。得意先ごとに期日超過日数や金額、過去の傾向を分析した上で、適切な与信管理や督促管理を行う必要があります。
システム上の問題：伝票登録日が特定の期間に集中していたり、移行ユーザなどの特定のユーザにて登録された得意先債権は、業務上問題の無い、システム上の不要データである可能性があります。これらについては、システムをクリーンな状態に保つためにも、しかるべき方法にて消込を行う必要があります。

リードタイム(Leadtime)

リードタイム(Leadtime) は、ビジネスプロセスの特定の処理間に費やされた平均期間を示します。

「販売伝票登録から請求書登録期間」では、【販売伝票タイプ】【販売伝票明細カテゴリ】【販売組織】【流通チャネル】などの項目ごとに日数を比較し、比較的サイクルタイムの長い販売組織などについては、業務処理に非効率な部分がある可能性があると捉え、該当販売組織でフィルタリングをした上で各バックログKPIを分析するなど、業務改善プロセスを開始することが出来ます。

例外(Exception)

例外(Exception) では、特定トランザクション実行時に発生したエラーを表示します。

「支払実行中の例外」では、自動支払プログラム(*)実行時に発生したエラーメッセージを一覧で確認することが出来ます。エラーの原因としては、支払ブロックが設定されている、支払方法が設定されていない、取引先マスタデータに必要な情報が設定されていない、などがあげられます。
自動支払プログラムでエラーが発生した場合、早急に該当未消込明細のマニュアル修正を行わないと仕入先への支払期日に間に合わなくなる恐れがあります。特定の仕入先が繰り返しエラーとなる場合などは、仕入先マスタ不備の可能性があり、仕入先マスタの整備を行うことでこれらのリスクを低減させることが出来る場合があります。
(*) 自動支払プログラムは、一般的に「仕入先債務」の支払処理に用いられますが、「得意先債権」を含めた実行も可能もであるため、本プロセスの関連KPIとして配置されています。

まとめ

本ブログでは、ビジネスプロセス監視(BPMon: Business Process Monitoring) を利用した、ビジネスプロセス監視の重要性について、監視対象プロセスや主要業績指標(KPI)の内容を例に挙げ説明してきました。

今回取り上げた KPI 以外にも、複数のSAPソリューションに関連した90以上のKPIが用意されており、様々な観点でのビジネスプロセス監視を行うことが出来ます。全KPIについての情報は、Business Process Monitoring Content (sap.com) より確認頂けます。
さらに、SAP Cloud ALM は継続した機能拡張が行われており、今後も KPI は拡充される予定です。SAP Solution Manager にて実装可能だった カスタムKPI についても実装に向けたロードマップが発表されており、将来的には SAP Cloud ALM での十分なビジネスプロセス監視が可能になると考えております。

SAP Cloud ALMを有効化し、ビジネスプロセス監視(BPMon)の利用を開始したいとお考えであれば、貴社担当営業、または、TQMまで是非ご相談下さい。
SAP Cloud ALM概要説明WS、有効化支援、ビジネスプロセス監視(BPMon)活用支援など、さまざまな支援サービスをご用意しております。