Integracija ERP in CRM: kaj določiti pred začetkom

Zakaj integracija ni le tehnično vprašanje#

Integracija ERP in CRM sistema povezuje dva sistema, ki v podjetju opravljata različno vlogo. ERP sistem vodi naročila, zaloge, računovodstvo in proizvodnjo, CRM sistem pa vodi stike, priložnosti in prodajni proces. Ko sistema nista povezana, prodajna ekipa ne vidi stanja zaloge ali plačilnega statusa kupca, računovodstvo pa ne vidi konteksta posla, iz katerega je naročilo nastalo. Integracija to razliko odpravi, vendar samo, če je pred začetkom jasno določeno, kateri sistem je izvoren vir za posamezen podatek in kako pogosto se podatki med sistemoma izmenjujejo.

Preden se lotimo razvoja integracije, moramo skupaj z naročnikom določiti obseg povezave: katere entitete se sinhronizirajo, kako pogosto in v katero smer. Brez te odločitve se projekt med izvedbo pogosto obrne, ker razvojna ekipa naleti na primere, ki jih obseg ni predvidel - podvojeni zapisi, nasprotujoči si podatki o istem kupcu ali napačno stanje zaloge, ki do prodajne ekipe pride z zamikom. Jasna opredelitev obsega pred začetkom skrajša število popravkov med razvojem in zmanjša tveganje, da bo integracija v produkciji delovala drugače, kot je bilo pričakovano.

Za naročnika to pomeni, da je treba integracijo obravnavati kot projekt, ne kot tehnično nastavitev med dvema sistemoma. Odločitve o lastništvu podatkov, pogostosti sinhronizacije in ravnanju ob napakah sprejemajo poslovni uporabniki obeh sistemov, ne le informacijski oddelek. Epix in specialistična partnerska mreža lahko projektno vodenje in usklajevanje teh odločitev prevzameta, vendar mora naročnik zagotoviti dostop do ljudi, ki poznajo dejansko rabo obeh sistemov v vsakdanjem delu, saj brez njihove udeležbe obsega integracije ni mogoče zanesljivo določiti.

Popis obstoječih sistemov in podatkov#

Prvi korak je popis obstoječih sistemov: katera različica ERP in CRM sistema je v uporabi, kateri moduli so aktivni in ali imata sistema odprt API ali je dostop mogoč samo prek uvoza datotek. Od tega je odvisno, ali je integracija mogoča v realnem času ali le v paketih, na primer enkrat na uro ali enkrat dnevno. Če eden od sistemov nima uporabnega API-ja, je treba to ugotoviti pred začetkom razvoja, ne šele med njim, saj to bistveno spremeni arhitekturo celotne rešitve.

Poleg tehničnega popisa je treba pregledati tudi stanje podatkov, ki bodo predmet sinhronizacije. Podvojeni zapisi, nepopolna polja in neusklajene šifre izdelkov ali kupcev se z integracijo ne odpravijo - integracija jih le prenese iz enega sistema v drugega, pogosto v večjem obsegu in hitreje, kot bi to opazili ob ročnem delu. Zato pred začetkom pregledamo, katere entitete so predmet integracije, kateri sistem je zanje izvoren vir, kakšna je trenutna kakovost podatkov in kateri identifikator povezuje isti zapis med sistemoma.

Popis pokaže tudi, ali gre za nov sistem ali za prevzem obstoječe, delno razvite integracije. V slednjem primeru pred nadaljevanjem pregledamo izvorno kodo, arhitekturo in dokumentacijo, saj brez tega ni mogoče zanesljivo oceniti, kaj v obstoječi rešitvi deluje in kaj je treba popraviti ali zgraditi na novo. Rezultat popisa je osnova za oceno obsega dela in za nadaljnje odločitve o tem, kateri podatki se sinhronizirajo in v katero smer.

• katere entitete (kupci, izdelki, naročila, računi, priložnosti) so predmet integracije
• kateri sistem je izvoren vir za posamezno entiteto
• kakšna je trenutna kakovost podatkov in kje so podvojeni zapisi
• kateri identifikator povezuje isti zapis med obema sistemoma
• kateri obstoječi API-ji in dostopi so že na voljo

Katere podatke sinhronizirati in v katero smer#

