※「スグに試せるシリーズ」、連載その2。

ワークフロー・システムの導入検討、、、少しでも「意味のあるデータ」を流してワークフロー製品を評価したい。

シリーズ第2弾は「日報」をテーマに取り上げる。以下に紹介する『日報フロー』も、ワークフロー製品の試用期間に稼働させるワークフローとして非常に都合が良い。フロー図がシンプルで、小さなチームから大会社まで、どんな組織でもスグに使い始められる。この例も、メインの業務に影響を与えることなく小さく始められる点が良い。

[日報フロー]

※「スグに試せるシリーズ」、連載その1。

ワークフロー・システムの導入検討、、、少しでも「意味のあるデータ」を流してワークフロー製品を評価したい。

しかし幾ら探しても、自組織の業務に完全にフィットする業務サンプルはない。つまり業務と言うモノは100社100様で、会社規模・会社業種・所属部門によって「あるべき業務プロセス定義」が大きく異なってしまうのだ。そして、シンプル過ぎる業務プロセス定義例(ワークフローサンプル)をダウンロードし、ワークフローシステムとして稼働させても、『テスト』や『ほげほげ』などのテキトーな入力をしてしまう。

以下に紹介する『目安箱ワークフロー』は、ワークフロー製品の試用期間に稼働させるワークフローとして、非常に都合が良い。フロー図がシンプルで、小さなチームから大会社まで、どんな組織であっても(使おうと思えば)スグに使い始められる。何と言っても、メインの業務に影響を与えることなく小さく始められる点が良い。

[目安箱フロー]

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

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

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

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

[問合回答業務フロー]

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

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

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

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

[書籍購入申請フロー]

「業務フロー」に組み込まれるべき「業務フロー」を考える。(へ?)

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

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

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

[原稿翻訳フロー]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[問い合わせ対応フロー-回答メール自動セット]
各支店からの「売上高報告」、その速報値を集計したい?

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

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

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

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

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

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

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

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

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

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

以下の業務プロセス定義例は、分析のための工夫がされている。すなわち
  • ホームページの『問合フォーム』に投稿があった場合と、
  • 各所に掲載している『問合アドレス』にメールが届いた場合
に、自動的に【問い合わせ対応ワークフロー】が起動するだけでなく、「最終回答までに要した時間」とこの問い合わせ案件が発生した日の「曜日」が、業務記録として自動的にセットされる仕組みになっている。実は過去に紹介したワークフローとほぼ同じだのだが、データ加工を行う『スクリプトタスク』が足されている点で異なる。

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

(A)「各処理(各工程)を加速させるマニュアル」(ミクロな視点)も欲しいが、
(B)「業務全体について理解が進むマニュアル」(マクロな視点)も欲しい。

ワークフローの処理画面を見れば、経験のない人でも割り当てられた仕事を処理することができる。例えば『休暇を申請する』『休暇を承認する』『休暇の取得を確認する』などなど、およそ表示されたフォーム画面に従って入力すれば良い。(そこには(A)「各処理を加速させるマニュアル」があるかも知れない)
※(Aの例) Google Drive マニュアルをワークフロー処理画面に貼ろう!

しかし、、、
  • 休暇を取ると給料が減るの?
  • 休暇が承認されないケースはどんな時なの?
  • そもそも休暇制度はどのように規定されているの?
などなど、業務全体視点や制度全体視点での疑問を解決したくなるケースは少なくない。

以下のワークフロー・サンプルには『休暇制度に関する概要』(業務マニュアル)が収録されている。すなわち、(A)「各工程を処理するための処理マニュアル」とは別に、(B)「業務フロー全体についてのマニュアル」がワークフロー内で参照できる様になっている。(Questetra [Ver.9.7] の新機能!!)

[休暇申請フロー]

「印紙税」とは何とも不思議な税制だ。作成した紙切れ(文書)に対して課税する。
所得税(年貢)や酒税であればその情報を捕捉しやすいが、「居酒屋の領収書」から「極秘の取引契約」まで、あらゆる文書に課税するのだ。膨大な量の文書について適切に納税される保証はないし、公平性を担保すべき税務調査コストもバカにならない。17世紀に発明したオランダ人も、まさか21世紀まで存続するとは思わなかっただろう。

