Koliko košta održavanje softvera i što mora pisati u ugovoru

Održavanje poslovnog softvera u pravilu godišnje košta između 15 i 20 % iznosa koji je plaćen za razvoj. Za aplikaciju izrađenu za 30.000 € to je okvirno od 4.500 do 6.000 € godišnje, odnosno 375 do 500 € mjesečno. Tome se dodaju troškovi poslužitelja i licenci, koji su obično odvojena stavka.

Mnoge tvrtke taj trošak ne planiraju. Aplikacija se preda, radi i nekoliko je mjeseci sve u redu. Onda stigne nova verzija preglednika, istekne certifikat, promijeni se API banke ili nova zakonska obveza traži dorade, a ugovora nema. U ovom tekstu objašnjavamo što održavanje stvarno pokriva, koji modeli postoje i kako ga ugovoriti.

Zašto softver treba održavati i kad se ništa ne mijenja

Vaša se aplikacija možda ne mijenja, ali mijenja se sve oko nje:

• Tehnološka podloga zastarijeva. Programski okviri i jezici imaju ograničen rok podrške. Primjerice, Microsoftova podrška za .NET 8 završava 10. 11. 2026. Aplikacije koje i dalje rade na toj verziji nakon tog datuma neće dobivati sigurnosne zakrpe.
• Mobilni se sustavi mijenjaju svake godine. Nova verzija iOS-a izlazi svake jeseni, a Google Play svake godine traži prilagodbu novijoj verziji Androida.
• Vanjski sustavi mijenjaju svoja sučelja. Banke, sustavi za plaćanje, dostavne službe i državni servisi povremeno mijenjaju API-je, često s rokom od nekoliko mjeseci.
• Propisi traže prilagodbe. Fiskalizacija i eRačuni, GDPR, pravila o isticanju cijena ili novi izvještaji za državna tijela znače dorade u postojećim sustavima.
• Otkrivaju se nove ranjivosti. Biblioteke koje aplikacija koristi redovito dobivaju sigurnosne ispravke koje treba primijeniti i testirati.

Sustav koji se dvije ili tri godine ne održava ne prestaje raditi preko noći. Svaka sljedeća promjena ipak postaje skuplja jer se zaostatak gomila, a u jednom trenutku obična nadogradnja više nije dovoljna. Tada je potrebna temeljita obnova.

Što ulazi u održavanje

Dobar ugovor o održavanju razdvaja nekoliko vrsta posla:

Vrsta posla	Što uključuje	Je li u paušalu
Preventivno održavanje	ažuriranje biblioteka, sigurnosne zakrpe, obnova certifikata, provjera sigurnosnih kopija	da
Nadzor rada	praćenje dostupnosti, grešaka i opterećenja, upozorenja kad nešto ne radi	da
Ispravak grešaka	otklanjanje grešaka u postojećim funkcijama	da
Prilagodbe okruženju	nove verzije iOS-a i Androida, preglednika, promjene vanjskih API-ja	najčešće da
Podrška korisnicima	odgovori na pitanja, pomoć pri radu	do dogovorenog broja sati
Manje izmjene	novi izvještaj, dodatno polje, promjena obrasca	do dogovorenog broja sati
Nove funkcionalnosti	novi moduli i veće dorade	ne, zasebna ponuda

Najviše nesporazuma nastaje oko granice između ispravka greške i nove funkcionalnosti. Zato ugovor treba jasno odrediti što je greška: funkcija ne radi onako kako je dogovoreno i isporučeno. Sve što nije dogovoreno smatra se izmjenom.

Modeli ugovora o održavanju

Mjesečni paušal

Fiksni mjesečni iznos koji pokriva preventivno održavanje, nadzor, ispravke grešaka i određeni broj sati za podršku i manje izmjene. Najčešći je i najpredvidljiviji model. Neiskorišteni sati obično se ne prenose, a dodatni se naplaćuju po dogovorenoj satnici.

Banka sati

Unaprijed se kupi određeni broj sati, primjerice 40 sati godišnje, koji se troše po potrebi. Dobar je izbor za stabilne sustave s malo promjena. Nedostatak je što preventivno održavanje lako padne u drugi plan ako ga nitko izričito ne traži.

