ワークフローサンプル

「回答メールを、協調作成したい」
「回答メールの作成進捗を、可視化したい」

問い合わせ対応フローは複雑だ。『エスカレーション』や『技術調査』、『営業部門依頼』や『FAQ登録』などなど、複雑な分岐フローが存在する会社も少なくない。「組織規模」による違いも大きい。おなじ業種でも10人組織と100人組織、1000人組織では、その流れは全くチガウだろう。すなわち、問い合わせ回答業務は、自分達にとって「あるべき姿」を模索し続けたい業務の一つだ。イマドキであれば「業務プロセス管理ツール」(BPMツール)で、業務フローの最適化を図りたい。

しかし、「フローの変更や改善」は得意な『汎用的な業務プロセス管理ツール(BPM)』ではあるが、入力画面の使いやすさの観点では、どうしても分が悪い。たとえば、自社の業務を考えてキッチリ設定した『入力項目』もそれら全てが「均一な感じ」になり、「どれが重要項目？」が分かりにくくなってしまう。

『Questetra BPM Suite』の場合、「入力フォーム画面」を徹底的にカスタマイズできる機能を持っている。
HTML の知識が必要になるが、「誰でも処理できる入力画面」や「スピーディに対応できる入力画面」を探究し続ける事ができる。新人社員でも即戦力になれるだろう。（高度なレイアウト機能）

[問合回答業務フロー]

「会社で書籍を購入する」、良くある話。

例えば、研究機関、Ｒ＆Ｄ部門、マーケティング部門。。。調査仕事に書籍は欠かせない。
例えば、ソフトウェア会社、デザイン会社、建築会社。。。クリエイティブな仕事にも最新書籍が欠かせない。

「欲しいと思った人が、欲しいと思った時に買う」のは良いとしても、せっかく会社の経費で買った本だ、、、社内に情報共有しておきたい。もし、『いつ誰がどんな本を買ったのか』がスグに分かる環境にあれば、「買おう」と思った本を買わずに済むかも知れない。「買うまでも無いかなぁ」と思った本が、隣の部署で立ち読みできるかも知れない。

以下のワークフローは書籍購入申請だ。「購入依頼」だけでなく「事後報告」にも利用できる。つまり、全ての書籍購入が記録され、自動的に保有書籍のデータベースが出来上がる仕組みだ。

[書籍購入申請フロー]

「業務フロー」に組み込まれるべき「業務フロー」を考える。（へ？）

結論から言えば『専門技能を部門横断的に発揮すべき仕事』が、それにあたる。事業内容あるいは会社規模によって大きく異なるが、「誤植確認」「原稿翻訳」「商標法違反チェック」「プレゼン資料ブラッシュアップ」などなど様々だ。

以下のワークフロー定義は、「原稿の日英翻訳業務」が多くの部署で発生する会社の「原稿翻訳フロー」だ。他の業務フローから呼び出される事（組み込まれる事）が想定されている点が秀逸だ。しかも翻訳完了後、「元の業務プロセス」に対して英訳済原稿データを自動的に送り返す。古いIT用語で言えば『サブルーチン』と言う仕組みだ。ビジネスプロセス的（BPM的）には『サブプロセスの呼び出し』と言っても良い。

社内の「翻訳センター」とでも言うべきこのチームは専門技能者の集まりだ。「彼らへの入力」と「彼らからの出力」を定義することは全社の業務効率の改善に大いに貢献する（在宅勤務制度のヒントにもなろう）。ちなみに、しばしば「本業に集中すべくこの業務は社外アウトソースしましょう」と言う議論になるが、社内用語・専門用語を熟知している点で、社外へのアウトソースとはクオリティが違う。

[原稿翻訳フロー]

『出張申請』はヤヤコシイ。

「事前承認」が必要だったり、「仮払い」(事前現金支給)をしてもらう必要があったり、会社側が手配してくれる種類のチケットがあったり…と、なんせ手続きが面倒なのだ。もし延泊して個人旅行を兼ねようものなら、何を提出すれれば良いかサッパリ分からない。

一方で『出張申請』を受け取る上司や経理担当だって嬉しくない。コト細かく入力された行程や必要経費について、確認するだけでもタイヘンだ。そもそも、イツでもドコでも予約変更できるこの時代に、『旅行計画』などと言う言葉自体が古い。。。また精算処理にしても「法人クレジットカード」で購入できるものが多くなり、もはや仮払いを行う必要性も無くなってきた。精算すべきものは立替金申請に含めて一括で精算したい。。。

