Kaj vključuje izdelava poslovne spletne aplikacije

Kaj je poslovna spletna aplikacija in zakaj zahteva drugačen pristop kot spletna stran#

Poslovna spletna aplikacija ni spletna stran, ki informacije zgolj prikaže, temveč sistem, ki izvaja poslovne procese: prijavo uporabnikov, dodeljevanje vlog in pravic, obdelavo podatkov ter povezavo z drugimi sistemi v podjetju. Izdelava spletnih aplikacij zato zahteva drugačen pristop kot izdelava predstavitvene spletne strani, saj mora rešitev prenesti sočasno uporabo večjega števila zaposlenih, ohraniti sledljivost sprememb in zagotoviti, da imajo zaposleni dostop le do podatkov, za katere so pooblaščeni.

V srednje velikih in velikih podjetjih tako aplikacijo uporabljajo različne skupine: zaposleni v proizvodnji, financah, kadrovski službi ali nabavi, pa tudi zunanji partnerji, dobavitelji ali stranke. Vsaka skupina potrebuje drugačen nabor funkcij in drugačno raven dostopa, zato je treba vloge opredeliti že na začetku projekta. Brez jasne delitve pravic se pogosto zgodi, da en oddelek vidi podatke drugega oddelka, kar v praksi pomeni tveganje za varnost podatkov in za skladnost poslovanja.

Odločitev o izdelavi poslovne spletne aplikacije zato ni le tehnično vprašanje, temveč organizacijsko. Vpliva na to, kako bodo oddelki med seboj delili podatke, kdo bo odgovoren za posamezen del sistema in kako se bo aplikacija vklopila v obstoječe okolje, od ERP in CRM sistemov do orodij za poročanje. Prav zato je smiselno že pred začetkom razvoja določiti obseg, odgovornosti in način sodelovanja z izvajalcem.

Kako poteka izdelava spletnih aplikacij od analize do uvedbe?#

Izdelava spletnih aplikacij poteka po jasno ločenih fazah: analiza zahtev, zasnova arhitekture, UX/UI oblikovanje, razvoj, testiranje in uvedba v produkcijsko okolje. Pri večjih projektih se faze ne izvajajo linearno v enem koraku, temveč po sklopih, ki jih je mogoče ločeno načrtovati, testirati in sprejeti. Tak pristop omogoča, da naročnik sproti preverja, ali rešitev ustreza dejanskim procesom v podjetju, še preden je razvita celotna aplikacija.

Pri večjih projektih se določi projektni vodja, ki je odgovoren za usklajevanje med ekipami, roki in komunikacijo z naročnikom. To je pomembno, kadar projekt posega v več oddelkov hkrati, saj mora nekdo spremljati, ali so zahteve financ, proizvodnje ali kadrovske službe med seboj usklajene. Projekt se lahko prevzame v celoti, od analize do podpore, ali pa le kot posamezen sklop, na primer samo UX/UI zasnova ali samo integracija z obstoječim sistemom.

Posebna okoliščina je prevzem že obstoječega ali nedokončanega sistema. V tem primeru se izdelava spletne aplikacije začne s pregledom izvorne kode, arhitekture, infrastrukture in podatkov, šele nato se določi, kateri deli se ohranijo in kateri je treba prenoviti. Tak pregled razkrije tudi tehnične dolgove in varnostne vrzeli, ki jih je treba nasloviti, preden se nadaljuje razvoj novih funkcij. Tak pregled je del odgovornega prevzema in šele po njem je mogoče zanesljivo oceniti nadaljnje korake projekta.

• Analiza zahtev in popis obstoječih sistemov
• Zasnova arhitekture in podatkovnega modela
• UX/UI oblikovanje uporabniških vlog in zaslonov
• Razvoj aplikacije po dogovorjenih sklopih
• Testiranje: ročno, avtomatizirano in prevzemno
• Uvedba v produkcijsko okolje in izobraževanje uporabnikov
• Podpora, vzdrževanje in nadaljnji razvoj

Katere sisteme je treba povezati z novo poslovno aplikacijo#

Poslovna spletna aplikacija redko deluje samostojno. V podjetju z več kot milijon evrov letnih prihodkov običajno že obstajajo sistem za vodenje poslovanja (ERP), sistem za upravljanje odnosov s strankami (CRM) ter sistemi za hrambo in obdelavo dokumentov. Nova aplikacija mora z njimi izmenjevati podatke prek vmesnikov (API), zato je treba že v fazi analize popisati, kateri sistemi obstajajo, kakšni so njihovi vmesniki in kje lahko pride do podvajanja ali izgube podatkov.

