Kako izbrati izvajalca za razvoj programske opreme

Kaj pomeni izbrati pravega izvajalca#

Izbira izvajalca za razvoj programske opreme pomeni odločitev, kdo bo prevzel odgovornost za sistem, ki vpliva na več oddelkov hkrati - IT, finance, proizvodnjo, kadrovsko službo ali nabavo. Projekt praviloma ne poteka ločeno od obstoječih sistemov, temveč se povezuje z ERP-jem, CRM-jem, dokumentnim sistemom in poročanjem, zato odločitev ni le tehnična, temveč organizacijska. Naročnik mora vedeti, kdo bo v ekipi izvajalca, kako bo potekala komunikacija, kje bodo shranjeni podatki in kdo bo odgovoren za delovanje sistema po zagonu.

Pri izbiri je pomembno razlikovati med izvajalcem, ki prevzame celoten projekt - od analize zahtev, arhitekture in razvoja do uvedbe in podpore - ter izvajalcem, ki opravi le posamezen sklop, na primer integracijo ali del funkcionalnosti. Oba pristopa sta legitimna, razlika je v tem, kdo nosi odgovornost za povezovanje sklopov in kdo skrbi za celovito testiranje pred objavo v produkcijsko okolje. Naročnik naj vnaprej opredeli, ali išče enega odgovornega izvajalca ali več specializiranih partnerjev za posamezne dele projekta.

Odločitev o izvajalcu vpliva tudi na zaposlene, ki bodo sistem uporabljali vsak dan. Če izvajalec ne pozna delovnih procesov v proizvodnji, kadrovski službi ali nabavi, se to pozna pri uporabnosti rešitve in pri številu popravkov po uvedbi. Zato je smiselno preveriti, ali ima izvajalec izkušnje s panogo naročnika in ali v projekt vključuje poslovne analitike, ki zahteve prevedejo iz jezika stroke v tehnične specifikacije, razumljive razvojni ekipi.

Katere kompetence in sestavo ekipe preverite#

Preden izberete izvajalca, preverite, kdo bo dejansko delal na projektu. Pri večjih projektih, ki posegajo v več sistemov hkrati, potrebujete širok nabor vlog - ne le razvijalce, temveč tudi solution architecte, tehnične vodje, DevOps in cloud inženirje, strokovnjake za kibernetsko varnost ter QA inženirje. Izvajalec naj zna pojasniti, katere vloge bo vključil v vaš projekt in zakaj, glede na obseg in zahtevnost sistema, ki ga gradite ali nadgrajujete.

Pri Epixu in njegovi specialistični partnerski mreži lahko za projekt sestavimo ekipo z ustrezno izobrazbo in izkušnjami - od diplomirancev računalništva, programske opreme in informacijskih sistemov do posameznikov z več kot deset, petnajst ali dvajset leti izkušenj v panogi. Znotraj mreže je dostopen tudi kader s certifikacijskimi profili s področja oblaka, varnosti in projektnega vodenja, standardi, kot so ISO 9001, ISO 20000/20001, ISO 27001 in ISO 27701, pa so del delivery strukture mreže, ne posamezne osebe.

Preverite tudi, ali ima izvajalec izkušnje v vaši panogi. Specialistična partnerska mreža, s katero sodeluje Epix, pokriva izkušnje med drugim v javnem sektorju, bančništvu, zavarovalništvu, zdravstvu, telekomunikacijah, energetiki, logistiki, proizvodnji in izobraževanju. Panožne izkušnje skrajšajo čas, potreben za razumevanje vaših procesov, in zmanjšajo tveganje, da bo rešitev tehnično pravilna, a poslovno neuporabna.

• Senior inženirji
• Solution architecti
• Tehnični vodje
• Full-stack razvijalci
• DevOps in cloud inženirji
• Strokovnjaki za kibernetsko varnost
• QA in test automation inženirji

Kaj preveriti pri referencah in preteklih projektih#

Reference povedo več kot predstavitev na sestanku, ker pokažejo, kako je izvajalec ravnal v konkretnih okoliščinah. Epix je na primer za projekt Kwizmo razvijal AI programsko rešitev za uporabo umetne inteligence nad internimi podatki, dokumentacijo in poslovnimi procesi - vključno z AI agenti, RAG sistemom, obdelavo dokumentov, integracijami in avtomatizacijo. Tovrsten projekt pokaže, ali izvajalec zna povezati AI z realnimi internimi podatki naročnika, ne le z demonstracijskim primerom.

