ワークフローサンプル

「検収報告を受ける」という受け身な工程

イラスト制作・Webサイト制作・内装工事。。。そんな受託事業には「検収対応」がツキモノです。

請負契約に基づく案件は、単に、(1)成果物を「納品する」だけではなく、(2)クライアントから「検収報告書を受け取る」という段階を経て始めて、(3)委託費を「請求する」ことが可能となります。

（もっとも、特別な取引関係にあっては「検収工程」が省略され「納品即請求」が許されるケースもありますが…）

世界中で

クライアントの為に「検収報告書」のサンプルを添付する
文書名を『納品書』とせず『検収依頼書（兼納品書）』といった名前にする

といった涙ぐましい努力や工夫が行われています。

何をする工程か決まってない？

しかし、現実の「検収報告の受領」は、

A. 納品当日に「検収報告書」を渡してくれるケース

ばかりではありません。

B. 検収期限ギリギリに「検収報告書」を送ってくれるケース
C. 検収報告書の提出は行われず「みなし検査合格に関する規定」の適用を前提とするクライアント

など、様々なケースが発生してしまいます。更に言えば、

D. 「成果物が仕様を満たしていない」と判断されて検収期間の延長を迫られるケース
E. 「成果物が仕様を満たしていない」と判断されて再納品を迫られるケース

もあるでしょう。

ではこの様な場合、どのように業務プロセスを描けばよいのでしょうか？　とくに「何もせずに期限がきて終わる」という(C)は、どのように表現すれば良いか悩みます。

[検収対応フロー]

とある工程の作業時間を計測したい

たとえば翻訳工程における「翻訳に要した時間」を計測したい場合、「翻訳結果」とともに「実作業時間」を報告（入力）してもらう方式が考えられます。

しかし、その方式では、各翻訳者に

着手時刻を手元にメモしておく
昔ながらのストップウォッチを使う
作業時間を計測するストップウォッチソフトを使う
翻訳結果を入力する画面に表示させた『ストップウォッチ・ボタン』を使う

といった手段で実作業時間を計測してもらう必要があります。この「作業時間を自己計測して報告する」という行為は、大きな手間と言わざるを得ません。

※もっとも「離席休憩」や「割り込み作業対応」といった除外すべき時間が途中発生した際に、計測を一時停止させる等の柔軟な対応が出来るメリットもあります。

報告値の確からしさ

また、結果として「正確でない実作業時間」が報告されてしまう可能性もあります。

たとえば人事考課や能力査定などの面で、「翻訳時間」を短く見せる（長く見せる）ことに何らかのインセンティブが働く制度なのであれば、その「作業時間」は少しずつ事実とは異なる数値が入力されるでしょう。

あるいはまた、シゴトの成果そのものに誇りを持ち、「翻訳時間」などに全く興味を持たない作業者がいたとすれば、「イイカゲンなデータ」が入力されることを想定せざるを得ません。

[翻訳フロー]

ミス発生に伴う生産性ダウン

決裁者さんにとって「差し戻し処理」は、億劫（おっくう）です。

申請内容を読み『無言』でOKすれば良いハズ（3分）のところ、（無言でNGするワケにも行かず）、更に10分かけて『差し戻す理由』を書かなければなりません。しかもそれが「単純ミスや誤記の指摘」であり、それが一日に5件・10件も発生するとなれば、流石に気分も滅入ってしまうでしょう。

そして当然、帰宅する時刻も１時間・２時間と遅くなってしまいます。

システム改良で下げられるミス率

『日付』をまちがう、『金額』をまちがう、『顧客の名前』をまちがう。

申請者さん達も、好き好んで間違っている訳ではありません。基本的には（？）、「業務プロセス定義の工夫や改良」によってミス率を下げることを考えたいものです。（プロセスを憎んでヒトを憎まず！）

入力画面の「注意書き」や「入力チェック」を改良する
業務フローに同僚による「レビュー工程」を追加する

[申請系プロセスのベースフロー-スクリプト]

各案件のログ

業務プロセスの最適化を考えるとき、「マスタ系のデータ」と「トランザクション系のデータ」の２分類における後者データを分析します。

具体的に言えば、『商品マスター』や『顧客マスター』などの「マスタ系データ」ではなく、『見積書No123の詳細』や『請求書No123の詳細』といった発生記録としての「トランザクション系データ」を分析します。

