• BPM
  • 2021/03/29

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

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


ソリューション事業部
ソリューション開発第2部
部長 荒谷 剛



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

コラム概要

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

アジェンダ

【2021年3月29日配信】
第2回(前編):PoCと実装開発での苦労

 

【関連コラムはこちらからご覧ください】
第1回:当社の非効率作業の数々とBPMとの出会い
第2回(後編): PoCと実装開発での苦労
第3回:ついに本番運用へ
 
【近日配信】
第4回:プロセスマイニングで本当に効果が上がったのか?

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

第1回では、社内業務プロセスにおける課題とBPMとの出会いについて、ご紹介をしました。第2回では、Poc(=Proof of Concept)と実装開発の苦労についてご紹介します。
 
PoCでは様々な3つの仮説を中心に検証する目的で実施をしました。その他の検証ポイントはまとめの表にて説明します。
 

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

 

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

Signavio Process Manager(以下SPM)は、BPMN2.0(=Business Process Model and Notation)のフォーマットで業務フローを定義することができます。SPMは、ブラウザで簡単に業務フローを描くことができます。PoCでは「リード発生~見積~受注確定」までの案件(商談)管理プロセスと、「見積~受注」、の基幹システム連携までの販売管理プロセスの現状(As Is)モデルを作成しました。
 
SPMは単なる業務フローだけでなく、モデリングした業務フローに、タスクを処理する「人数」、「コスト」、「発生頻度」、及びシミュレーションを行う「期間」をパラメータに設定し、設定期間内の処理件数や、所要時間、リソース、及びコストをシミュレーションすることができます。現状(As Is)モデルに、実際の業務を想定し、パラメータを設定後、コストを計算してみました。
 
SPMではリソース不足で処理待ちとなるタスクはボトルネックとして表示されます。新業務プロセス(To Be)では、このボトルネックを解消する業務をデザインします。
例えば、システムへの多重入力や報告資料の作成などは、情報の一元管理や他システムへの自動連係を行うようにデザインします。こうして現状の課題を解決するようなTo Beモデルを作成し、現状モデル(As Is)と同じようにパラメータを設定し、できるだけ同じ条件でシミュレーションを実行します。
シミュレーションの結果により、新業務プロセス(To Be)の効果が、定量的に見える化できましたので、シミュレーション機能は有効であると判断しました。
 
 
■図1:Signavio PMシミュレーション結果画面
 
  
■図2 :Signavio PMシナリオ登録画面
 
  
■表1: To Beコスト削減効果(Signavio PMシミュレーション結果)
※実データのため、金額については、ぼかしを入れております。
 

②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活動履歴ログの出力
 

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

SPMでデザインした新業務プロセス(To Be)モデルを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回(後編)で、実装開発の苦労についてご紹介したいと思います。

 

関連のコラムはこちらからご覧ください

第1回:当社の非効率作業の数々とBPMとの出会い
 
第2回(後編): PoCと実装開発での苦労
 
第3回:ついに本番運用へ

  • 働き方改革をリード
  • DXをサポート