Five complete project blueprints that get people hired — with the exact tech stack, free data sources, architecture and the mistakes that make recruiters close the tab.
Most supply chain analytics portfolios fail for the same reason: they are notebooks full of charts, not projects that change a decision. A recruiter opening your GitHub does not want to see another correlation heatmap of a retail dataset. They want evidence that you can take messy operational data, model it properly, produce a number a planner would actually act on, and explain the limits of what you built.
This guide gives you five project blueprints — each mapped to the four tools that matter in this field: SQL for data modelling, Python for analysis and optimisation, AI for explanation and interaction, and Power BI for the decision layer. Build one properly and you will be ahead of most applicants. Build three and you can hold your own in any supply chain analytics interview.
Every serious supply chain analytics project has the same skeleton. Learn it once and every project becomes a variation.
The most valuable and most requested skill in supply chain analytics. Build this one first.
SQL layer: build weekly aggregates per SKU and location, with promotional flags and calendar attributes joined in. Use window functions for lags and rolling averages at source.
Python layer: engineer lag features (1, 2, 4, 52 weeks), rolling means and standard deviations, calendar features (week of year, month, holidays) and promo indicators. Benchmark in this order — naive, seasonal naive, exponential smoothing, then XGBoost. Use time-series cross-validation, never a random split, or you will leak future data and report an accuracy you cannot reproduce.
AI layer: feed the model's SHAP values to an LLM and generate a plain-language explanation for each large forecast change: "Forecast for SKU-4471 in Pune is up 18% because the promotion flag is active and last year's same-week uplift was 22%."
Power BI layer: forecast vs actual by SKU segment, MAPE and bias trending over time, and an exception list of the worst-performing SKUs this cycle.
Where forecasting shows analytical skill, inventory optimisation shows business judgement — you are trading working capital against service level.
SQL layer: inventory position by SKU-location over time, demand variability, lead time history per supplier.
Python layer: ABC-XYZ segmentation, safety stock with both demand and lead-time variability, then a Monte Carlo simulation comparing your policy against the current one across 1,000 demand scenarios. Report service level achieved and working capital required for each.
AI layer: generate a monthly "inventory health" narrative — which segments are overstocked, which are at risk, what changed since last month.
Power BI layer: the working-capital-versus-service-level frontier, with a slicer that lets a manager pick a target service level and see the inventory investment required.
The Power BI showcase project. Most candidates build dashboards; very few build control towers.
The difference between a dashboard and a control tower: a dashboard reports what happened. A control tower flags what needs action, ranks it by financial impact, and lets you drill from the number to the root cause in two clicks. Build exception logic — "SKUs below safety stock with open demand in the next 7 days" — not just KPI tiles.
Power BI specifics worth learning here: a proper star schema in the model, DAX time-intelligence measures (YoY, rolling 12), drill-through pages, and row-level security if you want to demonstrate enterprise thinking.
The project that proves you can do prescriptive analytics, not just descriptive.
Python layer: model it as a capacitated vehicle routing problem with time windows (CVRPTW) using OR-Tools. Use a real distance matrix — OpenStreetMap via OSRM is free — rather than straight-line distances, because the difference is the whole point.
The number that matters: total distance and cost before versus after optimisation, plus vehicle utilisation. A 9–15% distance reduction against a manually planned baseline is a realistic, defensible result.
The newest and most differentiating project. Very few applicants have built one.
How it actually works: give the model your schema, use it to generate SQL, execute the query in a read-only sandbox, then pass the result back for a plain-language answer. The engineering that matters is the guardrails — schema grounding, query validation, row limits, and refusing to answer when the data cannot support it.
Be honest about limitations in your README. Text-to-SQL is impressive but brittle on ambiguous questions. Showing that you tested it on 30 questions and reporting that it answered 24 correctly — with an analysis of the 6 failures — is far more credible than claiming it works.
You do not need proprietary data to build a serious project.
1. No baseline. Covered above, and it is the most common failure. Without a naive benchmark, your accuracy number means nothing.
2. Random train/test splits on time-series data. This leaks future information into training and produces accuracy you cannot reproduce in production. Always split chronologically.
3. Optimising a metric nobody uses. R² on a demand forecast is almost meaningless to a planner. MAPE, WMAPE, bias and forecast value-add are the language of the field.
4. No business framing. "I built an XGBoost model with 0.87 R²" says nothing. "I cut forecast error 38%, which would release approximately ₹1.2 crore of safety stock at constant service level" says everything.
5. Five shallow projects instead of one deep one. Depth signals capability. One project with proper validation, an AI layer, a dashboard and honest documentation beats five tutorial notebooks.
6. No limitations section. Every model has failure modes. Stating them is the strongest credibility signal you can send, because it proves you understand the model rather than having copied it.
Expect these follow-ups, and prepare for them specifically: How did you validate it? What did you try that did not work? What happens when a new SKU has no history? How would you deploy and monitor this? The last question separates analysts from engineers — mention retraining triggers and drift monitoring even briefly and you will stand out.
Part-time, that is about three weeks. The documentation days are not optional padding — they are what turns a folder of code into something a hiring manager can evaluate in four minutes.
Our Supply Chain Analytics program walks through exactly these projects across 18 live weeks — SQL, Python, Excel and Power BI with AI copilots, on real supply chain data, ending with a portfolio you can show in interviews. The next cohort starts 15 September 2026.
If you want to go further and ship models into production — feature pipelines, MLflow, Docker, FastAPI and drift monitoring — that is the SC ML Engineering & MLOps program.
SQL, Python, Excel and Power BI with AI copilots. 18 live weeks, 110+ hours, real supply chain data — and a portfolio you can show in interviews.
Join supply chain leaders getting practical AI, forecasting, inventory and optimisation playbooks — plus new tools, courses and case studies. No spam, unsubscribe anytime.
📰 Latest from Mathnal Insights
Hormuz closure disrupts 20% oil, 34% helium, 46% urea. Brent +55%, freight +50%. Every route, cost & mitigation quantified.
Issue #9 · ESG & Scope 3EU CSRD fines 5% revenue, UK CMA 10% turnover, 150+ US lawsuits. 6 regulations, 8 warning signs, 6-pillar compliance framework.
Free Tool · Interactive SimulatorBayesian risk engine, 45 scenarios, Monte Carlo simulation, VaR/CVaR — simulate the Hormuz crisis on your supply chain.
View all 10 newsletters → | Free diagnostic tools → | CSCOP Certification →