Map the main systems a business runs, such as ERP and CRM, and the data that flows between them.
Why it matters
No new system arrives in an empty room. A new CRM must receive customers from the web shop, send orders to the ERP, and feed the finance reports, while the old systems keep running. Most of the risk in a project sits in those connections. A systems analyst who can draw the whole landscape on one page spots missing interfaces, duplicate data and hidden dependencies before they become late surprises.
The core idea: systems of record
A typical organisation runs a handful of major systems, each the system of record (the authoritative source) for certain data:
| System | What it does | Usually the system of record for |
|---|---|---|
| ERP (Enterprise Resource Planning: SAP, Oracle, Microsoft Dynamics 365, NetSuite) | Finance, purchasing, inventory, manufacturing, order fulfilment | Products, prices, stock, invoices, the general ledger |
| CRM (Customer Relationship Management: Salesforce, Dynamics 365 Sales, HubSpot) | Sales pipeline, marketing, customer service | Customers, contacts, leads, cases |
| HRIS (HR Information System: Workday, BambooHR) | People, payroll, absence | Employees, org structure |
| E-commerce platform | Online catalogue, basket, checkout | Web sessions, carts (orders pass to ERP) |
| Data warehouse / lakehouse | Reporting and analytics | Nothing; it is a copy for analysis |
| Identity provider (Microsoft Entra ID, Okta) | Sign-in and access for staff | User accounts and groups |
The rule that keeps a landscape sane: each data entity has exactly one system of record. Other systems may hold copies, but changes flow from the master. When two systems both think they own the customer's address, you get conflicts that no integration can fix.
Integration styles
How systems exchange data, from oldest to newest:
- File transfer: nightly CSV files over SFTP. Simple and still common; data is up to a day old.
- Shared database: two apps reading the same tables. Fast to build, painful to change; avoid for new work.
- Point-to-point APIs: system A calls system B's API directly. Fine for a few connections, but with many systems the lines multiply into a "spaghetti" diagram.
- Middleware / iPaaS (integration platform as a service, such as MuleSoft, Boomi, Azure Logic Apps): a central hub that transforms and routes messages.
- Event-driven: systems publish events ("order placed") to a message broker, and any interested system subscribes.
The analyst does not usually pick the technology alone, but should record for every interface: source, target, data, trigger, frequency, direction and owner.
Worked example: Harbor Outfitters
Harbor Outfitters sells outdoor gear in 12 stores and online. Today it runs:
- An ERP (NetSuite) for stock, purchasing and finance.
- A Shopify web shop.
- A 15-year-old in-house customer database (Microsoft Access) used by store staff for loyalty points.
- Point-of-sale (POS) tills in each store.
- Spreadsheets for the marketing email list.
The project: replace the customer database and the spreadsheets with a CRM. The analyst's first landscape map, as an interface list:
ID Source Target Data Trigger / frequency
I-01 Web shop ERP Orders Each order (API)
I-02 POS ERP Store sales Nightly file
I-03 POS Cust DB Loyalty points Each sale (shared DB)
I-04 Web shop Cust DB New customers Manual re-keying, weekly
I-05 Cust DB Marketing Email list Monthly export to spreadsheet
I-06 ERP Data wh. Sales, stock Nightly file
Two findings jump out. I-04 is manual re-keying: staff type web customers into the old database, so the CRM project must automate it. I-03 uses a shared database, which will break when the old database is switched off; the POS vendor must be involved early. The future-state map makes the CRM the system of record for customers and loyalty, with I-03, I-04 and I-05 replaced by APIs.
Common mistakes
- Mapping only the systems in scope and missing the ones that feed them.
- Ignoring spreadsheets and manual steps; they are interfaces too, and often the riskiest.
- Two systems of record for the same entity.
- Forgetting non-functional details: volumes, timing, error handling and who gets called when an interface fails.
Quick recap
- Each major system is the system of record for some data; keep exactly one master per entity.
- Interfaces range from nightly files to APIs, middleware and events; record source, target, data, trigger, frequency and owner.
- A landscape map and interface list reveal manual steps and hidden dependencies early.