日本でも1873年(明治6年)に導入され、以後140年も続いている。21世紀の今日にあっても、多くの企業で切手の様なモノ(印紙)を貼り付けては消印を押す。面倒くさくて仕方がない。。。3万円以上の領収書1枚につき200円(17号文書)、預金通帳1冊につき200円(18号文書)、取引基本契約書1冊につき4000円(7号文書)。。。そして日本国中で毎年、1兆円以上の印紙が売りさばかれている。

#もし印紙を見た事が無い方は、是非一度、日本の居酒屋で3万円以上の食事をして「領収書クダサイ」と言ってみて欲しい。どんな店でも切手のようなモノ(印紙200円)を貼った領収書をくれる。

ただ、この「文書」の種類がヤヤコシイ。つまり、個々の文書が「20分類の文書」のどれに該当するのか、結局幾ら貼れば良いのか、企業の契約担当者は、国税庁のホームページを何度も何度も参照することになる。しかし、スグには分からない。そこに書かれている内容が難解なのだ。(全種類の文書を網羅的に説明する必要があるので仕方がないのだが)

[押印/郵送フロー-マニュアル表示]

『問合フォーム』からの問い合わせに対して、十分な情報を迅速に回答できているか?

問い合わせ者は「大きな不安」を持っているのかも知れない…。
問い合わせ者は「大きな期待」をしてくれているのかも知れない…。

『電話サポート』であれば担当サポートスタッフの能力に大きく依存してしまう傾向にあるが、『問合フォーム』や『質問メール』への対応であれば、組織として手順を工夫することで一定の品質を担保できるハズだ。

以下の業務プロセス設定例は、
  • ホームページの『問合フォーム』に投稿があった場合と、
  • 各所に掲載している『問合アドレス』にメールが届いた場合
に、自動的に【問い合わせ対応ワークフロー】が起動する。すなわち組織としての「問い合わせ対応業務」が自動的に開始される仕組みになっている。

簡単な問い合わせであれば、ワークフロー起動後、即座に回答文が準備され対応終了になる。難易度が高い問い合わせであれば、研究開発部門等に助言依頼が回され一次回答だけが送られる。いずれにせよ、問合対応業務をワークフローシステムで管理することで、全ての問い合わせについて、「今誰が担当しているのか」や「どのステータスにあるのか」あるいは「どんな社内議論になっているのか」が一目で分かるようになる。言うまでもないが《進捗》の可視化は、「対応の迅速化」と「成果物品質の向上」につながる。

[問い合わせ対応フロー]

「【アドホックなプロセス】は設計困難である」
(↑…ていうかコレ、言っている事が理解困難である)

【アドホック】(ad hoc)とは、平たく言えば「担当者や処理手順が決まってない」と言う事だ。業務プロセスの世界で言えば、処理が3つ存在する事が分かっているものの、〔処理A〕→〔処理B〕→〔処理C〕と処理されるケースもあれば、〔処理C〕が処理されてから〔処理A〕と〔処理B〕が同時に処理されるケースもある、と言う業務だ。【アドホック】のもともとの意味は「反復的でない」とか「恒久的でない」とかと言う意味だ。

少しヤヤコシイ話になるが、、、
そもそも「業務プロセス図の表記法」としての BPMN に『反復可能で事前定義された業務フロー』を、しっかり定義すると言う使命がある。
しかし一方で「業務システム」としての BPMS (BPMシステム) は、(反復可能だろうが無かろうが)あらゆる業務進捗を管理したい。つまるところ BPMS にとって『事前定義できそうにない業務フロー』をどの様に扱うべきか、は非常に悩ましいのだ。

