Prečo sa ponuky na tú istú aplikáciu líšia násobne a ako ich porovnať

Modelová situácia: firma chce aplikáciu na mieru, zadanie pošle trom dodávateľom a najdrahšia z troch ponúk je násobkom najlacnejšej. Prvé podozrenie býva jasné: niekto predražuje.

Rozdiel však môže byť v tom, čo dodávateľ do ponuky zarátal, čo vynechal a aké riziko nechal na vás.

Či sa vlastný systém oplatí, rozoberáme v článku o návratnosti interného systému. Tu začíname o krok neskôr: ponuky ležia na stole a otázka znie, koľko stojí vývoj aplikácie, keď si ju každý dodávateľ predstavuje inak.

Násobný rozdiel nemusí byť predražovanie

Bente Anda, Dag Sjøberg a Audris Mockus opísali v štúdii z roku 2009 výberové konanie, v ktorom Simula Research Laboratory hľadala dodávateľa webového systému. Z 81 oslovených firiem v Nórsku poslalo ponuku s fixnou cenou 35, všetky na tú istú 11-stranovú špecifikáciu. Sumy bez DPH siahali od 2 630 do 69 940 eur, čo je približne 26,6-násobný rozdiel. Poučný je pomer, nie dnes už historické sumy.

Firmy pritom zadanie považovali za dobre špecifikované. Ponuky sa napriek tomu líšili aj v miere analýzy a návrhu, od žiadnej až po obrazovky, architektúru a dátové modely. Súvislosť ceny s plánovaným postupom autori nenašli a z ponúk sa podľa nich len obmedzene dalo vyčítať, ako firma pracuje a akú kvalitu chce dodať. Samotná suma teda neprezradí, čo za ňu dostanete.

V predbežnej fáze toho istého konania dalo 17 z týchto firiem nezáväzný odhad iba na základe jednostranového opisu potrieb. Najvyšší bol podľa Magneho Jørgensena a Gunnara J. Careliusa približne desaťkrát vyšší ako najnižší, okrem iného pre rozdiely v navrhovaných riešeniach a v produktivite. Autori upozorňujú, že pri vágnej špecifikácii cena ponuky projekt nielen odráža, ale aj definuje.

Z čoho sa cena skladá

Ak zadanie mlčí, tieto rozhodnutia urobí za vás dodávateľ:

• Rozsah funkcií. Čo aplikácia bude a nebude robiť. Veta „používateľ si vygeneruje report“ môže znamenať export do tabuľky aj analytický modul.
• Integrácie. Prepojenia napríklad s účtovníctvom. Ich náročnosť závisí od rozhraní, ktoré dodávateľ nemusí poznať.
• Dizajn a UX. UX, teda používateľská skúsenosť, ovplyvňuje, či ľudia aplikáciu prijmú, ako píšeme v článku o nepoužívaných systémoch. Hotová šablóna je lacnejšia než návrh overený na používateľoch.
• Dátový model. Štruktúra údajov a ich vzťahov. Stojí na ňom všetko ostatné, preto sa jeho chyby opravujú ťažko.
• Bezpečnosť a oprávnenia. Jedna rola pre všetkých je lacná, prístupy podľa pozície treba navrhnúť aj otestovať.
• Testovanie. Automatické testy po každej zmene overia, že pôvodné funkcie stále fungujú. Bez nich testujú vaši ľudia.
• Projektové riadenie. Koordinácia a riadenie zmien. Overte, či je v cene, alebo ho bude robiť niekto od vás.

Rozdiely sa skrývajú aj v nefunkčných požiadavkách, ktoré neopisujú, čo systém robí, ale ako dobre to robí: rýchlosť, spoľahlivosť či udržiavateľnosť, teda ako ľahko sa dá meniť. V nórskej štúdii boli opísané menej podrobne než funkčné a autori odporúčajú špecifikovať ich, najmä udržiavateľnosť, už v zadaní. Pomôcť môže model kvality z normy ISO/IEC 25010:2023, ktorý môžu pri špecifikácii používať aj objednávatelia.

Čo v ponuke nemusí byť

Tieto položky overte u každého dodávateľa. Ak ich zadanie nespomenulo, jeden ich mohol zarátať a druhý nie.

• Administrácia. Správa používateľov, číselníkov a obsahu. Bez nej robí každú drobnú zmenu vývojár na faktúru.
• Migrácia dát. Presun a vyčistenie údajov zo starého systému alebo z tabuliek.
• Viacjazyčnosť. Ak s ňou kód nepočíta od začiatku, jej doplnenie môže zasiahnuť veľkú časť aplikácie.
• Prístupnosť. Použiteľnosť aj pre ľudí so zdravotným znevýhodnením. Riešiť ju dodatočne znamená prerábať hotové obrazovky.
• Podpora po spustení. Opravy, bezpečnostné aktualizácie a pomoc používateľom. Ak chýba, prvý problém v prevádzke je nová objednávka.

