オンプレ基幹を残したままクラウドに業務を積む――中小製造業のための基幹連携という選択
受注情報は基幹システムに、見積書はExcelに、検査記録は紙の帳票に――バラバラに存在するデータを月末にまとめて突き合わせる作業に、毎回時間を取られていないでしょうか。
「そろそろ基幹システムを新しくしないと」と感じつつも、改修費用や業務停止のリスクを考えると二の足を踏む製造業の経営者・IT担当者は少なくありません。実はいま現場で選ばれているのは、基幹そのものを刷新するのではなく、基幹システムはそのままに、周辺業務をクラウド側に積み上げる「基幹連携」という構成です。
「基幹刷新」ではなく「基幹連携」が選ばれる背景
基幹システムのクラウド化を巡る解説記事では、機密性やカスタマイズ性が求められる基幹系はオンプレミスやプライベートクラウドに残し、可用性やスケーラビリティが必要な周辺業務だけをパブリッククラウド側に持つ「ハイブリッド構成」が主流になりつつあると紹介されています。AS/400などレガシー基幹のサポート終了に伴うモダナイズの文脈でも、全面刷新ではなく「分解・段階的移行」でデータ連携レイヤーを整備し、新旧システムの共存期間を作る手法が近年注目されています。
受注・在庫・生産管理が絡み合った基幹システムを一括で作り直すと、テスト工数も業務停止期間も膨らみます。長年運用してきた仕組みほど、影響範囲の見極めが難しくなります。
実際に不満の声が上がるのは「見積書を作るのに毎回同じ転記をしている」「検査記録が紙のまま」といった周辺業務です。基幹本体は問題なく動いていることも多く、そこを触る必要は必ずしもありません。
オンプレ基幹側は触らない：変更しない範囲を先に線引きする設計術
基幹連携を成功させる最初のステップは、「何を変えないか」を先に決めることです。特に受注データや在庫マスタといった基幹の中核部分は、原則として現行のまま残します。
マスタの持ち主を曖昧にすると、二重管理や不整合の温床になります。基幹側を唯一の正としてクラウド側は参照・更新依頼のみ行う設計にします。
CSV出力機能の追加や、既存バッチ処理への1ステップ追加など、最小限の変更に絞ることで、テスト範囲と業務停止リスクを抑えられます。
見積作成や検査記録など、日々の入力が発生する業務はクラウド側のアプリ画面に寄せ、基幹にはまとまったデータだけを渡します。
クラウド側に積む業務の代表例とデータ受け渡し方式
基幹に手を入れず、クラウド側にアプリを「積む」代表的な業務には次のようなものがあります。
- 見積書作成(品番・数量・単価を入力し、テンプレートに沿って出力)
- 検査記録の入力・保存(タブレットからその場で記録)
- 生産進捗の可視化(工程ごとのステータス更新)
- BI(Business Intelligence=蓄積データをグラフ化して経営判断に使う仕組み)によるレポート表示
これらとオンプレ基幹をつなぐ方式は、業務の性質によって使い分けます。
1日1回、決まった時間に受注データをCSVファイル(例：juchu_YYYYMMDD.csv)として基幹から出力し、クラウド側が取り込む方式。リアルタイム性は不要だが確実性を重視する業務に向いています。
API(Application Programming Interface=システム同士がデータをやり取りするための窓口)を使い、必要なタイミングで即座にデータを送受信する方式。在庫の即時反映など、リアルタイム性が求められる場面で使われます。
基幹とクラウドの間に「中間テーブル」と呼ばれる受け渡し専用の領域を設け、双方が決まった形式でデータを読み書きする方式。改修範囲を基幹側にほとんど及ぼさずに済むのが利点です。
Before / After：見積書作成の場合
営業担当がExcelで見積書を作成し、受注が確定したら基幹システムの受注入力画面に品番・数量・単価をあらためて手入力。転記ミスが起きても気づきにくい。
クラウド側の見積作成画面で品番・数量・単価を入力すると、そのまま見積書PDFが出力される。受注確定後は画面上の「基幹連携」ボタンを押すだけで、CSVファイルが自動生成され基幹システムの受注取込処理に渡る。転記工程が1本減り、Excelと基幹システムそれぞれに同じ数字を打ち込む二重入力がなくなる。
基幹システム連携の相談で最初に聞かれる3項目
基幹システム連携について相談すると、初回のヒアリングではほぼ必ず次の3点が確認されます。あらかじめ整理しておくと話が早く進みます。
基幹側のベンダーが現在も保守を行っているか、ソースコードの改修が可能かどうか。改修不可の場合は出力機能やバッチ処理の追加だけで完結する設計が必要になります。
受注データや在庫データが固定長ファイルなのかCSVなのか、文字コードは何かといった仕様の確認です。ここが曖昧だと連携設計そのものが進みません。
常時接続してリアルタイムでやり取りするのか、決まった時刻にまとめて処理するバッチ方式にするのか。業務の即時性の要否によって選択が変わります。
EDI(Electronic Data Interchange=企業間で受発注データを電子的にやり取りする仕組み)とAPIを組み合わせ、オンプレ基幹とクラウドサービスをリアルタイム連携させるサービスも拡充しています。中小企業では「基幹には手を入れず、APIやEDIで周辺業務だけをつなぐ」というニーズが強まっている状況です。
FAX受注・メール受注をクラウド側で読み取り基幹へ自動連携する構成
製造業でとりわけ悩みの種になりやすいのが、FAXやメールで届く受注情報です。担当者が内容を目視で確認し、基幹システムの受注入力画面に手作業で打ち込む――この工程は転記ミスの温床であると同時に、担当者不在時の業務停止リスクにもなります。
この課題に対しては、FAXやメールで届いた受注書をクラウド側で読み取り、内容をデータ化したうえで基幹システムに自動連携する構成が有効です。こうした文書のデジタル化とデータ連携を担う仕組みとして、DocSyncというサービスが自社サービスとして提供されているようです（外部情報源での裏付けは確認できていません）。受注書の画像やPDFを取り込み、必要な項目を抽出して中間テーブルやCSVの形で基幹に渡すことで、基幹側の改修を最小限に抑えながら手入力工程を減らせます。
まとめ
- 基幹刷新ではなく基幹連携を選ぶことで、改修費用と業務停止リスクを抑えながら周辺業務を改善できる
- 受注・在庫マスタなど基幹の中核は変更せず、見積書作成や検査記録などクラウド側に業務を積む設計が現実的
- CSV出力・API・中間テーブルを業務特性に応じて使い分け、FAX・メール受注の自動連携から着手するのが現実的な第一歩
本記事はAIを活用して作成しています。内容についての責任は当社が負います。AI活用ポリシー