Täglich sind meine Kollegen und ich im Austausch mit den Kunden unserer Software-Lösungen und allzu oft geht es darum, dass alles toll ist, aber genau EINE Sache fehlt oder anders sein müsste.
Das Feld ist super, aber es müsste 5cm weiter oben sein, damit wir es nicht übersehen.
Die drei Anreden (Sehr geehrter Dr. Müller, Hallo Andi …), die ihr pro Kontakt automatisch generiert sind okay, ich hätte aber gerne eine andere. Ob drei oder vier ist doch nun wirklich egal oder?
Ihr habt echt das übersichtlichste Reservierungsformular, aber baut doch noch die Felder X, Y und Z ein. Dann wäre es wirklich klasse.

Was ist so hart daran, Leute wegzuschicken?

Glaubt mir, es ist irre hart. Die Leute haben sich wirklich mit Deinem Produkt beschäftigt. Sie versuchen nur ihre Arbeit einfacher oder besser zu machen. Und in den meisten Fällen ist es auch völlig nachvollziehbar, was sie so beschreiben. Und dennoch kannst Du nicht alle Ideen reinlassen. Genau wie der Türsteher haben wir unsere Vorstellungen von der Party. Der Türsteher will keinen Ärger und ein bunt gemischtes Publikum. Und je nachdem, ob es ein Mainstream Club auf den Kölner Ringen oder ein Punkrock-Laden ist, wird er seine Auswahl treffen. Bei Software as a Service ist es exakt dasselbe. Heißt Du SAP und bist bekannt dafür, dass alles irgendwie geht, dann gibt es wahrscheinlich schon jede erdenkliche Option. Und falls nicht, dann kann man sie bestimmt bekommen. Wir sind aber nicht SAP. Wir wollen einfach sein und haben daher bewusst weniger Funktionen und auch weniger Anpassungsoptionen. Und die Kunden kommen genau deshalb zu uns. Eigentlich.

Die Summe aller Teile

In der Einzelbetrachtung ist es völlig egal, ob man eine Funktion, ein Feld mehr oder weniger einbaut. Die Auswirkung auf das große Ganze wird in den seltensten Fällen spürbar sein. Ob die Excel-Exportdatei 20 oder 21 Spalten hat, ist nun wirklich egal. Leider bleibt es aber nicht bei dem einen Feld. Und ob die Datei dann 20 oder 30 Spalten hat, ist dann schon ein Unterschied.

Okay, wir wollen das Feld also nicht einbauen. Wenn man es nicht ausführlich erklärt, dann denkt der Kunde, man findet seine Idee einfach blöd. Oder man hat keine Lust. Darum geht es aber nicht. Es geht nicht um gut oder schlecht, sondern um passend. Passend zu dem, wofür die Software als Ganzes steht.

Die Drohung

Wenn nett fragen nicht hilft, dann muss der Kunde eben drohen. Haben wir alle schonmal gemacht. Positiv formuliert heißt das dann: "Wenn Sie das noch einbauen, dann buche ich auch sofort und wir werden sicher sehr lange zufriedene Kunden". Wenn das auch nicht hilft, dann "überdenken wir die Einführung nochmal". Und in diesem Punkt haben wir es endlich mal leichter in der schönen neuen Software as a Service Welt. Natürlich fänden wir es super, wenn der Kunde bleibt oder kommt. Für keinen Kunden der Welt würden wir aber eine Funktion einbauen, die eigentlich nicht in unser Konzept passt. Zum einen ist es finanziell einfach nicht entscheidend, ob der einzelne Kunde kommt oder geht. Viel wichtiger ist aber, dass wir in dem Moment den einzelnen Kunden auf die eine Seite der Waage und alle anderen Kunden auf die andere Seite legen müssen. Was würden tausende Kunden sagen, wenn wir xy machen würden? Und wenn wir unsere Kunden richtig einschätzen, dann verpufft die Drohung sofort.

Der Perspektivenwechsel

