CRM-Anforderungen: welche Felder Pflicht?

Irgendwann liegt in jedem CRM-Projekt die Feldliste auf dem Tisch. Siebzig Properties, manchmal mehr. Die Frage ist dann nicht, welche davon du haben möchtest. Die Frage ist, welche davon Pflicht werden.

Diese Entscheidung fällt fast immer aus einer bestimmten Perspektive: aus der Sicht dessen, der später das Reporting bekommt. Wer auswerten will, wie lange ein Projekt vom Start bis zur Übergabe braucht, macht geplanten Start und geplantes Ende zu Pflichtfeldern. Der Gedanke ist richtig. Er hat nur eine Voraussetzung, die selten jemand prüft.

Ein Pflichtfeld setzt voraus, dass die Person, die es ausfüllt, die Antwort überhaupt hat. In Projektgeschäften mit vorgelagertem Partner hat sie die oft nicht.

Die Entscheidung, die niemand protokolliert

In der Konzeptphase jedes CRM-Projekts gibt es diesen einen Termin, in dem du mit deinem Team die Felder durchgehst. Er dauert zwei Stunden, es sind viele Felder, und irgendwann setzt jemand Häkchen. Als Entscheidung dokumentiert wird selten, was dort passiert. Es sieht ja aus wie Konfiguration.

In Wahrheit entscheidest du dort, wie Menschen arbeiten. Ein Pflichtfeld ist die einzige Stelle im CRM, an der das System jemanden anhält und nicht weiterlässt. Jedes Häkchen sagt damit, was jemand zu einem bestimmten Zeitpunkt wissen muss. HubSpot beschreibt das in der eigenen Dokumentation genau so: Ist eine Property als erforderlich markiert, können Nutzer den Datensatz nicht anlegen oder aktualisieren, solange sie keinen Wert setzen.

Dass diese Entscheidung so häufig danebengeht, liegt nicht an Nachlässigkeit. Es liegt an der Besetzung des Termins. Am Tisch sitzen die Leute, die das Reporting brauchen. Die Person, die das Feld später zwanzig Mal am Tag füllt, sitzt meistens nicht dabei.

Was eine CRM-Einführung insgesamt intern kostet, haben wir an anderer Stelle aufgeschrieben: CRM-Einführung – was sie intern wirklich kostet. Hier geht es nicht um den Aufwand, sondern um eine einzelne Entscheidung darin. Es ist die, deren Folgen am längsten nachwirken, weil sie in den Daten stecken und nicht im Projektplan.

Die Prüffrage: Hat der Ausfüllende die Information?

Eine einzige Frage fängt die meisten dieser Fehler ab, und sie kostet dich pro Feld ungefähr dreissig Sekunden:

Wer füllt dieses Feld, in welchem Moment, und woher kennt er den Wert?

Drei Teile, und am dritten scheitert es. Ein Beispiel, das in Projektgeschäften regelmässig auftaucht: Geplanter Start und geplantes Ende werden Pflichtfelder, damit du später Schätzung gegen Realität auswerten kannst. Das funktioniert, solange das ausführende Unternehmen den Endkunden selbst betreut. Sobald es über einen Partner beauftragt wird, kennt es den Termin schlicht nicht. Es erfährt ihn kurzfristig, oft erst, wenn die Arbeit schon läuft.

Das Feld bleibt trotzdem Pflicht. Also wird es gefüllt. Mit einem Datum, das plausibel aussieht.

Was ein falsch gefülltes Pflichtfeld im Reporting kostet

Der Schaden ist nicht die einzelne falsche Zahl. Der Schaden ist, dass die Auswertung danach etwas anderes misst, als auf ihr steht.

Eine Abweichungsanalyse zwischen geplantem und tatsächlichem Termin misst die Planungsqualität, solange die geplanten Termine echt sind. Sind sie zur Hälfte eingetippt, um ein Formular zu schliessen, misst dieselbe Auswertung die Eingabedisziplin. Beide Berichte sehen identisch aus. Dieselbe Überschrift, dieselben Achsen, dieselbe Farbe. Nur die Frage, die sie beantworten, ist eine andere geworden, und das steht nirgends.

Daraus folgt eine unbequeme, aber belastbare Regel: Ein leeres Feld ist ehrlicher als ein erfundenes. Ein leeres Feld ist ein sichtbarer Zustand. Du kannst darauf filtern und es nachtragen. Du kannst sogar eine Auswertung darauf aufbauen, die die Lücke offen ausweist. Ein gefülltes Feld ohne Deckung dagegen ist unsichtbar. Nachträglich lässt es sich von einem echten Wert nicht mehr unterscheiden.

Pflicht am Datensatz oder Pflicht ab einer Stufe

Die meisten Fälle, in denen ein Pflichtfeld beim Anlegen scheitert, lösen sich mit einer einzigen Unterscheidung. Die Information ist nicht unbekannt, sie entsteht nur später im Prozess.

Dann gehört das Feld nicht an den Datensatz, sondern an eine Stufe. CRM-Systeme können das: Du konfigurierst eine Property so, dass sie erst verlangt wird, wenn ein Datensatz in eine bestimmte Stufe wechselt. Die Information bleibt verpflichtend, nur eben zu dem Zeitpunkt, an dem sie tatsächlich vorliegt.

