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

ワークフローシステムを運用していると、業務フロー定義にのって仕事が次々と流れてくる。上司から、Webフォームから、タイマーで…。ホワイトワーカは優先順位を考えながら、自分の『タスクリスト』をコツコツと消化して行く。
では「流れ」が決まっていない仕事はどうすれば良いのだろうか。業務フローが決まっていない仕事が頻繁に発生する…。さりとて、メールや口頭で仕事を割り込ませるのは躊躇する…。

以下のワークフロー定義は、非常にシンプルな『汎用依頼フロー』だ。ワークフローシステムを体験してもらうためのワークフロー定義としても便利だ。１対１の関係で仕事を依頼する事ができる。具体的にはこんな感じで使えばよい。

＜依頼例＞

【実行依頼】Ａ書類のレビューをお願いします。
【実行依頼】Ｂ案件につきＣさんに回答しておいて下さい。
【実行検討依頼】Ｄと言うアイデアを実行すべきだと考えています。一度検討して下さい。
【実行検討依頼】Webサイトの表現を「ＸＸ」に修正すべきだと思います。確認して下さい。

実はこのワークフロー定義は『未整備ワークフローの発見』と言う課題において、非常に重要だ。未整備であるがゆえにメールや口頭で仕事を依頼してしまう。結果、仕事の記録が残らない。そして「見えないものは改善できない」。
『汎用的な依頼』の記録に何度も登場する仕事（依頼関係）があれば、ワークフローとして整備する事を検討した方が良い。

＜各タスク名＞
1.依頼、2.依頼対応報告、3.依頼対応確認

[汎用作業依頼 : 「3.依頼対応確認」画面]

機械翻訳の支援を得たとしても、人間による「翻訳」はある程度必要だ。

すなわち文意を翻訳するだけでなく、URLリンク先をそれぞれの言語にあわせて変更したり、購入手続などを国や地域にあわせてローカライズしたり、様々な「変換作業」が必要になる。（マニュアル、プレスニュース、FAQ、ブログ発信、障害情報などなど）
グローバル企業においては、「社内の事情に詳しい翻訳者」を確保する必要がある。この手の仕事は「仕事」や「各作業の流れ」を可視化し、育児中の社員や退職者も『在宅ワーカー』として参加できるようにしたい。

<各タスク名>
1.翻訳依頼、2.レビュー、3.質問対応、3zhCN.簡体翻訳、3zhHK.繁体翻訳、3ko.日韓翻訳、3en.日英翻訳、4de.英独翻訳、4fr.英仏翻訳、4es.英西翻訳、5.翻訳確認

クレーム対応業務に「他部署の協力」は欠かせない。
クレーム窓口が、電話やメールで『クレーム発信者』の感じたこと考えたことを真摯な態度で聞き、理解できたとしても、それだけで終わったのでは意味がない。実際に

商品品質の改善（不良品、欠品、納期遅延）
サービス内容の改善（サービス停止、サービスレベル低下）
社員対応の改善（電話応対、メール文章）

につなげなければならない。無論、中には「言いがかり」に近い『クレーム』もあるだろう。ただ、その様なケースであっても、「対応する必要ナシ」と言う判断は「しかるべき手順」を踏んで行いたい。まずは自社商品にあった手順を確立する事。さらにその業務手順を常に見直し続ける事。クレーム対応業務にも、業務プロセス管理（BPM）の考え方を適用したいものだ。

以下のワークフロー定義の第一タスク『1.苦情入力』では、各社員がメール・口頭・電話で受け取ったクレームをそのまま入力する。対応すべき社員（社長等も含む）が特定できる場合には、この時点で対応者を指名するが、指名できない場合にはカスタマーサービス部が対応する。
なお、場合によっては、偶然発見した『TwitterやFacebook上に流れている苦情』も入力対象として検討したい。

＜各タスク名＞
1.苦情入力、2.対応者指名、3.回答文、3b.レビュー

★6月6日から記事品質を高めた週刊発行になります！
★週刊化第一号の今日は「GoogleスプレッドシートのフォームとQuestetraを連携させる方法」を掲載！

「Workflow-Sample.net」では、業種や業務カテゴリに絞らず様々なワークフローTemplateを提供している。各記事のリピータ数や滞在時間などを分析していると、自ずと「注目業種」や「注目業務カテゴリ」が見えてくる。（日本語版での最近動向で言えば「テレワーカ（在宅勤務）」になる）

そんな中で「クレーム処理」は根強く注目されている業務カテゴリだ。顧客との接点だけでなく、社内での対処フローをどの様に構築すべきか、各社各様に模索しているのだろう。特に、

