CRM・会計・受注システムの連携見積もりは何で変わる？

同じCRM、受注システム、会計ソフトをつなぐ見積もりでも、2社が想定している仕事は大きく違うことがあります。一方は新規注文を送るだけ。もう一方は顧客の照合、会計側のステータスの返送、後からの変更や過去データの取り込みまで含めているかもしれません。

見積もりを比べるには、特定の注文がどう処理され、誰が結果を確認するかを記述します。システムの数から分かるのは、仕事がどこで起きるかです。構築すべきものを決めるのは、システム間のルールです。

一件の注文を追ってみる

架空の卸売会社を考えてみましょう。営業はCRMに顧客の連絡先を保存し、担当者は受注システムで注文を受け付け、経理は別の会計ソフトを使っています。会社は、受け付けた注文から経理が確認するための書類の下書きを作りたいと考えています。

注文ORD-204を例にします。顧客のCRM上のIDはC-81、会計上の取引先番号はA-347です。この2つが同じ顧客を指すと誰かが確認しなければなりません。社名だけで照合すると、名前が変わった場合や似た記録が複数ある場合の判断が残ります。

次に、各情報の正本となるシステムを決めます。連絡先の氏名はCRM、承認済みの請求先情報は会計、受け付けた数量と合意価格は受注システムを正本とするかもしれません。これはあくまで例としてのルールです。実際のルールはその会社が決める必要があります。

「受け付けた」の意味も明確にします。営業が注文を受け付けても、それだけで経理が作成された書類を承認したことにはなりません。MicrosoftのDynamics 365 Salesのドキュメントでは、見積もり、注文、請求書を別の段階として扱い、この違いを示しています。これは一製品の流れです。連携のルールは、実際に使うソフトと業務に合わせて決めます。

同じ3つのシステムでも、作業範囲は違う

架空の卸売会社について、考えられる3つの範囲を示します。実際の製品が必要な操作に対応していることが前提です。範囲を広げるほど、決め、実装し、確認する仕事が増えます。

最小の範囲で十分な場合もあります。その場合は手作業を見積もりに明記し、買い手がその運用でよいか判断できるようにします。広い範囲では、追加するデータの流れと判断事項を具体的に示します。

見積もりに使える連携内容を整理する

まず受注から会計への流れについて、開始条件を書きます。「受注システムで注文が受け付けられたとき」などです。注文IDと顧客IDの対応を記録します。移す項目を列挙し、必要なら数量、値引き、通貨、ステータスをどう解釈するかも書きます。会計上の扱いは担当者と合意してください。

連携先で行う操作も指定します。下書きを作るのか、更新可能な下書きを直すのか、経理へ確認を回すのか。誰が承認できるかも決めます。完了までの想定時間と、未完了の転送を担当者が調べ始める時点を示します。「定期的に」よりも合意した業務上の期限のほうが、見積もりに役立ちます。

戻り方向の流れも一つずつ記述します。会計から書類IDを返すことと、入金ステータスを返すことは別の操作です。どちらも、顧客の全項目やすべての書類を両システムから編集できるという意味ではありません。

システム間で意味を変換するためのMicrosoftのガイドは、データの意味が異なる場合に意図的な処理が必要な理由と、保守や監視を考慮すべきことを説明しています。そこで紹介されるのは一つの設計パターンであり、すべての連携で採用する必要があるわけではありません。見積もりでは、似た名前の項目を同じ意味だと決めつけず、変換作業を明示することが大切です。

結果を誰がどう確認するか決める

それぞれの流れについて、何をもって完了とするかを記録します。メッセージを送っただけでは、正しい顧客と金額で下書きが作られたか分かりません。元と先の記録をどう比較し、欠落や不一致をどう見つけ、調査に必要なIDをどう確認するかを決めます。

例外を最初に受け取る担当者やチーム、見られる情報、元の記録を修正できる人、再試行を許可できる人を決めます。顧客が見つからない、項目が拒否された、確認後に訂正が届いた、といった例を含めます。人が対応するケースも定めます。

これで連携内容を見積もりに使える形に整理できます。開始条件、正本となる情報、ID、方向、項目の意味、連携先の操作、時間、完了確認、例外の担当者がそろいます。テスト用アカウントを用意する人と、結果を受け入れる人も加えましょう。

過去データの範囲を決める

「古い注文も含める」だけでは判断できません。記録の種類と期間、必要な関連顧客レコードを決め、照合と整理の担当を割り当てます。取り込み後に何を確認するかも書きます。

この一度限りの作業は、継続的な転送と分けて考えます。過去データの範囲がどこで終わり、通常の処理がどこから始まるか、切り替え中の変更をどう扱うかを決めます。そうしないと、2社とも「データ取り込み」と書いていても、準備と確認の量が違うかもしれません。

前提条件と継続作業を比べる

各社に同じ連携内容を基に見積もってもらいます。製品のエディション、許可される操作、権限、インターフェースの制限、コネクターの条件について、確認済みのことと未確認のことを分けて示してもらいましょう。API一覧やコネクターのロゴだけでは、自社のアカウントで必要な操作ができるとは分かりません。

アクセスがまだない場合やルールが未決定の場合は、どう確認し、提案にどう影響するかを聞きます。英国政府のアジャイル契約に関するガイドは、公共調達で情報不足が商業上の選択に与える影響を論じています。ここで見積もりを比べる際に役立つのは、2つの約束を同じとみなす前に前提を明らかにする、という考え方です。

初期設定とテストは、継続的なソフトやコネクターの利用料と分けます。そのうえで、認証情報の管理、未完了の転送の確認、項目対応の変更、製品変更時の互換性対応など、合意する運用・保守作業を示します。何が含まれ、誰が担当し、後からの変更をどう決めるか確認してください。利用料の一行だけでは、その責任は分かりません。

最後に、各提案でORD-204がどう処理されるか追ってみます。何がいつ届き、完了できないときにどうなり、誰が引き継ぐか見えますか。違いがあれば、合計金額を比べる前に範囲として話し合いましょう。

具体的な連携についてLINK-Vと相談したい場合は、API連携サービスをご覧ください。データの流れと未決定の点をお持ちください。作業範囲と継続的なサポートは案件ごとに合意します。

連携の見積もりについてよくある質問