Questetra では、この様なアドホックな処理は「寄ってタカって処理」できるように工夫されている。すなわち、「複数のタスクを1タスクとしてまとめ、その1タスクをみんなで処理しよう」と言う発想だ。具体的には、以下の3つ機能によって協調的な作業を提供する事によって解決しようとしている。実はコレ、IT調査会社や学会からは非常に注目されるポイントだったりする。
  1. 複数人が同時に議論できる『チームタスク』(※チームスイムレーン上のタスク)
  2. 掲示板型データ (※関係者がタイムスタンプ付コメントを追記し続けられる特殊なテキスト型)
  3. 社内SNS (※案件IDをタグ付けした投稿は全て案件に紐付く)

[投資判断フロー]

『BPM製品』=『ワークフロー製品』+{便利な機能群}

間違いではない。うん、正しい。『BPM製品』は『ワークフロー製品』でもある。(一方で「『ワークフロー製品』は『BPM製品』である」…とは言い難い)
IT調査会社Gartnerが「BPM製品の10の評価ポイント」において示している様に、BPM製品の中核は「ワークフローエンジン(プロセス処理および状態監視エンジン)」である。すなわちBPM製品はワークフロー機能を必ず有している。
  1. ワークフローエンジン(プロセス処理および状態監視エンジン)
  2. モデル活用型のプロセスモデル構築機能
  3. 文書ファイルやケースファイルの関連付け機能
  4. 組織情報やユーザ情報の関連付け機能
  5. 他システム接続機能
  6. 工程監視機能/イベント検知機能
  7. シミュレーション機能/最適化機能
  8. ルール統括機構
  9. システム管理/システム統制
  10. プロセスモデル定義の構成管理機能
しかしその実、『BPM製品』と『(従来からの)ワークフロー製品』とでは、サポートする「業務フロー図の形状」に違いがある。

[広報制作フロー]

調達部門や営業部門に付き物の「日報」。
成果や感想をまとめ、毎日マネージャに提出する仕組みだ。業種業態によっては、非常に有効な情報共有手法だ。提出する側も、コメントを書く側も、毎日のサイクルの中で処理できるのが都合良い。

しかし、一方でこの「日報」、、、マネージャ以外に参照される事は少ない。せっかくの生きた情報なのに、、、せっかくの履歴なのに、、、、何ともモッタイナイ話だ。

以下の報告フロー例『面談報告業務』では、その報告頻度が、「日次」ではなく「都度」を想定している。つまり報告書のタイトルは、『X年Y月Z日 佐藤一郎』ではなく『京都株式会社 X年Y月Z日往訪』となる。

こうしておくと、「取引先名」で検索した際に参照しやすい。ワークフローシステム全体を「取引先名」で検索すれば、『面談報告業務』に格納された履歴情報だけでなく、『発注業務』や『見積提出業務』などの履歴情報も、併せて一覧できるだろう。
例えば、経理担当者が外部からの請求書に疑念を持った際には、過去のコンタクト履歴を素早く参照する事が出来るようになる。例えば、経営者が初期コンタクトから見積業務・成約処理・請求業務と言った時系列の情報を得ることが出来るようになる。社内の情報が一気に整理される。

[面談報告フロー]

業務の流れを定義する際、「業務プロセスの【S:始点】と【E:終点】を何に設定するか」は、センスが問われる。

例えば『問合対応フロー』であれば、「s:問い合わせの受信」に始まり「e:回答の送信」に終わる。
例えば『請求書発行フロー』であれば、「s:請求データの入力」に始まり「e:入金確認」に終わるだろう。
・・・これらのワークフロー設定に異論は少ない。

しかし仮に、『s:引合対応』から『見積受注』や『製造』などを経て『e:請求入金確認』に至る様な、、、長い工程を「一つの業務プロセス」として定義したとすれば、それには大きな反論があるだろう。何と言っても、フロー図が複雑になり、その作業工程が見づらくなる。更には「業務データ」の項目数も必然的に多くなり、処理に必要なデータが見づらくなってしまう。


最も簡単な解決策は、≪(A)フェーズに分割して管理≫する手法だ。

