Drei Vertriebsmitarbeiter, drei Tabellen, ein Forecast
Im Forecast tritt das Problem zutage. Jeder Vertriebsmitarbeiter kalkuliert aus seiner eigenen Kopie der Preistabelle, jede Kopie hat sich ein Stück von den anderen entfernt, und die Zahl im Deal-Datensatz ist die, die der Mitarbeiter gerade vor sich hatte. Der Forecast ist die Summe dieser Zahlen. Zum Quartalsende hat die Finanzabteilung gelernt, ihn abzuwerten, der Vertrieb hat gelernt, ihn zu verteidigen, und Sie sitzen dazwischen, ohne eine einzige Zahl, hinter der Sie stehen können.
Niemand hat entschieden, den Vertrieb so zu führen. Die Tabelle war das Werkzeug einer einzelnen Person, sie hat funktioniert, sie wurde weitergereicht, und jede Kopie wurde danach unabhängig von den anderen bearbeitet. Die Kosten entstehen nicht durch die Tabelle. Sie entstehen, weil das Angebot, das der Kunde erhalten hat, und die Zahl in Ihrem System von Anfang an nie miteinander verbunden waren.
Wo die Zahl abweicht
Verfolgen Sie einen einzelnen Deal. Ein Vertriebsmitarbeiter öffnet seine Kopie der Tabelle, wählt eine Konfiguration, wendet einen Rabatt an, den er für zulässig hält, und fügt die Summe in eine Dokumentvorlage ein. Das ist die erste Abweichung: Die Tabelle hat eine Zahl, das Dokument hat nach einer manuellen Änderung womöglich eine andere.
Dann trägt der Mitarbeiter einen Wert in den Deal-Datensatz ein. Zweite Abweichung: Es ist eine Zusammenfassung, gerundet, möglicherweise aus dem Gedächtnis, möglicherweise vom Stand vor der letzten Überarbeitung.
Ein Rabatt über dem üblichen Niveau wird in einem Chat oder über den Schreibtisch hinweg abgestimmt. Dritte Abweichung: Die Freigabe existiert, aber an keiner Stelle, die der Datensatz kennt.
Und schließlich ändert sich die Tabelle selbst. Jemand aktualisiert einen Preissatz, die Kopie auf einem anderen Laptop bleibt, wie sie ist, und zwei Mitarbeiter bieten dasselbe Produkt nun zu unterschiedlichen Preisen an. Vier Abweichungspunkte pro Deal machen eine übereinstimmende Zahl zur Ausnahme.
Den Rechner zu den Daten bringen
Die Lösung besteht darin, die Preislogik dorthin zu verlegen, wo der Deal ohnehin liegt: als native Erweiterung des CRM. Der Mitarbeiter öffnet den Deal, konfiguriert und kalkuliert das Angebot dort, und die Summe steht im Datensatz, weil sie genau dort berechnet wurde. Keine Zahl wird kopiert, weil es keinen zweiten Ort gibt.
Genau das haben wir gebaut: den Rechner und die Dokumentabläufe als native Erweiterungen im CRM eines Kunden, im selben Projekt, aus dem auch das Trust Center in Schluss mit Sicherheits-PDFs per E-Mail hervorgegangen ist.
Das ist kein weiteres Werkzeug, gegen das der Vertrieb sich wehren müsste. Es nimmt eines weg, und mit ihm den Wechsel zwischen Tabelle, Dokumentvorlage und CRM. Weniger Schritte sind das Versprechen; die Governance kommt dazu, ohne dass jemand danach gefragt hat. Komplexe Preisgestaltung ist das stärkste Argument gegen eine Tabellenkalkulation, nicht dafür: Regeln, die in Zellformeln vergraben sind, gehen kaputt, sobald die Datei kopiert wird, während eine versionierte Preislogik gelesen und getestet werden kann.
Freigaben innerhalb des Ablaufs
Die Freigabeschwelle ist die Regel, die festlegt, welche Rabatte ein Mitarbeiter allein gewähren darf, welche eine Führungskraft brauchen und welche die Finanzabteilung. Heute lebt sie in den Köpfen der Beteiligten und wird auf dem Flur durchgesetzt. Innerhalb des Ablaufs ist sie Teil der Preislogik: Ein Angebot, das die Schwelle überschreitet, wartet auf die Freigabe, bevor das Dokument erzeugt werden kann, und die Entscheidung, die freigebende Person und der Zeitpunkt werden in den Deal-Datensatz zurückgeschrieben.
Das ist keine zusätzliche Bürokratie. Das Gespräch findet ohnehin statt; es hinterlässt nur keine Spur. Wird es festgehalten, hat die Finanzabteilung eine Liste aller Ausnahmen und weiß, wer ihnen zugestimmt hat.
Die Schwelle im Rechner selbst durchzusetzen, ist das Vorgehen, das wir empfehlen, sobald er im Deal-Datensatz liegt: Die Regel hat dann einen Ort, an dem sie lebt, und die Entscheidung einen Ort, an dem sie festgehalten wird.
Was jede Seite gewinnt
Der Vertrieb gewinnt Geschwindigkeit. Das Angebot entsteht dort, wo der Deal ist, das Dokument kommt aus demselben Datensatz, und niemand gleicht am Monatsende zwei Zahlen miteinander ab.
Die Finanzabteilung gewinnt Belege. Eine versionierte Preislogik, verantwortet von der Finanzabteilung und nicht von demjenigen, der die Datei zuletzt geöffnet hat, sodass eine Preisänderung alle Mitarbeiter gleichzeitig erreicht und hinter jedem Rabatt über der Schwelle ein Name steht.
Für IT und Einkauf besteht der Gewinn in dem, was ausbleibt: kein neues System, das gekauft werden muss, kein neuer Login, der verwaltet werden muss, keine neue Integration, die am Leben gehalten werden muss. Die Logik läuft in einer Plattform, die Sie bereits administrieren, unter Zugriffsregeln, die Sie bereits festgelegt haben. Und was Sie in ein anderes CRM mitnehmen würden, ist ein aufgeschriebener Satz von Regeln, kein Ordner voller Tabellen.
Wenn Sie gerade mitten in der Migration auf ein neues CRM stecken, ist das der Grund, nicht zu warten. Entwerfen Sie die Preislogik jetzt, auf Papier, und setzen Sie sie einmal um, im Zielsystem.
Wo die Tabellenkalkulation weiterhin gewinnt
Nichts davon macht die Tabellenkalkulation nutzlos. Eine neue Preisstufe modellieren, prüfen, was ein Mengenrabatt über die Deals des letzten Jahres mit der Marge macht, oder ein Szenario für eine Vorstandsvorlage aufbauen: Das sind Aufgaben für die Tabellenkalkulation, und das sollten sie bleiben. Die Tabellenkalkulation ist der Ort, an dem die Finanzabteilung entscheidet, wie die Regeln lauten sollen. Das CRM ist der Ort, an dem die Regeln auf einen echten Kunden angewendet werden. Die Schwierigkeiten beginnen, wenn eine Datei beides versucht.
