Schlechte Daten fernhalten

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 2 von 6 im Kapitel Datenqualität und Governance, Kapitel 5 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Governance wird in die Org hineinentworfen · Weiter: Kennen Sie Ihre Daten

Die Frage, die dieses Modul beantwortet: Wie halten Sie Daten gut, und wie bleibt das so?

Es gibt zwei Wege, mit schlechten Daten umzugehen: sie aufhalten, bevor sie hereinkommen, oder sie hinterher bereinigen. Sie werden beides ein wenig tun. Aber wenn ich die Wahl habe, verhindere ich das Problem lieber, als eine Organisation darum herum zu bauen, es für immer zu bereinigen. Duplikate, falsche Kennungen, fehlende Informationen, nicht standardisierte Werte, Benutzer, die Felder ändern, die einem anderen System gehören, Integrationen, die gute Daten mit schlechten überschreiben: All das wird zum Bereinigungsprojekt von jemandem. Die Entwurfsfrage lautet also: Welche schlechten Daten kann ich vernünftigerweise von vornherein fernhalten? Und «vernünftigerweise» zählt, denn die Antwort ist nicht, jedes Feld zu sperren, bis das System unbenutzbar ist.

Gut genug ist eine geschäftliche Definition

Bevor Sie schlechte Daten verhindern, definieren Sie gut. Es gibt keine einzelne Definition. Gut kann heissen: vollständig genug, um den Prozess zu betreiben, genau genug, um zu entscheiden, aktuell genug für die Arbeitslast, einheitlich genug, um mit anderen Systemen kombiniert zu werden, eindeutig genug, um zu wissen, welchen Kunden wir meinen, standardisiert genug für Automatisierung, nachvollziehbar genug, um zu wissen, woher es kommt. Es hängt von den Daten ab. Wenn Steve Trucking einem Handelspartner eine Rechnung stellt, muss die rechtliche Identität des Partners stimmen. Wenn jemand aus dem Vertrieb nach einem Treffen Notizen macht, braucht niemand ein Gremium, das jeden Satz genehmigt. Gut genug ist eine geschäftliche Definition; die Architektur macht sie messbar und durchsetzbar.

Verhindern Sie die teuren Fehler

Nicht jedes schlechte Feld verdient dieselbe Aufmerksamkeit. Am meisten interessieren mich Fehler mit nachgelagerten Folgen. Ein doppelter Kunde heisst zwei Verkaufshistorien, zwei Servicehistorien, zwei Sätze Kontakte, zwei externe IDs, zwei Integrationen, die dasselbe Unternehmen synchronisieren, zwei Versionen im Data Warehouse und in Data 360, und irgendwann einen Agenten, der entscheidet, welcher Kunde der echte ist. Das ist weit teurer als ein Tippfehler in einer Beschreibung. Beginnen Sie also nicht mit «Wie validieren wir jedes Feld?» Beginnen Sie mit Welche schlechten Daten schaffen das grösste geschäftliche oder architektonische Problem?, und setzen Sie dort die stärksten Kontrollen.

Offen oder gesperrt?

Das Anlegen von Accounts ist das klassische Beispiel. Sollte jede Person im Vertrieb einen Account anlegen können? Meine Antwort: Es hängt von der Governance um die Daten ab. Für die meisten kleinen und mittleren Orgs ist offenes Anlegen in Ordnung. Jemand aus dem Vertrieb trifft einen Interessenten, legt den Account an, macht sich an die Arbeit; dafür ist ein CRM da. Duplikatsregeln, Pflichtangaben und Stewardship steuern die Qualität. Ich füge keinen schwerfälligen Genehmigungsprozess hinzu, nur weil Governance verantwortungsvoll klingt.

