Kako napisati zahteve za ERP: poglavja in popoln vzorec za vaš razpis

Dobro napisana ERP predloga zahtev (v tujini jo pogosto imenujejo RFP za ERP) je največ, kar lahko naredite za uspeh projekta, še preden se pogovorite s prvim ponudnikom. Podjetja, ki gredo na trg brez pisnih zahtev, običajno dobijo ponudbe, ki jih ni mogoče primerjati, nato pa med uvedbo odkrivajo, da je manjkalo prav tisto, kar so šteli za samoumevno. Ta vodnik pojasnjuje, čemu dokument služi, kako je sestavljen in kako ga napišete tako, da bo uporaben za direktorja, finančnega vodjo, vodjo informatike in računovodjo. Na koncu najdete popoln vzorec za prepis.

Čemu služi ERP predloga zahtev

Dokument z zahtevami je skupna točka vseh, ki odločajo o projektu. Služi trem namenom:

• Notranje usklajevanje. Ko morate zapisati, kako dejansko poteka naročilo, od prejema povpraševanja do izdanega e-računa, se razlike med oddelki pokažejo hitro in jih je ceneje rešiti na papirju kot v testnem okolju.
• Primerljive ponudbe. Vsi ponudniki odgovarjajo na ista vprašanja, zato lahko primerjate ne le ceno, ampak tudi obseg, predpostavke in tveganja.
• Podlaga za pogodbo. Kar je v zahtevah jasno opisano, lahko pozneje umestite v obseg dela in sprejemne kriterije. Kar ni zapisano, postane predmet dodatnih pogajanj.

Predloga zahtev ni tehnična specifikacija za razvijalce. Opisuje potrebe poslovanja, ne zaslonov in tabel. Natančno zasnovo pripravi integrator v fazi analize, ko pozna izbrani program.

Kje je mesto dokumenta v izbiri ERP

Zahteve so tretji korak v logičnem zaporedju: najprej ugotovite, ali sploh potrebujete ERP in kakšno vrsto (vodnik kako izbrati ERP), nato napišete zahteve, nato jih pošljete izbranim ponudnikom ali integratorjem (izbira ERP integratorja). Šele po prejemu ponudb sledijo predstavitve, referenčni pogovori in pogajanja. Če zahteve pišete po predstavitvah, jih nehote prilagodite temu, kar vam je ponudnik pokazal, in izgubite objektivnost.

Kdo naj sodeluje pri pisanju

Pri slovenskih malih in srednjih podjetjih se zahteve pogosto naložijo samo eni osebi, običajno vodji računovodstva ali informatike. To je napaka. Uspešen dokument nastane iz kratkih delavnic z ljudmi, ki procese živijo:

• Direktor ali lastnik določi cilje, obseg in prednostne naloge.
• Finančni vodja in računovodja opišeta knjiženje, obračun DDV, e-račune, zaključek obdobja in poročanje.
• Vodja nabave in skladišča opišeta naročanje, prevzem, zaloge in sledljivost.
• Vodja prodaje opiše ponudbe, pogodbe, cenike, popuste in obračun provizij.
• Vodja proizvodnje ali izvedbe opiše kosovnice, delovne naloge, kapacitete in beleženje časa.
• Informatik opiše obstoječe sisteme, povezave, varnost in zahteve glede gostovanja.

Naj dokument ima enega lastnika, ki zbere vse prispevke in odgovarja za končno različico. Brez tega zahteve hitro postanejo seznam želja, v katerem ima vsak oddelek svoj poseben modul.

Priporočena struktura dokumenta

Spodnja tabela prikazuje poglavja, ki jih mora imeti vsak resen dokument, in vprašanje, na katerega posamezno poglavje odgovarja.

Poglavje za poglavjem: kaj napisati

Predstavitev podjetja

Ponudnik mora v nekaj odstavkih razumeti, s kom ima opravka. Opišite dejavnost, pravno obliko, število podjetij v skupini in lokacij ter jezike in valute, v katerih poslujete. Navedite, ali prodajate v Sloveniji, v državah nekdanje Jugoslavije ali širše v Evropski uniji, saj to vpliva na davčne zahteve in prevode dokumentov. Konkretnih številk (število zaposlenih, promet) ne pišite, če vam ni do tega; za začetek zadošča razred velikosti podjetja in uporabnikov.

Cilji in obseg projekta