Ko je popis končan, se določi, kateri podatki se dejansko prenašajo med sistemoma. Ni nujno, da se sinhronizirajo vsa polja - pogosto je smiselno prenašati le tista, ki jih druga stran resnično uporablja pri vsakdanjem delu. Preveč podatkov v integraciji pomeni več možnosti za konflikt in daljši čas razvoja, premalo podatkov pa pomeni, da uporabniki še vedno ročno preverjajo informacije v drugem sistemu, kar zmanjša dejansko korist integracije za prodajno in računovodsko ekipo.

Smer sinhronizacije je odvisna od tega, kje podatek dejansko nastane. Kupec običajno nastane v CRM sistemu med prodajnim procesom in se od tam prenese v ERP sistem ob izstavitvi naročila. Zaloga in plačilni status po drugi strani nastajata v ERP sistemu in se od tam prenašata v CRM sistem, da ju prodajna ekipa vidi brez preklapljanja med sistemi. Enosmerna sinhronizacija je enostavnejša in bolj predvidljiva, dvosmerna sinhronizacija pa zahteva jasna pravila za primere, ko se isti zapis spremeni na obeh straneh hkrati, kar je pogost vir napak.

Pri določanju smeri in obsega sinhronizacije skupaj z naročnikom odločamo o več vprašanjih hkrati, saj vsaka odločitev vpliva na arhitekturo integracije in na to, koliko avtomatizacije je mogoče vgraditi brez tveganja za napačne podatke. Ta vprašanja rešujemo pred začetkom razvoja, ker je poznejše spreminjanje smeri sinhronizacije pogosto povezano s ponovnim delom na že zgrajenih delih integracije. Med drugim določimo:

Te odločitve neposredno vplivajo na arhitekturo integracije in na obseg avtomatizacije, ki jo je mogoče vgraditi brez tveganja za napačne podatke. Jasno določena pravila o smeri sinhronizacije in reševanju konfliktov pomenijo manj ročnega usklajevanja po uvedbi v produkcijo in manj primerov, ko podatek v enem sistemu ne ustreza podatku v drugem, kar bi sicer sprožalo dodatna vprašanja prodajne in računovodske ekipe.

• katera entiteta se sinhronizira enosmerno in katera dvosmerno
• kaj se zgodi, če se zapis spremeni v obeh sistemih hkrati
• ali se brisanje zapisa v enem sistemu prenese v drugega
• kako se obravnavajo napake pri prenosu (ponovni poskus, obvestilo, ročna potrditev)
• kje se hrani zapis o tem, kaj je bilo preneseno in kdaj

Kdo je lastnik podatka in kaj se zgodi ob konfliktu#

Lastništvo podatka pomeni, kateri sistem velja za avtoritativni vir za posamezno polje. Če je na primer naslov kupca lastniško polje CRM sistema, potem sprememba tega polja v ERP sistemu ne sme samodejno prepisati vrednosti nazaj v CRM sistem, temveč mora sinhronizacija to zaznati in sprožiti opozorilo. Brez tega pravila lahko pride do situacije, ko se isti podatek v neskončni zanki prepisuje med sistemoma, uporabniki na obeh straneh pa vidijo različne vrednosti, ne da bi vedeli, katera je pravilna.

Konflikti nastanejo, kadar uporabnik spremeni isti zapis v obeh sistemih, preden se sinhronizacija izvede. Pravilo za razreševanje konfliktov mora biti določeno vnaprej: ali velja zadnja sprememba, ali velja vrednost lastniškega sistema, ali se konflikt prikaže uporabniku v ročno odobritev. Ta odločitev je poslovna, ne tehnična, zato jo morajo potrditi ljudje, ki oba sistema uporabljajo pri vsakdanjem delu, ne le razvojna ekipa, ki integracijo gradi.

Za naročnika to pomeni, da mora pred začetkom razvoja določiti odgovorno osebo ali skupino, ki lahko med projektom sprejema take odločitve. Če teh odločitev ni mogoče sprejeti hitro, se razvoj integracije ustavlja prav na točkah, kjer bi sicer lahko nemoteno napredoval, kar podaljša celoten projekt. Zato v začetni fazi projekta skupaj z naročnikom določimo, kdo te odločitve sprejema, in ta dogovor zapišemo, preden se razvoj integracijske logike sploh začne.

