Dva sustava možete povezati bez stvarnog povezivanja procesa. Narudžba može prijeći iz CRM-a u ERP, ali statusi mogu značiti različite stvari, kupac može imati dva identifikatora, a neuspjeli prijenos može završiti u logu koji nitko ne prati. Integracija sustava postaje poslovno korisna tek kada je jasno koji je sustav mjerodavan za podatak, što događaj znači i tko rješava iznimku.
API integracija zato nije samo pitanje endpointa, autentikacije i formata poruke. Ona je dogovor o tome kako posao nastavlja kada je podatak uredan, kasni, stigne dvaput ili ga nije moguće obraditi.
Prvi uspješno preneseni zapis potvrđuje samo da je jedna tehnička veza u tom trenutku radila. Ne potvrđuje da su oba sustava jednako razumjela podatak niti da korisnik može završiti posao bez dodatnog ručnog usklađivanja.
Primjerice, CRM može označiti ponudu kao prihvaćenu kada je kupac usmeno potvrdio kupnju. ERP može zahtijevati dodatnu provjeru prije nastanka potvrđene narudžbe. Ako se oznaka "prihvaćeno" automatski preslika u oba sustava kao isto stanje, timovi mogu donijeti pogrešnu odluku o proizvodnji, isporuci ili naplati.
Problem se često ne vidi na demonstraciji. Pojavi se kada nedostaje porezni broj, kada vanjski API odgovara sporije nego obično ili kada korisnik promijeni adresu u sustavu koji nije predviđen kao izvor te promjene. Tada nastaju zasebne tablice, e-mailovi i ručni popravci. To su novi podatkovni otoci, samo smješteni između postojećih sustava.
Za svaku važnu informaciju jedan sustav treba biti mjerodavan. Drugi sustavi smiju imati kopiju, ali svima mora biti jasno gdje nastaje promjena mjerodavna za cijeli proces i kojim se pravilom prenosi dalje.
U jednom procesu raspodjela može izgledati ovako:
Owner podataka nije samo tehnička oznaka. On određuje tko smije ispraviti vrijednost kada se pojavi neslaganje. Bez tog pravila obično nastaju dva loša obrasca: zadnja promjena pobjeđuje, bez obzira na izvor, ili zaposlenici ručno uspoređuju zapise kada problem već zaustavi proces.
Za objekte koji se dijele između sustava pripremite mapu integracije. Za svaki objekt navedite:
Tehnički endpoint bez tih odgovora ne opisuje proces. On opisuje samo put kojim paket može putovati.
Poruka poput status=3 može imati značenje samo u izvornom sustavu. Integracija podataka postaje razumljivija i održivija kada događaj nosi poslovno značenje, primjerice: narudžba je odobrena, radni nalog je završen ili isporuka je blokirana.
Sustavi pritom ne trebaju dijeliti isti interni model. CRM, ERP i proizvodni sustav mogu zadržati vlastite šifre, statuse i pravila. Na granici između njih ipak trebaju dogovoriti stabilan jezik:
Takav ugovor olakšava i buduće promjene. Kada se doda novi kanal prodaje ili poslovni modul, ne treba nagađati što nejasna šifra predstavlja. Treba provjeriti može li novi sustav ispuniti već dogovoreno poslovno značenje. Kod šireg povezivanja Poslovni moduli povezani s ERP-om mogu se promatrati kao dio istog toka, a ne kao skup zasebnih priključaka.
Mreža će povremeno biti nedostupna. Odredišni sustav može usporiti. Podatak može biti nepotpun. Isti događaj može stići dvaput, a događaji mogu doći pogrešnim redoslijedom. To nisu rubni slučajevi koje treba ostaviti za kraj, nego uvjeti u kojima integracija mora ostati upravljiva.
Prije implementacije dogovorite sljedeće:
Vidljiva pogreška nije ugodna, ali daje timu priliku da reagira. Tiha pogreška stvara privid usklađenosti dok se poslovni proces već razdvaja. Zato operativni nadzor treba pratiti ne samo tehničku dostupnost veze nego i poslovne posljedice: koliko zapisa čeka, koji tok je blokiran i kojem korisniku je potrebna odluka.
Jedna osoba ne mora nositi sve odgovornosti integracije. Nijedna odgovornost ne smije ostati bez imenovanog vlasnika.
Posljednja uloga zaslužuje posebnu pažnju. Ako nije jasno tko može odlučiti o neispravnoj adresi, nedostajućem artiklu ili neusuglašenoj cijeni, problem se često prebacuje u zajedničku tablicu. Takva tablica postaje neformalni sustav evidencije i novi podatkovni otok.
Ne otvarajte istodobno deset integracijskih veza. Najprije dovršite jedan end-to-end proces. Dobar primjer je put od prihvaćene ponude do narudžbe, isporuke i računa.
Za taj tok zapišite:
Takav pilot otkriva razliku između tehničke razmjene i poslovne integracije. Može pokazati da je potreban dodatni identifikator, da se dva statusa ne smiju izravno preslikati ili da korisniku treba pregled zapisa na čekanju. Nakon što tim potvrdi obrazac na jednom toku, isti se princip može proširiti na druge objekte i procese.
Postoji i tradeoff. Široka standardizacija prije prvog toka može usporiti početak, a preuski pilot može previdjeti buduće potrebe. Praktičan pristup je standardizirati ono što je zajedničko i poslovno kritično - identifikatore, vlasništvo, događaje, pravila iznimki i nadzor - dok se detalji pojedinog sustava rješavaju ondje gdje nastaju.
Tim koji uključuje poslovne korisnike, vlasnike podataka i tehničke odgovorne osobe trebao bi zajedno odgovoriti na ova pitanja:
Uz ugovor pripremite probne slučajeve za ispravan događaj, nepotpun podatak, dupli događaj, pogrešan redoslijed i prekid odredišnog sustava. Integracija koja prolazi samo idealan test još nije spremna za svakodnevni rad.
Ako odgovori na ta pitanja nisu jasni, tehnički tim će ih ipak morati pretpostaviti. Te pretpostavke kasnije postaju skrivena poslovna pravila, a njihova promjena postaje skuplja kada je tok već u upotrebi.
Sljedeći korak nije nužno izrada novog API-ja. Za prvi odabrani tok dogovorite ownera podataka, dopušteno kašnjenje i osobu koja rješava iznimku. Ako te tri odluke nisu jasne, ERP i procesni screening može pomoći strukturirati proces prije implementacije. Kada jesu jasne, tehnički ugovor dobiva poslovni smisao.