Wenn wir uns schon (gegen) eine Idee oder Veränderung entschieden haben und sogar die Drohung nicht hilft, dann gibt es noch den Perspektivenwechsel. Der Kunde weiß bereits, dass wir keine Individualsoftware bauen, sondern dass alle anderen Nutzer auch mit der Änderung leben müssten. Um uns einen letzten Schubs zu geben, hören wir dann oft das Argument, dass "ganz viele andere Kunden eine solche Funktion oder Änderung sicherlich auch klasse finden würden". Jetzt stellt sich die Frage, wer das besser einschätzen kann: Der einzelne Kunde mit dem Änderungswunsch oder derjenige, der täglich von den unterschiedlichsten Kunden hört und liest. Den Perspektivenwechsel haben wir also permanent.

Heißt das ich muss als Software-Entwickler alles ablehnen, was nicht auch zu allen anderen Nutzern passt? Nein, das muss es nicht heißen.

Customizing vs. Productizing

Customizing ist, wenn ich Dir eine Software verkaufe und sie ganz individuell auf Deine Bedürfnisse anpasse. Der Speichern Knopf soll anders heißen? Sag mir wie. Ihr braucht nicht nur die letzte, sondern die letzten drei Notizen in einer Spalte im Excel Export? Null Problemo, brauchst Du vorher ein Angebot?

Wer im Software as a Service Geschäft Customizing betreibt oder anbietet, der hat etwas grundsätzliches nicht verstanden oder macht es noch nicht allzu lange. Denn jede Funktion oder Option, die man nicht allen sondern nur einem Kunden anbietet, führt zu Geschwindigkeitseinbußen und grauen Haaren bei den Entwicklern und Supportern. Wenn ich bei einem Seitenaufruf immer dieselben Funktionen anzeige, egal ob Kunde A oder B gerade einen seiner Kunden anschaut, dann ist das schlichtweg schneller, als wenn die Software überlegen muss, ob Kunde A vielleicht noch weitere Dinge eingeblendet haben möchte. Und nicht nur Kunde A hat Geschwindigkeitseinbußen, sondern auch Kunde B, der schließlich auch wartet, während die Software herausfindet, dass bei ihm alles "Standard" sein soll.

Im Gegensatz zum Customizing baut man die Funktion beim Productizing direkt in das System ein, aber eben so dass sie für jeden gleichermaßen funktioniert. Das Wort klingt scheußlich und das Konzept klingt sehr technisch, daher ein einfaches Beispiel zu unserem Online Buchungssystem CentralPlanner:

1. Nutzer A ist Gastronom und will seine Kunden in Stammgäste und unregelmäßige Besucher unterteilen.
2. Nutzer B betreibt ein Sportcenter und seine Besucher spielen Squash oder Badminton und genau das will er auseinander halten.

Anstatt für jeden Nutzer ein Customizing zu machen könnte man auch einfach eine ganz allgemeine Schlagwort / Tag Funktion einbauen. Dann können sowohl Nutzer A, als auch Nutzer B, ihren Fall ganz locker abbilden und die Software wird auch nicht verbastelt mit Unterschieden von Kunde zu Kunde.

Super, dann Productizen wir ab sofort einfach alles, denn dann ist es ja kein Customizing und okay. Fast richtig. Zu viel Productizing führt natürlich auch zu Komplexität. Die Frage die man sich stellen muss ist also: Würde die Mehrheit meiner Kunden das Productizing benutzen ODER kann ich es so bauen, dass diejenigen die es nicht brauchen, auch gar nichts davon mitbekommen? Wenn ich den Kunden, die danach fragen, einen Analysebereich einbaue, der rein gar nichts an den sonstigen Seiten verändert, dann wäre das also auch ein Paradebeispiel für ein gelungenes Productizing.

Und was machen wir, wenn wir nicht beliebig Productizen und schon gar nicht Customizen wollen? Richtig, dann machen wir weiter den Türsteher. Nur dass wir uns die Zeit nehmen zu begründen, warum wir entscheiden, wie wir entscheiden. Aus Sicht des Kunden ist es ein himmelweiter Unterschied, ob es heißt "Nein, machen wir nicht" oder ob der Türsteher den größten Wert der Disco oder Software verteidigt - der Wert weshalb der Kunde überhaupt da ist. Nur so schafft man es diese "Kunde gegen Anbieter" Konfrontation aufzulösen und daraus ein "Kunde gegen Kunden" zu machen. Der Kunde ist dabei logischerweise auch ein Teil der anderen Kunden. Und so wird dann auch jedem klar, dass wir in dem Moment nicht gegen ihn, sondern für alle Kunden und damit auch für ihn sind.