Kdaj se podjetju splača razviti lastno poslovno rešitev

Kdaj se podjetju splača razviti lastno poslovno rešitev?#

Razvoj lastne poslovne rešitve se podjetju splača takrat, kadar standardna programska oprema ne pokriva ključnega poslovnega procesa, kadar je treba povezati več obstoječih sistemov v enoten pretok podatkov ali kadar rast organizacije presega zmožnosti trenutne infrastrukture. V teh primerih prilagajanje tuje rešitve pogosto stane več, kot bi stal razvoj po meri, hkrati pa ne odpravi temeljne omejitve: proces ostane ujet v logiko, ki je niso zasnovali za vaše podjetje.

Odločitev se redko sprejme na podlagi enega samega razloga. Večina srednje velikih in velikih podjetij ter javnih zavodov se za lastno rešitev odloči, ko ugotovi, da vzdržuje več ločenih sistemov za isto nalogo, da podatki med oddelki ne tečejo samodejno ali da se poročanje vodstvu še vedno sestavlja ročno iz izvozov. Tak vzorec je signal, da obstoječa programska oprema ne sledi več obsegu poslovanja.

Druga pogosta okoliščina je sprememba regulative ali notranjih zahtev po sledljivosti. Javni zavodi in regulirane panoge morajo pogosto izkazati, kako je bila odločitev sprejeta, kdo je podatek vnesel in kje se hrani. Kadar tega standardna rešitev ne omogoča brez obsežnih nadgradnj, postane razvoj po meri bolj predvidljiva pot, ker se zahteve vgradijo neposredno v arhitekturo sistema in ne v naknadne obvode.

Tretji razlog je obseg, ki presega eno funkcijo. Če projekt zadeva hkrati proizvodnjo, nabavo, finance in poročanje vodstvu, redko obstaja ena tržna rešitev, ki bi enakovredno pokrila vse štiri. Takrat je smiselneje zgraditi sistem, ki povezuje obstoječe vire podatkov prek API-jev in dodaja samo tiste funkcije, ki jih trg ne ponuja, namesto da se podjetje prilagaja omejitvam enega samega dobavitelja.

Standardna rešitev ali razvoj po meri: kaj odloča#

Med standardno in po meri zgrajeno rešitvo odloča predvsem to, koliko je poslovni proces podjetja specifičen in koliko sistemov je treba povezati. Če proces sledi splošno uveljavljenemu vzorcu, kakršnega podpira večina tržnih sistemov, je standardna rešitev praviloma hitrejša in cenejša pot. Če pa proces vključuje izjeme, posebna pravila odločanja ali kombinacijo podatkov iz več virov, standardna oprema hitro doseže mejo prilagodljivosti.

Drugo merilo je življenjska doba odločitve. Standardna programska oprema se spreminja po urniku dobavitelja, ne po urniku naročnika; nadgradnje, ukinitve funkcij in spremembe licenciranja so zunaj nadzora podjetja. Lastna rešitev ostane v lasti naročnika toliko časa, kolikor jo potrebuje, in se spreminja po njegovih prioritetah. To je pomembno zlasti za procese, ki so za podjetje konkurenčna prednost in jih ne želi deliti s panogo.

Tretje merilo je število uporabniških vlog in njihova raznolikost. Kadar morajo isti sistem uporabljati proizvodnja, nabava, finance in vodstvo, a vsak oddelek potrebuje drugačen pogled na iste podatke, standardna oprema pogosto zahteva toliko dodatkov in obhodov, da se razlika v ceni in zanesljivosti med standardno in po meri zgrajeno rešitvijo zmanjša. Takrat je smiselno primerjati obe poti na podlagi dejanskega obsega, ne na podlagi začetnega vtisa o enostavnosti.

Kateri obstoječi sistemi vplivajo na odločitev#

