Ein Datenanalyseprojekt planbar machen und übergeben

Eine gute Analyse beginnt nicht mit einem Diagramm

Die Nordlicht Ersatzteillogistik GmbH beliefert Fahrradwerkstätten. In den letzten Monaten häufen sich teure Expressnachsendungen. Die Bereichsleitung vermutet Fehler bei der Kommissionierung, der Kundenservice vermutet verspätete Bestandskorrekturen und das Lager verweist auf unvollständige Bestellungen.

Der erste Auftrag lautet: “Analysiert unsere Lieferdaten und baut ein Dashboard, damit wir Expresskosten senken.” Das klingt nach einem Ziel. Für eine belastbare Projektplanung ist es noch zu offen. Es fehlt unter anderem, welche Entscheidung das Ergebnis unterstützen soll, welche Kosten betrachtet werden, wer die Daten freigibt und woran die Auftraggeberin eine erfolgreiche Analyse erkennt.

In dieser Lektion machst du aus diesem Wunsch einen ausführbaren Datenanalyseauftrag. Du planst Datenzugang, Arbeitspakete, Qualitäts- und Abnahmekriterien. Danach bereitest du die Übergabe so vor, dass Fachbereich und Betrieb Ergebnis, Grenzen und Entstehungsweg nachvollziehen können. Alle Namen, Daten und Ergebnisse des Szenarios wurden für diese Lektion neu erstellt.

Du brauchst Grundwissen zu Tabellen, Kennzahlen und betrieblichen Abläufen. Wie du einzelne Qualitätsfehler in Datensätzen untersuchst und bereinigst, behandelt die Lektion zur Datenqualität. Die Auswahl und Bewertung eines Modells des maschinellen Lernens ist ebenfalls ein eigenes Thema.

Auftrag und Nutzen geben der Analyse eine Richtung

Ein Datenanalyseprojekt beantwortet nicht einfach “etwas mit Daten”. Es unterstützt eine konkrete Entscheidung. Nach dem Auftragsgespräch hält das Team deshalb folgende Projektgrundlage fest:

Der Nutzen ist bewusst als bessere Entscheidungsgrundlage formuliert. “Expresskosten um 20 Prozent senken” wäre als alleiniges Projektziel ungeeignet. Die Analyse kann Maßnahmen begründen. Ob die Kosten später sinken, hängt auch von Umsetzung, Lieferlage und Bestellverhalten ab. Das Projekt verspricht deshalb nur eine Wirkung, die es selbst nachweisen kann.

Stakeholder bringen Bedarf, Wissen und Verantwortung ein

Ein Stakeholder ist eine Person oder Gruppe, die das Projekt beeinflusst oder von seinem Ergebnis betroffen ist. Nicht alle Stakeholder entscheiden dasselbe. Das Team ordnet deshalb Beiträge und Verantwortung vor dem Datenzugriff:

Eine Rollenliste allein reicht nicht. Jeder wichtige Kontrollpunkt braucht eine benannte Entscheidung. Sonst wartet das Projekt etwa auf eine “fachliche Freigabe”, ohne dass klar ist, wer sie erteilen darf.

Datenzugang folgt dem Zweck, nicht der Bequemlichkeit

Das Team prüft drei mögliche Quellen. Es übernimmt nicht automatisch alle verfügbaren Spalten.

Die gemeinsame Auftrags-ID verbindet die Exporte. Für die Analyse reicht eine projektbezogene, pseudonyme Kennung. Der Zuordnungsschlüssel bleibt beim verantwortlichen Quellsystem und wird nicht Teil des Analysebestands.

Pseudonymisiert bedeutet nicht anonym. Wenn Daten mit zusätzlichem Wissen wieder einer Person zugeordnet werden können, bleiben sie schutzbedürftig. Im Projekt gelten deshalb Zugriff nach Rolle, getrennte Ablagen für Roh- und Ergebnisdaten, protokollierte Exporte sowie eine vereinbarte Löschung nach der Übergabe.

Arbeitspakete liefern überprüfbare Ergebnisse

Ein Arbeitspaket beschreibt ein abgrenzbares Ergebnis mit Verantwortung und Fertigkriterium. “Daten anschauen” ist kein gutes Arbeitspaket. “Feldkatalog mit Herkunft, Bedeutung, Format und verantwortlicher Quelle fachlich freigegeben” lässt sich dagegen überprüfen.

Das Projekt wird in sieben Arbeitspakete gegliedert:

