Niemand merkt bei einem Standort, dass er falsch gewählt hat. Er merkt es beim fünften.
Fast niemand merkt, dass er das falsche System gewählt hat, solange er einen Standort betreibt. Bei einem Standort ist die Software in Ordnung. Sie ist es auch bei zweien. Irgendwo beim vierten oder fünften hört sie auf, es zu sein — und das, was gebrochen ist, stand auf keiner Funktionsliste, die irgendjemand verglichen hat.
So sieht es in jedem Anforderungsdokument aus, das uns erreicht hat, und genau deshalb lohnt sich das hier auch dann, wenn Sie heute einen einzigen Standort führen. Die Fragen, die darüber entscheiden, ob ein System Ihr Wachstum überlebt, sind die, mit denen Sie noch nichts zu tun haben. Und genau deshalb stellt sie niemand.
Beginnen wir mit der Version, die Sie vermutlich schon erlebt haben.
Es ist Donnerstagabend und auf dem Tisch liegt ein Angebot für ein neues System. Die Funktionsliste geht über zwei Seiten und hinter jeder Zeile steht ein Haken. Stundenpläne, Buchungen, Zahlungen, Anwesenheit, Elternkommunikation, Berichte. Haken, Haken, Haken, Haken.
Der erste Gedanke ist Erleichterung. Die können ja alles.
Der zweite kommt eine Minute später und ist unangenehmer: ein Haken hinter einer Funktion heißt nicht, dass Sie sie nächste Woche nutzen können. Er kann heißen das richten wir Ihnen beim Onboarding ein. Er kann heißen das würden wir Ihnen entwickeln. Manchmal heißt er das steht auf der Roadmap. Drei völlig verschiedene Zukünfte, ein identischer Haken — und nichts auf der Seite sagt Ihnen, welche Sie gekauft haben.
Diese Lücke ist keine Kleinigkeit. Bent Flyvbjerg und Alexander Budzier haben für die Harvard Business Review 1.471 IT-Projekte untersucht und festgestellt, dass eines von sechs nicht nur teurer wurde: es wurde ein anderes Projekt als das genehmigte, mit im Schnitt 200 % Kostenüberschreitung und fast 70 % Terminüberschreitung. Der Mechanismus ist langweilig und wiederholt sich. Ein Umfang, auf den sich beide Seiten nie genau geeinigt haben, weil ihn niemand präzise genug aufgeschrieben hat, dass man ihn hätte verletzen können.
Vier Dokumente kamen an, und sie waren nicht das, was wir erwartet hatten
Zwischen 2024 und 2026 haben uns mehrere Netzwerke mit mehreren Standorten ein formelles Anforderungsdokument geschickt, bevor sie sich zu irgendetwas verpflichtet haben. Eine Tabelle mit Prioritäten. Eine geschriebene Spezifikation mit skizziertem Datenmodell. Eine schlichte Fragenliste nach der ersten Demo, die sich als die schärfste der drei herausstellte.
Wir hatten Funktionslisten erwartet. Bekommen haben wir etwas anderes, und es hat uns das hier beigebracht: die Funktionsliste ist der Teil, der am wenigsten unterscheidet. Auf Stundenpläne, Zahlungen und Anwesenheit ist jeder ernsthafte Anbieter vorbereitet. Dort verliert niemand eine Ausschreibung.
Entschieden hat ein anderer Satz Fragen — jene, mit denen ein Einzelstandort nie zu tun hat — und eine Art zu fragen, die die meisten Käufer nie verwenden.
Also haben wir das Ganze veröffentlicht: 75 Fragen in 15 Themenfeldern, zusammengeführt und anonymisiert, sodass sich keine einzige Zeile auf eine Quelle zurückführen lässt, und unter jeder steht unsere eigene Antwort. Kostenlos, für uns und für alle anderen.
Hier ist die Kurzfassung.
Die Theorie: sortieren Sie zuerst Ihre eigene Liste, in vier Körbe
Das Nützlichste hat jedes dieser Netzwerke vor dem ersten Anbieterkontakt getan.
Es hat die eigenen Anforderungen sortiert: Muss, Sollte, Könnte, Wird nicht. Das ist MoSCoW — der Name ist nichts als diese vier Anfangsbuchstaben mit zwei kleingeschriebenen o’s dazwischen, damit man ihn aussprechen kann, und mit der Stadt hat er nichts zu tun. Dai Clegg hat es 1994 entwickelt und später dem DSDM Consortium übergeben, was bedeutet: es ist ein anerkannter Standard, und ein Anbieter, der eine so sortierte Liste bekommt, weiß bereits, was die Kategorien bedeuten.
Zwei Dinge sorgen dafür, dass daraus nicht bloß eine weitere farbige Tabelle wird.
Der Muss-Test. Fragen Sie, was passiert, wenn eine Anforderung nicht erfüllt wird. Lautet die ehrliche Antwort, dass Sie das Projekt abbrechen würden, ist es ein Muss. Wenn nicht, ist es keines. Die meisten markieren alles als unverzichtbar und markieren damit nichts.
Die Aufwandsverteilung. DSDM schlägt vor, dass Muss nicht mehr als etwa 60 % des Aufwands ausmacht, der Rest etwa 20 zu 20. Sind 90 % Ihrer Liste ein Muss, haben Sie sie noch nicht priorisiert — und ein Anbieter kalkuliert es, als hätten Sie es ernst gemeint.
Und dann ist da der vierte Korb, den alle leer lassen. Aufzuschreiben, was Sie nicht kaufen, ist das, was nach einem halben Jahr das Ausufern des Umfangs stoppt. Und es verhindert, dass ein Anbieter Ihnen eine Plattform für ein Problem anbietet, das Sie bewusst nicht lösen wollten. Ein Ausschluss, der nur in Ihrem Kopf existiert, wird wieder aufgemacht. Einer, der schriftlich beantwortet ist, nicht.
Die Praxis: verlangen Sie fünf Zustände, niemals einen Haken
Das ist die Korrektur für jenes Donnerstagsangebot. Lehnen Sie Ja und Nein ab. Lassen Sie jede Zeile in einem von fünf Zuständen landen:
- Standardmäßig vorhanden — diese Woche nutzbar, mit einem Link in die Produktdokumentation des Anbieters, nicht auf eine Marketingseite, damit Sie es ohne ihn prüfen.
- Richten wir mit Ihnen ein — real, aber Einrichtungsarbeit beim Onboarding, kein längst umgelegter Schalter. Fragen Sie, wer es macht, wie lange es dauert und ob es inklusive ist.
- Würden wir entwickeln — heute nicht vorhanden. Schriftlich, mit Termin, und fragen Sie, wer es danach pflegt; ein ungepflegter Sonderzweig ist schlechter als keine Entwicklung.
- Nicht im Produkt — nicht vorhanden und nicht schöngeredet. Als Phase zwei kalkuliert, oder gestrichen.
- Außerhalb des Umfangs, einvernehmlich — Ihr eigener Ausschluss, trotzdem beantwortet, damit die Linie hält.
Ein Anbieter, der wir haben das nicht von wir könnten das entwickeln trennt, ist das größte Risiko der ganzen Übung. Diese Unterscheidung ist für Sie mehr wert als jede Funktion auf der Liste.
Die Fragen, die ein Netzwerk stellt und ein Einzelstandort nie
Fünf Themenfelder kamen in jedem Netzwerkdokument vor und in fast keinem von einem Einzelstandort. Da dies unsere Seite ist, stehen unsere Antworten gleich daneben — und alle verlinken in unsere Produktdokumentation, nicht ins Marketing, also genau den Standard, den wir Ihnen eben für alle empfohlen haben.
Datentrennung. Fragen Sie, ob die Trennung zwischen Franchisenehmern architektonisch ist oder eine Berechtigungseinstellung, die jemand falsch setzen kann. In Zooza ist jeder Standort ein eigenes Konto; der Franchisegeber verbindet sie zu einem Netzwerk, das der Zentrale Reporting über alle hinweg gibt. Ein Franchisenehmer sieht die Daten eines anderen nicht, weil sie nicht in seinem Konto liegen. Und zieht eine Familie wirklich um, überträgt der Sammeltransfer ihre Forderung, ihr Guthaben, Notizen und Ihre eigenen Felder, mit einer Probeansicht — und wir dokumentieren auch, was nicht mitgeht, weil Zahlungshistorie und Lastschriftmandate dem ursprünglichen Unternehmen gehören.
Franchisegebühren. Fragen Sie, auf welcher Basis die Zahl entsteht — fakturiert, eingegangen, nach Rückerstattungen, ohne Umsatzsteuer — und legen Sie das fest, bevor Sie Anbieter vergleichen, denn sie nehmen nicht dasselbe an. Fragen Sie dann, ob die Gebühr nachträglich berechnet oder an der Quelle einbehalten wird; das sind zwei verschiedene Umsetzungen. Unsere wird in der Network Application aus echten Transaktionen nach den Regeln Ihres Netzwerks berechnet und steht neben eingegangenen Zahlungen, Nettoumsatz und offenen Forderungen, die Basis ist also sichtbar. Der Einbehalt an der Quelle hängt davon ab, wie jeder Standort kassiert, und den kalkulieren wir, statt ihn zu behaupten.
Standardisierung. Die Frage ist nicht kann man standardisieren, sondern welcher Mechanismus macht den Standard zum Normalfall. Unserer ist Kopieren: ein neuer Standort entsteht durch Kopieren eines Musterprogramms samt Klassen, wobei sich der Terminplan selbst auf die neuen Daten verschiebt. Produktcodes der Zentrale halten unterschiedlich benannte Programme vergleichbar. Und die ehrliche Hälfte: es gibt keinen einzelnen Knopf, der einen Preis in allen Standorten gleichzeitig ändert, weil Programme in jedem Konto liegen. Das ist der Preis der Eigenständigkeit der Franchisenehmer, und wir sagen es lieber.
Netzwerk-Reporting. Fast jedes Dokument enthielt eine Zeile im Sinne von eine automatische Version der Dashboards, die wir von Hand führen. Fragen Sie, was netzwerkweit ohne Individualentwicklung berichtet wird und ob es Standort gegen Standort schneidet. Unseres deckt Anmeldungen, Zahlungen, Nettoumsatz, offene Forderungen, Gebühren und Termine nach Unternehmen, Ort, Produkt und Zeitraum ab, mit einem Umschalter Unternehmen/Orte für Franchisenehmer mit mehreren Hallen. Der Lebenszeitwert ist die Lücke — der verlässt das System über Power BI oder einen Export.
Lokalisierung. Das unterschätzen Netzwerke am meisten, und genau hier ist ein Adjektiv wertlos. Akzeptieren Sie nicht das System ist mehrsprachig; fragen Sie, welche Hälfte, und dann nach allem, was nicht Sprache ist. Unsere Antwort ist eine Liste, keine Behauptung: Rechnungssysteme je Markt (Fakturoid für CZ/SK, Számlázz.hu für Ungarn, SmartBill und Oblio für Rumänien, ABRA Flexi, Xero international), Buchhaltungsexporte je Markt (Omega, Pohoda, SAP) und Zahlungswege je Region — FastPay für britisches BACS-Lastschriftverfahren, Global Payments über EU/EWR mit eigenem Konto je Rechtsträger, GoCardless, Stripe. Sprache sind drei unabhängige Einstellungen, das Büro kann also in einer arbeiten und Eltern in einer anderen lesen.
Und das, wonach alle zu fragen vergessen
Der Anbieter zeigt eine saubere Anmeldung. Ihre tatsächliche Woche besteht aus Probestunden, Wartelisten, verpassten Terminen, einem Kind das in Woche sechs dazukommt, einem Kind das in die nächste Gruppe wechselt, und einem Elternteil das zum Ende des nächsten Monats aufhören will, nicht heute.
In dieser Lücke leben die Verwaltungsstunden. Das meiste davon fangen drei Fragen ein:
- Lässt sich eine Kündigung auf ein künftiges Datum legen, nicht nur „jetzt oder nie”? Es wirkt kleinlich und kommt ständig vor. Unsere ja, und sie lässt sich widerrufen.
- Wird der Preis eines Nachrückers anteilig und automatisch berechnet — und finden Sie alle, die spät eingestiegen sind? In Zooza sind späte Buchungen ein vollwertiger Fall: pro Programm wählen Sie, ob sie deaktiviert sind, eine Freigabe brauchen oder sich selbst bestätigen, ob der Preis sinkt, und jede trägt einen eigenen Status, Sie finden sie also per Filter und nicht per Prüfung.
- Wenn das Jahr wechselt, wie rücken weitermachende Kinder auf? Unseres ist eine dokumentierte Checkliste — neue Perioden, jede weiterlaufende Klasse kopieren, damit sich der Plan selbst verschiebt, entscheiden, ob die Buchungen mitgehen, und die Auto-Anmeldung schreibt die bleibenden Familien erneut ein. Was Zooza nicht tut, ist von allein zu errechnen, dass ein Kind eine Jahrgangsstufe aufgestiegen ist; Ihre Struktur bilden wir einmal ab, und die September-Umstufung läuft darauf. Konfiguration, keine Zauberei.
Wo wir dabei sind, zwei weitere Dinge zum Mitnehmen in die eigene Liste. Kapazität sind in Zooza zwei Zahlen: das Buchungsformular sieht immer nur die Kapazität, während Nachholstunden und Probestunden auch die Zusatzkapazität sehen — eine Halle für sieben wird also als fünf plus zwei verkauft, und zwei Plätze bleiben denen, die sie bekommen sollen, ohne dass je überbucht wird. Und geteilte Termine lassen zwei Klassen im selben Raum zur selben Zeit gegen die echte Raumkapazität zählen, statt zwanzig Personen in zehn Plätze zu buchen. Die ist im Produkt als Beta gekennzeichnet, und das hören Sie besser hier, als dass Sie das Label selbst finden.
Das beste Signal ist immer noch ein Nein
Stellen Sie gegen Ende noch eine Frage laut: wofür sollten wir Sie nicht einsetzen?
Ein Anbieter mit einer klaren Antwort zeigt Ihnen die Kanten dessen, was Sie kaufen, und diese Information bekommen Sie anders nicht. Ein Anbieter, der jeder Zeile Ihres Dokuments zugenickt hat, hat es entweder nicht richtig gelesen oder nennt Ihnen die Grenzen nicht — und Sie finden sie selbst, später und auf eigene Kosten.
Was in beide Richtungen gilt, also hier einige von unseren, auf unserer eigenen Seite gedruckt neben den Dingen, auf die wir stolz sind: Warnungen zum Ablauf von Zertifikaten der Lehrkräfte sind nicht im Produkt, und eine Notiz ist keine Erinnerung. Es gibt keinen einzelnen Knopf für eine netzwerkweite Preisänderung. Lebenszeitwert-Reporting verlässt das System über Power BI, statt als Standardbericht zu kommen. Automatisches Löschen nach Aufbewahrungsfrist ist eine Frage an uns, keine Behauptung. Geteilte Termine sind Beta.
Nichts davon veröffentlicht sich angenehm. Alles davon ist für beide Seiten billiger, als es im vierten Monat herauszufinden.
Und „heute nicht im Produkt” ist nicht derselbe Satz wie „nein”. Bei jeder dieser Zeilen auf unserer Seite steht auch die Möglichkeit, darum zu bitten, denn ein guter Teil dessen, was Zooza heute kann, ist genau dadurch entstanden, dass ein Netzwerk es in genau so einem Gespräch angesprochen hat. Eine Lücke, die Sie sehen und zu der Sie fragen können, ist für Sie mehr wert als ein Haken, den Sie nicht prüfen können — und das ist am Ende das ganze Argument.
Alle 75 Fragen finden Sie hier, unter jeder unsere Antwort. Haken Sie die ab, auf die es Ihrem Netzwerk ankommt, drucken Sie das Ergebnis als ersten Entwurf Ihres eigenen Anforderungsdokuments und nehmen Sie es zu allen mit, mit denen Sie sprechen — uns eingeschlossen.
Quellen. Bent Flyvbjerg & Alexander Budzier, „Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, September 2011 — eine Studie von 1.471 IT-Projekten, in der eines von sechs ein „schwarzer Schwan” mit durchschnittlich 200 % Kostenüberschreitung und fast 70 % Terminüberschreitung war. MoSCoW-Priorisierung — 1994 von Dai Clegg entwickelt, später an das DSDM Consortium übergeben. Jede genannte Fähigkeit von Zooza verweist auf unsere Produktdokumentation unter help.zooza.online.
