最大4人に対して、「プロジェクト進捗度」(0-100)を回答してもらう。

毎週あちこちの調査をおこなう内部監査室にしてみれば、「進捗度の平均値」くらい自動算出されてればイイのに、、、と思ってしまう。

以下のワークフローには、報告者(1~4人)の入力が全員完了した時点で、自動的に「平均値」が算出される仕組み(スクリプト工程)が組み込まれている。(更には、その平均進捗度が90%を超えている場合に、自動的に関係役員宛メールが送信される仕組みにもなっている。)

このような「社内状況把握の自動化」は、業務の効率化のみならず、品質管理体制の強化等にも寄与するだろう。(受託事業、建設業、など)

[進捗報告プロセス-自動計算]

「工事進行基準」の会計処理には、"不正" の影が付きまとう。(東芝さん、ダイジョウブ?)

なんせ「進捗」に合わせて売上と原価を計上するのだから、会社は「真の進捗率」を把握し続けなければならない。もちろん、当初見積もり通りにプロジェクトが進んでいる場合は、「発生原価」と「当初見積」から導かれる「発生原価から算出された工事進捗」でよい。しかし、ゼネコン会社にせよ、SI会社にせよ、、、全てのプロジェクトが目論見通りには行くハズがない!

実際、、、進捗が100%になっても、150%になっても(!)、200%になっても(!!)、その工事が終わる気配がない "泥沼プロジェクト" は、必ず発生してしまうのだ。泥沼の発覚後に、取締役会がどれほど議論を尽くしても、現実の進捗は変わらない。

以下の業務プロセスは、非常にシンプルな「進捗報告プロセス」だ。

最大のポイントは「主観での工事進捗」を、複数人に報告させている点にある。この業務プロセス例では、最大4名のプロジェクト関係者が「報告作業」を行う仕組みだ。しかし、業務の流れとしては、経理部門(あるいは監査部門)が報告者を指名するところに始まる。したがって、「進捗 "調査" プロセス」と言ってもよい。

もし、プロジェクト関係者の多くが、「スケジュールは残り半分。でもマダ10%程度の進捗。」と思っているようならば、早い段階で会計上の修正を行う。それだけの話だ。

[進捗報告プロセス]

"上流工程で入力されたデータを、下流工程で書き換える。"

よくある話だが、なんとも気持ち悪い。特に、立替金申請など "現金の精算" を行うような業務フローで "上書き" するのは気色悪い。しかし、小さなミスがあった時も、すべて上流工程に差し戻していたのでは、仕事がはかどらない。。。特に "費目" の選択ミスなどは、日常的に発生する。

以下のワークフローは、前回記事に掲載されたワークフローに限りなく近いが、フロー途中に "項目複製" の[スクリプト工程]が設置されている。
  • A. 当人が申請したデータ
  • B. 経理が編集したデータ
これらを別々に管理している。

[立替金申請フロー-元データ記録]

"立替金の申請フロー" ほど[テーブル型データ]が似合うワークフローはない。
  • 各社それぞれに "入力フォーマット" があり、
  • 部署・ヒトそれぞれに "申請件数" が違う。
任意の列数を設計でき、しかも任意の行数入力を受け付けられる[テーブル型データ]は、業務プロセス設計者の強い味方だ。要するに "可変長のデータ" をシンプルに設計できる。

しかし一方で、業務データを集計する人は困っている。つまり "集計する時のフォーマットは違うんだ!" (事件は現場で起きているんだ風)などの悩みを持っていたりする。

以下のワークフローは、フロー終盤において自動的にデータ整形される。要するに "次の業務" で利用しやすいデータを別途作成しておく発想だ。こういう整形ケースでは、どうしても[スクリプト工程]を登場させることになってしまう。(プログラミング知識は身を助ける)

[立替金申請フロー-CSV生成]