9 pasti pri najemu IT izvajalca, ki vas bodo stale časa in denarja

70% digitalnih projektov ne uspe, zamudijo, prekoračijo proračun ali preprosto ne dobijo tega, kar so naročili. V javnem sektorju je ta številka še višja: 81 % IT projektov v javnih institucijah prekorači prvotni terminski plan, stroški pa so v povprečju trikrat višji kot pri zasebnih naročnikih.

Podatki niso novi, razlog zanje pa je pogosto presenetljivo enak: na eni strani je IT izvajalec, ki ve točno kaj dela. Na drugi strani pa naročnik, ki tega ne ve.

In tu se začnejo težave.

Večina organizacij, zasebnih podjetij in institucij javnega sektorja, ki se lotevajo digitalne transformacije in naročajo razvoj spletnih strani, mobilnih aplikacij ali digitalnih platform, nima internih kadrov, ki bi razumeli IT razvoj od znotraj. Ni nič narobe s tem, ni pričakovano, da boste razumeli razliko med backendom in frontendom.

Je pa problem, če vstopite v najem IT izvajalca brez vednosti o tem, kje so tipične pasti. V tem članku jih razkrijemo deset, skupaj z vprašanji, ki bi si jih morali zastaviti, preden podpišete pogodbo.

Past 1: Projektna naloga je preveč splošna, da bi bila koristna

Ko se organizacija, podjetje, občina ali javni zavod, odloči za digitalni projekt, je prva naloga priprava dokumenta z zahtevami: projektne naloge. In tu gre večinoma takoj narobe.

Tipična projektna naloga za najem IT izvajalca vsebuje naslednje: "Potrebujemo spletno aplikacijo, ki bo uporabnikom omogočala prijavo, pregled informacij in oddajo vlog." To je v resnici opis skoraj katerekoli spletne aplikacije na svetu.

Nespecifična projektna naloga ne zaščiti naročnika, zaščiti izvajalca. Ko so zahteve ohlapne, ima izvajalec proste roke pri interpretaciji. Ko pride do nesoglasij, se bo skliceval na to, kar je pač razumel. In bo imel prav.

Dobra projektna naloga odgovori na konkretna vprašanja: Kdo točno bo to uporabljal? Koliko uporabnikov hkrati? Katere podatke sistem obdeluje in kje so shranjeni? Kateri scenariji so kritični, kateri opcijski? Kaj se zgodi, ko sistem odpove?

Preden najem IT izvajalca sploh pride v poštev, bi morali imeti jasno sliko teh odgovorov. Brez dobro pripravljene projektne naloge ponudbe, ki jih prejmete, niso primerljive med seboj, vsak izvajalec bo ocenil drug digitalni projekt z drugačnimi predpostavkami.

V javnem sektorju ima slaba projektna naloga še dodatno, pravno dimenzijo. Pomanjkljiva ali nenatančna razpisna dokumentacija je najpogostejši razlog za pritožbo na DKOM (Državno revizijsko komisijo).

En slab odstavek v tehničnih zahtevah je dovolj, da ponudnik vloži zahtevo za revizijo, in projekt se ustavi za tri do šest mesecev, v najslabšem primeru pa je treba celoten postopek ponoviti

To ni samo zamuda. To je porabljen proračun za pripravo razpisa, izgubljen čas ekipe in politični pritisk, ki pade na odgovorno osebo.

Past 2: Šli ste k izvajalcu, preden ste popisali in uredili lastne procese

Ko organizacija pride k IT izvajalcu z besedami "digitalizirati hočemo ta proces", je to pogosto točka, ko bi morali stopiti korak nazaj.

Digitalizacija ni sinonim za izboljšanje. Digitaliziran slab proces je samo hitrejši slab proces. Če vaš postopek obdelave vlog zahteva sedem potrjevanj, tri tiskane forme in dva ročna e-mail koraka, in to preprosto prenesete v spletni sistem, ste dobili digitaliziran kaos, ne rešitev.

