『業務プロセス改善』(Business Process Improvement)なる言葉がある。

BPI などと略して言う人は、かなり重度の「カイゼン病」だ。しかし、常日頃から「業務プロセス」のあるべき姿(To-Be)を妄想し続ける事はスバラシイ。所詮、全ての日常業務は科学技術の進歩とともにカイゼンされるべき存在なのだ。『業務プロセス管理システム』(BPMS)なんてカイゼンを構想するためのツールにすぎない。そうだ。カイゼンなくして、成長なし!(荒、鼻息)

さて、、、各社員が「業務カイゼン案」を報告する業務プロセスは、これまでにも紹介してきた。すなわち
の2つのフローは、組織として改善アイデアを集約する上で非常に有効な仕組みと言える。

しかし、アイデアと言うものは、ふとした瞬間に舞い降りてくるもの。特に、「良いアイデア」ほど、舞い降りてくるタイミングが悪い。。。 寝床の中、トイレの中、風呂の中。。。 そして次の瞬間から徐々に揮発していく。(もう少し都合良いタイミングで舞い降りてきて頂きたいものだ。 by ピタゴラス)

そんな時には、(防水)スマホのメーラで「アイデア」をメモしておこう。

以下の業務プロセス定義は、「アイデア乱文メモ」をメール受信するとメール送信者のマイタスクに下書き保存しておく仕組みが追加されている。つまり、次に仕事デスクに座った時に、その「アイデア乱文メモ」を清書しキチンとした「改善案」として提出するのだ。

[カイゼン提案フロー(強制割当・メール開始対応)]

業務プロセス管理(BPM)の目的は、「継続的な業務改善」だ。

確かに、一度「業務プロセス定義」を作成すれば、業務データは効率よく受け渡しされるようになり、業務標準化の名のもとノイズの少ない業務データが蓄積されていくだろう。つまり大きく改善された気になる。しかし一方で、もしそのままその「業務プロセス定義」を使い続けたとすれば、やがて業務の進め方は陳腐化し市場環境の変化に対応できなくなるだろう。

言うまでも無い話だが、継続的な改善を実現するためには、「業務プロセス定義」の改良案が社内から自然と湧き上がり続けることが望ましい。すなわち、
  • 【業務の流れ】をXXXの様に変えてはどうか?
  • 【入力画面の文言】をXXXの様に変えてはどうか?
といった改善案が各社員の自由意思によって継続的に発信されるべきだ。前回記事『業務プロセスを改善するための業務プロセス!?』では、全社員がいつでも提案できる環境について考察した。

ただ、現実的に継続的に課題を指摘し続ける事はムツカシイ。 そこで今回は前回サンプルをさらに拡張し、なかば強制的に改良案を提出させる仕組みについて考察する。

[カイゼン提案フロー(強制割当対応)]

業務プロセスを改善し続けたい。みんな、そう思う。
  • 「フロー」を変えたい
  • 「データ項目」を変えたい
  • 「チーム編成」を変えたい
とは言っても、(a)「改善すべきポイント」が何なのか?、を把握できている上司は少ない。いくつもの課題を把握できているとして、(b)今どの改善の優先度が高いのか?、も把握している上司は珍しい。更に課題の優先度を把握しているとして、(c)どの様に改善すべきか?、まで把握している上司はほとんど居ない。。。

業務プロセスを改善するプラットフォーム(BPMシステム)があっても、実際にルールの変更を行うのは人間だ。

コンピュータが、会社の方針、メンバの個性、社会の情勢、、、などを理解して、人間に対して「このような改善が宜しいかと」と、、、「あるべき業務プロセス」を提言してくれる日は残念ながらマダマダ先の話だ。まずは改善すべきポイントの把握から、地道に実践していくしかない。
  • a. 改善ポイントの把握
  • b. 改善ポイントの優先順位の考察
  • c. 改善方針の策定(コンセンサス)
以下のワークフローは、(まずもって)、上司が「a.改善ポイントの把握」を行えるように、現場社員が「改善ポイント」を提案する業務プロセスだ。仮に全社員が週に一つ提案するだけでも、相当な数の「改善すべきポイント」が蓄積されるだろう。

ちなみに、コレ、、、「言うは易し、行うは難し」だ。
  • すべての提案に対して、一律500円の報奨金を出す
  • 最も価値ある提案に対して、毎月 MVP (Most Valuable Proposal) の表彰をする
などの工夫を講じるべきかもしれない。

[カイゼン提案フロー]

前回に引き続き「社内アンケート業務」とよばれる業務について考えたい。前回は、最大8人に対して「任意のアンケート」を実施できる汎用ワークフローについて考察した。ポイントは、
  • 8人分のスイムレーンを用意し、
  • 8人分の回答データを格納できるように設計した
の2点だ。いつでも色々なアンケートを実施できる所はスバラシイ。

しかし、この方式のワークフローでは50人や100人に対するアンケートは現実的ではない。もちろん、
  • A. 100のスイムレーンを用意し(!!)、さらに
  • B. 100人分の回答データを格納できるように定義する(!?!)
と言う拡張を行うのも悪くはないのだが、、、やはり色々な意味でナンセンスだ。 中でも特に問題視すべきは、データ集計を行うに「非常に使い勝手の悪いフォーマット」になってしまう点だ。集計という視点に立てば、「アンケート実施」の単位で記録されるのではなく、「アンケート回答」の単位で記録されるようにしたい。

以下の業務プロセス例は、まず「B.データ項目が発散する問題」を解決すべく、「アンケート準備」の業務プロセスと「アンケート回答」の業務プロセスの2つの業務プロセスに分けて定義した例だ。準備が1に対して回答がN、、、その「繰り返し単位」の違う業務プロセスをつなげる事で、それぞれ集計しやすいフォーマットになる。

[アンケート準備フロー]

[アンケート回答フロー(ユーザ指定開始)]