2つの業務システムが情報を適切に共有していない場合、通常は「ちょっとした不便」として扱われます。誰かがスプレッドシートを書き出し、数行修正して同僚にメールし、それを別の場所にアップロードする。これは、その担当者が休暇を取るか、注文量が倍増するか、あるいはシステムのアップデートでファイル形式が変わるまでは機能します。
急場しのぎの回避策として始まったものが、いつの間にかビジネスが依存する不可欠なプロセスになってしまうのです。
「再入力」は目に見えるコストに過ぎない
明らかなコストは、情報をある場所から別の場所へコピーする時間です。より大きなコストは「遅延」です。注文が入っても、在庫レベルに反映されるのは明日。入金があっても、会計上は未払いのまま。現場は今朝仕事を終えたのに、オフィス側ではまだ進行中だと思っている。
現場はこうしたギャップを埋めるために動きます。電話で確認し合い、自分専用のスプレッドシートを作り、念のために承認ステップを増やします。時間が経つにつれ、公式なシステムの裏で、ベテラン社員の頭の中にしかない「非公式な第2のシステム」が構築されていきます。
どのシステムが何を管理するかを決める
システムを連携させる前に、非常に重要となるシンプルな質問をします。「それぞれの情報について、どのシステムが最終決定権（正解）を持っていますか？」
顧客の住所を3つの異なる場所で変更できる場合、どれが優先されますか？ 会計システムに送られた後に請求書がキャンセルされた場合、会計担当はどうやってそれを知りますか？ スキャナーが誤って同じデータを2回送信した場合、2つの取引を作成すべきですか？
これらは技術的な質問のように聞こえますが、実際にはビジネス上の決断です。事前に合意しておくことで、後の混乱を大幅に防げます。連携によってデータが完璧に移動できたとしても、それが「間違ったデータ」であれば意味がないからです。
障害を想定した設計
システム間の連携は、日常的な理由で失敗します。インターネットの切断、パスワードの期限切れ、サプライヤーのソフトウェア変更、情報の到着順序の入れ替わりなどです。優れた連携システムはこれらを想定しています。問題を検知し、情報を保持し、適切に再試行し、何が滞っているかを誰でも確認して解決できるようにします。
再試行には注意が必要です。在庫レベルを2回確認しても害はありませんが、同じ支払い処理や出荷指示を2回送ると問題になります。適切に構築された連携システムは、重複したメッセージを認識して無視し、2重処理を防ぎます。
問題を可視化する
優れた連携システムは、いつでも次のような単純な質問に答えられるべきです。「今日は何件の注文がありましたか？ 待機中のものはありますか？ 最も古いものはどれくらい待機していますか？ 失敗したものはありますか？ 誰かの確認が必要ですか？」
最も有用なアラートは、コンピュータのことではなくビジネスに関するものです。「サーバーがビジーです」よりも「2時間、倉庫に注文が届いていません」の方がはるかに役立ちます。
また、注文数、請求合計、手元在庫など、システム間の合計値を定期的に比較することも重要です。優れたシステムであっても、徐々に数字が乖離していくことがあります。何も起きないことを保証できる人はいません。大切なのは、高額な損失につながる前に、問題を早期に発見することです。
最も支障が出ている連携から着手する
すべての連携が即時である必要はありません。売上レポートが夜間に更新されるだけで十分な場合も多いです。一方で、販売可能な在庫を制御するものや、お金を動かすものは、より高い信頼性と厳重な監視が必要です。
まずは、社内で情報がどのように流れているかをスケッチし、手作業の頻度を数え、どの問題に最も時間が取られているかを書き出してみるのが良いでしょう。そして、最も苦労している連携から修正します。小さくてもしっかりと監視された1つのリンクが、完成しない大規模なプラットフォームプロジェクトよりも多くのリスクを取り除いてくれます。
1つだけ覚えておくとしたら
優れた統合とは、接続したシステムの数ではありません。正しい情報が正しい場所に正しいタイミングで届くこと、そして届かなかったときにすぐ気づけることです。