Preden greste k izvajalcu, bi morali opraviti procesno odkrivanje: kdo dela kaj, zakaj tako, kje so ozka grla, kje se izgublja čas, kje prihaja do napak. Tukaj pogosto odkrijete, da problem sploh ni tehničen, ampak organizacijski. In da bi prava rešitev zahtevala pol manj razvoja in pol manj denarja.

Izvajalec tega ne bo naredil namesto vas, vsaj ne, če ga nihče ni prosil. Razvil bo točno tisto, kar ste opisali v projektni nalogi za digitalni projekt, četudi je to napačna stvar. Procesna analiza pred razvojem je ena najpomembnejših investicij pri digitalni transformaciji, in jo je mogoče narediti relativno hitro in poceni, preden se zares zavežete k razvoju.

Vprašanje, ki bi si ga morali zastaviti: Ali smo si pred tem, ko smo šli k izvajalcu, vzeli čas, da razumemo lasten proces, in preverili, ali ga je sploh smiselno digitalizirati v tej obliki?

Past 3: Nihče ni določil UX kot merilo uspešnosti, in to vas bo drago stalo

To je verjetno najpomembnejša past, o kateri se govori najmanj.

Ko organizacije v zasebnem sektorju ali javni upravi naročajo digitalne produkte, portale za občane, interne sisteme, mobilne aplikacije, so KPI-ji tipično: rok oddaje, proračun, seznam funkcionalnosti. Nihče ne zapiše: "Produkt mora biti enostaven za uporabo za osebo, ki ni vešča tehnologije."

In ko naročnik ne definira UX (user experience oz. uporabniške izkušnje) kot merljivo zahtevo, izvajalec tega ne bo optimiziral. Zakaj bi? To zahteva dodaten čas za raziskavo, testiranje z resničnimi uporabniki, iteracije. Nič od tega ni v pogodbi.

Rezultat: sistemi, ki tehnično delujejo, a jih nihče ne želi uporabljati. E-uprava, ki zahteva sedem korakov za oddajo vloge, ko bi zadostovala dva. Portal za zaposlene, ki deluje na računalniku, ne pa na telefonu, čeprav 80 % zaposlenih dela na terenu. Aplikacija, kjer morate ugotoviti, kako jo sploh uporabljati.

Stroški slabe uporabniške izkušnje niso samo frustracija. So merljivi: nižja stopnja dokončanja procesov, višji stroški podpore, večje število klicev na help desk, nižja produktivnost, odpor do sistema. V javnem sektorju to pomeni, da občani raje pridejo osebno na okence, ker jim je digitalni sistem preveč zoprn. To ni uspešna digitalizacija, to je draga imitacija.

Prava UX ni estetika. Je odgovor na vprašanje: "Ali bo ta oseba, v tem kontekstu, ob tej uri, z enim prstom na telefonu, uspela opraviti to nalogo?"

Kako to zaščititi? V pogodbi zahtevajte uporabniško testiranje kot del procesa. Zahtevajte vključitev vsaj 5 dejanskih končnih uporabnikov v testiranje pred prevzemom. In zahtevajte, da se UX metrike, čas do dokončanja naloge, stopnja napak, Net Promoter Score, merijo pri prevzemu.

Past 4: Notranji buy-in ekipe ni nihče preveril

Ni nič manj destruktivno kot aplikacija, ki jo vaši lastni zaposleni ne želijo uporabljati.

Notranje IT rešitve, sistemi za upravljanje dokumentov, CRM-ji, interne platforme, poslovodski sistemi, so pogosto načrtovane brez resničnega posvetovanja s tistimi, ki jih bodo dejansko uporabljali vsak dan. Nihče ni vprašal ekipe: kako trenutno delaš? Katere informacije potrebuješ? Kaj ti jemlje čas? Kaj ti je na obstoječem sistemu zoprno?

Rezultat je predvidljiv: zaposleni najdejo obhode. Exceli, ki naj jih sistem "ne bi zahteval". E-maili, ki obidejo sistem. Ročni postopki, ki potekajo vzporedno z digitalnimi. In na koncu je sistem plačan, vzdrževan, a ga pol ekipe ne uporablja, ker jim ga nihče ni prodal.

