Često se postavlja pitanje da li EDI ima budućnost. Stvoren je ranih 70-ih da bi se pojednostavila B2B komunikacija i omogućila trgovinskim partnerima da brzo i bezbedno razmenjuju informacije jedni sa drugima i smanjili ili potpuno eliminisali komunikaciju na papiru i naravno, tehnologija je napredovala u godinama od tada. Ovih dana mnogi komentatori govore o EDI-ju u istorijskim terminima i nude API tehnologije kao novi put napred. Pa šta je stvarnost?
Šta su API-ji?
Razgovarali smo o EDI-ju, šta je to i kako funkcioniše u prethodnim blogovima. Ali šta su API-ji? Gartnerov tehnički pojmovnik opisuje API kao „...interfejs koji pruža programski pristup funkcionalnosti usluge i podacima unutar aplikacije ili baze podataka. Može se koristiti kao gradivni blok za razvoj novih interakcija sa ljudima, drugim aplikacijama ili pametnim uređajima. Kompanije koriste API-je da bi zadovoljile potrebe digitalne transformacije ili ekosistema i započele poslovni model platforme.“ Jednostavno rečeno, to znači da je API interfejs koji omogućava dva različita sistema (recimo, sistem kupca i sistem dobavljača) aplikacije da razgovaraju jedni sa drugima i razmenjuju podatke bez potrebe da bilo koji sistem razume složenost oko toga za šta će se koristiti podaci koji se razmenjuju (ili poruka) ili kako će drugi sistem raditi ono što potom radi . Dobar praktičan primer kako API funkcioniše možete biti vi, kada naručite tajlandski obrok za poneti za zabavu koju održavate. Odete na internet, pročitate meni (API) i naručite. Restoran nema pojma ko prisustvuje vašoj zabavi ili šta slavite. Isto tako, nemate pojma gde se tačno restoran nalazi, koje specifične sastojke će koristiti ili ko će ga kuvati i kako… i niko od vas ne treba da znate. Poručujete, plaćate svoj novac, interfejs između vas i restorana osigurava da oni dobiju vašu porudžbinu i novac, dobijate hranu na svoju adresu, nadamo se na vreme. Ako razmišljate o API-jima u kontekstu povezujući različite, diskretne poslovne aplikacije, idealno deluju kao blokovi za višekratnu upotrebu (zbog čega ćete ih ponekad videti u poređenju sa poznatim danskim igračkama Lego kockicama) koje omogućavaju programerima da brže kreiraju veze između aplikacija; u stvari, komunikacioni mehanizam, ili kod, će povezati dve aplikacije zajedno. Zamislite veb lokaciju za poređenje cena za, recimo, ponude osiguranja. Sajt bi mogao da drži seriju tabela sa troškovima naknada svake osiguravajuće kompanije, ali oni bi morali da ažuriraju ovu tabelu neprekidno, u realnom vremenu... i morali bi to da rade za svaku osiguravajuću kompaniju koju pokrivaju. Ako, međutim, sajt za poređenje razvije i objavi API koji može da koristi bilo koje osiguravajuće društvo kako bi svakom omogućilo da kreira mogućnost obrade upita, i na sličan način svaka uključena osiguravajuća kompanija razvije i objavi svoj API kako bi omogućila povratnu ponudu,( i verovatno drugi API-ji za rukovanje ugovorima, prodajom i plaćanjem na mreži), onda se poslovanje ubrzava, možete dobiti ponudu i kupiti najbolju ponudu, u realnom vremenu (bez saznanja bilo šta od „kako se to radi“) i nove osiguravače, nove usluge, nove ponude, sve se mogu dodati brzo i lako. Poreklo API-ja može se naći u radu koji su istraživači obavili oko 2000. godine koji su pokušavali da razviju nove načine omogućavanja veće saradnje između aplikacija širom weba koje su trošile manje propusnog opsega i stoga uključivale manje koda.
Vremenom je razvoj JavaScript objektne notacije (JSON) otvorio priliku za razvoj ovog rada i kreiranje aplikacija koje su nudile odličnu povezanost pretraživača sa aplikacijama male gustine. Ovaj napredak je dodatno poboljšan jer su novi programski jezici kao što su Python, Ruby, PHP i naravno Java omogućili da novo programiranje bude brže (jer su bili prilagođeni programerima), fleksibilnije (zato što su bili veoma skalabilni) i jeftiniji (zbog navedenih razloga i činjenica da su bili nezavisni od platforme.) Kako je IT industrija prihvatila koncept razvoja API-ja i gigante za prikupljanje podataka kao što su Google, Facebook ..i svi ostali kojih se možete setiti... su predvodili, upotreba API-ja je eksplodirala. Sada se svi uobičajeni društveni mediji, potrošnja sadržaja, onlajn usluge, deljenje podataka i sadržaja, pa čak i platforme za isporuku državnih usluga, oslanjaju na API-je. Eksplozija „mobilnog“ računarstva bila je ogroman akcelerator i postoji svaki razlog da se očekuje da će evolucija IoT-a i ogroman rast međupovezanosti koji će to doneti pokrenuti sledeću promenu u evoluciji i upotrebi API-ja. Ukratko, oni su svuda ..i tu su da ostanu.
Pa gde nas to ostavlja danas?
Suprotno mnogim predviđanjima, i s obzirom na ono što smo upravo rekli o rastu API-ja, EDI nastavlja da napreduje – u stvari, procene sugerišu da će ukupno EDI tržište rasti na 12% CAGR 2022-2027 (EMR: Global Electronic Data Interchange ( EDI) Market Outlook). Dok je EDI trebalo da standardizuje B2B komunikaciju, ispostavilo se da stvarnost nije baš tako jednostavna. U Evropi kompanije koriste EDIFACT, dok je u SAD i Aziji ANSI Ks12 najrasprostranjeniji standard. Uz to, EDI, kao opšti model, je dobro uspostavljen, postoji već duže vreme i zasniva se na čvrstim standardima. To znači, naravno, da postoje prednosti i nedostaci korišćenja EDI: standardizacija jedne osobe i stoga jasna lakoća korišćenja je nefleksibilnost druge osobe i striktna spoljna 'kontrola od strane dominantnih igrača u određenoj industriji'. Ukratko, prednosti EDI-ja se mogu reći da su: Dobro dokumentovan i standardizovan tako da 'svi znaju pravila', a ova 'pravila ' se redovno testiraju tako da novi učesnici mogu odmah da počnu sa radom znajući tačno u kojim okvirima treba da rade i sa sigurnošću da se oni neće menjati bilo kakvom učestalošću. Mnogo godina razmišljanja, planiranja i standardizovane upotrebe, uključujući potpisivanje i šifrovanje zajedno sa bezbednim neporicanjem (tj. niko ne može da promeni dokument a da nije jasno i očigledno da je to uradio) znači da je EDI poruka veoma bezbedna, dostupna samo onima sa odgovarajućim dozvolama i integritetom podataka sadržano je apsolutno. Dugo uspostavljeni protokoli za razmenu poruka znače da ako nešto krene naopako, postoje jasne i adresirane staze toka posla koje omogućavaju brzu identifikaciju i rešavanje problema. To ne znači da EDI nema svoje nedostatke u određenim poslovnim okruženjima i generalno , razvoj API-ja je pokušao da odgovori na neka od ovih ograničenja. To uključuje: Jednostavno, budući da je brži i fleksibilniji za razvoj, primena API-ja omogućava preduzećima da reaguju na nove mogućnosti koje nisu pokrivene uobičajenim EDI standardima daleko brže , jeftino i nezavisno od sveobuhvatne 'kontrole' i vremenskih okvira velikih dominantnih igrača ili industrijskih tela. API-ji su veoma pogodni za razvoj integracija koje omogućavaju više od pukog deljenja poruka. Oni mogu olakšati povezivanje baza podataka i aplikacija na agilniji i lakši način, posebno veze sa mobilnim uređajima i aplikacijama. Sa evolucijom novih tehnologija i alata, razvoj API-ja je postao lakši, jeftiniji, a dostupnost i cena Stručno osoblje za razvoj koji će vam trebati generalno je mnogo manje od pokušaja da se „razvije“ nove funkcionalnosti u okviru EDI ekosistema. Pojava ovih novih, funki API tehnologija stvorila je osnov mišljenja da je EDI imao svoj dan i da će ga u potpunosti zameniti API-ji. Međutim, uvaženi analitičar Gartner je zaključio da: „API dopunjuju, a ne zamenjuju, tradicionalne B2B tehnologije kao što su elektronska razmena podataka i upravljani prenos datoteka. Lideri aplikacija bi trebalo da koriste API mogućnosti da dodaju nove kanale, omoguće automatizaciju i optimizuju svoj poslovni ekosistem za digitalno poslovanje.” „Koristite API-je za modernizaciju EDI za integraciju B2B ekosistema” Mark O’Nil i Vilijam Meknil, 11.06.2019.
Zašto je ova debata važna i kakvu ulogu treba da ima u vašem procesu planiranja?
Ni EDI ni API-ji ne nude savršeno rešenje za sve situacije, ali pružaju značajne prednosti korisnicima. Gore smo raspravljali o nekim ograničenjima EDI-ja i prednostima API-ja, tako da je sasvim ispravno da ponudimo prikaz u ogledalu i sumiramo prednosti EDI-a i neke od nedostataka API-ja. EDI nudi mnoge prednosti u odnosu na API-je, ali nosi neki nedostaci Nedostatak dugo uspostavljenih EDI formata je to što oni mogu biti složeni za rad i ako je potrebno da izvršite prilagođavanja, pronalaženje stručnjaka sa veštinama i iskustvom može biti izazovno i skupo ako ste podesili da koristite ono što je ' u ponudi“, ali onda otkrijete da morate da dodate komplementarne usluge, možda ćete otkriti da niste dovoljno opremljeni da se nosite sa izazovom Kako se pojavljuju nove mogućnosti i želite da se krećete brzo, a sa fokusom na platforme za mobilne računare, teško ćete se prilagoditi EDI platforma brzo API-ji, s druge strane, iako su često brži i jeftiniji načini dodavanja funkcionalnosti imaju svoje nedostatke. Oni nose nivo tehnološke složenosti koji zahteva ulaganje u kvalifikovano osoblje. Bezbednosni rizici se mogu smanjiti ako razvijete veze od tačke do tačke, ali ovo može biti dugotrajno i skupo. Bićete odgovorni za kreiranje sopstvene sposobnosti za praćenje revizije, kako biste zaštitili od narušavanja integriteta podataka, tako i da biste bili sigurni da možete da pratite gde su se pojavili problemi ili promene koje su napravljene dok se razvoj API-ja kreće i dalje u toku ostaje slučaj da ne postoji sveobuhvatno telo koje postavlja standarde, testira usklađenost ili garantuje međusobnu povezanost.
Pa kako možete izvući najbolje iz oba sveta?
Da bi se moglo raditi sa obe tehnologije potrebno je integraciono rešenje zasnovano na integracionoj platformi. Ovo omogućava deljenje i korišćenje podataka između EDI-a i API-ja i izvlačenje maksimuma iz B2B i/ili A2A integracije i podataka koji se razmenjuju. Takođe može biti korisno imati priliku da razgovarate o vašim poslovnim procesima sa stručnjacima za EDI, koji mogu da identifikuju gde možete da 'brzo pratite' da biste usvojili postojeće formate i protokole za najbržu i najlakšu implementaciju i podjednako preporuče oblasti u kojima API-ji mogu da ponude bolja opcija. Ovo je filozofija dizajna koja daje informacije u pravcu razvoja Omnizon platforme. API i EDI su komplementarni i mogu se primeniti u tandemu do velikog uspeha koristeći rešenje koje je razvio Omnizon. Nedostaci povezani sa EDI tehnologijom mogu se pojaviti kod velike većine rešenja, ali korišćenjem naše Omnizon iPaaS EDI platforme, korisnik ima alate u svojim rukama da lako prevaziđe ove probleme uz mogućnost transformacije tipova dokumenata i polja podataka uz brzu implementaciju dok zadržavanje mogućnosti korišćenja API-ja za određene integracije kada se pokaže kao jednostavnije, brže i jeftinije rešenje, posebno u pogledu povezivanja sa nekim od standardnih aplikacija, kao što su uobičajeni ERP sistemi ili mobilne aplikacije. U Omnizonu razumemo obim naših sposobnosti i planiramo pažljivo i disciplinovano kako bismo osigurali da nikada ne preteramo svoje kapacitete. Ne pokušavamo da budemo univerzalna platforma za povezivanje API-ja, već se fokusiramo na određene tržišne sektore i korisničke segmente. Primer ovoga je naš fokus na Odoo modulima. Ako ste korisnik Odoo-a, onda ćete po svoj prilici raditi u SMB sektoru. Ako je tako, moraćete da donesete kritične odluke o ulaganju u koje veštine možete sebi priuštiti da investirate i koje oblasti poslovanja predstavljaju osnovnu poslovnu aktivnost za vas. Razvojem Odoo-specifične povezanosti, REDOK je u mogućnosti da vam ponudi prilagođeno rešenje koje prepoznaje vaš fokus na potrebe i pruža značajne „brze“ poslovne prednosti, dok vam omogućava da se koncentrišete na vođenje svojih poslovnih operacija znajući da su vaše potrebe za međupovezivanjem dobro zadovoljene.
Omnizon Odoo moduli
Da bismo vam dali jasniju sliku o vrsti stvari na koje se fokusiramo, hajde da pobliže pogledamo šta smo uradili u Odoo prostoru. Omnizon je razvio nekoliko Odoo modula koji omogućavaju jednostavnu integraciju Odoo ERP sistema sa Omnizonovom iPaaS EDI platformom. Prvo imamo ono što zovemo osnovni modul koji daje mogućnost unosa GLN-ova za kompaniju i tačke isporuke i GTIN-a za proizvode . Ovo pruža čvrstu osnovu za razvoj pune funkcionalnosti. Drugi modul je namenjen korisnicima koji imaju ulogu kupca u poslovnom procesu, dok je treći modul razvijen za one u ulozi dobavljača. U većini slučajeva, ako koristite Omnizonovu iPaaS EDI platformu, biće vam potrebna oba Odoo modula. Sa ovim Odoo modulima, imate mogućnost da integrišete svoj Odoo ERP sistem sa partnerima koji koriste Odoo ili druge ERP sisteme, kao i sa partnerima koji nisu digitalni igrači i koji još uvek koriste e-poštu ili druge poruke za komunikaciju u samo nekoliko klikova. Za partnere kod kojih je veza između ERP-a i ERP-a integracija se postiže korišćenjem Enterprise EDI opcije. Za one koji ne koriste nijedan ERP sistem ili gde postoje neki drugi poslovni ili tehnički razlozi, onda se integracija ostvaruje korišćenjem Web EDI Portala za dobavljače ili Web EDI Portala za kupce, koji su sami po sebi sastavni moduli EDI platforme. Zbog sveobuhvatne mogućnosti Omnizon iPaaS platforme u kombinaciji sa Odoo modulima, u poziciji ste da odgovorite na izazove B2B integracije u vezi sa celokupnim procesom nabavke i prodaje, brzo i jednostavno bez potencijalnih nedigitalizovanih dobavljača ili kupaca. 'isključeni' iz vašeg digitalnog eko-sistema. Jednostavnost implementacije i potpunost integracije koju Omnizon Odoo moduli donose, povećava vašu konkurentsku prednost i pruža sve prednosti digitalizacije vaših poslovnih procesa na brz i jednostavan način. Vidimo razvoj ove vrste modula kao praktična demonstracija naše vizije da digitalna transformacija treba da bude dostupna svima i ne bi trebalo da bude složena niti dugotrajna i predstavlja dokaz za razvojni put koji smo posvećeni da sledimo.
Mi u Redoku, kao predstavnik Omnizona, nastavićemo da se bavimo potrebama korisnika u ključnim sektorima malih i srednjih preduzeća, tako da ostanite sa nama za dalja ažuriranja dok donosimo nove module na tržište.