Odločitev o razvoju lastne programske opreme je vedno odvisna od tega, kateri sistemi že delujejo v podjetju in kako so med seboj povezani. ERP in CRM sistemi, dokumentni sistemi ter orodja za poročanje običajno hranijo podatke, ki jih mora nova rešitev uporabljati ali dopolnjevati, zato je prvi korak natančen popis obstoječe infrastrukture, njenih API-jev in omejitev, še pred načrtovanjem nove funkcionalnosti.

Kadar podjetje že uporablja enega od uveljavljenih ERP ali CRM sistemov, je treba ugotoviti, kako odprt je njegov API, kakšne so licenčne omejitve za zunanje povezave in kdo znotraj podjetja pozna njegovo notranjo logiko. Ta ocena pogosto pokaže, da ni treba nadomestiti celotnega sistema, temveč zgraditi plast, ki povezuje obstoječe module z novo funkcionalnostjo, ne da bi bilo treba poseči v jedro obstoječe rešitve.

Enako velja za dokumentne in podatkovne sisteme. Če se pogodbe, naročila ali proizvodni nalogi še vedno gibljejo med e-pošto, skupnimi mapami in papirjem, mora nova rešitev najprej določiti, kje je enoten vir resnice za vsak tip podatka. Brez tega vsaka avtomatizacija podeduje obstoječo zmedo, le da jo izvede hitreje.

Pri tej presoji pomaga seznam vprašanj, na katera mora podjetje odgovoriti še pred izbiro izvajalca.

• Kateri sistemi že hranijo podatke, ki jih bo nova rešitev uporabljala
• Kakšen je API ali druga možnost povezave vsakega od teh sistemov
• Kdo je lastnik podatkov in kdo odloča o dostopu do njih
• Katere funkcije mora nova rešitev prevzeti in katere ostanejo v starem sistemu
• Kakšna je trenutna kakovost in urejenost podatkov, ki jih bo treba prenesti

Kako poteka analiza obsega projekta?#

Analiza obsega projekta poteka tako, da se poslovni proces razčleni na posamezne sklope, vsak sklop se oceni glede na zahtevnost in povezave z obstoječimi sistemi, nato se določi vrstni red izvedbe. Namen analize ni popisati vsako podrobnost vnaprej, temveč razmejiti dele projekta, ki jih je mogoče oceniti in izvesti ločeno, od tistih, ki zahtevajo dodatno razjasnitev.

V tej fazi se določijo uporabniške vloge, podatki, ki jih bo sistem potreboval, in sistemi, s katerimi se mora povezati. Pri Epixu to analizo predlagamo kot prvi korak, preden se projekt oceni v celoti, ker šele razčlenjen obseg pokaže, kateri deli so preprosti in kateri zahtevajo globljo tehnično presojo, denimo integracijo z obstoječim ERP ali CRM sistemom.

Rezultat analize je dokument, ki opredeli funkcionalnosti, odvisnosti med sklopi, tveganja in merila za prevzem vsakega dela rešitve. Ta dokument postane osnova za nadaljnje odločanje: kateri sklop se razvije najprej, kateri se lahko prevzame iz obstoječega sistema in kateri zahteva popolnoma nov razvoj. Brez te razmejitve se projekti pogosto zataknejo, ker se obseg med izvedbo nenehno širi.

Cena takega projekta se določi šele po tej analizi, ne pred njo. Na obseg vpliva število uporabniških vlog, količina in stanje podatkov za prenos, zahteve glede varnosti in skladnosti, potreba po mobilnem delu ter raven podpore po uvedbi. Ker se ti dejavniki med projekti močno razlikujejo, splošni cenovni razponi ne bi dali uporabne informacije – natančnejšo oceno dá šele razčlenitev na sklope.

Kdo naj sodeluje pri odločitvi o razvoju?#