Resnica je, da IT projekt brez internega buy-ina ne bo uspel, ne glede na to, kako tehnično dober je. Tega buy-ina ne doseže enodnevno izobraževanje po implementaciji, ampak vključitev ekipe v odkrivanje, oblikovanje in testiranje pred in med razvojem.

Enako velja za navodila in razlage. Sistem, ki ne pride z jasnimi, dostopnimi navodili za vsak tip uporabnika, bo vedno pod svojimi zmogljivostmi, ne zato, ker je slab, ampak ker ga nihče ne zna dobro izkoriščati.

Past 5: Vodstvo ne razume tehnologije kot orodja

To je morda najmanj zaznana past, ker se manifestira tiho: v projektih, ki so preveč ambiciozni za realne pogoje; v projektih, ki so premalo ambiciozni in zamudijo priložnost; v odločitvah, ki so sprejete na podlagi marketinških brošur, ne analize.

Ko vodstvo ne razume, kaj tehnologija zna in česa ne zna, nastajajo karakteristične napake. Kupijo drag sistem za problem, ki bi ga rešilo standardno orodje. Ne kupijo sistema, kjer bi bil donos na investicijo jasen in merljiv. Odobrijo projekt brez razumevanja, kaj je v danem proračunu sploh realno izvedljivo.

Posledica je dvojna: bodisi prekomerna investicija v napačno stvar, bodisi premajhna investicija v pravo, ker direktor ni razumel, kako bi ji ta rešitev pohitrila, pocenila ali optimizirala ključni poslovni proces. Ali pa: kako bi jo uporabili za boljše, hitrejše in cenejše storitve za stranke in občane.

Ni pričakovano, da bo vsak direktor razumel arhitekturne odločitve. Je pa pričakovano, in kritično za uspeh projekta, da razume, kaj tehnologija reši, kakšen je ROI in kako se jo da strateško uporabiti kot poslovno orodje. Organizacije, ki v to investirajo, pa četudi v obliki neodvisnega svetovalca, ki tehnično govorico prevede v poslovne argumente, sprejemajo bistveno boljše IT odločitve.

Past 6: Ko se projekt "konča", se pravi stroški šele začnejo

Podpišete prevzem. Izvajalec odide. In čez mesec dni ugotovite, da:

• sistem ne deluje na novejši verziji brskalnika

• manjka dokumentacija za vzdrževalce

• za vsako popravilo ali dopolnitev morate nazaj k istemu izvajalcu, ki zdaj zaračunava urno in po precej višjih tarifah

To je klasičen primer tehnološke odvisnosti, vendor lock-in, pri kateri ste prisiljeni ostati pri istem izvajalcu, ker samo on razume vaš sistem.

Zaščita: Ob prevzemu zahtevajte tehnično dokumentacijo, izvorno kodo v vaši lasti, navodila za vzdrževanje in vsaj en predajni sestanek z vašo IT ekipo ali novim izvajalcem. Brez tega ste kupili avto brez ključev.

Past 7: Nihče ni razmislil o tehnološkem dolgu in integraciji

Vsaka organizacija ima obstoječ IT sklad, skupek sistemov, orodij in platform, ki jih že uporablja. In vsaka nova IT rešitev mora v ta sklad vstopiti.

Tukaj se pogosto dogodi napaka: izvajalec predlaga tehnologijo, ki jo sam pozna in zna razviti. Naročnik to sprejme brez vprašanj. Nihče pa ni vprašal: ali je ta tehnologija združljiva z obstoječimi sistemi? Ali bosta ti dve rešitvi sploh komunicirali med seboj? Kakšni so stroški integracije? Ali bi rešitev z drugačno, morda že obstoječo, tehnologijo bila cenejša, manj tvegana in lažja za vzdrževanje?

Enako relevantno je vprašanje tehnološkega dolga: ali bo ta sistem čez tri leta zastarel? Je modularen in ga bo mogoče razširiti brez celotnega ponovnega razvoja? Kakšne nove tehnologije prihajajo, ki bi ta problem reševale bistveno bolje in ceneje, in ali bi se splačalo počakati, ali se prilagoditi?

