CRM-Anforderungen: welche Felder wirklich Pflicht sind

Irgendwann liegt in jedem CRM-Projekt die Feldliste auf dem Tisch. Siebzig Properties, manchmal mehr, und die Frage ist nicht, welche davon man haben möchte. Die Frage ist, welche verpflichtend 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 geprüft wird.

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 eines CRM-Projekts gibt es einen Termin, in dem Felder durchgegangen werden. Er dauert zwei Stunden, es sind viele Felder, und irgendwann setzt jemand Häkchen. Was in diesem Termin passiert, wird selten als Entscheidung dokumentiert — es sieht aus wie Konfiguration.

Es ist aber eine Entscheidung über Arbeitsabläufe. Ein Pflichtfeld ist die einzige Stelle im CRM, an der das System einen Menschen anhält und nicht weiterlässt. Jedes Häkchen ist damit eine Aussage darüber, was jemand zu einem bestimmten Zeitpunkt wissen muss. HubSpot nennt das in seiner eigenen Dokumentation genau so: Ist eine Property als erforderlich markiert, können Nutzer den Datensatz nicht anlegen oder aktualisieren, solange sie keinen Wert setzen.

Der Grund, warum diese Entscheidung so häufig danebengeht, ist nicht Nachlässigkeit. Es ist die Besetzung des Termins. Am Tisch sitzen die Personen, 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. Dieser Artikel geht nicht auf den Aufwand ein, sondern auf eine einzelne Entscheidung darin — 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?

Es gibt eine Frage, die pro Feld ungefähr dreissig Sekunden kostet und die meisten dieser Fehler abfängt:

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

Drei Teile, und der dritte ist der, an dem es scheitert. Ein Beispiel, das in Projektgeschäften regelmässig auftaucht: Geplanter Start und geplantes Ende werden zu Pflichtfeldern gemacht, damit man später Schätzung gegen Realität auswerten kann. 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. Sie tragen 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 — man kann darauf filtern, man kann es nachtragen, man kann eine Auswertung darauf aufbauen, die die Lücke ausweist. Ein gefülltes Feld ohne Deckung ist unsichtbar und lässt sich nachträglich nicht von einem echten Wert 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: Eine Property lässt sich so konfigurieren, dass sie erst verlangt wird, wenn ein Datensatz in eine bestimmte Stufe bewegt wird. Damit ist die Information weiterhin verpflichtend — nur zu dem Zeitpunkt, an dem sie tatsächlich vorliegt.

Die letzte Zeile ist die, die im Konzept meistens fehlt. Eine Stufen-Pflicht greift bei manueller Bearbeitung — nicht, wenn ein Workflow oder ein Import denselben Datensatz bewegt. Wer die Regel als Datenqualitätsgarantie 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. Die Frage lautet dann 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, und sie haben unterschiedliche Kosten:

• 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? In einem Geschäft mit vielen unverbindlichen Anfragen und wenigen Abschlüssen ist es Datenmüll — dann spät anlegen. In einem Geschäft mit wenigen, langlaufenden Vorgängen, an denen mehrere Abteilungen parallel arbeiten, ist es Doppelerfassung — dann früh anlegen.

Was diese Frage nicht entscheidet, ist, was im Ursprungskonzept stand. Der Übergabepunkt wird oft aus einer Vorlage übernommen, die für ein anderes Geschäftsmodell geschrieben wurde, und danach als gesetzt behandelt.

Dass an dieser Stelle echtes Geld liegt, lässt sich an unseren eigenen Projekten zeigen. 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“. Sie stehen dafür, dass die Systemgrenze und der Weg über sie hinweg selbst ein Kostenfaktor sind — und dass die Entscheidung darüber deshalb kein Konfigurationsdetail ist.

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

Die übliche Reihenfolge ist: erst alle Felder definieren, dann bauen, dann testen. Sie hat einen Konstruktionsfehler. Eine Liste mit siebzig Properties lässt sich am Tisch nicht beurteilen. Niemand kann in einer Tabelle sehen, ob ein Feld im laufenden Vorgang störend ist — man sieht nur, ob es fachlich sinnvoll klingt, und das klingt fast jedes Feld.

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

Was man daran in einer Woche lernt und an der Liste nie:

• Ob der Wert beim Anlegen tatsächlich vorliegt oder nachgereicht wird — sichtbar daran, was die Leute eintragen, wenn sie ihn nicht haben.
• Ob die Stufe, an die man die Pflicht hängen will, im Alltag überhaupt sauber durchlaufen wird oder regelmässig übersprungen.
• Ob der Vorgang im Zweitsystem zu früh oder zu spät entsteht — erkennbar 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

Gegen den Vorschlag, 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 man die Daten einpflegt, 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.