受託開発ソフト会社にせよ、BPO受託会社にせよ、お客様との約束事である『納品日』はゼッタイだ。一度の遅延が会社の信頼を大きく失墜させる。しかし、その『納品日』を十分に共有できているとは言い難い。

チームメンバーはむしろ「自分の処理」についての締切を認識し続ける。つまり「全工程」の締切である『納品日』については認識する機会が少ないのだ。≪ワークフローシステム≫の画面を見ていても、各工程担当者にとって「自分が引き受けた処理」についての締切(処理締切)は分かりやすいが、チーム全体として大切なハズの「全体納期」は認識しづらい。

ましてや…「今月末は納品日が集中しているゾ」と言った"案件横断的な情報"は、把握できるハズもない。

以下のワークフローでは「納品日データ」が≪カレンダーシステム≫と同期される仕組みが用意されている。具体的には「受注情報」の中の「納品日データ」が、OAuth (オーオース) と言うセキュア通信を使って Google Calendar に自動的に書き込まれる。カレンダーを見れば、いつでも「納品日の分布」を全体俯瞰する事ができる。これはチームメンバだけでなく、取締役や監査役にとっても非常に重要な情報源となる。

[受託~納品フロー]
※この記事には「改善編」があります

様々な日常業務をワークフロー化(ペーパレス化/電子化)している組織なら、『出退勤情報』(勤怠情報)もワークフローで流すと良い。

どうせワークフローで管理するなら「月に一度の出勤簿」作成ではなく、出勤時刻と退勤時刻を日次報告させる仕組みにするのはどうか?

良く考えると、前月1カ月をアレコレ思い出しながら出勤簿を作成させるのはナンセンスだ。上司だって「1カ月分の出勤簿データ」を一括して渡されても、もはやチェック機能を果たせないだろう。もし日次の勤務時間確認であれば、チョットした移動時間を使って承認処理できる。

[タイムカード]

会社には「多くの人に参照されるべき文書」が、いくつもある。
製品の『取扱説明書』、現場の『作業マニュアル』、あるいは『契約書の雛形』や『各種社内規程』などなど、実に多種多様だ。そして、その「文書」をメンテナンスし続ける事は、非常に難儀だ。改定時に「他の言語への翻訳」が必要になる類の「文書」なら、更にその管理は困難を極めるだろう。

以下のプロセス図は『製品マニュアル』の改訂を行う業務手順を表している。この業務プロセス定義でシステム化すれば、文書の改訂ポイントや最終確認者などが自動的に記録される様になる。

[マニュアル改訂]

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

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

シリーズ第3弾は「汎用作業依頼」をテーマに取り上げる。以下に紹介する『汎用作業依頼フロー』は、少し変わったワークフローだ。何せ、どんな業務にでも利用できる。ヘンな言い方をすれば「未定義の業務フロー」を定義している。

しかし、この「未定義領域の作業」を可視化する事(あぶりだす事)は非常に重要だ。「汎用作業依頼」で何度も依頼されている内容は、すなわち何か重要な業務プロセスが未定義となっている可能性が高い。仮に全く同じフロー図(構造※)になったとしても、業務履歴を自動記録するためにも、別のワークフロー(プロセスモデル)として稼働させた方が良いかも知れない。
※ 『1.作業依頼』→『2.完了報告』→『3.完了確認』と言う2者間の依頼構造

[作業依頼フロー]