ワークフローサンプル

「Web フォーム」で参加申込を受け付けて、自動的に「請求書」を送る。

イマドキ「ITを使った省力化」なんて誰でも考える。
もし『PayPal 決済』や『Google Wallet 決済』など、決済を特定の方法に限定すれば、「Web フォーム」と「決済システム」をつなぎこんだ、（完全に自動化された） Web サイトだって、簡単に作り込めるだろう。

しかし実際の所、50人や100人程度のイベントなら、メールと電話で対応したくなる。何故か？
端的に言って「法人名義に対する請求書送付」や「イベント当日の現金支払い」などなど、様々な要望（例外）があるからだ。人間が対応すれば、何でも柔軟に処理できてしまう。（当然ながらミスも発生するケド…）

以下の業務プロセスは、入金確認業務を人間が行う業務フローだ。
Google Spreadsheet で受け付けた参加申込データを引き継ぎ、その後の処理を人間が担う。具体的に言えば、『請求書発行＋銀行振込』『PayPalクレジットカード』『当日の現金手渡し』の決済完了を人間が確認する。

秀逸な点は、参加申込者が『請求書発行＋銀行振込』を指定した際に、「請求書 PDF」が自動的に送付されるところだ。

[請求フロー]

多くの営業支援ツール(SFA)では、『商談データ』を登録する。

各商談案件のステータスが可視化され、『将来の受注』（見込み）が精度良く予想できるようになる。具体的には、商談の金額や「20％・80％・100％」などの受注確度を登録する。「引合があった」とか「見積依頼を受けた」とか、登録すべき『商談案件』の定義は各社様々だ。

「もうすぐ【案件】になりそう、、、なんだケド。。。」

しかし、この『登録すべきの判断』は意外とヤッカイである。たとえば「まだまだネタレベル」の案件を積極的に登録する営業マンも居れば、「受注が見えてきた状態」になってから案件登録する営業マンも居る。

上司は言う。「全部だ！全部登録するんだ！」

以下の業務プロセスは、活動記録に対する考え方が、少しチガウ。。。
ここでは『案件の視点』ではなく、『面談(接触)の視点』でセールス履歴を記録する。日々の面談活動を登録すれば良いため、特別な「判断」は必要ない。顧客候補との往訪面談・来訪面談・電話会談・Web会議などの完了後(帰り道)に、記録する。「営業日報」と言っても良いだろう。往訪ベースの会社であれば、業務プロセス自体の名前を「往訪報告フロー」と言い換えても良い。

[商談前案件を可視化する面談報告フロー]

「このアナログな感じの立替金申請って、どうにかナランの・・・？」

月に一度、紙の領収書と「格闘」する人は少なくない。
タクシー代。セミナーの参加費。足りなくなった備品をあわてて買いに走った時の文具代。従業員は、何枚もの領収書をエクセルに入力する。そして全てが入力し終われば印刷し、押印(サイン)し、上司に提出するのだ。上司はその書類を何となく眺めて押印(サイン)し、経理部はその印刷物を見て、改めてエクセルに入力しなおす。冷静に考えると、何ともバカバカしい。。。

立替金の精算は、多くの会社で「伝統的な業務」になっている。
それだけに、往々にして業務効率化の余地が大きいのだ。

とは言え、立替金精算業務は、現金出納に直結するセンシティブな業務でもある。いわゆる「内部統制体制」も非常に重要だ。業務効率化を進めた結果が、不正や間違いの発生確率を上げてしまう様では困る。そう、、、何とも奥が深い業務プロセスと言えるだろう。改善活動の投資効果は極めて大きいが、改善担当者には相応の BPM スキルが要求される。

下記の業務プロセス事例は、「立替金精算申請書PDF」がワークフロー途中で自動的に生成される仕組みだ。

[立替金申請フロー-申請書自動作成]

ワークフローの『クラウド化』が実現すると、必ず「メール問合対応の業務フロー」もクラウド化したくなる。

理由はカンタンだ。

どこに居ても対応できる（自宅からでも、外出先からでも）
誰が対応しているか分かる（リアルタイム監視の視点）
どの工程で滞留したか分かる（パフォーマンス集計の視点）

