Na vsebino
Kontakt
Delo Projekti, ki dokazujejo naše kompetence.Kontakt Povpraševanje v 3 korakih

Razvoj programske opreme

Koliko stane razvoj poslovne aplikacije

Cena poslovne aplikacije ni določena s številom zaslonov, temveč z zahtevnostjo procesov, podatkov in integracij. Članek je namenjen podjetjem in javnim naročnikom, ki pripravljajo nov informacijski sistem ali prenovo obstoječega.

Objavljeno 23. avgust 2026

Predstavite nam projekt Vsi projekti

Cena se začne pri obsegu, ne pri številu zaslonov

Pri poslovni aplikaciji uporabniški vmesnik predstavlja samo en del sistema. Za njim so podatkovna baza, poslovna pravila, uporabniške pravice, API-integracije, infrastruktura in mehanizmi za nadzor delovanja.

Preprost uporabniški tok lahko zahteva veliko logike v ozadju: sistem mora preveriti podatke iz več virov, uporabniku določiti pravice, ustvariti dokument, poslati podatke v drug informacijski sistem in shraniti revizijsko sled.

Pred oceno je treba določiti ključne poslovne procese, uporabniške vloge, podatkovni model, integracije, migracijo, administrativni del, infrastrukturo ter zahteve za QA, DevOps in SLA.

Če ti elementi niso določeni, je ponudba ocena na podlagi predpostavk. Več kot je odprtih vprašanj, večje je tveganje za spremembe obsega med projektom.

  • poslovni procesi
  • uporabniške vloge
  • podatkovni model
  • API-integracije
  • migracija podatkov
  • QA in primopredaja
  • DevOps, infrastruktura in SLA

Poslovna logika pogosto določa večji del zahtevnosti

UX/UI je pomemben, vendar mora poslovni sistem predvsem pravilno izvajati pravila glede statusov, potrjevanja, pravic, dokumentov in obdelave podatkov.

Več kot ima proces izjem, stanj in medsebojnih odvisnosti, več analize, razvoja in QA je potrebnega.

Pri oceni je treba odgovoriti na vprašanja: kdo lahko ustvari zapis, kdo ga spremeni, kdaj se zaklene, kdo ga potrjuje, kaj se zgodi ob zavrnitvi, kateri podatki so obvezni, kaj se prenese v ERP ali CRM in kaj mora ostati zapisano zaradi sledljivosti.

Če teh pravil ni mogoče jasno opisati, jih bo treba določiti med razvojem - to neposredno poveča obseg analize, razvoja in QA.

Integracije lahko bistveno spremenijo obseg

Povezava z ERP, CRM ali drugim informacijskim sistemom zahteva več kot samo podatek, da API obstaja. Preveriti je treba dokumentacijo, avtentikacijo, razpoložljive podatke, omejitve in testno okolje.

Dogovoriti je treba tudi odgovornosti in odziv sistema v primeru nedosegljivosti ali napačnega odziva zunanje storitve.

Integracija, pri kateri so API-ji dokumentirani in je na voljo testno okolje, je bistveno drugačen projekt od integracije s sistemom, kjer je treba podatkovni tok šele raziskati.

Migracija podatkov zahteva ločeno analizo

Migracija lahko vključuje uporabnike, dokumente, zgodovino, statuse in druge poslovne podatke. Pred izvedbo je treba pregledati izvor, določiti preslikavo in preveriti kakovost podatkov.

Naročnik in izvajalec morata določiti tudi način potrditve pravilnosti prenosa.

Poseben problem so podatki, katerih pomen se je skozi leta spreminjal ali niso zapisani dosledno.

  • kdo zagotovi izvoz podatkov
  • v kakšni obliki so podatki na voljo
  • koliko različnih virov obstaja
  • ali se prenašajo tudi dokumenti in priponke
  • kdo potrdi pravilnost migracije
  • ali je potreben poskusni prenos pred končno migracijo

Spletna in mobilna aplikacija nista isti projekt

Če sistem potrebuje samo spletni vmesnik, je obseg drugačen kot pri projektu, ki vključuje tudi mobilno aplikacijo. Ta lahko zahteva drugačne uporabniške tokove, prilagoditve vmesnika in dodatno preverjanje na napravah.

Če mora del funkcionalnosti delovati brez povezave ali uporabljati funkcije naprave, se tehnični obseg še poveča. Specifikacija mora zato jasno določiti, ali gre za spletno aplikacijo, mobilno aplikacijo ali oboje.

