Nimeni nu descoperă la o singură locație că a ales greșit. Descoperă la a cincea.

Aproape nimeni nu descoperă că a ales sistemul greșit cât timp are o singură locație. La o locație software-ul este în regulă. Este în regulă și la două. Undeva pe la a patra sau a cincea încetează să fie — iar lucrul care a cedat nu era pe nicio listă de funcții pe care cineva a comparat-o.

Așa arată în fiecare document de cerințe care a ajuns la noi, și tocmai de aceea merită citit chiar dacă astăzi aveți un singur loc. Întrebările care decid dacă un sistem vă supraviețuiește creșterii sunt cele cu care încă nu aveți de-a face. Și exact de aceea nu le pune nimeni.

Să începem cu versiunea pe care probabil ați trăit-o deja.

E joi seara și pe birou stă o ofertă pentru un sistem nou. Lista de funcții are două pagini și la fiecare rând e o bifă. Orare, rezervări, plăți, prezență, comunicare cu părinții, rapoarte. Bifă, bifă, bifă, bifă.

Primul gând e ușurare. Doar le au pe toate.

Al doilea vine după un minut și e mai neplăcut: o bifă în dreptul unei funcții nu înseamnă că o puteți folosi săptămâna viitoare. Poate însemna v-o configurăm la implementare. Poate însemna v-am dezvolta-o. Uneori înseamnă e pe planul de dezvoltare. Trei viitoruri complet diferite, o singură bifă identică — și nimic de pe acea pagină nu vă spune pe care ați cumpărat-o.

Golul acesta nu e un fleac. Bent Flyvbjerg și Alexander Budzier au studiat pentru Harvard Business Review 1.471 de proiecte IT și au constatat că unul din șase nu a fost doar mai scump: a devenit un alt proiect decât cel aprobat, cu o depășire medie de buget de 200 % și de termen de aproape 70 %. Mecanismul este plictisitor și se repetă. Un obiectiv asupra căruia cele două părți nu s-au înțeles niciodată exact, pentru că nimeni nu l-a scris destul de precis cât să poată fi încălcat.

Au venit patru documente și nu erau ce ne așteptam

Între 2024 și 2026, mai multe rețele cu locații multiple ne-au trimis un document formal de cerințe înainte să se angajeze la ceva. Un tabel cu priorități. O specificație scrisă cu modelul de date schițat. O simplă listă de întrebări după prima prezentare, care s-a dovedit cea mai ascuțită dintre cele trei.

Ne așteptam la liste de funcții. Am primit altceva și ne-a învățat asta: lista de funcții este partea care diferențiază cel mai puțin. Pentru orare, plăți și prezență este pregătit orice furnizor serios. Acolo nu pierde nimeni o licitație.

A decis un alt set de întrebări — cele cu care un operator cu un singur loc nu are de-a face — și un mod de a întreba pe care majoritatea cumpărătorilor nu îl folosesc niciodată.

Așa că am publicat tot: 75 de întrebări în 15 domenii, reunite și anonimizate astfel încât niciun rând să nu poată fi urmărit până la sursă, iar sub fiecare stă răspunsul nostru. Gratuit, pe noi și pe toți ceilalți.

Iată versiunea scurtă.

Teoria: întâi sortați-vă propria listă, în patru coșuri

Cel mai util lucru l-a făcut fiecare dintre acele rețele înainte de primul contact cu un furnizor.

Și-a sortat propriile cerințe în trebuie, ar trebui, ar putea, nu va exista. Acesta este MoSCoW — numele nu este altceva decât cele patru inițiale cu două „o” mici intercalate ca să poată fi pronunțat, și nu are nicio legătură cu orașul. L-a creat Dai Clegg în 1994 și l-a donat ulterior DSDM Consortium, ceea ce înseamnă că este un standard recunoscut: un furnizor care primește o listă sortată astfel știe deja ce înseamnă categoriile.

Două lucruri fac să funcționeze, în loc să devină încă un tabel colorat.

Testul „trebuie”. Întrebați ce se întâmplă dacă o cerință nu este îndeplinită. Dacă răspunsul sincer este că ați anula proiectul, este „trebuie”. Dacă nu, nu este. Majoritatea oamenilor marchează absolut totul ca indispensabil, prin care nu marchează nimic.

Repartizarea efortului. DSDM propune ca „trebuie” să nu însumeze mai mult de aproximativ 60 % din efort, cu restul cam 20 la 20. Dacă 90 % din lista voastră este „trebuie”, încă nu ați prioritizat-o — iar un furnizor o va cota ca și cum ați fi vorbit serios.

