ここまで私は、

・現場ヒアリング主義
・調整コスト
・要件定義崩壊
・「動くが誰も触（さわ）れないシステム」

についてお話ししてきました。

では、どうすれば良いのでしょうか。

私は、その答えの一つが、

「業務モデリング」だと思っています。

しかし、この言葉を出すと、多くの人が、

「業務フロー図を書くことですか？」と考えます。

もちろん、それも間違いではありません。

しかし、本来の業務モデリングは、もっと深いものです。

私は、業務モデリングとは、「仕事の設計図を作ること」だと考えています。

例えば、建築では、設計図無しに家を建てることはありません。

・どこに柱を置くのか
・荷重をどう支えるのか
・電気配線をどう通すのか
・将来の増改築へどう備えるのか

を考えながら、構造を定義していきます。

もし設計図無しに、その場の思い付きで増改築を繰り返せば、建物は徐々に不安定になっていきます。

実は、多くの日本企業の業務システムで起きていることは、これに非常によく似ています。

つまり、

「構造を定義しないまま増築を繰り返している」のです。

そして、その背景には、「業務を設計する」

という発想自体が、日本企業にあまり根付いていないという問題があります。

例えば、多くの企業では、

「今、現場がどう動いているか」は把握しています。

しかし、「本来、どのような構造で業務を成立させるべきか」は定義されていない。

そのため、

・担当者依存
・部門毎運用
・例外処理
・ローカルルール

が積み上がり続けます。

つまり、「運用」が業務構造を代替してしまっているのです。

しかし、本来必要なのは、

「頑張って回すこと」ではなく、「安定して回る構造を設計すること」です。

ここで重要になるのが、業務モデリングです。

では、業務モデリングとは何をするのでしょうか。

私は、本来の業務モデリングとは、

・誰が
・何を
・どの情報を使い
・どのルールで判断し
・どの状態へ遷移させ
・どこへ引き継ぐのか

を構造として定義することだと考えています。

つまり、「仕事の流れ」ではなく、「仕事が成立する構造」を定義するのです。

ここで非常に重要なのが、「標準業務」という考え方です。

多くの企業では、「現場毎にやり方が違う」ことが、半ば当然になっています。

しかし、それでは、

・データ定義
・責任分界
・判断ルール
・システム構造

を統一出来ません。

すると、調整が増えます。

つまり、調整コストの多くは、「業務構造が標準化されていないこと」から生まれているのです。

ここで誤解して欲しくないのは、「全員同じ作業をしろ」と言いたい訳ではありません。

本当に重要なのは、「何を共通構造として持つか」です。

例えば、

・顧客とは何か
・受注とは何か
・承認とは何か
・完了とは何か

を統一しなければ、データもシステムも整合しません。

つまり、業務モデリングとは、「企業活動の意味を定義すること」でもあるのです。

そして、この構造が定義されると、初めて、

・システム設計
・データ設計
・権限設計
・ワークフロー設計
・KPI設計

を整合性を持って行えるようになります。

私は、多くの企業で、「システム開発」が目的化してしまっていると思っています。

しかし、本来必要なのは、「どのような業務構造で会社を運営するのか」を定義することです。

システムは、その結果に過ぎません。

つまり、「業務モデリング」とは、単なるIT技法ではありません。

企業活動そのものを設計することなのです。

そして私は、日本企業に今、本当に必要なのは、

「効率化」より前に、「構造を定義する文化」だと考えています。

なぜなら、構造が定義されていない組織では、DXを進めるほど、「調整」が増殖してしまうからです。

逆に言えば、業務モデリングが出来ている企業では、

・変更容易性
・データ整合性
・保守性
・拡張性

が高まります。

つまり、「変化に耐えられる企業」へ近付いていくのです。

私は、これからの時代に必要なのは、「システムを導入する力」ではなく、

「業務構造を設計する力」なのだと核心しています。

合同会社タッチコア　小西一有

[先週からの関連Blog]

第1回 「現場に聞けば業務は分かる」という危険な誤解 

第2回 「断捨離」が局所改善になる会社

第3回 日本企業は「調整」を仕事にしてしまった 

第4回 なぜ要件定義でシステムが壊れるのか

第5回 「動くが誰も触（さわ）れないシステム」が完成する