Integration — Where the ERP Ends and Everything Else Begins | ERP for Beginners S2 Ep4

Season Two of ERP for Beginners, episode four. The first three episodes of this season looked inside the ERP — customisation versus configuration, master data versus transactional data, and the document flow that ties every module together. This one turns the camera around. A modern enterprise stack is never just the ERP. It's the ERP plus fifteen or twenty other applications — CRM, warehouse management, business intelligence, e-commerce, payroll, banks, tax portals — and the wiring between them is where most of the expensive complexity actually lives. This episode is a vendor-neutral, plain-English tour of that wiring: what integration is, why the ERP doesn't just absorb everything, and why the integration track routinely consumes a third of a program's budget. What You'll Learn: - Why the ERP is the trunk of the tree, not the whole tree — and why specialist surrounding systems don't go away when the ERP arrives - The landscape — CRM, WMS, BI / data warehouse, e-commerce, payroll, banks, tax authorities - Batch integration — the nightly file, how it works, why it's still the most common pattern, and where its latency hurts - Real-time integration — request-response APIs versus event-driven pub/sub, and the trade-off between power and fragility - Middleware — what iPaaS, ESBs, and message queues actually do, and how hub-and-spoke collapses forty-five point-to-point edges to ten - The system-of-record question — one owner writes, everyone else reads, and what happens when two systems fight over the same field - Where the complexity lives — why integration is a third of the budget and a disproportionate share of the risk - The question to ask about any ERP screen — what feeds it, and what reads from it Timestamps: 0:00 - Intro — where the ERP ends 0:20 - What's in this episode 0:48 - Why the ERP doesn't do everything 1:48 - The landscape around the ERP 2:58 - Batch — the nightly file 3:53 - Real-time — APIs and events 4:58 - Middleware — what sits between 5:58 - Who owns which data — the system-of-record question 6:53 - Where the complexity actually lives 7:48 - Why this matters — the better question 8:33 - Recap — integration in five points 9:15 - Coming next in Season 2 Key Takeaways: 1. The ERP is the trunk of the tree, not the whole tree. A typical mid-to-large enterprise stack has fifteen to twenty specialist surrounding systems, each doing one thing better than the ERP does. 2. Two families of integration, different trade-offs. Batch is simple and easy to reconcile but up to a day stale; real-time via APIs or events is live but introduces failure modes batch doesn't have. 3. Middleware collapses the integration mesh. Ten systems with point-to-point links is forty-five edges; a hub — iPaaS, ESB, message queue — makes it ten. Every system talks to the hub; the hub handles translation, retries, and audit. 4. One owner per shared field. The system-of-record principle says exactly one system writes any given field; everyone else reads a synchronised copy. The ERP is authoritative for the ledger — not automatically for everything. 5. Integration is routinely a third of the ERP program's budget and a disproportionate share of the risk. It also doesn't end at go-live — every new system added, every upgrade, re-triggers integration work. Budget accordingly. The reframe — when you see an ERP screen in a demo, the most useful question isn't "what does this screen do?" but "what systems feed it, and what systems read from it?" The ERP is one large node in a graph of enterprise applications, and the edges often matter more than the node. Taught by CelesteAI. Like and subscribe to catch the rest of Season 2.