Nikt nie odkrywa przy jednej lokalizacji, że wybrał źle. Odkrywa to przy piątej.

Prawie nikt nie odkrywa, że wybrał zły system, dopóki prowadzi jedną lokalizację. Przy jednej lokalizacji oprogramowanie jest w porządku. Jest w porządku i przy dwóch. Gdzieś przy czwartej albo piątej przestaje być — a to, co pękło, nie było na żadnej liście funkcji, którą ktokolwiek porównywał.

Tak wygląda to w każdym dokumencie wymagań, który do nas trafił, i właśnie dlatego warto to przeczytać, nawet jeśli dziś prowadzicie jedno miejsce. Pytania, które decydują, czy system przeżyje wasz wzrost, to te, z którymi jeszcze nie macie do czynienia. I dokładnie dlatego nikt ich nie zadaje.

Zacznijmy od wersji, której prawdopodobnie już doświadczyliście.

Jest czwartek wieczorem i na biurku leży oferta na nowy system. Lista funkcji ma dwie strony i przy każdym wierszu jest ptaszek. Grafiki, rezerwacje, płatności, obecności, komunikacja z rodzicami, raporty. Ptaszek, ptaszek, ptaszek, ptaszek.

Pierwsza myśl to ulga. Przecież oni potrafią wszystko.

Druga przychodzi po minucie i jest gorsza: ptaszek przy funkcji nie znaczy, że można jej użyć w przyszłym tygodniu. Może znaczyć skonfigurujemy to wam przy wdrożeniu. Może znaczyć dorobilibyśmy to. Czasem znaczy jest na planie rozwoju. Trzy zupełnie różne przyszłości, jeden identyczny ptaszek — i nic na tej stronie nie mówi, którą kupiliście.

Ta luka nie jest drobiazgiem. Bent Flyvbjerg i Alexander Budzier przebadali dla Harvard Business Review 1471 projektów IT i stwierdzili, że jeden na sześć nie był tylko droższy: stał się innym projektem niż ten zatwierdzony, ze średnim przekroczeniem budżetu o 200 % i harmonogramu o prawie 70 %. Mechanizm jest nudny i się powtarza. Zakres, co do którego obie strony nigdy się dokładnie nie umówiły, bo nikt nie zapisał go na tyle precyzyjnie, by dało się go złamać.

Przyszły cztery dokumenty i nie były tym, czego się spodziewaliśmy

Między 2024 a 2026 rokiem kilka sieci z wieloma lokalizacjami przysłało nam formalny dokument z wymaganiami, zanim zobowiązały się do czegokolwiek. Arkusz z priorytetami. Pisemna specyfikacja z naszkicowanym modelem danych. Zwykła lista pytań po pierwszej prezentacji, która okazała się z tych trzech najostrzejsza.

Spodziewaliśmy się list funkcji. Dostaliśmy coś innego i nauczyło nas to tego: lista funkcji to część, która różnicuje najmniej. Na grafiki, płatności i obecności przygotowany jest każdy poważny dostawca. Tam nikt nie przegrywa przetargu.

Decydował inny zestaw pytań — te, z którymi operator jednego miejsca nie ma do czynienia — i sposób pytania, którego większość kupujących nigdy nie stosuje.

Więc opublikowaliśmy to w całości: 75 pytań w 15 obszarach, scalonych i zanonimizowanych tak, by ani jeden wiersz nie dał się przypisać do źródła, a pod każdym jest nasza własna odpowiedź. Za darmo, na nas i na wszystkich pozostałych.

Oto wersja skrócona.

Teoria: najpierw posortujcie własną listę, do czterech koszyków

Najbardziej użyteczną rzecz każda z tych sieci zrobiła jeszcze przed kontaktem z dostawcą.

