ガンダムを出撃させる際の業務プロセス(ワークフロー)を明確にしておきたい。そうしておけば、新人の少年兵が入ってきても、スグに現場で働いてもらえる。極めて便利だ。(編注:へっ? ベンリ…なの?)

ここで定義する『ガンダム出撃ワークフロー』は、大まかに「1.敵発見、2.戦闘配置宣言、3.出撃命令、4.出撃」と言う4つの工程で構成される。しかし実際には出撃しないケースもあるので、業務プロセスの分岐ポイントや途中終了のさせ方に注意が必要だ。詳しく見て行こう!

まず、この業務プロセスは「1.敵発見」に始まる。
ここでは、レーダーが反応して自動検知されるケースと、人間の目視確認による発見ケースを想定している。しかし、いずれにせよ『管制担当』によって『艦長に報告する』という処理に集約される。業務プロセス設計の観点では、この様な場合に細かい経緯を全て列挙するのではなく、『艦長に報告する』と言う象徴的な「処理」に注目したい。(編注:ナンデそんなに偉そうなんだ)

ちなみに、実際の『艦長への報告』を口頭で行ってしまうと、大事な業務記録が残らない。(と言うかワークフローシステムの出番がなくなる)。 ココは『Questetra BPM Suite SaaS Edition』を使って報告して頂くことにしようぢゃないか。

…そう!、ワークフローを使えば、仮に、ブライト・ノア(Bright Noah)艦長が、艦長室でデスクワークをしていても、トレーニングジムで汗を流していても、メールで詳細情報を確認する事ができる(!!?)。便利だ。
…そう! 艦内警報システムとRESTfulに連携させれば、「艦内警報」が自動化される。これは便利だ。
…と言うか、艦長への報告時刻や報告者が業務記録として自動的に保存される。これは相当に便利だ。

ところでホワイトベースの『管制担当』者は2名だ。そう、オスカ・ダブリン(Oscar Dublin)とマーカー・クラン(Marker Clan)の両名しかいない。すなわち、この2名が不在の時にはこのワークフローを流れるべきプロセスは完全に滞留してしまう。リスクコントロールマトリックス(RCM)のドキュメントで特記しておくべき「リスク事項」と言って良い。

[ガンダム出撃フロー]

販売促進のための販促品や記念品は「アイデア勝負」だ。何処かで見かけたノベルティではインパクトに欠ける。

そんな場合には、やっぱりプロに提案してもらうのが良い。社内の「無知」を集めるより、社外の「プロ」に聞いた方が早い。…と考えた時点で『ノベルティ制作フロー』には「社外のプロ」が関与する事になる。

ここで紹介するノベルティ制作ワークフローでは、マーケティング部の担当者が数量やテーマなどの要望を設定するところから始まる(タスク『1.要望設定』)。「社外のプロ」(ノベルティ販売会社)は、その要望にかなう提案書(GoogleDocs等)を作成し、そのURLを書き込む(タスク『2.質問/提案』)仕組みだ。

[ノベルティ制作フロー]


人から仕事を「依頼」される。コレ良くある話。

しかし、社内のどこで「どんな依頼が行われているか」は実は良く分からない。それらを可視化・分析すれば「仕事の連鎖」が見えてくる。そう、その連鎖こそ真のワークフローだ。
ここでは「個々の依頼」を管理可視化するシンプルなフローを考えたい。仕事の丸投げも想定したい。


[作業依頼フロー]

Google Docs のWebフォームで「キャンペーン申込」を受け付けたい!
クラウド時代の今、実によくある話だ。「Google Apps」のWebフォームを利用するケースも多い。Google Sites と組み合わせる人もいるだろう。実に簡単に「公開フォーム」を作成できる。 そして驚くほどカスタマイズできる。しかも「集計」だってリアルタイムだ。何と言ってもタダ(無料)で使えるのもイイ!

しかし、単に受け付けるだけでは満足できなくなる。すなわち「クイックレスポンス」だ。例えば、(1)受付完了メールを送る、(2)関連資料を郵送する、(3)各エリア担当営業に申込情報を渡す…。そんなワークフローを実現したくなる。されど Google Apps には、ワークフロー機能が無い