一連の業務を「東京から大阪までの新幹線」に喩えれば、「(1)東京から名古屋」と「(2)名古屋から京都」と「(3)京都から大阪」に3分割して管理する方法だ。つまり、(1)~(3)それぞれのフェーズで重要な手順を、各設計責任者が定義する。『建築工事』や『研究論文作成』など、プロジェクト自体が長期に及ぶ業務を想像すればイメージしやすい。関与する人間(管掌する部門)が変わるポイントでフェーズ分割するのが王道だろう。

もう一つの解決策は、抽象化して≪(B)単純サイクルに分割して管理≫する方法だ。

「東京から大阪までの新幹線」で言えば、これを「発車から停車」と言うシンプルな業務プロセスの繰り返しと捉える。極めて汎用性が高くなり、また業務手順を詳細に記録できるようになる。同時に(一般論ながら)「全体」を俯瞰しづらくなる。

[発車から停車までの業務プロセス]

「よし、Google Apps の導入は完了した!」
「さて、Google Apps アカウントでログインできるワークフローを検証してみたい!」

近年、法人向け業務システムは確実に「クラウド・コンピューティング化」している。
平たく言えば『使った分だけ料金を払う仕組み』に移行しているのだ。ITも、水道、ガス、電気と同じ歴史を歩んでいる。特筆すべきは SaaS 製品の普及と多様化だ。ソフト購入の手間やバージョンアップの手間を大幅に削減した。実に便利な世の中になったものだ。

  • クラウド型グループウェア(メール+カレンダ+...)/オフィススイート(ワープロ+表計算+...): Google Apps、Microsoft Office 365、IBM SmarterCloud (旧 LotusLive)、、、
  • クラウド型顧客管理[CRM]: Salesforce、Microsoft Dynamics CRM、Synergy!、ZOHO CRM、、、
  • クラウド型経営資源計画[ERP]: SAP、Oracle、NetSuite、、、

「よし、ワークフローのテスト環境はできた!」
「さて、実際の業務データ(仕事)を流し、ワークフローを評価してみよう!」

良くあるテストとして、『無意味な業務フロー』に『無意味なテストデータ』を流す。しかし、それでは現実感(リアリティ)が湧かない。実のある評価が進まないのだ。たとえば「ココには注意書きが必要だな」など、実運用時に必要となる機能を試す機会を失ってしまう。

以下に紹介する業務テンプレート『目安箱フロー』は、(1)あまり存在しない業務フロー(業務重複にならないフロー)で、にもかかわらず、(2)リアリティが湧く業務フローで、ひょっとすると、(3)本運用の際にも稼働させ続けてもイイかもしれない、そんな業務フローだ。徳川吉宗(暴れん坊将軍)の『小石川養生所』や『町火消』の様に、新事業のヒントが上申されるかもしれない!!

[目安箱フロー]
「日常業務の手順」をキッチリ決めて、楽しく効率よく仕事を回す。
『稟議』『原稿作成』『クレーム対応』・・・、ワークフローシステムで仕事を流せば、手際よくそしてヌケモレ無く仕事を進められる。

一方で「非日常な業務の手順」をキッチリ決めておく事も、意外と重要だ。
特に、業務処理が自動的に記録される点が良い。いつ、どの様な書類で処理された(されている)のか、参照できるようになる。もし、過去のデータを簡単に再利用できるようになれば、後任者の業務効率は飛躍的に改善するだろう。

以下のワークフロー定義は『第三者割当増資』(資金調達)の事務手続きを定義している。
ベンチャー企業であれば、その発生頻度も少なくない。毎回「司法書士」に任せてしまうのも悪くないが、法務局の登記事務を含めて自分達で処理できれば毎回数万円の「司法書士報酬」を節約できる。さらに登記事務そのものに慣れれば、『新株予約権発行』の登記や、毎年の『役員重任』なども自分達で出来るようになるだろう!

[第三者割当増資の手続きフロー]

「契約書の郵送記録」って、意外と残ってナイ。
「いつ発送したのか」、「誰が発送したのか」、「同梱発送した内容物は何だったのか」
結構、大切な情報なのだが、案外ナイ。メールやFAXの通信記録なら、それなりに存在するのに。。。