Posortowała własne wymagania na musi być, powinno być, mogłoby być, nie będzie. To MoSCoW — ta nazwa to nic innego niż te cztery pierwsze litery z dwiema małymi „o” wstawionymi po to, by dało się to wymówić, i z miastem nie ma nic wspólnego. Stworzył to Dai Clegg w 1994 roku i później przekazał DSDM Consortium, co znaczy, że to uznany standard: dostawca, który dostaje tak posortowaną listę, już wie, co znaczą te kategorie.

Dwie rzeczy sprawiają, że to działa, zamiast być kolejnym kolorowym arkuszem.

Test „musi być”. Zapytajcie, co się stanie, jeśli wymaganie nie zostanie spełnione. Jeśli szczera odpowiedź brzmi, że odwołalibyście projekt, to „musi być”. Jeśli nie — nie jest. Większość ludzi oznacza jako niezbędne absolutnie wszystko, czym nie oznacza niczego.

Rozkład wysiłku. DSDM proponuje, by „musi być” nie stanowiło więcej niż około 60 % wysiłku, z resztą mniej więcej 20 na 20. Jeśli 90 % waszej listy to „musi być”, jeszcze jej nie spriorytetyzowaliście — a dostawca wyceni to tak, jakbyście mówili poważnie.

A potem jest czwarty koszyk, ten, który każdy zostawia pusty. Zapisanie, czego nie kupujecie, to to, co po pół roku zatrzymuje rozlewanie się zakresu. I nie pozwala dostawcy sprzedawać wam platformy na problem, którego postanowiliście nie rozwiązywać. Wykluczenie, które istnieje tylko w waszej głowie, zostanie otwarte ponownie. To, na które odpowiedziano na piśmie, nie.

Praktyka: żądajcie pięciu stanów, nigdy ptaszka

To jest poprawka na tamtą czwartkową ofertę. Odrzućcie tak i nie. Niech każdy wiersz wyląduje w jednym z pięciu stanów:

• Jest standardowo — do użycia w tym tygodniu, z linkiem do dokumentacji produktowej dostawcy, a nie na stronę marketingową, żebyście sprawdzili to bez niego.
• Skonfigurujemy to z wami — realne, ale to praca wdrożeniowa, nie przełącznik, który już jest włączony. Pytajcie, kto to robi, ile trwa i czy jest w cenie.
• Dorobimy to — dziś tego nie ma. Na piśmie, z terminem, i zapytajcie, kto to potem utrzymuje; nieutrzymywana gałąź na zamówienie jest gorsza niż brak budowy.
• Nie ma tego w produkcie — nie ma i nie owija się tego w bawełnę. Wycenione jako druga faza, albo wypada.
• Poza zakresem, uzgodnione — wasze własne wykluczenie, odpowiedziane i tak, żeby linia się trzymała.

Dostawca, który nie odróżni mamy to od umielibyśmy to dorobić, jest największym ryzykiem całego przedsięwzięcia. To odróżnienie jest dla was warte więcej niż jakakolwiek funkcja na liście.

Pytania, które zadaje sieć, a jedna lokalizacja nigdy

Pięć obszarów pojawiło się w każdym dokumencie sieciowym i prawie w żadnym od pojedynczej lokalizacji. Skoro to nasza strona, nasze odpowiedzi stoją tuż obok — a wszystkie linkują do naszej dokumentacji produktowej, nie do marketingu, czyli dokładnie tego standardu, którego przed chwilą poleciliśmy wymagać od wszystkich.

Rozdzielenie danych. Pytajcie, czy rozdzielenie między franczyzobiorcami jest architektoniczne, czy jest to ustawienie uprawnień, które da się zepsuć. W Zoozie każda lokalizacja to osobne konto; franczyzodawca łączy je w Sieć, która daje centrali raportowanie w poprzek wszystkich. Franczyzobiorca nie widzi danych innej lokalizacji dlatego, że nie ma ich na koncie. A kiedy rodzina faktycznie się przenosi, Masowy transfer przenosi jej dług, kredyt, notatki i wasze własne pola, z podglądem próbnym — i mamy udokumentowane również to, co się nie przenosi, bo historia płatności i mandaty należą do firmy źródłowej.

