Beispielhafte Auswertungen, wie sie in proALPHA- und Power-BI-Projekten typischerweise entstehen, ohne erfundene Kundennamen oder Ergebniszahlen, sondern als fachliche Beschreibung des Vorgehens.
| Ebene 0 | Ebene 1 | Ebene 2 |
|---|---|---|
| Baugruppe A x 1,00 | BSTRohteil-01 x 7,00 Stk | KNorm-102 x 14,00 Stk |
| Halbzeug-110 x 7,00 Stk | ||
| BSTRohteil-02 x 5,00 Stk | KNorm-103 x 10,00 Stk | |
| Halbzeug-111 x 5,00 Stk | ||
| KTeil-136 x 1,00 Stk | ||
| KTeil-250 x 2,00 Stk | ||
| KTeil-401 x 3,00 Stk |
| Artikel | Herkunft | Menge kumuliert | ME |
|---|---|---|---|
| BSTRohteil-01 | Ebene 1 | 7,00 | Stk |
| KNorm-102 | Ebene 2 | 98,00 | Stk |
| Halbzeug-110 | Ebene 2 | 49,00 | Stk |
| BSTRohteil-02 | Ebene 1 | 5,00 | Stk |
| KNorm-103 | Ebene 2 | 50,00 | Stk |
| Halbzeug-111 | Ebene 2 | 25,00 | Stk |
| KTeil-136 | Ebene 1 | 1,00 | Stk |
| KTeil-250 | Ebene 1 | 2,00 | Stk |
| KTeil-401 | Ebene 1 | 3,00 | Stk |
Mehrstufige Stücklisten sind in proALPHA korrekt hinterlegt, aber nur Ebene für Ebene einsehbar. Wie viel von einem Teil insgesamt gebraucht wird oder wo es überall verbaut ist, lässt sich so kaum beantworten.
Ein Power-BI-Report löst die komplette Struktur automatisch auf und zeigt sie in zwei Sichten: als Matrix für die Herkunft und als Tabelle mit den über alle Ebenen kumulierten Mengen.
| Teil | Gruppe | Bedarf | Unterdeckung | Termin | Deckungstyp | Produktionsauftrag | Rückmeldung | Einkaufsbeleg | Position |
|---|---|---|---|---|---|---|---|---|---|
| Artikel A-1042 | Baugruppe | 54,00 | −54,00 | 03.07 | Offen | ||||
| Artikel B-2210 | Kaufteil | 152,00 | −112,00 | 04.07 | Einkauf | 45012 | 20 | ||
| Artikel C-0087 | Eigenfert. | 15,00 | −3,00 | 04.07 | Produktion | FA-33210 | 12 | ||
| Artikel D-3315 | Kaufteil | 67,00 | −67,00 | 05.07 | Offen | ||||
| Artikel E-1190 | Baugruppe | 38,00 | −38,00 | 06.07 | Produktion | FA-33198 | 8 | ||
| Artikel F-4402 | Kaufteil | 28,00 | −20,00 | 06.07 | Einkauf | 45033 | 10 | ||
| Artikel G-2098 | Eigenfert. | 14,00 | −10,00 | 07.07 | Produktion | FA-33245 | 3 | ||
| Artikel H-3170 | Kaufteil | 9,00 | −4,00 | 08.07 | Einkauf | 45041 | 5 | ||
| Artikel I-5541 | Baugruppe | 23,00 | −23,00 | 09.07 | Offen |
Fehlteile entstehen laufend in der Fertigung, doch aus hunderten Einzelpositionen lässt sich kaum ablesen, wie dringend die Lage wirklich ist.
Ein Power-BI-Report verdichtet alle Fehlteile zu einer zentralen Kennzahl mit Verteilung nach Kategorie und Zeitverlauf. Ein Klick öffnet die passende Detailliste.
Offene, abgeschlossene und teilbearbeitete Aufträge werden in unterschiedlichen Auswertungen unterschiedlich dargestellt. Eine verlässliche, mengen- und wertbasierte Sicht auf den aktuellen Auftragsbestand und den zu erwartenden Umsatz fehlt.
Ein zentrales Datenmodell auf Basis von Auftragsköpfen und -positionen führt offene, abgeschlossene und teilbearbeitete Aufträge zusammen, inklusive der Logik für Rahmen- und Abrufaufträge, die sonst leicht doppelt oder gar nicht in den Forecast einfließen. Mengen- und wertbasierte Auswertungen werden mit Liefertermin- und Forecast-Logik verknüpft, sodass Planung und Management dieselbe Datenbasis nutzen.
Informationen zu Artikeln, Lieferanten, Einkaufsbelegen sowie Lieferzeiten und Konditionen sind fachlich korrekt im ERP gepflegt, jedoch historisch gewachsen und über mehrere Tabellen verteilt. Typische Fragen des Einkaufs lassen sich nur mit hohem manuellen Aufwand beantworten.
Ein bidirektionaler Report zeigt sowohl die artikelzentrierte Sicht (welche Lieferanten beliefern diesen Artikel, wie zuverlässig sind sie) als auch die lieferantenzentrierte Sicht (welche Artikel und Warengruppen werden bezogen, wie hoch ist das Einkaufsvolumen). Ergänzt um Lieferantentyp, Standort, historische Liefertreue und Dispositionskennzeichen.
Ein Unternehmen nutzt eine gewachsene Qlik-Sense- oder QlikView-Anwendung, möchte aber aus strategischen Gründen, etwa einer bestehenden Microsoft-Umgebung oder internen Kompetenzen, zu Power BI wechseln. Die fachliche Logik hinter den Kennzahlen steckt oft tief in Ladeskripten und Set-Analysis-Ausdrücken.
Datenmodell, Ladeskripte und Kennzahlenlogik der bestehenden Anwendung werden analysiert und fachlich in ein äquivalentes Power-BI-Datenmodell übersetzt (Power Query, DAX). Die Migration erfolgt schrittweise statt als "Big Bang", sodass alte und neue Kennzahlen parallel verglichen und validiert werden können.
Kennzahlen aus Vertrieb, Einkauf, Produktion und Finanzen liegen in unterschiedlichen Einzelberichten vor. Die Geschäftsführung benötigt eine schnelle, verlässliche Gesamtsicht, ohne sich durch operative Detailtiefe arbeiten zu müssen.
Ein zentrales Management-Dashboard führt bereichsübergreifende KPIs und Trendvergleiche in einer Oberfläche zusammen. Die zugrunde liegenden Kennzahlendefinitionen werden vorab fachlich abgestimmt; bei Bedarf ist ein Drill-Down in die operative Ebene möglich.
Ein gewachsenes Power-BI-Modell funktioniert im Tagesgeschäft, stößt aber an technische Grenzen: Excel-basierte Zuordnungstabellen, keine zentrale Datenhaltung, unklare Skalierung. Das Unternehmen möchte den nächsten Schritt gehen, weiß aber nicht genau, was es extern beauftragen soll.
Das bestehende Modell wird fachlich zurückübersetzt: Tabellen, Kennzahlen (Measures) und Beziehungen werden dokumentiert und zu einem strukturierten Anforderungsdokument für eine Zielarchitektur verdichtet, als Grundlage für den Aufbau eines Data Warehouse oder Lakehouse, z. B. mit Microsoft Fabric.
Ein zentraler Bericht wurde über Jahre in einer gewachsenen Excel-Mappe gepflegt: Daten aus mehreren Quellen werden manuell zusammengetragen, komplexe Formeln versteht meist nur noch eine Person, und jede Aktualisierung ist mit Copy-Paste-Aufwand und Fehlerrisiko verbunden.
Die bestehende Excel-Logik wird analysiert und die relevante Berechnungslogik in ein zentrales Datenmodell übernommen. Datenquellen werden automatisiert angebunden, sodass ein Power-BI-Bericht entsteht, der sich selbst aktualisiert, statt manuell gepflegt zu werden. Excel bleibt dabei ein sinnvolles Werkzeug für Ad-hoc-Analysen, nur nicht mehr für den zentralen Bericht.
Nach einigen Jahren "jeder baut sich sein Dashboard" weiß niemand mehr genau, welche Reports noch aktuell und vertrauenswürdig sind. Statt einer einheitlichen Sicht entsteht ein Datenfriedhof aus Einzellösungen.
Einführung eines strukturierten Anforderungsprozesses für neue Reports, eines zentralen Reports, der alle bestehenden Berichte katalogisiert (Report-Inventory), sowie eines einheitlichen visuellen Erscheinungsbilds für alle Dashboards.