Implementacija Business Central u Srbiji: plan

Kada finansijski direktor pretražuje „implementacija Business Central Srbija“, obično ne traži samo novi softver. Traži način da zatvori mesec bez paralelnih Excel tabela, da odobrenja ne ostaju u sandučetu, da projekti i nabavke imaju isti izvor podataka i da svaka promena u sistemu ne postane višenedeljni razvojni zahtev.

Microsoft Dynamics 365 Business Central može da poveže finansije, prodaju, nabavku, projekte, osnovna sredstva i izveštavanje u jednom cloud sistemu. Međutim, uspeh implementacije ne određuje broj uključenih modula. Određuju ga jasne odluke o procesima, kvalitet podataka, realan obim prilagođavanja i disciplina u testiranju. AI može značajno ubrzati ovaj posao, ali ne može zameniti odgovornost ljudi koji poznaju poslovanje i proveravaju svaku promenu.

Implementacija Business Central u Srbiji počinje procesima

Najskuplja greška je pokušaj da se u novi ERP preseli svaka navika iz starog sistema. Pre početka konfiguracije, tim treba da razdvoji proces koji je zaista potreban od koraka koji postoji samo zato što je prethodno rešenje bilo ograničeno.

Dobar početni radni sastanak ne pita samo: „Koje funkcije želite?“ Preciznija pitanja su: ko kreira zahtev za nabavku, ko ga odobrava, kada nastaje obaveza, ko knjiži ulazni račun, na koji način se račun povezuje sa narudžbenicom i projektom, i koji dokument finansijski direktor želi da vidi pre plaćanja. Ista logika važi za prodaju: od ponude i porudžbenice, preko otpremnice i fakture, do naplate i analize marže.

Za kompanije u Srbiji, procesi moraju obuhvatiti i zakonske tokove. To uključuje izlazne i ulazne SEF fakture, PDV evidencije i POPDV, kursne liste NBS, kao i fiskalizaciju kada je ona deo poslovnog modela. Lokalizacija nije dodatak koji se ostavlja za poslednju nedelju. Ona je uslov da finansije od prvog dana mogu da rade u sistemu.

Plan od pet do osam nedelja, bez lažnih obećanja

Tipičan go-live može biti realan za pet do osam nedelja kada kompanija ima definisan obim, dostupne ključne korisnike i razumno uređene početne podatke. Taj rok nije univerzalan. Proizvodna firma sa složenim planiranjem, mnogo skladišta i velikim brojem integracija ima drugačiji projekat od uslužne organizacije koja uvodi finansije, projekte i odobrenja.

Prva faza je snimanje procesa i potvrda obima. Tada se odlučuje šta ide u standardnu konfiguraciju, šta zahteva prilagođavanje, a šta može da sačeka narednu fazu. Ova odluka štiti budžet bolje od bilo kakve kasnije kontrole troškova.

Sledi konfiguracija osnovnih podataka i finansijske strukture: kontni plan, grupe knjiženja, dimenzije, korisnici, dozvole, bankovni računi, kupci, dobavljači i artikli. Dimenzije zaslužuju posebnu pažnju. Ako se profitni centar, projekat, donator, sektor ili lokacija dosledno postave na dokumentima, izveštavanje postaje pitanje nekoliko klikova, a ne ručnog sabiranja podataka iz više izvora.

Treća faza obuhvata migraciju, testiranje i obuku. Ne prenosi se sve automatski. Otvorene stavke kupaca i dobavljača, početna stanja glavne knjige, osnovna sredstva, artikli i zalihe obično imaju prioritet. Istorijski podaci mogu ostati dostupni u prethodnom sistemu ili se preneti selektivno, u zavisnosti od potreba revizije i operativnog izveštavanja.

Gde AI zaista ubrzava prilagođavanja

Standardni Business Central pokriva veliki deo tipičnih finansijskih i operativnih potreba. Razlika nastaje kada kompanija želi poseban obrazac odobravanja, dodatnu proveru pre knjiženja, automatsko povezivanje dokumenata, prilagođeni izveštaj ili integraciju sa drugim sistemom.

U tradicionalnom modelu korisnik opisuje potrebu konsultantu, konsultant je prevodi u specifikaciju, programer piše AL kod, a zatim se čeka testiranje. Problem nije u tome što je ovaj postupak pogrešan, već što između poslovnog zahteva i funkcionalnog rešenja često nastaje mnogo administrativnog vremena.

