2015年に出版した
『業務効率UP+収益力UP 中小企業のシステム改革』幻冬舎 (2015/9/18) より
書籍内のコンテンツをタイトルごとに公開いたします。
コンテンツの最後に、コンサルタントのコメントを追加しておりますので、合わせてご覧ください。
P.144～
第4章
「To Beモデル」のシステム構築＆改修で、業務効率・収益力を向上させるる
To Beモデル（あるべき姿）とは何か
私どもの会社では、ITシステムの導入にあたって、現状の業務を精査したうえで、あるべき理想の業務プロセス（To Beモデル）を構築することを売りにしています。
このTo Beモデルの重要性について説明しましょう。
一般的にSIerは、新システムの導入にあたっては、海外製の高額なERPシステムのセットを売りつけることを目的にしています。その売り文句は以下のとおりです。
「当社のERPにはグローバルスタンダードのノウハウが盛り込まれています。ERPを導入して、業務プロセスをERPに合わせて改善していけば、グローバルな競争力を持つように業務の改善ができます」
この言い分には一理あります。
会社の業務には一定のパターンがあるのに、それぞれの会社がそれぞれのやり方に固執しているのは、たしかに非効率だからです。そこで、欧米の一流企業の「最も効率の良い業務の進め方」をもとにして作られたのが、ERPというシステムです。ですから、ERPシステムが規定するとおりに仕事の進め方を変更すると、業務効率が向上することは理論的には間違いありません。
ところが、現実はそううまくはいかないものです。
たいていの日本の会社では、ERPシステムを導入しても、あまり業務効率は向上しません。その理由は、ERPシステム導入の際に、なぜか、自分たちの仕事のやり方に合わせて、システムのほうを大幅にカスタマイズしてしまうからです。
業務効率の向上を目論んでERPシステムの導入を決めるのは経営陣ですが、ERPシステムのカスタマイズを要求するのは現場の人間です。
現場の人が「うちの会社にはこの項目が必要だ」とか「現在、こういう処理をしているから、こういう機能がないとだめ」とか、いろいろと要求を出すので、システムの要件がどんどん現状の業務水準に引きずられて、結局は高額なカスタマイズ費用をかけて、業務プロセス自体は何も変わっていないというケースが散見されます。
ERPで業務を変えるつもりが、業務のほうにERPを変えられてしまって、高価なシステムが何の意味もないものになってしまうのです。
では、システム導入にあたって、いっさいのカスタマイズを許さず、システムどおりに現場の人を動かすようにすればよいのかといえば、それもちょっと違うと思います。
なぜなら、ERPの持っている解が、必ずしも皆さんの会社にとって正しくて最適なものとは限らないからです。
システムの入力欄が足りないとか、手順が実際の業務と異なるとか、ビジネスは相手があってのものなので、自分のところだけ勝手にやり方を変えるわけにはいかないところもあります。また、海外製のERPパッケージは、日本の商習慣に合わないために使いづらく、かえって手間が増えてしまうことも多いものです。
どんなシステムも人間の作ったものである以上、完璧ではありません。システムを盲信して、現場の仕組みを破壊してしまうと、取り返しのつかないことになる恐れもあります。その意味では、ある程度のカスタマイズは、やむを得ないと言えるかもしれません。
とはいえ、現場のやり方がまったく変わらないのであれば、システム導入の意味もありません。
この難問の答えは、第三の道にあります。システムの押しつけてくる業務も、現場で実際に行われている業務も、本当に進むべき道ではありません。
本気で業務改革をしたいのであれば、まずはITシステムありきではなく、どのようなやり方が理想的なのか、アイデアを出すところから始めなければなりません。
私どもの会社では、この理想の業務プロセスをTo Beモデルと呼んでいます。
To Beモデルは現状の業務よりも、あるいはパッケージ・システムが持つ基本性能よりも、さらに高みにある理想の業務プロセスです。
To Beモデル（あるべき姿）を明確にして、現場の担当者にTo Beを十分に理解してもらったうえで、パッケージ・システムとの間でのギャップの調整（フィット＆ギャップ）を行うのが、本来あるべきシステム導入だと私たちは考えています。
ここで重要なのは、To Beモデルをもまた、絶対視しないことです。現実には、現場の人間の能力や、予算の制限などもあって、To Beモデルの姿にまでカスタマイズを施すことはなかなか難しいものです。
そこで、現場の人間に受け入れられつつも、効率的な業務が遂行できる業務プロセスをCan Beモデル（現実的な解）と呼んで区別します。システム導入にあたっては、最終的にCan Beモデルへと向かって、皆の意識を高めていくのが理想的です。
ここからは、私どもの会社で行ったコンサルティングをもとに一部脚色した事例で、具体的なシステム改革のプロセスを紹介していきます。
ITコンサルタントのコメント（2022年9月6日）
システム導入前に、システム導入の目的を明確化することは従来と変わりません。
従来は、ERP導入の失敗例のような目的に反するシステムのカスタマイズを行わないように、あるいはシステム導入自体が目的とならないように、システム導入前に理想の業務モデル(To Beモデル)を策定することが重要でした。
2022年現在では、DXを失敗させないために、ありたい姿(Will Beモデル)をシステム導入の前に描くことが重要です。To Beモデルと異なる点は、自社がどうありたいかを定義するため、To Beモデルのような世の中のお手本が存在しないことです。
ただし、To Beモデルが廃れてWill Beモデルを必ず採択する、というわけではありません。
DXではWill Beモデルが適していますが、To Beモデルを利用することもあります。
例えば、事業の成長と共にシステムのカスタマイズを重ねてきたことで、システムの維持やカスタマイズに掛かるコストが増大しているようなケースです。このような状況を問題と捉え改善する場合は、To Beモデルで理想の業務プロセスを定義し、最適なシステム構成を考えます。
To BeモデルとWill Beモデルのどちらにも共通していることは、システム導入前に、システム導入目的を明確にすることです。
目的の実現に向けてシステム導入を推進していただくことを願います。
