ワークフローサンプル: 第560話：経費精算クラウドを使わない理由(2)

業務：経費の申請と精算

クラウド型ワークフローで「経費申請フロー」のシステム化を実現した！（第559話参照）

もともとワークフローシステムには、他にも様々な「業務フロー」が定義されている。なので、立替金の申請だからといって「経費申請のためのシステム」にログインし直す必要はない。

しかも「課長承認」や「部長承認」といった工程での滞留状況が、業務フロー図上に可視化される。申請した社員も、決裁した上司も、取締役達も、、、「どの工程にどんな申請があるのか」を折々に確認するようになった！　そして他人のアウトプットについて助言やコメントが付けられるケースも増えてきた！　やはり「どこで滞留しているのか？」が分かる事って、ホント大事だ！

課題：リアルタイム集計

しかし、、、「決裁一覧や決裁総額が的確に把握されているか？」については、やや疑問だったりする。。。

つまり、申請の中には「経費申請を取り止める」に至ったものも多数混ざっている。全ての申請を単純集計しただけでは「正確な経費の総額」にならないからだ。。。

う～む、精算業務に特化された『経費精算クラウド』を使った方がイイのだろうか？？

[経費精算フロー-案件ステータス]

解決：業務ステータスの管理

様々な視点から案件が「集計」される業務では、業務オリジナルな「案件ステータスコード」を持たせることを検討します。

この経費精算フローの場合は『精算進捗ステータス』というデータ項目（数値型）が定義されています。そして案件の進捗に合わせて管理コードが自動的に書き換えられる仕組みになっています。つまり、第1工程が完了すれば「+1」され、第2工程が完了すれば「+10」され、第3工程が完了すれば「+100」されます。また、途中否決された申請は「-1倍」されます。 ※ 自動工程［サービスタスク（データ設定）］

0. 申請準備中(初期値)
1. 申請済み上司承認待ち
10～99. 課長承認済み(経理確認待ち)
100～999. 部長承認済み(経理確認待ち)
1000～. 課長・部長・経理の全て承認済み
-1～-999. 申請者による取下
-1000以下. 経理による却下

たとえば経費支出を抑制したい「課長」の視点であれば、「自分が承認した案件」（ステータス：10以上）や「自分は承認したものの部長に否決された案件」（ステータス：-100以下）について集計／モニタリングしたいところです。もし月単位でのモニタリングを頻繁に行うなら、以下のようなフィルタリングを設定しておくべきと言えるでしょう。

『精算進捗ステータス』が "10以上"
『立て替えた日』が "前月１日より後"
『立て替えた日』が "前月末日より前"
『立替人所属組織』が "営業部"

※ #today.addMonths(-1).getFirstTimeInMonth()
※ #today.addMonths(-1).getLastTimeInMonth()

考察：「不連続値としてのフラグ」と「連続値としての数値」

課長と部長ですら「集計したい案件」は異なります。

業務プロセスを設計するプロセスオーナーは、社内ユーザが「どの様な集計や分析を行いたい」のか、社内ユーザが「どの様な集計や分析を行うべき」なのか、、について、想像力を働かせるべきです。

ワークフローに流れた案件
ワークフローに流れている案件

について様々な方法でグルーピングしたい場合には、まず「フラグでの管理」を検討します。たとえば「課長承認済み」や「部長承認済み」といったデータ項目を持たせることでニーズに応じたフィルタリングを簡単に作成することができます。

しかしフラグ管理は、フラグの数が多くなるにつれ条件式の改修が複雑になる傾向にあります。また、データ分析やデータ集計の観点で言えば「似ているもの」の抽出が困難になります。（データマイニング、クラスター分析、業務プロセス改善）

もし業務上の案件ステータスについて、その類似度が「数値」で表現できるようであれば、積極的に「数値コードでの管理」を検討します。案件の属性値が連続値として管理されていれば、日常活用されるフィルタがメンテナンスしやすくなるだけではなく、様々なグルーピング（クラスター）を気軽に抽出・集計できるようになります。（正確に言えば非連続な離散値）

＜オペレーティング画面：どれか（１.を入力中の状態）＞