Born Unified vs. Stitched Together: The Two Faces of ERP Integration

Two Types of ERP Integration: Model Integration vs. Application Integration

The article opens by noting that nearly every ERP vendor claims "integration," but the term has become so overused that it loses discriminatory power. The author recounts a conversation with an IT director at a manufacturing company who was confused after three months of vendor evaluations.

Core Distinction: Grown vs. Assembled

The author categorizes integration into two fundamentally different approaches:

Model Integration (模型一体化) : The ERP is built on a single unified business model — unified business objects, unified data model, unified core transactions. Modules such as procurement, inventory, production, sales, quality, equipment, projects, cost, and finance are not independent products but different business domains under the same model. This integration is intrinsic: a single business event (e.g., production completion and put-away) simultaneously updates inventory quantities, forms product costs, and reflects financial values without interfaces, scheduled jobs, or manual reconciliation. Data and rules are shared; accounts are naturally consistent.

Application Integration (应用一体化) : The ERP is treated as a comprehensive management application platform. Starting from a financial management base, it expands domain by domain (HR, contracts, expense, tax, treasury). Each application can be built and evolved independently, then connected via APIs, messaging, data synchronization, and integration platforms into a unified portal. This approach offers flexibility, speed, and incremental deployment, but cross-application consistency is no longer guaranteed by the model; it must be engineered through interface design, messaging mechanisms, data synchronization, error compensation, and data governance.

In short: model integration relies on birth; application integration relies on maintenance.

Analogy: Organism vs. Team

The author illustrates the difference with an analogy:

Model integration is like a human body: heart, brain, limbs are born as one system; coordination is automatic.

Application integration is like an ad-hoc team: each member is capable, but synchronization depends on command, communication, and training.

Humans never ask "does the heart need to sync with the hand?"; teams ask "do these numbers match?" every day.

Four Key Trade-offs

Model integration benefits: peace of mind — business and finance are naturally consistent, audits are easier. Costs: heavy implementation, long cycles, rigid processes, limited customization. Adopting a module means signing a long-term process contract.

Application integration benefits: freedom — deploy what you need, when you need it. Costs: you must sustain a governance framework — interface ownership, message loss handling, data discrepancy resolution — all ongoing responsibilities.

Most enterprises fail not by choosing wrong, but by not understanding the price of their chosen path: wanting model integration's ease but disliking its rigidity; wanting application integration's flexibility but unwilling to staff governance.

The result: gaining neither advantage.

Four Decision Questions

When evaluating ERP integration, ask:

Do finance and operations need real-time consistency, or is month-end reconciliation sufficient?

Can the organization accept a single unified process, or do different units inherently require different rules?

Can the IT team sustain long-term interface and data governance?

Over the next three years, is the priority stability, or frequent new domains, acquisitions, and rapid expansion?

If answers lean toward the first option in each pair, model integration fits better; if toward the second, application integration is more economical.

The article concludes with a real-world check: the IT director admitted their accounts required significant effort to reconcile. The author advises clarifying "why they don't match" first — that clarity reveals whether the enterprise needs an organism or a team.