Integration Deep Dive Aug 27

Yes, because they are different products serving different businesses. Kinetic is a manufacturing ERP built around jobs, bills of material and production scheduling. Prophet 21 is a distribution ERP built around inventory, pricing and order velocity. The CRM side looks similar, but what the sales team needs to see differs: a manufacturer's rep asks about job status and lead time, a distributor's rep asks about stock position and price for this customer. Scope the field mapping to the business model, not to the ERP brand.

Direct connections are possible and are simpler to reason about when there are only two systems and the data flow is well defined. Middleware earns its cost when there is a third or fourth system in the picture, when transformations are complex, or when you need queuing and retry logic because one system goes offline for maintenance. The tradeoff is operational: a direct connection has fewer moving parts, but middleware gives you a place to see and replay a failed message instead of discovering the gap weeks later.

Decide early whether the CRM shows one consolidated view of an account or mirrors the ERP's legal entity structure. Manufacturers with several operating companies frequently have the same customer set up separately in each, and sales leadership wants to see the total relationship while finance needs the entities kept apart. The workable pattern is a parent account in the CRM that rolls up several ERP customer records beneath it, with currency carried on the transaction rather than the account.

Customer service is usually the largest beneficiary, because most inbound calls are order status questions that otherwise require someone to open the ERP or ask a colleague. Finance benefits when collections conversations can see the sales relationship rather than only the aging report. Leadership benefits from a pipeline that reconciles to actual shipped revenue, rather than two numbers that never match. Scoping the project as a sales tool alone tends to undersell it internally and makes the budget harder to justify.

Direct database access usually disappears, which is the point at which many home-grown integrations stop working. Cloud deployments expose data through APIs with rate limits and authentication that on-premise integrations were never written to handle, and the upgrade schedule stops being something you control. Anything reading the ERP database directly should be inventoried before a cloud migration is scheduled, not after, because rebuilding those connections is often the longest task in the project.

No, and that is precisely the tradeoff. An ERP-native CRM removes the integration problem because it shares the ERP's data model. What you give up is the sales functionality that a dedicated CRM invests in: pipeline management, forecasting, marketing automation, mobile use by field reps, and the ability to change sales process without an ERP change request. The decision is whether the integration work costs less than the sales capability you would be doing without.

Custom point-to-point integrations break when the ERP's underlying tables, APIs or field names change during an upgrade, because the integration was written against the old structure. Prebuilt connectors avoid this by sitting on the vendor's supported interface rather than the database directly, so the vendor absorbs the change. The practical test to apply to any integration you already own: ask whether it reads the ERP through a documented, versioned API, or through direct table access. The second kind is the one that fails on upgrade weekend.

It depends on the decision the data supports. Order status and inventory that a rep quotes to a customer on a live call need to be current, so those are read in real time or near real time. Historical invoice totals, aggregated revenue and account history change slowly and are fine on a scheduled sync. Real time everywhere is expensive and creates load on the ERP for no benefit. Set the frequency per data type, not per system.

You need a declared system of record per field before the integration goes live, otherwise the two systems overwrite each other in a loop. The usual split is that the ERP owns billing entity, credit terms and shipping addresses, while the CRM owns contacts, relationships and sales activity. The harder question is identity: what makes two records the same customer. Most manufacturers and distributors use the ERP's customer number as the key, and the integration then carries it into the CRM as a read-only field.

Bring in what a customer-facing person needs to answer a customer question: order status, shipment dates, invoice and payment history, open quotes, item availability. Keep out anything that is internal accounting detail, cost data, or a record nobody in the CRM will act on. The common failure is syncing everything because it is technically possible, which slows the integration, multiplies conflict points and buries the useful fields. If no one can name the person who will look at a field, it does not need to sync.