Pri odločitvi o razvoju lastne poslovne rešitve morajo sodelovati vodstvo, vodja IT ter vodje oddelkov, katerih procesi so neposredno prizadeti, ker odločitev vpliva na proračun, na obstoječe sisteme in na vsakodnevno delo zaposlenih. Če kateri od teh glasov manjka, se pogosto zgodi, da rešitev tehnično deluje, a je oddelki ne uporabljajo po načrtu.

Vodstvo odloča o prioriteti in proračunu projekta glede na to, koliko poslovne vrednosti prinaša v primerjavi z drugimi investicijami. Vodja IT presoja tehnično izvedljivost, vpliv na obstoječo infrastrukturo in varnostne zahteve. Vodje oddelkov, kot so proizvodnja, nabava, finance ali kadri, pa poznajo dejanski potek dela in lahko že v zgodnji fazi opozorijo na izjeme, ki jih splošen opis procesa ne zajame.

Pri večjih projektih je smiselno določiti tudi notranjega skrbnika projekta na strani naročnika, ki komunicira z izvajalcem, usklajuje odločitve med oddelki in potrjuje posamezne sklope ob njihovem zaključku. Brez te vloge odločitve prehajajo med preveč ljudmi hkrati, kar podaljšuje vsak korak usklajevanja in povečuje tveganje, da se zahteve med izvedbo razlagajo različno.

Pri javnih zavodih se temu pridružijo še zahteve po sledljivosti odločanja in morebitna obveznost javnega naročanja, zato je smiselno vključiti tudi osebo, ki pozna pravne okvire nabave. Pri regulirani panogi je podobno vlogo smiselno nameniti osebi, ki odgovarja za skladnost in varstvo podatkov, saj njena zgodnja vključenost prepreči, da bi se zahteve glede skladnosti dodajale šele proti koncu projekta.

Varnost podatkov in skladnost pri lastnem razvoju#

Varnost podatkov je pri razvoju lastne poslovne rešitve stvar arhitekture, ne naknadne nadgradnje, zato jo je treba opredeliti že v fazi analize obsega. To pomeni določiti, kdo ima dostop do katerih podatkov, kako se vodi revizijska sled sprememb in kako so ločena razvojno, testno in produkcijsko okolje, tako da v testnem okolju nikoli ne nastopajo resnični osebni podatki.

Ločitev okolij ni zgolj tehnična podrobnost, temveč neposredno vpliva na to, kako varno se rešitev testira. Spremembe gredo skozi pregled in testiranje, preden pridejo v produkcijo, kar zmanjša tveganje, da bi napaka ali varnostna vrzel prišla neposredno do uporabnikov. Pri sistemih, ki hranijo osebne ali finančne podatke, je ta korak še pomembnejši, ker napake v produkciji prizadenejo prave stranke ali zaposlene.

Vprašanje lastništva podatkov je prav tako del varnostne presoje. Izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta ali posameznega sklopa. To naročniku omogoča, da po uvedbi ni odvisen od enega izvajalca za dostop do lastnih podatkov, kar je pomembno tako pri menjavi partnerja kot pri morebitnem notranjem prevzemu nadaljnjega razvoja.

Pri projektih v javnem sektorju ali reguliranih panogah je treba že na začetku opredeliti, katere zahteve glede skladnosti in varstva podatkov veljajo za konkreten proces, in te zahteve vgraditi v arhitekturo sistema, ne dodajati naknadno. Jasno dogovorjen obseg varnostnih zahtev prav tako vpliva na to, kako se določi obseg testiranja in kdo poleg razvojne ekipe presoja, ali rešitev te zahteve dejansko izpolnjuje.

• Kdo ima dostop do katerih podatkov in kako se ta dostop dodeljuje
• Kako se vodi revizijska sled sprememb v sistemu
• Kako so ločena razvojno, testno in produkcijsko okolje
• Kako potekata pregled in testiranje sprememb pred objavo v produkcijo
• Kdo je lastnik izvorne kode in podatkov po zaključku projekta

Kako razvoj po meri vpliva na zaposlene in delovne procese#

