ワークフローサンプル: 2015/04

全ての企業活動は「請求」のために行われている、と言っても過言ではない。しかし、その業務プロセス設計は難易度が高い。

例えば「見積書」（前回記事）であれば、大まかなに、(1)上司承認、(2)客先提出、(3)受注確認、といったステップになるだろう。その設計において、

税務や会計などの「専門知識」
他システム連携やデータ加工といった「システム知識」
月次決算の迅速化といった外部圧力やそれに対する使命感
会計記帳と財務出納の分離といった相互牽制（内部統制）の工夫

などは不要だ。（意外と「見積書発行フロー」は平和）

しかし一方で「請求書」の場合は、その下流工程に「売掛金の記帳」「入金の確認」「証憑としての保管」といった重要な作業が続く。実際、業種業態や会計方針、そして導入済みの他システムによって各社様々だ。業務プロセスの始点(開始ポイント)や終点(終了ポイント)ですら、その「あるべき姿」は各社違う。

以下のワークフローは、「請求書の発行後」にフォーカスされた業務プロセスだ。経理部門に閉じた業務プロセスではあるが、「会計ソフト／会計クラウドへの入力を軽減させる」などの工夫がある。

[請求書発行から会計記帳まで]

「"値引き要求" に応じてでも、売りたい！」

もちろん業種に依存する話だが、ビジネスの現場において「承認が必要な見積書」が必要になるケースは少なくない。「納期」や「見積金額」などが微妙に違う見積書、、、が何枚も必要になることだってある。

しかし上司にしてみれば、似たような「見積書」をタクサン見せられても、スグには承認できない。

「納期」はコレで良いのか？
「値引金額」はコレで良いのか？？
「見積有効期限」はコレで良いのか？？？

承認者のシゴトは、他の見積書と比較して判断するコトだ。（転記ミスや誤植を探すのがシゴトではない）

以下の見積承認プロセスでは、見積データが承認された後に、自動的に「見積書PDF」が生成される仕組みだ。承認判断の工程では、業務データに集中して承認できる。たとえば、過去に承認した見積書や、過去に否決した見積書の［データ項目］を比較して判断する事もカンタンだ。

当然のことだが、このワークフローに従って日頃の見積承認業務を処理していれば、見積データが綺麗に蓄積されていく。また、承認された見積書PDFも全て自動的に蓄積されていく。前任者のナレッジも引き継ぐことが出来る。すばらしい。

[見積承認フロー]

マニュアル、プレスリリース、Webサイト。。。

翻訳仕事は様々な部署で発生する。確かに "一般的な翻訳" なら Out-sourcing や Crowd-sourcing も選択肢に入るが、"専門用語バリバリ" の文章は内製すべきと言える。（もしくは特定の翻訳依頼先に絞るべきと言える）

以下はシンプルな翻訳業務だ。

特筆すべきは、翻訳されるべき文章が "2段組み表示" の左側に表示され、翻訳文を右側の入力フォームに書きこめる点だ。特に短い原稿なら、Webブラウザだけで素早く処理できる。（ブラウザのスペルチェッカ―機能拡張も有用！）

また "いつ/誰が" といった基本的なワークフロー情報以外に、"作業量" (翻訳文の文字数)を自動計測している所も、非常に秀逸といえる。

[翻訳フロー]

部下の原稿をチェックするなら「赤ペン」に限る？

確かに、紙に原稿を印刷して、

この辺がダメ！
この辺が読みづらい！！
この辺をもっと具体的に！！！

とかとか、アレコレと自由に書き込むのは気持ちイイ。。。場合によっては、矢印つけたり、文章全体を囲んだり、、、その作業効率は非常に良い。（紙を手渡しできるなら／口頭で補足できるなら／記録が残らなくてイイなら）

この「赤ペンが持つ機能」（？）は、パソコンソフトであれば「校閲機能」に該当するのだろう。『Microsoft Word』の場合、上司は「変更記録」モードで書き込み、部下は「変更箇所/コメントの表示」モードで確認する。

うんうん。ん？ Web ワークフローであれば、どうすればイイの？

以下のワークフローは「JavaScript のレビュー業務」を表している。このレビュー工程では、レビューされるべき原稿が「2段組み表示」の左側に表示され、レビューコメントを右側にある入力フォームに書きこむ、と言う仕組みになっている。

確かにこの設定は「仕組みとしてシンプルすぎる感」が否めない。が、しかし、使ってみると意外と便利だったりする。何と言っても、特別なパソコンソフトを立ち上げる必要もなく、素早く対応できる点がスバラシイ。

[スクリプト・レビュー]