ワークフローサンプル

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

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

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

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

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

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

まぁ、そもそも『振込元の名義表記』が想定と違ったり、『振込元の電話番号』が登録内容と異なったり…。入金確認については、「人間が融通を利かさないと処理できない入金」が多いと言うのも現実なので、キッチリと人手をかけてチェックするのは正しい。銀行口座との「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～)
業務手順を分かりやすく図示して可視化するための表記ルール。複数の人間（や機械）が関わる「一連の業務処理」を記述するのに有効なモデリング手法で、（１）IT技術者でなくとも初見で理解できる、（２）システム実装に直結する、と言った特徴を持つ。業務プロセス管理（BPM：Business Process Management）ツールの基盤技術。業務フローのテンプレートをお届けしている『ワークフローサンプル』も、BPMN 手法を使っている。

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

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

ワークフローＡから、ワークフローＢを呼び出す。

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

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

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

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

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

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

なんで、ワークフローに「ファイル添付」できないんだよぉ！

今どき、そんなワークフローは使い物にならない。ワークフローシステムも日進月歩、ドンドン進化している。「文字型」・「数値型」・「日付型」・「時刻型」あたりの基本データ以外にも、

外部リストを使った「選択型」
上流フローで選択候補を設定する「選択型」
色々なデータをひとまとまりの表にできる「テーブル型」
タイムスタンプ付きで追記される「掲示板型」

の様なデータ型が使えるのだ。業務の流れをドンドン改善していく事を想定した「業務プロセス管理システム」（BPM: Business Process Management）でも、ワークフローに流れる「データセット」に様々なデータ型を定義できる。少なくとも Questetra では。。。

※ 参考）モデリング: 設定可能なデータ型（Questetraの使い方：リファレンス）

と言う事で、今回は「契約締結業務」で必要なデータセットを考察したい。

[契約書確認フロー ]

「見積」から「受注」までの業務の流れを捕捉したい。

・今、どの見積書が「失注／受注」の判断を待っている状態なのか、いつでも確認したい。
・受注した時には、必要十分な情報をヌケモレなく、自動的に関連部署に伝えたい。

営業部門でやりたい事は色々あるが、まずは何より「現在情報の共有」だ。以下のワークフロー定義では、セールスチームの案件管理を、非常にシンプルな業務フローで定義している。まさに簡易SFAと言える。ここで注意したいのは、日常の業務報告はシンプルでなければ継続できない点だ。

このワークフローは、営業マンの『1.案件発生報告』に始まる。案件発生登録の直後には、営業リーダに対して『1a.助言や戦略の指示』と言うタスクが明示的に割り当てられる。

その後、セールス担当は自分の担当する案件で、見積提出や往訪などのステータス変更があった際に、タスク『2.見積提出や往訪の記録』で進捗を掲示板型データに追記し「一時保存」する。なお、もしチーム内に共有すべき事項があるなら、「商談中」のフラグを確認して「終了」させる。その場合には、チーム内への「案件進捗共有メール」が、自動的に送信される。

なお、受注や失注が確定した場合には、「受注・失注」のフラグをonにして、タスク『2.見積提出や往訪の記録』を「終了」させれば良い。自動的に「受注しました！メール」がチーム内に飛ぶ仕組みだ。

（敗北分析のためのデータは、上司だけが知れば良い。つまり「失注ですメール」はリーダだけに飛ぶように設定するのがイイような気がする）

[営業-見積もりから受注まで共有フロー]

完全に「無人」で一連の処理が終わってしまう業務フローと言うものもある。

「無人フロー」とは、何かエラーが起きた時だけ人間が関与する、と言った業務フローだ。例えば、(1)Webサイトで『無料アカウント発行』を受け付け、(2)自動的にアカウントがシステム設定され、(3)自動的に申込者に『案内メール』が回答される様なフローも、「無人フロー」の一種と言ってよい。

以下の業務フローは、他の様々な業務プロセスから売上データを受け取る「データベース」の様な役割を持つ無人フローだ。全事業の請求フローから売上情報だけがデータ送信され、全事業の売上データが集約される。

[売上データ集約無人フロー]