Za javni sektor je referenčen primer projekt za Občino Sevnica z imenom Zdravo Jem, kjer je Epix razvil programsko rešitev in interaktivne vsebine za javni prostor na 55-palčnem zaslonu na dotik, vključno s konfiguracijo kiosk okolja, integracijo programske in strojne opreme, namestitvijo na lokaciji ter dokumentacijo in podporo. Pri javnem sektorju je pomembno, da izvajalec pozna zahteve glede dostopnosti, dokumentacije in dolgoročne podpore, ne le razvoja same aplikacije.

Pri pregledu referenc bodite pozorni na obseg - ali je izvajalec prevzel projekt v celoti, od analize do podpore, ali je izvedel le en sklop. Vprašajte tudi, kako je potekala primopredaja: kdo je dobil dostope, dokumentacijo in gesla ter kako je bilo poskrbljeno, da izvorna koda in podatki ostanejo last naročnika. Ti podatki povedo več o zanesljivosti izvajalca kot splošne trditve o izkušnjah.

• Ali je šlo za nov sistem ali prevzem obstoječega
• Ali je projekt vključeval integracijo z drugimi sistemi
• Ali je bil projekt v regulirani panogi ali javnem sektorju
• Kdo je bil odgovoren za dokumentacijo in podporo po uvedbi
• Kakšen je bil obseg testiranja pred uvedbo

Kako izvajalec ravna z obstoječimi sistemi in podatki#

Večina projektov v podjetjih z več kot milijon evrov prihodkov ne poteka na praznem prostoru, temveč zahteva povezovanje z obstoječim ERP-jem, CRM-jem, dokumentnim sistemom (DMS/ECM) ali proizvodnim sistemom. Izvajalec mora znati prevzeti tudi obstoječ ali nedokončan sistem, kar pomeni pregled izvorne kode, arhitekture, infrastrukture in podatkov, preden predlaga nadaljnje korake. Brez tega pregleda je vsaka ocena obsega in tveganj zgolj ugibanje.

Pri integraciji z obstoječimi sistemi Epix in njegova partnerska mreža gradita in povezujeta ERP, CRM, DMS in ECM sisteme prek API-jev, prilagojenih vsakemu okolju posebej. Imen posameznih proizvajalcev sistemov namenoma ne navajamo, dokler integracija ni dejansko potrjena v konkretnem projektu - to velja tudi za vas kot naročnika: zahtevajte, da izvajalec pokaže, kako namerava povezati vaše obstoječe sisteme, ne le, da to načeloma zna.

Pomembno je tudi, kako izvajalec loči okolja. Razvojno, testno in produkcijsko okolje morajo biti ločena, v testnem okolju pa se ne uporabljajo pravi osebni podatki naročnika. Spremembe gredo skozi pregled in testiranje, preden pridejo v produkcijo. Izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje - to velja ne glede na to, ali gre za nov projekt ali prevzem obstoječega sistema.

Varnost podatkov in obvladovanje tveganj#

Varnost podatkov je pri projektih, ki povezujejo več poslovnih sistemov, eno od ključnih meril za izbiro izvajalca. Vprašanje ni le, ali izvajalec pozna pojem varnosti, temveč kdo znotraj njegove ekipe ali partnerske mreže dejansko pokriva posamezna področja - od varnostne arhitekture in penetracijskega testiranja do upravljanja ranljivosti (vulnerability management), upravljanja identitet in dostopov (IAM) ter odziva na incidente.

Znotraj specialistične partnerske mreže, s katero sodeluje Epix, so dostopni tudi profili s certifikati s področja varnosti in oblaka ter standardi, vključeni v delivery strukturo, kot sta ISO 27001 in ISO 27701, ki se nanašata na upravljanje informacijske varnosti in zasebnosti podatkov. Teh standardov ne pripisujemo Epix Group d.o.o. neposredno, temveč mreži, ki jo je mogoče vključiti v posamezen projekt glede na zahtevnost in panogo naročnika, na primer pri javnem sektorju ali reguliranih dejavnostih.