Cilji naj bodo poslovni, ne tehnični. Namesto »želimo moderen sistem« zapišite »želimo zmanjšati ročno prepisovanje med prodajo in računovodstvom« ali »želimo imeti v istem trenutku pregled nad zalogo v vseh skladiščih«. Jasno zapišite tudi, kaj je izven obsega, na primer upravljanje kadrov ali spletna trgovina, ki ju boste obravnavali v drugi fazi. To je najcenejši način, da preprečite širjenje obsega.

Poslovni procesi

To je najpomembnejše poglavje in tisto, ki ga podjetja najpogosteje preskočijo. Za vsak ključni proces napišite kratek opis v obliki zaporedja korakov: kdo, kaj, s čim in kdaj. Dovolj so naslednji procesi:

• od povpraševanja do plačila (ponudba, naročilo, dobava, račun, terjatev),
• od potrebe do plačila dobavitelju (zahtevek, naročilnica, prevzem, prejeti račun, plačilo),
• upravljanje zalog in skladišč,
• proizvodnja ali izvedba storitev,
• finančno knjigovodstvo in zaključek obdobja,
• poročanje vodstvu.

Pri vsakem procesu zabeležite tudi izjeme: kaj se zgodi pri reklamaciji, delnem plačilu, vrnitvi blaga, računu v tuji valuti. Prav izjeme določajo, ali bo program ustrezal ali ne.

Funkcionalne zahteve po modulih

Zahteve razdelite po področjih in jih označite po pomembnosti: obvezno, zaželeno, po izbiri. Brez te razvrstitve bo vsak ponudnik na vse odgovoril »da« in primerjava bo brez vrednosti. Pri vsaki zahtevi naj bo prostor za odgovor ponudnika, ki mora izbrati eno od možnosti: v standardu, z nastavitvijo, z dodatnim razvojem, ni mogoče.

Posebej pazite pri preskoku med splošnimi in ozko slovenskimi zahtevami. Splošne zahteve (glavna knjiga, odprte postavke, amortizacija) najdete pri vsakem ponudniku. Razlike so v podrobnostih, kot so slovenski kontni načrt, obrazci za davčne evidence, obračun DDV z izmenjavo podatkov prek eDavkov in lokalni obrazci za zaposlene. Teh podrobnosti zato ne skrivajte v splošne besede.

Tehnične zahteve

Tehnično poglavje naj odgovori na tri vprašanja: kje bo sistem stal, kako se bo povezoval in kako bo zavarovan. Za gostovanje navedite, ali dopuščate oblak, zasebni oblak ali lastni strežnik; razmislek o tem je v vodniku oblak ali lastni strežnik. Zapišite zahteve glede varnostnih kopij, obnovitve po okvari, nadzora dostopa po vlogah in skladnosti z Splošno uredbo o varstvu podatkov (GDPR). Naštejte vse sisteme, s katerimi se mora ERP povezati: spletna trgovina, bančne povezave, sistem za razporejanje dela, zunanji skladiščni ali dostavni sistem, orodja za poslovno analitiko.

Zakonske zahteve v Sloveniji

Slovensko podjetje mora v zahteve zapisati obveznosti, ki so vezane na državo. Najpogosteje gre za:

• izdajanje in prejemanje e-računov v obliki, ki jo zahtevajo stranke, zlasti javni sektor (več v vodniku o e-računih in obračunu DDV),
• davčno potrjevanje računov pri gotovinskem poslovanju, ki ga nadzira FURS (podrobnosti v vodniku o davčni blagajni in ERP),
• obračun in poročanje DDV ter izmenjavo podatkov z državnimi portali,
• hrambo dokumentacije v zahtevanih rokih in njeno nespremenljivost,
• podatkovno povezavo z zunanjim računovodskim servisom, če knjigovodstvo ni v hiši.

Splošen pregled najdete v vodniku o zakonskih zahtevah za ERP. Zahteve naj ponudnik potrdi z opisom, kako jih izpolni, ne le z odgovorom »da«.

Prenos podatkov

Podjetja prenos podatkov pogosto podcenijo. V zahtevah zapišite, katere podatke boste prenesli (partnerji, artikli, začetna stanja, odprte postavke, osnovna sredstva), iz katerih sistemov in v kakšni obliki so danes. Navedite tudi, kakšno zgodovino želite ohraniti v novem sistemu in kakšno samo v arhivu. Ponudnik naj opiše svoj pristop k čiščenju, preslikavi in preizkusnemu prenosu. Več o tem je v vodniku o migraciji ERP.

