Standard
Implementierung abgesichert
- 2×Anforderung gegengeprüftpro Monat, schriftliche Empfehlung
Sparring live
- 2×Session, 90 Minutenpro Monat, remote, mit Protokoll
- Kurzfragen zwischendurchAntwort in der Regel in 3 Werktagen
Kernprodukt
Architektur, Datenmodelle und Coding – abgesichert, während implementiert wird.
Ihr Team verantwortet die Lösung. Ich sichere die Entscheidungen ab.
Neue Anforderungen erreichen mich, bevor Ihr Team sie umsetzt. Ich prüfe sie gegen Architektur und Wartbarkeit und gebe eine schriftliche Empfehlung, in der Regel innerhalb von drei Werktagen: tragfähig, tragfähig mit Auflagen oder überarbeiten. Die Entscheidung trifft Ihr Team.
Zwei bis vier Termine im Monat à 90 Minuten, remote. Eingereichte Unterlagen sehe ich vorher durch, damit die Session eine Entscheidung vorbereitet statt eine Diskussion eröffnet. Jede Session endet mit einem Protokoll: besprochene Punkte, geprüfte Alternativen, meine Empfehlung.
Zwischen den Terminen können Sie mir konkrete Fragen schriftlich stellen – zu einem bekannten Sachverhalt, ohne dass ich Unterlagen sichten muss. Antwort in der Regel innerhalb von drei Werktagen, ohne dass ein Termin nötig ist.
Das SAP-Analytics-Sparring
Architektur, Datenmodelle und Coding – abgesichert, während implementiert wird.
Implementierung abgesichert
Sparring live
Implementierung abgesichert
Schriftlich erhalten
Sparring live
Implementierung abgesichert
Schriftlich erhalten
Sparring live
Anforderung: ein abgegrenztes Vorhaben – ein Datenmodell, ein Bericht mit seinen Kennzahlen, eine Transformationskette oder eine technische Konzeptfrage. Richtgröße bis ca. 10 Datenobjekte bzw. Kennzahlen. · Partnerkonzept: ein Lösungskonzept oder Angebot eines Dienstleisters für ein abgegrenztes Vorhaben, Richtgröße bis ca. 25 Seiten. · Kurzfrage: eine konkrete Frage zu einem bekannten Sachverhalt, schriftlich gestellt und ohne Sichtung von Unterlagen beantwortbar. · In allen Stufen: keine Implementierung – bei Bedarf als gesondertes Angebot buchbar. Relevante Systemzugänge müssen vorhanden sein. Vor-Ort-Tage zum Tagessatz zzgl. Reisepauschale.
Von Anfang an richtig.
Technologie
Der Datenfluss der Ziel-Landschaft – Quellen → Datenmodell → Reporting – plus Qualität und Standards als durchgehende Ebene. SAP only: Datasphere, BW/4HANA, SAP Analytics Cloud, Business Data Cloud.
S/4HANA und Non-SAP-Quellen · CDS-View-Extraktoren auswählen/erweitern inkl. Delta-Fähigkeit · Replication/Data Flows in Datasphere · Ladefehler-Handling
Schichtenarchitektur (LSA++ bzw. Datasphere-Spaces/Layering) · ADSOs und CompositeProvider bzw. Views und Analytic Models · Business-Logik in Transformationen · Historisierung · Prozessketten/Task Chains, Delta-/Vollladestrategie, Monitoring
SAC-Stories und Dashboards · Analysis for Excel · Analytic Models/Queries als semantische Schicht · datenbezogene Berechtigungen im Modell · Query- und Berichtsperformance
Namenskonventionen · Modellierungsstandards für skalierbare Modelle · übergabefähige technische Dokumentation · Transport-/Deployment-Prozess · Performance-Prinzipien (Pushdown, Partitionierung)
Die Methode
Datenqualität entsteht nicht durch Prüfen am Ende, sondern durch Entscheidungen an jeder Stufe. Jeder Fehler wandert nach unten und wird dabei teurer – eine falsche Granularitätsentscheidung kostet in der Konzeption eine Stunde, im Bericht eine Woche. Zehn Stufen entlang des Prozesses – mit klar benannten Verantwortlichkeiten, nachvollziehbar bis zur Quelle, unabhängig geprüft vor jeder Produktivsetzung, entschieden nach Messwerten statt nach Eindruck.
Risiko Die fachliche Anforderung ist unklar oder nur mündlich vereinbart; „Umsatz" bedeutet in drei Abteilungen drei verschiedene Dinge. Hier entstehen die teuersten Fehler, weil keine spätere Kontrolle sie auffängt.
Kontrolle Kennzahl vor dem Bau definiert – mit Berechnungsregel, Abgrenzung und fachlichem Eigentümer; Rückverfolgbarkeit von der Anforderung bis zum gebauten Objekt.
Nachweis Jede Kennzahl im Bericht lässt sich auf eine schriftliche Definition zurückführen.
Risiko Technologieentscheidung nach Präferenz statt nach Anforderung – gewählt, bevor Latenz, Volumen, Historisierungstiefe, Nutzergruppen und Governance geklärt sind.
Kontrolle Anforderungsprofil vor der Technologie; dokumentierte Zielarchitektur mit benannten Schichten und ihrem Zweck.
Nachweis Man kann sagen, warum diese Technologie – mit Kriterien, nicht mit Gefühl.
Risiko Extraktoren ohne echte Delta-Fähigkeit; unbemerkte Ladefehler.
Kontrolle Delta-Verhalten je Quelle klären, bevor gebaut wird; automatisierter Abgleich Quelle/Staging über Satzzahlen und Summen.
Nachweis Reconciliation-Lauf ohne Nachfrage; Monitoring mit Schwellwerten und Alarmierung.
Risiko Übersprungene Schichten, uneinheitliche Granularität, nicht eindeutige Schlüssel, Dubletten, ad hoc gewachsene Historisierung.
Kontrolle Verbindliche Schichtentrennung (Staging – Harmonisierung – Semantik); dokumentierte Entscheidung zu Schlüssel und Granularität je Objekt; definierte Dublettenbehandlung; bewusste Historisierungsstrategie.
Nachweis Kein Reporting-Objekt greift direkt auf Rohdaten zu; Schlüssel sind nachweislich eindeutig; Modell vor Produktivsetzung geprüft von jemandem, der es nicht gebaut hat.
Risiko Verstreute und duplizierte Business-Logik – dieselbe Regel an drei Stellen, die auseinanderlaufen; frühe Aggregation, die Granularität unwiederbringlich verwirft.
Kontrolle Jede Logik genau einmal und auf der richtigen Schicht; Pushdown statt Verarbeitung im Frontend; Granularität und Historie erhalten, solange kein Grund dagegen spricht; Wiederholbarkeit als Prinzip.
Nachweis Zweimal laden liefert dasselbe Ergebnis.
Risiko Mappings und Hierarchien aus Excel ohne Eigentümer; Fehlschlüssel, die stillschweigend verworfen werden; verletzte referenzielle Integrität mit Waisen-Sätzen, die Summen verfälschen.
Kontrolle Jede Anreicherung mit benannter Quelle, fachlichem Owner und Aktualisierungsrhythmus; referenzielle Integrität geprüft; Sätze ohne Schlüsseltreffer werden sichtbar behandelt, nicht unterdrückt.
Nachweis Liste aller Anreicherungen mit Owner; sichtbares Reject-Handling; messbarer Anteil nicht zuordenbarer Sätze.
Risiko Fehlende Standards, unkommentierte Business-Regeln, Performance-Fallen, die erst unter Last auffallen.
Kontrolle Namens- und Coding-Konventionen; Kommentierung der fachlichen Regel; Review außerhalb des bauenden Teams; Performance als Prüfkriterium mit definierten Schwellen.
Nachweis Review-Protokoll mit erkennbarer Rollentrennung.
Risiko Nachbau je Bericht – zwei Nutzer sehen unterschiedliche Zahlen, niemand weiß, welche stimmt; personenbezogene Felder ohne Klassifizierung.
Kontrolle Datenbezogene Berechtigungen zentral im Modell (Data Access Controls), nie im Frontend; personenbezogene Daten klassifiziert und im Berechtigungskonzept berücksichtigt; Testfälle je Rolle mit erwarteten Werten.
Nachweis Test derselben Kennzahl unter mehreren Rollen.
Risiko Kennzahlen im Frontend neu berechnet, abweichende Filterlogik, unsichtbarer Datenstand.
Kontrolle Kennzahlen ausschließlich aus der semantischen Schicht; keine Formeln im Frontend; sichtbarer Zeitstempel des Datenstands; Abnahme durch den Fachbereich gegen vorab definierte Testfälle.
Nachweis Abnahmeprotokoll – und niemand rechnet mehr nach.
Risiko Qualität verfällt unbemerkt – Quellen ändern sich, Volumina wachsen, Regeln laufen auseinander; Abweichungen werden gemeldet, aber nie bis zur Ursache verfolgt.
Kontrolle Definierte Qualitätsregeln (Pflichtfelder, Wertebereiche, Plausibilität gegen Vorperioden) laufen automatisiert; Aktualitätsanforderung je Datenbereich festgelegt und überwacht; gemeldete Abweichungen haben einen definierten Weg bis zur behobenen Ursache.
Nachweis Qualitätskennzahlen über die Zeit, nicht nur zum Go-Live.
Ausblick
KI-Readiness ist kein zusätzliches Thema, sondern der Härtetest dieser Kette. Was ein Mensch im Bericht durch Kontextwissen ausgleicht, skaliert ein Modell zum Fehler.
Vier Anforderungen gehen über das Bestehende hinaus – und alle vier hängen an Stufen, die es bereits gibt: maschinenlesbare Semantik, damit ein Glossar nicht nur von Menschen gelesen werden kann. Erhaltene Granularität und Historie, weil frühe Aggregation jedem späteren Modell die Grundlage nimmt. Maschinell auswertbare Lineage – Herkunft muss abfragbar sein, nicht nur dokumentiert. Und ein Berechtigungsmodell, das auch nicht-menschliche Zugriffe trägt.