ワークフローサンプル: 2011/10

BPMSは「クレーム対応ツール」としても有用だ。。。
※ BPMS: 業務プロセス管理システム (Business Process Management System)

実際、部署横断的な『クレーム対応プロセス』は、一度決めても、あるべき業務フローは変化する。取扱製品の追加、会社組織の変更、事業環境の変化。場合によっては、時期や季節によって変更すべきケースもあるだろう。（従来の「ワークフローシステム」では実現がムツカシイ）

なお、クレーム対応ワークフローを立ち上げる際には、「データ項目」をしっかり考察しておくことをおススメする。すなわち

どの様なクレームが、どの程度の頻度で発生しているのか？
どの様なクレームは、どの程度の時間で解決しているのか？
どの様なクレームに、誰が対応しているのか？

これらの分析を可能とする「業務データ」がキッチリ記録されるようにしたい。

例えば『クレームの種類』と言う選択肢データを考えてみる。。。果たして「(1)製品不備、(2)操作法不明、(3)期待との差、(4)その他」と言う構成で良いのか？。。。（考え出すと夜も寝られない）

＜各タスク名＞
1.起票、2.担当指名、3.一次対応、3b.助言、4.最終対応、4b.助言、5.対応の評価

BPM活動（業務改善活動）の定番は「生産性向上」だ。しかし、このエコ推進の時代にあって「ペーパーレス」と言う観点で目標設定するケースも少なくない。

最近では受信FAXの紙ムダを排除するために『ペーパーレスFAX』（インターネットFAX）を導入する企業も増えてきた。デジタル化されたデータ、どうせならワークフローで「宛先」にキッチリと届けたい。（記録にもなる）

ちなみに営業マンの視点で言えば、FAXを外出先でも確認できるのは非常に都合が良い。管理職の視点で言えば、どの様なFAXが何通届いているのか可視化されるのも非常に便利だ。（検索や集計も）

PS: ちなみに…、届いたFAXが受信機に何時間も放置されている実態があるなら、やっぱり「生産性向上」の観点かもしれない。

＜各タスク名＞
1.宛先確認、1b.宛先判断、2.FAX着信確認

SFAとは、Sales Force Automation（セールス・フォース・オートメーション）の略。要するに『セールス情報』を社内共有する仕組みだ。「足で稼いだ情報」もあれば、「Webからの資料請求」もある。いずれにせよ成約（受注）までの流れを可視化する。

SFAプロセスの開始例：展示会での名刺獲得、キャンペーン応募、クレーム対応時の製品紹介…

もし、自社オリジナルの営業フローを構築したいなら、既存のSFAサービスを使わず、BPMシステム上で「あるべき業務プロセス」を探究するのも一手だ。その営業フローは「競争力の源泉」になるだろう。

ちなみに、オリジナリティを追求する上で「どの様な『セールス情報』を共有するべきなのか？」と言う方針は、事前に真剣に考えておく必要がある。方針が曖昧だと「不毛な入力作業に追われるセールスマン」を量産してしまう事になりかねない。

＜セールス情報の種類＞

A1. 顧客ニーズ把握　「見積書データの可視化」
A2. ライバルの把握　「X社製品とコンペ」
A3. 顧客の興味機能　「モデリング機能が大好評」
A4. 顧客の購買予算　「5年で1000万円の予算」
B1. 提案活動の共有　「往訪説明しました」
B2. 人脈情報の共有　「部長とは同級生だよ」
B3. 提案準備の共有　「2時間かけて作ったパワポ」
B4. 社内からの助言　「直筆の手紙を書こう」
C1. 商談スケジュール　「10月中決裁の模様」
C2. 受注失注の管理　「失注しました」

＜各タスク名＞
1a.資料請求対応、1b.引合情報入力、2.担当者アサイン、3.一次コンタクト履歴、4.コンタクト履歴、5.受注失注確認

月次で請求書を発行するビジネスは多い。
クラウドの３要素「IaaS・PaaS・SaaS」は言うまでも無く、人材派遣の請求(派遣業)、掛け売りの回収(製造業建設業等多くの業種)など、様々な業種で、毎月請求書が発行されている。

ルーティーンな業務フローだけに、効率化や改善がもたらす効果は大きい。

以下のワークフロー定義は、「請求書作成フロー」が終了する際に、「次の請求書作成フロー」を自動開始させておく仕組みだ。つまり、自らが死ぬ前に自分自身のコピーを生んおく仕組みだ。

具体的に言えば、タスク『3.請求書作成発送』の直後の「メッセージ送信中間イベント」（複製）で、「メッセージ開始イベント」（複製開始）を呼び出す仕組みとなっている。

＜各タスク名＞
0.新規受注報告、1.請求書情報確定、2.請求書情報確認、3.請求書作成発送、4.入金確認

「障害の発生」の公表は、正確性と迅速さが欠かせない。特に「一次発表」までの時間を、如何に短縮できるかが大きなポイントと言える。事業内容（業種）に応じて『障害情報』の発表フォーマットはそれぞれ異なるが、その作成手順（業務プロセス／ワークフロー）には大きな違いはない。

Web事業者（広義の「Webサービス」）
データセンター事業者
SaaS事業者
通信事業者
交通機関
など

なお、忘れられがちな話だが、それらの障害情報を集積しキッチリと分析する事が最も大切だ。障害発生時の業務プロセスを整備するだけでなく、報告時刻などの対応履歴を定期的に分析するようにしたい。

＜各タスク名＞
1.障害検知報告、2.アサイン、3a.一次発表文作成、3b.アプリ一次報告、3c.インフラ一次報告、4a.発表文定時更新、4b.アプリ復旧定時報告、4c.インフラ復旧定時報告、5.一次発表文確認、6.復旧完了確認