Tukaj ni enostavnega odgovora, je pa to vprašanje, ki bi ga vsak naročnik moral zastaviti izvajalcu, in pričakovati jasno, strokovno utemeljitev. Izvajalec, ki ga zanima le izpeljati digitalni projekt in ne dolgoročni uspeh vaše digitalne infrastrukture, vam tega vprašanja ne bo zastavil sam. Tehnološki dolg namreč ne nastane čez noč, raste tiho, dokler enkrat ne postane dražji od novega razvoja.

Past 8: Zakaj ne morete preprosto zamenjati izvajalca

Odvisnost od izvajalca pogosto ne nastane iz nevednosti, ampak iz pogodbe, ki ščiti izvajalca bolj kot naročnika. To velja tako za zasebni sektor kot za javna naročila, v javni upravi pa je odvisnost od zunanjih IT izvajalcev po ugotovitvah OECD eden od sistemskih izzivov celotne regije.

Na kar morate biti pozorni: Kdo je lastnik izvorne kode? Kje so podatki shranjeni in kdo ima dostop? Ali je sistem zgrajen na lastniški platformi izvajalca ali na standardnih tehnologijah? Kaj se zgodi ob odpovedi pogodbe?

V javnem sektorju je to posebej občutljivo, OECD je v pregledu slovenske digitalne uprave izrecno opozoril, da odvisnost od IT izvajalcev vpliva na transparentnost in funkcionalnost sistemov, izvajalci pa se pogosto sklicujejo na zaščito intelektualne lastnine.

Dober izvajalec ne bo imel težav z odgovori na ta vprašanja. Tisti, ki bo odgovoril z "to je naša lastniška tehnologija" ali "tega ne delamo", vam s tem pove vse, kar morate vedeti.

Past 9: Sistem ste prevzeli. A ga je kdo testiral z resničnimi uporabniki?

Zadnja past je paradoksalno tista, ki jo je najlažje preprečiti.

Preden digitalni projekt uradno zaključite in ga preddate v produkcijsko okolje, ne glede na to, ali gre za rešitev za javni sektor ali zasebno podjetje, bi moral iti skozi strukturirano testiranje z resničnimi ali reprezentativnimi končnimi uporabniki. Ne razvijalci. Ne projektni vodja. Ne direktor. Pravi uporabniki, ki prvič vidijo sistem.

V praksi to redko pride v poštev, ker ni v pogodbi, ker zamuje čas, ker je proračun izčrpan. Rezultat: napake odkrijejo občani, ko poskušajo oddati vlogo za gradbeno dovoljenje ob 22:00 z mobilnega telefona. Ali zaposleni na prvem delovnem dnevu z novim internim sistemom. Nobeden od njiju tega ne bo pozabil, in vaša IT reputacija trpi skupaj z njima.

Stroški popravljanja napak po prevzemu so v povprečju 6-krat višji kot stroški odkrivanja med razvojem. Ura UX testiranja pred lansiranjem prihrani dneve reševanja po njem.

Zakaj javni sektor tega problema ne more rešiti z zaposlitvijo

Logična rešitev bi bila: zaposlite internega IT strokovnjaka, ki bo nadzoroval projekte. Na žalost je to v javnem sektorju strukturno težko izvedljivo.

Javni sektor vrednoti delovna mesta po tarifnih razredih, definiranih z zakonodajo in kolektivnimi pogodbami. Izkušen IT arhitekt, UX strateg ali senior razvijalec na slovenskem trgu zasluži 2.500-5.000 EUR neto ali več. Javni sektor jim pogosto ne more ponuditi niti polovice tega zneska v okviru obstoječih razredov, ne da bi hkrati porušil plačne razrede vseh ostalih zaposlenih.

Rezultat: IT strokovnjaki v javni upravi so pogosto bodisi neizkušeni, bodisi preobremenjeni z operativnimi nalogami, bodisi so že zdavnaj odšli v zasebni sektor.

To ni kritika javnih uslužbencev, je sistemska realnost, ki jo morajo vodje prepoznati in primerno nadomestiti z zunanjimi kapacitetami. Ne z izvajalci, ki razvijajo, ampak z neodvisnim partnerjem, ki naročnika zastopa, nadzoruje in ščiti njegove interese v celotnem življenjskem ciklu projekta.

