超上流工程とは? 第2回 IT企画・構想策定が必要とされる背景

DXLTS

前回のコラムでは、IT企画・構想策定のフェーズ「超上流工程」について、実際にどんなことをするのか?を簡単に解説しました。

今回は「超上流工程」が必要とされる理由や背景について考えてみたいと思います。


執筆者

忰田 雄也(LTS ビジネスマネジメント本部・マーケティンググループ長)
SE・テクニカルライターを経て、LTS入社。ERP等システム導入や業務改革におけるユーザー企業向け社内広報・教育展開のコンサルティングに従事。2017年よりLTSコンサルティングサービスのマーケティングを担当。2021年より本サイト「CLOVER Light」の立ち上げ~運営・編集を務める。

セミナー情報

「動き出す」IT部門へ
~ユーザー部門との協創によるデジタル価値創出に向けて~

デジタル変革の流れが加速する中で、企業におけるIT部門の役割にも転換が求められています。 本セミナーでは、デジタル変革を企画し、ユーザー部門とともにデジタル価値を創出するためのアプローチを紹介いたします。

超上流の「IT企画・構想策定」を必要とするユーザー像

「ERP導入の前に、自社のIT課題検討を一緒にやってほしい」というご相談をお客様から頂く場合、お客様の基幹システムの状況はおおよそ2つのパターンに分類できます。

一つ目は、ERP等の初期の乗り換えブームに乗り遅れてしまいかなり古い仕組み(汎用機・オフコン等)が動いているケース。もう一方は、初期のブーム時に導入したERPをアップグレードして使い続けるか この機に乗り換えるかを検討しているケース、です。財務や販売管理のみERP化しているものの、周辺システムが年代物という複合ケースもあります。

両者に共通していることは2点あります。一つは「システム老朽化による業務との乖離や複数システムの平行運用による非効率な業務など単なるシステム刷新では課題解決が困難」な状況に陥っていること、もう一つは「過去に強引なIT化を進めた結果、課題が発生しているので今回はしっかり考えてシステムを導入したい」という強い願望を持っていることです。

強引なIT化」の中身は様々ですが、おおよそ以下の様な状況です。

  • 十数年前の現行業務に最適化したシステムを作ってそのまま運用しているため保守が大変
  • 現在稼働しているシステムの導入時はベンダーの言いなりで進めてしまった
  • ERP導入時にかなりのカスタマイズを入れてしまい運用が大変

このように一度失敗したと感じているお客様の「次は外部の知見を得てしっかり進めたいという思いから、IT企画構想の検討がスタートします。

システム導入前の「IT企画・構想策定」が必要になるまで

一昔前の基幹システム導入プロジェクトでもITの企画や構想策定をやっていたか?というと、あまりそういうフェーズや案件を聞くことはなかったかと思います(例外として一部の超大手企業では事業戦略策定の中でIT戦略も検討するケースがあったかもしれません)。

当時、多くの企業ではお抱えのITベンダーがユーザーに近い位置に立って、ある程度相談に乗りつつ(一定レベルで課題感を共有した状態で)システムの導入から運用までを担っている…というケースが多かったのではないでしょうか。

しかし、そういった状況の背景で発生した以下のような変化が企業のIT導入を変えたのではないかと考えています。

  • 基幹システムのパッケージ化
  • パッケージシステム導入を専門とするITベンダーの増加
  • 並行して進んだITベンダーのシステムエンジニアリング力の低下
  • 大企業向けERPパッケージシステムの登場
  • クラウドなど新しい技術によるIT構築や環境の自由化
  • SaaSなど手軽にシステムを利用する選択肢の増加

ITベンダーの営業活動がシステム検討フェーズだった時代

超上流のフェーズというプロジェクト開始前の検討フェーズが過去には存在しなかったかと言うと、そうではありません。「システム導入プロジェクト=ITベンダーにとってシステム開発・導入案件」と考えると、検討フェーズは契約するITベンダーを顧客が選定するフェーズです。契約前ということは、ITベンダーにとっては営業段階に該当します。