Varnost, dostopi in revizijska sled#

Integracija ERP in CRM sistema pomeni, da API dostopi enega sistema segajo v drugega, zato je treba pred začetkom določiti, kdo ima dostop do integracijskih poverilnic, kako so te shranjene in kdo lahko spreminja pravila sinhronizacije. To je še posebej pomembno, kadar gre za regulirano panogo ali javni sektor, kjer so zahteve po reviziji dostopa in varnosti podatkov strožje kot v drugih okoljih in kjer mora biti vsaka sprememba integracijske logike sledljiva.

Revizijska sled pomeni, da je za vsak prenesen zapis mogoče videti, kdaj je bil prenesen, iz katerega sistema in kaj je spremembo sprožilo. Brez revizijske sledi je težko ugotoviti vzrok napake, ko se podatek v enem sistemu razlikuje od podatka v drugem, in še težje dokazati skladnost poslovanja ob morebitnem nadzoru ali reviziji, kar je pri javnem sektorju in reguliranih panogah pogosta zahteva. Pred začetkom integracije zato skupaj z naročnikom določimo dostope, ločevanje okolij in ravnanje z dnevniki prenosov.

Te odločitve niso enkratne, saj morajo veljati tudi po uvedbi, ko se integracija vzdržuje in nadgrajuje skozi čas. Zato jih vključimo v dokumentacijo, ki jo naročnik prejme ob primopredaji, skupaj z dostopi in gesli, izvorna koda in podatki integracije pa ostanejo last naročnika. Tak dogovor naročniku omogoča, da lahko podporo po uvedbi kadar koli prevzame sam ali jo prenese na drugega izvajalca, ne da bi bil odvisen izključno od ene ekipe.

• kdo ima dostop do integracijskih poverilnic in API ključev
• kako so ločena razvojna, testna in produkcijska okolja
• da testno okolje ne uporablja pravih osebnih podatkov naročnika
• kako dolgo se hranijo dnevniki prenosov in kdo ima dostop do njih
• kdo je odgovoren za odziv, če pride do varnostnega incidenta pri prenosu podatkov

Testiranje integracije pred uvedbo v produkcijo#

Integracija med dvema sistemoma se ne testira enako kot posamezna aplikacija, ker napaka na eni strani lahko poškoduje podatke na drugi. Zato pred uvedbo pripravimo testne scenarije, ki pokrijejo tipične prenose podatkov, robne primere in namerno sprožene napake, na primer nedosegljiv API, nepopoln zapis ali podvojen identifikator, ki bi sicer v produkciji ostal neopažen.

Testiranje poteka v ločenem testnem okolju, kjer ne uporabljamo pravih osebnih podatkov naročnika. To pomeni, da je treba pred testiranjem pripraviti testne podatke, ki dovolj verno posnemajo strukturo produkcijskih podatkov, ne da bi vsebovali dejanske osebne ali poslovne informacije kupcev. Ločevanje okolij velja skozi celoten razvoj, ne le v fazi testiranja pred uvedbo.

Testni nabor za integracijo ERP in CRM sistema je odvisen od obsega povezave, vključuje pa praviloma več ravni preverjanja, od ročnega pregleda posameznih zapisov do avtomatiziranega ponavljanja celotnih sinhronizacij. Namen je odkriti napake, preden vplivajo na prave podatke v produkciji, in preveriti, da integracija ustrezno obravnava tudi primere, ki se v vsakdanjem delu zgodijo redko, a imajo velik vpliv, če ostanejo neopažene. Testni nabor običajno vključuje:

Po potrebi vključimo neodvisen QA, ločen od razvojne ekipe, ki je integracijo zgradila. To je smiselno predvsem pri integracijah, ki vplivajo na finančne podatke ali na podatke, pomembne za skladnost poslovanja, kjer napaka po uvedbi v produkcijo prizadene več oddelkov hkrati, ne le enega uporabnika. V takih primerih neodvisno testiranje pred prehodom v produkcijo zmanjša tveganje, da bi napako odkrili šele, ko že vpliva na poslovanje.

• ročno preverjanje prenosa posameznih zapisov med sistemoma
• avtomatizirano testiranje ponavljajočih se sinhronizacij
• API testiranje odzivov ob napakah in časovnih zamikih
• regresijsko testiranje po vsaki spremembi integracijske logike
• prevzemno testiranje po vnaprej dogovorjenih merilih pred prehodom v produkcijo

