Nikto nezistí, že vybral zle, pri jednej lokalite. Zistí to pri piatej.
Takmer nikto nezistí, že vybral zlý systém, kým má jednu prevádzku. Pri jednej lokalite je softvér v poriadku. Je v poriadku aj pri dvoch. Niekde pri štvrtej či piatej prestane byť — a tá vec, ktorá sa zlomila, nebola na žiadnom zozname funkcií, ktorý ste porovnávali.
Takto to vyzerá v každom zadaní, ktoré nám prišlo, a práve preto sa toto oplatí prečítať, aj keď dnes prevádzkujete jedno miesto. Otázky, ktoré rozhodujú, či systém prežije váš rast, sú tie, ktoré ešte riešiť nemusíte. A presne preto si ich nikto nepoloží.
Začnime verziou, ktorú ste pravdepodobne už zažili.
Je štvrtok večer a na stole máte ponuku na nový systém. Zoznam funkcií má dve strany a pri každom riadku je fajka. Rozvrhy, rezervácie, platby, dochádzka, komunikácia s rodičmi, reporty. Fajka, fajka, fajka, fajka.
Prvá myšlienka je úľava. Veď oni vedia všetko.
Druhá príde o minútu a je horšia: fajka pri funkcii neznamená, že ju viete použiť budúci týždeň. Môže znamenať nastavíme vám to pri nasadení. Môže znamenať dovyvinuli by sme vám to. Občas znamená je to na roadmape. Tri úplne odlišné budúcnosti, jedna a tá istá fajka — a nič na tej stránke vám nepovie, ktorú ste si kúpili.
Tá medzera nie je maličkosť. Bent Flyvbjerg a Alexander Budzier preskúmali pre Harvard Business Review 1 471 IT projektov a zistili, že jeden zo šiestich nebol len drahší: stal sa iným projektom, než aký sa schvaľoval, s priemerným prekročením rozpočtu o 200 % a harmonogramu o takmer 70 %. Mechanizmus je nudný a opakuje sa. Rozsah, na ktorom sa obe strany nikdy presne nedohodli, lebo ho nikto nenapísal dosť presne na to, aby sa dal porušiť.
Prišli štyri dokumenty a neboli také, aké sme čakali
Medzi rokmi 2024 a 2026 nám niekoľko sietí s viacerými prevádzkami poslalo formálny dokument s požiadavkami ešte predtým, než sa k čomukoľvek zaviazali. Tabuľka s prioritami. Písaná špecifikácia s načrtnutým dátovým modelom. Obyčajný zoznam otázok po prvej ukážke, ktorý sa ukázal byť z tých troch najostrejší.
Čakali sme zoznamy funkcií. Dostali sme niečo iné a naučilo nás to toto: zoznam funkcií je tá časť, ktorá rozlišuje najmenej. Na rozvrhy, platby a dochádzku je pripravený každý vážny dodávateľ. Tam tender nikto neprehrá.
Rozhodovala iná sada otázok — tie, ktoré prevádzkovateľ jedného miesta riešiť nemusí — a spôsob kladenia, aký väčšina kupujúcich nikdy nepoužije.
Tak sme to celé zverejnili: 75 otázok v 15 okruhoch, zlúčených a anonymizovaných tak, aby sa ani jeden riadok nedal dohľadať k zdroju, a pod každou je naša vlastná odpoveď. Zadarmo, na nás aj na všetkých ostatných.
Tu je skrátená verzia.
Teória: najskôr si roztrieďte vlastný zoznam, do štyroch košov
Najužitočnejšiu vec urobila každá z tých sietí ešte pred kontaktovaním dodávateľa.
Roztriedila si vlastné požiadavky na musí byť, malo by byť, mohlo by byť, nebude. To je MoSCoW — ten názov nie je nič iné než tie štyri začiatočné písmená s dvoma malými „o” navyše, aby sa to dalo vysloviť, a s mestom to nemá nič spoločné. Vymyslel to Dai Clegg v roku 1994 a neskôr to daroval DSDM Consortium, čo znamená, že je to uznávaný štandard: dodávateľ, ktorému príde takto roztriedený zoznam, už vie, čo tie kategórie znamenajú.
Fungovať namiesto ďalšej farebne označenej tabuľky mu dávajú dve veci.
Test na „musí byť”. Spýtajte sa, čo sa stane, ak požiadavka nebude splnená. Ak je úprimná odpoveď, že by ste projekt zrušili, je to „musí byť”. Ak nie, nie je. Väčšina ľudí označí za nevyhnutné úplne všetko, čím neoznačí nič.
Rozloženie úsilia. DSDM navrhuje, aby „musí byť” netvorilo viac než asi 60 % úsilia, so zvyškom približne 20 na 20. Ak je 90 % vášho zoznamu „musí byť”, ešte ste ho nepriorizovali — a dodávateľ to nacení, akoby ste to mysleli vážne.
A potom je tu štvrtý kôš, ten, čo každý nechá prázdny. Napísať si, čo nekupujete, je to, čo po pol roku zastaví rozliezanie rozsahu. A zabráni dodávateľovi ponúkať vám platformu na problém, ktorý ste sa už rozhodli neriešiť. Vylúčenie, ktoré existuje len vo vašej hlave, sa znova otvorí. To, ktoré je odpovedané písomne, nie.
Prax: žiadajte päť stavov, nikdy nie fajku
Toto je oprava tej štvrtkovej ponuky. Odmietnite áno a nie. Nech každý riadok skončí v jednom z piatich stavov:
- Je to štandardne — použiteľné tento týždeň, s odkazom do produktovej dokumentácie dodávateľa, nie na marketingovú stránku, aby ste si to overili bez neho.
- Nastavíme to s vami — je to reálne, ale je to práca pri nasadení, nie prepínač, ktorý je už prepnutý. Pýtajte sa, kto to robí, ako dlho to trvá a či je to v cene.
- Dovyvinieme to — dnes to tam nie je. Písomne, s termínom, a spýtajte sa, kto to potom udržiava; neudržiavaná zákazková odnož je horšia než žiadny vývoj.
- V produkte to nie je — nie je a nebalí sa to do obalu. Nacenené ako druhá fáza, alebo vypadne.
- Mimo rozsahu, dohodnuté — vaše vlastné vylúčenie, odpovedané aj tak, aby tá čiara držala.
Dodávateľ, ktorý nerozlíši máme to od vedeli by sme to dovyvinúť, je najväčšie riziko celého cvičenia. To rozlíšenie má pre vás väčšiu cenu než ktorákoľvek funkcia na zozname.
Otázky, ktoré si sieť kladie a jedna prevádzka nikdy
Päť okruhov prišlo v každom sieťovom zadaní a takmer v žiadnom od jednej prevádzky. Keďže toto je naša stránka, naše odpovede sú hneď vedľa — a všetky odkazujú do našej produktovej dokumentácie, nie na marketing, čo je presne ten štandard, ktorý sme vám pred chvíľou odporučili vyžadovať od všetkých.
Oddelenie dát. Pýtajte sa, či je oddelenie medzi franšízantmi architektonické, alebo je to nastavenie oprávnení, ktoré sa dá pokaziť. V Zooze je každá prevádzka samostatný účet; franšízor ich spojí do Siete, ktorá centrále dá reporting naprieč všetkými. Franšízant nevidí dáta inej pobočky preto, že ich nemá v účte. A keď sa rodina naozaj sťahuje, Hromadný presun prenesie jej dlh, kredit, poznámky aj vaše vlastné polia, so skúšobným náhľadom — a máme zdokumentované aj to, čo sa nepresunie, lebo platobná história a inkasné mandáty patria pôvodnej firme.
Licenčné poplatky. Pýtajte sa, z akého základu sa číslo počíta — fakturované, prijaté, po vratkách, bez DPH — a dohodnite to skôr, než porovnávate dodávateľov, lebo nebudú predpokladať to isté. Potom sa pýtajte, či sa poplatok fakturuje dodatočne, alebo sa sťahuje pri zdroji; to sú dve rôzne riešenia. Náš sa počíta v Network Application zo skutočných transakcií podľa pravidiel vašej siete a sedí vedľa prijatých platieb, čistého výnosu a nedoplatkov, takže základ je vidieť. Sťahovanie pri zdroji závisí od toho, ako každá pobočka inkasuje, a to nacenime, netvrdíme.
Štandardizácia. Otázka nie je dá sa štandardizovať, ale aký mechanizmus robí zo štandardu predvolený stav. Náš je kopírovanie: nová pobočka vzniká skopírovaním vzorového programu a jeho skupín, pričom sa rozvrh sám posunie na nové dátumy. Produktové kódy od centrály držia inak pomenované programy porovnateľné. A úprimná polovica: neexistuje jedno tlačidlo, ktoré zmení cenu vo všetkých pobočkách naraz, lebo programy žijú vnútri každého účtu. To je cena za samostatnosť franšízantov a radšej to povieme.
Reporting siete. Takmer každý dokument obsahoval riadok v zmysle automatická verzia dashboardov, ktoré si vedieme ručne. Pýtajte sa, čo sa reportuje za celú sieť bez zákazkového vývoja a či to reže prevádzku proti prevádzke. Náš pokrýva registrácie, platby, čistý výnos, nedoplatky, poplatky a termíny podľa firmy, miesta, produktu a obdobia, s prepínačom Firmy/Miesta pre franšízantov s viacerými sálami. Životná hodnota je medzera — tá odchádza cez Power BI alebo export.
Lokalizácia. Toto siete podceňujú najviac a práve tu je prídavné meno bezcenné. Neberte systém je viacjazyčný; pýtajte sa, ktorá polovica, a potom na všetko, čo nie je jazyk. Naša odpoveď je zoznam, nie tvrdenie: fakturačné systémy podľa trhu (Fakturoid pre CZ/SK, Számlázz.hu pre Maďarsko, SmartBill a Oblio pre Rumunsko, ABRA Flexi, Xero medzinárodne), účtovné exporty podľa trhu (Omega, Pohoda, SAP) a platobné rails podľa regiónu — FastPay pre britské BACS inkaso, Global Payments naprieč EÚ/EHP s vlastným účtom pre každý právny subjekt, GoCardless, Stripe. Jazyk sú tri nezávislé nastavenia, takže kancelária môže pracovať v jednom a rodičia čítať v inom.
A to, na čo sa zabudne každý
Dodávateľ predvádza čistú registráciu. Váš skutočný týždeň sú ukážkové hodiny, čakacie zoznamy, zmeškané termíny, dieťa, ktoré sa pridá v šiestom týždni, dieťa prechádzajúce do vyššej skupiny, a rodič, ktorý chce skončiť ku koncu ďalšieho mesiaca, nie dnes.
V tej medzere žijú administratívne hodiny. Väčšinu z nej zachytia tri otázky:
- Dá sa storno naplánovať na budúci dátum, nie len „teraz alebo nikdy”? Vyzerá to malicherne a prichádza to neustále. To naše áno, a dá sa odvolať.
- Počíta sa cena oneskorene prihláseného alikvótne a automaticky — a nájdete všetkých, čo prišli neskoro? V Zooze sú neskoré registrácie plnohodnotný prípad: pre každý program si volíte, či sú vypnuté, vyžadujú schválenie, alebo sa potvrdia samy, či sa cena kráti, a každá má vlastný stav, takže ich nájdete filtrom, nie auditom.
- Keď sa prelomí rok, ako sa pokračujúce deti posunú? Náš je zdokumentovaný postup — nové obdobia, skopírovať každú pokračujúcu skupinu, aby sa rozvrh posunul sám, rozhodnúť, či idú aj prihlášky, a automatické prihlasovanie znova zapíše rodiny, čo zostávajú. Čo Zooza neurobí, je domyslieť si sama, že dieťa prešlo do vyššieho ročníka; vašu štruktúru raz zmapujeme a septembrový posun beží nad ňou. Konfigurácia, nie kúzlo.
Keď sme pri tom, ešte dve veci na ukradnutie do vlastného zoznamu. Kapacita je v Zooze dvojica čísel: rezervačný formulár vidí vždy len Kapacitu, kým náhradné hodiny a ukážky vidia aj Kapacitu navyše — takže sála pre sedem sa predá ako päť plus dva a dve miesta ostanú tým, ktorí ich majú dostať, bez toho, aby sa kedy prepredala. A zdieľané termíny nechajú dve skupiny v tej istej sále v ten istý čas počítať proti skutočnej kapacite miestnosti namiesto toho, aby sa do desiatich miest prihlásilo dvadsať ľudí. Tá je v produkte označená ako beta a radšej to počujete tu, než aby ste ten štítok našli sami.
Najlepší signál je stále nie
Položte si nahlas ešte jednu otázku, niekde ku koncu: na čo by sme vás používať nemali?
Dodávateľ s jasnou odpoveďou vám ukazuje hrany toho, čo kupujete, a tú informáciu inak nezískate. Dodávateľ, ktorý prikývol na každý riadok vášho dokumentu, ho buď poriadne nečítal, alebo vám o limitoch nepovie — a nájdete si ich sami, neskôr a na vlastné náklady.
Čo platí na obe strany, tak tu sú niektoré naše, vytlačené na vlastnej stránke vedľa vecí, na ktoré sme hrdí: upozornenia na expiráciu certifikátov lektorov v produkte nie sú a poznámka nie je pripomienka. Neexistuje jedno tlačidlo na zmenu ceny v celej sieti. Reporting životnej hodnoty odchádza cez Power BI namiesto toho, aby prišiel ako štandardný report. Automatické mazanie po retenčnej lehote je otázka na nás, nie tvrdenie. Zdieľané termíny sú beta.
Nič z toho sa nezverejňuje príjemne. Všetko je to pre obe strany lacnejšie než zistiť to vo štvrtom mesiaci.
A „dnes to v produkte nie je” nie je tá istá veta ako „nie”. Pri každom takom riadku na našej stránke je aj možnosť vyžiadať si to, lebo slušná časť toho, čo Zooza dnes vie, vznikla presne tým, že to niektorá sieť otvorila pri presne takomto rozhovore. Medzera, ktorú vidíte a môžete sa na ňu spýtať, má pre vás väčšiu cenu než fajka, ktorú si neviete overiť — a to je nakoniec celý argument.
Celých 75 otázok nájdete tu, pod každou naša odpoveď. Odklikajte si tie, na ktorých vašej sieti záleží, výsledok si vytlačte ako prvý návrh vlastného zadania a vezmite ho ku všetkým, s ktorými hovoríte — nás nevynímajúc.
Zdroje. Bent Flyvbjerg & Alexander Budzier, „Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, september 2011 — štúdia 1 471 IT projektov, v ktorej bol jeden zo šiestich „čierna labuť” s priemerným prekročením rozpočtu o 200 % a harmonogramu o takmer 70 %. MoSCoW prioritizácia — vytvoril Dai Clegg v roku 1994, neskôr darovaná DSDM Consortium. Každá spomenutá schopnosť Zoozy odkazuje na našu produktovú dokumentáciu na help.zooza.online.