Opłaty licencyjne. Pytajcie, od jakiej podstawy liczy się ta liczba — zafakturowane, otrzymane, po zwrotach, bez VAT — i ustalcie to, zanim porównacie dostawców, bo nie założą tego samego. Potem pytajcie, czy opłata jest fakturowana po fakcie, czy pobierana u źródła; to dwa różne rozwiązania. Nasza liczona jest w Network Application z rzeczywistych transakcji według zasad waszej sieci i stoi obok otrzymanych płatności, przychodu netto i zaległości, więc podstawę widać. Pobieranie u źródła zależy od tego, jak każda lokalizacja inkasuje, i to wyceniamy, a nie twierdzimy.

Standaryzacja. Pytanie nie brzmi czy da się ustandaryzować, tylko jaki mechanizm czyni standard stanem domyślnym. Nasz to kopiowanie: nowa lokalizacja powstaje przez skopiowanie wzorcowego programu wraz z grupami, przy czym grafik sam przesuwa się na nowe daty. Kody produktów nadane przez centralę utrzymują porównywalność inaczej nazwanych programów. I szczera połowa: nie istnieje jeden przycisk, który zmieni cenę we wszystkich lokalizacjach naraz, bo programy żyją wewnątrz każdego konta. To cena za samodzielność franczyzobiorców i wolimy to powiedzieć.

Raportowanie sieci. Niemal każdy dokument zawierał wiersz w sensie automatyczna wersja pulpitów, które prowadzimy ręcznie. Pytajcie, co raportuje się dla całej sieci bez prac na zamówienie i czy tnie lokalizację przeciw lokalizacji. Nasze pokrywa zapisy, płatności, przychód netto, zaległości, opłaty i zajęcia według firmy, miejsca, produktu i okresu, z przełącznikiem Firmy/Miejsca dla franczyzobiorców z kilkoma salami. Wartość życiowa to luka — ta wychodzi przez Power BI albo eksport.

Lokalizacja. To sieci lekceważą najbardziej i właśnie tu przymiotnik jest bezwartościowy. Nie przyjmujcie system jest wielojęzyczny; pytajcie, która połowa, a potem o wszystko, co nie jest językiem. Nasza odpowiedź to lista, nie twierdzenie: systemy fakturowe według rynku (Fakturoid dla CZ/SK, Számlázz.hu dla Węgier, SmartBill i Oblio dla Rumunii, ABRA Flexi, Xero międzynarodowo), eksporty księgowe według rynku (Omega, Pohoda, SAP) i szyny płatnicze według regionu — FastPay dla brytyjskiego polecenia zapłaty BACS, Global Payments w UE/EOG z osobnym kontem dla każdego podmiotu prawnego, GoCardless, Stripe. Język to trzy niezależne ustawienia, więc biuro może pracować w jednym, a rodzice czytać w innym.

I to, o co każdy zapomina zapytać

Dostawca pokazuje czysty zapis. Wasz prawdziwy tydzień to zajęcia próbne, listy oczekujących, nieobecności, dziecko dołączające w szóstym tygodniu, dziecko przechodzące do wyższej grupy i rodzic, który chce skończyć z końcem kolejnego miesiąca, a nie dziś.

W tej luce żyją godziny administracji. Większość z niej wyłapią trzy pytania:

1. Czy anulowanie da się zaplanować na przyszłą datę, a nie tylko „teraz albo nigdy”? Wygląda drobiazgowo i wraca bez przerwy. Nasze tak, i da się je cofnąć.
2. Czy cena spóźnionego liczy się proporcjonalnie i automatycznie — i czy znajdziecie wszystkich, którzy dołączyli późno? W Zoozie spóźnione zapisy są pełnoprawnym przypadkiem: dla każdego programu wybieracie, czy są wyłączone, wymagają zatwierdzenia, czy potwierdzają się same, czy cena spada, a każdy ma własny status, więc znajdziecie je filtrem, a nie audytem.
3. Kiedy rok się przełamie, jak przechodzą kontynuujące dzieci? Nasz to udokumentowana lista kontrolna — nowe okresy, skopiować każdą kontynuowaną grupę, żeby grafik przesunął się sam, zdecydować, czy idą też zapisy, a automatyczny zapis wpisze ponownie rodziny, które zostają. Czego Zooza nie zrobi, to wydedukować sama, że dziecko weszło do wyższego rocznika; waszą strukturę mapujemy raz, a wrześniowe przejście działa na tym. Konfiguracja, nie magia.