Podjetja pogosto uporabljajo enega od uveljavljenih sistemov za vodenje poslovanja ali odnosov s strankami, izbira konkretnega sistema pa je odločitev naročnika in ni del te ponudbe. Pomembnejše od imena sistema je, kakšne vmesnike ponuja, kako pogosto se podatki osvežujejo in kdo je lastnik posameznega podatkovnega polja. Te odgovore je treba dobiti še pred začetkom razvoja integracije, sicer se tveganje prenese v kasnejšo fazo projekta.

Vsaka integracija prinaša tudi vprašanje odgovornosti: kdo vzdržuje vmesnik, kaj se zgodi, če se podatkovna struktura v obstoječem sistemu spremeni, in kako se napake pri prenosu podatkov zaznajo. Ta vprašanja je smiselno razrešiti v dogovoru o podpori, še preden se aplikacija uvede v produkcijsko okolje, saj se integracije med sistemi pogosto izkažejo za najbolj občutljiv del celotnega projekta. Zato je smiselno integracije načrtovati in testirati ločeno od preostalega razvoja.

• Sistem za vodenje poslovanja (ERP)
• Sistem za upravljanje odnosov s strankami (CRM)
• Sistemi za hrambo in obdelavo dokumentov (DMS, ECM)
• Orodja za poslovno poročanje
• Proizvodni ali skladiščni sistemi
• Kadrovski sistemi in evidence delovnega časa
• Plačilni ali računovodski sistemi

Kaj vključuje UX/UI zasnova za različne uporabniške vloge#

UX/UI zasnova poslovne aplikacije se razlikuje od oblikovanja javne spletne strani, ker mora služiti ljudem z zelo različnimi nalogami in ravnjo digitalnega znanja. Zaposleni v proizvodnji bo aplikacijo uporabljal drugače kot analitik v financah ali vodja nabave, zato se zasloni, meniji in postopki oblikujejo glede na konkretno vlogo, ne glede na povprečnega uporabnika. Napačno zasnovan vmesnik pogosteje vodi do napačno vnesenih podatkov kot do nezadovoljstva z videzom.

Del zasnove je tudi določitev, katere akcije sme posamezna vloga izvesti: kdo lahko podatke le pregleduje, kdo jih sme urejati in kdo odobrava spremembe pred objavo. Taka delitev je še posebej pomembna pri procesih, ki vplivajo na finance, kadre ali proizvodnjo, kjer napačen vnos ali nepooblaščena sprememba povzroči realne poslovne posledice. Zato se vloge in dovoljenja določijo skupaj z vodji posameznih oddelkov, ne le s projektno ekipo.

Kadar aplikacijo uporabljajo tudi zaposleni na terenu ali v proizvodnji, je treba zasnovo prilagoditi tudi uporabi na manjših zaslonih in v okoljih, kjer ni vedno zanesljive povezave. Taki primeri zahtevajo preprostejše zaslone z manj koraki in jasno povratno informacijo o tem, ali je bil podatek uspešno shranjen, saj se napake v takem okolju opazijo šele, ko je prepozno za hiter popravek.

Kaj obsega razvoj poslovne spletne aplikacije#

Razvoj zajema vse, od enterprise informacijskih sistemov in poslovnih aplikacij do SaaS platform, portalov in administracijskih sistemov, pri čemer se posamezni sklopi gradijo in med seboj povezujejo prek vmesnikov (API). Epix v tem delu projekta pokriva razvoj programske opreme, API-integracije in avtomatizacijo poslovnih procesov, delovnih tokov, poročanja ter obvestil, kar pomeni, da se ročna opravila, kot je prepisovanje podatkov med sistemi ali ročno sestavljanje poročil, nadomestijo z avtomatiziranimi koraki.

Kadar je del procesa obdelava dokumentov, iskanje po vsebini ali podpora pri odločanju, se v razvoj vključi tudi AI: agenti, RAG, semantično iskanje ali ekstrakcija podatkov iz dokumentov. Taki elementi niso samostojen projekt, temveč del iste aplikacije, ki uporabniku na primer samodejno predlaga naslednji korak ali izlušči podatke iz prejetega dokumenta, namesto da bi jih zaposleni vnašal ročno. Tak pristop skrajša čas obdelave dokumentov, ne da bi spremenil, kdo je za rezultat odgovoren.

Pri projektih, ki posegajo v specifična področja, kot so oblak, visoka razpoložljivost ali kibernetska varnost, Epix sestavi projektno ekipo iz svoje specialistične partnerske mreže, ki pokriva cloud in DevOps inženiring, varnostno arhitekturo ter mobilni razvoj. Tako se obseg ekipe prilagodi zahtevnosti projekta, namesto da bi naročnik moral sam iskati in usklajevati več ločenih izvajalcev za posamezne tehnične sklope. Tako naročnik dobi ustrezen kader, ne da bi moral sam sestavljati več ločenih pogodb.