どのタイミングで上司や役員と情報共有するべきか
どの様なチェックを受けるべきか

あたりが難しい。以下は、クレーム対応はカスタマーサービス部部長の最重要任務であると言う前提に立ったワークフロー定義だ。全てのクレーム回答文はカスタマーサービス部部長のレビュー後（もしくは修正後）に送信される。

＜各タスク名＞
1.苦情入力、2.一次回答文作成、3.一次回答文レビュー、4.二次回答文作成、5.二次回答文レビュー

[クレーム対応：「3.一次回答文レビュー」画面]

見積～発注までの「企業間（横断型）のワークフロー」を構築し、可視化してみると誰しもが思う。

納品工程も可視化したい。
検収工程も可視化したい。
入金の実施状況も可視化したい。
入金確認状況も可視化したい。

ちなみに、企業間にまたがるワークフローを運用すると、たとえば「取引先が『入金確認作業』を完了させているかどうか」まで見えてしまう。しかし、良く考えるとなんら困る話ではない。（むしろ便利）

類似）

＜各タスク名＞
1.見積依頼、1b.依頼承認、2.見積回答予定入力、3.見積書作成、4.見積書承認、5.見積書内容の発注、6.修正対応、7.修正承認、8.受注確認、9.納品完了報告、10.入金確認

[見積・受注・納品処理: 「1b.依頼承認」画面]

『サプライチェーンは「企業横断型ワークフロー」だ』の例では、受注側だけが「上司承認（リーダ決裁）」を想定している。発注側の「上司承認（リーダ決裁）」も想定するとなると、以下の様なワークフロー定義になるだろう。

＜各タスク名＞
1.見積依頼、1b.依頼承認、2.見積回答予定入力、3.見積書作成、4.見積書承認、5.見積書内容の発注、6.修正対応、7.修正承認、8.受注確認

[見積処理-上司承認: 「1b.依頼承認」画面]

業務プロセス管理（BPM）活動の多くは、『企業内』の作業手順（ワークフロー）を管理し、そのカイゼンを図る。
しかし実際にアレコレ作業手順を見直す活動をしていると、『企業内』より『企業間』の業務プロセスの方がヤリガイがある事に気づく。主な理由は以下の通りだ。

業務定義しやすい：そもそも各社の役割分担が明確である
通信に無駄が多い：文書（メール／FAX／郵送）のやり取り手間を許容している
保存に無駄が多い：各社それぞれに、それぞれの方法でデータ管理している
丁寧な改善を行う：社外の人に迷惑はかけられないと言う緊張感をもって改善プロジェクトを遂行する

※（もちろん『企業間業務プロセス』の場合、コンセンサスを図るのがタイヘン）

今や「電子メール」ですら歴とした"文書"だ。もちろん日本の法律においても裁判証拠になる。「紙」の文書は少しずつでも減らしていきたい。

以下のワークフロー定義は、取引の多い企業同士における「見積書＋発注書＋発注請書」を全面的にペーパレス化（電子文書化）する事を主眼においている。平たく言えば『得意先様用発注システム』だ。（SCM）

＜各タスク名＞
1.見積依頼、2.見積回答予定入力、3.見積書作成、4.見積書承認、5.見積書内容の発注、6.修正対応、7.修正承認、8.受注確認

[見積処理: 「3.見積書作成」画面]

お客様に入力して頂くWebフォームが正常に動作するかテストしたい。良くある話だ。
そんな時、ワークフローが自動化され過ぎていると困った事態になることもある。例えば、開発社員がテスト入力した住所などに「無料体験版」が実際に郵送されてしまってはコスト高だ。

『「無料体験版」から優良顧客度の分かる顧客リストを！』を拡張し、『テスト入力』の場合は別のフローに至るようにしたい。以下のワークフロー定義では、『申込者氏名』に「test」で開始される文字列が入力された場合、アカウント発行の自動処理が行われない。

類似：

＜各タスク名＞
0.テスト入力の確認、1.申込情報入力、2.手動アカウント発行、3.アカウント発行の検証、4.引合情報確認、5.電話営業結果入力

[体験版アカウント発行-自動発行: 「0.テスト入力の確認」画面]

試供品や無料体験版をつのり、お客様に自動送付する。
その受付から送付までの一連の業務フローが自動化され、見込顧客の満足度が上がるのは良い事だ。しかしソレだけで終わったのでは、ビジネスとして如何なものか。すなわち、見込顧客へのプッシュマーケティングにつなげたい。
以下のワークフロー定義では、申込情報をセールス部門に伝達する。

類似：

＜各タスク名＞
1.申込情報入力、2.手動アカウント発行、3.アカウント発行の検証、4.引合情報確認