Fachbeitrag · Wirtschaftsinformatik ·
CRM-Datenmodell: Warum eine Person, ein Unternehmen und eine Rolle getrennte Objekte sind
Eine Ansprechperson ist weder automatisch ein Kunde noch dauerhaft eine Entscheiderin. Im CRM beschreiben Person, Organisation und Beteiligung unterschiedliche Sachverhalte. Werden sie in einem einzigen Datensatz vermischt, entstehen Dubletten, widersprüchliche Zuständigkeiten und fehlerhafte Auswertungen. Eine Beziehung mit eigener Gültigkeit ist häufig aussagekräftiger als ein zusätzliches Freitextfeld am Kontakt.
Identität und Beziehung unterscheiden
Eine Person kann für mehrere Organisationen tätig sein und in unterschiedlichen Vorhaben verschiedene Aufgaben übernehmen. Der Personenstammsatz beschreibt ihre Identität, der Organisationsstammsatz das Unternehmen. Eine Beziehung verbindet beide und trägt beispielsweise Funktion, Zeitraum und fachliche Zuständigkeit. Eine weitere Beziehung kann dieselbe Person einem konkreten Verkaufsprojekt zuordnen. So muss eine geänderte Projektrolle nicht die allgemeine Stellenbezeichnung überschreiben. Stabile interne Schlüssel verhindern, dass eine Namensänderung wie ein neuer Mensch behandelt wird.
Ein überschaubares Beispiel
Ein technischer Ansprechpartner unterstützt zunächst die Produktauswahl und später die Abnahme. Gleichzeitig betreut er als externer Berater ein zweites Unternehmen. Zwei kopierte Kontaktkarten würden Änderungen auseinanderlaufen lassen. Ein gemeinsamer Personenbezug mit getrennten Beziehungen erhält dagegen den Zusammenhang. Für das erste Projekt kann die Rolle im Auswahlverfahren gelten, für das zweite eine beratende Aufgabe. In einer Kontaktliste sind das zwei Beteiligungen, aber weiterhin nur eine Person. Diese Unterscheidung verändert auch die Bedeutung einer Kontaktzählung.
Import und Auswertung darauf ausrichten
Beim Import müssen Schlüssel für Personen, Organisationen und Beziehungen getrennt geprüft werden. Eine gleiche geschäftliche E-Mail-Adresse kann ein Hinweis sein, ist aber keine universell sichere Identitätsregel. Funktionspostfächer und wechselnde Adressen erfordern zusätzliche Prüfung. Berichte sollten ausdrücklich zwischen Personen, aktiven Beziehungen und Projektbeteiligungen unterscheiden. Ein gemeinsamer Testdatensatz mit mehreren Firmenbezügen zeigt früh, ob Schnittstellen und Exporte diese Struktur erhalten oder versehentlich wieder zu einer flachen Liste vereinfachen.
Grenzen des Modells beachten
Ein feineres Datenmodell erzeugt noch keine verlässlichen Angaben. Fachlich zuständige Personen müssen Rollen, Gültigkeit und widersprüchliche Zuordnungen pflegen können. Für Beziehungen sind klare Änderungsregeln sinnvoll: Was endet beim Firmenwechsel, welche Projektbeteiligung bleibt bestehen und welcher historische Bezug wird benötigt? Zu viele kaum genutzte Beziehungstypen erschweren die Arbeit. Entscheidend ist deshalb ein Modell, das die tatsächlichen Abläufe abbildet, verständlich bleibt und bei Suchfunktionen, Berechtigungen sowie Berichtszahlen dieselbe Bedeutung verwendet.
Für eine Abnahme eignen sich bewusst mehrdeutige Beispiele: ein Rollenwechsel ohne Firmenwechsel, zwei Personen mit gleichem Namen und eine gemeinsame Kontaktadresse. Erwartete Suchergebnisse und Zählwerte werden vorab festgelegt und anschließend gegen die tatsächliche Ausgabe geprüft.
Technical article · Business informatics ·
CRM data models: Why a person, an organisation and a role are separate objects
A contact person is not automatically a customer or a permanent decision maker. In a CRM system, people, organisations and participation describe different facts. Combining them in one record can create duplicates, conflicting responsibilities and misleading reports. A relationship with its own validity period is often more informative than another free-text field on a contact.
Separate identity from relationships
One person can work with several organisations and perform different tasks in different initiatives. The person record describes identity, while the organisation record describes the business. A relationship connects them and can carry a function, time interval and responsibility. Another relationship can connect the same person to a particular sales opportunity. A change in project role then need not overwrite a general job title. Stable internal identifiers prevent a change of name from being treated as a new person.
A manageable example
A technical contact initially supports product selection and later acceptance. At the same time, the person advises a second organisation as an external specialist. Two copied contact cards would allow subsequent changes to diverge. A common person reference with separate relationships preserves the connection. One project can record participation in selection, while another records an advisory task. A contact list therefore contains two instances of participation but still only one person. This distinction also changes what a contact count means.
Align imports and reporting
Imports need separate checks for person identifiers, organisation identifiers and relationship identifiers. A matching business email address can be evidence, but it is not a universally safe identity rule. Shared mailboxes and changing addresses require additional review. Reports should explicitly distinguish people, active relationships and opportunity participants. A common test dataset containing several company relationships reveals whether interfaces and exports preserve this structure or silently flatten it into a list that no longer carries the original meaning.
Recognise the limits of the model
A more detailed model does not make information reliable by itself. Responsible users need ways to maintain roles, validity periods and conflicting assignments. Relationship changes need understandable rules: what ends after a company move, which project participation continues, and which historical relationship remains relevant? Too many rarely used relationship types make daily work harder. The objective is therefore a model that reflects real processes, remains understandable, and uses the same business meaning in search, access control and reporting figures rather than merely adding more fields.
Acceptance tests can deliberately include ambiguous examples: a role change without a company change, two people sharing a name and a shared contact address. Define the expected search results and counts in advance, then compare them with the actual output.