出張申請の「経路」は Google Map で！

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

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

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

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

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

[出張承認フロー]

静的な選択肢と動的な選択肢、開催地選定フローの例

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

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

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

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

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

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

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

乱数を利用したワークフローの自動分岐

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

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

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

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

[しりとりフロー]

問合受信と同時に回答文ドラフトを自動生成

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

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

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

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

売上高をその日の為替レートで自動変換（為替API活用）

各支店からの「売上高報告」、その速報値を集計したい？

前回紹介した日報ワークフロー（※）があれば、いつでも売上高の日次変動を確認できる様になる。絞り込み機能を使えば、任意の期間の売上高を集計する事も容易だ。しかし一部の売上高報告が、異なる通貨になっていればどうか？？？
※ 「日報」に気象データを取り込む意味（天気API活用）

以下のワークフローは前回紹介の『営業日報フロー』をベースに、当日の為替レートで売上高を変換する機能が追加されている。すなわち、その日の為替レート情報をインターネットから自動的に取得し、海外店の店長が入力した売上高（現地通貨）を本店通貨表記に自動変換する仕組みだ。実際に本店の通貨に換金するタイミングは異なるにせよ、売上高の「速報値」を自動集計できるようになるのはスバラシイ。

[営業日報フロー-為替]

「日報」に気象データを取り込む意味（天気API活用）

「天気」に左右される業務は少なくない。

良く議論される事例として「ビールの仕入業務」がある。ウェザー・マーチャンダイジングなどと言われる事もあるが、要するに「売れ行き」を予想して「仕入」を行う業務だ。担当者は天候や予想最高気温などを見て（更に祭事やイベントをチェックして）その発注数量を決めるのだ。

もちろん他にも色々ある。
「建設現場の週間計画」、「農業の悪天対応」、「イベント体制の準備」、「ゴルフ場のキャンセル対応」などなど、様々な業務で天気が影響する。また、一見『屋外』とは縁の無さそうな「通販業の問合対応」なども、実は天候に左右されるらしい。

以下の業務フローは飲食業の売上日報だ。典型的な「日次報告型のワークフロー」と言える。
ここでは天候と気温も併せて報告させ「気象による売上変動」を分析するための基礎データとなるようにしている。特筆すべきは、その気象データがあらかじめ自動的に入力されている点だ。報告担当者は『天候』や『気温』を入力する必要が無い。この雛形は、清掃業・建設業・人材派遣サービス等でも転用できるだろう。（「夏休みの絵日記」に転用してはイケナイ…）

[営業日報フロー-天気]

目指せコンシェルジュサービス！ 回答所要時間を自動記録

ホームページ問い合わせの回答、平均何時間？
土日の問い合わせにも、キチンと対応できてる？

処理件数が増えてくると分析したくなる。例えば『問合フォーム』への「平均レスポンス時間」を分析したい。業務を定量的に観測すると、業務改善は加速する。反省会の基礎データにもなるし、目標も立てやすい。

以下の業務プロセス定義例は、分析のための工夫がされている。すなわち

• ホームページの『問合フォーム』に投稿があった場合と、
• 各所に掲載している『問合アドレス』にメールが届いた場合

に、自動的に【問い合わせ対応ワークフロー】が起動するだけでなく、「最終回答までに要した時間」とこの問い合わせ案件が発生した日の「曜日」が、業務記録として自動的にセットされる仕組みになっている。実は過去に紹介したワークフローとほぼ同じだのだが、データ加工を行う『スクリプトタスク』が足されている点で異なる。

[問い合わせ対応フロー-回答時間記録]