ワークフローサンプル: 2013/09

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

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

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

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

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

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

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

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

以下の業務プロセス設定例は、

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

に、自動的に【問い合わせ対応ワークフロー】が起動する。すなわち組織としての「問い合わせ対応業務」が自動的に開始される仕組みになっている。

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

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

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

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

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

Questetra では、この様なアドホックな処理は「寄ってタカって処理」できるように工夫されている。すなわち、「複数のタスクを１タスクとしてまとめ、その１タスクをみんなで処理しよう」と言う発想だ。具体的には、以下の3つ機能によって協調的な作業を提供する事によって解決しようとしている。実はコレ、IT調査会社や学会からは非常に注目されるポイントだったりする。

複数人が同時に議論できる『チームタスク』（※チームスイムレーン上のタスク）
掲示板型データ（※関係者がタイムスタンプ付コメントを追記し続けられる特殊なテキスト型）
社内SNS （※案件IDをタグ付けした投稿は全て案件に紐付く）

[投資判断フロー]

『BPM製品』＝『ワークフロー製品』＋｛便利な機能群｝

間違いではない。うん、正しい。『BPM製品』は『ワークフロー製品』でもある。（一方で「『ワークフロー製品』は『BPM製品』である」…とは言い難い）
IT調査会社Gartnerが「BPM製品の10の評価ポイント」において示している様に、BPM製品の中核は「ワークフローエンジン（プロセス処理および状態監視エンジン）」である。すなわちBPM製品はワークフロー機能を必ず有している。

ワークフローエンジン（プロセス処理および状態監視エンジン）
モデル活用型のプロセスモデル構築機能
文書ファイルやケースファイルの関連付け機能
組織情報やユーザ情報の関連付け機能
他システム接続機能
工程監視機能／イベント検知機能
シミュレーション機能／最適化機能
ルール統括機構
システム管理／システム統制
プロセスモデル定義の構成管理機能

しかしその実、『BPM製品』と『(従来からの)ワークフロー製品』とでは、サポートする「業務フロー図の形状」に違いがある。

[広報制作フロー]

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

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

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

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

[面談報告フロー]