Leitfaden zur Implementierung von Datenqualität für moderne Datenteams
|
7
min. Lesezeit
Ihre Dashboards sind wieder veraltet, eine Pipeline ist über Nacht ausgefallen, und die erste Frage am Morgen ist immer noch dieselbe: „Können wir dieser Zahl vertrauen?“ Das ist eine typische Herausforderung für viele Teams, die eine Datenqualitätsimplementierung durchführen, nachdem das Data Warehouse, der Lake und der BI-Layer bereits live sind. Die Lösung ist kein weiterer Cleanup-Sprint, sondern der Aufbau von Kontrollen (controls), die verhindern, dass schlechte Daten zum Problem anderer werden.
Ein funktionierendes Programm beginnt mit einer einfachen Idee: Nur ein kleiner Teil der Daten birgt wirklich ein geschäftliches Risiko. Die erfolgreichsten Teams behandeln Qualität nicht als einmaliges Projekt, sondern wie einen operativen Betrieb – mit Verantwortlichkeiten, Schwellenwerten und Alarmen, die sich in die bereits genutzten Pipelines integrieren lassen.
Inhaltsverzeichnis
Warum die Implementierung von Datenqualität ohne ein Kontrollsystem scheitert
Identifizierung kritischer Datenelemente und Festlegung gestufter Schwellenwerte
Architektur- und Bereitstellungsoptionen für Enterprise-Umgebungen
Entwerfen von Validierungsregeln und Baselines zur Anomalieerkennung
Integration von Qualitätsprüfungen in Pipelines und MLOps-Workflows
Checkliste für die Einführung Ihrer Datenqualitätsimplementierung
Warum die Implementierung von Datenqualität ohne ein Kontrollsystem scheitert
Vom Bereinigungsaufwand zu gesteuerten Kontrollen
Viele Datenteams betreiben Qualitätsarbeit immer noch wie eine Notfallrettung. Ein Dashboard zeigt falsche Werte, jemand öffnet ein Ticket, ein Analyst korrigiert ein Modell, und in der nächsten Woche tritt dasselbe Problem erneut auf, weil niemand das Upstream-Verhalten geändert hat. Dieses Muster ist genau der Grund, warum moderne Ansätze Datenqualität als ein gesteuertes System aus Genauigkeit, Vollständigkeit, Konsistenz, Aktualität, Eindeutigkeit und Validität betrachten und nicht als einmalige Bereinigungsaktion (TechTarget).
Die Fehlerursachen sind meist banal. Ein verspäteter Ladevorgang lässt einen Umsatzbericht flach aussehen, ein fehlender Schlüssel führt dazu, dass Joins Datensätze verwerfen, oder eine Schemaänderung verschiebt eine Metrik. Sobald ein Team Hunderte von täglichen Ladevorgängen hat, lässt sich die manuelle Fehlerbehebung nicht mehr skalieren, und im Data Warehouse sammeln sich kleine Vertrauensverluste an, die den Nutzern auffallen, lange bevor sie erklärt werden können.
Praktische Regel: Wenn eine Prüfung keinen Owner, keinen Schwellenwert und keinen Weg zur Behebung hat, ist sie keine Kontrolle (control), sondern nur eine Notiz.
Warum periodische Audits fehlschlagen
Periodische Audits helfen, aber sie sind zu langsam für Live-Pipelines. Zeitgemäße Praxisleitfäden rücken Aktualität, Latenznachverfolgung, Ablaufregeln und Echtzeit-Synchronisierung in das Zentrum des routinemäßigen Qualitätsmanagements. Denn das erste Anzeichen für Probleme sind oft verzögerte oder inkonsistente Daten und nicht offensichtliche Beschädigungen (Lumenalta). Aus diesem Grund hat sich das Kontrollmodell hin zu Prüfungen verlagert, die in Pipelines eingebettet, anhand von Regeln validiert und im Zeitverlauf überwacht werden.
Der andere Fehlermodus ist kultureller Natur. Teams nennen diese Arbeit „Datenbereinigung“, was nach einer endlichen Aufgabe klingt, und planen sie dann wie ein Projekt mit Enddatum. In der Praxis ähnelt das bessere Modell eher dem Release-Management. Sie identifizieren die kritischen Datenelemente, ordnen Business-Regeln den Prüfungen zu, definieren Akzeptanzschwellenwerte und überwachen diese auch nach dem ersten Rollout kontinuierlich. Dieser Ansatz deckt sich mit Best Practices, die betonen, dass Datenkataloge, Herkunft (Provenance), Lineage und Aktualität etabliert sein müssen, bevor tiefere governance-Ebenen effektiv greifen können (TechTarget).
Wenn dieser Wandel stattfindet, ändert sich die Diskussion. Man fragt nicht mehr, ob die Daten „richtig aussehen“, sondern ob sie innerhalb der Toleranzgrenzen liegen, wer für die Ausnahme verantwortlich ist und wie groß die Auswirkungen auf nachgelagerte Systeme sind, wenn sie es nicht sind.
Identifizierung kritischer Datenelemente und Festlegung gestufter Schwellenwerte
Starten Sie mit den Feldern, die Risiken bergen
Die meisten Programme scheitern, weil sie versuchen, zu viel auf einmal zu messen. Beginnen Sie mit den kritischen Datenelementen, die mit Umsatz, Compliance oder dem Kerngeschäft verknüpft sind, und lassen Sie den Rest in Ruhe, bis der erste Bereich stabil ist. Die Richtlinien von Gartner zur Datenqualität besagen, dass Anwendungsfälle und Datenressourcen nach Wert und Risiko kartiert werden sollten, bevor man Dimensionen und Metriken auswählt (Gartner).
Das ist besonders in regulierten Umgebungen wichtig, wo sich Risiken meist auf eine kleine Anzahl von Feldern konzentrieren und nicht auf das gesamte Data Warehouse. Identifikatoren, Salden, Patientenakten und ähnliche Daten verdienen weitaus mehr Aufmerksamkeit als unbedeutende Referenztabellen. Wenn Sie versuchen, alles gleichermaßen zu instrumentieren, endet das Team mit einem unruhigen Dashboard, einer schwachen Priorisierung und einem falschen Gefühl von Abdeckung.
Ein praktischer Weg, um zu entscheiden, was in den Scope gehört, sind drei Fragen:
Was geht kaputt, wenn dieses Feld falsch ist? Umsatzrealisierung, Kundenkommunikation, Compliance-Meldungen oder Modell-Features liefern oft schnell die Antwort.
Wer bemerkt den Fehler zuerst? Finanz-, Operations-, Support- und ML-Teams stoßen oft auf unterschiedliche Fehlermodi.
Können wir die Zuständigkeit klar zuweisen? Wenn die Behebung fünf Teams erfordert, muss die Regel wahrscheinlich enger gefasst werden.
Nutzen Sie diesen Filter, um das erste Monitoring-Set zu definieren. Das Ziel ist nicht, das größte Programm aufzubauen, sondern die Fehler abzufangen, die wirklich wehtun. Ein nützliches Hilfsmittel zur Eingrenzung ist der Blickwinkel der kritischen Datenelemente, da er das Team zwingt, die wirklich wichtigen Felder zu benennen, bevor Zeit für eine breite Abdeckung aufgewendet wird.
Nutzen Sie Baselines, bevor Sie Regeln festlegen
Bevor Sie Validierungslogik schreiben, sollten Sie die Quelle profilieren. Richtlinien zur Implementierung in Behörden empfehlen, zunächst Zeilenanzahlen, Null-Raten, Min/Max-Werte, Datentypen und wiederkehrende Muster zu analysieren und diese Ergebnisse dann zu nutzen, um Akzeptanzschwellenwerte als Prozentsätze und messbare Prüfungen festzulegen (Oracle). Diese Reihenfolge spart viel Nacharbeit, da Sie nicht raten müssen, wie der Normalzustand aussieht.
Schwellenwerte funktionieren besser, wenn sie gestuft statt binär sind. Ein praktisches Framework nutzt Gold für ≥ 99 % Genauigkeit, Silver für 95–98 % und Bronze für Werte unter 95 %, bei denen eine Behebung erforderlich ist (Acceldata). Diese Struktur bietet Produktbesitzern und Daten-Stewards eine gemeinsame Sprache und vermeidet die scheinbare Präzision von einfachem Bestehen oder Nichtbestehen bei jeder einzelnen Regel.
Der erste Durchlauf sollte eng gefasst bleiben. In einem ausgereiften Enterprise Warehouse ist ein kleineres, überwachtes Set mit klaren Schwellenwerten meist besser als eine breite, lückenhafte Abdeckung, der niemand vertraut.
Architektur- und Bereitstellungsoptionen für Enterprise-Umgebungen
Wählen Sie, wo die Prüfungen tatsächlich ausgeführt werden
Bei der Architekturentscheidung geht es nicht um Eleganz, sondern darum, wo die Daten liegen und wer sie anfassen darf. In Finanz-, Gesundheits-, Telekommunikations- und Behördenumgebungen ist die Übertragung von Produktionsdaten an ein externes System oft ausgeschlossen, sodass die Ausführung direkt in der Datenbank die praktische Wahl ist. Dadurch bleiben die Daten in der vom Kunden kontrollierten Umgebung und unnötige Datenbewegungen werden reduziert.
Viele Implementierungen scheitern beim ersten Versuch. Teams kaufen ein Dashboard-Tool, das in Demos gut aussieht, und stellen dann fest, dass sie immer noch überall dort benutzerdefinierten Code benötigen, wo Data Warehouse, Data Lake und Pipelines voneinander abweichen. Das bessere Muster ist, die Qualitäts-Engine nah an den Daten zu halten und die Ergebnisse dann über eine UI, eine API oder ein SDK bereitzustellen – je nachdem, wer darauf reagieren muss.
Es gibt in beiden Fällen Kompromisse:
Zentralisierte Dashboards helfen bei der teamübergreifenden Transparenz, können aber zu reiner Schau werden, wenn sie nicht mit Verantwortlichkeiten und Durchsetzung verknüpft sind.
Codebasierte SDKs geben Entwicklern die gewünschte Kontrolle, erfordern jedoch ein klares Betriebsmodell, da sonst jedes Team seine eigene Interpretation derselben Regel baut.
Private-Cloud- oder On-Premise-Bereitstellungen wahren die Kontrolle, was besonders wichtig ist, wenn Datenresidenz und Anbieterzugriff sensible Themen sind.
Hybride Setups können funktionieren, wenn nicht jeder Datensatz die gleiche Behandlung erfordert, aber die Aufteilung muss bewusst erfolgen.
Die beste Architektur ist diejenige, die sich in die bestehende Infrastruktur einfügt, ohne dass das Data Warehouse oder der Orchestration-Stack neu geschrieben werden müssen.
Halten Sie die Plattform nah an den Daten
Moderne Plattformen benötigen in Enterprise-Umgebungen meist drei Kernfunktionen, um nützlich zu bleiben. Erstens, automatische Baseline-Ermittlung, damit das System wiederkehrende Muster versteht. Zweitens, Trendanalysen, um Abweichungen (Drift) zu erkennen, anstatt nur Fehler zu zählen. Drittens, Schema-Tracking, damit das Hinzufügen, Entfernen oder Ändern von Datentypen bei Spalten nicht unbemerkt nachgelagerte Berichte unbrauchbar macht.
Eine Plattform wie digna passt in dieses Muster, indem sie Analysen direkt in den Datenbanken des Kunden ausführt, die Aktualität überwacht und Schemaänderungen nachverfolgt, ohne dass die Daten die kontrollierte Umgebung verlassen müssen. Das ist genau die Art von Deployment-Modell, die Enterprise-Teams in der Regel benötigen, wenn Observability mit Datenschutz und bestehenden Investitionen in das Data Warehouse koexistieren muss.
Der wichtigste Kompromiss ist der Wartungsaufwand. Eine Plattform, die zu weit von den Daten entfernt ist, benötigt mehr Integrationscode und mehr Ausnahmebehandlungen. Eine Plattform, die nah an den Daten läuft, ist im Betrieb oft ruhiger, da sie das Verhalten der Quelle direkt sieht und nicht auf kopierte Extrakte angewiesen ist, um Änderungen zu verstehen.
Entwerfen von Validierungsregeln und Baselines zur Anomalieerkennung
Ordnen Sie Kontrollen dem richtigen Fehlermodus zu
Ein praktisches Kontrollmodell kombiniert vier Ansätze: reaktiv, proaktiv, zweckgerichtet (fit-for-consumption) und Anomalieerkennung (OvalEdge). Diese Mischung ist wichtig, da unterschiedliche Fehler unterschiedliche Reaktionen erfordern. Ein fehlender Wert ist ein Problem. Ein fehlerhaftes Format ein anderes. Eine langsame Abweichung in einem Quellsystem erfordert wiederum eine ganz andere Kontrolle.
Reaktive Regeln fangen Probleme ab, nachdem sie aufgetreten sind. Proaktive Regeln stoppen schlechte Daten bereits bei der Eingabe. Zweckgerichtete Prüfungen stellen sicher, dass die Daten für einen bestimmten geschäftlichen Zweck nutzbar sind. Die Anomalieerkennung überwacht Änderungen, die nicht dem gelernten Muster entsprechen. Diese Trennung verleiht der Plattform eine klare Struktur und verhindert, dass Teams jede Regel in einen starren, fehleranfälligen Hard-Stop verwandeln.
Die Kerndimensionen bleiben dieselben: Genauigkeit, Vollständigkeit, Konsistenz, Aktualität, Validität und Eindeutigkeit. Der entscheidende Schritt ist, jede Dimension dem richtigen Kontrollpunkt zuzuordnen, anstatt so zu tun, als könne eine einzige Regel alles abdecken.
Eine gute Regel sagt Ihnen, was fehlgeschlagen ist, wo es fehlgeschlagen ist und wen es interessieren sollte. Alles andere wird nur zur Dekoration auf einem Dashboard.
Lassen Sie Baselines Drift und Timing-Abweichungen abfangen
Die Anomalieerkennung zahlt sich aus, wenn sich die Quelle langsam verändert. Wenn sich das Volumen, die Verteilung oder das Timing-Muster einer Tabelle signifikant verschiebt, kann eine gelernte Baseline dies melden, bevor ein Business-User das Problem in einem Bericht bemerkt. Dies reduziert den Bedarf an Hunderten von manuell erstellten Prüfungen, insbesondere in dynamischen Pipelines, in denen sich Schemata und Quellverhalten häufig ändern.
Die Aktualität erfordert eine eigene Behandlung. Zur gängigen Praxis gehört heute die Überwachung erwarteter Lieferzeiten, die Erkennung von Verzögerungen und terminbasierte Eingangsprüfungen als Standard-Qualitätskontrollen (Lumenalta). Verspätungen führen oft zu Fehlentscheidungen, noch bevor eine andere Prüfung anschlägt. Ein „korrekter“ Datensatz, der erst nach dem Meeting eintrifft, erfüllt die Qualitätsvorgaben ebenfalls nicht.
Das Schema-Tracking schließt eine weitere häufige Lücke. Hinzugefügte Spalten, gelöschte Spalten und Änderungen des Datentyps können nachgelagerte Analysen unbrauchbar machen, selbst wenn die Pipeline an sich fehlerfrei läuft. Behandeln Sie diese Änderungen als primäre Signale und nicht als Randnotiz, da sie oft die früheste Warnung dafür sind, dass ein Schnittstellenvertrag (Source Contract) nicht mehr eingehalten wird.
Integration von Qualitätsprüfungen in Pipelines und MLOps-Workflows
Machen Sie Qualitäts-Gates zum Teil der Bereitstellung
Qualität ist nur dann wirksam, wenn die Pipeline sie automatisch durchsetzt. Das bedeutet, dass Validierungsprüfungen, Anomalieerkennung und Aktualitätsüberwachung als Teil desselben Bereitstellungspfads laufen sollten, der Daten in Produktions-Dashboards oder Modell-Training-Jobs einspeist. Wenn das Team CI/CD für Code nutzt, gehört das Datenqualitäts-Gate genau dort hin.
Der Ablauf sollte unspektakulär sein: Validierung beim Import (Ingest), Validierung nach Transformationen und erneute Validierung vor der Veröffentlichung. Wenn ein Ladevorgang geplant ist, führen Sie die Prüfungen nach Zeitplan aus. Handelt es sich um Streaming, integrieren Sie die Prüfungen direkt in den Datenstrom. Speist er ein ML-Modell, blockieren Sie das Feature-Set, bevor schlechte Eingaben das Training oder die Bereitstellung erreichen.
Nutzen Sie Alarmierungen sparsam und zielgerichtet. Eine einzige fehlerhafte, zu sensible Regel kann mehr Schaden anrichten als das eigentliche Datenproblem selbst, weil die Beteiligten den Warnungen irgendwann nicht mehr vertrauen. Alarme sollten nach Schweregrad und geschäftlicher Auswirkung geroutet werden, nicht nur danach, wer gerade Bereitschaft hat.
Leiten Sie Ausnahmen an Verantwortliche weiter, nicht an Posteingänge
Der Grund, warum eindeutige Ownership so wichtig ist, ist einfach: Wiederkehrende Fehler verschwinden nicht, nur weil jemand sie in ein Ticket kopiert. Sie verschwinden, wenn der zuständige Data Steward oder Custodian den Fehler sehen, die Ursache verstehen und das Verhalten an der Quelle beheben kann. Aus diesem Grund verknüpfen ausgereifte Frameworks Prüfungen mit expliziter Ownership und Eskalationspfaden, anstatt Analysten die gesamte manuelle Triage zu überlassen (Monte Carlo).
Feedbackschleifen halten die Regeln aktuell. Quellen ändern sich, Geschäftsziele ändern sich, und das Team sollte damit rechnen, dass sich auch das Schwellenwertmodell anpasst. Automatisierung hilft hier, da sie menschliche Fehler reduziert und das Programm langfristig tragfähig macht. Wenn der Workflow funktioniert, verbringen die Engineers weniger Zeit mit der manuellen Überwachung der Pipeline und mehr Zeit mit deren Optimierung.
Teams, die nach einem gesteuerten Workflow suchen, greifen oft auf Tools wie digna, dbt-Tests oder datenbankeigene Prüfungen zurück. Die Toolauswahl ist jedoch nur dann entscheidend, wenn das Routing-Modell klar definiert ist. Das Tool sollte das Problem melden, der Steward sollte die Behebung verantworten und die Historie sollte zeigen, ob derselbe Fehler immer wieder auftritt.
Kontinuierliche Überwachung und ROI-Messung
Qualität als laufendes System messen
Eine Pipeline kann morgens fehlerfrei aussehen und bis zum Mittagessen dennoch fehlerhafte Daten liefern. Manuelle Stichproben können mit diesem Tempo nicht mithalten. Daher muss eine kontinuierliche Überwachung direkt im Kontrollsystem verankert sein, um Verzögerungen, Abweichungen (Drift) und Schemaänderungen zu erkennen, bevor diese Probleme Entscheidungen beeinflussen. Der praktische Wandel führt weg von gelegentlichen Bereinigungen hin zu einer gesteuerten Messung, bei der der Datensatz permanent unter Beobachtung steht, anstatt nur kalendarisch geprüft zu werden.
Definieren Sie Erfolgskriterien in operativen Begriffen und nicht in vagen Vertrauenswerten. Teams verfolgen in der Regel Genauigkeitsbereiche, überwachte Verzögerungsfenster und Ausnahmeraten, um zu entscheiden, ob das Programm stabil läuft. Diese Signale funktionieren besser als die bloße Frage, ob ein Datensatz „sauber“ aussieht, da sie sich im Trend darstellen, über verschiedene Quellen hinweg vergleichen und konkreten Ownern zuordnen lassen.
Auch die historische Analyse ist wichtig. Wenn Sie vergangene Vorfälle überprüfen, zeigt sich das Muster meist in den Ankunftszeiten, der Drift und wiederkehrenden Ursachen, die bei einem einmaligen Audit übersehen werden. Das macht das Monitoring zu einem echten Managementsystem statt zu einer bloßen Flut von Alarmen. Genau deshalb muss Datenqualitätsmonitoring die Prüfung selbst direkt mit der Quelle, dem Owner und dem Behebungsweg verknüpfen.
Nützlicher Test: Wenn eine Metrik Ihnen nicht bei der Entscheidung hilft, ob Sie ein Problem beheben, eskalieren Sie es oder ignorieren es, gehört sie in einen Bericht, nicht in ein Monitoring-System.
Ergebnisse ohne Vanity-Metriken nachverfolgen
Der ROI von Datenqualität zeigt sich in der Regel in weniger Ad-hoc-Krisenreaktionen, schnellerer Erkennung und weniger manuellem Reparaturaufwand. Ein Monitoring-Dashboard kann dies sichtbar machen, wenn es die Qualitätsabdeckung mit den operativen Auswirkungen verknüpft und nicht nur mit technischen Aktivitäten. Die richtige Frage ist nicht, wie viele Prüfungen existieren, sondern ob diese Prüfungen Fehlentscheidungen verhindern und wiederholte Arbeit reduzieren.
Regelmäßige Neubewertungen sind wichtig, da sich Quellen und Ziele ständig ändern. Automatisierung hilft dabei, den Rhythmus beizubehalten, aber der Wert entsteht durch den geschlossenen Kreislauf: Erkennen, Zuweisen, Beheben, Bestätigen und anschließendes Anpassen der Regel, wenn sich das Geschäft ändert. Wenn dasselbe Problem immer wieder auftritt, müssen der Schwellenwert, das Ownership-Modell oder der vorgelagerte Prozess überprüft werden.
Checkliste für die Einführung Ihrer Datenqualitätsimplementierung
Klein anfangen und mit messbarem Erfolg expandieren
Beginnen Sie mit ein oder zwei Bereichen, die das größte geschäftliche Risiko bergen. Profilieren Sie die Quelle, definieren Sie die Business-Regeln, legen Sie die Schwellenwerte fest und bestimmen Sie die Owner, bevor Sie die Abdeckung ausweiten. Wenn die ersten Rollouts nicht stabil laufen, vervielfacht eine Ausweitung des Scopes lediglich das Rauschen.
Ein praktischer Ablauf für die Einführung sieht wie folgt aus:
Wählen Sie kritische Datenelemente aus. Konzentrieren Sie sich auf Felder, die mit Umsatz, Compliance oder Kernprozessen verknüpft sind.
Profilieren Sie die Quelle. Erfassen Sie Baselines für Zeilenanzahlen, Null-Raten, Wertebereiche, Datentypen und häufige Muster.
Legen Sie Akzeptanzbereiche fest. Nutzen Sie messbare Schwellenwerte und gestufte Ergebnisse, damit das Team weiß, wann eine Behebung eingeleitet werden muss.
Integrieren Sie die Automatisierung. Führen Sie Prüfungen direkt in der Pipeline aus, nicht durch nachträgliche manuelle Kontrollen.
Weisen Sie Verantwortlichkeiten zu. Stellen Sie sicher, dass jeder wiederkehrende Fehler bei einem Steward oder Custodian landet, der die Quelle korrigieren kann.
Überprüfen und erweitern Sie. Weiten Sie die Abdeckung erst aus, wenn der erste Bereich stabil läuft.
Achten Sie streng auf Scope Creep. Teams versuchen oft, zu viele Metriken zu definieren, bevor sie die geschäftskritischen stabilisiert haben, oder sie vergessen Legacy-Systeme und externe Quellen, in denen sich die meisten Unregelmäßigkeiten verbergen. So wird das Programm auf dem Papier beeindruckend, in der Produktion jedoch hochgradig fragil.
Fokus der Einführung auf Ownership legen
Die beste Einführungs-Checkliste ist so kurz, dass die Beteiligten sie auch tatsächlich nutzen. Sie sollte die Abstimmung mit Stakeholdern, Testphasen, Eskalationspfade und die Schwellenwerte abdecken, die darüber entscheiden, ob Daten für die Veröffentlichung geeignet sind. Sie sollte auch Raum für Ausnahmen lassen, da nicht jede fehlgeschlagene Regel bedeutet, dass die Daten falsch sind.
Der abschließende Test ist, ob das Programm die manuelle Fehlersuche reduziert. Wenn Analysten ihre Vormittage immer noch damit verbringen, dieselben fehlerhaften Eingabedaten abzugleichen, sind die Kontrollen noch nicht operativ im Einsatz. Wenn Owner das Problem, den Schwellenwert und den Weg zur Behebung ohne ein Meeting einsehen können, beginnt die Implementierung zu greifen.
Wenn Sie ein Datenqualitätsprogramm aufbauen oder ersetzen, kann digna Ihnen helfen, kritische Datenelemente zu überwachen, Datensätze direkt in der Datenbank zu validieren sowie Aktualität und Schemaänderungen nachzuverfolgen – ohne dass Produktionsdaten Ihre Umgebung verlassen müssen. Besuchen Sie digna, um zu sehen, wie sich das in ein echtes Data Warehouse oder einen Pipeline-Stack integrieren lässt.
