Data, engineered into systems that improve how you decide.
I design and build the pipelines, statistical models, and machine learning systems behind better business decisions — for organizations from five employees to enterprise data teams. Every engagement is scoped to the problem, not sold off a price list.
A good fit for
Five capabilities I bring to every engagement.
Engagements can draw on one of these or several — most real problems touch more than one.
Data Engineering & Infrastructure
The pipelines and storage that make everything else possible.
- ETL / ELT pipeline design & build
- Warehouse & lakehouse architecture
- Integrating disparate systems
- Data quality & governance
Analytics & Business Intelligence
Turning clean data into numbers people actually use.
- KPI & metrics frameworks
- Reporting automation
- Dashboards & forecasting
- Performance monitoring
Data Science & Statistical Modeling
Answering "why," not just "what," with methods that hold up.
- Applied statistics & causal inference
- Experimentation & A/B testing
- Econometric & behavioral modeling
- Uncertainty-honest forecasting
Machine Learning Systems
Models that run in production, not just in a notebook.
- Predictive modeling for real decisions
- MLOps — deployment & monitoring
- Retraining & drift detection
- NLP / computer vision where it fits
Data Strategy & Fractional Leadership
Direction for organizations that need it before they need a headcount.
- Data maturity assessments
- Roadmaps & build-vs-buy calls
- Fractional Chief Data/Analytics Officer
- Vendor & tooling evaluation
Not sure which of these your problem falls under?
Tell me what you're dealing with — that's my job to sort out, not yours.
The stack behind the five capabilities
What the work actually looks like
# Difference-in-differences: isolate the causal effect
# of the March price change from seasonal drift
model <- lm(
revenue ~ treated * post + factor(month),
data = panel_data
)
tidy(model) |>
filter(term == "treated:post")
#> term estimate std.error p.value
#> treated:post -4.10 1.85 0.031Data Science & Statistical Modeling — the model behind Case 03: separating a real effect from seasonal noise.
-- Standardize inventory events across 5 source
-- systems into one common fact table
with unified_inventory as (
select warehouse_id, sku_id, qty_on_hand, event_ts
from {{ source('erp', 'stock_snapshot') }}
union all
select warehouse_id, sku_id, qty_on_hand, event_ts
from {{ source('wms', 'inventory_events') }}
)
select * from unified_inventory
where event_ts >= current_date - interval '1 day'Data Engineering & Infrastructure — the model behind Case 01: five systems, one fact table.
# Nightly job: score demand, then check for drift
forecast = model.predict(latest_features)
drift_score = ks_2samp(
reference_window, latest_features["units_sold"]
).statistic
if drift_score > DRIFT_THRESHOLD:
alert_team("Demand model drift detected", drift_score)Machine Learning Systems — the monitor behind Case 04: catching drift before it costs you.
Four steps. No surprises on scope.
Discovery
I learn the business problem first, the data second — a short technical and business conversation, not a sales pitch.
Scope
A written proposal: defined deliverables, timeline, and cost. Nothing starts until you know exactly what you're getting.
Build
The engineering, analysis, or modeling work — inside your own environment wherever that's the right call.
Operate or hand off
Fully documented and handed to your team, or supported on an ongoing basis. You choose which.
Analysis you can act on. Systems you can run.
What a lot of data consulting gives you
- A slide deck full of correlations, not causal answers
- A proof-of-concept that never reaches production
- A one-size-fits-all playbook
- A team sized for their margins, not your problem
What I do instead
- Statistically rigorous analysis — causal inference, not just correlation
- Production-grade pipelines and ML systems, not prototypes
- Scoped to the actual problem, sized to match
- Direct access to me — the person doing the work
One illustrative case for each of the five capabilities.
Chosen to show the range — engineering-only, analytics-only, and the full path through statistics and ML.
One view of inventory, out of five disconnected systems
Inventory, sales, and freight data lived across an ERP, a warehouse management system, a legacy Access database, and spreadsheets. No one could see stock across all six warehouses on the same day — every cross-location view was rebuilt by hand.
I built automated ingestion pipelines from all five sources into a single warehouse, with a common data model for SKU, location, and inventory movement, plus validation rules to catch mismatched SKU codes between systems before they reached a report.
Same-day cross-warehouse visibility replaced a 3–5 day manual reconciliation cycle, and the resulting warehouse became the foundation for the forecasting work in Case 04.
A weekly report that surfaced a quoting problem no one had noticed
The owner tracked jobs in one system, invoices in QuickBooks, and ad spend in a third — and spent several hours most weeks manually assembling a picture of the business.
I connected all three sources into one automated weekly report with core KPIs — revenue, margin, quote conversion, marketing lead cost — delivered every Monday with no spreadsheet work required.
The report surfaced a 15-point drop in commercial quote acceptance over two months that had gone unnoticed inside the noise of day-to-day operations, prompting a change to how commercial estimates were priced.
Separating what a price change caused from what would have happened anyway
Revenue dipped the month after a price increase, and leadership wanted to roll it back — but the same month included the usual seasonal slowdown, and no one could say how much of the dip the price change actually caused.
I ran a quasi-experimental comparison between affected and unaffected customer cohorts to isolate the causal effect from seasonality, then layered a survival-based churn model on top to flag which customer segments were actually at elevated risk.
The price change explained a small fraction of the dip, not the feared cause of most of it — the churn model redirected retention budget to the one segment genuinely at risk instead of an across-the-board discount.
Replacing "reorder what we sold last year" with a monitored forecast
Store-level reordering ran on manual rules pinned to last year's sales, causing chronic overstock on slow SKUs and stockouts on fast movers whenever local trends or promotions shifted.
I built a demand forecasting model incorporating seasonality, local trend, and promotional calendars, deployed with a monthly retraining schedule and automated drift alerts rather than a one-time model handoff.
Stockouts on top-selling SKUs dropped meaningfully within two quarters, and the retraining pipeline keeps the model current as store-level patterns shift — the system, not a point-in-time model, was the deliverable.
Answering "what kind of data hire do we actually need?" before making one
Leadership knew they needed "someone in data" but not which role — a mis-hire risked bringing in an analyst with nothing usable to analyze, since the underlying data was never centralized in the first place.
I ran a data maturity assessment across existing systems, current reporting practices, and the board's actual near-term questions, then delivered a 12-month roadmap sequencing infrastructure work ahead of any analytical hire.
The roadmap specified a data engineer as the correct first hire, not the analyst originally planned — avoiding a hire who would have had no reliable data to work with for months.
Grounded in a few sectors, not spread thin across all of them
Sized to the organization, not the other way around.
Businesses that have outgrown spreadsheets but aren't ready to hire a data team.
Operators with real data volume and real decisions riding on it, without deep in-house data science bench.
Data teams that need specialized capacity — a causal question, a stalled ML system, a pipeline no one owns.
I also support government and public-sector work, most often as a subcontractor delivering data science, analytics, or ML capacity to an established prime. If you're a prime or agency exploring that, reach out directly.
Data Science · Analytics · Engineering
Hi, I'm Osei — the data scientist, analyst, and engineer behind Managed Analytics. My training sits at an intersection most data people don't come from: an M.S. in Social Data Science from Arizona State University, paired with an M.A. in Anthropology from Northern Arizona University. One degree built for statistical rigor. The other built for understanding why people actually behave the way the data says they do.
That combination is the point. Most people can run a regression; far fewer have been formally trained to question what the numbers are really capturing, or to notice when a clean statistical result is quietly papering over a messier human reality. I bring both — plus 10+ years turning research, survey, government, and administrative data into reports, models, and systems that hold up to scrutiny.
In practice, that means R, Python, SQL, and SAS for the technical work, and a research background in study design, survey methodology, and qualitative analysis to make sure the technical work is asking the right question in the first place.
- M.S. Social Data Science — Arizona State University2026
- M.A. Anthropology — Northern Arizona University2023
- B.A. Economics & Anthropology — University of Cape Coast, Ghana2019
Questions worth answering upfront
What size of organization do you work with?
Anywhere from a five-person business to an enterprise data team looking for specialized capacity. The engagement shape changes; the underlying work doesn't.
How is this different from just hiring a data analyst?
An analyst answers questions inside the tools you already have. I also build the infrastructure and models that make new questions answerable in the first place — pipelines, statistical rigor, and production ML, not just a faster spreadsheet.
How is a project priced?
Every engagement is scoped individually after a discovery conversation — cost depends on complexity, timeline, and what you already have in place. There's no published price list because there's no standard project.
What does a first engagement typically look like?
Most relationships start with a single well-defined project — a pipeline, an analysis, or an assessment — rather than an open-ended retainer. It's the fastest way for both sides to see if the fit is right before anything ongoing is discussed.
Do you deliver a model, or a working system?
A working system, by default. A model that isn't deployed, monitored, and retrained on a real schedule isn't done — that's the difference between a data science exercise and a machine learning system.
Can you take on data engineering work without analysis or ML attached?
Yes. Pipelines, warehousing, and integration work stand on their own — plenty of engagements are exactly that, especially as a first phase before any modeling makes sense.
Do you work on-site or remotely?
Remotely by default, inside your own cloud or data environment wherever possible. On-site work can be arranged when it genuinely speeds things up.
Will you work under our security and confidentiality requirements?
Yes — NDAs, data handling agreements, and access scoped to exactly what a project requires are standard, not an exception. Tell me your requirements during scoping and they'll be reflected in the proposal.
Do you take on government contracting work?
Yes — most often as a subcontractor to an established prime rather than a direct prime contract. If you're a prime contractor or agency evaluating data science, analytics, or ML capacity, get in touch directly to discuss fit.
Tell me about the problem you're trying to solve.
No pricing to navigate — a couple of details, then straight to picking a time to talk.