そこで登場するのが Google Apps とダイナミックに連携できるワークフロー、、、そう「Questetra BPM Suite」だ! コチラも無料でも使える。 これで複数人で効率良く、しかも迅速に対応できるようになる!!

[申込受付対応フロー_営業対応地域選択]

「BPO」は、ビジネスプロセス・アウトソーシングの略。要するに「外部委託」だ。

総務・経理・人事・福利厚生・コンタクトセンターなど、コア業務でない業務を外部企業に委託する。中でも「情報システム運用」を外部委託する事例は実に沢山見受けられる。(特に「ITアウトソーシング」などと呼んだりする)

例: クレーム管理、データ入力、データ分析、代理店管理、セールス研修、製品テスト…

一方で、受託する側は「BPOを専業で行うBPOベンダー」や「海外の低賃金を活用するオフショアBPO会社」だけでなく、SIer・印刷会社・コンサル会社などの事業進出が目覚ましい。まだまだ市場規模は拡大していくのだろう。(ちなみに日本のBPO市場は、世界市場の成長率に比較すると低調だが、既に1兆円規模だ)

BPOにおいては、委託側にとっても受託側にとっても「業務プロセスの可視化」と「業務マニュアルの整備」がとても重要だ。しかしそれがナカナカ進まない。ここでは受託側が営業段階で業務プロセス(仮プロセス)を提案していく、と言うシナリオを想定している。

以下は、「業務プロセスを提案設計する業務」の業務プロセスだ。(ヤヤコシイ)

[業務フローを設計する業務フロー]

『企画書』は大切だ。例えば「新事業」「新製品」「業務改善」と言ったキーワードで、多くの企画書ができあがる。会社にとっては多ければ多いほど良い。そして現実、その中のごく一部の企画書だけが採用される。

以下の「企画書審査ワークフロー」では各ステージで企画書がフルイにかけられ、最終的に生き残った企画書だけが社長に読まれる仕組みだ。

しかし、ただ単に企画書の『サバイバル』を業務プロセスに落としこんだだけでは面白くない。むしろここでは『企画倒れ』となった企画書達を「会社の資産」することを考えたい。すなわち「再利用できる企画書」を発掘できる環境を整えたい。

[企画書稟議フロー]

セールスマンには「流派」がある(?)

「1次コンタクト」なんて無機的な表現ぢゃなく、見込顧客が『A.タネ状態』なのか、『B.発芽している状態』なのか、『C.刈り取れる状態』なのか、をハッキリさせたいんだよ。なっ、有機的だろ!(どうだろ?)

もはや「SFA」などと言う上品な言葉とは無縁な気もするが、そんな流派のSFAフローを考えてみた。

[プロセスモデル]

「週報」や「日報」は、チーム内の作業状況や作業予定を可視化するツールとして有効だ。(管理職視点で言えば、各メンバの「考課資料(評価資料)」としても重要なのだろう)

しかし、週報や日報は「書き忘れ」や「未提出」がツキモノだ。いつでも『マイタスク一覧』に表示される様に自動起動させておくのが良いだろう。以下のワークフローサンプルでは、毎週月曜日の朝9時に『1.週次報告を書く』と言うタスクが自動的に立ち上がる。すなわち『タイマー開始イベント』でプロセスが開始される。メンバは少しずつ書き足して毎日「途中保存」すればイイ。最終提出となる「締切」は4日後の金曜日だ。

<各タスク名>
1.週次報告を書く、2.チェック&指摘、3.指摘への対応、4.確認

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.受注失注確認

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

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

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

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

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

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

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

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

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

日本では台風シーズン到来だ。そして気象警報が発令されると「電話連絡網」が回ってくる。(休校を知らせるための電話伝言ゲーム)

ただ最近では、「メールの普及」「個人情報への配慮」「リアルタイム性の担保」等の理由から、電話連絡網(緊急連絡網)を廃止して、メーリングリストでの情報配信に切り替える学校も多い。

『緊急メール』の配信で注意したいのは「誤解の無い文章の作成」だ。メールでの情報配信は便利なのだが、要らぬ誤解は混乱を助長する。「情報が正確に伝わっているか?」、かならず起案者以外の職員にレビューしてもらってから送信するルールにしたい。

以下のワークフローでは、(1)配信文章の起案、(2)素早いレビュー校正、(3)素早い承認、を考える。(レビューや承認は、スマートフォンが吉!)