現在のようにパッケージ型基幹システムが主流になる前は、システムは個別設計・開発がほとんどでした(財務や給与計算など汎用業務向けシステムは当時からありました)。その場合、どんなシステムを導入するのがよいか?を顧客の相談に乗りながら一緒に検討するのは、ITベンダーにとって営業~提案の活動です。フルスクラッチが主流の時代だと20~30年以上前に遡りますが、当時はITベンダーの営業担当が顧客からヒアリングして理想のシステム像を作り、契約~開発・導入へ進んでいたそうです。ほとんどのケースで「アナログ業務のIT化」だったため、顧客の要求からシステム開発まで進めることは、今ほど複雑ではなかったと思います(その分ハードウェアやネットワークなどインフラの制約が強かったと思います)。

個別開発からパッケージシステムへ

その後「業務の基幹部分となる売上や財務の仕組みはどの業界・業種でもほぼ同じ」であるため、特定顧客向けに設計開発したシステムの主要機能の使い回しで稼ぐようになり、ITベンダーはゼロからの開発をせずに済むパッケージシステムの開発や販売に移行していきます。

顧客によって個別の要望がある部分はパッケージシステムをカスタマイズして機能追加する対応が主流でした。顧客ごとに担当エンジニアがついてシステムの運用を支援し、カスタマイズを繰り返せば多少業務やルールが変わっても対応できます。

しばらくはそんな運用でも変化に対応できました。

パッケージシステムの高機能・複雑化

パッケージシステムの導入・運用が主流になってから、また時間が経過します。

すると、個社ごとにカスタマイズ対応した差異が、ITベンダーのシステム運用サポート業務にとって重荷になっていきます。これは顧客も同様で、カスタマイズ部分の改修コストが毎年発生していくことになりました。

パッケージシステムは「カスタマイズなしの標準機能で導入するほうがよい」ということが分かってきます。要望の多かったカスタマイズ機能は標準機能に内包されシステムのパラメーター操作で個別機能のオンオフや拡張機能を制御できるようにしました。自社で複数のパッケージシステムを販売するようになり、パッケージシステム間でデータを連携できる機能も標準で内包するようになります。

その結果、標準機能が複雑化しITベンダーのエンジニアの役割はこのパラメーターの調整や旧システムからのデータ移行やテストが主となっていきます。

ITベンダーにとっては「標準機能で複雑な対応をせずに導入できるユーザー」がよい顧客となり、顧客は「標準機能で要求を満たせるシステム」を選んで導入する時代になりました(実際はこの自社に合うシステムを選定することが難しいのですが、それはまた次回へ)。

超大手企業は大規模ERPへ、中小企業はサブスク型のSaaSへ

一方で、一部の超大手企業向けのソリューションとして主に海外製ERPの導入ブームが起きます。

ERP導入=業務の標準化という構図が出来上がったことで導入前の業務整理やERPに合わせた運用変更が必要になり、導入効果と難易度が上がりました。超大手企業は国内外の大手コンサルティング企業の支援を受けるようになります。

また別の動きとして、新興企業はクラウドやオープンソースなど新しい技術でITを巧みに利用するようになり、中小企業はSaaSの組み合わせでアナログ業務のIT化が容易になりました。

残されたのは、超大手・中小企業の間に位置する、すでに初期のIT導入を経験している中堅~大手企業と、主流となったパッケージ導入以外ではビジネスが難しくなったITベンダーです。

シンプルな機能しか持たないSaaSのシステムでは要求を満たせず、かといって大手ERP導入を大手コンサルティング企業に全面的に依頼する予算もコンサル活用経験も不足している、なんとかしようとIT導入を進めると前述のように「強引なIT化」になってしまう。

このような八方塞がりが、取り残された中堅~大手企業の状況ではないでしょうか。これがまさに、前述した「IT企画・構想策定」を必要とするユーザー像の実態です。

こういった状況を背景として考えると、超上流フェーズを実施する機運が比較的最近になって盛り上がってきたことが理解しやすいのではないかと思います。


次回は、超上流工程を進めるのに必要なスキルや知識について考えてみたいと思います。