コラム
2021年3月29日

社内導入におけるプロセスイノベーションとマイニングの効果検証【第2回(前編)】

第2回(前編):PoCと実装開発の苦労 

BPM

デジタルトランスフォーメーション事業本部
ビジネスイノベーション事業部
BPMソリューション部
部長 荒谷 剛

【プロフィール】
 入社以来基幹系システムを中心に設計、開発、PMに従事
 その後脱Notes intra-mart移行案件の提案や、プロジェクトの責任者を担当、
 現在はintra-mart開発事業を統括

【保有資格】
 PMP(Project Manager Professional)
 Signavio Process Manager 認定
 Signavio Process Intelligence 認定

コラム概要

アグレックスは、働き方改革を積極的に推進し、業務の効率化・自動化を行っています。既存のIT資産を「使い続ける」と共に、 クラウドやAI、IoT、RPAなどの新技術・サービスを「組み合わせて使う」ことで、 変化やニーズに対応できる先進技術への移⾏を行っています。
本コラムでは当社の社内業務で、プロセスイノベーションとマイニングを実践し、その実際の効果について全4回でお届けします。

アジェンダ

【2021年3月29日配信】
第2回(前編):PoCと実装開発での苦労
【関連コラムはこちらからご覧ください】

第2回(前編):PoCと実装開発での苦労

第1回では、社内業務プロセスにおける課題とBPMとの出会いについて、ご紹介をしました。第2回では、Poc(=Proof of Concept)と実装開発の苦労についてご紹介します。

PoCでは様々な3つの仮説を中心に検証する目的で実施をしました。その他の検証ポイントはまとめの表にて説明します。

  1. 1Signavioのシミュレーション機能は有効か?
  2. 2SFAであるDPS for SalesからSignavio PIで利用可能なプロセスログが取得できるか?
  3. 3IM-BPMでRPA、Forma、IM-WFの統制が取れるか?

1.Signavioのシミュレーション機能は有効か?

Signavio Process Manager(以下SPM)は、BPMN2.0(=Business Process Model and Notation)のフォーマットで業務フローを定義することができます。SPMは、ブラウザで簡単に業務フローを描くことができます。PoCでは「リード発生~見積~受注確定」までの案件(商談)管理プロセスと、「見積~受注」、の基幹システム連携までの販売管理プロセスの現状(AsIs)モデルを作成しました。

SPMは単なる業務フローだけでなく、モデリングした業務フローに、タスクを処理する「人数」、「コスト」、「発生頻度」、およびシミュレーションを行う「期間」をパラメータに設定し、設定期間内の処理件数や、所要時間、リソース、およびコストをシミュレーションすることができます。現状(AsIs)モデルに、実際の業務を想定し、パラメータを設定後、コストを計算してみました。

SPMではリソース不足で処理待ちとなるタスクはボトルネックとして表示されます。新業務プロセス(ToBe)では、このボトルネックを解消する業務をデザインします。
例えば、システムへの多重入力や報告資料の作成などは、情報の一元管理や他システムへの自動連係を行うようにデザインします。こうして現状の課題を解決するようなToBeモデルを作成し、現状モデル(AsIs)と同じようにパラメータを設定し、できるだけ同じ条件でシミュレーションを実行します。
シミュレーションの結果により、新業務プロセス(ToBe)の効果が、定量的に見える化できましたので、シミュレーション機能は有効であると判断しました。

■図1:Signavio PMシミュレーション結果画面
■図2 :Signavio PMシナリオ登録画面
■表1: ToBeコスト削減効果(Signavio PMシミュレーション結果)
※実データのため、金額については、ぼかしを入れております。

2.SFAであるDPS for SalesからSignavio PIで利用可能なプロセスログが取得できるか?

DPSでは、案件(商談)や営業員の活動日報、顧客(取引先)および担当者(パーソン)を有機的に連携させ、営業や見込管理にかかわる必要な情報を一元管理する事が可能です。Signavio Process Intelligence(以下SPI)で、システムから取得できるイベントログから、業務プロセスを処理するために要した時間、傾向や標準プロセスからの逸脱頻度等を分析し、新たなインサイトを得て業務プロセス改善につなげるために、DPSからプロセスログが取得できるかが、重要になります。
SPMではシステム開発前のモデリングの段階での仮説検証で使用しますが、SPIはシステム稼働後のファクトデータに基づく業務分析およびシミュレーションを行うツールです。

SPIで分析するためのイベントログは以下の3つの情報が必要になります。

  • いつ(When)
  • 何のプロセス(What)
  • 何をした(How)
  •  

販売管理や生産管理等、対象システムがイベントログ記録している前提で、各プロセスの定義や手順が明確であれば、ログは取得しやすいですが、営業活動のプロセスや手順をはっきり定義できない特長がありますので、どのようなログをとれば分析ができるのか、そもそもログは取得できるのかを調査するのに苦労しましたが、DPSの機能を調べていくうちに、営業活動により案件や商談の状況や状態が変化していくことに気づき、活動とそれに紐づく「活動を行った時点」の案件状態を取得してみることにしました。

DPSのテーブル構造を分析した結果、情報は取得できることがわかりました。SQLで活動と案件を結合しintra-martの標準機能であるView Creatorで表形式にし、CSV形式で出力しSPIに取り込んだところ、イベントログとして認識され、分析を行うことが可能になりました。
DPSは、これから本格利用することになりますので、実際の活動に基づく意味のある分析はこれからとなり検証はできていませんが、仕組みとしてはできることが確認できました。

■図3: DPS活動履歴ログの出力

3.IM-BPMでRPA、Forma、IM-WFの統制が取れるか?

SPMでデザインした新業務プロセス(ToBe)モデルをintra-martのBPM基盤であるIM-BPMに登録し、新たにシステムをIM-BPM上で作成しました。IM-BPMにシステム開発における上流工程のアウトプットである業務フローを、そのままintra-mart上で表現し、開発した画面やワークフローを業務フロー上に組み込みました。
この結果、BPMNによる共通表記で、業務プロセスがシステムと一体となり、可視化および統制が可能となりました。

また、業務運用においては業務フロー通りにシステム間がバトンリレーされる動きをするので、処理漏れなどの属人性が排除されます。デザインした業務フロー上で、どの伝票がどのプロセスにいるかという事も可視化することができるようになりました。IM-BPMからIM-Forma DesignerやIM-WorkFlowで開発した画面およびプロセスを組み込み、プロセスの順番を入れ替えるといったことが容易に実現できます。

BPMでは、業務改善サイクルを回す必要があるため、システムの組み換えが容易にできることは最重要要件です。
RPAは、検証を行った環境の問題で、IM-BPMから呼び出すことは確認できませんでしたが、カタログベースで、問題ないことは確認しているので、開発フェーズで環境を整備したうえで確認することにしました。

■図4: IM-BPM実行可能モデル

PoCでは、3つの仮説を概ね概ね検証することが実施できました。

〇:問題なし ▲一部問題あり引き続き検証 ×;問題あり

■表2: 検証結果まとめ(本文中の①~③含む)

次回第2回(後編)で、PoCと実装開発の苦労についてご紹介したいと思います。