Načrt uvedbe in vzdrževanje

Opišite, kako si predstavljate uvedbo: v enem koraku ali po fazah, po podjetjih ali po modulih, ter katere obdobje poslovnega leta ni primerno za preklop. Navedite, kdo bo na vaši strani sodeloval v projektu in koliko časa mu lahko dovolite. Ponudnika vprašajte po šolanju, dokumentaciji, podpori po zagonu in pogojih za nadaljnji razvoj. Pri tem poglavju vam bo v pomoč vodnik o uvedbi ERP.

Proračun

Ne skrivajte proračunskega okvira, če ga imate. Ponudnik, ki ga pozna, bo predlagal rešitev, ki je izvedljiva. Ločite stroške licenc ali naročnine, uvedbe, prilagoditev, šolanja in vzdrževanja. Zahtevajte, da ponudbe vsebujejo enako razčlenitev, sicer jih ne boste mogli primerjati. Za okvir razmišljanja o strukturi stroškov glejte ceno ERP.

Merila izbire

Merila določite, preden dobite ponudbe, in jih sporočite ponudnikom. Običajno jih utežite v kategorije, kot so skladnost s funkcionalnimi zahtevami, ustreznost za slovenske razmere, izkušnje v vaši panogi, kakovost načrta uvedbe, skupni stroški lastništva, tehnična arhitektura in vzdrževanje. Ne uporabljajte najnižje cene kot edinega merila; ena najpogostejših napak, opisanih v vodniku o napakah pri ERP projektih, je ravno izbira na podlagi zneska na naslovnici ponudbe.

Kako ponudniki odgovarjajo na zahteve

Da bi bili odgovori primerljivi, pripravite obrazec za odgovor in ga priložite dokumentu. Najbolj uporabne so naslednje odgovorne kategorije:

Dodajte stolpec za opombe in stolpec za povezavo na ceno, tako da vidite, katere zahteve so skrite v dodatnih stroških. Če ponudnik odgovori na vse zahteve s »standard«, je to povod za dodatno vprašanje, ne za zaupanje.

Pogoste napake pri pisanju zahtev

• Seznam funkcij namesto opisa potreb. »Mora imeti modul za skladišče« ne pove ničesar; »v skladišču moramo slediti serijam in rokom uporabnosti pri prevzemu in odpremi« pove vse.
• Vse je obvezno. Če je vsaka zahteva ključna, nobena ni, ponudniki pa ne vedo, kje lahko prilagodijo rešitev.
• Prepisovanje tujih predlog brez prilagoditve. Predloge, narejene za druge trge, ne poznajo slovenskih e-računov, davčnega potrjevanja ali lokalnih poročil.
• Pozabljene izjeme. Zahteve opisujejo običajni potek, izjeme pa povzročijo večino težav po zagonu.
• Brez lastnika. Če dokumenta ne vodi ena oseba, se vsak oddelek zanese na drugega.
• Zahteve brez meril ocenjevanja. Brez točkovanja se odločitev sprejme po občutku, ne po dokumentu.

Kako zahteve vplivajo na izbiro programa

Dobre zahteve ne pokažejo samo ponudnika, ampak tudi vrsto rešitve. Podjetje s proizvodnjo po naročilu in zahtevnimi kosovnicami bo imelo drugačne zahteve kot trgovsko podjetje s hitrim obračanjem zalog. Med programi, s katerimi se najpogosteje srečujejo slovenska podjetja, je več pristopov:

• Odoo je modularen sistem, ki ga lahko postopoma razširjate in prilagajate; zahteve naj zato jasno ločijo, kaj mora biti v prvi fazi.
• PANTHEON je domača rešitev z močno lokalno prepoznavnostjo; v zahtevah ponudnika vprašajte, kako pokriva vaše posebnosti in povezave.
• Microsoft Dynamics 365 Business Central, SAP Business One in Oracle NetSuite so mednarodne rešitve, pri katerih morate posebej preveriti slovensko lokalizacijo in način zagotavljanja zakonskih zahtev.

