Himanshu Laddhad

Building a single data mapping by hand took an estimated three to five weeks. I led a team of five through a nine-week proof of concept: a retrieval-grounded pipeline that drafts new mappings from 400+ existing ones, then a small in-house model set against GPT-4.1. I presented the trade-off to leadership as it was, 68% valid first try against 78%, in exchange for keeping partner data private, rather than claiming parity.

• Cut mapping build time from PartnerLinQ’s estimated 3–5 weeks to 3–4 hours in a proof of concept (POC) by building a RAG pipeline over 400+ existing XSLT mappings, with GPT-4.1 tool-calling and Groq routing.
• Presented the team’s model comparison to PartnerLinQ leadership: a small in-house Qwen model (QLoRA) reached 68% first-try Altova validity against GPT-4.1’s 78%, a trade-off that keeps partner data private.
• Led a team of five over 9 weeks, handing engineers the code, report and a Streamlit test harness to build a chat assistant.

The mandate was open-ended: modernise how the business used its operational data, with no predefined scope. I drew the boundary myself, owning the pipeline and the KPIs built on it rather than claiming ownership of upstream systems I could not enforce. The decision I would defend hardest is that failing rows are set aside under a labelled reason code, never dropped, because a missing record is not a clean record.

• Gave 10+ users one trusted source for four event streams with an automated ETL pipeline on Databricks, replacing manual consolidation.
• Kept KPIs clean without manual runs by running dbt models and tests through Airflow (task dependencies, automatic retries, failure alerts), with failing rows set aside under labelled reason codes.
• Contributed to a ~75% drop in recurring quality exceptions by ranking functions with EDA in Power BI to target engineering fixes.
• Gave engineering and quality the cause behind problems on request, pulling an affected item’s history across the four streams and checking when it began, so fixes were permanent instead of repeat workarounds.
• Saved 20+ hours a week of manual reporting by gathering KPI requirements from 3 cross-functional groups and building the Power BI data model, dashboards and KPI documentation for 9 KPIs, training users along the way.

Planning ran on spreadsheet moving averages fed by a single source, and an earlier attempt to patch it had stalled. My manager handed it to me because I questioned the assumption rather than the tool. I proposed a rebuild instead of a patch, proved it on one product line in a two-week parallel run, and only then asked for full commitment. Later I added a daily dashboard so supply surprises became same-day schedule decisions. When a stale input produced silently wrong forecasts, I flagged it the same day and put freshness checks in front of procurement. The teams that had been most sceptical trusted the system more afterwards.

• Led 3 people in moving forecasting from Excel to an XGBoost model (500+ SKUs), sending slow-moving SKUs to a trailing annual average, cutting forecast error 18% and excess and shortage stock.
• Translated SKU forecasts into monthly demand per component with a Python job, lifting on-time delivery from under 95% to about 98%.
• Turned supply surprises into same-day schedule decisions with a daily production dashboard for the operations and supply chain standup (quality joined when needed): time-by-time plan, status and alerts for every department.
• Instituted freshness checks that stop stale inputs reaching procurement (est. $5K–$20K per incident) and weekly forecast-vs-orders checks.
• Compared scenarios with a linear optimization model in Excel with Analytic Solver to reorder urgent sales orders when shortages left 20% of priority orders unfulfilled; operations reworked that week’s plan, cutting the figure to 8%.

A short, focused internship, and where I first learned that most of the loss in a process concentrates in a handful of exception modes, provided the data is clean enough to rank them honestly.

• Helped the operations team focus fixes where they mattered, projecting a 10% process efficiency gain.
• Ranked 140+ exception categories by frequency using Pareto analysis in Python on 9 months of operational time-series data.
• Supported corrective-action tracking across procurement, quality assurance and operations; the team reported exception frequency down about 90% and reprocessing rate down 14%.