ワークフローサンプル

「見積書」や「請求書」の発行が可視化されている会社は、残念ながら少ない。たとえば

今、何枚の見積書が発行されているのか？
今、何枚の請求書が発行されているのか？

と言う問いに対して、即答できる担当者は少ない。

多くの会社では、営業部門や経理部門が「Excel手作業」で一枚一枚作成し、プリンタで印刷し、担当者と責任者に押印してもらい、控えとしてコピーを取って、封入して郵送する。。。せっかく最初はパソコンで作ったのに、知らず知らずのうちに「アナログ化」され、集計しづらいものになる。

以下の「請求書発行ワークフロー」は、いわば『請求書発行システム』だ。
ワークフローに入力された「請求データ」は、ワークフロー内で決裁承認され、そのデータから『請求書PDF』が自動的に生成される。言い換えれば、請求書PDFはこのシステムからしか生成されない。請求書PDFの発行を一元的に管理できる。業務プロセスが、ここまで整備できれば、たとえば業務データ「発行日」「請求先社名」「請求額」をCSVダウンロードする事ができる。すなわち、いつでも「リアルタイムの請求台帳」を作成する事だって可能だ。

ちなみに、この「請求書発行ワークフロー」が秀逸なのは、オンラインストレージ『Google Drive』の特定フォルダに「請求書」が自動でバックアップ保存される仕組みだ。

[請求書発行ワークフロー]

『業務プロセス』を改革する前に、『業務プロセス』を改革するツールを学びたい。

「なるほど、ソリャそうだ」と言う事で、今回はかなりシンプルな利用方法を例示してみる。
以下のワークフロー定義は「メールを書く」と言う業務だ。すでに「業務の流れ」とは言えない。処理工程（タスク）は１つしかない。処理担当者も１人だけだ。差し戻しもなければ、ループもない。

[メール送信ワークフロー]

ちょっとした「仕事」を誰かに依頼する、、、日常的に良くアル！

多くの場合、『Email』と言う「魔法のツール」で解決される。すなわち仕事の依頼元であるAさんが依頼先であるBさんに対して

ワタシの在職証明書を発行して下さい
競合製品XXXの調査をお願いします

と言った内容のメールをしたためるのだ。しかしこの Email と言うツール、「魔法のツール」であると同時に「タスクの墓場」でもある。。。

ここでは、

「業務プロセス」と呼ぶにはタメラワレルような『発生頻度』が低い業務
「業務プロセス」と呼ぶにはタメラワレルような『工程』が短い業務

から見直す事を考えたい。その後には、発生頻度が高い業務プロセスや、工程が長い業務プロセスをも改善できるようになるだろう。

[汎用依頼ワークフロー]

「導入事例記事」の掲載は重要だ。特にIT企業においては、このコンテンツの良し悪しが「売り上げ」をも左右する。

実際、Microsoftも、IBMも、SAPも…、
Oracleも、Googleも、Salesforceも…、
製品を持つITベンダーなら、すべての会社が「導入事例コンテンツ」を掲載していると言っても過言ではないだろう。もちろん Questetra も御多分に漏れない。⇒ 導入事例

以下のワークフローは「導入事例原稿」の作成フローだ。場合によってはその完成まで、１か月以上の時間がかかるケースもある業務だ。しっかりと『現在進捗』を可視化し、また折々に『実績』を集計して、あるべき業務プロセスに向けた業務改善を継続的に行いたい。

[導入事例公開フロー]

いよいよ今週2013年5月26日に、改正公職選挙法が施行される。
日本でも、インターネットで「選挙運動」ができるようになる。（えっ、イマサラ!?!）

要するに候補者（や政党）は、選挙期間中も Facebook
を毎日更新する様になる訳だ。メールもバンバン送る様になる訳だ。そんでもって「私に投票して下さい」と堂々と書けるようになる。（今まで「電話」をかけまくってたのはナンだったんだろう？）

注意しなければならないのは、一般人もこの「選挙運動をしてしまっている」と言う事実だ。
たとえば、選挙期間中に「Ａ候補がんばれ」とか「Ｂ候補をヨロシク」と発信するなんて事は、誰にだってできる。あるいは「Ｃ候補は、あんな奴は当選させちゃダメだ」なんて、ついつい同調して発信してしまうだろう。
しかし今回決まったルールでは、ブログやSNSで「選挙運動」や「落選運動」をするなら『その者に連絡をする際に必要な情報』を表示しておかなければならない。Facebook
や Twitter で発信している以上、全く問題ないが、ブログやホームページで情報発信したい場合には注意が必要だ。

（少し話はズレルが）、メールでの「選挙運動」は明確に禁止されている。一般人は「メール転送」も含めてメールで「選挙運動」しちゃダメだ（まずもってバレナイんだけど…）

さて、、、
そこで新たな業務が発生しそうなのが、Blog や掲示板の運営会社だ。

A. 誹謗中傷記事に対する削除依頼を、執筆者に連絡する業務
B. メールアドレス等の表示義務違反を、執筆者に連絡する業務

これは、かなりの規模の人間タスクになる様な気がする。。。
「中傷削除」を依頼する人は、候補者その人だ。まずは「候補者の本人確認」から行わなければならない。また人気サイトの場合、表示義務違反の指摘が膨大な数になる可能性もある。インターネット関連会社にとって、関連する業務プロセス整備（ワークフロー整備）は急務だ。

[公開記事の修正依頼フロー]

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

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

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

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

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

[請求フロー]

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

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

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

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

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

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

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