Ändern Sie jetzt die Landschaft. Der rechtliche Kunde wird im ERP als Stammdatum geführt, fliesst mit einer ERP-Kennung in Salesforce, und das ERP ist massgeblich. Jetzt heisst offenes Anlegen zwei Wege, dieselbe gesteuerte Entität anzulegen. Wenn das ERP und der Vertrieb beide dasselbe Unternehmen anlegen, welcher Datensatz gewinnt, welche Kennung nutzen Integrationen, welcher Datensatz hält die Historie? Offenes Anlegen hört auf, eine Frage der Benutzerfreundlichkeit zu sein, und wird eine Stammdatenfrage. Wenn Accounts in einem ERP als Stammdaten geführt oder mit ihm synchronisiert werden, sperren Sie das Anlegen.

Aber völliges Sperren scheitert auch. Jemand aus dem Vertrieb hat einen Interessenten getroffen, der nicht im ERP ist, und will eine Opportunity eröffnen, und das Governance-Modell sagt «kein Account für Sie». Also wartet die Person drei Tage auf die Finanzabteilung, hängt die Opportunity an den falschen Account oder führt den Interessenten in einem Notizfeld oder einer Tabelle. Wir haben das Datenmodell geschützt und dem Geschäft geschadet.

Der Mittelweg: ein vorläufiger Datensatztyp

Hier ist der Mittelweg, den ich mag. Lassen Sie den Vertrieb den Account mit einem bestimmten Datensatztyp anlegen, einem Interessenten- oder vorläufigen Typ, und kontrollieren Sie seine Umwandlung in den gesteuerten Typ. Der Vertrieb erfasst das Unternehmen und beginnt zu verkaufen. Der Datensatz sagt klar: noch nicht im massgeblichen System etabliert. Dann wandelt ein kontrollierter Prozess ihn um: Die Finanzabteilung genehmigt ihn, oder eine Integration übergibt ihn dem ERP, das ihn entweder einem bestehenden Kunden zuordnet oder einen neuen anlegt und die massgebliche Kennung zurückschickt. Jetzt überschreitet der Datensatz eine Grenze, vorläufig → gesteuert, was etwas ganz anderes ist, als wenn zwei Systeme jeweils anlegen, was sie für den Stammdatensatz halten.

Der Datensatztyp ist der Mechanismus, den ich unterrichte. Was immer Sie verwenden, machen Sie den Zustand in den Daten sichtbar: woher der Datensatz kam, ob er die Grenze überschritten hat, wer ihn jetzt ändern darf, und die Kennung, die ihn mit dem massgeblichen System verbindet. Die ERP-Kunden-ID, die erst nach der Umwandlung existiert, ist das klarste Signal von allen.

Ein Datensatztyp pro Datenfluss

Legen Sie den ganzen Datenfluss auf ein Bild, und Sie sehen, warum das funktioniert. Kunden und Produkte kommen aus dem ERP herein. Opportunities und ihre Positionen gehen hinaus und werden zu Aufträgen im ERP. Und Accounts? Manche kommen herein, manche gehen hinaus. Ein gängiges Muster, das ich über viele Implementierungen hinweg gesehen habe, sind deshalb zwei Datensatztypen auf Account, einer für jede Richtung. Ein Sales-Account entsteht in Salesforce: Der Vertrieb legt ihn an, bearbeitet ihn, verkauft an ihn, und wenn daraus ein Kunde wird, wird er ins ERP geschickt. Ein ERP-Account (ich habe ihn auch Customer oder einfach SAP genannt) entsteht im ERP und kommt über die Integration herein. Niemand ausser der Integration legt diesen Datensatztyp an, und seine Stammdatenfelder (rechtlicher Name, Adressen, Zahlungsbedingungen) sind für Benutzer:innen schreibgeschützt. Der Datensatztyp sagt Ihnen, in welche Richtung der Datensatz fliesst, also steht die Richtung der Stammdatenhoheit direkt auf dem Datensatz.

Click to enlarge

Ein Datensatztyp pro Datenfluss: Sales-Accounts gehen hinaus, ERP-Accounts kommen herein.