Naplata po stvarnom utrošku

Bez ugovora i bez obveza, plaća se samo kad nešto treba. Izgleda najjeftinije, ali nema zajamčenog vremena odziva, a nitko ne prati sustav dok se nešto ne pokvari. Za poslovno važne aplikacije takav model ne preporučujemo.

Okvirne cijene

Tip sustava	Okvirno mjesečno
Manja interna aplikacija, do 20 korisnika	150 do 400 €
Poslovni sustav s integracijama	400 do 1.200 €
Mobilna aplikacija s poslužiteljskim dijelom	300 do 1.000 €
Kritični sustav s dežurstvom izvan radnog vremena	od 1.500 €

Iznosi ne uključuju poslužitelje, licence trećih strana ni veće dorade. Stvarni iznos ovisi o veličini sustava, broju integracija i traženom vremenu odziva.

Što obvezno upisati u ugovor

1. Vrijeme odziva po težini problema. Primjerice, ako sustav ne radi, odziv je unutar dva sata u radnom vremenu, za grešku koja otežava rad sljedeći radni dan, a za manju grešku u dogovorenom roku.
2. Granicu između greške i izmjene, kako je opisano u prethodnom odjeljku.
3. Broj uključenih sati za podršku i manje izmjene te satnicu za dodatni rad.
4. Sigurnosne kopije: koliko se često rade, gdje se čuvaju i koliko se često provjerava može li se sustav iz njih vratiti.
5. Vlasništvo i pristup: izvorni kod, repozitorij te pristupni podaci za poslužitelje i domene trebaju biti u vlasništvu naručitelja ili mu biti dostupni.
6. Dokumentaciju: tko je ažurira i gdje se nalazi.
7. Izlazak iz ugovora: rok otkaza i obvezu predaje svega što je potrebno da sustav preuzme netko drugi.

Peta i sedma točka štite vas ako se suradnja jednom završi. Bez njih postajete ovisni o jednom izvođaču, čak i kad niste zadovoljni.

Kad održavanje više nije dovoljno

Ako je sustav star deset i više godina, napisan u tehnologiji koju više nitko ne podržava, a svaka izmjena traje tjednima, redovito održavanje samo odgađa problem. Tada je razumnije planirati postupnu obnovu: dio po dio sustava prelazi na novu tehnologiju, dok stari i dalje radi. O tome pišemo na stranici migracija legacy sustava.

Česta pitanja

Koliko godišnje košta održavanje aplikacije?

Okvirno 15 do 20 % cijene razvoja godišnje. Za sustav izrađen za 30.000 € to je od 4.500 do 6.000 € godišnje, bez troškova poslužitelja i licenci.

Je li održavanje obvezno ako aplikacija radi?

Nije zakonski obvezno, ali bez njega aplikacija postupno postaje sigurnosni rizik i sve ju je skuplje mijenjati. Mobilne aplikacije bez ažuriranja mogu postati nedostupne novim korisnicima u trgovinama.

Može li održavanje preuzeti netko tko nije razvio aplikaciju?

Može, ako postoji pristup izvornom kodu i barem osnovna dokumentacija. Preuzimanje obično počinje tehničkim pregledom sustava, nakon kojeg je jasno u kakvom je stanju i što treba prvo napraviti.

Što je uključeno u mjesečni paušal?

Najčešće preventivno održavanje, sigurnosne zakrpe, nadzor rada, ispravak grešaka i dogovoreni broj sati za podršku i manje izmjene. Nove funkcionalnosti uvijek se dogovaraju zasebno.

Što ako nam održavanje treba samo povremeno?

Tada je dobar izbor banka sati. Ipak preporučujemo da se u nju uključi barem jedna provjera i ažuriranje sustava u tromjesečju, kako se zaostatak ne bi gomilao.

Što dalje

Ako imate sustav bez ugovora o održavanju ili niste sigurni u kakvom je stanju, dobar je početak tehnički pregled: popis verzija, ranjivosti, sigurnosnih kopija i rizika. Kako radimo održavanje, pročitajte na stranici održavanje softvera, a za pregled vašeg sustava javite nam se.