• Enterprise informacijski sistemi in poslovne aplikacije
• SaaS platforme
• ERP, CRM, DMS in ECM rešitve
• Delovni tokovi (workflow) in administracijski sistemi
• Portali za zaposlene, partnerje ali stranke
• Marketplace in booking rešitve

Varnost in ločena okolja za razvoj, testiranje in produkcijo#

Razvojno, testno in produkcijsko okolje se pri izdelavi poslovne spletne aplikacije vedno ločijo, saj sprememba, ki gre neposredno v produkcijo, ogrozi delovanje sistema, ki ga zaposleni dnevno uporabljajo. Vsaka sprememba zato najprej gre skozi pregled in testiranje, šele nato se objavi v produkcijskem okolju. Taka ločitev je še posebej pomembna v podjetjih, kjer izpad aplikacije pomeni zastoj v proizvodnji, financah ali komunikaciji s strankami.

V testnem okolju se nikoli ne uporabljajo pravi osebni podatki, kar zmanjšuje tveganje, da bi testni podatki prišli v napačne roke ali bili obdelani mimo pravil o varstvu osebnih podatkov. To je pomembno zlasti za aplikacije, ki obdelujejo podatke o zaposlenih, strankah ali poslovnih partnerjih, saj je GDPR okvir, znotraj katerega se takšni podatki smejo obdelovati, enak ne glede na okolje.

Varnostna vprašanja, ki jih je treba razrešiti pred uvedbo, vključujejo nadzor dostopa po vlogah, beleženje sprememb in redne varnostne posodobitve. Pri projektih, ki zahtevajo poglobljeno varnostno presojo, na primer penetracijsko testiranje ali vulnerability management, Epix te naloge pokrije prek svoje specialistične partnerske mreže, saj gre za ločeno strokovno področje, ki dopolnjuje razvojno ekipo, ne pa je nadomešča, saj mora biti presoja neodvisna od ekipe, ki je aplikacijo razvila.

Kako poteka testiranje pred objavo aplikacije v produkcijo?#

Testiranje poteka v več plasteh: ročno preverjanje po vnaprej pripravljenih scenarijih, avtomatizirano testiranje in testiranje v okviru CI/CD procesa, preden se sprememba objavi. Cilj je zaznati napako, še preden jo opazi uporabnik, in preveriti, da nova funkcija ne pokvari tistega, kar je že delovalo. Pri poslovnih aplikacijah, ki povezujejo več sistemov, je prav testiranje integracij pogosto tisto, kjer se pokažejo najresnejše težave.

Pri zahtevnejših projektih se testiranje izvede ločeno od razvojne ekipe, saj neodvisen QA lažje opazi odstopanje, ki ga razvijalec, ki je kodo napisal, spregleda. Prevzemno testiranje se izvede na koncu sklopa, po merilih, ki so bila dogovorjena že v fazi analize, tako da naročnik vnaprej ve, kaj točno se preverja in kdaj je sklop mogoče šteti za zaključen. Tako se izognemo sporom o tem, ali je posamezen del projekta dejansko zaključen.

Testiranje ni enkraten korak pred uvedbo, temveč se ponavlja ob vsaki naslednji spremembi. Regresijsko testiranje preveri, ali je nova funkcija vplivala na obstoječe dele aplikacije, performančno testiranje pa, ali sistem prenese pričakovano število hkratnih uporabnikov. Oboje je še posebej pomembno pri aplikacijah, ki jih dnevno uporablja več oddelkov hkrati. Tak način testiranja je del rednega vzdrževanja, ne enkratnega dogodka ob zagonu aplikacije.

• Testni scenariji za posamezno uporabniško vlogo
• Ročno testiranje novih funkcij
• Avtomatizirano testiranje (funkcijsko, API, regresijsko)
• Testiranje v okviru CI/CD procesa
• Prevzemno testiranje po vnaprej dogovorjenih merilih
• Neodvisen QA, ločen od razvojne ekipe

Kaj vključuje podpora po uvedbi poslovne spletne aplikacije?#

Podpora po uvedbi vključuje nadzor delovanja, odpravo napak, SLA z dogovorjenimi odzivnimi časi, tehnične in varnostne posodobitve ter nadaljnji razvoj aplikacije. Obseg podpore se določi po projektu, saj se potrebe podjetja z milijonskim prometom razlikujejo od potreb manjše organizacije. Pomembno je, da je podpora dogovorjena še pred uvedbo, ne šele takrat, ko se pojavi prva napaka, saj se v tem trenutku najbolj pozna, kako jasno so bile odgovornosti razdeljene vnaprej.