<各タスク名>
1.配信文起案、2.配信文校正、3.承認、3b.事後承認

「コンプライアンス体制の基本は『規程書類』だ」
と言う意見を否定するつもりはない。しかし一方で、社員全員に『憲章』や『規程』に興味を持ち続けてもらう事は現実的ではない。

1. コンプライアンス体制を維持する
2. その本質: 全社員が「法令や定款」を守る必要がある
3. その方針: 社内での「相互監視体制」をとるべきだ
4. その方法: 社内の多くに認知された≪目安箱≫を設置しよう。

この思考は正しい。社内に目安箱と言うポストを配置すれば良い。しかし「投稿者の投函時ストレス」「回収者の手間」を考えるに、今どきオンラインで受け付けたい所だ。「紛失すること」も、「もみ消されること」も無いだろう。

※ ≪内部通報システム≫、≪内部告発システム≫と呼ぶ事もできるが、≪目安箱≫と呼ぶのがイイような気がする。


<各タスク名>
1.投稿、2.投稿確認、3.調査&回答文作成、3a. 疑問対応、4.回答掲示

パッケージソフトウェアの制作やウェブサイトの制作は「完成したら終わり」と言うものではない。むしろ『変更要望』と言う更新業務に追われる日々が「始まる」と言った方が良い。時には「不具合」も報告されるだろう。

以下の業務フロー図は、「不具合報告」や「要望」のステータス管理を効率よく行う事を主眼に置いた設計だ。(※ 社員が全員、ワークフローのアカウントを持つケース)

<各タスク名>
1.不具合要望登録、2.回答者指名/優先度設定、3.一次回答、3a. 疑問対応、4.最終回答、5.一次回答確認、6.最終回答確認

[不具合&要望の受付から回答 「2.回答者指名/優先度設定」]


「ID・パスワード」の発行業務は『地味』ではあるが『極めて重要』だ。その運用を誤ると「情報漏洩」や「情報システムの乗っ取り」など、事業継続に大きな支障をきたす可能性すらある。少なくとも、発行ログはきっちりと記録しておきたいものだ。

以下のワークフローでは、

  • A. 人事部門による「入社研修プロセス」から『自動起動』されるケース(新規ID発行)と、
  • B1. 一時雇用者等のためのIDが『申請』されるケース(新規ID発行)、
  • B2. そして社員の『パスワード忘れ』『改名時のID変更』のケース(既存ID更新)、

に対応している。Aはプロセス間連携、BはWebフォーム連携を想定している(プロセスモデル接続API)

当然の話ながら、「アカウント発行」や「アカウント再発行」を行う以上、「アカウント削除」についてもその業務フローを整備したい。「紙面の都合」と言う名の「大人の都合」でまたの機会としたい。

<各タスク名>
0.承認者指名、1.承認、2.認証コード発行、3.認証コードを聞いて入力、4.仮パスワード変更確認、5.確認


[セキュアな パスワード発行: 「2.認証コード発行」画面]


「プレス原稿の作成フロー??」
「オレの代わりは居ないし、ナカナカ人には伝えられない仕事なんだよ・・・!」

どれだけ会社規模が大きくなっても、「たった一人が担当している仕事」の1つや2つは存在する。しかし、その様な「一子相伝の秘められたプロセス」であっても、業務フロー定義を諦めるべきではない。少なくとも、『各案件がどの進捗にあるのか』を明らかにするだけでも、大きなメリットがある。

以下のワークフローは『プレスニュース原稿の作成フロー』の概略工程を定義したものだ。情報収集や裏づけなどの細かいタスクは気にせず、大きな流れだけを定義している。

<各タスク名>
0.NEWSアイデア提案、1.NEWSネタ熟成、1a. 助言対応、2.NEWS草稿執筆、2a. 助言対応、3.配信代行サービス登録、4.Webサイト アップ、5.効果測定、6.意見感想投稿


[プレスニュース原稿の作成 : 「2.NEWS草稿執筆」画面]


問い合わせ対応はタイヘンな仕事だ。「理解する力」や「専門知識」も重要だが、「説明する力」がもっと重要だ。一朝一夕には身につくものではない。

