Every ERP integration we have ever scoped has come in late. Not by a day or two — by weeks, sometimes months. The estimates are not bad. The integrations themselves, in pure software terms, are not difficult. What inflates the timeline is consistent and almost never on the project plan.
This is a short note on the four things that always cost the missing weeks, and how to budget for them honestly.
01. The customer ID is not the customer ID
The first day of any ERP integration begins with a discovery: the table called customer joins to invoice on a column called customer_id. Easy. The first day ends with the realization that some customers in that table also exist in a separate partner table, that the sales team uses a third ID for the same entity in the CRM, and that finance has been quietly maintaining a fourth mapping in a spreadsheet for two years.
This is not a data quality problem. It is the normal state of data in a mid-sized firm. The work that the timeline did not budget for is the conversation across teams about which ID is canonical, and the migration to use it.
Plan for it. A week, sometimes two, just for this.
02. The undocumented business rules
Every ERP has invoices that close on the last business day of the month — except for one customer category that closes on the 15th, except for one country that follows a fiscal calendar, except for the one client whose contract was hand-edited in 2019. None of these exceptions are written down. All of them will break the integration if you do not discover them.
The discovery happens by testing, not by reading. You will run the integration on real data, you will get a number that disagrees with the official one by a small amount, and you will spend three days finding the exception. Then you will find another one.
Every mid-sized firm has business rules that exist only in one person's head. The ERP is the place those rules go to be invisible.
— working principle
03. The historical data is not the same shape as the current data
The schema you are integrating against is the schema as it exists today. The data you are pulling spans, typically, five to ten years. Somewhere in there, the schema changed.
Currency codes were renamed. A status that used to be one column became a join to a lookup table. The field that has been called region for two years used to be called territory. The integration that handles "current" data correctly will mishandle "historical" data silently — and your reports, which compare year-on-year, will be quietly wrong.
This is the failure mode that survives the longest. It does not break anything. It just makes the numbers slightly suspect, in a way that the people relying on them cannot easily explain.
04. The people part
The fourth missing week is, almost always, the conversation between the integration team and the people whose monthly close you are about to slightly disrupt. Even read-only integrations affect their work, because they will need to validate the new data against their existing reports, and reconcile any differences.
Budget a week for this conversation. Have it early. Bring the finance lead into the design review before the integration runs against real data, not after. The fastest path to a delayed integration is a finance team that finds out about it the morning the first reconciliation diverges from theirs.
Rule of thumb: the integration timeline most teams quote is the engineering time. Add a week for IDs, a week for business rules, a week for historical data, and a week for the finance conversation. Then quote.
A short closing
ERP integrations are not technically hard. The reason they are slow is that the work is mostly not technical. It is forensic, social, and historical. Estimate as if those things take time, and the project lands close to where you said it would. Estimate the engineering time only, and the project will be three weeks late, every time.
Svaka ERP integracija koju smo ikad opisali kasnila je. Ne za dan-dva — za nedelje, ponekad mesece. Procene nisu loše. Same integracije, u čistim softverskim okvirima, nisu teške. Ono što naduvava vremenski plan dosledno je i skoro nikada nije na planu projekta.
Ovo je kratka beleška o četiri stvari koje uvek koštaju nedostajuće nedelje, i kako iskreno za njih budžetirati.
01. ID klijenta nije ID klijenta
Prvi dan svake ERP integracije počinje otkrićem: tabela customer se spaja na invoice po koloni customer_id. Lako. Prvi dan se završava uvidom da neki klijenti iz te tabele postoje i u zasebnoj partner tabeli, da prodajni tim koristi treći ID za isti entitet u CRM-u, i da je finansije tiho održavalo četvrto mapiranje u tabeli dve godine.
Ovo nije problem kvaliteta podataka. To je normalno stanje podataka u srednjoj firmi. Posao za koji vremenski plan nije budžetirao je razgovor preko timova o tome koji je ID merodavan, i migracija na njegovu upotrebu.
Planirajte za to. Nedelju, ponekad dve, samo za ovo.
02. Nedokumentovana poslovna pravila
Svaki ERP ima fakture koje se zatvaraju poslednjeg radnog dana u mesecu — osim jedne kategorije klijenata koja se zatvara 15., osim jedne zemlje koja prati fiskalni kalendar, osim jednog klijenta čiji je ugovor ručno izmenjen 2019. Nijedan od ovih izuzetaka nije zapisan. Svi će slomiti integraciju ako ih ne otkrijete.
Otkriće se dešava testiranjem, ne čitanjem. Pokrenućete integraciju na stvarnim podacima, dobićete broj koji se ne slaže sa zvaničnim za malu vrednost, i provešćete tri dana tražeći izuzetak. Zatim ćete naći drugi.
Svaka srednja firma ima poslovna pravila koja postoje samo u nečijoj glavi. ERP je mesto na kome ta pravila odu da budu nevidljiva.
— radni princip
03. Istorijski podaci nisu istog oblika kao trenutni
Šema sa kojom integrišete je šema kakva je danas. Podaci koje povlačite obuhvataju, tipično, pet do deset godina. Negde u tom periodu, šema se promenila.
Šifre valuta su preimenovane. Status koji je nekad bio jedna kolona postao je spoj sa lookup tabelom. Polje koje se već dve godine zove region ranije se zvalo territory. Integracija koja ispravno obrađuje „trenutne" podatke neispravno će obraditi „istorijske" podatke u tišini — i vaši izveštaji, koji upoređuju godinu na godinu, biće tiho pogrešni.
Ovo je način otkazivanja koji najduže preživljava. Ne lomi ništa. Samo čini brojeve blago sumnjivim, na način koji ljudi koji se na njih oslanjaju ne mogu lako da objasne.
04. Ljudski deo
Četvrta nedostajuća nedelja je, gotovo uvek, razgovor između integracionog tima i ljudi čije ćete mesečno zatvaranje uskoro malo poremetiti. Čak i samo-čitajuće integracije utiču na njihov rad, jer će morati da validiraju nove podatke u odnosu na svoje postojeće izveštaje i da pomire razlike.
Budžetirajte nedelju za ovaj razgovor. Vodite ga rano. Uvedite finansijskog lidera u dizajn pregled pre nego što integracija krene na stvarnim podacima, ne posle. Najbrži put do kasne integracije je finansijski tim koji za nju sazna ujutru kada se prvo usaglašavanje razlikuje od njihovog.
Pravilo: vremenski plan integracije koji većina timova navede je inženjersko vreme. Dodajte nedelju za ID-jeve, nedelju za poslovna pravila, nedelju za istorijske podatke, i nedelju za razgovor sa finansijama. Onda navedite.
Kratko zatvaranje
ERP integracije nisu tehnički teške. Razlog zbog kog su spore jeste taj što posao uglavnom nije tehnički. Forenzički je, društveni i istorijski. Procenjujte kao da te stvari traju, i projekat sleti blizu mesta koje ste rekli. Procenjujte samo inženjersko vreme, i projekat će kasniti tri nedelje, svaki put.
Filed under: DATA · METHOD First published: Jan 11, 2026