Praktičen del varnosti se kaže tudi v vsakodnevnem delu: ločena razvojna, testna in produkcijska okolja, brez pravih osebnih podatkov v testnem okolju, ter jasna pravila, kdo ima dostop do produkcijskih podatkov. Naročnik naj od izvajalca zahteva, da ta pravila opiše konkretno za svoj projekt, ne le načelno, saj se prav v teh podrobnostih pokaže razlika med izvajalcem, ki varnost razume kot proces, in tistim, ki jo obravnava kot dodatek na koncu projekta.

• Varnostna arhitektura
• Penetracijsko testiranje
• Vulnerability management
• IAM - upravljanje identitet in dostopov
• Utrjevanje infrastrukture
• Odziv na incidente
• Cloud security

Testiranje in kakovost pred uvedbo#

Kakovost programske rešitve se ne pokaže ob predstavitvi, temveč pri dejanski uporabi po uvedbi, zato je testiranje eno od meril, ki jih je vredno preveriti vnaprej. Izvajalec naj zna opisati testne scenarije, ki jih uporablja, razmerje med ročnim in avtomatiziranim testiranjem ter to, kako testira posamezne dele sistema (API testiranje) in celoto po vsaki spremembi (regresijsko testiranje).

Pri avtomatiziranem testiranju se uporabljata med drugim orodji Playwright in Cypress, testi pa tečejo znotraj CI/CD okolja, torej ob vsaki spremembi kode, ne le pred večjimi izdajami. Pred prevzemom sistema naročnik opravi prevzemno testiranje po vnaprej dogovorjenih merilih, tako da je jasno, kdaj je posamezen sklop zaključen in pripravljen za produkcijsko uporabo.

Pri zahtevnejših ali reguliranih projektih je smiselno vprašati tudi, ali je mogoč neodvisen QA, ločen od razvojne ekipe. Neodvisno testiranje zmanjša tveganje, da napake ostanejo neopažene, ker jih preverja nekdo, ki ni pisal kode, temveč sistem uporablja z vidika končnega uporabnika. To je še posebej pomembno pri sistemih, ki jih bodo dnevno uporabljali zaposleni iz več oddelkov.

• Testni scenariji
• Ročno testiranje
• Avtomatizirano testiranje (Playwright, Cypress)
• API testiranje
• Regresijsko testiranje
• Testiranje v CI/CD
• Prevzemno testiranje

Projektno vodenje, odgovornosti in komunikacija#

Pri projektih, ki trajajo dlje časa in vključujejo več oddelkov naročnika, je organizacija dela enako pomembna kot tehnično znanje. Pri večjih projektih Epix določi projektnega vodjo, odgovornosti posameznih ekip, roke ter način komunikacije in poročanja naročniku, tako da je ob vsakem trenutku jasno, kdo je odgovoren za kateri del sistema.

Naročnik naj vnaprej dogovori, kako pogosto bo prejemal poročila o napredku, kdo je kontaktna oseba na strani izvajalca in kako se rešujejo spremembe obsega med projektom - te se praviloma obravnavajo kot zahteve, ki jih je treba oceniti in uskladiti glede na termin, ne kot samoumevno vključene v prvotni dogovor. Jasna delitev odgovornosti med oddelki naročnika in ekipo izvajalca zmanjšuje tveganje zamud, ki nastanejo zaradi nejasnosti, kdo mora potrditi posamezno odločitev.

Ob zaključku projekta ali posameznega sklopa sledi primopredaja: izvorna koda in podatki so last naročnika, dokumentacija, dostopi in gesla pa so del formalne predaje. Naročnik naj vztraja, da je primopredaja opredeljena že v pogodbi, ne dogovorjena naknadno, saj se prav v tej fazi najpogosteje pokažejo nejasnosti glede lastništva in dostopov.

Podpora in vzdrževanje po uvedbi (SLA)#

Izbira izvajalca ne pomeni le, kdo bo sistem zgradil, temveč tudi, kdo bo skrbel za njegovo delovanje po zagonu. Po uvedbi lahko izvajalec prevzame nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj sistema. Obseg podpore se določi po projektu, zato je smiselno vnaprej vprašati, kaj konkretno podpora vključuje in kaj ostane v pristojnosti naročnika.

Pri podpori se napake običajno razvrščajo po razredih glede na vpliv na poslovanje. Prvi razred pomeni izpad, ko sistem ali ključni del ne deluje in ima obravnava najvišjo prednost z odzivnim časom, dogovorjenim v pogodbi o podpori. Drugi razred je motnja, ko sistem sicer deluje, a posamezna funkcija ne, tretji razred je manjša napaka brez vpliva na poslovanje, ki se uvrsti v naslednjo objavo, četrti razred pa je zahteva za spremembo ali nadgradnjo, za katero se oceni obseg in uskladi termin.