Koliko vas stane, če se lotite projekta napačno?

Poglejmo konkretne številke, okvirne, ker je vsak projekt drugačen, a ilustrativne.

Razvoj digitalnega portala za upravljanje vlog ali storitev v javnem sektorju pogosto stane med 80.000 in 300.000 EUR. Zdaj dodajte tipične posledice napak, opisanih v tem članku:

• Prekoračitev proračuna za 50-100 %, po podatkih za javni sektor povsem tipično: to je 40.000 do 300.000 EUR dodatnega stroška

• Popravljanje UX po lansiranju, ker sistem ni bil testiran z uporabniki: 20-80 % začetnega proračuna

• Pravne posledice neupoštevanja WCAG, in to ni priporočilo, je zakonska obveznost: Zakon o dostopnosti spletišč in mobilnih aplikacij (ZPSJU) zahteva skladnost za vse javne digitalne storitve, nadzira pa jo Inšpektorat za informacijsko družbo. Globe in obvezna sanacija v kratkih rokih

• Podpora in klicni center za sistem, ki ga uporabniki ne razumejo: tisoče ur letno

• Ponoven razvoj čez 3-5 let, ker sistem ni prilagodljiv in ga ni mogoče nadgraditi (vendor lock-in)

Skupaj govorimo o razliki med 50.000 in 500.000 EUR, odvisno od tega, koliko napak je bilo narejenih v pripravi in izvajanju projekta. Tega nihče ne zapiše v cost-benefit analizo pred razpisom. A bi moral.

Po podatkih PMI se 12 % vsake investicije v IT projekt izgubi izključno zaradi slabega upravljanja. Na projektu vrednosti 200.000 EUR je to 24.000 EUR izgubljenega denarja, samo za začetek, brez upoštevanja zamud, popravkov in ponovnega razvoja.

Za javni sektor k temu dodajte še tveganje revizije Računskega sodišča. Sodišče ne preverja samo, ali je bil projekt zaključen, preverja, ali so bila javna sredstva porabljena smotrno in učinkovito. Projekt, ki je bil zaključen v proračunu, a ga nihče ne uporablja, ali sistem, ki zahteva takojšnje popravke po prevzemu, je za revizorje problematičen. Odgovornost v takem primeru ne pade na organizacijo abstraktno, pade na konkretno osebo, ki je projekt vodila in podpisala prevzem.

Kako dobro izgleda

Nasprotje vseh zgoraj opisanih scenarijev ni utopija, je pristop, ki ga kakovostni digitalni partnerji prakticirajo sistematično.

Začne se z razumevanjem problema pred pisanjem kode: popis procesov, validacija predpostavk, pogovor z dejanskimi uporabniki. Sledi jasno definirana projektna naloga, ki ščiti naročnika in postavlja merljiva merila uspešnosti, vključno z UX. Jasni mejniki z realnimi ocenami. Transparentna komunikacija o tveganjih. Predaja z dokumentacijo, brez skritih odvisnosti. In testiranje z resničnimi uporabniki, preden gre produkt v produkcijo.

Tak pristop ni dražji, ampak je cenejši, ker prepreči drage popravke in zamude. In ravno to je digitalna transformacija, ki resnično deluje: ne projekt z obkljukanimi postavkami, ampak sprememba, ki jo čutijo ljudje, ki jo vsak dan uporabljajo.

Zahteva pa partnerja, ki zna reči ne, ki vas izzove preden se strinja, in ki razume, da je cilj delujoč produkt za resnične ljudi, ne zaključen projekt.

Se prepoznate v napisanem?

Najem IT izvajalca je investicija javnega denarja, ki jo je mogoče, in ki jo je treba, zaščititi. Večina problemov, opisanih v tem članku, nastane ne zato, ker je izvajalec nesposoben ali nepošten, ampak ker pogoji, pričakovanja in merila niso bila jasno definirana na začetku. In ker ni nihče na strani naročnika, ki bi znal postavljati prava vprašanja, prepoznati tveganja in zaščititi javni interes, ne le preveriti, ali je bil projekt formalno zaključen.

