Od sastavnice do cene koštanja, bez tabele između

Po tome gde stoje temelji. Dimenziono knjiženje ide od prve stavke, pa profitabilnost po nalogu, pogonu, proizvodu i kupcu izlazi iz iste glavne knjige iz koje izlazi bruto bilans — a ne iz naknadnog polja i tabele pored. Pravila su verzionisana, pa nalog nosi verziju sastavnice po kojoj je otvoren i posle godinu dana. Dokumenti imaju statusne mašine sa dozvoljenim prelazima, a odobrenje po limitu radi isti workflow kernel u nabavci i u pogonu. WMS je u jezgru — lokacije, vođeno komisioniranje, talasi — pa poluproizvod ne živi u drugom sistemu od gotovog proizvoda. Modul zakačen sa strane sve to mora da rekonstruiše kroz interfejs, a rekonstrukcija daje brojke kojima se na kraju ne veruje.

Ne. NG Operations je zaseban proizvod porodice Konis za pogonsku operativu i tako ostaje — NG One orkestrira ekosistem, ne guta ga. Dodirna tačka je konkretna: UX planiranja u NG One-u (grid, planerski cockpit, what-if) preuzet je iz NG Operations jer je proveren u stvarnom pogonu, a ne dizajniran za demo. Razmena podataka stoji na API-first sloju sa REST i OpenAPI opisom nad svakim entitetom, uz MCP pristup za agente. Obim razmene se utvrđuje po projektu, jer granica između pogonske operative i lanca nije ista ni u dva pogona — i to govorimo unapred, a ne posle potpisa.

Kalkulacija izlazi iz stavki, ne iz proseka: materijal po stvarnom utrošku i stvarnoj nabavnoj ceni u koju su ušli i zavisni troškovi uvoza, rad po prijavi sa pogona, kooperacija po usluzi, režija po ključu koji je konfiguracija sa datumom važenja — pa se prošli obračun ne menja kad se ključ promeni. Odstupanje od predkalkulacije ostaje vezano za nalog na kom je nastalo i razloženo je po uzroku: materijal, vreme, škart, kooperacija. Knjiženje ide na dimenzije, tako da profitabilnost po proizvodu, nalogu, pogonu ili kupcu izlazi iz iste glavne knjige iz koje izlazi bruto bilans i uvek se s njim slaže. Backdated prijava pokreće preobračun umesto da ostavi pogrešnu cenu koštanja da stoji.

Ništa se ne dešava sa otvorenim nalogom — i to je poenta. Sastavnica je verzionisan zapis, a nalog nosi referencu na verziju po kojoj je otvoren, pa izmena normativa važi za naloge koji tek nastaju. Kad se posle traži zašto je utrošak odstupao, verzija se čita sa naloga umesto da se rekonstruiše iz mejlova. Ako izmenu treba primeniti i na otvoren nalog, to je odluka koja se donosi svesno, ostavlja trag i vidi se u istoriji naloga — a ne tiha promena koja unazad menja značenje već prijavljenog utroška.

Imamo oboje. APS daje konačno terminiranje sa ograničenjima kapaciteta, alata, ljudi i kalendara, i uz svaki nalog objašnjenje zašto je pao baš na taj termin — raspored koji se ne može objasniti planer ionako ne brani pred pogonom. Ispod njega stoje plan prodaje i proizvodnje, MRP, Production Grid i what-if scenariji u kopiji plana, pa se pomeranje isproba pre nego što dotakne objavljen raspored. PLM vodi životni ciklus proizvoda i inženjerske izmene kroz ECO: ko je tražio izmenu, ko ju je odobrio i od kada važi na sastavnici. Jedna napomena bez ulepšavanja: terminiranje je onoliko tačno koliko su tačna vremena po operaciji, a ta vremena dolaze iz prijave sa pogonskih terminala — zato APS i prijava stoje u istom jezgru, a ne u dva sistema koja se noću sinhronizuju.

Redosledom kojim se podaci oslanjaju jedni na druge. Prvo tehnička priprema: artikli sa JM konverzijama, sastavnice sa verzijom i datumom važenja, tehnološki postupci i normativi — to je deo koji traži najviše vašeg rada, jer je danas najčešće raštrkan po tabelama i po glavama ljudi. Zatim se postavljaju dimenzije i ključ za režiju sa datumom važenja, pa predkalkulacija ima referencu od prvog naloga. Onda plan i MRP, pa pogon i prijava, pa kvalitet i održavanje. Do go-live-a se ide sa jednom linijom ili jednom grupom proizvoda, ne sa celim pogonom odjednom. Konfiguracija je verzionisana i odvojena od jezgra (clean-core), pa ono što se podesi u fazi uvođenja preživljava nadogradnju umesto da se vraća na sto sa svakom novom verzijom.