Razvoj poslovne rešitve po meri vpliva na zaposlene predvsem tako, da spremeni, kako vsak dan opravljajo svoje naloge, zato mora biti sprememba procesa del projekta, ne njegova stranska posledica. Če se nova rešitev vpelje brez priprave zaposlenih na spremenjen potek dela, se pogosto zgodi, da ljudje ob novem sistemu še naprej uporabljajo stare razpredelnice ali e-pošto.

Zato je smiselno že v fazi analize obsega vključiti ljudi, ki bodo sistem dejansko uporabljali, ne le njihovih vodij. Njihovo poznavanje izjem in obhodov, ki so se nabrali skozi leta dela s starim sistemom, pogosto razkrije zahteve, ki jih vodstvo ne pozna. Ta vključenost tudi zmanjša odpor ob uvedbi, ker zaposleni v rešitvi prepoznajo odgovor na lastne težave, ne vsiljene spremembe od zgoraj.

Uvedba nove rešitve pomeni tudi usposabljanje in dokumentacijo, ki ostane pri naročniku. Dokumentacija, dostopi in postopki za vsakdanjo uporabo so del primopredaje, kar zaposlenim omogoča, da se na novo rešitev lahko vedno znova navežejo brez odvisnosti od posameznika, ki je sistem poznal najbolje. To je še posebej pomembno pri fluktuaciji zaposlenih ali pri prehodu nalog med oddelki.

Nazadnje je treba realno oceniti, kako hitro lahko posamezni oddelek sprejme novo rešitev, in temu prilagoditi vrstni red uvajanja po sklopih. Postopna uvedba, pri kateri se najprej uvede sklop z največjo poslovno vrednostjo in najmanjšim tveganjem, zaposlenim omogoča, da se navadijo na nov sistem, preden se nanj naveže še preostali del procesa.

Kako izbrati izvajalca za razvoj poslovne programske opreme?#

Izvajalca za razvoj poslovne programske opreme je treba izbrati glede na to, ali lahko prevzame celoten projekt ali le posamezen sklop, kako pristopa k analizi obstoječih sistemov in kakšen model podpore ponuja po uvedbi, ne zgolj glede na ceno ponudbe. Izvajalec, ki ne postavi vprašanj o obstoječih sistemih in podatkih, pogosto ne razume dejanskega obsega projekta.

Pomembno je preveriti, kako izvajalec organizira projekt: ali določi projektnega vodjo, kako so razdeljene odgovornosti med ekipami, kakšen je dogovorjen način komunikacije in poročanja ter kako poteka testiranje pred objavo sprememb v produkcijo. Pri večjih projektih, ki zadevajo več oddelkov hkrati, je struktura odločanja pogosto pomembnejša od posameznega tehnološkega izbora.

Preveriti velja tudi, ali izvajalec lahko prevzame obstoječ ali nedokončan sistem po pregledu izvorne kode, arhitekture, infrastrukture in podatkov, saj se marsikateri projekt ne začne na praznem listu, temveč nadaljuje delo prejšnjega izvajalca ali notranje ekipe. Zmožnost takega prevzema je pokazatelj, da izvajalec razume tudi sisteme, ki jih ni sam zgradil, in ne le lastnih rešitev.

Nazadnje je smiselno preveriti obseg kadra, ki ga izvajalec lahko dejansko postavi na projekt: ali gre za eno samo ekipo ali za širšo mrežo, iz katere se lahko sestavi projektna skupina z ustreznimi vlogami – od arhitekture in razvoja do varnosti, QA in podpore. Pri Epixu to pomeni, da lahko glede na obseg projekta sestavimo ekipo iz lastnih kadrov in specialistične partnerske mreže, ne da bi bilo treba naročnika napotiti k drugemu izvajalcu za del projekta.

