情報システム部門が向かうべき方向とERP活用を考える

CIOLoung正会員・山本浩平

　一般企業の情報システム部門は、千差万別という言葉が当てはまると思えるほどいろいろな在り様があります。しかし経営や事業に貢献するIT/デジタルを担うという存在意義は共通であり、筆者自身の経験からもあるべき情報の姿は一定の枠に収まると考えます。ではそれはどんな姿でしょうか？ここで考察してみます。

　まず人材を含め外部のIT企業に技術的に依存している組織と、内製化している組織について。前者は利用部門と打ち合わせをするにも情報システム部門だけでは回答できませんから、外部の方が同席したり、同席しない場合には利用部門から聞いたことを外部の方に伝えて回答を得て、改めて利用部門に伝えるようなことが多かれ少なかれ起こっているでしょう。

　後者でも、内製化はしているものの日常のシステム運営で手一杯だった場合には、利用部門や経営者と会話しても話題に事欠くことが多いでしょう。しかしグローバルな視野で他社の動向をベンチマークしたり、最新の情報技術の動向に目を向けていたりする場合は別です。利用部門や経営者と同じ目線で会話し、また業務プロセスの変革や最新の情報技術の活用について積極的に提案ができるはずです。

　では、どのようにして3番目の情報システム部門を作るか、変えていくのかについて考えてみます。基幹システムにはスクラッチ開発したものや、ERPのようなパッケージを使って構築したものがあります。最初に構築したときの技術環境や更新・刷新時の経営状況などから、どちらもありえるのですが、スクラッチ開発したシステムは自ら手を加え続けないと進化しないことが課題でしょう。

　対して、ERPは多くの企業が必要とする機能であれば、時間の早い遅いはともかく、いつかは実装されて利用可能になります。例えば、カーボンフットプリント計算のスコープ3（注1）がもうすぐ利用できるようになります。加えて、基幹システムの機能はどこの企業でも同じようなもので、「我が社の基幹システムには現場のノウハウが盛り込まれ、ERPでは代替できない」などと思っているのは、その会社の方々だけなのがほとんどです。このような理由からERPを活用する方に分があります。

注1：カーボンフットプリントの算出におけるスコープ3は、製品の原材料の調達から製造、販売、消費、廃棄に至る事業者活動において排出される温室効果ガスの量（間接排出量）を指す。このスコープ3と、スコープ1（自社における温室効果ガスの直接排出量）とスコープ2（自社で利用した電力や熱などの間接排出量）を合わせた排出量をサプライチェーン排出量となる。

　次に、ERPを導入する場合の留意点を考えます。外部のIT企業に依存している場合、そのIT企業は技術に加えて自社の業務プロセスにも詳しいことが多いので、ERP導入のパートナーに選ぶパターンをよく耳にします。しかしこれは多くの場合、ERP導入を機に業務プロセスをシンプル化・標準化しようとすることと矛盾してしまいます。

　シンプル化・標準化より以前の業務プロセスに目が行きがちで、それが利用部門にも受け入れられやすいからです。パートナーであるIT企業にとっては、アドオンプログラムが多いほうが売り上げにつながる面もあります。そのため追加開発が増え、導入時のシステム障害も多発しがちです。結局のところ、自社と同じ業界でアドオンプログラムを少なく導入した実績があるパートナーを探すのがよいでしょう。

　パートナーを決め、業務プロセスを検討する段階ではどうでしょうか？多いのは情報システム部門と各利用部門からメンバーを選び、業務プロセスを検討するパターンです。検討することはよいのですが、利用部門に業務プロセスに盛り込む要件を聞くのはお薦めできません。利用部門の方々がERPに精通しているならともかく、そのようなケースはほとんどないからです。利用部門からの要件を忠実に盛り込もうとするあまり、ERPでは別の方策があるにもかかわらず、それを使わずにアドオンプログラムを量産することになります。

　お薦めは、同業他社や他の企業を知ったパートナーと情報システム部門で必要な業務プロセスを検討することです。それで問題があるかを利用部門がチェックする形にすれば、アドオンプログラムを少なくすることができます。生産システムやEDIなど他システムとのインタフェースや会社のロゴが入った帳票はERPの機能にはありませんから、この方法でも50～70個のアドオンプログラムは必要になるでしょう。

　しかしこれくらいなら品質を十分なレベルに上げることは可能ですので、導入時にそれほど多くのシステム障害が発生するとは思えません。ユーザー企業の情報システム部門がERPコンサルタントを目指すなら別のアプローチが必要だと思いますが、そうではない場合によく言われるFit to Standardを実現する現実的な方法ではないでしょうか。

　このようにしてERPを導入すれば、情報システム部門は過去のように年中、利用部門からのシステム改訂要望に対応する必要は激減します。例えば2023年10月から始まるインボイス制度のように、法令が変わったことへの対応があるくらいだと思われます。そうすると過去の基幹システムに比べて自らがプログラムの品質に責任を持つ範囲が数100分の1になり、業務負荷は飛躍的に改善されるでしょう。

　しかし内製化を目指すなら、これだけでは不十分です。例えばERPが稼働しているベースとなっているミドルウェアについて理解しておかないと、システム障害を社内で解決できないでしょう。アプリケーションの担当者がミドルウェアのすべてを理解しておく必要はありませんが、例えばアプリケーションに関連する定義体やそれを本番環境に反映する手順は理解する必要があります。

　また、ERPの導入が大規模な業務プロセスの変更を伴うものであっても、基幹システムの置き換えが主目的になってしまっては非常にもったいないです。経営者や各利用部門を管掌する役員と会社を運営して行く上での重要なKPI、それを各部門の日々の業務に落とし込んだ際のKPIについてプロジェクトの中で議論すべきです。そのうえで導入後に工数をかけずにそれらのKPIを見ることのできる仕組みと、それ以外のデータを分析したい場合にだれでも利用できるデータレイクを同時に作ることを強くお勧めします。

　このようにして自立して内製化ができる情報システム部門となり、広くグローバルに他社の動向や最新の技術動向に目を向けて、経営層に次に打つ手を提案できる情報システム部門になれば、経営者の情報システム部門を見る目も変化するのではないでしょうか。私自身もこのような情報システム部門を1つでも増やせるように尽力していきたいと思います。