基幹・ERPを残したまま現場システムをつなぐ

全面刷新と段階刷新

基幹そのものが保守終了やサポート切れを迎えている場合は、連携で延命するより刷新の検討が先です。一方、基幹は動いているが現場の記録が紙・Excelに残っている場合は、段階刷新のほうが投資効率が高くなります。

どのシステムを正とするか

連携の失敗の多くは、方式の選択ではなく、正となるシステムをマスタ単位で決めていないことに起因します。次の粒度で決めます。

「両方で編集できる」状態を作らないことが原則です。どうしても双方向が必要な場合は、項目単位で編集権を分けます。

連携方式の選択

リアルタイムとバッチ

• 業務上、何分以内に反映されれば足りるかを先に決める（「即時」と言われた要件の多くは日次で足りる）
• 夜間バッチにする場合、翌日の朝までに何が確定している必要があるかを確認する
• リアルタイムにすると、相手システムの停止時の扱いを設計する必要が出る
• 締め処理のタイミングと、締め後の訂正をどう反映するかを決める

同期失敗・重複・整合性

• 一意キー（伝票番号＋行番号など）を決め、重複取り込みを検知できるようにする
• 失敗したデータを捨てず、保留キューに残して再処理できるようにする
• 失敗の通知先（担当者、チャット、メール）と、気づくまでの時間を決める
• 日次で件数・合計の突合を行い、ずれを早期に検知する
• 訂正・取消の伝播順序（どちらから直すか）を決める

データ移行

• 移行対象と年数を決める（参照だけなら旧システムを読み取り専用で残す選択肢もある）
• マスタの重複・表記ゆれを、誰がどの基準で統合するかを決める
• 移行後の検証（件数、合計、抜き取り）を移行前に合意する
• 移行リハーサルを行い、所要時間と切り戻し手順を確認する

切替・並行稼働

1. 切替方式（一斉か、業務・拠点単位の段階切替か）を決める
2. 並行稼働の期間と、その間の二重入力の負担を見積もる
3. 戻す条件（何が起きたら旧運用へ戻すか）を事前に決めておく
4. 切替直後の確認項目（当日の受注、出荷、在庫の一致）をリスト化する
5. 繁忙期・締め日を避けて日程を組む

費用・期間を左右する条件

• 連携先システムの数と、それぞれの方式
• 相手システムの仕様書・テスト環境の有無、保守ベンダーの協力可否
• 相手側の改修が必要かどうか（費用負担の合意も含む）
• 同期の頻度と、失敗時の復旧要件
• 移行データの量と品質
• 並行稼働の期間

よくある質問

基幹システムにAPIがありません。連携できますか。

できる場合が多くあります。CSVの入出力、データベースの参照、帳票出力の取り込みなど、代替手段を組み合わせます。ただしデータベースへの直接アクセスは相手システムの保守契約に抵触することがあるため、事前に保守ベンダーへ確認してください。

連携を増やすと、あとで基幹を入れ替えられなくなりませんか。

連携部分を業務ロジックから切り離し、入出力の仕様として文書化しておけば、入れ替え時の影響を局所化できます。逆に、現場システムの中に基幹固有の仕様が散在すると入れ替えが困難になります。設計時に、連携の入口・出口を1か所に集める構成にします。

二重入力をなくすには何から着手すべきですか。

まず、同じ情報がどこで何回入力されているかを洗い出し、それぞれの正となるシステムを決めます。多くの場合、片方向の連携を1本通すだけで大半の重複入力が解消します。全体を一度につなごうとせず、件数の多い1本から始めてください。