DWH + BI für einen Schweizer Pharma-Mandanten

Ausgangslage

Ein Schweizer Pharma-Distributions-Mandant betreibt mehrere Geschäftsbereiche mit eigenen Produkten und unterschiedlichen Distributionspartnern (Wholesaler, Direktkunden, Logistik-Anbieter). Die operativen Daten — Verkaufstransaktionen, offene Bestellungen, Materialbewegungen, Lager­bestände, Stock-Notifications, Retouren — kamen aus mehreren Quellsystemen als CSV-Reports per E-Mail, in unterschiedlichen Frequenzen und Formaten. Die Auswertung erfolgte manuell in Excel, mit den üblichen Konsequenzen: Versionschaos, lange Antwortzeiten auf Management-Fragen, keine durchgängige Historie.

Aufgabe

Eine integrierte, langfristig wartbare Daten- und BI-Plattform aufbauen, die

• alle relevanten Distributions-Reports automatisch ingestiert,
• sie strukturiert in einer Datenbank persistiert,
• nachvollziehbare Historie über mehrere Jahre erlaubt,
• und sie über eine moderne Web-Anwendung den Geschäftsbereichs-Verantwortlichen direkt zugänglich macht — mit Sales Explorer, Stock Viewer, Open Orders und Dashboard-Widgets.

Das Ganze als Solvia-Eigenentwicklung, ohne SaaS-Drittanbieter, im Tenant des Mandanten.

Komponenten

Die Lösung besteht heute aus zwei eigenständigen, aber miteinander verzahnten Solvia-Projekten:

1. Daten-Warehouse-Pipeline (Backend)

Eine ETL-Pipeline in .NET 10, aufgeteilt in mehrere unabhängig deploybare Komponenten:

Komponente	Aufgabe
MailFactory	Holt die Reports automatisch aus dem Microsoft-365-Postfach des Mandanten via Microsoft Graph API.
CsvToXmlAdapter	Transformiert die CSV-Reports in ein einheitliches XML-Format mit Schema-Validierung.
XmlToRest	Übergibt die strukturierten Daten an die zentrale REST-API.
RestApi	Validiert, persistiert und stellt die Daten als REST-Endpunkte für Drittanwendungen zur Verfügung (SQL Server als Persistenz-Schicht).
Common	Geteilte Entitäten und Services für alle Komponenten.
HistoricalBackfill	Einmal-Loader für die Bulk-Ingestion historischer Reports.

Unterstützt werden sechs Report-Typen mit insgesamt mehreren hundert Eigenschaften pro Entität — von Sales-Transaktionen (rund 256 Properties pro Datensatz) bis zu Stock- und Retour-Daten.

2. Business Planner (Frontend)

Eine eigenständige Blazor-Web-Anwendung als BI-Frontend auf der Daten-Warehouse-API:

• Sales Explorer — interaktive Auswertung über Filter, mit Drill-Down von der Produkt-Gruppe auf das einzelne Material.
• Stock Viewer — aktueller Bestand mit Filter-Möglichkeiten und Historie.
• Open Orders — offene Bestellungen pro Geschäftsbereich.
• Dashboard — kumulative YTD-Charts pro Business Unit (Actual vs. Budget vs. IQVIA-Referenzdaten), nach Geschäftslogik des Mandanten ausgerichtet (Budget-Jahr-Granularität statt rollendes 12-Monats-Fenster).
• Saveable Views — Filter-Kombinationen werden als wiederverwendbare „Saved Views” gespeichert; Charts werden als Widget-Konfigurationen auf einem composable Dashboard zusammengestellt.

Die Lösung ist Multi-Tenant ausgelegt (mehrere Geschäftsbereiche pro Mandant mit getrennten Auswertungen) und folgt einem strikten Berechtigungs-Modell.

Vorgehen

Das Projekt ist über mehrere Phasen schrittweise gewachsen, statt als Big-Bang-Migration ausgerollt zu werden:

1. Discovery mit dem CEO und den Bereichs-Verantwortlichen — welche Reports sind kritisch, welche Auswertungen werden täglich/wöchentlich gebraucht, welche Management-Fragen lassen sich heute nicht beantworten.
2. Erste Pipeline für den wichtigsten Report-Typ (Sales-Transaktionen) in Produktion. Sechs Wochen vom Start bis zur ersten produktiven Auswertung.
3. Schrittweise Erweiterung auf die weiteren fünf Report-Typen, jeder mit eigener FEAT-Spezifikation und produktiv geprüft.
4. Frontend-Aufbau als eigenständige Blazor-Anwendung, mit dem CEO als Hauptansprechpartner für UX-Entscheidungen (Cumulative-YTD-Pattern, Entfernung nicht aussagekräftiger Charts, BU-Fokus auf die produktiv genutzten Geschäftsbereiche).
5. Architektur-Refactor (ProductGroup als primäres Auswahl-Element statt Material) — angekündigt, priorisiert, schrittweise umgesetzt.

Alle Entscheidungen sind in einer eigenen PRD- und FEAT-Dokumentation festgehalten.

Ergebnis

• Vollständige Automatisierung der Report-Ingestion. Die manuellen Excel-Routinen sind weggefallen; aktuelle Distributions-Daten stehen morgens nach dem Tagesabschluss der Quellsysteme automatisch zur Verfügung.
• Historische Datenbasis über mehrere Jahre, jederzeit auswertbar — Trend-Analysen, Jahres­vergleiche, ad-hoc-Fragen zu vergangenen Perioden sind in Sekunden möglich.
• Self-Service-Auswertungen für die Geschäfts­bereichs-Verantwortlichen, ohne Wartezeit auf eine zentrale Reporting-Abteilung.
• Stabile Plattform seit mehreren Jahren in Produktion, mit kontinuierlicher Weiter­entwicklung pro Geschäftsanforderung.

Tech-Stack

Bereich	Technologie
Backend-Sprache	.NET 10, C#
Frontend	Blazor (Server)
Datenbank	Microsoft SQL Server
Mail-Ingestion	Microsoft Graph API
Build/Deploy	Eigene PowerShell-Publish-Pipeline
Doku	PRD + FEAT-Specs, Mermaid-Diagramme, Markdown

Was sich daraus ableiten lässt

Ein Daten-Warehouse + BI-Stack dieser Tiefe ist kein Standardprodukt. Er entsteht, wenn ein KMU eine Geschäftslogik hat, die kein Standard-Reporting-Tool sauber abbildet — und einen IT-Partner findet, der die Logik versteht, das Backend baut, das Frontend gestaltet und beides langfristig pflegt. Solche Vorhaben gehören in unsere Software-Entwicklungs-Linie und sind über mehrere Mandate hinweg reproduzierbar.

Verwandte Inhalte

• Case-Study: Komplett-Stack-Betreuung für einen Pharma-Dienstleister — das umgebende IT-Mandat dieses selben Kunden.
• Software-Entwicklung — die Service-Linie, in der solche Vorhaben entstehen.
• Branche Health: Klinik · Pharma · Radiologie — Branchen-Übersicht mit weiteren Kompetenz-Punkten.