しかし実際に稼働させると、「回答者を割り当てるフロー」よりも、「社内の助言を得るフロー」の方が重要であることに気づく。
つまり、例えば「サーバが止まっているの？」と言う問い合わせを受けても、窓口担当者には分からないのだ。例えば「技術的な質問になるのですが…」と言う問い合わせであれば、どうしても技術部門に助言を求めざるを得ない。そして、この手の問い合わせに、如何に早く回答できるか、は会社の信用にかかわる！

以下のワークフロー『問合対応業務フロー』は、非常にシンプルな「助言依頼フロー」を内包している。非常に秀逸だ。

[問合対応業務フロー]

『スピード！スピード！スピード！』
「ココは複数人での同時処理にしよう！」
「ココは人間の目視判断ではなく条件式で自動化しよう！」

業務プロセスの滞留ポイントを洗い出し、「処理の並列化」や「処理の自動化」を考える例は少なくない。いや、むしろ王道だ。一連の処理が素早く終了する事は、多くの業務において望ましい。

一方、、、途中処理をわざと滞留させる業務もある。典型的な例をあげれば「立替金申請フロー」だ。
すなわち、申請を書き始めてから、申請が提出されるまでの時間は、どうでも良い。申請提出が締切日に間に合いさえすれば良いのだ。

では、どうすれば「毎月５日まで」に全社員に申請させることが出来るのだろうか？

[立替金申請フロー]

前回のワークフロー雛形(※)は非常にシンプルだった。
その反動で、今回のワークフロー雛形は非常に複雑だ。
※ ワークフローで「提案書の書き方」を標準化できるか？

クラウド型ワークフローの『Questetra BPM Suite』は、もちろん「ワークフローシステム」と呼ばれる製品種類にも分類できる。しかし、一方で「業務プロセス管理システム」(BPMS)と呼ばれる製品種類でもある。

「業務プロセス管理システム」(BPMS)とは、「業務プロセス管理活動」(BPM活動)（業務フローを改善し続ける経営管理概念）を支援するツールだ。業務プロセスを Drag＆Drop で描画すれば自動的に業務システムが出来上がる、と言う所に特徴がある。現場管理職や一般従業員（システム利用者）自身が、業務プロセスを改良できるところが画期的だ。「魔法のツール」と言っても良い。

以下の業務プロセス図は、いわゆる「基幹業務プロセス」を表現している。
営業担当による「受注の入力」に始まり、管理部の「入金確認」に終わる一連の作業手順が表現されている。こんな業務プロセスも BPMS を使えば、一瞬でシステム化できてしまう。本当にスゴイ時代になったものだ。

もっとも、「受注」から「サービス提供」を経て、「請求」や「入金確認」を行うと一言で言っても、業種業態・会社規模・会社文化によって多種多様だ。また事業環境の変化にあわせて、あるべき業務プロセスも変化し続ける。これからの時代、『良いシステムを創る事』が重要なのではなく、『システムを変更し続ける事』が重要なのだ。

＜特徴＞

各処理画面には簡単な業務マニュアルが書かれている
重要作業工程ではメールによるアラートも届く
明細入力中の合計値計算は自動で補完される
業務データが挿入された請求書PDFが自動的に生成される
翌月も同種の請求書が発行される場合には次回の請求プロセスが予約される
見積プロセスから見積書データが自動的に引き継がれる
オンライン販売のデータが自動的に取り込まれる

[受注→作業→請求書発行]

4月1日、、、日本では「新年度」だ。
学生達は新しい学年に進級し、新社会人達は始めての出社日を迎え、社会人達は（前期のコトはマーサテオイテ）新しい年度の新しい目標を立てる！

言うまでも無く「業務プロセス」を見直すには絶好の機会だ。
しかし、既に4月1日を迎えてしまっている今日に至って、改めて複雑な業務の改善アイデアを提示するのは「ヤボ」と言うもの。。。以下は、簡単に始められる『提案書レビュー』のオンライン化を提案したい。コレなら、30分で業務フロー図が書けて、30分でワークフローシステムを稼働できる。

この『提案書レビュー』を稼働させれば、チーム内の提案書がどんどん可視化される。
すなわち、「いま誰が、どんな提案書を書き、どんな指摘を受け、どんな改良をしようとしているのか」が可視化され、記録されるるようになる。また、提案書データが日々蓄積される状態になれば、新たに提案書を書こうと思った時にラクだ。過去のイケテル提案書を検索し、それを参照して作ればよい。

[提案書フロー]