以下は「契約書等」の郵送処理を行うのワークフローだ。秀逸なポイントは、特に重要な契約書の場合に、先方の手元に届いたかをきちんと電話確認すると言う工程だろう。「契約」と言う企業間にとって非常に大切なコミュニケーションが滞留するリスクを低減させている。さらに「送付状」の自動生成機能も秀逸だ。窓付封筒に入れれば、封筒に住所や相手先の名前を手書きする必要もなくなる。郵送事務コストを下げるばかりか、誤送ミスを未然に防ぐことができる。う~ん、かなりベンリだ。

[押印/郵送フロー-送付状生成]

『顧客データ』だけ集めたいな。。。

Web引合対応、問い合わせ対応、外出報告フロー(名刺交換)。。。 「顧客候補の情報」は、社内の色々な業務で収集されている。できることならば、一元的に管理したいものだ。(CRM活動の基礎データ)

以下は、顧客候補情報を管理するためだけのワークフローだ。
他の様々なワークフローから、「郵便番号」「都道府県」「組織」「部署」「名前」「メールアドレス」の主要データと、「メール配信同意の有無」(フラグ)「新規取引の可能性」(評点)が、送信されてくる事を想定している。

これは「データベースの様な使い方」と言っても良い。
ただ注意しなければならないのは、データは次々と『追加』されるばかりで、過去データの『更新』や『削除』には主眼が置かれない。すなわち、蓄積データを活用する際には、追加日時で絞り込む、処理者で絞り込むなどの工夫が必要となる。
いわゆる『ビッグデータ』の活用においても必要になる発想だが、新しい情報の『追加』を優先し、『更新』や『削除』のコストを押さえるべきケースは少なくない。具体的に言えば、『3年以上前の名刺情報』なんて、よほどの場合でない限り活用すべきではない。

[顧客データ収集プロセス]

業務記録と言えば「紙」が定番。

『請求書』や『発注書』、あるいは『契約書』や『議事録』などなど、様々な情報が「紙」で記録されるのだ。基本的な考え方は、江戸時代の『朱印状』や聖徳太子が遣隋使に持たせた『国書』と大して変わらない。要は証拠を残したい。

しかし、紙の管理は容易ではない。。。
何と言っても「情報検索性」が低い。更には「情報共有」も不可能に近い。
  • 「あの契約書って、いつ郵送したんだっけ???」
  • 「あの注文請書、ちゃんと誰か郵送した???」
情報端末が爆発的に普及した21世紀。我々は「証拠を残しておきさえすればイイ!」と言う考えから、「活用しやすい形で業務データを記録する!」と言う発想に改めなければならない。少しずつでも電子化/電磁的記録を推進する必要がある。

以下は、「会社から発送される郵送物」を、少しでも電磁的に記録しようと試みるワークフローだ。
コピー機でコピーをとってバインダーに閉じるのではなく、元となったデジタルデータと処理時刻を正確に記録する所に主眼がある。押印やサインが必要な書類の場合には、「スキャンデータ」も追加で保存される。

[押印/郵送フロー]

『提案書』や『企画書』を書くのがシゴト! そんなビジネスパーソンは少なくない。

IT業界のセールス、広告代理店の企画部門、コンサルティング会社の公共担当部署、などなどなど。。。 しかし提案書作成や企画書作成は「個人プレー」に走りがちだ。つまり、なかなか「ノウハウ」が溜まらないし、なかなか「再利用性」が高まらないのだ。
仮に「ファイルサーバに保存する事」と言うルールを決めたとしても、「メンドウ」と言う理由だけで一元管理されることはない。多くの企画書ファイルは、誰かのパソコンの、どこかのフォルダで、深い眠りにつくのだ。もっともっと、みんなで共有すればイイのに。。。

以下のワークフローは、「他人の提案書を読む」と言う活動を『業務』として規定している。
この例では「イイのデキタ!」と思うプレゼン資料を登録すると、指名した同僚2名がレビューする事になる。と同時にその資料がクラウド型オンラインストレージ『Google Drive』の該当フォルダに保存される仕組みだ。(『新規顧客向け提案書』『既存顧客向け提案書』『テンプレート/その他』)

[提案書レビュー・共有フロー]