Și apoi e al patrulea coș, cel pe care toți îl lasă gol. Să scrieți ce nu cumpărați este ceea ce, după jumătate de an, oprește extinderea obiectivului. Și împiedică un furnizor să vă ofere o platformă pentru o problemă pe care deja hotărâserăți să nu o rezolvați. O excludere care există doar în capul vostru se redeschide. Una la care s-a răspuns în scris, nu.

Practica: cereți cinci stări, niciodată o bifă

Aceasta este corecția pentru acea ofertă de joi. Refuzați da și nu. Faceți ca fiecare rând să ajungă într-una din cinci stări:

• Există ca standard — utilizabil săptămâna aceasta, cu un link în documentația de produs a furnizorului, nu pe o pagină de marketing, ca să verificați fără el.
• Îl configurăm cu voi — real, dar este muncă de configurare la implementare, nu un comutator deja pornit. Întrebați cine o face, cât durează și dacă este inclusă.
• L-am dezvolta — astăzi nu există. În scris, cu termen, și întrebați cine îl întreține după; o ramură la comandă neîntreținută este mai rea decât nicio dezvoltare.
• Nu există în produs — nu există și nu se împachetează frumos. Estimat ca faza a doua, sau scos.
• În afara obiectivului, de comun acord — propria voastră excludere, răspunsă oricum, ca linia să țină.

Un furnizor care nu distinge avem asta de am putea dezvolta asta este cel mai mare risc al întregului exercițiu. Distincția asta valorează pentru voi mai mult decât orice funcție de pe listă.

Întrebările pe care le pune o rețea și o singură locație niciodată

Cinci domenii au apărut în fiecare document de rețea și aproape în niciunul de la o singură locație. Fiindcă aceasta este pagina noastră, răspunsurile noastre stau chiar alături — și toate trimit în documentația noastră de produs, nu în marketing, adică exact standardul pe care tocmai vi l-am recomandat să îl cereți de la toți.

Separarea datelor. Întrebați dacă separarea între francizați este arhitecturală sau este o setare de permisiuni care se poate strica. În Zooza fiecare locație este un cont separat; francizorul le unește într-o Rețea care dă sediului central raportare peste toate. Un francizat nu vede datele altei locații pentru că nu sunt în contul lui. Iar când o familie chiar se mută, Transferul în masă îi duce datoria, creditul, notele și câmpurile voastre proprii, cu o previzualizare de probă — și avem documentat și ce nu se mută, pentru că istoricul plăților și mandatele aparțin companiei-sursă.

Redevențele. Întrebați de la ce bază se calculează cifra — facturat, încasat, după returnări, fără TVA — și stabiliți asta înainte să comparați furnizori, pentru că nu vor presupune același lucru. Apoi întrebați dacă redevența se facturează ulterior sau se reține la sursă; sunt două implementări diferite. A noastră se calculează în Network Application din tranzacții reale după regulile rețelei voastre și stă lângă plățile încasate, venitul net și restanțe, deci baza se vede. Reținerea la sursă depinde de cum încasează fiecare locație, iar pe aceea o cotăm, nu o afirmăm.

Standardizarea. Întrebarea nu este se poate standardiza, ci ce mecanism face din standard starea implicită. Al nostru este copierea: o locație nouă apare prin copierea unui program-model și a grupelor lui, orarul mutându-se singur pe noile date. Codurile de produs de la sediul central păstrează comparabile programele denumite diferit. Și jumătatea onestă: nu există un singur buton care schimbă un preț în toate locațiile deodată, pentru că programele trăiesc în fiecare cont. Este prețul autonomiei francizaților și preferăm să o spunem.

Raportarea rețelei. Aproape fiecare document conținea un rând în sensul o versiune automată a tablourilor pe care le ținem de mână. Întrebați ce se raportează pe toată rețeaua fără dezvoltare la comandă și dacă taie locație contra locație. A noastră acoperă înscrieri, plăți, venit net, restanțe, redevențe și ședințe după companie, locație, produs și perioadă, cu un comutator Companii/Locații pentru francizații cu mai multe săli. Valoarea pe durata de viață este lipsa — aceea iese prin Power BI sau printr-un export.

Localizarea. Asta o subestimează rețelele cel mai mult și exact aici un adjectiv nu valorează nimic. Nu acceptați sistemul este multilingv; întrebați care jumătate, și apoi despre tot ce nu este limbă. Răspunsul nostru este o listă, nu o afirmație: sisteme de facturare pe piață (Fakturoid pentru CZ/SK, Számlázz.hu pentru Ungaria, SmartBill și Oblio pentru România, ABRA Flexi, Xero internațional), exporturi contabile pe piață (Omega, Pohoda, SAP) și canale de plată pe regiune — FastPay pentru debitul direct BACS britanic, Global Payments în UE/SEE cu cont separat pentru fiecare entitate juridică, GoCardless, Stripe. Limba sunt trei setări independente, deci biroul poate lucra în una și părinții pot citi în alta.

