業務プロセス、改善サイクルを回すコツ

業務プロセスの改善サイクルを回すのは容易ではない。ホントは毎月毎週のようにコツコツとPDCAを回したい。しかし、現状把握（Check）や対応（Act）に時間が取れないのが実情？業務プロセス定義をバージョンアップする（Re-Plan）なんて夢物語？？ここでは「少しの工夫」で「小さな改善」を繰り返す方法について提案してみたい。

1. 集計も自動化！

自動開始（毎週や毎月）の「集計＆通知」が好き。

要は、業務データを無人で期間集計してくれる（そして通知してくれる）業務プロセス。ソレは「業務プロセスに流れたデータを集計する業務プロセス」というコトになる。（ヤヤコシイ…）

平たく言えば “自動レポート機能” だ。

たとえば、、、『立替金精算プロセス』に対して『前月立替金の集計プロセス』、、、のように集計用の業務プロセス（ワークフローアプリ）を作るのだ。それらは勝手に始まり（タイマー開始）、途中の処理工程も全て無人で、そして勝手に終わる。そして、最下流に「関係者へのメール通知」や「タイムライン投稿」が配置されるのがオキマリとなる。

222-立替金精算
- 222-notice-前月立替金の集計と通知　（←毎月・スタッフ別集計）
- 222-cross-前月立替金の集計　（←毎月・全社集計）
242-出退勤報告
- 242-notice-前週の出勤簿の通知　（←毎週・スタッフ別集計）
242b-アルバイト出退勤報告
- 242b-cross-アルバイトの前月勤務時間集計
216-Flexible-Billing-Cycle
- 216-notice-Flexible-Report
（などなど）

▼多用しているデータ抽出工程『Questetra BPMS: 案件, 指定データTSV一括抽出』

日付フィルタされた複数の案件データを複数行のTSV文字列として抽出します。抽出項目は “string:0,date:2,select:3″ のようなCSV書式で指定します。Tabコードと改行コードは、自動的に削除されます。”ファイル型” はファイル名が、”選択型” は選択された選択肢の表示テキストが抽出されます。

2. ソレって、モニタリングでわ？

確かに、わざわざ “集計用のプロセス” を実装する必要なんてナイ。業務データの期間集計をしたければ、その時々に「モニタリング機能」を使えば良い。いつでも、様々な角度から、過去のデータを集計できる。

そう。。。”集計プロセス” たちは、その「モニタリング」を自動化して、（通知して）、いるに過ぎない。

だがシカシ！、、、だが然し！！、、、なのだ！？！

3. いつでもデキル＝永遠にシナイ

「集計の無人化」をアレコレ実践してみて、改めて思う。

人間にとって「自分の意志で情報を見に行く」っていうのは、実は “とてもシンドイコト” なのだ。

興味がない訳ではない
モチベーションが湧かない訳でもない

が “過去データを振り返ること” はあまりしたくないのだ。

単に「振り返りたくない」と表現してしまうと語弊があるので、掘り下げて考えてみたい。

むしろ “振り返るコト” は、”目の前にある新しいシゴト” に比べれば、大概はラクだ。（見て眺めれば良いだけ、なのだから…）　それでも人間は、“A: 振り返るコト” を “B: 目の前にあるシゴト” と比べてしまうと、ついつい「後で…」と考えてしまう生き物なのだ。　それは「今すぐヤル」ということ自体にメリットが無いのだ。「後でやっても同じ」→「後でやろう」。そして、その繰り返しで、結局 “集計データ” を見る機会が少なくなってしまう。

もし「KPIを集計し報告すること」それ自体が仕事なのであれば、きっと “後回し” にはしない。しかし、そのような場合、集計作業が完了した時点で「振り返り見るパワー」が残っていない。　たしかに、（ウマく言えないが）、KPI情報は「見る」のかも知れない。しかし、きっと「観ることができていない」のだろう。そして「診ることもできていない」のだろう。そして何の改善（PDCAサイクル／BPMサイクル）にも繋がらない。

そもそも “いつでも見ることができるモノ” と思ってしまった瞬間に、“いつまでも見ないモノ／めったに見ないモノ” にしてしまうのは、人類の必然なのだろう。

神戸に20年間住んでたクセに、一度も「異人館」に行かなかったようなものだ。。。（違）