日本にも「マイナンバー」がやってくる。

社会システム全体の効率化のためには、避けては通れない制度だ。
  • 行政の業務プロセスも、
  • 企業の業務プロセスも、
これから大きく変わっていくのだろう。。。何にせよ、今年(2015年)の10月にも「通知カード」が書留郵便で届く。赤ちゃんからお年寄りまで、「住民票」があるヒト全員に。。。 と言うことで、本ブログでは、企業に当座必要なワークフローについて考えてみたい。(「社会保障/税/災害対策」の3分野+αに展開される制度の全体像については他記事に譲る)

以下のワークフローは、非常にシンプルな「マイナンバーの申請フロー」だ。

ほぼ全ての企業は「所得税の納税」(源泉徴収)や「保険・年金の加入」の義務がある。つまり「マイナンバーを集めない」(個人番号を集めない)という選択肢はない。従業員や役員など、全員からモレなく集める必要があるのだ。早いウチに(=「通知カード」を紛失してしまうマデに?)申請してもらうのが、会社にとっても、社員にとっても良い。

[マイナンバー申請フロー(1)]

内部監査室や社外取締役が、最大4人の社員に対してアンケート調査を行う。
普通に考えれば、
  1. 上流に「調査をセットする工程」を作り、
  2. 下流には、4つに分流させた上で4つの「回答工程」を作る、
ことになる。もちろん、各自が記入する回答欄は別々に作り互いに見えないようにすることで、他の人の意見に惑わされることなく回答できるようにする。。。

この業務フローについては、すでに過去3週に渡ってアレコレ考察してきた。

しかしこれらのワークフロー、、、回答内容こそ見えないものの、「他の調査対象は誰か?」は分かってしまう。それぞれの社員が独立して回答すべきケースにおいて…、あるいは調査を行っていること自体を隠蔽(いんぺい)したいケースにおいては、使いづらい。

※ 調査を4回に分けて行えば良い、ともいう話もあるが、色々メンドウ。。。

以下は、アンケート回答工程を別の業務プロセスとして分離することで、「他の回答者」を隠蔽している。

[進捗報告プロセス(親プロセス)]

[進捗報告プロセス(子プロセス)]

「業務プロセス管理」などと説明されると、少し分かりにくい、、、
むしろ、「ルーティーン・プラットフォーム」と説明された方がシックリ来る、、、

という人は少なくない(一般従業員の視点)。説明方法はさておき、、、クラウド上の『マイタスク』(ToDo)を見れば、いま自分が為すべき事がわかるというのは本当に有り難い。「いつでも」や「どこからでも」のキーワードは、リモートワークの視点でも重要だろう。

しかし、その時、「締切時刻を過ぎてしまったタスク(ToDo)」が、大量に残っているとテンションが下がる。

以下は、そのような事態が発生しないようにデザインされたルーティーン(業務プロセス)だ。「調査に対して回答する」というタスク(ToDo)は、『回答締切時刻』になれば自動的に消滅する。

[進捗報告プロセス-締切設定]

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

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

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

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

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

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

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

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

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

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

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

[進捗報告プロセス]

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

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

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

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

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

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

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

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