This person is the reason you probably don’t need to hire a data engineering team. They just need a better tool. It’s called dbt, and this article explains it with as little jargon as humanly possible.
The problem dbt solves
Raw data from an ERP or CRM is never directly usable. Before a number is allowed into a report, someone has to remove duplicates, align formats, join tables, calculate KPIs. In most companies today, this work happens in a chain of exports, Excel formulas and copy-paste steps — by hand, every month, with exactly one person who understands the whole chain.
dbt (short for "data build tool") moves precisely this work to one place: into the central database, as traceable, automatically executed steps.
What dbt actually does
Each preparation step is a small SQL file. SQL is the query language for databases — not a programming language in the classic sense, more a very precise way of writing down instructions you already think in Excel terms. "Take all orders, drop the duplicates, sum revenue per customer and month" looks roughly like this in SQL:
select customer_id, month, sum(amount) as revenue
from orders
group by customer_id, monthThat is not a simplified illustration. That’s genuinely it.
These files — dbt calls them "models" — build on one another: raw data becomes cleaned tables, cleaned tables become KPIs. dbt knows the dependencies and runs everything in the right order every night. What used to be the manual month-end process now runs by itself at four in the morning.
The two features that save projects
The truly valuable parts of dbt, though, are two unassuming side features.
First: built-in tests. With a single line you declare that a customer ID must never appear twice, or that revenue must never be negative. dbt checks this on every run and raises an alarm when a source system suddenly delivers nonsense. Data quality goes from gut feeling to a defined, automatically monitored threshold — and the eternal "are these numbers right?" debate finally gets a reliable answer.
Second: automatic documentation. dbt generates a clickable map of which table is built from which. That sounds mundane, but it’s the difference between a project that depends on one person’s memory and one that any successor, freelancer or IT partner can understand within days. We’ve seen handovers that would have failed on exactly this point.
Can your Excel person really learn this?
Honest answer: the fundamentals, yes — and faster than you’d expect. Someone who works confidently with formulas, pivot tables and VLOOKUP typically picks up SQL basics in two to three weeks and dbt basics in another two. What remains genuinely hard, and needs experience, is data modelling — deciding how the overall table landscape is structured. Our usual pattern: the model is designed once with external help; day-to-day operation and expansion stay in-house. Enablement, not dependency.
Core or Cloud?
dbt comes in two flavours. dbt Core is open source and free, but someone has to organise its execution. dbt Cloud costs money and brings a web interface, scheduling and notifications. For companies without their own IT team, the Cloud variant is almost always the right call — the premium is smaller than your first self-inflicted outage.
Where dbt sits in the big picture
For completeness, the whole chain: source systems deliver data, a loading tool brings it into the central database, dbt turns it into clean, tested tables, and on top sit Power BI and — once you’re ready — forecasting models. dbt is the middle piece, and it’s the piece that decides maintainability and trust.
Whether this setup is the right one for you is what our Data Readiness Check tells you in five minutes. And if you already know who your Excel person is: bring them to the first meeting. It’s worth it.