Náklady za roky používania rozoberáme v článku Sedem SaaS nástrojov alebo jeden systém? Pri čítaní ponuky si z neho stačí vziať jedno: kód bez testov a dokumentácie je lacnejšie dodať, no drahšie meniť, lebo vývojár musí pri každej úprave najprv zistiť, čo zmena rozbije.

Kto nesie riziko: fixná cena, time and materials, hybrid

Fixná cena znamená, že riziko prekročenia nákladov nesie dodávateľ, a preto si ho zaráta do ceny: čím vágnejšie zadanie, tým väčšia rezerva alebo užší výklad rozsahu. Americký predpis pre federálne nákupy Federal Acquisition Regulation uvádza, že zmluva s pevnou cenou kladie na dodávateľa maximálne riziko a o type zmluvy sa má rokovať spolu s cenou. Nejde o naše právo, logika je však podľa nás prenosná.

Time and materials znamená, že platíte odpracované hodiny podľa dohodnutých sadzieb a riziko neistoty nesiete vy. Ten istý predpis ho pripúšťa, len keď rozsah či trvanie prác nemožno vopred presne odhadnúť. Keďže tento model dodávateľa nemotivuje kontrolovať náklady, predpis vyžaduje dohľad objednávateľa. Vyžaduje tiež strop ceny, ktorý dodávateľ prekračuje na vlastné riziko.

Hybrid s fixným prvým míľnikom dáva pevnú cenu prvej etape s jasným výstupom, napríklad analýze či prototypu, a o zvyšku sa rozhoduje až nad popísaným rozsahom. Dodávateľ nesie riziko malej etapy a vy rozhodujete o väčšine rozpočtu s lepšími informáciami. Prvá etapa však stojí peniaze aj čas a jej výstup musí vedieť použiť aj iný dodávateľ, inak si závislosť kúpite o etapu skôr.

Nepresné zadanie sa zaplatí počas vývoja

Change request je formálna žiadosť o zmenu dohodnutého rozsahu s vlastnou cenou a vplyvom na termín. Pri nepresnom zadaní sa z výnimky stáva pravidlo, lebo chýbajúce časti sa ukážu až počas vývoja.

Jørgensen a Carelius uvádzajú, že častou príčinou prekročenia nákladov dodávateľa sú zmeny požiadaviek, ktoré nemožno vyfakturovať klientovi. Kto vyhral nízkou cenou, má preto podľa nás silný motív účtovať ako zmenu každú odchýlku. Ak zmluva vopred neurčí sadzbu, spôsob odhadu a schvaľovanie zmien, o ich cene vyjednávate, keď dodávateľa už ľahko nevymeníte.

Nepresné zadanie však neplatíte iba faktúrami. Rámec Cost of Friction, ktorý na blogu používame, počíta náklad trenia ako čas × frekvencia × počet ľudí × náklad. Modelový výpočet s hypotetickými vstupmi: 30 nejasných bodov zadania, z ktorých každý zaberie dve hodiny stretnutia troch vašich ľudí, znamená 2 × 30 × 3 = 180 hodín internej práce. Nevyfakturuje vám ju nikto, a predsa ju zaplatíte. Dosaďte vlastné čísla a hodinový náklad.

Práva ku kódu a možnosť zmeniť dodávateľa

Vendor lock-in je stav, keď dodávateľa nemôžete ľahko vymeniť, lebo systému rozumie iba on. Európska komisia v roku 2016 uviedla, že skúsenosť s IKT lock-in priznalo 42 % sledovaných organizácií.

Podľa § 91 ods. 4 Autorského zákona č. 185/2015 Z. z. v znení účinnom od 1. septembra 2026 sa na počítačový program vytvorený celkom alebo sčasti na objednávku vzťahujú ustanovenia o zamestnaneckom diele a objednávateľ sa považuje za zamestnávateľa. Ak nie je dohodnuté inak, objednávateľ teda vykonáva majetkové práva, najmä právo dielo použiť, môže ich výkon postúpiť tretej osobe a platí, že autor súhlasil aj so zmenou diela (§ 90 ods. 4 až 6).

Dielom na objednávku zákon rozumie dielo vytvorené na základe zmluvy o dielo a rozhoduje aj to, čo sa strany dohodli. Zákon navyše rieši práva, nie odovzdanie: bez zdrojového kódu vo vašom úložisku, prístupov a dokumentácie vám právo meniť dielo veľa nepomôže.

Zmluva má upraviť aj hotové časti, ktoré dodávateľ prinesie, napríklad jeho platformu či platené komponenty, lebo tie nevznikli na vašu objednávku. Nejde o právne poradenstvo, zmluvu dajte posúdiť advokátovi.

Ako ponuky porovnať

Pošlite všetkým dodávateľom rovnaké otázky a odpovede zapíšte vedľa seba:

1. Čo je v rozsahu a čo z neho výslovne vylučujete?
2. Aké predpoklady ste urobili o integráciách, dátach a rolách?
3. Ako riešite výkon, bezpečnosť a udržiavateľnosť a čo testujete?
4. Ako oceňujete a schvaľujete zmeny rozsahu?
5. Čo obsahuje podpora po spustení a koľko stojí prvý rok prevádzky?
6. Aké práva ku kódu získame, kde bude uložený a ako prebehne odovzdanie inému dodávateľovi?

Autori nórskej štúdie odporúčajú, aby ponuky uvádzali pracovné postupy a ambície v kvalite výslovne, nie iba skryto vo fixnej cene. Za varovné signály považujeme:

• Fixná cena bez otázok. Vágne zadanie ocenené pevnou sumou bez spresňujúcich otázok môže stáť na úzkom výklade rozsahu alebo na rezerve, o ktorej neviete.
• Chýbajúce testovanie. Chyby potom nájdu až vaši používatelia.
• Nejasné práva a prístupy. Nie je jasné, kde bude kód uložený, alebo sú prístupy viazané na trvanie spolupráce.

Kedy je lacnejšia ponuka správna voľba

Štyri firmy z nórskej štúdie systém napokon nezávisle vyvinuli. Najlacnejšia z nich, za 8 750 eur, mala 93 % sklz voči dohodnutému termínu a slabú spoľahlivosť aj udržiavateľnosť. Najdrahšia, za 56 000 eur, mala 5 % sklz a dobrú použiteľnosť aj udržiavateľnosť. Podľa ceny bola 6,4-krát drahšia, po započítaní práce objednávateľa už len 3,4-krát. Výsledky nekopírovali poradie cien a lacnejší systém mohol byť podľa autorov najlepšou voľbou pre objednávateľa, ktorý toleruje meškanie, má dostatočnú odbornosť a nižšie nároky na niektoré aspekty kvality.

Môže ísť napríklad o interný nástroj s krátkou životnosťou alebo o overenie nápadu.

V dátach Magneho Jørgensena z 785 325 väčšinou veľmi malých zákaziek na globálnom outsourcingovom trhovisku riziko zlyhania najviac znižovala predchádzajúca spolupráca klienta s dodávateľom, na 17 % úrovne projektov bez nej. Klienti, ktorí vybrali ponuku s cenou aspoň na úrovni priemeru, mali pri inak rovnakých podmienkach riziko na 85 % úrovne klientov s väčším dôrazom na nízku cenu. Na väčšie projekty sa to podľa autora dá zovšeobecniť len opatrne. Dodávateľa podľa neho najlepšie preverí realistická skúška, napríklad skutočný projekt, a tou môže byť malá platená prvá etapa.

Úvodná fáza mení odhad na plán

Steve McConnell opisuje kužeľ neistoty, model zlepšovania presnosti odhadu počas projektu. Pri úvodnom koncepte môžu byť aj odhady skúsených odhadcov štvornásobne nepresné oboma smermi, teda so 16-násobným rozptylom, a presnejšie to podľa neho nejde. Kužeľ nezúži ďalší týždeň práce na odhade, iba rozhodnutia o tom, čo produkt bude a nebude robiť, o požiadavkách a rozhraní.

Tieto rozhodnutia prináša analýza alebo prototyp. Dodávatelia potom oceňujú aspoň rovnaký rozsah, hoci podobné ceny to nezaručí, ako ukázala nórska štúdia.

Firmy, ktoré v spomínanom konaní najprv odhadovali z jednostranového opisu, ponúkli neskôr na podrobnú špecifikáciu v priemere vyššie ceny než ostatné. Jørgensen a Carelius preto odporúčajú nežiadať orientačné ceny z neúplných informácií, ak môžu finálne ponuky stáť na úplnejších.

Platená analýza pritom nie je povinná. Pri malej a jasne ohraničenej aplikácii môže stačiť spresniť zadanie vlastnými silami. Analýza môže ukázať aj to, že vývoj nepotrebujete, lebo problém vyrieši zjednodušenie procesu alebo hotový nástroj. Na otázku, koľko stojí vývoj aplikácie, preto neexistuje poctivá odpoveď skôr, než je jasné, aký problém má aplikácia riešiť.

Čo si z toho zobrať

• Násobný rozdiel medzi ponukami nemusí znamenať predražovanie. Môže ísť o iný rozsah, riešenie či rezervu na riziko.
• Všetkým dodávateľom pošlite rovnaké otázky a porovnávajte rozsah, vylúčenia a predpoklady, nie iba konečné sumy.
• Ak sa dá zadanie spresniť, nežiadajte orientačné ceny z vágneho opisu. Pri nejasnom rozsahu začnite fixne ocenenou úvodnou fázou, ktorej výstup môže použiť aj iný dodávateľ.
• Pred podpisom si v zmluve upravte práva ku kódu, prístupy, dokumentáciu aj hotové komponenty a dajte ju posúdiť advokátovi.
• Lacnejšia ponuka môže byť správna voľba, ak znesiete meškanie, máte nižšie nároky na kvalitu a dodávku viete odborne ustriehnuť.