Če stojite pred digitalnim projektom in nimate internih strokovnjakov, ki bi vas pri tem vodili, razmislite o neodvisnem partnerju, ki vas zastopa na strani naročnika: pri pripravi projektne naloge, oceni ponudb, nadzoru razvoja in prevzemu.

Se prepoznate v tem, kar ste prebrali?

Če imate projekt, ki se vam zdi, da ne gre po pravi poti, ali pa ste pred razpisom in želite zagotoviti, da se ne bo ponovilo, kar ste prebrali tukaj, nas pokličite.

Ponujamo brezplačno 45-minutno posvetovanje, brez obveznosti in brez prodajnih govorov. Samo iskren pogovor o vašem projektu in o tem, kje so realna tveganja.

Rezervirajte termin za brezplačno posvetovanje

Pogosta vprašanja (FAQ)

Zakaj IT projekti zamujajo? Najpogostejši razlogi so nespecifična projektna naloga na začetku, pomanjkanje jasnih mejnikov s sankcijami, slaba komunikacija med naročnikom in izvajalcem ter spremembe zahtev med razvojem. Globalne statistike kažejo, da 70 % IT projektov ne doseže prvotnih ciljev.

Kaj je UX in zakaj je pomemben za digitalne projekte? UX (user experience oz. uporabniška izkušnja) opisuje, kako enostavno in intuitivno je sistem za dejanskega končnega uporabnika. Slab UX pomeni, da sistem tehnično deluje, a ga nihče ne želi ali ne zna uporabljati, kar rezultira v nižji produktivnosti, višjih stroških podpore in odporu do sistema.

Zakaj je treba procese urediti pred digitalizacijo? Ker digitalizacija ne izboljša slabih procesov, jih samo pospeši. Vsak korak, ki je v analognem svetu odveč ali nelogičen, bo v digitalni obliki povzročal enake probleme, samo hitreje. Procesno odkrivanje pred razvojem pogosto razkrije, da je prava rešitev bistveno preprostejša in cenejša od prvotno načrtovane.

Kako preverim, ali je IT ponudba realna? Zahtevajte razčlenitev stroškov po funkcionalnostih, ne samo skupno ceno. Primerjajte vsaj tri ponudbe in vprašajte vsako o metodologiji razvoja, načinu komuniciranja in odgovornosti pri zamudah. Nepojasnjena razlika v ceni med ponudbami je vedno povod za podrobnejši pogovor.

Kaj pomeni tehnološki dolg pri IT razvoju? Tehnološki dolg nastane, ko so pri razvoju sprejete hitre ali kratkovidne odločitve, ki pozneje otežijo vzdrževanje, nadgradnje ali integracijo z novimi sistemi. Dober izvajalec vas bo opozoril na tehnološki dolg in predlagal arhitekturne odločitve, ki so vzdržne dolgoročno, ne le funkcionalne danes.

Kako zagotovim, da bodo zaposleni dejansko uporabljali nov sistem? Vključite ekipo že v fazo odkrivanja in oblikovanja, ne šele pri uvajanju. Zagotovite jasna navodila in razlage za vsak tip uporabnika. In izberite izvajalca, ki razume, da uspešnost projekta ni "sistem je zgrajen", ampak "sistem ga ljudje z veseljem uporabljajo".

Kaj pomeni vendor lock-in pri IT razvoju? Vendor lock-in je situacija, ko ste prisiljeni ostati pri istem IT izvajalcu, ker samo on razume in vzdržuje vaš sistem, bodisi ker ni pogodbenega lastništva nad kodo, ali ker je sistem zgrajen na lastniški tehnologiji. Zaščita: lastništvo izvorne kode in dokumentacija sta pogodbena zahteva, ne opcija.

Koliko stane razvoj spletne aplikacije v Sloveniji? Cene variirajo glede na kompleksnost. Enostavna spletna stran z integracijami se začne pri ~€10.000, mobilna aplikacija pri ~€20.000, kompleksni portali in platforme pa segajo od €50.000 navzgor. Izjemno nizke cene so pogosto opozorilo, ne ugodna priložnost.