Razdelitev na razrede pomaga, da se izpad celotnega sistema obravnava drugače kot manjša kozmetična napaka. Odzivni časi za posamezen razred se dogovorijo v pogodbi o podpori glede na kritičnost aplikacije za poslovanje, saj univerzalnega odzivnega časa, ki bi ustrezal vsem podjetjem enako, ni. Za aplikacijo, od katere je odvisna proizvodnja, so pričakovanja drugačna kot za interno orodje, ki ga uporablja le ena skupina zaposlenih.

Podpora po uvedbi ne pomeni le odpravljanja napak, temveč tudi nadaljnji razvoj: nove funkcije, prilagoditve zakonodaji ali povezavo z dodatnim sistemom, ki ga podjetje uvede kasneje. Zato je smiselno, da isti izvajalec, ki je aplikacijo razvil, pozna tudi njeno arhitekturo in lahko nadaljnje spremembe izvede brez ponovnega podrobnega pregleda celotnega sistema. To je pomembno zlasti takrat, ko se zakonodaja ali organizacija podjetja spremeni hitreje, kot je bilo predvideno ob zagonu aplikacije.

• Razred 1 — izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Razred 2 — motnja: sistem deluje, posamezna funkcija ne
• Razred 3 — napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• Razred 4 — zahteva: sprememba ali nadgradnja, obseg in termin se uskladita posebej

Kdo je lastnik kode in podatkov po zaključku projekta#

Izvorna koda in podatki so last naročnika, ne izvajalca. To velja ne glede na to, ali je aplikacijo razvil Epix od začetka ali je šlo za prevzem že obstoječega sistema. Ob zaključku projekta ali posameznega sklopa so dokumentacija, dostopi in gesla del primopredaje, tako da naročnik ni odvisen od enega izvajalca za vsak nadaljnji poseg v sistem. Taka ureditev velja ne glede na obseg projekta, ki ga Epix prevzame.

Ta določba je še posebej pomembna pri podjetjih z več kot milijon evrov letnih prihodkov, kjer menjava izvajalca, reorganizacija IT oddelka ali prehod na notranjo ekipo ni izjema, temveč realna možnost v življenjski dobi aplikacije. Jasna primopredaja kode, podatkov in dokumentacije pomeni, da tak prehod ne ustavi poslovanja in da nov izvajalec lahko nadaljuje delo brez obnavljanja sistema iz nič.

Enako velja za nedokončane ali podedovane sisteme: preden se nadaljuje razvoj, se pregleda izvorna koda, arhitektura, infrastruktura in podatki, da je jasno, kaj se ohrani in kaj je treba prenoviti. Tak pregled je del odgovornega prevzema projekta in prepreči, da bi se nadaljnji razvoj gradil na nepreverjenih temeljih. Taka praksa je še posebej pomembna, kadar je bil prejšnji izvajalec nedosegljiv ali dokumentacija pomanjkljiva.

Kako izbrati izvajalca za izdelavo poslovne spletne aplikacije in od česa je odvisna cena?#

Pri izbiri izvajalca je najpomembneje, ali lahko prevzame projekt v celoti, od analize do podpore po uvedbi, ali pa le posamezen sklop, na primer samo integracijo ali samo UX/UI zasnovo. Enako pomembno je, ali izvajalec ob večjih projektih določi projektnega vodjo, jasne odgovornosti ekip in dogovorjen način poročanja, saj to vpliva na to, kako se bo projekt odvijal, ko sodeluje več oddelkov hkrati in ko je treba uskladiti zahteve, ki si včasih nasprotujejo.

Cene izdelave poslovne spletne aplikacije ne navajamo v splošnih razponih, ker je odvisna od obsega funkcionalnosti, števila uporabniških vlog, količine in stanja podatkov za prenos, zahtev glede varnosti in skladnosti ter tega, ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega. Prav tako nanjo vpliva, ali je potreben mobilni del, kakšen je obseg AI funkcij in kakšna raven podpore po uvedbi je dogovorjena.

Pred oceno cene zato predlagamo krajšo analizo, ki obseg projekta razčleni na sklope, tako da je vsak sklop mogoče oceniti in izvesti ločeno. Tak pristop naročniku da jasnejšo sliko, kateri del projekta je nujen takoj in kateri lahko sledi kasneje, namesto da bi se cena ocenjevala za celoten projekt, še preden je obseg sploh natančno znan. Tako se izognemo oceni, ki ne upošteva dejanske zahtevnosti posameznega sklopa.

• Obseg funkcionalnosti in število uporabniških vlog
• Koliko obstoječih sistemov je treba povezati
• Ali gre za nov sistem ali prevzem obstoječega
• Količina in stanje podatkov za prenos
• Zahteve glede varnosti, revizijske sledi in skladnosti
• Obseg testiranja in potreba po neodvisnem QA
• Raven podpore in dogovorjeni odzivni časi po uvedbi