Univerzalnih odzivnih časov v urah ali dnevih ne objavljamo, ker so odvisni od kritičnosti sistema in dogovora z naročnikom - sistem, ki podpira proizvodnjo ali javno storitev, praviloma zahteva drugačen odzivni čas kot interno orodje za poročanje. Naročnik naj zato od izvajalca zahteva, da odzivne čase za posamezen razred zapiše v pogodbo o podpori, ne le splošno obljubo hitre odzivnosti.

• 1 - izpad: sistem ali ključni del ne deluje, najvišja prednost obravnave
• 2 - motnja: sistem deluje, posamezna funkcija ne
• 3 - napaka: manjša napaka brez vpliva na poslovanje, vključena v naslednjo objavo
• 4 - zahteva: sprememba ali nadgradnja, obseg in termin se uskladita posebej

Kako je določena cena in obseg projekta#

Cena razvoja programske opreme ni fiksna številka, ki jo je mogoče podati pred pregledom zahtev, temveč se določi po pregledu obsega, funkcionalnosti in tehnične zahtevnosti projekta. Namesto splošnih cenovnih razponov je bolj smiselno razumeti, od česa je cena odvisna, saj to naročniku pomaga pripraviti realnejše povpraševanje in primerjati ponudbe na enaki osnovi.

Na obseg in s tem na ceno projekta vpliva več dejavnikov hkrati, zato jih je smiselno pregledati še pred pripravo povpraševanja. Gre za vprašanja, ki jih izvajalec praviloma postavi na prvem sestanku in na podlagi katerih lahko šele oceni zahtevnost projekta. Če teh odgovorov naročnik nima pripravljenih vnaprej, se prva faza sodelovanja podaljša, ocena obsega pa ostane manj natančna.

Pred oceno cene je zato smiselno izvesti krajšo analizo, ki obseg projekta razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno. Tak pristop naročniku omogoča, da se odloči, kateri sklopi so nujni takoj in kateri lahko sledijo v naslednji fazi, hkrati pa izvajalcu omogoča natančnejšo oceno brez ugibanja o obsegu dela.

• Obseg funkcionalnosti in število uporabniških vlog
• Koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• Ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• Količina in stanje podatkov, ki jih je treba prenesti
• Zahteve glede varnosti, revizijske sledi in skladnosti
• Obseg AI dela in zahtevana natančnost
• Raven podpore po uvedbi in dogovorjeni odzivni časi

Koraki pri izbiri izvajalca#

Ko povežete vsa zgornja merila, se izbira izvajalca izkaže za postopek, ne za enkratno odločitev na podlagi ponudbe. Najprej opredelite, ali potrebujete izvajalca za celoten projekt ali za posamezen sklop, nato preverite, kdo bo dejansko sestavljal projektno ekipo in kakšne izkušnje ima s podobnimi sistemi ali panogo, v kateri delujete.

V naslednjem koraku preverite, kako izvajalec ravna z obstoječimi sistemi in podatki, kakšna je njegova praksa na področju varnosti in testiranja ter kako je urejena podpora po uvedbi, vključno z razredi napak in odzivnimi časi. Na koncu preverite, kako je opredeljena primopredaja izvorne kode, podatkov, dokumentacije in dostopov, saj ta del pogodbe pogosto odloča o tem, kako samostojni boste po zaključku projekta.

Za organizacijo, ki upravlja več sistemov hkrati, je tovrsten sistematičen pregled pomembnejši od primerjave cen med ponudniki, saj napačna izbira izvajalca po navadi ne pomeni le izgubljenega časa, temveč tudi tveganje za podatke, procese in zaposlene, ki bodo sistem uporabljali vsak dan. Jasno opredeljena merila pred izbiro zmanjšajo možnost nesporazumov med izvedbo in po njej.

• Opredelite obseg - celoten projekt ali posamezen sklop
• Preverite sestavo projektne ekipe in izkušnje s panogo
• Preverite ravnanje z obstoječimi sistemi in podatki
• Preverite prakso na področju varnosti in testiranja
• Dogovorite razrede napak in podporo po uvedbi
• Opredelite primopredajo kode, podatkov in dokumentacije v pogodbi