Sistemi, ki jih že plačujete, končno usklajeni med seboj.
Vaš ERP, vaš CRM, vaša spletna trgovina in preglednica, ki jo je nekdo sestavil, da premosti vrzel med njimi. Povežemo, kar že uporabljate, da se zapis vnese enkrat, ostali sistemi pa mu sledijo, namesto da ga nekdo ročno pretipkava v naslednji zaslon.
Za kaj gre
Integracija sistemov pomeni uskladiti dva ali več sistemov, ki niso bili nikoli narejeni tako, da bi vedeli drug za drugega. O istem kupcu, istem naročilu in isti zalogi morajo trditi isto, ne da bi številko med njimi prenašal človek. To ni proces z odločitvijo na sredini. Tak proces je avtomatizacija poslovnih procesov. Če niste prepričani, kaj od tega potrebujete, se splača prebrati vsako stran posebej. Tu gre bolj za vodovodno napeljavo: sistemi, od katerih vsak svoje delo že dobro opravlja, se usklajujejo sproti ali po urniku.
Klic API je redko težji del. Težje je to, da je kupec v sistemu A eno samo polje z imenom, brez preverjanja dvojnikov, sistem B pa zahteva ime, priimek in davčno številko ter dvojnik na slab dan tiho zavrne. Da se dva sistema ujemata, je treba za vsako polje določiti en sam vir resnice, zgraditi tabelo preslikav, ker večina sistemov različnih ponudnikov nima skupnega ID-ja, in se zavestno odločiti, kaj se zgodi, ko je bil zapis od zadnje sinhronizacije spremenjen v obeh sistemih, namesto da tiho obvelja tisti, ki se je sinhroniziral zadnji.
Najprej zgradimo samo branje: podatke potegnemo v senčno kopijo, jo na oko primerjamo z obema sistemoma in pisanje vklopimo šele, ko preslikava zdrži nekaj dni resničnega prometa. Pri integraciji lahko napaka pri pisanju pokvari zapis v sistemu, s katerim nekdo prav ta trenutek izstavlja račun kupcu. Napaka pri branju ne pokvari ničesar. Omejitve števila klicev, ostranjevanje in ponudnik, ki API spremeni skoraj brez opozorila, so običajen teden. Zato sinhronizacija od prvega dne dobi čakalno vrsto napak in opozarjanje: pokvarjena preslikava je tako zahtevek, ne kupec, ki opazi, da njegovo naročilo ni nikoli prispelo.
Kaj dobite
Preslikava polj
Vsa polja, ki jih eden ali drugi sistem hrani za zapis, ki ga usklajujemo, in za vsako določen vir resnice. Zapisano, ne samo sprogramirano.
Mehanizem sinhronizacije
Prek webhookov, kjer jih ponudnik podpira, in s poizvedovanjem po urniku, kjer jih ne. Odmerjen po omejitvi števila klicev, ki jo postavlja ponudnik, namesto da bi ga zasipal z zahtevami.
Tabela za ujemanje zapisov
Zapis v enem sistemu poveže z njegovim parom v drugem. Večina sistemov različnih ponudnikov nima skupnega ID-ja, ujemanje samo po imenu pa račune pripne napačnemu kupcu.
Logika usklajevanja
Izrecen odgovor na vprašanje, kaj se zgodi, ko se je zapis od zadnje sinhronizacije spremenil v obeh sistemih. Odločeno namenoma, ne tako, da po naključju obvelja zadnje pisanje.
Čakalna vrsta napak
Zapisi, ki se ne dajo preslikati, počakajo v vrsti in so označeni, da jih pogleda človek. Sinhronizacija jih ne zavrže in jih ne poskuša znova v nedogled, dokler ne nastane kaj hujšega.
Nadzor in opozarjanje
Sinhronizacija, ki se tiho ustavi, je slabša od take, ki ni nikoli tekla. Zato o tem nekdo izve prej kot kupec.
Preverjanje samo z branjem
Več dni primerjanja senčne kopije z obema sistemoma, preden se v katerega od njiju karkoli zapiše. Prehod na živo sinhronizacijo je tako zavestna odločitev.
Izvorna koda in dokumentacija preslikav
Oboje dobite v roke, da lahko sinhronizacijo vzdržuje, pregleda ali razširi tudi nekdo, ki ga pri gradnji ni bilo zraven.
Kdaj je integracija sistemov prava izbira in kdaj ne
Prava izbira
- Plačujete dva ali več sistemov, ki vsi potrebujejo isti zapis, na primer kupca, naročilo ali stanje zaloge, danes pa jih ročno usklajuje človek.
- Enemu od sistemov pri določenem podatku že zaupate, recimo pri zalogi, ceni ali statusu kupca, in potrebujete, da mu ostali sledijo, namesto da mu oporekajo.
- Opekli ste se že z izvozom CSV, ki je star en dan, še preden ga kdo prebere, ali s preglednico, ki je po tihem pravi vir resnice, a tega nihče ne prizna.
- Sistemi, ki jih povezujemo, imajo API, pa čeprav neroden ali nedokumentiran. Če ga nima nobeden, je to drugačen in grši projekt, kar povemo, preden začnemo.
- Količina je dovolj velika, da napačno vtipkan ali izpuščen zapis nekaj pomeni: pri sto naročilih na dan se tipkarska napaka konča s povratno bremenitvijo, ne z opravičilom.
Ni prava izbira
- Gre za API enega ponudnika, ki ga je treba v eni smeri priključiti na programsko opremo, ki jo že imate, in ni drugega poslovnega sistema, ki bi moral ostati usklajen. To je ožji primer in ima svojo stran: integracija API.
- Potrebujete odločitev ali odobritev, ki mora skozi ljudi, preden se karkoli zgodi. To je avtomatizacija poslovnih procesov, ne to, kar opisuje ta stran.
- Drugega sistema še ni in ga je treba šele postaviti. To je uvedba ERP, ta stran pa predpostavlja, da sistemi, ki jih povezujemo, že obstajajo.
- Sistema skupaj obdelata manj kot približno sto zapisov na mesec. Ročni izvoz in uvoz postavite hitreje kot integracijo in nikomur ne bi smelo biti nerodno, če naredi kar to.
- Ena stran nima API-ja in ga tudi ne načrtuje, kar pri nekaterih starejših računovodskih programih res drži. Iskren odgovor je v tem primeru krhka zasilna rešitev z avtomatizacijo uporabniškega vmesnika. Povedali vam bomo, da je potrebno prav to, namesto da bi se pretvarjali, da je drugače.
- Želite eno enotno bazo podatkov, ki oba sistema nadomesti, namesto da bi ju povezali. To je bližje internim orodjem ali migraciji in je drug pogovor.
Kako poteka
- 01
Branje obeh strani
Vsa polja, ki jih eden ali drugi sistem hrani za zapis, ki ga usklajujemo, in kateri ima prav, ko se ne ujemata. Tu se pokaže, ali je projekt preprost ali zahteva resen razmislek.
- 02
Preslikava in ujemanje
Preslikava polj in ključ za ujemanje zapisov med sistemoma, oboje zapisano, preden obstaja kakršna koli koda za sinhronizacijo.
- 03
Najprej samo branje
Podatke potegnemo v senčno kopijo in jo na oko preverimo ob obeh sistemih, da napako v preslikavi ujamemo, preden lahko karkoli zapiše.
- 04
Vklop pisanja
Čakalna vrsta napak in opozarjanje takrat že tečeta. Ne dodajamo ju šele potem, ko prvi incident pokaže, da sta bila potrebna.
- 05
Predaja
Dokumentacija preslikav, dostopni podatki in izvorna koda, da sinhronizacija teče naprej tudi takrat, ko je ne nadziramo več mi.
Vprašanja, ki jih slišimo
Kaj se zgodi, ko zapis obstaja v obeh sistemih, a se podatki ne ujemajo?
Na to odgovorimo, preden napišemo kakršno koli kodo za sinhronizacijo, ne potem, ko ta nekaj pokvari. Posamezno polje ima običajno očiten vir resnice: zaloga se vodi v ERP, ne v spletni trgovini. Kjer ga res nima, gre konflikt v čakalno vrsto za človeka, namesto da ga razreši sistem, ki se je po naključju sinhroniziral zadnji.
Ali morata oba sistema imeti pravi API?
Potrebujeta vsaj kakšen API, tudi če je grob. Tudi s ponudnikom, ki ponuja samo izvoz CSV in nobenih webhookov, se da delati, le da po urniku namesto v realnem času. Brez kakršnega koli API-ja to postane avtomatizacija uporabniškega vmesnika. To povemo naravnost pred začetkom, ker je to bolj krhka vrsta projekta in ima drugačno ceno.
Sinhronizacija v realnem času ali po urniku?
Prek webhookov, kjer jih ponudnik podpira in količina opraviči spremljanje dogodkov v živo. Kjer ne, podatke prevzemamo po urniku, običajno v razmiku od nekaj minut do ene ure. Realni čas na sestanku zveni bolje, kot je običajno vreden pri podatkih, ki jih človek tako ali tako pogleda le enkrat na dan.
Je mogoča povezava spletne trgovine ali platforme, ki jo uporabljamo prav mi?
Verjetno. Navedite jo v prvem pogovoru in naravnost vam povemo, ali smo s tem API-jem že delali ali bi njegovo dokumentacijo brali prvič. Razliko pošteno upoštevamo v časovnem načrtu že na začetku, ne za nazaj.
Newsletter
Novice iz delavnice
Zapisi o tem, kako načrtujemo, gradimo in dostavljamo programsko opremo. Brez kampanj, brez avtomatiziranih nizov sporočil, odjavite pa se lahko z enim klikom.
Isti zapis pretipkavate še v drug sistem?
Povejte nam, za katera dva sistema gre in kako je v vsakem videti kupec, naročilo ali račun. Sporočilo prebere inženir in vam naravnost pove, ali se integracijo splača graditi.