Namen dokumenta ni izbrati program namesto vas, ampak ponudnikom omogočiti, da pokažejo, kako njihov program pokrije vaše potrebe. Če dvomite, ali zahteve odgovarjajo velikosti podjetja, se posvetujte z neodvisnim strokovnjakom; naš brezplačni postopek povezovanja z integratorjem je zasnovan prav za to.

Popoln vzorec za prepis

Spodnji vzorec lahko prekopirate in prilagodite. Besedila v oglatih oklepajih zamenjajte z lastnimi podatki, nepotrebna poglavja pa izbrišite.

Naslovnica in povzetek

• Naslov dokumenta: Zahteve za uvedbo sistema ERP
• Naročnik: [ime podjetja]
• Kontaktna oseba za razpis: [ime in vloga]
• Rok za vprašanja ponudnikov: [datum]
• Rok za oddajo ponudbe: [datum]
• Oblika oddaje: [elektronsko, po e-pošti ali prek portala]
• Zaupnost: vsebina dokumenta je poslovna skrivnost naročnika in se uporablja samo za pripravo ponudbe.

Poglavje A: predstavitev naročnika

• Dejavnost in glavni izdelki ali storitve: [opis]
• Pravna oblika in struktura skupine: [opis]
• Lokacije (sedež, enote, skladišča, proizvodnja): [seznam]
• Trgi in jeziki poslovanja: [Slovenija, drugi trgi]
• Valute in davčni režimi: [EUR, druge valute, DDV po državah]
• Razred velikosti: [majhno, srednje, večje] in predvideni uporabniki: [razpon]

Poglavje B: cilji in obseg

• Poslovni cilji projekta: [seznam v obliki »želimo …, da bi …«]
• Merila uspeha po zagonu: [opis]
• Vključeni procesi in organizacijske enote: [seznam]
• Izključeno iz prve faze: [seznam]
• Predvidene poznejše faze: [seznam]
• Omejitve (sezonska obdobja, zakonski roki, razpoložljivost ljudi): [opis]

Poglavje C: poslovni procesi

Za vsak proces izpolnite naslednjo tabelo.

Poglavje Č: funkcionalne zahteve po modulih

Pri vsaki zahtevi označite pomembnost (obvezno, zaželeno, po izbiri); ponudnik izpolni stolpec odgovora (standard, nastavitev, dodatek, razvoj, ni mogoče) in opombo.

Finance in računovodstvo

• Glavna knjiga, slovenski kontni načrt in več poslovnih enot ali podjetij
• Terjatve in obveznosti, odprte postavke, opomini in pobotanje
• Obračun DDV, evidence in izmenjava podatkov, potrebna za eDavke
• Osnovna sredstva in amortizacija
• Večvalutno poslovanje in tečajne razlike
• Bančni izpiski, plačilni nalogi in uskladitev
• Stroškovna mesta, projekti in analitika
• Zaključek obdobja, revizijska sled in poročila za vodstvo

Prodaja in odnosi s strankami

• Ponudbe, naročila, pogodbe in cenik s popusti
• Dobavnice, računi in dobropisi
• Izdajanje e-računov in pošiljanje prek izbranega kanala
• Davčno potrjevanje računov pri gotovinski prodaji, če je potrebno
• Evidenca strank, kontaktov in zgodovine komunikacije
• Provizije in obračun prodajnih zastopnikov

Nabava

• Zahtevki, naročilnice in odobritve po vlogah
• Prevzem blaga in primerjava z naročilom in računom
• Prejem in obdelava e-računov dobaviteljev
• Ocenjevanje dobaviteljev

Zaloge in skladišče

• Več skladišč in lokacij
• Sledljivost po serijah in rokih uporabnosti
• Inventura, premiki in popisi
• Povezava s čitalniki črtne kode
• Minimalne zaloge in samodejna predlagana naročila

Proizvodnja (če je relevantno)

• Kosovnice in tehnološki postopki
• Delovni nalogi in beleženje porabe
• Kapacitete, planiranje in razporejanje
• Izračun lastne cene
• Kontrola kakovosti in sledljivost

Storitve in projekti (če je relevantno)

• Beleženje ur in stroškov po projektih
• Obračun po opravljenem delu ali po mejnikih
• Spremljanje donosnosti projekta

Kadri in plače (če je v obsegu)

• Evidenca zaposlenih in delovnega časa
• Obračun plač v skladu s slovenskimi predpisi ali povezava z zunanjim obračunom

Poročanje in analitika

