中堅企業のIT課題と解決のためのアプローチ　中堅企業のDX～課題の本質と解決の方法（後編）

ライター

中堅企業のIT現場で発生していること

ここまで、ITで課題を抱える中堅企業の状況と、その背景について解説してきました。

では、難しい中堅企業の課題をどのように解決すればよいか、考えてみたいと思います。

まずは、実際に中堅企業のIT課題解決のための支援をしている中で経験した事象を紹介し、それらを踏まえて考えられるアプローチをいくつか紹介します。

保守期間はすでに終了　システム刷新のデッドラインがなくなる

大手企業であれば「システムやハードウェアの保守期間終了までになんとか次期システムの稼働を目指す」となるところが、プロジェクトの立ち上げ時点ですでに保守期間が終わっている、といったケースがありました。

明確な期限をすでにオーバーしており、では次期システムを、と考えると当然大規模な投資が発生します。予算を通すには、基幹システムの入れ替えに対するビジネスのメリットを説明しなくてはいけない、となります。

費用対効果は？システム入れるといくら稼げるのか？今のシステムは動いているのにどうして必要なのか？稼げる現場の人間をなぜプロジェクトに投入しないといけないのか？

話は堂々巡りになり、時間だけが過ぎていきます。

プロジェクトを進められず数年単位で遅延する

社内で稼働中の現行システムは全てベンダーが管理しており、必要なシステム改修や運用もベンダーに任せている、その状況の中で別の業務のシステム化の話が立ち上がりました。しかし、IT担当者は普段から業務要件をまとめるところも含めて全てベンダーに頼っていたため、新たにシステム化する業務の要件のとりまとめができません。その後、その業務のシステム化プロジェクトは数年間完全に停止しました。プロジェクト経験の圧倒的な不足がもととなり、プロジェクトを組成し先に進めることができませんでした。

苦労してRFPを作成したがITベンダーが提案を辞退する

次期基幹システム検討のためのIT企画・構想からしっかり着手し、外部のコンサルタントも入れて次期システムの選定に入ります。現状は他の中堅企業と同様に課題が多いものの、要件はRFPにしっかりまとめることができました。

しかし、提案を依頼したベンダーの反応がよくないのです。最初は話を聞くものの、徐々に反応が鈍くなり、1社また1社と提案辞退の連絡を入れてきます。

大手顧客向けに数年前からERP刷新に向けたプロジェクトを進めているため、ベンダー側に新たな顧客に対応できる余力がない、という話でした。実際、ここ数年の基幹システム刷新の潮流は大手企業が先行して動いています。しかし同時に、ベンダーからすれば、売上規模が大きくないのに複雑な要件の顧客は優先順位が低くなるということです。

システム開発は終えたが本番稼働できない

トップダウンで決まったシステム刷新プロジェクトで、すでに導入するパッケージシステムも決定しており、あとは業務要件に合わせて構築・テストを進めていきます。ユーザーテストの段階で実際のシステム利用者に参加してもらいましたが、システムが変わることを知らされておらず、さらに業務上必要な機能が複数漏れておりテストどころではなくなってしまいます。プロジェクト側はユーザーの意見を収集しますが、すでに方針変更できるフェーズではなく、新システムの稼働後もユーザーは現行システムを利用する状態となり、予定より長期間にわたって現行システムとの平行稼働・稼働しながらの機能実装を続けることになりました。

その他の失敗しがちな対応

費用はかかるものの、コンサルティング企業を使って課題解決をお願いする、という対応は検討余地があります。外部のコンサルタントを使い慣れているのであれば、有効なアプローチですが、今回紹介しているようなプロジェクト経験が極端に少ない中堅企業の場合は、コンサルタントは指示を仰ぐ対象となってしまい、本来自社がやりたかった・到達したかった着地点から外れてしまうリスクを抱えることになります。

決めうちで何の検討もせずにパッケージシステムを選定し導入を進めてしまう、というのも実際かなり多く見られるケースですが、これもリスクは大きいです。実際の業務とパッケージの機能の区切りが合わない、必要なデータが移行できない、企業規模とシステムの許容範囲が合わない、など致命的な問題が後から発覚すると取り返しがつきません。

課題のある業務や部門で新たに人材を採用する、という対応をする企業もありますが、あまり上手くいったケースは見られません。既存業務やその成り立ちを知らない人間があとから入っても課題の特定が難しいですし、既存業務を回している数名の熟練者が対応しないと解決できない場面では人を増やしても対応しようがありません。

課題を認識し適切に対処するためのアプローチ

さて、ここからは解決のためのアプローチを考えてみます。

あるべき論を先に提示すると、自社のあるべき姿を描き、現状のIT課題の特定と検証、優先順位付け、IT環境の現状把握、等を外部の業務分析の専門家を入れて進めて、最初に着手すべき対策（ファーストプロジェクト）のスコープを決めて着手していきます。

