Kako izabrati ERP za narednih 10 godina
Spisak modula opisuje ono što sistem radi danas; deceniju određuje pet odluka koje se donose prvog dana i posle se ne mogu retrofitovati — a proveravaju se iz terminala, ne sa slajda.
- Objavljeno
- Autor
- Konis Software
Procena ERP-a skoro uvek počne pogrešnim instrumentom: tabelom u kojoj je svaki red funkcionalnost, svaka kolona dobavljač, a svako polje kvačica. Instrument je pogrešan jer meri ono što se lako izjednači. Na dovoljno apstraktnom spisku svaki ozbiljan sistem ima svaku kvačicu — vodi zalihe, obračunava PDV, radi sa kupcima — pa se izbor svede na cenu i na utisak sa demoa. Ni jedno ni drugo ne predviđa narednih deset godina.
Deceniju određuje ono čega na spisku nema. Modul koji će firmi zatrebati u trećoj godini — nova evidencija koju uvede zakon, dimenzija troška koju traži novi vlasnik, integracija sa sistemom koji još ne postoji — danas se ne može zakvačiti jer još nije osmišljen. Da li će taj modul moći da se doda bez preseljenja podataka i bez prepisivanja jezgra određuje arhitektura ispod svih kvačica. Nju spisak ne prikazuje, a demo je krije.
Teza ovog teksta je jednostavna: ne kupuje se spisak modula, kupuje se arhitektura. Modul se dodaje kad zatreba; pet arhitektonskih odluka donosi se prvog dana i posle se ne mogu retrofitovati bez migracije, prepisivanja ili tihe laži da je urađeno. Tih pet — otvoren API ispod svakog ekrana, prilagođavanje van jezgra, izolacija u bazi, poreklo kao deo zapisa i pravila sa intervalom važenja — mogu se proveriti, ali ne sa slajda. Proveravaju se iz terminala, iz šeme baze i iz jednog nezgodnog pitanja dobavljaču.
Modul se dodaje, arhitektura se nasleđuje
Na spisku funkcionalnosti svako polje teži potvrdi. Svaki dobavljač će potvrditi da ima API, da se prilagođava, da je bezbedan, da koristi veštačku inteligenciju. Reči su iste; ono što stoji iza njih razlikuje se za red veličine, i ta razlika se ne vidi dok je ne iznudite. Kroz svaku stavku procene vredi povući jednu granicu: da li je to nešto što se dodaje (još jedan izveštaj, još jedno polje, još jedan modul) ili nešto što se nasleđuje od prvog dana (oblik zapisa, mesto izolacije, način na koji se sistem proširuje). Prvo se kupuje kad zatreba. Drugo se ili ima na početku ili se plaća kroz migraciju kad bude prekasno.
Pet odluka koje se ne mogu retrofitovati
Sintagma da se nešto ne može retrofitovati nije fraza za utisak. Znači da dodavanje kasnije zahteva jedno od tri: preseljenje svih postojećih podataka u novi oblik, prepisivanje jezgra koje su ostali klijenti već primili, ili odluku da se ne uradi i da se rupa prekrije ručnim radom. Sledećih pet odluka su noseći zidovi, a ne boja na zidu. Za svaku je dat i način da se proveri koji dobavljač ne može da odglumi.
1. API-first: ekran je samo jedan klijent
API-first ne znači tek to da API postoji. Znači da je svaka radnja u sistemu prvo dostupna kroz dokumentovan interfejs, a ekran je samo jedan njegov klijent — isti put kojim ide integracija, automatizacija i budući modul koji još ne postoji. Kad je API naknadna dogradnja, pokriva deo površine, zaobilazi poslovna pravila koja žive u ekranu i zaostaje za svakom novom funkcijom. Deceniju integracija — sa bankom, sa SEF-om, sa e-trgovinom, sa sistemom kupca koji tek dolazi — nosi baš ta granica. Ako ekran ume nešto što API ne ume, za deset godina ćete to raditi rukama.
2. Clean core: prilagođavanje bez grananja jezgra
Svaka firma traži nešto svoje — polje, pravilo, izveštaj, tok odobravanja. Pitanje nije da li sistem to može, nego gde to prilagođavanje živi. Kod clean core pristupa ekstenzije stoje van jezgra, na predviđenim tačkama proširenja, a jezgro ostaje isto za sve klijente i prima nadogradnje bez bola. Kad se prilagođavanje radi grananjem — izmenom jezgra ili dodavanjem kolone u sistemsku tabelu — dobijate privatnu verziju koja se sa svakom sledećom zakrpom dobavljača mora ručno spajati. To spajanje plaćate zauvek, a nadogradnje kasnite ili preskačete. Firma koja je najviše prilagođavala tako završi na najstarijoj verziji.
3. Izolacija u bazi (RLS), ne u aplikaciji
U multitenant sistemu podaci više klijenata dele istu bazu, pa je pitanje gde se izvršava granica između njih. Ako granicu čuva aplikacija — obećanjem da svaki upit nosi uslov po tenantu — onda jedan zaboravljen uslov u jednom upitu procuri tuđe podatke, i to se otkrije tek kad je kasno. Izolacija na nivou baze (row-level security) pomera granicu tamo gde je aplikacija ne može zaobići: baza vraća samo redove tenanta čiji je kontekst postavljen, i ništa van njega. To je odluka o šemi i o politikama nad tabelama; ne dograđuje se kasnije bez dodira u svaki upit koji je ikada napisan. Ista mehanika povlači i drugu granicu koju kupci retko pitaju — ko sa strane dobavljača vidi vaše podatke i koji trag ostaje kad ih pogleda.
4. AI-native jezgro: poreklo i nacrt su polja, ne dugme
AI-native se najlakše lažira, jer se svodi na dugme ili bočni chat zakačen sa strane. Prava razlika je u tome da li jezgro zna sopstveno poreklo. Svaki zapis nosi podatak ko ga je napravio — čovek, deterministično pravilo ili prihvaćen predlog — upisan pri nastanku i nepromenljiv. Ono što nosi veštačka inteligencija je nacrt koji čovek potvrđuje, a ne stavka koja se proknjiži sama. Bez tog polja i bez tog stanja nacrta, automatizacija se ne može ni izmeriti ni revidirati, a AI koji knjiži bez potvrde je rizik koji se otkrije na reviziji. Poreklo i nacrt su odluke o modelu podataka; dodati ih posle znači ponovo obeležiti sve što je već uneto — što niko ne uradi, pa se umesto toga izmisli.
5. Vremenski važeća pravila: parametar ima interval važenja
Zakonski parametri se menjaju — stopa PDV-a, osnovice doprinosa, minimalna cena rada. Pitanje je da li parametar u sistemu ima interval važenja ili je jedna tekuća vrednost u šifarniku koja se pri promeni prepiše. Ako se prepiše, prošlost je izgubljena: dokument iz zatvorenog perioda posle promene više ne može da dokaže koju je stopu nosio, a backdated knjiženje dobija današnju vrednost umesto tadašnje. Stopa PDV-a u Srbiji bila je 18% od 2005, pa 20% od oktobra 2012 — to su javne činjenice, i sistem mora da zna koja je važila na koji datum, ne samo koja važi danas. Verzionisan parametar sa opsegom važenja i referenca verzije zamrznuta na stavci ne dograđuju se kasnije; ugrađuju se pre prve knjižene stavke.
Kako to proveriti iz terminala, a ne sa slajda
Svih pet odluka ima proveru koju slajd ne može da odglumi, jer ne traži tvrdnju nego artefakt: odziv API-ja, red u šemi, ponašanje baze, dokument iz prošlog perioda. Provera se ne izvodi na dobavljačevom srećnom putu, nego na vašem neugodnom slučaju, i traje koliko i jedan poziv ili jedno pitanje na koje odgovor ne sme da bude prezentacija.
| Odluka | Provera koja se ne odglumi na slajdu | Crvena zastavica |
|---|---|---|
| API-first | Reprodukuj iz terminala ono što ekran radi klikom: napravi dokument, proknjiži ga i pročitaj ga nazad — bez ekrana. | API pokriva deo površine, zove privatne rute do kojih integracija ne dopire, ili je zaseban proizvod. |
| Clean core | Uporedi jezgro dva klijenta — mora biti identično; razlika sme da živi samo u ekstenziji i konfiguraciji. | Obećanje da će vam sistem prilagoditi znači privatnu granu; svaka sledeća zakrpa je spajanje koje plaćate i nadogradnja koju odlažete. |
| Izolacija (RLS) | Poveži se ulogom aplikacije bez konteksta tenanta i pokušaj upit — mora vratiti nula redova. | Filter po tenantu živi u upitima aplikacije, a ne u bazi; ili je jedini odgovor da svako dobija svoju bazu. |
| AI-native jezgro | Pogledaj šemu: postoji li polje porekla na stavci i može li se zapis koji je napravilo pravilo odvojiti od onog koji je napravio čovek. | AI je bočni chat bez veze sa zapisom; predlog se knjiži bez stanja nacrta; polja porekla nema. |
| Vremenski važeća pravila | Promeni datum važenja stope i ponovo otvori stari dokument — mora prikazati stopu koja je tada važila. | Stopa je jedna tekuća vrednost prepisana pri promeni; backdated dokument dobija današnju stopu. |
Spisak modula opisuje ono što sistem radi danas; arhitektura opisuje šta će moći kad se pravila promene. Prvo se proverava na demou, drugo iz terminala — i samo drugo traje deceniju.
Pitanja za dobavljača
Dobra pitanja ne traže uveravanje nego artefakt: ne pitanje da li postoji API, nego zahtev da se pošalje specifikacija. Odgovor koji stigne kao slajd je sam po sebi nalaz. Sledeća pitanja pokrivaju pet odluka i još dve granice koje se retko pitaju a deceniju koštaju — vlasništvo nad podacima i pristup dobavljača:
- Pošaljite specifikaciju API-ja. Koji udeo radnji iz ekrana mogu da izvedem bez ekrana?
- Kad izađe vaša sledeća verzija, šta se dešava sa poljima i pravilima dodatim za nas? Pokažite nadogradnju klijenta koji je prilagođavao sistem.
- Gde se izvršava izolacija između klijenata — u bazi ili u upitima aplikacije? Pokažite politiku, ne dijagram.
- Nosi li stavka podatak ko ju je napravio — čovek ili pravilo — upisan pri nastanku i nepromenljiv?
- Da li se predlog koji nosi AI knjiži sam, ili je nacrt koji čovek potvrđuje?
- Kad se stopa PDV-a promeni, kako iz sistema dokažem koja je stopa primenjena na dokument iz zatvorenog perioda?
- Kako da izvezem sve svoje podatke bez vaše asistencije — koji format i koji interfejs? Šta ostaje kod vas kad odem?
- Ko sa vaše strane može da vidi moje podatke, pod kojim uslovom, i koji trag ostaje kad ih pogleda?
Kako NG One pristupa ovome
NG One je građen oko tih pet odluka kao oko nosećih zidova, jer su to odluke koje sam ne bi mogao da doda kasnije. Ispod svakog ekrana stoji dokumentovan API kojim ide i integracija i automatizacija; prilagođavanja žive van jezgra, pa jezgro ostaje isto za sve i prima nadogradnje; izolacija između klijenata izvršava se u bazi kroz row-level security, ista mehanika koja povlači i granicu prema platformskom osoblju; poreklo je polje na zapisu — ručno, pravilo ili prihvaćen nacrt — a ono što nosi veštačka inteligencija ostaje predlog dok ga čovek ne potvrdi; zakonski parametri imaju interval važenja, a referenca verzije se zamrzava na knjiženoj stavci. Svaka od tih tvrdnji ima parnjak u kodu, u migraciji ili u API-ju — ne u slajdu — jer je to isti test koji ovaj tekst traži od svakog dobavljača.