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

例えば「見積書」(前回記事)であれば、大まかなに、(1)上司承認、(2)客先提出、(3)受注確認、といったステップになるだろう。その設計において、
  • 税務や会計などの「専門知識」
  • 他システム連携やデータ加工といった「システム知識」
  • 月次決算の迅速化といった外部圧力やそれに対する使命感
  • 会計記帳と財務出納の分離といった相互牽制(内部統制)の工夫
などは不要だ。(意外と「見積書発行フロー」は平和)

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

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

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

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

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

しかし上司にしてみれば、似たような「見積書」をタクサン見せられても、スグには承認できない。
  • 「納期」はコレで良いのか?
  • 「値引金額」はコレで良いのか??
  • 「見積有効期限」はコレで良いのか???
承認者のシゴトは、他の見積書と比較して判断するコトだ。(転記ミスや誤植を探すのがシゴトではない)

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

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

[見積承認フロー]

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

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

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

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

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

[翻訳フロー]
部下の原稿をチェックするなら「赤ペン」に限る?

確かに、紙に原稿を印刷して、
  • この辺がダメ!
  • この辺が読みづらい!!
  • この辺をもっと具体的に!!!
とかとか、アレコレと自由に書き込むのは気持ちイイ。。。場合によっては、矢印つけたり、文章全体を囲んだり、、、その作業効率は非常に良い。(紙を手渡しできるなら/口頭で補足できるなら/記録が残らなくてイイなら)

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

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

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

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

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