この方法は「IT企画・構想フェーズ（超上流フェーズ）とは？」として別の記事で紹介する予定です。

では、これまで課題を抱え続けた中堅企業では、どのようなアプローチが有効かを考えてみたいと思います。

特定のパッケージシステムをベースに業務の標準化を検討する

このような状況に対して、正攻法で現状分析・課題整理を始めると、かなりの時間と費用がかかります。中堅企業の社内プロジェクトとして進めようとしても業務分析の専門的なスキルが不足し、また仮に課題を収集し羅列しても次の取り組みにつながりません。

いっそのこと、課題整理や最適なシステムの選定など通常必要とされるプロセスをあきらめ、特定のパッケージシステムの標準機能をベースに導入検討を進めるという方法が、一つ目のアプローチです。

この前提で進めていくと、標準的なパッケージシステムの機能的なカバー範囲や、導入した場合の工程、どの程度業務を変えれば標準機能を使えるのか、後工程で必要となる作業、などを想像できるようになり、仮に「このパッケージでは難しい」となっても、他のシステム検討が素早く進められるようになります。

このアプローチを採用する場合は、事前に自社に合いそうなパッケージシステムの選定を内部で（システム担当者が）行っておき、最初に検討する対象を選べることが重要です。

システム刷新をしながらシステムとメンバーを育てる

前述のアプローチに近いですが、こちらは機能の不足を認識した上で特定のパッケージシステム等への刷新を進めます。そして、不足機能部分は稼働後のシステム運用改善のフェーズで追加開発・カスタマイズし、導入プロジェクトを一過性で終わらせない、という方法です。アジャイル的な基幹システム最適化のアプローチをすることで、常にシステムに変化があり、IT担当者はプロジェクト推進の経験獲得のできる環境を、利用ユーザーには常に変化への対応とシステム改善の要望を言える環境を作り出せます。

パッケージ標準に合わない一部の業務を対象外としてシステムを入れ替える

DXに悩む中堅企業の特徴として、特定の領域・製品・ポジション等に強みがあり安定しているという点を挙げました。このような特徴は「簡単に真似されにくい強み」であるのと同時に「標準化が難しい業務プロセス」という側面も抱えています。特徴的なビジネスモデルやプロセスは、パッケージシステムでの対応を難しくし、中堅企業がシステムの刷新を躊躇する要因にもなります。「ウチのビジネスに合うシステムがない」で思考が停止してしまうと、その先のハードルは実行面でも予算面でも非常に高くなってしまいます。

いっそ、標準化が難しいプロセスは最初のシステム化スコープから外し、それ以外の標準機能で対応可能な部分から新しいシステムに入れ換えてしまう、というアプローチは検討できないでしょうか。システム化や自動化が大変な部分は後に残して、可能な個所から新しい環境に変えていく。非効率な作業が多く現行業務にも合っていなかった従来のシステム環境を脱し、一部に手作業当の部分も残りますが、全体としてのシステム運用の工数は削減される可能性があります。空いた時間で、システム全体のアーキテクチャを検討しその結果を基に標準化困難部分をIT化する道筋を描きます。従来は、場当たり的に個別システムを導入したために「システムアーキテクチャ全体のあるべき姿」がない状態になっていました。そこで、まずは標準化できるところからベースを作ってしまうことで、ベースを前提にしたアーキテクチャ設計に着手できます。

小さな取り組みを自社内で進める

中堅企業の支援をしているコンサルタントが口をそろえて言うのは、最も大きな課題は個別最適化された現行システムの複雑さや非効率なシステム・業務遂行上のアナログ処理の多さ・業務の属人化…などの、外から見ても想像できる問題ではなく、システム導入など業務を変えるためのプロジェクト経験の不足、またそのような変革や改善の活動を主体的に実施することで得られる課題解決に必要なコスト・時間等の共通認識の欠如、です。

経営層から現場までを含めた組織や人・文化の問題が、仮に外部から支援をしてプロジェクトを進めるにあたっても壁となるケースが多いのです。

変革を目指したプロジェクト活動の試行やトレーニングが不足している状態なので、まずは比較的容易に導入や改善活動ができるRPAの導入や、アナログ処理をしていた個別業務をSaaSなどでオンライン・ワークフローシステム化する、などの活動を進めてみることをお勧めします。

社内の改善プロジェクト立ち上げや実行、経営への説明をする経験を積み、巻き込む人や部門を増やしていくことで、時間はかかりますがプロジェクト推進能力や変化への対応力が身についていきます。

中堅企業がDXを進める際の注意点