どんな組織においても『問い合わせ回答のベストプラクティス』を組織内で共有したいものだ。最初は手間がかかるが、徐々に回答効率・回答品質・回答時間のすべてが改善する。
以下は、様々な問い合わせに対して地域言語(例えば日本語)で回答文を作成するだけでなく、FAQとして管理すべきものについては、地域言語と英語の両方でデータベース化するワークフローだ。「データベース化」する先のシステムとしては様々に想定できるが、いずれのシステムにせよワークフロー完了時に自動的に投稿される様に設定したい。
・社内専用FAQ: グループウェア、社内ブログ、Facebook非公開グループ、など
・Web公開FAQ: 公式ブログ、ディスカッションサイト(Google Group)、Facebook公開グループ、など
<各タスク名>
0.手動、0a.例外エントリ対応、1.回答担当指名、2.回答文作成、2a.重要顧客対応、2b.助言、3.回答後経過の記録、4.FAQ掲載文作成、5.翻訳




[問い合わせ対応 : 「2.回答文作成」画面]



「≪資料請求≫の受付」は、B2Bビジネスに限らず、B2Cビジネスにおいても、有効なマーケティング手法だ。場合によっては、外部に委託するタスク(BPO)もあるだろう。いずれにせよ≪見込顧客の満足≫を得られるスピードで対応したいものだ。

Webフォームで受け付けたデータは『メッセージ開始イベント』(手紙アイコン付の細丸アイコン)にて、ワークフローに取り込まれる。

<各タスク名>
0. 例外エントリ対応、1.重複等チェック、1b. 事務質問対応、2.重要顧客対応、3.郵送処理、3b. 郵送質問対応


[資料請求対応 : 「3.郵送処理」画面]


震災後の日本ではBCPに関連する商品やサービスが「特需」だ。IT業界でもクラウド関連製品などの需要が伸びている。(新聞紙面に「節電」「在宅勤務」「BCP」の文字を見ない日は無い)

※ BCPとは「Business Continuity Plan」の略で『事業継続計画』と訳される。『非常事態発生時対応計画』(コンティンジェンシープラン)が「非常時にとるべき行動」に主眼が置かれているのに対し、BCPは「事業を復旧させるための行動」と比較的長期にわたる行動を規定する。

しかし『事業継続計画』(BCP)の作成は容易なことではない。例えば、「社屋の停電」や「交通網の寸断」などの想定シナリオの下で、「主要な業務プロセスをどの様な形で復旧させるべきか」を平時から検討しておく必要がある。すなわちこの検討には、平時の業務の流れを熟知している必要があるだけでなく、場合によっては高度に経営視点での考察も必要となろう。

以下は『「想定する条件下での業務フロー」を準備する業務フロー』だ。

<各タスク名>
1.業務フローおよび想定条件の指定、2.業務フロー図の検討、2b. 相談対応、3.検討業務フロー図のレビュー、4.検討業務フロー図の確認


[業務フロー図作成 : 「2.業務フロー図の検討」画面]



ワークフローシステムやBPMSの導入動機に「脱メール」がある。

確かに電子メールは便利なのだが「記録」として整理する事は困難だ。また現実、メーリングリストを使うケースが多いのだが、何よりメールを読む全員の時間がもったいない。それでいて、読むべき人に、読むべき内容が、適切に伝わっているとも言い難い。(営業日報など)

・A. 重要なナレッジは、いつでも誰でも参照できる記録として残す
・B. 急ぎ情報共有すべき人には通知され、情報確認事実を関係者が認識できるようにする

どんな改善活動にも言えることだが、カイゼン活動を行うなら目標設定が重要だ。もし、日々の社内情報共有フローに課題を感じているなら、これらA.B.は『最初の設定する目標』としてオススメだ。

<各タスク名>
1.日報作成、2.日報確認、2b. 日報差戻対応、3.日報確認


Business Process Outsourcing なる言葉がある。要するに外部委託だ。グループ企業内に特定業務を一元的に担う組織が存在する場合も、外部委託していると言って良い。

今日では、情報システム部門やコールセンター部門に留まらず、総務部門や経理部門も外部に委託する。それぞれの会社が得意な仕事を「分業」すると言う極めて合理的な考え方だ。しかし、現実は内製化したくなる場面も少なくない。多くの場合『コスト面』ではなく、『スピード面』や『品質面』で不満に感じる。