Și ceea ce toți uită să întrebe

Furnizorul arată o înscriere curată. Săptămâna voastră reală e formată din ședințe de probă, liste de așteptare, absențe, un copil care se alătură în săptămâna șase, un copil care trece în grupa următoare, și un părinte care vrea să se oprească la finalul lunii viitoare, nu azi.

În acel gol trăiesc orele de administrare. Cea mai mare parte o prind trei întrebări:

1. Se poate programa o anulare la o dată viitoare, nu doar „acum sau niciodată”? Pare un fleac și apare constant. A noastră da, și poate fi revocată.
2. Se calculează prețul unei înscrieri târzii proporțional și automat — și îi găsiți pe toți cei care au venit târziu? În Zooza înscrierile târzii sunt un caz de sine stătător: pentru fiecare program alegeți dacă sunt dezactivate, necesită aprobare sau se confirmă singure, dacă prețul scade, iar fiecare are status propriu, deci le găsiți cu un filtru, nu cu un audit.
3. Când se schimbă anul, cum trec copiii care continuă? Al nostru este o listă documentată — perioade noi, copiați fiecare grupă care continuă ca orarul să se mute singur, decideți dacă vin și înscrierile, iar înscrierea automată reînscrie familiile care rămân. Ce Zooza nu face este să deducă singură că un copil a trecut într-un an superior; structura voastră o cartografiem o dată, iar promovarea din septembrie rulează peste ea. Configurare, nu magie.

Fiindcă tot suntem aici, încă două lucruri de luat pe propria listă. Capacitatea în Zooza sunt două numere: formularul de rezervare vede mereu doar Capacitatea, în timp ce ședințele de recuperare și cele de probă văd și Capacitatea suplimentară — o sală de șapte se vinde deci ca cinci plus doi, iar două locuri rămân celor care trebuie să le primească, fără ca sala să fie vreodată suprarezervată. Iar ședințele partajate fac ca două grupe în aceeași sală la aceeași oră să conteze față de capacitatea reală a încăperii, în loc să înscrie douăzeci de persoane pe zece locuri. Acelea sunt marcate în produs ca beta și e mai bine să auziți asta aici decât să găsiți eticheta singuri.

Cel mai bun semnal rămâne un nu

Puneți spre final încă o întrebare cu voce tare: pentru ce nu ar trebui să vă folosim?

Un furnizor cu un răspuns clar vă arată marginile a ceea ce cumpărați, iar informația asta nu o obțineți altfel. Un furnizor care a dat din cap la fiecare rând din documentul vostru fie nu l-a citit cu atenție, fie nu vă va spune despre limite — și le veți găsi singuri, mai târziu și pe banii voștri.

Ceea ce este valabil în ambele sensuri, așa că iată câteva dintre ale noastre, tipărite pe propria pagină lângă lucrurile cu care ne mândrim: avertizările privind expirarea certificatelor instructorilor nu sunt în produs, iar o notiță nu este o atenționare. Nu există un singur buton pentru schimbarea prețului în toată rețeaua. Raportarea valorii pe durata de viață iese prin Power BI în loc să vină ca raport standard. Ștergerea automată după termenul de păstrare este o întrebare către noi, nu o afirmație. Ședințele partajate sunt în beta.

Nimic din asta nu se publică plăcut. Totul este pentru ambele părți mai ieftin decât să afli în luna a patra.

Iar „astăzi nu există în produs” nu este aceeași propoziție cu „nu”. La fiecare astfel de rând de pe pagina noastră există și posibilitatea de a-l cere, pentru că o bună parte din ce face Zooza astăzi a apărut exact așa — o rețea a ridicat subiectul într-o discuție exact ca aceasta. O lipsă pe care o vedeți și despre care puteți întreba valorează pentru voi mai mult decât o bifă pe care nu o puteți verifica — și acesta este, până la urmă, întregul argument.

Toate cele 75 de întrebări sunt aici, sub fiecare răspunsul nostru. Bifați-le pe cele care contează pentru rețeaua voastră, tipăriți rezultatul ca prima schiță a propriului document de cerințe și duceți-l la toți cu care vorbiți — inclusiv la noi.

---

Surse. Bent Flyvbjerg și Alexander Budzier, „Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, septembrie 2011 — un studiu pe 1.471 de proiecte IT în care unul din șase a fost o „lebădă neagră” cu o depășire medie de buget de 200 % și de termen de aproape 70 %. Prioritizarea MoSCoW — creată de Dai Clegg în 1994, donată ulterior DSDM Consortium. Fiecare capabilitate Zooza menționată trimite la documentația noastră de produs de pe help.zooza.online.