Die letzte Zeile fehlt im Konzept meistens. Eine Stufen-Pflicht greift bei manueller Bearbeitung. Bewegt ein Workflow oder ein Import denselben Datensatz, greift sie nicht. Wer die Regel als Garantie für Datenqualität verkauft, verspricht mehr, als sie hält.

Der Übergabepunkt: ab welcher Stufe entsteht der Vorgang im Zweitsystem

Dieselbe Diskussion wiederholt sich eine Ebene höher, sobald ein zweites System im Spiel ist: ein ERP, ein Projekt- oder Planungswerkzeug. Dann fragst du nicht mehr, welches Feld Pflicht ist, sondern ab welcher Stufe der Vorgang im Zweitsystem überhaupt entsteht. In Konzernstrukturen mit mehreren Einheiten am selben Prozess wird daraus schnell eine konzernweite CRM-Frage, weil jede Einheit einen anderen Übergabepunkt gewohnt ist.

Beide Antworten sind vertretbar, aber sie kosten Unterschiedliches:

• Früh anlegen gibt beiden Systemen von Anfang an eine gemeinsame Vorgangsnummer. Alles, was danach passiert, hängt an einem Schlüssel. Der Preis: Auch Vorgänge, aus denen nie etwas wird, landen im Zweitsystem.
• Spät anlegen hält unqualifizierte Vorgänge draussen und das Zweitsystem sauber. Der Preis: Bis zur Übergabe existiert dieselbe Sache zweimal unter zwei Bezeichnungen, und irgendjemand pflegt beide.

Die Wahl hängt an einer einzigen Frage: Ist die grössere Gefahr Datenmüll oder Doppelerfassung? Hast du viele unverbindliche Anfragen und wenige Abschlüsse, ist es Datenmüll. Dann legst du spät an. Hast du wenige, langlaufende Vorgänge, an denen mehrere Abteilungen parallel arbeiten, ist es Doppelerfassung. Dann legst du früh an.

Was diese Frage nicht entscheidet: was im Ursprungskonzept stand. Oft wird der Übergabepunkt aus einer Vorlage übernommen, die für ein anderes Geschäftsmodell geschrieben wurde. Danach gilt er als gesetzt, und niemand fragt mehr nach.

Dass an dieser Stelle echtes Geld liegt, zeigen unsere eigenen Projekte. Bei aumico war das Ergebnis eines aufgeräumten Prozesses nicht mehr Felder, sondern weniger Reibung bis zum Angebot:

Beide Zahlen stehen nicht für „mehr Pflichtfelder“. Was sie zeigen: Die Systemgrenze und der Weg über sie hinweg sind selbst ein Kostenfaktor. Die Entscheidung darüber ist deshalb kein Konfigurationsdetail.

Warum ein schmales Testsystem eine vollständige Feldliste schlägt

Die übliche Reihenfolge lautet: erst alle Felder definieren, dann bauen, dann testen. Diese Reihenfolge hat einen Konstruktionsfehler. Eine Liste mit siebzig Properties lässt sich am Tisch nicht beurteilen. In einer Tabelle sieht niemand, ob ein Feld im laufenden Vorgang stört. Du siehst nur, ob es fachlich sinnvoll klingt, und das tut fast jedes Feld.

Schneller ist ein Umweg: ein schmales Testsystem, das nur die eine strittige Stelle abbildet. Nicht die ganze Pipeline, nicht alle Objekte. Nur der Ausschnitt, über den gestritten wird, mit echten Vorgängen und den Leuten, die später damit arbeiten.

Was du daran in einer Woche lernst und an der Liste nie:

• Ob der Wert beim Anlegen vorliegt oder nachgereicht wird. Das siehst du daran, was die Leute eintragen, wenn sie ihn nicht haben.
• Ob die Stufe, an die du die Pflicht hängen willst, im Alltag überhaupt sauber durchlaufen wird oder regelmässig übersprungen.
• Ob der Vorgang im Zweitsystem zu früh oder zu spät entsteht. Erkennbar ist das daran, wo Leute anfangen, parallel Listen zu führen.

Das ist keine Aufforderung, Konzeptarbeit zu überspringen. Es ist eine Aussage darüber, welche Fragen ein Konzept beantworten kann und welche nicht. Reihenfolgen, Zuständigkeiten und Objektmodell gehören ins Konzept. Ob ein bestimmtes Feld beim Anlegen ausfüllbar ist, gehört in den laufenden Vorgang.

Der Einwand, und warum er recht hat

Schlägst du vor, weniger Felder auf Pflicht zu setzen, kommt zuverlässig derselbe Einwand. Und er ist berechtigt: Der Gedanke sei nicht falsch, aber in der Praxis schwer umsetzbar. Die Frage sei nicht, ob die Daten eingepflegt werden, sondern wie richtig sie am Ende sind.

Genau. Das ist die Frage. Und sie ist der Grund für alles, was oben steht, nicht ein Gegenargument dazu.

Wer Pflichtfelder abschafft, bekommt leere Felder. Das ist kein Fortschritt. Aber wer sie dort erzwingt, wo die Information fehlt, bekommt gefüllte Felder ohne Deckung. Und das ist schlechter, weil es aussieht wie ein Ergebnis. Die Alternative zu „Pflicht überall“ ist nicht „Pflicht nirgends“, sondern Pflicht dort, wo die Antwort vorliegt, und eine Stufe später dort, wo sie erst entsteht. Dann ist die Vollständigkeit erzwungen und die Richtigkeit möglich.