Kaj vključiti v načrt uvedbe#

Uvedba integracije v produkcijsko okolje je ločen korak od razvoja in testiranja. Načrt uvedbe določa, kdaj se sinhronizacija prvič zažene, kako se obravnava obstoječa razlika med podatki v obeh sistemih pred prvim zagonom in kdo spremlja delovanje integracije v prvih dneh po uvedbi, ko je verjetnost nepredvidenih primerov največja. Ta korak zato načrtujemo ločeno od razvoja, čeprav ga izvaja ista projektna ekipa.

Prvi zagon pogosto zahteva enkratno uskladitev obstoječih podatkov, preden se vklopi sprotna sinhronizacija. Ta korak je treba načrtovati ločeno, ker gre za enkratni prenos večje količine zapisov, ki ga je smiselno preveriti ročno, preden sistem preide na samodejno delovanje, saj morebitna napaka pri prvem usklajevanju podatkov vpliva na vse poznejše sinhronizacije.

Za naročnika načrt uvedbe pomeni jasnost o tem, kaj se zgodi na dan prehoda, kdo je dosegljiv, če pride do napake, in kako se ukrepa, če je integracijo treba začasno ustaviti. Te odločitve uskladimo skupaj z naročnikom pred datumom uvedbe, ne med njo, saj se s tem izognemo improvizaciji v trenutku, ko je sistem že v uporabi.

Podpora in vzdrževanje po uvedbi#

Po uvedbi integracija ostaja del sistema, ki ga je treba spremljati. Manjša sprememba v enem od povezanih sistemov, na primer nova različica ali sprememba polja, lahko prekine sinhronizacijo, zato je smiselno vnaprej dogovoriti, kdo spremlja delovanje integracije in kdo odpravlja napake, če do njih pride, ter kako se posamezna vrsta napake obravnava.

V okviru podpore delujemo po razredih glede na vpliv napake na poslovanje: izpad integracije, ko sistem ali ključni del ne deluje, obravnavamo prednostno, motnjo posamezne funkcije po prednosti, dogovorjeni v pogodbi o podpori, manjše napake brez vpliva na poslovanje pa uvrstimo v naslednjo objavo. Zahteve za spremembo ali nadgradnjo integracije ocenimo posebej in uskladimo termin izvedbe z naročnikom.

Naročnik obdrži lastništvo izvorne kode in podatkov integracije, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta. To pomeni, da lahko podporo po uvedbi prevzame naročnik sam, jo v celoti prepusti Epixu in specialistični partnerski mreži ali izbere kombinacijo, kjer določene naloge ostanejo interne, druge pa se izvajajo zunaj podjetja.

Kako k projektu pristopi Epix#

Pri integraciji ERP in CRM sistema lahko prevzamemo celoten projekt, od popisa obstoječih sistemov do uvedbe in podpore, ali samo posamezen sklop, na primer razvoj integracijske plasti, medtem ko naročnik sam vodi ostale dele projekta. Pri večjih projektih določimo projektnega vodjo, odgovornosti posameznih ekip, roke izvedbe in način komunikacije ter poročanja skozi celoten projekt.

Znotraj Epixa in specialistične partnerske mreže gradimo in povezujemo ERP, CRM, DMS in ECM sisteme prek API-jev. Projektne ekipe sestavimo glede na zahteve posameznega projekta, od solution architectov, ki določijo arhitekturo integracije, do QA inženirjev, ki pripravijo in izvedejo testne scenarije pred uvedbo v produkcijsko okolje. Enak pristop uporabimo tudi, kadar je treba integracijo po uvedbi še naprej razvijati ali prilagajati spremembam v enem od povezanih sistemov.

Prevzamemo lahko tudi obstoječo ali nedokončano integracijo, potem ko pregledamo izvorno kodo, arhitekturo, infrastrukturo in stanje podatkov. Cena projekta ni pavšalna, temveč se določi po pregledu zahtev in obsega, zato pred začetkom predlagamo krajšo analizo, ki obseg razdeli na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno od drugih. Tak pristop naročniku omogoča odločanje po korakih, ne da bi moral vnaprej potrditi celoten projekt.