Den schwierigen Fall beseitigt das nicht. Jemand aus dem Vertrieb wandelt einen Lead für Steve’s Plumbing um, aber Steve’s Plumbing gibt es schon als ERP-Account, und irgendwie hat die Duplikatsprüfung ihn nicht erkannt. Jetzt führen Sie zusammen, ordnen die untergeordneten Datensätze neu zu und entscheiden, welcher Datensatz überlebt (Kapitel 6, Modul 3).

Und bleiben Sie nicht am Datensatztyp selbst hängen. Normalerweise vermeide ich Datensatztypen, wenn es keinen starken Grund für sie gibt. Ich habe sie hier verwendet, weil vor Dynamic Forms der Datensatztyp das Seitenlayout bestimmte und ein Layout die ERP-Felder schreibgeschützt zeigte. Mit Dynamic Forms können Sichtbarkeitsregeln Felder abhängig vom Wert eines Feldes ein- und ausblenden, ein Feld kann auf einer bestimmten Seite schreibgeschützt sein, und Salesforce sagt selbst, dass Dynamic Forms die Zahl der nötigen Seitenlayouts und Datensatztypen verringern (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab), beide auf Englisch). Aber schreibgeschützt auf einer Seite heisst schreibgeschützt auf dieser Seite: Die API, ein Datenimport oder eine Integration kann das Feld trotzdem schreiben. Die echte Durchsetzung ist die Sicherheit auf Feldebene oder eine Validierungsregel; Validierung in der Oberfläche ist keine Datenvalidierung (Kapitel 3, Modul 9). Datensatztypen haben ihren Platz weiterhin verdient, wenn die beiden Arten von Account unterschiedliche Auswahllistenwerte oder Geschäftsprozesse brauchen. Worauf es wirklich ankommt: Ein Feld sagt klar, woher der Datensatz kam, der ERP-Schlüssel selbst, ein Stammdaten-Kennzeichen oder eine Auswahlliste für die Quelle. Steuern Sie dann die Bearbeitbarkeit über dieses Feld.

Click to enlarge

Von vorläufig zu gesteuert: Der Vertrieb verkauft sofort; nur der massgebliche Prozess macht den Datensatz zu einem gesteuerten.

Schützen Sie den gesteuerten Datensatz

Sobald der Kunde aus dem ERP zurückkommt, sind seine ERP-ID, sein rechtlicher Name, seine Steuernummer und seine Rechnungsdaten gesteuerte Attribute. Sollte der Vertrieb sie ändern? Nicht, wenn sie dem ERP gehören. Das ist die Richtlinie aus Modul 1, die ihren Durchsetzungspunkt braucht: die ERP-ID schreibgeschützt, die rechtliche Identität kontrolliert, während der Vertrieb weiterhin Gebiet, Beziehungsnotizen und die eigenen Klassifizierungen von Salesforce bearbeitet. Das Ziel ist kein unantastbarer Account. Es ist eine klare Linie zwischen Daten, die Salesforce besitzt, und Daten, die Salesforce referenziert. (Das Präfix erp_ aus Kapitel 4 macht diese Linie im Schema sichtbar.)

Am Ende haben Sie einen Golden Record, der eigentlich ein Hybrid ist. Die Stammdatenfelder des ERP kommen herein: rechtlicher Name, Rechnungs- und Lieferadresse, Zahlungsbedingungen. Dann fügt Salesforce eigene Felder hinzu, die nie zurückgehen: eine Vertriebsbewertung, das letzte Bestelldatum, so ziemlich alles, was das Marketing nutzt. Derselbe Account, zwei Arten von Feldern, und jede Art hat eine Quelle.

Am schwierigsten sind die bidirektionalen. Angenommen, jemand im Vertrieb muss den rechtlichen Namen im ERP von Steve’s Plumbing in Steve’s Plumbing LLC ändern lassen. In denselben fünf Minuten ändert jemand im ERP ihn in Steve’s Plumbing L.L.C. Wessen Änderung gewinnt? Hier ist die Denkweise: Wenn ein Feld im ERP als Stammdatum geführt wird, ändern Sie das Feld nicht, Sie beantragen die Änderung. Entscheiden Sie, was passiert, wenn der Antrag kollidiert: Das ERP gewinnt, der Antrag wird abgelehnt, wenn sich der Wert inzwischen geändert hat, oder er wartet, bis ein Mensch ihn klärt. Und entscheiden Sie, ob zusammengehörige Felder als eine Änderung gemeinsam reisen oder einzeln. Kapitel 6 führt Kollisionen weiter aus (Schleifen und Kollisionen).