1. Auftrag, Stakeholder, Scope und Abnahmekriterien bestätigen.
2. Quellen, Felder, Rollen, Exportweg und Löschregel freigeben.
3. Unveränderte Datenstände übernehmen und ihre Herkunft protokollieren.
4. Verknüpfung und Qualitätsprofil erstellen; blockierende Befunde entscheiden lassen.
5. Kennzahlen, Vergleiche und Interpretationen entwickeln und fachlich prüfen.
6. Visualisierungen, Ergebnisbericht und Maßnahmenvorschläge abnehmen lassen.
7. Reproduktionspaket, Betriebsunterlagen, Schulung und Abschlussbewertung übergeben.

Meilensteine entscheiden über den nächsten Schritt

Ein Meilenstein ist kein beliebiges Kalenderdatum. Er markiert ein überprüfbares Zwischenergebnis oder eine Entscheidung. Für das Szenario gelten vier Meilensteine:

Risiken brauchen Auslöser, Wirkung und Reaktion

Ein Risiko beschreibt ein mögliches zukünftiges Ereignis. “Schlechte Daten” ist zu ungenau. Das Team formuliert stattdessen, woran es das Risiko erkennt, was es bewirken würde und wie es reagiert.

Risiken werden nicht nur am Projektstart notiert. Das Team prüft sie an jedem Meilenstein. Ein bereits eingetretenes Ereignis ist kein Risiko mehr, sondern ein Problem mit Entscheidung, Verantwortung und Termin.

Qualitäts- und Abnahmekriterien entstehen vor der Auswertung

Qualitätssicherung prüft nicht nur, ob ein Skript ohne Fehlermeldung läuft. Sie verbindet Daten, Methode, Darstellung und fachliche Aussage mit beobachtbaren Kriterien.

Die konkrete Grenze für nicht verknüpfbare Aufträge legt das Projekt mit den verantwortlichen Rollen fest. Sie ist keine allgemeingültige Fachregel. Wichtig ist, dass sie vor der Ergebnisbewertung bestätigt und bei einer Abweichung nicht still verschoben wird.

Reproduzierbarkeit macht den Entstehungsweg prüfbar

Ein Ergebnis ist reproduzierbar, wenn eine berechtigte Person mit dem dokumentierten Datenstand, den festgehaltenen Versionen und den beschriebenen Schritten dasselbe Analyseergebnis erzeugen kann. Dazu übergibt das Team kein loses Notebook, sondern ein geordnetes Paket:

analyse-expressnachsendungen/
├── README.md
├── manifest.yml
├── data/
│   └── input-checksums.txt
├── src/
│   ├── 01_import.sql
│   ├── 02_transform.py
│   └── 03_kennzahlen.py
├── config/
│   └── projektparameter.yml
├── tests/
│   └── test_kennzahlen.py
└── output/
    ├── kennzahlen.csv
    └── abbildungen/

Das Manifest benennt Datenstand, Ausführungsreihenfolge, Laufzeitumgebung, Werkzeugversionen und verantwortliche Rolle. Zugangsdaten liegen nicht darin. Der Ordner data enthält in der Übergabe nur Prüfsummen und Herkunftsnachweise, sofern die Rohdaten nicht mit übergeben werden dürfen.

Ein reproduzierbarer Lauf garantiert noch keine richtige Interpretation. Er garantiert nur, dass der technische Entstehungsweg wiederholbar ist. Fachreview und Aussagegrenzen bleiben zusätzlich nötig.

Eine Visualisierung beantwortet eine Frage

Das Team findet im Szenario: Bei Aufträgen mit dokumentiertem Nachpick tritt die Kennzahl “Expressnachsendung” häufiger auf als bei Aufträgen ohne Nachpick. Diese Beobachtung stammt aus den erfundenen Projektdaten der Lektion. Sie beweist nicht, dass der Nachpick die Nachsendung verursacht. Beide können zum Beispiel durch denselben Bestandsfehler beeinflusst sein.

Für die Ergebnisdarstellung gelten deshalb vier Fragen:

1. Welche betriebliche Frage beantwortet die Grafik?
2. Welche Grundgesamtheit und Bezugsgröße werden verglichen?
3. Welche Aussage tragen die Daten?
4. Welche Ursache oder Übertragbarkeit tragen sie nicht?

Eine passende Bildunterschrift lautet etwa: “Anteil der Standardaufträge mit Expressnachsendung, getrennt nach dokumentiertem Nachpick, erstes Halbjahr 2026. Dargestellt ist ein Zusammenhang im analysierten Datenstand, kein Ursachennachweis.”

Übergabe verbindet Ergebnis, Nutzung und Betrieb

Die Abnahme findet mit Logistikleitung, Lagerkoordination und IT-Betrieb statt. Das Team zeigt nicht nur Folien, sondern führt drei vereinbarte Prüfungen durch:

