業務をシステム化する理由

これまで多くのお客様の「業務をシステム化する」プロジェクトへ参画しました。うまくいっているプロジェクトもあれば失敗するプロジェクトもありました。おそらく、失敗しているプロジェクトの方が多いように思います。

ここで少し考えたいのですが、失敗したプロジェクトとはどういうプロジェクトのことでしょうか?

そもそも、業務をシステム化する目的とは何でしょうか?コストを削減すること?売り上げを伸ばすこと?お客様の利便性を高めること?…さまざまいわれていますが、結局のところは会社にとって利益を大きくするためです。

コストを削減することを目的にする場合、売り上げが一定だとすると下がったコストの分だけ利益が増大します。売り上げを伸ばす場合はコストが一定だとすると、売り上げの伸びた分だけ利益が増大します。

基本的には業務システムを導入するということは、利益を大きくする手段でしかないのです。ところが、当初は利益を大きくするための手段として経営上導入を検討されるシステムも、要件定義(実現したいシステムの青写真を検討する段階)から設計(システムの設計)をおこなうあたりでどんどんぶれてきます。あれも必要、これも必要…あっちを立てればこっちがたたないなどなど、複雑に絡み合った業務をシステムになかなか落とし込むことができないのです。

この段階でシステムに落とし込もうとした場合、たいていは設計が肥大化します。どんどん大きくなっていきます。大きくなって収拾がつかなくなるか、「業務で対応」「運用でフォロー」という言葉が飛び交います。

本来であれば、業務で対応することや運用でフォローすることを減らすためにシステム化することを前提にしています。ところが、システムを構築するにつれてシステムに合わせて業務が発生するのです。

もちろん、すべてをシステム化することは費用対効果の点から考えて問題があります。けれども、当初もくろんだ利益を上げるためのシステム化は業務全体を中途半端にシステム化し、その結果システム化に伴う新たな業務・運用が発生するという状況になってしまいます。

こうなってくるとシステム化は失敗する方向へ進みます。完成したシステムはこれまでできたことができなかったり、新たにシステム化してほしい内容が発生するからです。

では、どうすればシステム化を成功させることができるか?これは、とても難しいことですが、一つの方法として、システム化する領域を小さくするという方法があります。システムの設計を行う際に当初想定していた内容から乖離が出てきた段階で、システム化の対象を見直すのです。

販売管理で考えたときに、受発注をシステム化する場合でも、受注と発注のデータ受け渡しだけをあらかじめ想定(決定ではない)しておきシステム化の対象は受発注だけれども、システム化を行うのは受注だけにするなど柔軟に対応することを検討します。

こうすることで、密接に絡んだ業務でも今までの仕組みを残す部分とシステム化する部分に分けて調整しながら進めることができます。すべてをドラスティックに変更することは華々しいですが、リスクも大きいのです。

私はこれからも多くのシステムを開発していくと思いますが、小さく確実に進めるスタイルが失敗しない方法だと考えています。たとえ地味でも失敗しないことを着実に進めることで成功に結びつくと考えているからです。

長くなりましたが、業務をシステム化する理由はお客様の利益を最大化することです。そのために私たちシステム屋は、小さく確実なシステム化を行うことがベストなプラクティスだと思います。