人間は失敗する生き物。
人間は神の失敗作。
失敗は成功の母。

ん???、まぁナンでもイイです。とにかく失敗した時には、反省しましょう。再発の防止に努めましょう。

マジメな話、『失敗事例』は企業にとって「非常に大切なナレッジ」だ。いつ誰がどの様な失敗をしたのか。社内で共有し、また、いつでも参照できる様にしておきたい。そして、失敗や失敗した人を非難するのではなく、同じ失敗を繰り返さないための「教材」としたい。

1年を振り返る時、新人が増えた時、業務フローを変える時、などに、チームみんなで『「ミス・失敗」を思い出す会』を催すのも良いだろう。

[反省文報告ワークフロー]


銀行口座に入金があった際に「入金通知」がメールで届く、、、
と言うサービスはある。でも、発行済み請求書との付き合わせ作業(入金消し込み)を無人化するには、この「入金通知」の情報だけではゼンゼン足りない。

まぁ、そもそも『振込元の名義表記』が想定と違ったり、『振込元の電話番号』が登録内容と異なったり…。入金確認については、「人間が融通を利かさないと処理できない入金」が多いと言うのも現実なので、キッチリと人手をかけてチェックするのは正しい。 銀行口座との「API連携」なんて、現実的にはマダ先の話だ。

※ 特に日本では、請求書は「漢字」でも、入金名義は「カタカナ」だったり「ローマ字」だったり・・・。

しかし、
しかししかし、
それでも、この「入金消し込み作業」を少しは工夫改善したい。やはり無駄が多すぎる。何より、ミス・ヌケ・モレの発生が起きない様な業務プロセスを考察したい。

そう、
ミス・ヌケ・モレを担当者の責任にするのではなく、ミス・ヌケ・モレは業務プロセスの問題と捉えたい。

[入金確認フロー]

難解なビジネスプロセスも、業務の流れ図(フロー図)を見れば誰でも理解できる!
「フロー図の書き方」には色々あるが、『業務フローの描画手法 BPMN』の利点は BPMN と言う言葉を知らない人でも眺めていれば理解できる点だ。

最近では企業のみならず、政府機関や任意団体でも、業務の見直しに BPMN を活用するケースが急増してきた。人員の入れ替わり時や新人配置時にも「業務をスグに覚えられる」のがウケている。業務マニュアルより BPMN を優先するのは至って合理的だ。

(1) 簡単なビジネスプロセスも BPMN で描いて、キッチリと社内共有する。
(2) 定義した BPMN を使って、情報システムを構築する。(BPMツール)
(3) 情報システムの運用実績を元に、ビジネスプロセスを更に改善する。

ちなみに、意外と上手く運用に乗らないのが「紙との併用」が必要になるビジネスプロセスだ。ここでは、その代表格である「立替金申請」を考察してみたい。

※ BPMN: Business Process Modeling Notation (1.x) / Business Process Model and Notation (2.0~)
業務手順を分かりやすく図示して可視化するための表記ルール。複数の人間(や機械)が関わる「一連の業務処理」を記述するのに有効なモデリング手法で、(1)IT技術者でなくとも初見で理解できる、(2)システム実装に直結する、と言った特徴を持つ。業務プロセス管理(BPM:Business Process Management)ツールの基盤技術。業務フローのテンプレートをお届けしている『ワークフローサンプル』も、BPMN 手法を使っている。

参考)http://store.questetra.com/ja/bpm/bpmn/

[立替金申請フロー_デジタル領収書]

ワークフローAから、ワークフローBを呼び出す。

『ワークフロー間の連携』は高機能ワークフロー製品の醍醐味(??)の1つだ。例えば「販売部門のプロセス」から「製造部門のプロセス」に、ヌケモレなく業務データを受け渡すことがデキル! (Google Apps などクラウドワーカなら「業務情報」はクラウド型ワークフローがイイよ)

参考)ワークフローの処理中に別のワークフローを自動起動する

ただ、、、確かに「販売フロー」と「製造フロー」の様に、上流プロセス・下流プロセスが明確な場合には、迷いなく連携させられるのだが、交互に継続する様なケースでは一気に難易度があがる。

ソフトウェア工学的に言う所の『ウォーターフォール型』に対する『スパイラル型』だ。更に言えば、例えば「顧問契約」や「保守サービス」などでは、『継続的な受注』のサイクルと『サービス提供』のサイクルが、並行して循環する。要するに、営業は営業で次の受注に向けて動いているし、同時並行でサービス部門がサービス提供のプロセスを進めている。(ダブル・スパイラル?)

そんな時のために、『受注プロセス』を「サイクルする親プロセス」とし、『サービス提供プロセス』を「子プロセス」とする方法を紹介したい。

[循環する受注プロセス ]