Stoppen Sie Duplikate an der Tür

Duplikate summieren sich. Fangen Sie eines ab, bevor es angelegt wird, und es ist ein kleines Problem. Finden Sie es zwei Jahre später, mit Opportunities, Kundenvorgängen, Kontakten, Rechnungen, Integrationen und Analytik an beiden, und es ist ein grosses. Modul 7 von Kapitel 3 hat die Mechanismen behandelt (Abgleichsregeln, Duplikatsregeln, eindeutige externe IDs), also unterrichte ich sie nicht erneut. Die Governance-Frage lautet: Wo müssen wir Duplizierung verhindern, und wo dulden wir sie und lösen sie später? Ein beiläufiger Marketing-Lead kann mit Unklarheit leben. Ein vom ERP gesteuerter Kunde mit Finanztransaktionen nicht.

Standardisieren Sie, was Maschinen lesen

Freitext ist wunderbar für Menschen und schrecklich, wenn ein System ihn deuten muss. Schreiben Sie Arizona, AZ, Ariz., Phoenix area und Southwest in ein Feld, das die Zuweisung steuert, und Sie haben ein Qualitätsproblem. Wenn ein Wert Automatisierung, Integration, Berichte, Sicherheit, Zuweisung oder die Aktion eines Agenten steuert, denken Sie gründlich darüber nach, wie standardisiert er sein muss. Nicht jedes Textfeld wird zur Auswahlliste, aber unterscheiden Sie Informationen, die Menschen lesen, von Informationen, auf denen Maschinen entscheiden. Die zweiten verdienen stärkere Kontrolle.

Lassen Sie Pflichtfelder keine falschen Daten erzeugen

Wir entscheiden, dass ein Feld zählt, und machen es erforderlich. Der Benutzer kennt die Antwort nicht, das System lässt ihn nicht weiter, also tippt er N/A, Unknown, 999999 oder test@test.com. Das Feld ist ausgefüllt; die Daten sind Müll. Bevor Sie etwas verlangen, fragen Sie, ob der Benutzer es an diesem Punkt tatsächlich weiss. Wenn nicht, verlangen Sie es später im Prozess, lassen Sie ein anderes System es liefern, nutzen Sie den vorläufigen Zustand oder bieten Sie ein ausdrückliches Unbekannt an, wenn unbekannt eine legitime Antwort ist. Eine Validierungsregel kann eine Richtlinie durchsetzen. Sie kann niemanden dazu bringen, etwas zu wissen, das er nicht weiss.

Jede Datengrenze braucht eine Qualitätsentscheidung

Menschen sind nicht die einzige Quelle schlechter Daten; Integrationen erzeugen sie schneller. Die Ladeliste eines Handelspartners kommt mit ein paar hundert Zeilen. Eine Handvoll hat ungültige Postleitzahlen, ein paar nennen ein unbekanntes Verteilzentrum, zwei wiederholen dieselbe Auftragsreferenz. Was passiert? Die ganze Datei ablehnen? Die guten Zeilen annehmen und die schlechten zurückschicken? Alles laden und später bereinigen? Die Ausnahmen in Quarantäne stellen? Wer wird informiert, und wie erfährt der Partner, was gescheitert ist? Es gibt keine allgemeine Antwort, aber es muss eine geben. Kapitel 4 sagte, jeder Pfeil braucht einen Mechanismus. Ergänzen Sie: Jede Datengrenze braucht eine Qualitätsentscheidung: was wir annehmen, ablehnen oder in Quarantäne stellen, und wem die Ausnahme gehört.

Click to enlarge

