ワークフローサンプル: 「トップの即決事項」と「稟議ワークフローの結果」を一元管理

「パソコンを買う」、「人を雇う」。。。
実際のところ『トップダウン』で即決される事もあれば、『ボトムアップ』に決裁される事もある。どちらが良いと言うものではない。しかし『トップダウン決定』も『ボトムアップ決裁』も、どちらも組織としての決定情報として一元記録したいものだ。

以下の業務プロセス定義は、（起案者はさておき）、最終的な決定者、決定時刻、決定内容が、同じフォーマットで記録できる「意思決定プロセス」の事例だ。組織としての決定は、ここに流れたプロセスを参照すれば良い。ここでは「トップダウンで即決された事」を、さも「ボトムアップで決定された」かのように記録するような事はしない。

このクラウド時代にあって「組織としての決定データ」を電子化すべきは当然だが、この事例の様に「組織としての決定フロー」を複数想定しておくことも、組織機動性担保の観点で重要だと言える。

＃稟議書を『紙』で保存していたのでは、「過去の決定」を検索する事すらままならない。

ちなみに、、、
日本には、ボトムアップ型の意思決定記録フォーマットとして、「稟議(RINGI)」と言う仕組みがある。

社内規程で定められた起案責任者によって立案され、多人数の同意を得てから、決裁者が決裁する。例えば『大規模な広告』を出稿する際には、起案責任者は大規模広告が必要な理由や広告出稿の概要を書いた文書を作成し、それぞれの広告費の見積書を沿えて提出する。実際、その稟議書が決裁者に辿り着くまでに相当な時間と手間がかかってしまう。

しかし違う観点から見れば、決裁する時点で

本当に『大規模な広告』にする必要があるのか？
もっと『大規模な広告』にする必要があるのではないか？
その広告に伴う『リスク』に対応できているか？
その広告によって得られる『効果』は正しく予想されているか？

と言った議論は十分に尽くされているとも言える。すなわち、決裁後の広告出稿作業は、驚くほど迅速かつ円滑に進められる。多くの場合、トップ自らが広告出稿作業について指示する必要はない。
日本企業の中で根強く支持され、今後もしぶとく(?)生き残るであろう仕組みだ。

[調達決裁ワークフロー]

このワークフローでは、通常は「１⇒２⇒３」の『起案決裁ステップ』（いわゆる稟議工程）を踏んでから、「５⇒６」の『実施工程』が実行される。しかし特徴的なのは、その『起案決裁ステップ』を踏まずに、「権限者決定」だけで、実施段階に進むルートが用意されている点だ。

なお、ステップ５の「実施記録」をモニタリングすれば、組織としての決定が、どう進捗し、どういった顛末を迎えたか？、が把握できる。「あの計画、どうなったの？」などと言う日常の疑問は、いつでも解決可能だ。

ちなみに、この意思決定フローは、全体を見渡せる非常に分かりやすいダイアグラムだ。しかし、良く見ると「計画書の書き直し」が想定されていない。つまり上司が、工程２や３で否決すれば、その計画は完全にお蔵入りしてしまう。この業務プロセス定義は、否決した上司が、計画立案したメンバに対して口頭で指導したり、「社内SNS」機能でやり直しを通知したりする事を想定している。

PS
やや話がそれるが、別途『上下の組織構造』は単純化すべきだ。
仮に1000人を超える大きな組織でも、この事例にあるように「フラットな３階層」程度にすることも不可能ではない。言うまでもないが『上下の組織構造』を単純化するには、『業務分担』を分かりやすく美しく分ける必要がある。

[調達決裁ワークフロー: 「2. 決裁／承認」画面]