• Die Auftraggeberin findet zu jeder Kernaussage Kennzahl, Filter, Datengrundlage und Grenze.
• Die Lagerkoordination kann eine Visualisierung in eigenen Worten erklären und daraus eine zulässige Prozessfrage ableiten.
• Der IT-Betrieb führt mit der Anleitung einen Testlauf aus und erkennt einen absichtlich veränderten Eingabe-Datenstand an der Prüfsumme.

Zur Übergabe gehören Ergebnisbericht, Kennzahlenblatt, Reproduktionspaket, Freigaben, Rollen- und Löschkonzept, Betriebsablauf, Schulungsnotiz und eine Liste offener Punkte. Ein Dashboard ohne diese Unterlagen wäre eine Oberfläche, aber noch keine belastbare Projektübergabe.

Der Abschluss bewertet Ergebnis und Vorgehen getrennt

Im Szenario sind die vereinbarten Ergebnisbestandteile vorhanden. Der zweite Analyselauf erzeugt dieselben Ergebnistabellen, und das Fachreview bestätigt die Interpretation im dokumentierten Umfang. Ein offener Punkt bleibt: Das Reklamationssystem enthält für einen Teil der älteren Vorgänge keine freigegebene Ursachenkategorie. Diese Vorgänge werden sichtbar als “nicht klassifiziert” ausgewiesen und nicht nachträglich geschätzt.

Der Plan-Ist-Vergleich zeigt außerdem, dass M2 zwei Arbeitstage später erreicht wurde. Die Positivliste der Exportfelder wurde erst nach einem Freitextfund ergänzt. Das Projektergebnis ist im freigegebenen Umfang abnahmefähig. Das Vorgehen kann trotzdem verbessert werden.

Aus der Abschlussbesprechung entstehen drei Lessons Learned:

• Exportfelder werden künftig vor dem ersten Testexport über eine Positivliste und eine Schemaprüfung begrenzt.
• Fachreviews erhalten bereits bei Projektstart feste Termine und eine kurze Prüfanleitung.
• Die Kategorie “nicht klassifiziert” wird als eigener Datenqualitätsbefund geführt, statt Fälle still einer vermuteten Ursache zuzuordnen.

Eine Lesson Learned beschreibt nicht nur, was passiert ist. Sie verbindet Beobachtung, Ursache und eine konkrete Änderung für die nächste Arbeit.

Was du aus dem Projekt mitnimmst

• Eine Analyse beginnt mit einer betrieblichen Frage, einer Entscheidung und einer ehrlichen Projektgrenze.
• Stakeholder liefern Bedarf und Fachwissen; Rollen legen fest, wer Daten, Interpretation, Abnahme und Betrieb verantwortet.
• Daten werden zweckgebunden, minimiert und mit dokumentierter Herkunft übernommen.
• Arbeitspakete liefern Ergebnisse. Meilensteine verbinden diese Ergebnisse mit einer Entscheidung.
• Reproduzierbarkeit, Fachreview und verständliche Visualisierung sichern verschiedene Teile der Qualität.
• Die Übergabe umfasst Ergebnis, Entstehungsweg, Nutzung, Betrieb, Grenzen und offene Punkte.
• Lessons Learned werden erst wirksam, wenn aus einer Beobachtung eine konkrete Änderung folgt.

Quellenbasis und Abgrenzung

Der KMK-Rahmenlehrplan ordnet die vollständige kundenspezifische Prozess- und Datenanalyse dem Lernfeld 12c zu. Die Fachinformatikerausbildungsverordnung nennt im Prüfungsbereich “Planen und Durchführen eines Projektes der Datenanalyse” unter anderem Anforderungsanalyse, Projektplanung, Identifikation und Analyse von Daten sowie Aufbereitung und Dokumentation der Ergebnisse. Der Prüfungskatalog stützt die Breite von Projektplanung, Stakeholderanalyse, Risiken, Leistungsübergabe, Soll-Ist-Vergleich und Lessons Learned.

Die Lektion zeigt daraus eine berufliche Handlung an einem neu erstellten Szenario. Sie übernimmt keine Prüfungsaufgabe und trifft keine Aussage über einen bestimmten Prüfungstermin. Konkrete Einreichungs-, Genehmigungs- und Formvorgaben für eine betriebliche Projektarbeit richten sich nach dem zuständigen Verfahren und sind nicht Gegenstand dieser Lektion.

Die Lektion plant Qualitätskontrollen, erklärt aber nicht die systematische Erkennung und Bereinigung einzelner Datenfehler. Das gehört zur Lektion “Datenqualität prüfen und verbessern”. Sie entwickelt außerdem kein Modell des maschinellen Lernens. Auswahl, Training und Bewertung solcher Modelle gehören zum eigenen ML-Modellprozess.

Belegmatrix