しかし、BPOサービスを提供する側が、BPMシステム(業務プロセス管理システム)を使いこなし、顧客の要望する業務フローに逐次近づける事ができたとしたらどうだろう? 『業務フローのダイアグラム』を使い、毎月のミーティングでカイゼン案を提示し、その日から業務フロー定義を変更できたとしたらどうだろう?

ここでは簡単の為に、総務アウトソーシングの名刺作成フローに注目し考察してみたい。

<各タスク名>
1.名刺作成申請、2.名刺作成承認、3a.作業着手通知、3b. 質問対応、4.作業完了報告、5.作業完了確認


[名刺作成:「3a.作業着手通知」画面]

今この瞬間、有効期限内の見積書は『何枚』提出されていているのか?
今この瞬間、それぞれの受注確率を加味した『受注見込総額』はいくらになるのか?
あるいは・・・
あのXXX案件の『現状のステータス』はどうなっているのか?
あのYYY案件の『最新の見積金額』はいくらになっているのか?

セールス関連の情報は、経営判断や事業方針決定に欠かせない。今どきの営業支援システム(SFA)でも「リアルタイム」にセールス関連情報を可視化できる。特にオンライン(クラウド)で管理する意義は大きい。例えば、過去に提出した見積書をいつでもどこからでも検索する事ができる。同じ顧客に対して違う見積金額を提示してしまう事も無くなるだろう。

しかし『見積書発行プロセス』や『受注プロセス』が自ら定義できるのなら、業務プロセス管理システム(BPM)で「セールス関連の情報」を収集する事ができる。(更には『生産プロセス』につなぎこむ事もできるだろう)

<各タスク名>
0. リード入力、1. 一次コンタクト、2. 提案ヒアリング、3. 見積書提出、4. 受注報告

[引合~見積書作成フロー:「2. 提案ヒアリング」画面]

会社によっては『翻訳』と言う仕事が「あちこちの部署」で発生する。「Webサイト」を翻訳したり、「プレゼン資料」を翻訳したり、場合によっては「製品に直接印刷される注記」を翻訳したり…。この様な場合、翻訳チームは、多くの部署からの翻訳依頼に対応する事になる。そして『翻訳業務フロー』は特定の部署に帰属する業務フローではなくなる。

業務プロセス管理活動(BPM活動)が成熟して行く過程において、特定の業務処理を共通化(サービス化)させる事は良く行われる。この翻訳チームは「社内向け翻訳サービス」を提供する組織となる。

以下のワークフロー定義は、多くの部署の業務プロセスから共通的に「呼び出される事」を想定した日英翻訳フローの例だ。

<各タスク名>
0.原稿投入/翻訳者指名、1.翻訳者指名、2.翻訳文作成、3.翻訳文レビュー

[日英翻訳 : 「1.翻訳者指名」画面]

提案書を作成したら…、Webコンテンツを作成したら…、プレスニュースの原稿を作成したら…、事業報告書を作成したら…、どんなものでも「レビューをしてもらう習慣をつける」事は大切だ。作成した本人には気付かない助言や第三者視点の感想が得られる。

以下のワークフロー定義は、ホワイトワーカ達は、企画書や提案書など何か成果物を作成する度に誰かにレビューを依頼すると言う仕組みだ。指名する相手は、上司でも良いし、同僚でも良い。

<各タスク名>
1.レビュー依頼、2.レビュー依頼対応報告、3.レビュー依頼対応確認

[汎用レビュー依頼 : 「3.レビュー依頼対応確認」画面]

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

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

<依頼例>
  • 【実行依頼】A書類のレビューをお願いします。
  • 【実行依頼】B案件につきCさんに回答しておいて下さい。
  • 【実行検討依頼】Dと言うアイデアを実行すべきだと考えています。一度検討して下さい。
  • 【実行検討依頼】Webサイトの表現を「XX」に修正すべきだと思います。確認して下さい。
実はこのワークフロー定義は『未整備ワークフローの発見』と言う課題において、非常に重要だ。未整備であるがゆえにメールや口頭で仕事を依頼してしまう。結果、仕事の記録が残らない。そして「見えないものは改善できない」。
『汎用的な依頼』の記録に何度も登場する仕事(依頼関係)があれば、ワークフローとして整備する事を検討した方が良い。

<各タスク名>
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.依頼承認」画面]