One question can cross several systems.
A sales question may look simple: why did revenue change this month? The answer can depend on commerce orders, ERP adjustments, CRM context, and analytics definitions. Bringing those systems together does not start with drawing an arrow between their names. It starts with understanding which records answer which part of the question.
Map the decision before choosing the integration. Identify the system of record for each measure, the identifiers used to join records, the update frequency, and the people who can explain exceptions. Keep the intended audience and access boundary visible throughout the design.
Agree what the numbers mean.
“Sales” may refer to orders placed, invoices issued, or recognised revenue. Returns, discounts, cancellations, currency, and reporting periods can change the answer. AI should not resolve those definitions by improvising. The relevant business and data owners need to agree the approved metric view.
For a reporting use case, calculations should come from trusted queries or established analytics logic. AI can help interpret the question, select an allowed view, and explain a result. Keep the source, scope, period, and calculation visible so a person can check the answer and understand its limits.
Connect only what the workflow needs.
A bounded first release might use read-only data for one product category, business unit, or reporting period. That can expose identifier mismatches, missing records, and freshness issues without requiring every system to be connected at once. The scope should be useful enough to test the real decision.
Design for the cases where a source is unavailable or the requested information is not permitted. A clear response may be to show the missing context, ask for a narrower question, or route the work to an owner. Confident wording is not a substitute for complete and authorised evidence.
Make the connection an owned capability.
An integration is not finished when data first moves. It needs ownership, monitoring, evaluation cases, recovery steps, and a way to manage changes in source definitions. Business reviewers should help test ordinary questions as well as ambiguous periods, duplicate records, incomplete joins, and restricted requests.
The deliverable is a practical blueprint: approved sources, business definitions, access rules, integration choices, evaluation criteria, and operating responsibilities. That blueprint connects an AI strategy to the existing company. It gives the team a clear basis for extending the capability when the evidence supports the next step.