• Standardna poročila za vodstvo, finance in prodajo
• Prilagodljive nadzorne plošče
• Izvoz podatkov v običajne formate

Poglavje D: tehnične zahteve

Poglavje E: zakonske in davčne zahteve

• Podpora za e-račune (izdajanje, prejemanje, formati) in način posodobitev ob spremembah predpisov
• Davčno potrjevanje računov in povezava s FURS, če podjetje posluje z gotovino ali kartičnimi plačili
• Obračun DDV, posebni režimi in poročanje
• Hramba dokumentov in sledljivost sprememb
• Način zagotavljanja zakonskih posodobitev: kdo jih izvede, kdaj in ali so vključene v vzdrževanje
• Izmenjava podatkov z zunanjim računovodjo ali revizorjem

Poglavje F: prenos podatkov

Ponudnik naj opiše pristop k čiščenju, preslikavi in preizkusnemu prenosu ter vlogo naročnika pri prevzemu.

Poglavje G: načrt uvedbe

• Predlagani pristop (hkraten preklop ali po fazah): [opis]
• Obdobja, ki niso primerna za preklop: [npr. zaključek poslovnega leta]
• Vloge na strani naročnika: [vodja projekta, ključni uporabniki]
• Razpoložljivost naročnikovih ljudi: [opis]
• Pričakovanja glede analize, nastavitve, preizkušanja in sprejema
• Šolanje: kdo, kdaj in v kakšni obliki
• Podpora po zagonu in vzdrževanje: odzivni časi, kanali, jezik podpore
• Upravljanje sprememb in komunikacija z zaposlenimi

Poglavje H: proračun in oblika ponudbe

• Proračunski okvir ali način financiranja: [opis ali »na željo ponudnika«]
• Zahtevana razčlenitev stroškov: licence ali naročnina, uvedba, prilagoditve, prenos podatkov, šolanje, vzdrževanje
• Zahtevana ocena skupnih stroškov lastništva za daljše obdobje
• Pogoji plačila in vezava na mejnike
• Predpostavke, na katerih temelji ponudba
• Veljavnost ponudbe: [obdobje]

Poglavje I: zahteve do ponudnika

• Kratka predstavitev ponudnika in organizacija projektne skupine
• Izkušnje v naši panogi in v slovenskih razmerah (brez navajanja zaupnih podatkov drugih strank)
• Referenčni pogovor z dvema ali več strankami, ki jih ponudnik predlaga
• Odgovornost ponudnika za podizvajalce
• Pogoji za izhod: izvoz podatkov in prehod na drug sistem

Poglavje J: merila izbire

Poglavje K: postopek in pravila

• Predstavitev rešitve na podlagi izbranih scenarijev iz poglavja C
• Dostop do preizkusnega okolja za ocenjevalce
• Izbor ožjega kroga ponudnikov in pogajanja
• Pridržek, da naročnik ni zavezan k izbiri nobene ponudbe
• Zaupnost informacij na obeh straneh

Kako preveriti dokument, preden ga pošljete

Pred pošiljanjem dokument preberite z očmi ponudnika. Ali razume, kaj prodajate in komu? Ali iz poglavja o procesih razume, kje so izjeme? Ali so obvezne zahteve zares obvezne? Ali je razvidno, kako boste ocenjevali? Priporočljivo je, da dokument prebere tudi nekdo, ki ni sodeloval pri pisanju, na primer računovodja iz zunanjega servisa, saj hitro opazi nejasnosti pri zakonskih in davčnih točkah.

Če imate več sto zahtev, jih ne črtajte vse brez premisleka. Raje jih razvrstite v obvezne in zaželene ter obvezne omejite na tiste, brez katerih poslovanje ni mogoče. Manj, a bolj jasnih obveznih zahtev vodi do boljših ponudb.

Naslednji korak

Ko imate osnutek, ga pošljite vsaj dvema ali trem ponudnikom ali integratorjem in primerjajte odgovore po isti tabeli. Če ne veste, komu ga poslati, ali če v regiji, kjer posluje vaše podjetje, ne poznate pravih naslovov, vam lahko pomagamo: oddajte kratko povpraševanje in povezali vas bomo z integratorjem, ki ustreza vaši dejavnosti in velikosti. Pogovor je brezplačen, zahteve pa ostanejo vaše in jih lahko uporabite pri kateremkoli ponudniku.

Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.