A data warehouse is a central database that brings together data from separate systems — ERP, CRM, production, HR — for reporting, with shared definitions and full history. ETL (extract, transform, load) pulls data from each source, cleans it according to business rules and loads it into the warehouse, so reports run from one source and everyone sees the same number.
Why data ends up scattered
As a company grows, every job gets its own system. Accounting and inventory live in the ERP, quotes in the CRM, orders on the webshop and marketplace portals, production data in the MES, staff records in the HR software. Each system produces data in its own format, on its own schedule, with its own codes.
When a report is needed, the typical routine goes like this: someone exports from each system, stitches the files together in Excel with lookups, and fixes unmatched records by hand. Sales and finance end up with different revenue figures; heavy report queries slow the ERP during working hours; and when someone wants a like-for-like comparison with last year, prices and the organisation chart have long since changed. We set out the way out of this manual routine in moving from Excel reports to BI.
The ERP alone cannot fix this, because it is built to record transactions, not to analyse them. A quote in the CRM, a marketplace order or a downtime event in the MES may never reach the ERP at all.
The cost of leaving it as it is
In Türkiye, most businesses record their data but do not analyse it:
According to TurkStat, in 2025 28.3% of Turkish enterprises with 10+ employees used ERP software, while only 6.5% used business intelligence (BI) software. (TurkStat ICT Usage Survey in Enterprises 2025)
That gap represents companies whose data sits in systems but is never combined for decisions. The cost of scattered data never shows up as a single line item; it surfaces in a wrong report, a delayed decision, stock counted twice. Data quality expert Thomas C. Redman estimates the cost of bad data at 15% to 25% of revenue for most companies, and reckons two-thirds of those costs can be identified and eliminated permanently (MIT Sloan Management Review, "Seizing Opportunity in Data Quality", 2017).
The infrastructure picture is shifting as well. TurkStat reports that 20.2% of Turkish enterprises used paid cloud computing services in 2026 — 57.0% of those with 250+ employees against 16.7% of those with 10-49 (TurkStat ICT Usage Survey in Enterprises 2026). The same survey found that only 15.2% employed ICT specialists. In short, a data warehouse is no longer only for large corporates, but building and running one takes expertise most companies do not have in-house.
Data warehouse and ETL: the building blocks
A warehouse project is made up of several layers:
- Source systems: ERP (Logo, SAP, Mikro, Netsis or bespoke), CRM, e-commerce and marketplace APIs, MES/SCADA, HR and payroll, spreadsheets.
- ETL / ELT processes: extracting data from the source, transforming it according to business rules and loading it into the warehouse. In ELT the raw data is loaded first and transformed inside the warehouse.
- Staging area: where raw data is held temporarily and quality checks run before transformation.
- Warehouse model: a star schema built from fact tables (sales, production, movements) and dimension tables (customer, product, date, branch). It makes reports faster and easier to understand.
- Data marts: subsets of the warehouse focused on one area such as sales, finance or production.
- Data lake: separate storage for high-volume or unstructured data such as sensor streams, log files and images.
- Consumption layer: BI dashboards, reports, AI demand forecasting and other AI models.
ETL, ELT or a direct connection?
| Approach | How it works | Good fit for | Watch out for |
|---|---|---|---|
| Direct reporting connection | The BI tool queries the source database directly | One system, few users, simple reports | Slows the live system; history is not kept |
| ETL | Data is transformed outside the warehouse and loaded clean | On-premises servers, strict data rules | Changing a transformation rule may mean reloading |
| ELT | Raw data is loaded first, transformed inside the warehouse | Cloud warehouses, high data volumes | Access to personal data in raw tables must be controlled |
| CDC (change data capture) | Only changed records are transferred | Frequently updated critical data such as stock and orders | Check that the source database supports it |
In practice most projects mix these: stock and order data moves within minutes via CDC, while finance data is loaded in a nightly batch.
Why keeping history matters
When a customer moves to a different sales rep this year, which rep should last year's sales be credited to? The answer changes your reports. Source systems usually hold only the current state. A warehouse uses a "slowly changing dimension" technique to store old and new values with their dates, so historical figures stay correct when prices, customer accounts or the organisation change.
A data warehouse and ETL project, step by step
- Collect the questions. A warehouse is designed around the business questions it has to answer. List what management, sales, finance and production ask every month and the KPIs they use. We explain how to choose those indicators in BI dashboard KPIs.
- Map the sources. Which data lives in which system and table, how often it changes and who owns it. Parallel lists kept in spreadsheets belong on this map too.
- Write shared definitions. Without a single definition of "net sales", "active customer" or "stock on hand", a warehouse simply moves the old argument into a new database.
- Measure data quality. Duplicate customer accounts, inconsistently coded products and empty mandatory fields are identified before loading. We cover this in detail in data quality and duplicate records.
- Choose the platform. PostgreSQL, MSSQL or cloud warehouses such as BigQuery and Redshift; the choice depends on data volume, existing licences, where personal data must be held and your team's skills. We break down the cloud cost items in cloud migration cost.
- Start with one area. Build one data mart — sales or finance, say — end to end, put the reports in front of users, then expand.
- Automate and monitor. ETL jobs should be scheduled and re-runnable; failed loads should be logged and reported to an owner. An ETL job that stops silently leads to decisions on stale data.
- Plan access and KVKK. Because a warehouse brings many systems' data together, permissions need more care than in the sources. Masking, retention and disposal periods and access logs for personal data are designed from the start, in line with KVKK, Türkiye's Personal Data Protection Law (the local counterpart of GDPR).
How we build it at Digital Bridge
On our data warehouse and ETL integration projects, the setup we deliver includes:
- Scheduled, re-runnable ETL. Data is pulled from the sources at the agreed interval and transformed to your business rules. Failed loads are logged, retried automatically and reported to the owner.
- A central warehouse modelled as a star schema. We choose PostgreSQL, MSSQL or a cloud platform based on your data volume and existing systems, and historical figures are preserved when prices, accounts or the organisation change. For the cloud-versus-on-premises decision our cloud migration and infrastructure consultancy team joins the process.
- Quality checks at load time. Empty fields, duplicate records, format errors and broken references are caught during loading, and faulty records are held back before they reach a report. Where the root cause must be fixed at source, we continue with data governance and quality work.
- CDC transfers that spare the live system. Critical data such as stock and orders arrives within minutes, finance data daily in batch; because only changed records move, the ERP does not slow down.
- Source system connections. We build connectors for Logo, SAP, Mikro, Netsis and bespoke ERPs, CRMs and marketplace APIs, drawing on our system integrations experience.
- Consumption layer. On top of the warehouse we build BI dashboards and models such as demand forecasting analytics, all fed from the same single source.
Operational systems can be sources too. Entry, attendance and canteen records from SmartPass can be exported as reports and loaded alongside ERP data, so headcount and attendance sit next to production and cost figures in the same warehouse.
We do not sell off-the-shelf packages; after a needs analysis we provide a written proposal covering scope, phases and cost.
Next step
Ask yourself three questions. How many systems do you export from to build the management report? Do two departments report the same KPI with different numbers? Can you make a reliable like-for-like comparison with last year? If even one answer bothers you, a warehouse project that starts with a single data area is worth considering. Get in touch and we will map your sources with you and scope the first data mart.