Integracija radi pouzdano tek kada oba sustava jednako tumače svaki poslovni podatak. Ugovor o poslovnom podatku zato ne opisuje samo format poruke. On određuje značenje integracijskih polja, dopuštene vrijednosti, jedinicu mjere, obveznost, vlasnika promjene i odgovor na neispravan zapis.
Bez tog dogovora dva tehnički povezana sustava mogu razmjenjivati poruke, a poslovni proces ipak može stvarati pogrešne narudžbe, zalihe ili knjiženja. Problem često nije u vezi među sustavima nego u različitom razumijevanju podatka.
Tehnička specifikacija obično navodi naziv polja, tip podatka i način prijenosa. To je potreban početak, ali nije dovoljno za poslovnu odluku. Polje quantity može biti broj s dvije decimale, no ostaje otvoreno pitanje predstavlja li broj komade, kilograme, metre ili pakiranja. Polje customer_id može imati valjan format, ali možda pripada kupcu koji nije odobren za narudžbe.
Ugovor o poslovnom podatku povezuje tehničku razmjenu s poslovnim značenjem. Za svako polje koje utječe na proces treba zapisati barem:
Takav zapis služi ljudima koji vode proces, korisnicima ERP-a i inženjerima koji održavaju integraciju. Njegova je vrijednost u tome što uklanja prešutne pretpostavke prije nego što postanu operativni incident.
Najprije treba odrediti koju odluku podatak podržava. Kod predaje narudžbe to mogu biti odluke o prihvatu narudžbe, raspoloživosti artikla, isporuci, računu ili knjiženju. Tek nakon toga ima smisla dogovoriti polja i tehnički prijenos.
Koristan redoslijed rada izgleda ovako:
Vlasnik ulaznog podatka nije nužno vlasnik cijelog procesa. Sustav za upravljanje odnosima s kupcima, primjerice, može biti izvor kontakta kupca, dok ERP ostaje službeni izvor za računovodstveni status kupca. Ugovor mora jasno razdvojiti tko smije stvoriti vrijednost, tko smije izmijeniti vrijednost i koji sustav objavljuje službeno stanje za pojedinu odluku.
Sljedeći je scenarij hipotetski. Služi kao obrazac za radionicu, a ne kao opis određenog ORKA rješenja ili korisnika.
Prodajni sustav šalje narudžbu u ERP kada prodajni korisnik potvrdi predaju. Za zaglavlje narudžbe ugovor može odrediti ove podatke:
Za svaki redak ugovor može odrediti:
Ovdje jedinica mjere nije dopuna polju količine. Količina 12 bez jedinice ne govori prima li ERP 12 komada, 12 kilograma ili 12 pakiranja. Ako sustavi koriste različite šifrarnike jedinica, ugovor treba sadržavati preslikavanje, vlasnika tog preslikavanja i postupak promjene.
Pretpostavimo da prodajni sustav pošalje redak s artiklom i količinom, ali bez unit_of_measure . Primatelj ne bi trebao stvarati djelomičnu narudžbu niti nagađati jedinicu. Treba odbiti cijeli zapis ili, ako je tako ugovoreno, samo neispravan redak. Izbor ovisi o tome dopušta li proces djelomičnu obradu.
Odgovor primatelja treba sadržavati dovoljno podataka za ispravak bez traženja zapisa u tehničkim logovima:
Poruka ne smije prebacivati poslovnu interpretaciju na korisnika ERP-a. Ako primatelj prihvaća samo potpune narudžbe, to pravilo treba biti vidljivo pošiljatelju prije slanja i provjerljivo tijekom prihvata integracije.
Ograničenja u bazi podataka mogu provjeravati jedinstvenost, obvezna polja i veze među zapisima. PostgreSQL, primjerice, dokumentira ograničenja poput NOT NULL , UNIQUE , PRIMARY KEY i stranih ključeva: PostgreSQL Constraints .
Takve provjere su važne, ali ne zamjenjuju poslovna pravila. Pravilo "kupac smije naručiti samo artikle iz odobrenog asortimana" ili "narudžba s određenim statusom zahtijeva ručnu provjeru" treba definirati zasebno. Ugovor mora navesti gdje se pravilo provodi, tko odlučuje o iznimci i kakav odgovor vraća sustav.
Ovo razdvajanje smanjuje dvije česte pogreške. Prva je pokušaj smještanja svake poslovne odluke u tehničku validaciju. Druga je ostavljanje osnovne kvalitete podataka isključivo korisničkim uputama. Tehničko ograničenje, poslovno pravilo i operativni postupak imaju različite odgovornosti, iako zajedno štite isti proces.
Promjena šifre artikla, jedinice mjere, obveznosti polja ili značenja statusa može promijeniti rezultat procesa bez promjene same veze među sustavima. Zato ugovor treba uključiti postupak promjene:
Korisno je voditi verziju ugovora i vezati je uz poslovni događaj, a ne samo uz tehničko izdanje. Time tim može utvrditi prema kojim su pravilima obrađene starije narudžbe.
Prije prihvata ugovora o poslovnom podatku prođite ovaj popis:
Ako odgovori nisu jasni, korisno je prvo provesti Screening poslovnog procesa . Time se može utvrditi gdje nastaje poslovna odluka, koji sustav vodi službenu transakciju i koje iznimke zahtijevaju radni postupak. Tek tada ugovor o podatku postaje upotrebljiv alat za povezivanje sustava, a ne dokument koji se otvara tek nakon greške.