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

連携の前に決める3つのこと

連携方式の比較から始めると、あとで「どちらのデータが正しいのか」「止まったら誰が直すのか」が決まらず、二重入力が別の形で残ります。基幹を残すと決めた時点で、次の3つを業務単位で先に決めます。

残す部分・新たに作る部分・人が判断する部分

基幹を残す連携では、基幹の中身を作り替えずに、その外側に受け渡しの仕組みを足します。どこまでを仕組みに任せ、どこを人が判断するかを最初に分けておくと、既存の保守ベンダーとの責任分界も説明しやすくなります。

基幹側の改修が必要になる場合は、改修の可否と費用負担を基幹の保守ベンダーと合意してから進めます。当社が基幹の中身を直接変更することを前提にはしません。

基幹に直接触れないデータの流れ (説明用の構成例)

これは考え方を示す説明用の構成例で、特定の実案件の構成図ではありません。実際の構成は、基幹が持つ出力・取込の機能と保守契約を確認してから決めます。

1. 1基幹から読み取り専用で出力する基幹が標準で持つCSV出力・帳票出力・APIなど、既にある出口を使います。基幹のデータを書き換える権限は連携側に持たせません。
2. 2出力を受け口 (出力領域) に置く連携専用の置き場所に出力します。読み書きできる人・システムを限定し、ファイルやデータを残す期間を決めます。
3. 3照合・差分処理で新規・変更・削除・重複を分ける伝票番号と行番号などの一意キーで、前回との差分を判定します。マスタに無い品番や必須項目の欠けは、捨てずに保留へ回します。
4. 4取込候補を画面で確認する差分と保留の理由を一覧で見せます。金額や数量が大きく変わったものなど、確認が必要な行を目立たせます。
5. 5人が承認する担当者が承認した行だけを取込対象にします。承認者と日時を記録します。
6. 6基幹の標準の取込機能で登録し、結果を記録する取込の成否、件数、合計を記録し、失敗した行は再送できる状態で残します。

基幹のデータベースへ直接つなぐことは、連携の必須条件ではありません。直接つなぐ方式は実装が早く見えますが、基幹の保守契約、負荷、アクセス権の境界に影響するため、他の出口が無い場合に限り、読み取り専用で保守ベンダーの合意を得たうえで検討します。

全面刷新と段階刷新

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

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

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

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

連携方式の選択

どの方式にも向き不向きがあり、「CSVなら安全」「APIなら確実」とは言い切れません。まず前提と同期の遅れを比べます。

次に、権限・再送・削除の扱いを比べます。連携の障害は、ここを決めていないことから起きやすくなります。

特定の基幹・ERP製品が上記のどの方式に対応するかは、製品の公式仕様、現在の保守契約、テスト環境で確認してからお答えします。確認前に「つながる」とはお伝えしません。

リアルタイムとバッチ

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

同期失敗・再送・重複・整合性

失敗したデータを捨てないこと、そして再送しても結果が二重にならないことが、連携を安心して止めたり再開したりできる条件です。

データ移行

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

切替・並行稼働

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

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

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

相談の前に用意するもの

構成図や仕様書が揃っていなくても相談できます。最初の検証範囲を決めるには、次の3つが分かれば足ります。

1. 現在使っているシステム名 (基幹・ERP、Excel、現場のシステムなど。製品名とバージョンが分かれば記載)
2. 転記・二重入力が起きている業務を1つ (例: 受注の内容を基幹に打ち直している)
3. その業務で、データが何分・何時間以内に反映されていれば足りるか (同期頻度)

さらに詳しく整理できる場合は、次の項目を空欄のまま使ってください。製品名が分かるだけでは接続できるかは判断できないため、相談のあとで公式仕様・保守契約・テスト環境を確認します。ID・パスワード・APIキーは書かないでください。

実データ、顧客名の入った帳票、システムの接続情報は、相談フォームに添付・記載しないでください。必要になった段階で、秘密保持契約を結んだうえで受け渡し方法を決めます。

よくある質問

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

できる場合が多くあります。CSVの入出力、帳票出力の取り込みなど、基幹が既に持っている出口を組み合わせます。データベースへの直接アクセスは相手システムの保守契約に抵触することがあるため、他の出口が無い場合に限り、事前に保守ベンダーへ確認してから検討します。対応できるかどうかは、製品の仕様と契約を確認したうえでお答えします。

基幹のデータベースに直接つなぐ必要がありますか。

必須ではありません。基幹の標準の出力を連携専用の置き場所に出し、照合と人の承認を経て、基幹の標準の取込機能で登録する構成であれば、基幹のデータベースには触れずに済みます。直接つなぐ方式は、保守契約・負荷・権限の確認が取れた場合に、読み取り専用で検討します。

CSV連携なら安全ですか。

方式だけでは決まりません。CSVでも、ファイルの置き場所を誰が読めるか、処理後のファイルを残すか、同じファイルを二重に取り込まないか、削除をどう伝えるかを決めていないと、情報漏えいや数字のずれの原因になります。どの方式でも、権限・再送・削除の扱いを先に決めます。

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

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

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

まず、同じ情報がどこで何回入力されているかを洗い出し、それぞれの正となるシステムを決めます。そのうえで、件数が多く、打ち直しの手間が大きい1本から片方向の連携を試し、効果と運用上の問題を確かめてから範囲を広げます。全体を一度につなごうとしないことが、失敗を小さくする近道です。