Data Science student with a unique edge: 8 years of enterprise data experience in SAP IS-U & FI-CA. I bridge the gap between deep operational data model, modern AI-ML, RAG/LLM systems, and data engineering.
From seminar projects with industry partners to independent builds — every card links straight to the readme, report, or live demo, so nothing has to be taken on trust.
Weekly parcel-volume forecasting for a major logistics operator — 37 customer-product lines, a 16-week horizon, three years of history. Benchmarked 14 models (naïve, Croston, ARIMA, Holt-Winters, ML, robust shrinkage) under 7-fold rolling time-based validation; matching a model to each line beat the best single global rule by ~14%. Figures withheld for confidentiality.
K-Means trajectory clustering sorting new grocery customers into three archetypes by the shape of their first 23 weeks — including an 11% "fading" cohort worth 6.5× more, with Week 9 as the trigger to act. Part of a wider engagement covering lifecycle segmentation, market-basket analysis and 8-method anomaly detection. Figures withheld for confidentiality.
Multi-dimensional analysis of 8,064 Destatis records (2005–2020, WZ2008) across industry, firm size and time. Found a stable 28.69% mean gross yield and clear economies of scale — firms with 20+ staff reach ~2.3× the labour productivity of micro-operations.
Automated forecast pipeline for Mt Manaslu (8,163 m): pulls Open-Meteo API data, vertically interpolates it onto six climbing bands via geopotential height, checks safety thresholds, and ships twice-daily digests + real-time danger alerts over email / Telegram / SMS. GitHub Actions-scheduled, SQLite-deduplicated, 99 offline tests.
Fine-tuned Microsoft's Phi-3 Mini (3.8B) on a purpose-built 400-pair personal-finance Q&A set using QLoRA (4-bit, LoRA rank-16). Merged the adapter into a standalone 7.6 GB model, containerised it with Docker + FastAPI, and deployed it on GCP Vertex AI behind a multi-turn Gradio chat UI — taken end-to-end from dataset to a live cloud endpoint over 11 deployment iterations.
A modern data-science toolkit, backed by a deep understanding of enterprise data systems.
Grouped by capability.
pandas, NumPy, scikit-learn, statsmodels, SciPy, matplotlib, Streamlit.
Analytical queries, window functions, schema design, pgvector for embedding storage and search.
Statistical modeling, EDA, data visualization, time series forecasting, Monte Carlo, Bayesian application.
Git, Jupyter, VS Code, Linux (intermediate); Docker, FastAPI, ETL, CI/CD (basic).
SAP IS-U & FI-CA master data, MIS reporting, stakeholder reporting, primary point of contact.
Bridging deep enterprise data operations with modern machine learning. Here is the timeline of that transition.
Graduate studies in statistical modelling, machine learning, and data engineering. Seminar projects with industry partners on real operational datasets.
Maintained large-scale enterprise master data in SAP IS-U and FI-CA systems for a state power utility. Ran billing & revenue analysis, compiled MIS reports for senior stakeholders, and supported corporate audits with structured, auditable records.
MCA & BCA in Computer Applications, plus three years tutoring mathematics online for U.S. students. Summarised here rather than listed in full — the focus is the current M.Sc. and the enterprise data work above.
Full pre-2013 history available on request via the contact form.
Open to Werkstudent, internship and full-time data and AI roles. Feel free to reach out using the form or connect with me on LinkedIn.
Teaching a small 3.8-billion-parameter open model to answer personal-finance questions reliably — then shipping it as a live, containerised cloud service rather than leaving it in a notebook.
General-purpose language models are large, expensive to run, and give broad, hedged answers to narrow questions. For a focused use case — everyday personal-finance questions like budgeting, compound interest, credit scores and index funds — a 70B-class model is overkill, and prompting a hosted API gives up control, privacy and cost predictability.
The real challenge isn't the training step most tutorials stop at. It's everything after: evaluating whether the tuned model is actually better, packaging it so it loads correctly outside the notebook, and getting it to survive a managed cloud platform's health checks and weight-loading quirks. A model that works in Colab but dies in a container is not a deliverable.
Take a small, capable open model — Microsoft's Phi-3 Mini (3.8B) — and specialise it to one narrow domain with parameter-efficient fine-tuning, so the result stays cheap to train and small enough to self-host. Then carry it end-to-end: build the dataset, fine-tune with QLoRA, evaluate manually, merge the adapter back into the base weights, wrap it in a Docker + FastAPI inference service, and deploy it on GCP Vertex AI with a Gradio chat front end.
Generated 400 clean question-answer pairs across seven personal-finance sub-topics — Budgeting (70), Index Funds & Investing (80), Credit Scores & Cards (70), Compound Interest (60), Debt Management (50), Emergency Funds (40), Taxes & Retirement (30) — stored as a two-column CSV ready for training.
Loaded Phi-3 Mini in 4-bit quantisation and attached a rank-16 LoRA adapter (Unsloth, PEFT, TRL, BitsAndBytes). Data was formatted into Phi-3's chat template and trained for 3 epochs at learning rate 2e-4, batch size 2 with gradient accumulation 4, on a Colab Pro GPU.
Built a 30-prompt manual evaluation with a 0–2 scoring rubric, used the weak responses to correct the dataset and retrain, then merged the LoRA adapter into the base weights to produce a single 7.6 GB standalone model. Fixed an inference bug where skip_special_tokens=True stripped the <|assistant|> delimiter — decoding only newly generated tokens via outputs[0][input_length:].
Wrapped the model in a Docker + FastAPI server and deployed it on GCP Vertex AI, fronted by a multi-turn Gradio chat UI. Getting a 7.6 GB model to load cleanly on a managed platform took 11 container iterations (v1 → v11).
| Symptom | Root cause | Fix |
|---|---|---|
| Container killed in an invisible restart loop | Synchronous model load blocked Uvicorn, so Vertex AI's health probe timed out | Async startup with run_in_executor — health checks pass immediately while weights load in the background |
| Model refused to initialise | Saved tokenizer_config.json held an invalid tokenizer_class key | Strip the bad key at runtime, with a LlamaTokenizer fallback |
| Generic 500 / weight-shape collision | A duplicate model.safetensors left in the storage bucket | Delete the duplicate before deploy — the two startup fixes only worked once applied together |
The working v11 config pinned torch==2.4.1 and transformers==4.46.3 on a python:3.11-slim image and an n1-highmem-8 (52 GB) machine with low_cpu_mem_usage=True. Final state: model live, answering finance questions correctly.
A multi-dimensional study of 16 years of official German trade statistics (Destatis, WZ2008) — profiling profitability, capital investment, labour productivity, firm-size economies and growth across industries, firm sizes and time.
Germany's economy rests on its Mittelstand and industrial base. Using the official Destatis annual statistics of wholesale and retail trade (WZ2008 classification, aligned with European NACE Rev. 2), this project asks how profitability, capital investment, labour productivity, firm size and firm counts moved across industries and firm-size classes between 2005 and 2020 — a window spanning the 2008 financial crisis, the eurozone debt crisis and the run-up to COVID-19.
The processed dataset holds 8,064 observations, each a unique Year × Economic Activity × Employee-Size-Class combination described by 15 columns — enterprise counts, local units, persons employed, turnover, turnover per enterprise and per person, input of goods, gross capital formation, gross yield ratio and expenditure. From the raw Destatis Excel export the pipeline standardises number formats, handles confidentiality-suppressed cells, harmonises WZ2008 codes and size classes across years, and recomputes the derived ratios. Analysis and visualisation are in Python — pandas, NumPy, matplotlib, seaborn — with reusable functions factored into a utilities module and the full workflow in a Jupyter notebook.
Across 7,857 valid observations the gross yield ratio averages 28.69% (median 29.30%, SD 11.42%), holding in a narrow 27–31% band for 16 years. The one real dip is 2011–2012 (~27%), a lagged echo of the financial crisis, after which it settles back to 28–29% — resilient in aggregate but highly variable firm to firm.
Gross capital formation averages 1.22% of turnover and climbs from ~0.95% in the mid-2000s to ~1.30% by 2020 — a ~27% relative increase, with a time trend explaining ~64% of the variation (R²=0.637). It peaks around 2011–2012 and plateaus at elevated levels after 2016.
Median turnover per person employed rises monotonically with firm size — 1–2, 3–5, 6–19, 20+ — with the largest firms more than doubling the smallest (~2.3×, +131%). A high mean but low median in the smallest class shows a few exceptional micro-operators pulling the average up while most stay modest (charted above).
Firm-size class and turnover per enterprise correlate at r=0.542 — size alone explains ~29% of the variance (R²≈0.29). Each step up in size class adds roughly €8,900 in enterprise turnover; the 20+ class spreads widest, many firms above €1M. Scale is a structural advantage, not a guarantee — within-class variation stays large.
Enterprises and local units both grow ~27% from 2005 to 2020, reaching about 5.2M enterprises and 7.3M local units, but the path is boom-and-bust: expansion to a ~2015 peak (~5.8M / ~8.0M), then sustained decline through 2016–2020. Local units run ~38% above enterprise counts throughout, pointing to many multi-site operators.
An end-to-end, self-running data pipeline that turns a free public weather API into actionable high-altitude safety alerts for Mt Manaslu (8,163 m) — extract, transform, store, decide and deliver, fully automated and fully tested.
On an 8,000 m peak, weather is the difference between a summit and a rescue — but the vertical forecasts climbers rely on are expensive and manually interpreted. The engineering question was infrastructural: can a free public API be turned into a reliable, correctly-interpolated, self-scheduling alerting service that runs a whole season with no server to babysit and no silent failures? This is a monitoring tool, not a go/no-go decision tool — a disclaimer to that effect ships in every message.
Six independent, individually-tested stages wired into one orchestrator (main.py --mode digest|danger|test|status). Everything that can change — altitude bands, thresholds, schedule, channels — lives in config.yaml, never in code.
GFS's ~25 km grid puts Base Camp and the summit in the same cell, so changing lat/lon does nothing — the altitude signal comes from pressure levels (600–300 hPa) interpolated onto each band using that forecast hour's returned geopotential height, not a static table. On build day 350 hPa sat at 8,635 m, not the textbook ~8,100 m; a lookup table would have read the summit's weather 500 m too high.
Wind directions are converted to u/v components before interpolation and recombined after. Averaging degrees directly would turn a steady northerly (359° and 1°) into a southerly — a silent 180° error.
The hourly danger check fingerprints the active hazard set in SQLite: a new or worsening hazard breaks through immediately, an unchanged one repeats only every 12 h, and a single all-clear is sent when red lifts. The fingerprint ignores sub-km/h model wobble, so hourly re-runs never look like fresh hazards.
Rather than dumping conditions, the service scans the 7-day forecast for runs of 6+ consecutive hours where every climbing band is simultaneously green with no precipitation, and reports each window with its worst wind and coldest wind chill.
Every band is graded green / amber / red against configurable limits (wind chill uses the NWS formula, applied only in its valid range — T ≤ 10 °C, V ≥ 4.8 km/h — rather than fabricated outside it):
| Parameter | Green | Amber | Red |
|---|---|---|---|
| Wind speed (climbing band) | < 30 | 30–50 | > 50 km/h |
| Wind gusts (surface) | < 40 | 40–60 | > 60 km/h |
| Wind chill | > −40 | −40 to −50 | < −50 °C |
| Snowfall (24 h) | < 20 | 20–50 | > 50 mm |
| Pressure fall (6 h) | < 3 | 3–6 | > 6 hPa |
| CAPE | < 100 | 100–500 | > 500 J/kg |
The service runs entirely on GitHub Actions — four scheduled workflows (twice-daily digest at 01:00 / 13:00 UTC, hourly danger check, a keepalive, and the test suite), with systemd units as a self-hosted alternative. 99 fully-offline tests run in CI against a captured Open-Meteo response, covering wind-vector round-trips and the 359°/1° wrap, geopotential bracketing, wind chill against NWS reference values, threshold boundaries, summit-window splitting, alert de-duplication and the SMS segment budget. A preflight script scans the tree and git history for leaked secrets before the repo goes public; recipients resolve from environment variables and are masked in all logs. Channels ship disabled with console as default, so it runs end-to-end with zero credentials.
Benchmarking 14 forecasting models to predict weekly parcel volumes for a major logistics operator — and showing that matching a model to each customer-product line beats forcing one global rule on all of them.
Confidential project — a TU Dortmund Real World Solution Summit challenge on a major parcel-logistics operator's proprietary weekly volumes, under a data agreement. Absolute volumes are withheld; percentages, ratios and model results are exact. The code is private.
Customers often report their expected volumes too late, yet the operator has to plan staff, trucks, sorting machines and network capacity in advance. Over-capacity wastes money; under-capacity causes delays and parcel backlogs — a direct cost/time/quality trade-off. The goal: a reliable early forecast of weekly parcel volumes that supports operational planning before customers announce.
37 active customer-product lines (20 customers × 2 products), weekly from 2023–2025, with no missing values. Two EDA findings shaped the whole approach. First, demand is heavy-tailed and concentrated: a handful of huge orders dominate (mean far above median), Product A is 63% of volume vs B's 37%, and the top 10 lines carry ~62% of all volume — so robustness to spikes matters more than model complexity, and a mild ~3%/yr downward trend runs underneath. Second, within a customer, Products A and B are statistically independent (p > 0.05, robust across timescales and under multiple-testing correction) — most customers are specialists — which justifies modelling each line on its own. My contributions centred on the EDA and the per-line (customer-based) modelling.
Strictly time-based, with no look-ahead: models train only on data available at the forecast date. The main split trains on two years (~87%) and tests the next 16 weeks (~13%), repeated over 7 rolling start weeks so the score doesn't hinge on one split. Everything is scored on mean absolute error — lower is better — with 14 candidate models compared.
Test all 14 models on the pooled data and keep the single best rule for every line. The winner was a spike-robust shrinkage rule — forecast = [0.5 × last year's same week + 0.5 × trimmed-mean level] × 0.97 — blending the yearly pattern with a spike-ignoring average and baking in the ~3%/yr decline. It beat copy-last-year, ARIMA, Holt-Winters and ML on average, but one rule can't fit all 37 lines equally.
For each line, pick the lowest-validation-error model from the same 14-model pool. There was no single winner — the best model varied by line, spread across flat-level, Croston (intermittent demand), shrink-to-trimmed, Easter-aligned, ARIMA, two-year-average, Holt-Winters and ML. Volatile and intermittent lines favoured robust / intermittent-demand models; stable lines favoured smooth ones.
Matching a model to each customer-product line cut mean absolute error by ~14% over the best single global rule — the core recommendation: don't force one model on all 37 lines, tailor it. The delivered 16-week forecast came in about 3% below last year (0.97×), in line with the underlying trend, as a 37 × 16 = 592-row deliverable.
A four-part analytics engagement for an Online Grocery retailer — segmenting new customers by onboarding behaviour, profiling them by lifecycle value, mining co-purchase baskets, and auditing the data for anomalies with eight independent methods.
Confidential project — built on an Online Grocery retailer's proprietary order and customer data under a data agreement. Customer counts and volumes are withheld or shown approximately; cluster proportions, quality metrics and ratios are exact, and trajectory values are normalised (0–1). The repository is private.
The retailer spent heavily acquiring customers who placed one or two orders and vanished — average deliveries fell 56% from Week 1 to Week 23 — with no visibility into who was leaving or when, and the same generic re-engagement email for everyone. The reframing: don't emit a binary churn label after the fact; cluster customers by the shape of their ordering curve. Each customer's 23-week history was pivoted into a trajectory matrix and per-row min-max normalised (shape, not volume); K-Means with K chosen across five metrics (K=3 won four of five) split the base into three archetypes.
The three archetypes each got their own play: Never-activated (~70%) — flat from day one, so low-cost automated reactivation only, no premium budget. Late adopters (~19%) — rising, so light encouragement, don't over-intervene. Early-active, fading (~11%) — strong start, peak at Week 9, then decline, and 6.5× more valuable per head — urgent personalised retention at Week 9, the highest-ROI play. The business case: budget was being wasted on the 70% who never activated while the valuable 11% were under-served.
A second clustering view segmented customers on standard-scaled behavioural and lifecycle features (order frequency, basket size, tenure) to separate high-value loyal shoppers from occasional and at-risk ones — the volume-and-value complement to the shape-based drop-off view.
Clustered the ~2,000-article catalogue by co-purchase similarity (cosine over basket-level co-occurrence), reduced via PCA and grouped with K-Means at k=8 — which cut the "undifferentiated" bucket from ~51% of articles to ~29% and surfaced a distinct dairy-forward segment alongside fresh-produce and frozen/ready-meal groups. Turned into actions: co-locate frequently co-ordered items in the fulfilment centre to cut picker travel, build themed app collections ("weeknight dinner essentials"), and a one-tap "reorder your usual dairy" prompt for habitual buys.
An eight-method audit over ~2.3M order lines (~19k customers), deliberately using independent methods rather than one blanket rule so each catches a different failure mode: referential-integrity checks, IQR and MAD quantity outliers (cross-checked — and they disagreed on most flags, a useful caution against trusting either alone), Isolation Forest and LOF behavioural detectors (~1% of customers flagged, with near-zero overlap between the two), a delisted-article business rule, and inter-purchase timing. Illustrative finds: a potted-basil line running ~40× the catalogue's low-quality baseline (still ~13× against vegetables only), and tens of thousands of same-day duplicate orders.
Einem kleinen Open-Source-Modell mit 3,8 Milliarden Parametern beibringen, Finanzfragen zuverlässig zu beantworten – und es dann als Live-Cloud-Dienst bereitzustellen, anstatt es in einem Notebook zu belassen.
Allgemeine Sprachmodelle sind groß, teuer im Betrieb und geben breite, vorsichtige Antworten auf enge Fragen. Für einen fokussierten Anwendungsfall – alltägliche Finanzfragen wie Budgetierung, Zinseszins, Kreditwürdigkeit und Indexfonds – ist ein Modell der 70B-Klasse überdimensioniert, und die Nutzung einer gehosteten API kostet Kontrolle, Privatsphäre und Kostenplanbarkeit.
Die eigentliche Herausforderung ist nicht der Trainingsschritt, bei dem die meisten Tutorials aufhören. Es ist alles danach: zu bewerten, ob das abgestimmte Modell tatsächlich besser ist, es so zu verpacken, dass es außerhalb des Notebooks korrekt lädt, und es dazu zu bringen, die Gesundheitsprüfungen und Gewichtungslade-Eigenheiten einer verwalteten Cloud-Plattform zu überstehen. Ein Modell, das in Colab funktioniert, aber in einem Container stirbt, ist kein Deliverable.
Nehmen Sie ein kleines, leistungsfähiges Open-Source-Modell – Microsofts Phi-3 Mini (3,8B) – und spezialisieren Sie es mit parameter-effizientem Fine-Tuning auf eine einzige Domäne, damit das Ergebnis kostengünstig zu trainieren und klein genug für das Self-Hosting bleibt. Dann Ende-zu-Ende durchziehen: Datensatz erstellen, mit QLoRA feinabstimmen, manuell evaluieren, den Adapter wieder in die Basisgewichte zusammenführen, in einen Docker + FastAPI Inferenzdienst einpacken und auf GCP Vertex AI mit einem Gradio-Chat-Frontend deployen.
Generierte 400 saubere Frage-Antwort-Paare aus sieben Finanz-Subthemen – Budgetierung (70), Indexfonds & Investieren (80), Kreditwürdigkeit & Karten (70), Zinseszins (60), Schuldenmanagement (50), Notfallfonds (40), Steuern & Ruhestand (30) – gespeichert als zweispaltige CSV, bereit für das Training.
Lud Phi-3 Mini in 4-Bit-Quantisierung und befestigte einen Rank-16 LoRA-Adapter (Unsloth, PEFT, TRL, BitsAndBytes). Die Daten wurden in Phi-3s Chat-Template formatiert und für 3 Epochen mit einer Lernrate von 2e-4, Batch-Größe 2 mit Gradient Accumulation 4, auf einer Colab Pro GPU trainiert.
Baute eine manuelle 30-Prompt-Evaluierung mit einer 0–2 Bewertungsskala, nutzte die schwachen Antworten zur Korrektur des Datensatzes und trainierte erneut, dann führte ich den LoRA-Adapter mit den Basisgewichten zusammen, um ein einziges eigenständiges 7,6-GB-Modell zu erstellen. Behob einen Inferenz-Bug, bei dem skip_special_tokens=True das <|assistant|> Trennzeichen entfernte – dekodierte nur neu generierte Tokens über outputs[0][input_length:].
Verpackte das Modell in einen Docker + FastAPI-Server und deployte es auf GCP Vertex AI, fronted durch eine mehrstufige Gradio-Chat-UI. Ein 7,6-GB-Modell sauber auf einer verwalteten Plattform zu laden, dauerte 11 Container-Iterationen (v1 → v11).
| Symptom | Grundursache | Lösung |
|---|---|---|
| Container in einer unsichtbaren Neustartschleife getötet | Synchrones Laden des Modells blockierte Uvicorn, sodass der Gesundheitscheck von Vertex AI fehlschlug | Asynchroner Start mit run_in_executor – Gesundheitschecks bestehen sofort, während Gewichte im Hintergrund laden |
| Modell weigerte sich zu initialisieren | Gespeicherte tokenizer_config.json enthielt einen ungültigen tokenizer_class Schlüssel | Entfernen des fehlerhaften Schlüssels zur Laufzeit, mit einem LlamaTokenizer Fallback |
| Generischer 500 / Gewichtungsform-Kollision | Eine doppelte model.safetensors im Storage-Bucket hinterlassen | Löschen des Duplikats vor dem Deploy – die beiden Startkorrekturen funktionierten nur, wenn sie zusammen angewendet wurden |
Die funktionierende v11-Konfiguration pinnte torch==2.4.1 und transformers==4.46.3 auf einem python:3.11-slim Image und einer n1-highmem-8 (52 GB) Maschine mit low_cpu_mem_usage=True. Endzustand: Modell live, beantwortet Finanzfragen korrekt.
Eine mehrdimensionale Studie über 16 Jahre offizieller deutscher Handelsstatistiken (Destatis, WZ2008) – Profilierung von Rentabilität, Investitionen, Arbeitsproduktivität, Größenvorteilen und Wachstum über Branchen, Unternehmensgrößen und Zeit hinweg.
Deutschlands Wirtschaft ruht auf seinem Mittelstand und seiner Industriebasis. Unter Verwendung der offiziellen Destatis-Jahresstatistik des Groß- und Einzelhandels (WZ2008-Klassifikation, abgestimmt auf die europäische NACE Rev. 2) fragt dieses Projekt, wie sich Rentabilität, Kapitalinvestitionen, Arbeitsproduktivität, Unternehmensgröße und Unternehmensanzahl zwischen 2005 und 2020 über Branchen und Größenklassen hinweg verändert haben – ein Zeitfenster, das die Finanzkrise 2008, die Euro-Schuldenkrise und die Zeit vor COVID-19 umfasst.
Der verarbeitete Datensatz enthält 8.064 Beobachtungen, jeweils eine eindeutige Kombination aus Jahr × Wirtschaftstätigkeit × Mitarbeitergrößenklasse, beschrieben durch 15 Spalten – Unternehmensanzahl, lokale Einheiten, Beschäftigte, Umsatz, Umsatz pro Unternehmen und pro Person, Wareneinsatz, Bruttoanlageinvestitionen, Bruttorendite und Ausgaben. Aus dem rohen Destatis-Excel-Export standardisiert die Pipeline Zahlenformate, behandelt geheim gehaltene Zellen, harmonisiert WZ2008-Codes und Größenklassen über die Jahre und berechnet die abgeleiteten Kennzahlen neu. Analyse und Visualisierung erfolgen in Python – pandas, NumPy, matplotlib, seaborn – mit wiederverwendbaren Funktionen in einem Utilities-Modul und dem vollständigen Workflow in einem Jupyter Notebook.
Über 7.857 gültige Beobachtungen liegt die Bruttorendite im Durchschnitt bei 28,69% (Median 29,30%, SD 11,42%) und hält sich 16 Jahre lang in einem engen Band von 27–31%. Der einzige echte Einbruch ist 2011–2012 (~27%), ein verzögertes Echo der Finanzkrise, danach pendelt es sich wieder auf 28–29% ein – widerstandsfähig in der Aggregation, aber von Firma zu Firma sehr variabel.
Die Bruttoanlageinvestitionen machen durchschnittlich 1,22% des Umsatzes aus und steigen von ~0,95% Mitte der 2000er auf ~1,30% bis 2020 – ein relativer Anstieg von ~27%, wobei ein Zeittrend ~64% der Variation erklärt (R²=0.637). Sie erreichen ihren Höhepunkt um 2011–2012 und stagnieren nach 2016 auf erhöhtem Niveau.
Der Median-Umsatz pro Beschäftigtem steigt monoton mit der Unternehmensgröße – 1–2, 3–5, 6–19, 20+ – wobei die größten Firmen die kleinsten mehr als verdoppeln (~2,3×, +131%). Ein hoher Mittelwert, aber ein niedriger Median in der kleinsten Klasse zeigt, dass einige außergewöhnliche Mikrobetriebe den Durchschnitt nach oben ziehen, während die meisten bescheiden bleiben.
Unternehmensgrößenklasse und Umsatz pro Unternehmen korrelieren mit r=0.542 – allein die Größe erklärt ~29% der Varianz (R²≈0.29). Jede Stufe in der Größenklasse fügt grob 8.900 € Unternehmensumsatz hinzu; die 20+-Klasse streut am weitesten, viele Firmen über 1 Mio. €. Größe ist ein struktureller Vorteil, keine Garantie – die Variation innerhalb der Klasse bleibt groß.
Unternehmen und lokale Einheiten wachsen von 2005 bis 2020 beide um ~27% und erreichen etwa 5,2 Mio. Unternehmen und 7,3 Mio. lokale Einheiten, aber der Weg ist Boom-and-Bust: Expansion zu einem Höhepunkt um 2015 (~5,8 Mio. / ~8,0 Mio.), dann anhaltender Rückgang durch 2016–2020. Lokale Einheiten liegen durchweg ~38% über den Unternehmenszahlen, was auf viele Mehrstandortbetreiber hindeutet.
Eine vollautomatische Datenpipeline, die eine kostenlose öffentliche Wetter-API in umsetzbare Höhenwarnungen für den Mt. Manaslu (8.163 m) verwandelt – extrahieren, transformieren, speichern, entscheiden und liefern, voll automatisiert und getestet.
Auf einem 8.000 m hohen Gipfel ist das Wetter der Unterschied zwischen einem Gipfelsieg und einer Rettung – aber die vertikalen Prognosen, auf die sich Kletterer verlassen, sind teuer und werden manuell interpretiert. Die technische Frage war infrastruktureller Natur: Kann eine kostenlose öffentliche API in einen zuverlässigen, korrekt interpolierten, selbst planenden Alarmierungsdienst verwandelt werden, der eine ganze Saison ohne Serverbetreuung und ohne stille Fehler läuft? Dies ist ein Überwachungstool, kein Go/No-Go-Entscheidungstool – ein entsprechender Haftungsausschluss wird in jeder Nachricht mitgeliefert.
Sechs unabhängige, einzeln getestete Stufen, verdrahtet in einen Orchestrator (main.py --mode digest|danger|test|status). Alles, was sich ändern kann – Höhenbänder, Schwellenwerte, Zeitplan, Kanäle – lebt in config.yaml, niemals im Code.
Das ~25 km Grid von GFS legt Base Camp und Gipfel in dieselbe Zelle, sodass eine Änderung des Längengrads nichts bewirkt – das Höhensignal kommt von Druckniveaus (600–300 hPa), die auf jedes Band unter Verwendung der für diese Prognosestunde zurückgegebenen geopotentiellen Höhe interpoliert werden, nicht aus einer statischen Tabelle. Am Tag des Builds lag 350 hPa bei 8.635 m, nicht bei den Lehrbuch-~8.100 m; eine Lookup-Tabelle hätte das Wetter des Gipfels 500 m zu hoch abgelesen.
Windrichtungen werden vor der Interpolation in u/v-Komponenten umgewandelt und danach wieder kombiniert. Das direkte Mitteln von Graden würde einen stetigen Nordwind (359° und 1°) in einen Südwind verwandeln – ein stiller 180°-Fehler.
Der stündliche Gefahrencheck fingerprinted die aktive Gefahrenmenge in SQLite: Eine neue oder sich verschlimmernde Gefahr bricht sofort durch, eine unveränderte wiederholt sich nur alle 12 Stunden, und ein einziges "Alles klar" wird gesendet, wenn Rot aufgehoben wird. Der Fingerprint ignoriert Modellschwankungen im Sub-km/h-Bereich, sodass stündliche Wiederholungsläufe niemals als frische Gefahren erscheinen.
Anstatt Bedingungen auszuspucken, scannt der Dienst die 7-Tage-Prognose nach Läufen von 6+ aufeinanderfolgenden Stunden, in denen jedes Kletterband gleichzeitig grün ist und kein Niederschlag fällt, und meldet jedes Fenster mit seinem schlechtesten Wind und der kältesten Windchill.
Jedes Band wird als Grün / Gelb / Rot gegen konfigurierbare Grenzwerte eingestuft (Windchill verwendet die NWS-Formel, die nur in ihrem gültigen Bereich angewendet wird – T ≤ 10 °C, V ≥ 4,8 km/h – anstatt außerhalb davon fabriziert zu werden):
| Parameter | Grün | Gelb | Rot |
|---|---|---|---|
| Windgeschwindigkeit (Kletterband) | < 30 | 30–50 | > 50 km/h |
| Windböen (Oberfläche) | < 40 | 40–60 | > 60 km/h |
| Windchill | > −40 | −40 bis −50 | < −50 °C |
| Schneefall (24 h) | < 20 | 20–50 | > 50 mm |
| Druckabfall (6 h) | < 3 | 3–6 | > 6 hPa |
| CAPE | < 100 | 100–500 | > 500 J/kg |
Der Dienst läuft vollständig auf GitHub Actions – vier geplante Workflows (zweimal täglich Digest um 01:00 / 13:00 UTC, stündlicher Gefahrencheck, ein Keepalive und die Test-Suite), mit systemd-Units als selbst gehostete Alternative. 99 vollständig offline Tests laufen in CI gegen eine aufgezeichnete Open-Meteo-Antwort und decken Wind-Vektor-Roundtrips und den 359°/1°-Wrap, Geopotential-Bracketing, Windchill gegen NWS-Referenzwerte, Schwellengrenzen, Summit-Window-Splitting, Alarm-De-Duplizierung und das SMS-Segmentbudget ab. Ein Preflight-Skript scannt den Tree und die Git-History nach geleakten Secrets, bevor das Repo öffentlich geht; Empfänger werden aus Umgebungsvariablen aufgelöst und in allen Logs maskiert. Kanäle werden mit console als Standard deaktiviert ausgeliefert, sodass es Ende-zu-Ende ohne Anmeldeinformationen läuft.
Benchmarking von 14 Prognosemodellen zur Vorhersage wöchentlicher Paketvolumina für einen großen Logistikdienstleister – und der Nachweis, dass die Anpassung eines Modells an jede Kunden-Produkt-Linie die erzwungene Verwendung einer globalen Regel schlägt.
Vertrauliches Projekt – eine TU Dortmund Real World Solution Summit Challenge zu den proprietären Wochenvolumina eines großen Paketlogistikers im Rahmen einer Datenvereinbarung. Absolute Volumina werden zurückgehalten; Prozentsätze, Verhältnisse und Modellergebnisse sind exakt. Der Code ist privat.
Kunden melden ihre erwarteten Volumina oft zu spät, aber der Betreiber muss Personal, LKWs, Sortiermaschinen und Netzkapazitäten im Voraus planen. Überkapazität kostet Geld; Unterkapazität führt zu Verzögerungen und Paketstaus – ein direkter Kosten-/Zeit-/Qualitätskompromiss. Das Ziel: eine zuverlässige frühe Prognose der wöchentlichen Paketvolumina, die die operative Planung unterstützt, bevor Kunden ihre Volumina ankündigen.
37 aktive Kunden-Produkt-Linien (20 Kunden × 2 Produkte), wöchentlich von 2023–2025, ohne fehlende Werte. Zwei EDA-Erkenntnisse prägten den gesamten Ansatz. Erstens ist die Nachfrage heavy-tailed und konzentriert: Eine Handvoll riesiger Bestellungen dominiert (Mittelwert weit über dem Median), Produkt A macht 63% des Volumens aus vs. B's 37%, und die Top 10 Linien tragen ~62% des Gesamtvolumens – daher ist Robustheit gegenüber Spitzen wichtiger als Modellkomplexität, und ein milder Abwärtstrend von ~3%/Jahr läuft darunter. Zweitens sind innerhalb eines Kunden die Produkte A und B statistisch unabhängig (p > 0.05, robust über Zeitskalen und unter Multi-Testing-Korrektur) – die meisten Kunden sind Spezialisten – was die Modellierung jeder Linie rechtfertigt.
Streng zeitbasiert, ohne Look-Ahead: Modelle trainieren nur mit Daten, die zum Prognosezeitpunkt verfügbar sind. Der Haupt-Split trainiert auf zwei Jahren (~87%) und testet die nächsten 16 Wochen (~13%), wiederholt über 7 rollierende Startwochen, sodass die Punktzahl nicht von einem Split abhängt. Alles wird anhand des mittleren absoluten Fehlers bewertet – niedriger ist besser – wobei 14 Kandidatenmodelle verglichen werden.
Testen Sie alle 14 Modelle auf den gepoolten Daten und behalten Sie die einzige beste Regel für jede Linie. Der Gewinner war eine spitzennrobuste Shrinkage-Regel – Prognose = [0.5 × Vorjahreswoche + 0.5 × getrimmtes Mittel] × 0.97 – die das Jahresmuster mit einem spitzenignorierenden Durchschnitt vermischt und den Rückgang von ~3%/Jahr einbackt. Sie schlug Copy-Last-Year, ARIMA, Holt-Winters und ML im Durchschnitt, aber eine Regel kann nicht alle 37 Linien gleich gut abdecken.
Wählen Sie für jede Linie das Modell mit dem niedrigsten Validierungsfehler aus demselben 14-Modell-Pool. Es gab keinen einzigen Gewinner – das beste Modell variierte je nach Linie und verteilte sich auf Flat-Level, Croston (intermittierende Nachfrage), Shrink-to-Trimmed, Easter-Aligned, ARIMA, Two-Year-Average, Holt-Winters und ML. Volatile und intermittierende Linien bevorzugten robuste / intermittierende Nachfragemodelle; stabile Linien bevorzugten glatte.
Die Anpassung eines Modells an jede Kunden-Produkt-Linie senkte den mittleren absoluten Fehler um ~14% gegenüber der besten einzelnen globalen Regel – die Kernempfehlung: Zwingen Sie nicht allen 37 Linien ein Modell auf, sondern passen Sie es an. Die gelieferte 16-Wochen-Prognose lag etwa 3% unter dem Vorjahr (0,97×), im Einklang mit dem zugrunde liegenden Trend, als ein 37 × 16 = 592-Zeilen-Deliverable.
Ein vierteiliges Analyseprojekt für einen Online-Lebensmittelhändler – Segmentierung neuer Kunden nach Onboarding-Verhalten, Profilierung nach Lifecycle-Wert, Analyse von Warenkörben und Prüfung der Daten auf Anomalien mit acht unabhängigen Methoden.
Vertrauliches Projekt – basiert auf proprietären Bestell- und Kundendaten eines Online-Lebensmittelhändlers im Rahmen einer Datenvereinbarung. Kundenanzahlen und -volumina werden zurückgehalten oder ungefähr angegeben; Cluster-Anteile, Qualitätsmetriken und Verhältnisse sind exakt, und Trajektorienwerte sind normalisiert (0–1). Das Repository ist privat.
Der Händler investierte stark in die Akquise von Kunden, die ein oder zwei Bestellungen aufgaben und verschwanden – die durchschnittlichen Lieferungen fielen von Woche 1 bis Woche 23 um 56 % – ohne Sicht darauf, wer wann ging, und mit derselben generischen Reaktivierungs-E-Mail für alle. Die Neurahmung: kein binäres Churn-Label im Nachhinein vergeben; Kunden nach der Form ihrer Bestellkurve clustern. Die 23-Wochen-Historie jedes Kunden wurde in eine Trajektorienmatrix überführt und pro Zeile min-max normalisiert (Form, nicht Volumen); K-Means mit K, das über fünf Metriken gewählt wurde (K=3 gewann vier von fünf), teilte die Basis in drei Archetypen.
Die drei Archetypen erhielten jeweils ihre eigene Strategie: Nie aktiviert (~70 %) – von Anfang an flach, also nur kostengünstige automatisierte Reaktivierung, kein Premium-Budget. Späte Adopter (~19 %) – steigend, also leichte Ermutigung, nicht zu stark eingreifen. Früh aktiv, abfallend (~11 %) – starker Start, Höhepunkt in Woche 9, dann Rückgang, und 6,5× wertvoller pro Kopf – dringende personalisierte Bindung in Woche 9, die Strategie mit dem höchsten ROI. Der Business Case: Das Budget wurde für die 70 % verschwendet, die nie aktiviert wurden, während die wertvollen 11 % unterversorgt waren.
Eine zweite Clustering-Ansicht segmentierte Kunden anhand standard-skalierter Verhaltens- und Lifecycle-Merkmale (Bestellhäufigkeit, Warenkorbgröße, Betriebszugehörigkeit), um hochwertige treue Käufer von gelegentlichen und gefährdeten zu trennen – die volumen- und wertbasierte Ergänzung zur formbasierten Drop-off-Ansicht.
Der Katalog mit ~2.000 Artikeln wurde nach Co-Purchase-Ähnlichkeit (Kosinus über Co-Occurrence auf Warenkorbebene) geclustert, via PCA reduziert und mit K-Means bei k=8 gruppiert – was den "undifferenzierten" Anteil von ~51 % der Artikel auf ~29 % senkte und ein deutliches milchproduktorientiertes Segment neben Frischwaren- und Tiefkühl-/Fertiggericht-Gruppen hervorbrachte. In Maßnahmen umgesetzt: häufig zusammen bestellte Artikel im Fulfillment-Center nebeneinander platzieren, um den Kommissionierweg zu verkürzen, thematische App-Kollektionen erstellen ("Wochenend-Dinner-Essentials") und eine Ein-Klick-Aufforderung "Ihre üblichen Milchprodukte nachbestellen" für habituelle Käufe.
Ein Audit mit acht Methoden über ~2,3 Mio. Bestellzeilen (~19.000 Kunden), das bewusst unabhängige Methoden anstelle einer pauschalen Regel verwendete, damit jede einen anderen Fehlermodus abfängt: referenzielle Integritätsprüfungen, IQR- und MAD-Mengen-Ausreißer (gegengeprüft – und sie stimmten bei den meisten Flags nicht überein, eine nützliche Warnung, keiner allein zu vertrauen), Isolation Forest und LOF Verhaltensdetektoren (~1 % der Kunden geflaggt, mit nahezu keiner Überschneidung zwischen beiden), eine Geschäftsregel für delistete Artikel und Kaufzeitpunkt-Abstände. Illustrative Funde: eine Topfbasilikum-Linie mit ~40× dem Niedrigqualitäts-Baseline des Katalogs (immer noch ~13× gegenüber nur Gemüse) und Zehntausende von am selben Tag duplizierten Bestellungen.