• Ali izvajalec pred ponudbo izvede analizo obstoječih sistemov in podatkov
• Kako je organizirano vodenje projekta in poročanje naročniku
• Ali lahko prevzame obstoječ ali nedokončan sistem po pregledu kode in arhitekture
• Kakšen je postopek testiranja pred objavo sprememb v produkcijo
• Kakšen model podpore in odzivnosti ponuja po uvedbi
• Ali ima dostop do kadra za celoten obseg projekta ali le za del

Vzdrževanje, podpora in SLA po uvedbi#

Po uvedbi lastne poslovne rešitve je treba določiti, kdo spremlja njeno delovanje, kdo odpravlja napake in po kakšnih pravilih se obravnavajo zahteve za spremembe, saj projekt s tem, ko gre rešitev v produkcijo, ne postane zaključen, temveč preide v novo fazo. Brez dogovorjenega modela podpore se manjše napake nabirajo, dokler ne postanejo ovira za vsakdanje delo.

Dogovor o podpori se običajno razdeli po stopnji resnosti napake: izpad celotnega sistema ali ključnega dela ima najvišjo prednost, motnja posamezne funkcije se obravnava po dogovorjeni prednosti, manjša napaka brez vpliva na poslovanje se uvrsti v naslednjo objavo, zahteva za spremembo ali nadgradnjo pa se najprej ovrednoti po obsegu, preden se določi termin izvedbe.

Poleg odprave napak lahko podpora vključuje tehnične in varnostne posodobitve ter nadaljnji razvoj rešitve, saj se potrebe podjetja po uvedbi redko ustalijo. Obseg podpore se določi po projektu in je lahko ozek, osredotočen le na odpravo napak, ali širši, vključno z rednim razvojem novih funkcij glede na spremembe v poslovanju ali regulativi.

Za naročnika je ključno, da ostane lastnik izvorne kode in podatkov ne glede na izbrani model podpore, saj to omogoča menjavo izvajalca podpore brez izgube dostopa do lastnega sistema. Dogovor o podpori naj zato vedno vključuje tudi dokumentacijo, dostope in gesla kot del primopredaje, ne le obljubo odzivnosti.

Prevzem obstoječega ali nedokončanega sistema#

Prevzem obstoječega ali nedokončanega sistema je pogosto realnejša pot kot razvoj znova, kadar je velik del rešitve že vložen, a projekt zaradi menjave izvajalca, odhoda ključnih ljudi ali spremembe prioritet ni bil dokončan. V takih primerih se najprej pregledajo izvorna koda, arhitektura, infrastruktura in podatki, šele nato se presodi, kateri deli se lahko obdržijo in kateri je treba zgraditi na novo.

Ta pregled pokaže, ali je obstoječa arhitektura sposobna prenesti načrtovano rast obsega uporabnikov in podatkov ali je bila zasnovana za bistveno manjši obseg, kot ga podjetje danes potrebuje. Pokaže tudi, kako je urejena dokumentacija in ali je sploh mogoče ugotoviti, zakaj so bile sprejete določene tehnične odločitve, kar neposredno vpliva na to, koliko časa bo trajalo, da nova ekipa sistem razume.

Odločitev med nadaljevanjem obstoječega sistema in razvojem novega po meri se zato sprejme šele po tej analizi, ne pred njo. Pri nekaterih projektih se izkaže, da je smiselno obdržati jedro sistema in ga dopolniti z manjkajočimi funkcijami ali povezavami, pri drugih pa pregled pokaže, da bi bilo nadaljnje popravljanje dražje in počasnejše od novega razvoja po meri, prilagojenega trenutnim potrebam podjetja.

Ne glede na izbrano pot ostaja temeljno pravilo enako: izvorna koda in podatki so last naročnika, dokumentacija in dostopi pa so del primopredaje ob vsakem prehodu med izvajalci. To naročniku omogoča, da odločitev o nadaljevanju ali novem razvoju sprejme na podlagi dejanskega stanja sistema in ne na podlagi tega, kdo trenutno hrani dostope do njega.