What Business Data Should Be Ready Before Connecting AI to ERP or CRM?

A common mistake we see when discussing AI ERP and AI CRM projects is starting with the question of which AI model to use before checking the business data that will support the system. For a serious AI integration, at least five data groups should be mapped: customer master data, product master data, transactions, inventory, and operational workflows. These datasets do not have to be perfect before a project begins, but they need enough structure and consistency to be processed, validated, and traced back to the original source.

Customer master data, for example, should contain more than a name and phone number. A sales AI may need customer_id, company name, contact person, WhatsApp number, email, region, customer type, assigned salesperson, purchase history, product categories purchased, payment terms, credit limit, and customer status. If the same company appears as "PT ABC", "ABC Indonesia", and "PT ABC Indonesia", the AI may interpret them as three different customers and produce misleading analysis.

Product master data is another frequent source of problems. A distributor with thousands of SKUs may have internal codes, barcodes, product names, brands, categories, types, dimensions, purchasing units, selling units, prices, suppliers, and active status. If the same product has different names in the ERP, marketplace, and sales spreadsheet, AI data preparation must include a mapping layer that connects those records.

Transaction context is equally important for AI that reads documents, generates recommendations, or executes workflows. The system needs to distinguish between draft, completed, cancelled, returned, and paid transactions. Without those statuses, AI may include transactions that should no longer be counted.

Many companies believe they are ready for AI because they have millions of transaction records. Transaction volume, however, is not the same as data readiness. If the master data is inconsistent, a large transaction database can actually amplify the problem. AI analyzes patterns from the information it receives, so inconsistent customer, product, branch, salesperson, or transaction identities can distort the results.

Consider a distributor with products recorded as "Semen 50 Kg", "Semen 50kg", and "Semen Portland 50 KG". These may refer to the same product, but the system cannot safely assume that without a proper product mapping. Before AI is used for product recommendations or inventory forecasting, the company should establish a stable product_id and treat the display name as an attribute that can change.

The same principle applies to customers. A WhatsApp number can be a useful identifier, but it is not always a perfect business identity. One phone number may be used by an owner operating multiple stores, while one company may have several contact persons. A CRM intended for AI should therefore maintain a stable customer_id and clear relationships between companies, branches, contacts, phone numbers, and transaction history.

At Sahabat Teknologi, we typically recommend creating a simple data dictionary before AI development begins. Each important field should have a defined meaning, format, owner, update frequency, nullability rule, and source system. A document like this is often more useful during implementation than a long AI prompt because it establishes what the data actually means.

For AI ERP projects, transaction and inventory data are often among the most valuable datasets because they represent the company's actual operating condition. However, the data needs enough context to be useful. An AI system asked, "What should we purchase next month?" cannot rely only on historical sales. It may also need transaction dates, quantities, prices, warehouses, suppliers, returns, current inventory, minimum stock levels, and supplier lead times where available.

Suppose a store sold 1,000 units of a product in one month. That number may look significant, but if 700 units came from a one-time project, AI should not automatically assume that normal demand will remain at 1,000 units the following month. Transaction data should include customer, channel, date, transaction type, and, where possible, information about projects or promotions.

Inventory requires the same level of context. "500 units in stock" does not necessarily mean 500 units are available for sale. Some may be reserved for sales orders, damaged, located in another warehouse, in transit, or awaiting physical stock reconciliation. The definition of available stock therefore needs to be explicit.

The Indonesian business environment also makes sales channels particularly important. A company may receive orders through physical stores, sales representatives, its website, WhatsApp, Tokopedia, Shopee, TikTok Shop, or other marketplaces. If those records are not connected, AI may analyze each channel independently and fail to recognize that the same customer is purchasing through several channels.

Forecasting also requires caution around historical anomalies. Major promotions, price changes, new branches, stockouts, or large projects can make unusual patterns appear normal. AI data preparation should preserve enough context for the model or forecasting logic to distinguish recurring demand from exceptional events.

AI data preparation does not stop at database records. Business workflows also need to be documented because many useful AI implementations require the system to participate in a process rather than simply answer questions.

Consider a quotation workflow. At a distributor, the process may begin with an inquiry through WhatsApp. A salesperson identifies the customer, selects products, checks pricing, applies a discount, requests approval if the discount exceeds a certain threshold, generates a quotation PDF, sends it to the customer, and records the follow-up in the CRM. If AI only has access to the product database, it is not truly integrated into the business process.

For these use cases, we typically map each stage and determine which actions AI can perform and which ones still require human approval. AI may read a WhatsApp inquiry, match products, prepare a quotation draft, or summarize customer history. Decisions involving discounts beyond a defined threshold, price changes, item removal, or credit approval can remain subject to human approval.

This approach is also important for security. The NIST AI Risk Management Framework uses the functions Govern, Map, Measure, and Manage to structure AI risk management. Companies therefore need to understand the system's purpose, risks, evaluation methods, and controls when the output does not behave as intended.

Do not give an AI system unrestricted ERP access simply because it can call an API. Permissions should follow the actual business requirement. An AI that only needs to read inventory does not need permission to modify stock. An AI that creates an invoice draft does not automatically need permission to post the transaction into accounting.

Before committing a significant budget to AI integration, we recommend conducting a data readiness audit. It does not have to become a large consulting project. For an initial pilot, one business process is enough, such as AI customer service, product recommendations, sales assistance, inventory forecasting, or quotation generation.

Start with real production data rather than a clean sample prepared by the IT team. For example, take 500 customers, 1,000 products, and several months of transaction history. Check how many duplicate customers exist, how many products have no SKU, how many transactions have no customer, how many transactions lack clear status values, how many prices are missing, how many units are inconsistent, and how many records cannot be connected across tables.

Then create a simple readiness classification. AI data preparation can categorize datasets as ready, needs cleaning, needs mapping, or unavailable. If 90% of the required information already exists but is spread across three systems, the main problem may be integration. If critical information has never been recorded, the company needs to improve its operational data capture before expecting AI to produce reliable results.

Not every data problem needs to be solved before the first pilot. This distinction is important because cleaning an entire database can cost significantly more than the business value of the initial AI use case. It is often more practical to clean the data required for one workflow, test the result, and expand the scope only when the business case is proven.

For companies using both ERP and CRM, the next step is to define the system of record. For example, the ERP may be the primary source for inventory and transactions, while the CRM is the primary source for customers and sales activities. A marketplace may remain the source for a particular sales channel. AI should then retrieve information from those sources through controlled APIs or data pipelines rather than relying on spreadsheets manually exchanged every week.

If the audit shows that the data is not ready, that does not mean the AI project must be cancelled. The audit creates a more realistic roadmap: clean the master data, document the workflow, build the required integrations, establish permissions, and then start with one measurable AI use case.