Skoro już o tym mowa, dwie rzeczy do zabrania na własną listę. Pojemność to w Zoozie dwie liczby: formularz rezerwacji widzi zawsze tylko Pojemność, podczas gdy zajęcia do odrobienia i próbne widzą też Pojemność dodatkową — salę na siedmioro sprzedaje się więc jako pięć plus dwa, a dwa miejsca zostają tym, którzy mają je dostać, bez ryzyka przepełnienia. A zajęcia współdzielone sprawiają, że dwie grupy w tej samej sali o tej samej porze liczą się wobec rzeczywistej pojemności pomieszczenia, zamiast wpuszczać dwadzieścia osób na dziesięć miejsc. Te są w produkcie oznaczone jako beta i lepiej usłyszeć to tutaj, niż znaleźć tę etykietę samemu.

Najlepszym sygnałem wciąż jest nie

Zadajcie pod koniec jeszcze jedno pytanie na głos: do czego nie powinniśmy was używać?

Dostawca z jasną odpowiedzią pokazuje wam krawędzie tego, co kupujecie, a tej informacji inaczej nie zdobędziecie. Dostawca, który przytaknął każdemu wierszowi waszego dokumentu, albo go porządnie nie przeczytał, albo nie powie wam o ograniczeniach — i znajdziecie je sami, później i na własny koszt.

Co działa w obie strony, więc oto kilka naszych, wydrukowanych na własnej stronie obok rzeczy, z których jesteśmy dumni: ostrzeżeń o wygaśnięciu certyfikatów instruktorów w produkcie nie ma, a notatka nie jest przypomnieniem. Nie istnieje jeden przycisk na zmianę ceny w całej sieci. Raportowanie wartości życiowej wychodzi przez Power BI, zamiast przychodzić jako raport standardowy. Automatyczne usuwanie po terminie przechowywania to pytanie do nas, a nie twierdzenie. Zajęcia współdzielone są w becie.

Nic z tego nie publikuje się przyjemnie. Wszystko to jest dla obu stron tańsze niż odkrycie tego w czwartym miesiącu.

A „dziś nie ma tego w produkcie” to nie to samo zdanie co „nie”. Przy każdym takim wierszu na naszej stronie jest też możliwość poproszenia o to, bo spora część tego, co Zooza dziś potrafi, powstała właśnie dlatego, że jakaś sieć poruszyła to przy dokładnie takiej rozmowie. Luka, którą widzicie i o którą możecie zapytać, jest dla was warta więcej niż ptaszek, którego nie umiecie sprawdzić — i to jest ostatecznie cały argument.

Wszystkie 75 pytań znajdziecie tutaj, pod każdym nasza odpowiedź. Odhaczcie te, na których zależy waszej sieci, wydrukujcie wynik jako pierwszy szkic własnego dokumentu wymagań i zabierzcie go do wszystkich, z którymi rozmawiacie — nas nie wyłączając.

---

Źródła. Bent Flyvbjerg i Alexander Budzier, „Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, wrzesień 2011 — badanie 1471 projektów IT, w którym jeden na sześć był „czarnym łabędziem” ze średnim przekroczeniem budżetu o 200 % i harmonogramu o prawie 70 %. Priorytetyzacja MoSCoW — stworzona przez Dai Clegga w 1994 roku, później przekazana DSDM Consortium. Każda wspomniana możliwość Zoozy odsyła do naszej dokumentacji produktowej na help.zooza.online.