以下の申請ワークフローは「仮払い制度」を廃止し、【出張計画の概要】を事前承認する点に重きが置かれている。

秀逸な点は、入力された出張行程(地名)を Google Map で参照できるところだ。その『移動ルート』や『移動コスト』がワンクリックで把握できるため、「承認する立場の人」(上司)や「監査する立場にある人」もその出張概要を瞬時に理解できる。

[出張承認フロー]

意思決定には、「1つの案に対して可否を決定」するパターンもあれば、「複数の案から選択」すると言うパターンもある。

日本独自の伝統的なビジネス習慣である『稟議書』は、「1つの案」に対して可否を決定するワークフローだ。（恐ろしく大人数の…、そして紙が真っ赤に染まる程の…、印影が押される）

一方、以下のワークフロー定義は、「複数の案」から選択する選定ワークフローの例だ。
この例では上流工程にて「候補地」と各候補地の利点や課題についての考察が列挙され、下流工程で「開催地」が決定される。「セミナー開催地の選定」と言った真面目な業務から、「社員旅行の行先決定」と言ったユルイ業務まで、様々な選定で活用できるだろう。

当然の話だが、最終決定を選択する選択肢は案件毎に異なる。すなわち、下流工程の選択インターフェースを「セレクトボックス(選択型)」で表示したくても、各案件毎に選択肢が変わる。この様な場合、上流工程で入力された「複数行の文字列型」の各行を「下流工程の選択肢」として表示させると言う技を使う。例えば、上流工程で『候補地』(文字列型複数行)に

東京
マドリード
イスタンブール

と言う3行テキストが入力されれば、下流工程の『開催地』セレクトボックス(orラジオボタン)に「東京/マドリード/イスタンブール」が一覧されると言う仕組みだ。

[セミナー開催地選定フロー]

業務プロセスの中で「乱数」を使うケースは、、、あまりナイ。

強いて言えば、内部統制視点で「レビュー者の固定化」を防いだり、当選者を決める「厳正な抽選における当選者番号の決定」で自動化させたり、…するくらいだろうか？

以下のワークフローサンプルは、社内で「しりとり」ができる業務プロセス定義だ。全くもって実用性はないが、クエステトラのブログで紹介したところ「アーカイブを見てみたい」との稀有な意見もあったので、改めて当サイトのコンテンツとして紹介しておく。（もちろんアーカイブも無料ダウンロード可能）

この例では「しりとり」のやり取り相手（回答者）が「乱数」で選択される。分岐ゲートウェイの直前で「乱数」を発生させ、その乱数に従って分岐ゲートウェイの経路が選択される仕組みだ。（自動分岐）

[しりとりフロー]

お客様からの「問い合わせ」に対し、『迅速』かつ『正確』に答えたい。

「問い合わせ管理システム」は色々あるが、自社オリジナルの回答フローを反映できるシステムは多くない。品質向上、スピードアップ、再発防止、、、業務フローを改変する動機は様々だが、創意工夫した問合回答フローがシステムに反映できなければ「人間コスト」が増える一方だ。
例えばもし「不具合に関する問い合わせ回答には、必ず技術部隊のレビューを得る」と言った業務ルールが存在するなら、もはや「問い合わせ管理システム」ではなく「業務プロセス管理システム」（BPMシステム）で管理すべきかも知れない。フロー図上に現在進捗（滞留状況）を俯瞰できるようになり、統括責任者の指示も大幅にスピードアップする。（更には、受信窓口が各回答担当の得意領域に応じて案件を手動で振り振る、と言ったフロー拡張が起きるかもしれない）

以下の業務プロセス定義は、「メール問合」や「Webフォーム問合」から、「回答メールの送信」までのワークフローが定義されている。このワークフローを活用すれば、「一次回答の文面」や「最終回答の文面」だけでなく、「先輩社員のチェック時刻」や「他部署からの助言」も、ひとまとまりの業務データとして記録される。ナレッジとして参照できるようになり、また更なる業務改善の基礎データにもなるだろう。

[問い合わせ対応フロー-回答メール自動セット]