Kernprodukt

Das SAP-Analytics-Sparring

Architektur, Datenmodelle und Coding – abgesichert, während implementiert wird.

Ihr Team verantwortet die Lösung. Ich sichere die Entscheidungen ab.


So arbeiten wir

01

Anforderung gegenprüfen, bevor implementiert wird

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.

02

Sparring-Sessions im festen Rhythmus

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.

03

Kurzfragen zwischendurch

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

Was Sie bekommen

Architektur, Datenmodelle und Coding – abgesichert, während implementiert wird.

Standard

Für Teams mit stetigem Anforderungsfluss

Implementierung abgesichert

  • Anforderung gegengeprüftpro Monat, schriftliche Empfehlung

Sparring live

  • Session, 90 Minutenpro Monat, remote, mit Protokoll
  • Kurzfragen zwischendurchAntwort in der Regel in 3 Werktagen

Erweitert

Wenn Teams viel zu bewältigen haben

Implementierung abgesichert

  • Anforderung gegengeprüftpro Monat, schriftliche Empfehlung

Schriftlich erhalten

  • Modellierungsstandardserstellt und laufend gepflegt

Sparring live

  • Session, 90 Minutenpro Monat, remote, mit Protokoll
  • Kurzfragen zwischendurchAntwort in der Regel in 3 Werktagen

Intensiv

Für größere Unternehmen und laufende Projekte

Implementierung abgesichert

  • Anforderung gegengeprüftpro Monat, schriftliche Empfehlung
  • Partnerkonzept bewertetpro Monat, inkl. Aufwandsschätzung

Schriftlich erhalten

  • Modellierungsstandardserstellt und laufend gepflegt

Sparring live

  • Session, 90 Minutenwöchentlich, remote, mit Protokoll
  • Kurzfragen zwischendurchAntwort in der Regel in 3 Werktagen

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

Technologie-Landkarte

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.

01

Quellen & Extraktion

S/4HANA und Non-SAP-Quellen · CDS-View-Extraktoren auswählen/erweitern inkl. Delta-Fähigkeit · Replication/Data Flows in Datasphere · Ladefehler-Handling

02

Datenmodell & Ladeprozesse

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

03

Reporting

SAC-Stories und Dashboards · Analysis for Excel · Analytic Models/Queries als semantische Schicht · datenbezogene Berechtigungen im Modell · Query- und Berichtsperformance

Qualität & Standards

Namenskonventionen · Modellierungsstandards für skalierbare Modelle · übergabefähige technische Dokumentation · Transport-/Deployment-Prozess · Performance-Prinzipien (Pushdown, Partitionierung)

Die Methode

Die Qualitätskette

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.

  1. 01Anforderung und KennzahldefinitionDie Kennzahl wird definiert, bevor sie gebaut wird – inklusive der Frage, was ausdrücklich nicht dazugehört.

    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.

  2. 02ArchitekturauswahlDas Anforderungsprofil steht fest, bevor über Technologie gesprochen wird.

    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.

  3. 03QuellanbindungDelta-Verhalten je Quelle ist geklärt, der automatisierte Abgleich definiert.

    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.

  4. 04DatenmodellSchichtentrennung, Schlüssel, Granularität und Historisierung stehen am Entwurf fest, bevor gebaut wird.

    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.

  5. 05TransformationenJede Business-Logik liegt an genau einer Stelle und auf der richtigen Schicht.

    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.

  6. 06Stammdaten und AnreicherungenJede Anreicherung ist mit Quelle, Owner und Aktualisierungsrhythmus benannt; der Umgang mit Fehlschlüsseln ist geklärt.

    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.

  7. 07CodingReview gegen Coding-Standards und Performance-Schwellen, durch jemanden, der nicht selbst gebaut hat.

    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.

  8. 08Berechtigungen und DatenschutzBerechtigungen liegen im Modell, nicht im Bericht – mit Testfällen je Rolle.

    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.

  9. 09Bericht und AbnahmeKennzahlen kommen aus der semantischen Schicht, die Abnahme-Testfälle stehen vorab fest.

    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.

  10. 10Betrieb und MessungWelche Regeln laufend geprüft werden und wer auf Abweichungen reagiert, ist mit dem Team festgelegt.

    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

Was das für KI-Vorhaben bedeutet.

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.

Kennenlern-Session mit Ihrem Team.

Wenn Qualität beruhigt.