課題を抱える中堅企業が、システムの刷新を念頭に置いた新たな取り組みを進めるにあたって、有効と考えられるアプローチをいくつか紹介しました。最後に、中堅企業がDXを進める際の注意点を書いておきたいと思います。

短期的な効果を期待しない

「このツールを導入すればDXできる」「短期間で効果が出る」といった非現実的な効果の期待や耳障りのいいソリューションは根本的な課題解決につながらないため、あまりお勧めはしません。とはいえ、活動のきっかけや分かりやすいファーストプロジェクトに何らかのツール導入などをすることは現実的にも発生しうるため、その時に「本来解決したい課題は何だったのか」「まずクリアすべき小さな目標をどうセットするか」などをしっかり決めて関係者に共有しながら進めるのがよいと思います。

すべてを通して言えることは、短期的な効果を期待すべきではないということです。変化に対して対応できる組織能力を身に付ける、事業内容に合わせたIT環境に変化させる、そういったプロジェクト活動を数年～数十年単位で進めていなかったわけですので、あらためて活動を始めてもすぐに効果は期待できません。また、基幹システムのような企業としての必要投資に対する短期的・売上的な期待をするのは間違っています。変革プロジェクトを進めることで最も短期的で分かりやすい変化があるのは、推進するチ―ムや関係者の変化なので、人や組織の意識の変化やプロジェクト推進能力の向上を期待値として持っておくのがよいと思います。

システムの全体像に関わる活動を進める

アプローチの一つとして「小さな取り組みを自社内で進める」という提案をしました。この時、会社全体の最適化につなげ難い個別業務・特定部門内だけの改善や自動化を繰り返していると、その先の変化につながりません。企業のシステムアーキテクチャ全体に関わる機能に対するIT化を少しずつ進めて、徐々にアーキテクチャ全体像に近づけていくのが理想的です。このような活動をする際は、特定部門に閉じない全社的な業務変革チームや活動を集約するCoEのような中央機能があると、会社全体の業務ルールの整備や成功体験の共有なども進むためより効果的です。

外部人材を活用する場合の注意点

社外のコンサルタントや、システム開発や導入経験のあるプロ人材に相談する、IT課題解決の活動に参加してもらう、という方法は有効です。ただし、外部の人材や支援企業が得意とする課題やフェーズはそれぞれ大きく異なりますので、どんな状況にどんな専門家に参加してもらうか？を間違えないようにしたいです。

例えば、業務の効率化のためにシステム化をしたい、事業内容が増えたため現行システムから新たなシステムを開発したい、という要件がある際に、それならシステムの開発経験が豊富な専門家を連れて来よう、という人選をしてしまうケースがあります。

やるべきことの順序は、まず効率化や新たな業務のIT化に向けた業務の分析です。開発が得意な人の出番は、分析した結果どのような方法でのIT化が実現できるか？IT化する部分としない部分の線引きをどうするのか？最適なシステムの要件は何か？を検討した先のフェーズです。

実際に、このような専門家の選択ミスは多く発生しています。システムの刷新をするはずのプロジェクトなのに、現行システムの帳票をそのまま新システムに組み込む前提の指示出しだけをする自称コンサルタントが取り仕切っていたためにシステムベンダーが困惑し、プロジェクトがなかなか進まない、といった事態を、過去実際に経験しています。

このような人選ミスを起こさないために手っ取り早い方法は、コンサルティング企業で現行業務分析・業務フロー標準化など上流フェーズを経験している経験者（ここ10年くらいの間の上流フェーズ経験者が望ましい）に相談することです。経験値が古いと「ゼロからのシステム化」しか経験していないシニアな人材も多いため、人選にはいずれにしても注意をしたほうがよいと思います。人選そのもののアドバイスを含めてフリーのコンサルティング企業出身者の紹介をしてくれるサービスも最近は多くありますので、まずは信頼できる相談先を探して、慎重に人選するところから始めてみてはいかがでしょうか。

まとめ

今回は、ここ数年のコンサルティング事例を振り返り、中堅（準大手）企業が抱えるITの検討やプロジェクトを進める上での課題、それに対して考えられる解決策を紹介しました。

提示した事例や考察は、あくまで弊社がここ数年で見知った範囲のため、もっと他のご意見や全く別の課題もあると思います。この記事を書くための情報収集からスタートし最も強く感じたことは、中堅企業の課題感や中堅企業を切り取った情報・調査データ等が非常に少ない、ということです。有名な大手企業と、数多くある中小企業の間に存在するためスポットライトが当たりにくく、かつ業態や事業内容も多岐にわたり共通化が難しいため中堅企業の実態は見えにくいですが、日本の産業・雇用や競争力を支えるために無くてはならない存在です。今後も、中堅どころで頑張る企業や人を応援できるように情報を発信したいと思います。

---