Pri projektu Zdravo Jem za Občino Sevnica smo razvili programsko rešitev za interaktivni kiosk. Tak projekt ni spletna stran na večjem zaslonu - zahteva prilagoditev načinu uporabe na lokaciji, vmesniku na dotik in tehničnim pogojem naprave.

AI zahteva natančno opredeljen primer uporabe

AI funkcionalnost mora biti opisana kot konkretna sistemska zahteva, na primer obdelava dokumentov, RAG, AI agent ali avtomatizacija procesa.

Če AI agent dostopa do drugih sistemov, so potrebne API-integracije, uporabniške pravice in pravila glede dejanj, ki jih sistem lahko izvede.

Kwizmo je primer Epixovega dela na področju enterprise AI.

QA, DevOps in SLA so del informacijskega sistema

Projekt ni zaključen s prvo implementacijo funkcionalnosti. Potrebni so QA, dogovorjeni kriteriji primopredaje ter preverjanje integracij, pravic in uporabniških scenarijev.

Po uvedbi je treba določiti tudi infrastrukturo, spremljanje delovanja, postopke nameščanja novih različic in model vzdrževanja. Če so zahtevani odzivni časi, jih mora določiti SLA.

Spremembe med projektom so normalne, a morajo biti nadzorovane

Pri razvoju informacijskega sistema se potreba po spremembah skoraj vedno pokaže. Težava nastane, kadar ni jasno, ali je sprememba del prvotnega obsega ali dodatna zahteva.

Dobra specifikacija zato ne služi samo pripravi ponudbe, ampak tudi vodenju projekta. Pri vsaki pomembnejši spremembi je treba preveriti vpliv na razvoj, podatkovni model, integracije, QA in infrastrukturo.

Če se projekt začne z nejasnim obsegom, se te odločitve prestavijo v fazo razvoja. Posledica ni le sprememba stroška, ampak tudi bistveno več koordinacije med naročnikom, razvijalci in drugimi izvajalci.

Kaj potrebujete za realno ponudbo

Za prvo oceno je treba opisati trenutni in ciljni proces, uporabniške vloge, ključne funkcionalnosti, zahtevane integracije, migracijo podatkov ter osnovne infrastrukturne in varnostne zahteve.

Pri javnih naročilih jasen tehnični obseg omogoča, da različni ponudniki ocenjujejo primerljiv predmet naročila.

Če sistem že obstaja, so koristni tudi dostop do tehnične dokumentacije, opis arhitekture, podatkovne baze in obstoječih API-jev.

  • opis trenutnega in ciljnega procesa
  • uporabniške vloge in pravice
  • seznam ključnih funkcionalnosti
  • sistemi za integracijo
  • podatki za migracijo
  • varnostne in infrastrukturne zahteve

Kolikšna je cena poslovne aplikacije

Brez opredeljenega obsega konkretne številke ni mogoče podati brez ugibanja. Strošek sestavljajo analiza, UX/UI, razvoj, podatkovna baza, poslovna logika, integracije, migracija, AI funkcionalnosti, QA, DevOps, infrastruktura in vzdrževanje.

Epix razvija programsko opremo, AI rešitve in avtomatizacije za podjetja in javni sektor. Med referenčnimi projekti so Kwizmo, Smart Venue Platform, BeatLogic.ai in interaktivni kiosk Zdravo Jem za Občino Sevnica.

Pogosta vprašanja

Ali je mogoče ceno aplikacije določiti samo na podlagi seznama funkcionalnosti?

Približno oceno je mogoče pripraviti, vendar mora seznam opisati tudi poslovno logiko, uporabniške vloge, integracije, podatke in druge tehnične zahteve. Enaka funkcionalnost je lahko glede na okolje izvedena zelo različno.

Kaj običajno najbolj vpliva na zahtevnost poslovne aplikacije?

Največji vpliv imajo obseg poslovne logike, integracije, struktura podatkov, migracija, uporabniške pravice, AI funkcionalnosti ter zahteve za infrastrukturo, QA in SLA.

Ali je mobilna aplikacija vključena v razvoj spletnega sistema?

Ne nujno. Če projekt zahteva tudi mobilno aplikacijo, mora biti ta del jasno določen v obsegu, saj lahko zahteva dodatne uporabniške tokove, prilagoditve in QA.

Zakaj je migracijo podatkov treba oceniti ločeno?

Ker je zahtevnost odvisna od kakovosti in strukture obstoječih podatkov, števila virov, dokumentov, preslikave med sistemi in postopka preverjanja po prenosu.

Povezano

Sorodne rešitve

Se sliši kot vaš projekt?

Pošljite opis projekta, obstoječi sistem, razpisno dokumentacijo ali datum dogodka.

Predstavite nam projekt