分析に有用なログ

ワークフローシステムに流れる『〇〇案件の詳細』は、案件が開始されるたびに蓄積されるデータであり、全て「トランザクション系データ」に該当します。

しかしながら、業務プロセス内で定義された『データ項目』に、全てのトランザクション情報が格納されている訳ではありません。たとえば『第2工程に到達した時刻』や『ループ構造を周回した回数』といった「システム側で保持されている情報」（案件それぞれのログ）は、エクスポートしやすい形で格納されていません。

以下のワークフローは『差し戻された回数』（ループ構造を周回した回数）という「システム側で保持されている情報」が、業務プロセス側の『データ項目』に自動的に取り込まれる設定となっています。

[申請系プロセスのベースフロー]

小さく始める

「システムに慣れるには、どうしたら良いでしょうか？」

投資効果だけを考えれば「既存の非効率な業務」をシステム化するのが効果的です。もし「紙ベース」で行われている業務があるのなら、その業務のシステム化を検討すべきです。もし、受注・出荷・請求といった「基幹業務」に適用すれば、比較的容易に『効果』が『投資』を上回ることでしょう。

しかし、(1)管理者：システムの設定ノウハウが高くない、(2)一般社員：システムの利用リテラシが高くない、といった状況なのであれば、全く『効果』が出せない危険性もあります。それは「原稿用紙に手書き」してきた小説家に「パソコンでの制作」を強要するようなものです。

「システムの導入で、業務効率を悪化させてしまうかも」。そんな不安がある場合、まずは「小さな業務」で、（できれば毎日必ず行う業務で）、試運転するのが良いかも知れません。

改良し続けるという習慣

ペーパレスやテレワークを推進する際には、「ワークフローシステム」の導入が検討されます。

最初に適用する業務を何にすべきかは、非常に悩ましいところですが、たとえば、以下の「勤務時間報告」という小さなワークフローは有力な候補と言えるでしょう。何と言っても「必然的に毎日利用することになる」のが良いところです。

実際に「データ入力」を行ってみて、実際に「承認」を行ってみて、、、何が必要で、何が省略できるのか、おのずと理解が深まるでしょう。また、その利用の中で、様々なアイデアも生まれてきます。

管理者：業務フローの設計ノウハウが高まる
一般社員：工程を担当するという基本的な使い方を理解できる

[出退勤報告フロー]

入力ミスが多い？

ワークフロー・システムでは、ヒューマン工程における「入力ミス」が避けられません。

たとえば「請求書発行日」と「入金期限」の２つの日付を入力する必要があるワークフロー工程であれば、

データ複製のまま１年前の日付を入力してしまう
請求書発行日と入金期限を逆に入力してしまう

といったミスが発生しがちです。（折々に、実際の発生率を計算してみるのも良いでしょう）

もちろんミスをした担当者が不注意なのかも知れません。あるいは、集中力を高めれば、その瞬間だけはミスなく入力できるかも知れません。しかし、100件・1000件と「ミスなし」を続けることは、むしろ困難と言わざるを得ないでしょう。もし入力項目数が多い業務なら、5件・10件でもミスなく入力することですら難しいかも知れません。

初期値を設定する

システム機能として「初期値の設定」が可能なら積極的に利用したい所です。

クラウド型ワークフロー『Questetra BPM Suite』の場合、日付データ項目の初期値として「今日から3日後」や「来月の末日」を設定できます。「データ複製」のケースには無力ですが、新しい案件データを業務プロセスに流す場合には、とても有効な方法です。

＜設定画面＞

[日付入力フォームのテスト]

入力ミスが多い？

ワークフロー・システムでは、ヒューマン工程における「入力ミス」が避けられません。

たとえば「単価」と「数量」の２つの数値を入力する必要があるワークフロー工程であれば、

12000 が 1200 と一桁が足りない数値を入力してしまう
金額を入力すべき場所に数量を入力してしまう

最大値・最小値を設定する

システム機能として「入力値の制限」が可能なら積極的に利用したい所です。

クラウド型ワークフロー『Questetra BPM Suite』の場合、数値データ項目には「最大値」と「最小値」を設定できます。もし「単価」の入力値を「10,000円～100,000円」と制限しておけば、その入力制限によって「1200円」という誤入力の発生率をゼロにすることが可能です。

＜設定画面＞