Jede Datengrenze braucht eine Qualitätsentscheidung.

Historische Daten sind anders

RouteDesk hält acht Jahre Historie von Steve Trucking, und ihre Qualität schwankt je nach Verteilzentrum. Sollten wir alle acht Jahre auf den heutigen Standard bereinigen, bevor wir sie verschieben? Wahrscheinlich nicht automatisch. Wofür sind sie da: tägliche Abläufe, Nachschlagen, Reklamationen, Berichte, Trendanalysen? Müssen sie alle in Salesforce, oder kann ein Teil woanders bleiben? Das Migrationskapitel geht in die Tiefe. Der Governance-Punkt: Historie braucht nicht automatisch denselben Standard wie aktive Daten. Wenn Sie Entscheidungen darauf stützen, zählt die Qualität. Wenn Sie sie zum Nachschlagen behalten, reicht vielleicht ein anderer Standard. Kennen Sie den Zweck, bevor Sie ein Vermögen ausgeben, um die Vergangenheit zu bereinigen.

Messen Sie, worauf jemand handeln wird

Governance ist nie fertig, also müssen Sie sehen, wann die Qualität abrutscht: steigende Duplikatsraten, mehr Datensätze in Quarantäne, mehr Ablehnungen bei Integrationen, sich ausbreitende Platzhalterwerte, mehr Anträge auf Umgehung, Berichte, die nicht mehr übereinstimmen. Aber bauen Sie nicht 150 Kennzahlen, um 143 davon zu ignorieren. Bei Steve Trucking sind es vielleicht Lieferungen ohne gültige Partnerreferenz, Lieferungen ohne brauchbare Adresse, wiederholte Auftragsreferenzen, abgelehnte Partnernachrichten, Accounts, die im vorläufigen Zustand feststecken. Ein Dashboard voller grüner Kreise heisst nicht, dass die Daten gut sind. Messen Sie, worauf jemand bereit ist zu handeln.

Über die Prüfung hinaus: Was KI ändert. Schlechte Daten werden zunehmend zu schlechtem Handeln. Ein Mensch bemerkt vielleicht, dass eine Telefonnummer falsch aussieht, bevor er anruft; ein Agent verwendet einfach den Wert, den er bekommt. Doppelte Kunden, veraltete Status, falsche Pflichtwerte und falsche Kennungen werden direkt zur falschen Nachricht oder zur falschen Aktualisierung. Das erhöht den Wert der Vorbeugung. Es beseitigt nicht den Bedarf an Stewardship.

Was Architekt:innen hier entscheiden

• Welche Qualitätsmängel genug Schaden anrichten, um vorbeugende Kontrollen zu rechtfertigen.
• Ob gesteuerte Datensätze frei angelegt werden, nur vom massgeblichen System oder über einen Weg von vorläufig zu gesteuert.
• Welche Attribute Salesforce besitzt und welche es nur referenziert.
• Was mit eingehenden Daten passiert, die Prüfungen nicht bestehen (annehmen, ablehnen oder in Quarantäne stellen), und wem die Ausnahme gehört.
• Welche Qualitätssignale gemessen werden, damit Stewards das Abrutschen sehen.

Sie werden nie jeden schlechten Datensatz verhindern. Die Aufgabe sind keine perfekten Daten; sie ist, zu verhindern, dass vermeidbare schlechte Daten zu teuren Daten werden. Stoppen Sie das Duplikat, bevor es zwei Jahre Historie hat. Schützen Sie die Kennung, bevor zehn Integrationen von der falschen abhängen. Lassen Sie den Vertrieb den Interessenten anlegen, aber tun Sie nicht so, als sei er der gesteuerte Kunde, bevor er es ist. Und wenn etwas Schlechtes durchkommt, sorgen Sie dafür, dass jemand es sehen, übernehmen und beheben kann.

Weiterlesen

• Salesforce-Hilfe, Things to Know About Duplicate Rules (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Salesforce-Hilfe, Break Up Your Record Details with Dynamic Forms (opens in a new tab) und Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.