Večina projektov Business Central, ki se zataknejo, se ne zatakne zaradi programa. Zataknejo se zaradi nejasnega obsega, slabo očiščenih podatkov, preveč prilagoditev ali zato, ker se je izkušena ekipa iz projekta umaknila. Audit Business Central je strukturiran pregled, ki te vzroke loči od simptomov in vam da podlago za odločitev: popraviti, prevzeti z drugim partnerjem ali pogumno začeti znova na posameznih področjih.
Ta stran je namenjena direktorjem, finančnim vodjem in vodjem IT v slovenskih malih in srednjih podjetjih, ki so že v projektu ali že delajo v sistemu, pa jim ne ustreza. Če uvedbo šele načrtujete, začnite pri strani o uvedbi Business Central.
Znaki, da je audit nujen
Nobeden od spodnjih znakov sam po sebi ne pomeni propada, skupaj pa kažejo, da projekt ne drži smeri:
- Mejniki se pomikajo, nihče pa ne zna pojasniti, kaj točno še manjka.
- Računovodja zaklepa mesec z ročnimi popravki, izvozi v Excel pa so postali redna praksa.
- Poročila se ne ujemajo z glavno knjigo ali z zalogo, vsak oddelek pa ima svojo »resnico«.
- Obračun DDV in priprava podatkov za eDavke zahtevata vsakič dodatno delo, čeprav bi moral sistem to podpirati.
- Uporabniki ne zaupajo sistemu in vzporedno vodijo lastne preglednice.
- Vsaka sprememba je dolgotrajna in draga, ker se nihče več ne spomni, zakaj je nekaj nastavljeno tako, kot je.
- Po posodobitvi nekaj preneha delovati, integratorja pa je težko dobiti na telefon.
- Računi se kopičijo, odgovorov ni. Ponudba je bila za uvedbo, v resnici pa plačujete nenehno »dodelavo«.
Če prepoznate več kot dva, je audit cenejši od nadaljnjega čakanja.
Kaj se pregleda pri auditu Business Central
Dober audit ni seznam vtisov. Je pregled po področjih, pri vsakem pa so jasna vprašanja in dokazi.
| Področje | Kaj se preveri | Tipična ugotovitev |
|---|---|---|
| Konfiguracija | Kontni načrt, knjižbene skupine, dimenzije, številčna zaporedja, vloge in dovoljenja | Nastavitve, prenesene iz starega sistema brez premisleka, podvojene dimenzije |
| Podatki | Šifranti kupcev, dobaviteljev, artiklov, odprte postavke, začetna stanja | Podvojeni partnerji, neusklajena začetna stanja, neuporabljeni artikli |
| Prilagoditve | Razširitve, sprememba standardnih postopkov, izvorna koda, odvisnosti | Posegi tam, kjer bi zadostila standardna funkcija; koda brez dokumentacije |
| Integracije | Povezave z banko, spletno trgovino, prodajnimi in skladiščnimi sistemi | Ročni uvozi, ki bi jih morala opraviti povezava; krhke povezave brez nadzora napak |
| Delovanje | Hitrost poročil in knjiženja, tehtani postopki, planirane naloge | Težki izpisi ob koncu meseca, nepotrebni filtri, neučinkovite razširitve |
| Varnost | Dodeljevanje vlog, ločevanje nalog, skrbniški dostopi, zunanji uporabniki | Preveč uporabnikov z vsemi pravicami, računi nekdanjih sodelavcev |
| Različica | Različica, prehodi na nove izdaje, združljivost razširitev | Razširitve, ki ovirajo posodobitev, zaostanek za izdajami |
| Slovenska zakonodaja | Podpora za DDV, e-račune, davčno potrjevanje računov (FURS), poročanje | Ročni obvozi, ker lokalizacija ni bila ustrezno izbrana ali nastavljena |
Konfiguracija in podatki
Večina težav, ki jih uporabniki pripišejo »počasnemu sistemu«, izvira iz konfiguracije in podatkov. Revizor preveri, ali je struktura glavne knjige skladna z načinom, kako podjetje dejansko spremlja stroške in prihodke, ali dimenzije res služijo analitiki in ali so začetna stanja ob prehodu uskladljiva s prejšnjim sistemom. Pomembno je tudi, ali je bila selitev podatkov dokumentirana tako, da jo je mogoče ponoviti ali pojasniti revizorju.
Prilagoditve in razširitve
Business Central je zasnovan tako, da se spremembe izvajajo kot razširitve, ne pa s posegi v osnovno kodo. Pri auditu preverite, kaj je bilo narejeno, zakaj in ali bi isto dosegli s standardom. Sledijo vprašanja o prilagoditvah in razvoju: kdo ima izvorno kodo, kje je shranjena, ali obstaja zgodovina sprememb in ali so razširitve preizkušene z novimi izdajami. Prilagoditev, ki je ne zna vzdrževati nihče razen avtorja, je tveganje, ne vrednost.
Slovenska lokalizacija
Pri slovenskem podjetju je posebej pomembno vprašanje lokalizacije. Microsoft sam dobavlja lokalizacijo za izbrane države, drugje pa Business Central deluje z lokalizacijskimi aplikacijami, ki jih razvijajo partnerji in so dostopne prek Marketplace; v državi je lahko več takšnih rešitev, ena rešitev pa lahko obsega več aplikacij. Audit zato ugotovi, katera lokalizacija je v vašem okolju nameščena, kdo jo vzdržuje in ali je usklajena z vašo različico. Več o razmerah pri nas piše stran Business Central v Sloveniji, o zahtevah za račune in DDV pa vodnik o e-računih in DDV-obračunih.
Različica in posodobitve
Spletni Business Central prejema dve večji posodobitvi na leto, aprila in oktobra, med njima pa mesečne manjše, ki vsebujejo tudi kritične popravke in regulativne spremembe. Če razširitve niso pripravljene na novo izdajo, posodobitev zastane ali povzroči napake, podjetje pa nenehno zaostaja. Audit zato obvezno vključi pregled različic in izdaj ter preveri, ali se razširitve preizkušajo v peskovniku, preden nova izdaja pride v produkcijo.
Reševanje projekta: popraviti, prevzeti ali zamenjati
Rezultat dobrega audita ni ocena »dobro« ali »slabo«, ampak razvrstitev ugotovitev po resnosti in po tem, kdo jih lahko odpravi. Običajno se pokažejo tri poti.
- Popravki z istim partnerjem. Smiselno, kadar je težava v obsegu, komunikaciji ali nekaj slabih nastavitvah, ekipa pa je kompetentna in pripravljena sodelovati.
- Prevzem projekta z novim partnerjem. Smiselno, kadar je zaupanja zmanjkalo, kadar so ključni ljudje odšli ali kadar partner nima znanja za vaše področje (proizvodnja, trgovina, storitve).
- Ponovna uvedba posameznih modulov. Smiselno, kadar je določeno področje, na primer skladišče ali proizvodnja, zasnovano tako, da ga ni mogoče pametno popraviti.
Ponovni začetek celotnega projekta je redko potreben. Veliko pogosteje je dovolj, da se obdrži osnova (podjetje, kontni načrt, šifranti) in se zamenjajo najšibkejši deli.
Menjava integratorja Business Central brez ponovnega začetka
Menjava je mogoča, ker je Business Central standardna platforma: znanje o njej ni zaklenjeno pri enem izvajalcu. Pri menjavi sta dva ločena vprašanja: tehnično (kje so podatki, koda, dokumentacija) in pogodbeno (licence, podpora, odgovornost).
Licence za spletni Business Central se po Microsoftovi dokumentaciji kupujejo prek programa Cloud Solution Provider, torej prek partnerja. Zato menjava partnerja običajno pomeni tudi prenos naročnine in skrbniških pravic. Preden o tem govorite z dosedanjim izvajalcem, preverite v svojem Microsoftovem najemniku, kdo je globalni skrbnik in kateri partner ima delegirane pravice.
Razmislite tudi, kako je urejena podpora. Prvo linijo običajno nudi partner kot delegirani skrbnik najemnika in po potrebi stopnjuje na Microsoft. Če je partner Microsoftu poslal zahtevek v vašem imenu, je potreben ustrezen podporni načrt. Microsoft pa obravnava incidente, ne uporabniških vprašanj in ne popravljanja pokvarjenih podatkov. Ta meja je vredna pogovora z novim partnerjem, zato si oglejte tudi podporo in vzdrževanje.
Dokumenti in dostopi, ki jih je treba pridobiti
| Kaj | Zakaj je pomembno |
|---|---|
| Skrbniške pravice v vašem najemniku | Ne smete biti odvisni od računa izvajalca |
| Dokumentacija konfiguracije in poslovnih pravil | Nova ekipa ne sme ugibati, zakaj je nekaj nastavljeno tako |
| Seznam razširitev, izvorna koda, repozitorij | Brez kode ni vzdrževanja, brez zgodovine ni razumevanja |
| Opis integracij in dostopnih podatkov za povezave | Povezave z banko, spletno trgovino ali skladiščem morajo ostati delujoče |
| Seznam uporabnikov, vlog in dovoljenj | Osnova za varnostni pregled in prerazporeditev licenc |
| Zapisi o preizkusih in sprejemni zapisniki | Dokazujejo, kaj je bilo že potrjeno |
| Odprti zahtevki in znane napake | Ob prevzemu se vidi, kaj je dejansko nedokončano |
| Podatkovni izvozi in predloge uvoza | Za primerjavo začetnih stanj in morebitno ponovno uvozno pot |
Če dosedanji izvajalec dokumentacije nima, to samo po sebi ni razlog za obup: nova ekipa lahko konfiguracijo in razširitve rekonstruira iz samega okolja, a bo za to potrebovala čas in dostop. Dobro je, da to zapišete v pogodbi o prevzemu.
Varnostna kopija in previdnostni ukrepi
Pred vsakim večjim posegom naredite varnostno kopijo in dogovorite preizkusno okolje. Okolje je mogoče obnoviti do desetkrat na koledarski mesec, na katerikoli trenutek v zadnjih osemindvajsetih dneh, v isti regiji Azure, obnova pa je na voljo le s plačljivo naročnino. To je dobra mreža za popravke, ni pa nadomestilo za premišljen postopek. Spremembe najprej preizkusite v peskovniku, šele nato v produkciji.
Načrt sanacije: kako izgleda dober prevzem
Dober načrt ima preprosto zasnovo. Brez številk in brez obljub, ki jih nihče ne more izpolniti:
- Stabilizacija. Najprej se ustavi krvavitev: kritični postopki (knjiženje, izdaja računov, plačila, DDV) morajo delovati zanesljivo, tudi z začasnimi rešitvami.
- Diagnoza. Audit po zgoraj navedenih področjih, rezultat pa je seznam ugotovitev po resnosti, z odgovornimi osebami.
- Dogovor o obsegu. Kaj se popravi zdaj, kaj kasneje in česa ne počnemo. Brez tega se projekt spet razraste.
- Čiščenje podatkov in konfiguracije. Šifranti, odprte postavke, vloge, nepotrebne nastavitve.
- Poenostavitev prilagoditev. Kjer standard zadošča, se razširitev opusti; kjer je potrebna, se dokumentira in preizkusi.
- Preizkus in sprejem. Ključni uporabniki, računovodja in vodja financ potrdijo scenarije, ki so bili prej sporni.
- Usposabljanje in prevzem v redno vzdrževanje. Sistem zaživi, ko ga ljudje razumejo; glejte usposabljanje za Business Central.
Na vsakem koraku naj ima podjetje enega odgovornega naročnika. Brez njega projekt rešuje integrator, ne pa podjetje samo.
Kako izbrati partnerja za prevzem
Prevzem je zahtevnejši od nove uvedbe, ker partner ne odgovarja le za svoje delo, ampak tudi za razumevanje tujega. Ob izbiri bodite pozorni na naslednje:
- Izkušnje s prevzemi, ne le z novimi uvedbami.
- Znanje s področja računovodstva in zakonodaje v Sloveniji, vključno z DDV, e-računi in zahtevami glede davčnega potrjevanja računov pri vaši dejavnosti.
- Certificirani svetovalci in razvijalci. Microsoftov program za partnerje Business Applications med merili upošteva certifikate, med njimi MB-800 za funkcionalnega svetovalca in MB-820 za razvijalca Business Central. Certifikat ni dokaz kakovosti, je pa smiseln minimalni standard.
- Pripravljenost na neodvisen pregled in na jasno razmejitev odgovornosti za obstoječe napake.
- Poznavanje vaše panoge, saj se proizvodnja, trgovina in storitve razlikujejo.
Več meril najdete v članku kako izbrati integratorja Business Central in v splošnem vodiču o izbiri integratorja ERP. Na tipične vzorce neuspehov opozarja tudi vodič o napakah pri ERP projektih.
Kako vam pomagamo mi
Nismo integrator in sami projektov ne izvajamo. Na podlagi opisa vašega stanja vas povežemo z integratorjem, ki ima izkušnje z auditom ali prevzemom projekta Business Central, v skladu z vašo panogo in velikostjo podjetja. Storitev je brezplačna in neodvisna od izbire programske opreme; kako poteka, je opisano na strani kako deluje povezovanje. Če se med auditom izkaže, da Business Central ne ustreza vašim potrebam, tega ne skrivamo: stran o alternativah pokaže, kdaj je smiselno razmisliti o drugi rešitvi.
Opišite težavo, tudi če je še nejasna. Za dober začetek zadostuje: kdaj je bil sistem uveden, kdo ga je uvedel, kaj vas najbolj moti in kaj ste že poskusili.
Pogosta vprašanja
Kdaj je smiselno narediti audit Business Central?
Takrat, ko se uvedba vleče mimo dogovorjenih mejnikov, ko računovodja ročno popravlja knjiženja, ko so poročila nezanesljiva ali ko po posodobitvi nekaj preneha delovati. Audit je smiseln tudi pred menjavo integratorja, saj dobite neodvisno sliko stanja, na kateri lahko gradite pogajanja in načrt popravkov.
Ali lahko zamenjam integratorja Business Central sredi projekta?
Da, in to ni redkost. Licence za spletno različico se kupujejo prek partnerja v programu Cloud Solution Provider, zato menjava pomeni tudi prenos partnerskega odnosa in skrbniških pravic v vašem Microsoftovem najemniku. Podatki, paketi z razširitvami in dokumentacija ostanejo vaši, če so jih pogodbe in dostopi ustrezno urejeni.
Ali moramo po slabem projektu začeti znova?
Običajno ne. Audit loči, kaj je mogoče obdržati (osnovni podatki, razumna konfiguracija, dobri postopki) in kaj je treba popraviti ali zamenjati. Ponovna uvedba pride v poštev šele, ko je zasnova temeljno zgrešena, na primer ko so bile vgrajene prilagoditve, ki posegajo v osnovno logiko, ali ko podatkov ni mogoče več zaupanja vredno očistiti.
Kaj lahko naredi Microsoft, če se projekt zaplete?
Microsoftova podpora obravnava incidente, ne pa vprašanj o uporabi, in ne pomaga pri popravljanju pokvarjenih podatkov. Prvo linijo podpore običajno zagotavlja vaš partner kot delegirani skrbnik najemnika, ki po potrebi stopnjuje na Microsoft. Zato je za reševanje projekta ključen izkušen partner, ne le dostop do Microsofta.
Kaj ob prevzemu projekta zahtevati od dosedanjega integratorja?
Dokumentacijo konfiguracije, seznam razširitev z izvorno kodo in repozitorijem, opis integracij, sezname uporabnikov in vlog, zapise o preizkusih ter pregled odprtih zahtevkov. Zahtevajte tudi skrbniške pravice v svojem najemniku, da nikoli ne ostanete odvisni od enega samega računa.
Viri
- Microsoft Learn – Technical support for Business Central
- Microsoft Learn – Business Central licensing
- Microsoft Learn – Update rollout timeline
- Microsoft Learn – Backup and restore of environments
- Microsoft Learn – About localization
Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.