ERP a CRM: najprv pravidlá údajov, potom prepojenie
API je iba jedna časť integrácie. Potrebujete vedieť, ktorý systém rozhoduje, čo sa prenáša a ako sa opraví neúspešný prenos.
Názvy systémov ešte neurčujú zadanie
Požiadavka na prepojenie ERP a CRM často vznikne pri ručnom prepisovaní objednávok alebo zákazníckych údajov. Skôr než vyberiete spôsob prenosu, prejdite konkrétny proces. Kto vytvorí kontakt? Kedy z obchodnej príležitosti vzniká objednávka? Ktorý údaj má zákazník vidieť v portáli?
Z takéhoto rozhovoru vznikne mapa udalostí a údajov. Pomôže oddeliť to, čo sa má prenášať automaticky, od rozhodnutia človeka. Preniesť každý dostupný údaj oboma smermi môže vytvoriť ďalšie problémy, ak nikto neurčil pravidlá jeho aktualizácie.
Každý údaj potrebuje vlastníka
Ten istý zákazník môže mať v oboch systémoch rozdielny názov, kontaktnú osobu alebo adresu. Pri návrhu určte, ktorý systém je pre konkrétne pole rozhodujúci. Fakturačné údaje sa môžu spravovať inde než obchodné poznámky. Pravidlo potrebuje poznať aj tím, ktorý bude riešiť opravu.
Prepojenie musí vedieť rozpoznať ten istý záznam. Zhoda e-mailu či názvu firmy nemusí byť spoľahlivým identifikátorom. Dohodnite mapovanie záznamov, postup pri duplicite a správanie pri zmazaní. Sú to procesné otázky, ktoré nemožno vyriešiť iba technickým prístupom k API.
Rozhodnite, aká čerstvá má byť informácia
Nie všetky údaje treba preniesť okamžite. Dostupnosť produktu pri objednávke môže mať iné požiadavky než denný súhrn. Frekvencia prenosu vplýva na zaťaženie, cenu prevádzky aj správanie pri výpadku. Dohodnite ju podľa toho, ako sa s informáciou pracuje.
Používateľ má vedieť, čo zobrazený stav znamená. Ak sa údaje aktualizujú v intervaloch, rozhranie môže ukázať čas poslednej úspešnej aktualizácie. Pri kritickom kroku môže byť potrebné čerstvé overenie. Tak sa technické rozhodnutie premietne do zrozumiteľného pracovného postupu.
Pripravte cestu pri chybe
Prepojenie treba skúšať aj pri nedostupnom systéme, neplatnom údaji alebo prerušenom prenose. Ak opakujete tú istú požiadavku, nesmie bez kontroly vytvoriť ďalšiu objednávku. Návrh preto potrebuje identifikáciu prenášaných úloh a pravidlá opakovania.
Záznam chyby má ukázať, čo sa nepodarilo a kto môže pokračovať. Pri procese s viacerými systémami treba určiť aj správanie, keď jedna časť uspeje a ďalšia zlyhá. Niekedy možno krok vrátiť, inokedy ho musí preveriť zodpovedný človek. Tento postup patrí do zadania aj testovania.
Ukážkový tok: schválená objednávka
Predstavte si, že obchodník schváli objednávku v CRM a interný systém má vytvoriť zodpovedajúci záznam. Prepojenie potrebuje vedieť, ktoré údaje sú povinné a ako identifikuje zákazníka. Ak interný systém objednávku prijme, ale potvrdenie sa nevráti, ďalší pokus musí najprv rozpoznať už vykonaný krok.
Tento ilustračný príklad ukazuje, prečo nestačí otestovať úspešnú odpoveď API. Skúška potrebuje aj prerušenie spojenia, nesprávny identifikátor a opakované doručenie. Používateľ zároveň potrebuje rozlíšiť stav čakajúci na spracovanie od stavu, ktorý vyžaduje opravu údajov.
Začnite jedným celým tokom
Ako prvý rozsah vyberte uzavretú cestu, napríklad prenos schválenej objednávky a spätné zobrazenie jej stavu. Získate konkrétny výsledok a overíte mapovanie, oprávnenia aj chyby. Potom môžete doplniť ďalšie údaje a udalosti.
Pri odovzdaní si vypýtajte opis pravidiel, prehľad rozhraní a postup riešenia výpadku. Integrácia bude potrebovať údržbu pri zmenách systémov. Dohodnutá zodpovednosť za prenos je rovnako dôležitá ako jeho prvé úspešné spustenie.
Od témy ku konkrétnemu riešeniu.
Súvisiaca realizácia: FaxCopy a.s.