AI-asistirani razvoj skraćuje taj put. Korisnik može opisati zahtev jednostavnim jezikom: „Kada ulazni račun prelazi 300.000 dinara, zahtevam odobrenje finansijskog direktora pre knjiženja. Trošak mora biti označen projektom, a dokument sa nedostajućim prilogom ne sme da prođe.“ AI može analizirati zahtev, predložiti poslovna pravila, pripremiti AL kod i postaviti promenu u testno okruženje.

To ne znači da se kod automatski šalje u produkciju. Ispravan model uključuje pregled konsultanta i programera, testne scenarije, proveru dozvola i potvrdu vlasnika procesa. HOLYERP taj princip primenjuje kroz HOLY BC Agent: AI ubrzava analizu i razvoj, dok iskusni konsultanti validiraju svaku promenu pre produkcije.

Najveća korist nije samo u bržem pisanju koda. Ona je u kraćem ciklusu učenja. Poslovni korisnik vidi predlog u testnom okruženju, proverava ga na stvarnom primeru i daje konkretnu povratnu informaciju. Tako se smanjuje rizik da se nedeljama razvija funkcija koja je pogrešno shvaćena na prvom sastanku.

Kontrola kvaliteta nije suprotnost brzini

AI može brzo generisati nacrt rešenja, ali ne poznaje sam po sebi specifične računovodstvene politike, ugovorne obaveze ili interne kontrole kompanije. Zato kvalitetan projekat zahteva jasnu podelu odgovornosti.

Poslovni vlasnik potvrđuje da proces odgovara stvarnom radu. Finansijski tim proverava knjiženja, PDV tretman, obavezne dimenzije i dokumentaciju. IT ili administrator proverava dozvole, integracije i upravljanje okruženjima. Konsultant proverava da promena prati standardnu arhitekturu Business Central-a i da neće stvoriti problem pri budućim ažuriranjima.

Posebno su važni testni slučajevi koji uključuju izuzetke. Nije dovoljno proveriti da li standardna faktura prolazi. Treba testirati avans, storno, delimičnu isporuku, devizni račun, nedostajuću dimenziju, pogrešnog odobravaoca, dupliran dokument i neuspešan prenos e-fakture. Upravo na ovim situacijama se vidi da li je proces zaista spreman za rad.

Kako izgleda tok e-fakture u operativnom radu

Kod izlazne fakture, korisnik kreira dokument iz prodajne porudžbenice ili usluge, sistem proverava obavezna polja i knjiženja, a zatim se dokument šalje na SEF. Status prihvatanja ili odbijanja mora biti vidljiv uz dokument, zajedno sa istorijom poruka i eventualnim razlogom odbijanja. Finansije tako imaju trag od poslovnog događaja do zakonske razmene.

Kod ulazne fakture, dokument se preuzima ili evidentira, povezuje sa dobavljačem, narudžbenicom, prijemom robe ili projektom, a zatim ide na odobrenje prema vrednosti, organizacionoj jedinici ili vrsti troška. Tek nakon potvrde i provere, račun se knjiži i postaje raspoloživ za plaćanje. Evidencija odobrenja nije formalnost - ona pokazuje ko je doneo odluku, kada i na osnovu kog dokumenta.

Ovaj tok ima smisla i za manje kompanije. Pravila mogu biti jednostavnija, ali nedostatak kontrole ne postaje prihvatljiv samo zato što je broj računa manji. Razlika je u tome što manjoj organizaciji često nije potreban složen razvoj, već dobro podešena standardna funkcionalnost.

Šta treba odlučiti pre potpisivanja projekta

Pre početka implementacije, rukovodstvo treba da odredi ko donosi odluke kada se zahtevi sukobe, ko potvrđuje podatke za migraciju i koliko vremena ključni korisnici mogu realno da izdvoje. ERP projekat ne može uspešno voditi samo IT sektor, jer su najvažnije odluke vezane za finansije, prodaju, nabavku i operativni rad.

Takođe treba definisati granicu između prve faze i budućih poboljšanja. Ako svaki dobar predlog postane obavezan pre go-live datuma, rok se neizbežno pomera. Bolji pristup je da prva faza pokrije kritične tokove: knjiženje, fakturisanje, nabavku, odobrenja, zakonske obaveze i osnovno izveštavanje. Nakon stabilizacije, AI-asistirana prilagođavanja mogu brže uvoditi dodatne automatizacije.

Najkorisniji sledeći korak nije duga lista želja. Izaberite jedan proces koji danas najviše usporava finansije ili operacije, opišite ga jasnim jezikom i tražite da ga vidite u testnom okruženju. Kvalitet implementacije se najbolje procenjuje po tome koliko brzo stvaran problem postaje proverljivo rešenje.