Vom Kundenanruf zum Feature: Wie Konzeption bei uns wirklich abläuft

Die meisten Features unserer Branchensoftware beginnen nicht in einem Strategie-Meeting, sondern am Telefon. Ein Disponent, eine Werksleiterin, ein Buchhalter — jemand, der jeden Tag mit unserer Software arbeitet, sagt einen Satz wie: „Könnt ihr nicht auch noch …?“ Was dann passiert, entscheidet darüber, ob aus einem Wunsch ein tragfähiges Feature wird — oder eine Funktion, die niemand nutzt.

Hier ist unser Ablauf. Ungeschönt, so wie er wirklich stattfindet.

Schritt 1: Zuhören — und die Frage hinter der Frage finden

Der geäußerte Wunsch ist selten das eigentliche Problem. „Ich brauche einen Export nach Excel“ heißt fast nie, dass jemand Excel liebt — es heißt meistens: „Ich bekomme aus eurer Software eine Auswertung nicht heraus, die ich jede Woche brauche.“ Das sind zwei völlig verschiedene Features.

Deshalb ist der erste Schritt bei uns immer ein Gespräch über den Arbeitsablauf, nicht über die gewünschte Funktion: Was machst du gerade? Wie oft? Was passiert mit dem Ergebnis? Wer bekommt es danach? Erst wenn wir den Prozess verstanden haben, reden wir über Software.

Schritt 2: Einordnen — Standard, Konfiguration oder Individualität?

Jede Anforderung durchläuft bei uns dieselbe Sortierung:

• Kann der Standard das schon? Erstaunlich oft: ja, nur anders als erwartet. Dann ist die Antwort eine Schulung, kein Feature.
• Ist es eine Konfigurations-Lücke? Dann bauen wir die Option in den Standard — konfigurierbar, damit sie anderen Werken nicht im Weg steht.
• Ist es echte Individualität? Selten, aber es kommt vor. Dann wird es ein kundenspezifisches Projekt mit eigenem Konzept.

Diese Sortierung schützt das Wichtigste, das eine über Jahrzehnte gewachsene Software hat: einen Standard, der Standard bleibt. Jede Sonderlocke, die ungeprüft in den Kern wandert, zahlen später alle Kunden mit Komplexität.

Schritt 3: Aufwandsschätzung — ehrlich statt optimistisch

Unsere Aufwandsschätzungen entstehen im Entwicklerteam, nicht im Vertrieb. Wer den Code kennt, schätzt anders — und vor allem: ehrlicher. Eine Schätzung bei uns enthält immer drei Teile:

1. Die eigentliche Implementierung
2. Die Integration in bestehende Abläufe (Verwiegung, Faktura, Schnittstellen — nichts lebt isoliert)
3. Migration, Tests und Dokumentation

Der dritte Punkt ist der, der in optimistischen Schätzungen fehlt — und der Grund, warum sich Projekte anderswo verdoppeln.

Schritt 4: Konzept auf Papier, Feedback vom Werk

Vor der ersten Zeile Code entsteht ein Konzept: Masken-Skizzen, Datenfluss, Randfälle, was sich nicht ändert. Das Dokument geht an den Kunden zurück — und zwar an die Person, die angerufen hat, nicht nur an die Geschäftsführung.

Diese Schleife wirkt bürokratisch und spart in Wahrheit Wochen: Ein Missverständnis, das im Konzept auffällt, kostet einen Absatz. Dasselbe Missverständnis im fertigen Feature kostet einen Umbau.

Schritt 5: Pilot beim Anrufer

Das fertige Feature geht zuerst dorthin, wo die Anforderung herkam. Der Disponent, der den Wunsch geäußert hat, ist der beste Tester, den es gibt — er weiß genau, was er wollte, und merkt sofort, ob er es bekommen hat. Erst nach dem Pilot wandert die Funktion in den Standard und damit in das nächste Release für alle.

Warum wir das so erzählen

Weil dieser Ablauf der Kern dessen ist, was Branchensoftware von generischer Software unterscheidet: Die Nähe zwischen dem, der anruft, und dem, der den Code schreibt. Bei uns liegen dazwischen keine fünf Abteilungen — manchmal nur ein Flur.

Der Satz „Könnt ihr nicht auch noch …?“ ist seit über 30 Jahren unsere wichtigste Produktstrategie. Wir haben nicht vor, das zu ändern.