基幹システムを刷新せず、周辺業務アプリの追加でDXを進める設計術

「基幹システムを刷新しましょう」と提案を受けたものの、見積金額と停止期間を見て即座に棚上げにした——そんな経験を持つ経営者・IT担当者は少なくないはずです。

基幹システムを刷新できない中小製造業の構造的ジレンマ

経済産業省が指摘する「2025年の崖」は、老朽化した基幹システム（企業の受発注・在庫・会計などコアとなる業務を支える中心的なシステム）を放置すると、2025年以降に年間最大12兆円の経済損失が生じる可能性があるという試算です。この言説は「刷新すべき」という方向に世論を誘導しがちですが、現場の実態はもっと複雑です。

つまり「刷新できない」のではなく、「刷新しない」という選択を合理的に下している中小企業が多いというのが実情です。そこで注目したいのが、基幹システム本体には手を付けず、その周辺に小さな業務アプリを追加していく設計術です。

Before：基幹システムからExcelに吐き出し、手作業で加工する現場

多くの中小製造業の現場では、次のような業務フローが日常的に行われています。

この一連の流れには、同じ数字を何度も転記する工程が複数存在します。転記のたびに入力ミスのリスクが発生し、担当者が休むと誰も処理の流れを再現できない、という属人化も起きがちです。基幹システム自体は正常に稼働しているのに、その「出口」と「入口」の間がアナログな手作業で埋められている状態です。

After：基幹システムの横に小さな業務アプリを追加する

ここで有効なのが、基幹システムを刷新する代わりに、見積作成・発注管理・日報入力といった単機能の業務アプリを横に設置し、API（システム同士がデータをやり取りするための接続規格）やCSV連携で自動的につなぐ設計です。

具体的には、次のような画面構成になります。

この設計により、基幹システムから一度エクスポートしてExcelで加工していた転記工程が1本減り、二重入力がなくなります。基幹システム本体のコードには一切触れないため、刷新に伴う停止リスクも発生しません。

優先順位の決め方：定型業務から着手する判断基準

すべての業務を一度にアプリ化しようとすると、要件が複雑化し、結局「刷新プロジェクト」と同じ轍を踏みます。優先順位を見極めることが設計の肝です。

逆に、特殊な値引き交渉や個別仕様の契約対応など、例外処理が多い業務を最初に手がけると、画面項目が肥大化し、現場が「結局Excelの方が早い」と感じてしまいます。小さく始めて成功体験を積むことが、次のアプリ追加への推進力になります。

1業務1画面の試験導入から全社展開への手順

リスクを抑えるための展開手順も重要です。

この積み上げ方式であれば、万が一うまくいかない業務アプリがあっても、基幹システム本体や他の業務への影響は限定的です。