API интеграција: како да повежете своје пословне системе

Шта API и webhooks заправо раде?

Замислите онлајн продавницу, складиште и рачуноводствени програм као три одвојене канцеларије. Ако нису повезани, запослени преписује поруџбину из једног система у други, проверава стање телефоном или у Excel-у, а затим поново уноси податке за фактуру.

API је договорени начин да један систем затражи или пошаље информације другом систему. Онлајн продавница може да затражи стање одређеног производа, пошаље нову поруџбину или затражи статус пошиљке. Систему коме су информације потребне започиње комуникацију.

Webhook функционише у супротном смеру. Када се догоди неки догађај, систем шаље обавештење на унапред задату адресу. На пример, након успешног плаћања платни оператер шаље webhook вашем софтверу, који мења статус поруџбине и може да покрене следећи корак.

Које процесе вреди прво повезати?

Не почињите са намером да повежете све. Изаберите процес који се често понавља, успорава тим или ствара скупе грешке. Обично је то кретање поруџбине, контакт са клијентом, стање залиха или плаћање.

Онлајн продавница, складиште и ERP

Када стигне нова поруџбина, продавница шаље производе, количине, податке о клијенту и начин плаћања ERP систему. ERP враћа стање залиха и статус поруџбине, а када се стање у складишту промени, продавница добија ажуриране количине. Тако је мањи ризик да продате робу која је већ распродата.

Унапред треба договорити који је систем водећи за цену, стање залиха, производ и клијента. Ако и продавница и ERP могу да мењају исту вредност без јасног правила, интеграција ће само брже преносити конфликт.

Сајт, CRM и продајни тим

Форма за упит на сајту може да креира lead у CRM-у са извором, услугом, бројем телефона и поруком. На основу тих података креира се задатак за продавца, клијенту се шаље потврда или се покреће другачији процес за хитне и стандардне упите.

Овде најчешћи проблем није недостатак API-ја, већ нејасна дефиниција lead-а. Треба да знате када се креира нови контакт, шта се дешава код поновног упита и ко добија задатак. Ако ова правила нису описана, добићете дуплиране клијенте и неравномерно распоређене упите.

Плаћања, фактурисање и обавештења

Успешно плаћање може да промени статус поруџбине у „плаћено“, пошаље податке ERP систему и покрене креирање фактуре. Одвојено се може послати имејл или порука клијенту. Важно је да се фактура не креира поново ако платни оператер исто обавештење пошаље више пута.

Сајт, CRM и телефонија

При долазном позиву телефонски систем може да проследи број CRM-у како би се отворила картица клијента. Након разговора систем може да забележи исход, задатак или белешку. Ово је посебно корисно када продаја и корисничка подршка обрађују велики број долазних упита.

За сложеније процесе помаже ERP изграђен око вашег стварног начина рада. На пример, ERP систем по мери може да обједини складиште, продају, фактуре, улоге и извештаје, уместо да повезује десетине некомпатибилних табела.

Које су опције и колико коштају?

Цена зависи од броја система, доступне документације, броја објеката за синхронизацију, правила за податке и потребе за админ панелом и мониторингом. Наведени распони су оквирни за Бугарску у еврима. Прецена процена могућа је након прегледа API документације и стварног процеса.

Код готовог конектора, ниска цена не значи да је посао завршен. Треба проверити поља, пореска правила, дуплирање, заокруживање, одбијена плаћања и повраћаје. Код прилагођене интеграције буџет највише зависи од броја сценарија и изузетака, а не од самог броја система.

Ако је главни проблем продавница и њене операције, почните са израдом онлајн продавнице, при чему се везе са системима за плаћање, курирским службама и интерним системима планирају од почетка. Ако већ имате функционалну продавницу, интеграција може да се изгради око њених доступних API могућности.

Како изгледа поуздана интеграција?

Добра интеграција није само да „два система разговарају“. Она описује шта се дешава у нормалном сценарију, при кашњењу, код неисправних података и при поновном слању. Процес обично пролази кроз следеће кораке.

1. 01
   Описивање процеса

   Забележите шта се данас дешава од почетка до краја. Ко уноси поруџбину, где се проверава стање залиха, када се издаје фактура и ко сазнаје за проблем? Овде се виде ручне радње и места на којима се губе информације.

2. 02
   Провера система и документације

   Проверите да ли сваки систем има API или вебхукове, како се потврђује приступ, да ли постоји тестно окружење и која су ограничења. Код спољног добављача затражите документацију, примере захтева и правила за промене интерфејса.

3. 03
   Одређивање података и одговорности

   Успоставите мапирање поља: број поруџбине, SKU, количина, цена, ПДВ, клијент, адреса и статус. Одредите који систем може да мења сваку вредност и шта се дешава у случају неслагања.

4. 04
   Изградња малог првог сценарија

   Почните са једним током, на пример новом поруџбином ка ERP-у или новим lead-ом ка CRM-у. Немојте истовремено укључивати сва обавештења, извештаје и изузетке. Тако је лакше утврдити да ли је логика исправна.

5. 05
   Тестирање са стварним граничним случајевима

   Тестирајте одбијено плаћање, недостатак залиха, погрешан број телефона, враћену поруџбину, обрисан производ, прекинуту везу и поновљени вебхук. Управо ови случајеви показују да ли је интеграција спремна за рад, а не само да ли функционише у демонстрацији.

6. 06
   Надзор и предаја тиму

   Обезбедите евиденцију захтева, обавештење о грешци и начин за поновну обраду. Тим мора да види која је поруџбина блокирана, зашто је блокирана и како да је исправи без интервенције у бази података.

Шта најчешће пође по злу?

Један захтев се извршава два пута

Webhook може бити поново послат ако прималац не потврди пријем на време. Зато сваки догађај треба да има јединствени идентификатор, а систем треба да провери да ли је већ обрађен. Ово је посебно важно за плаћања, фактуре и слање пошиљки.

Један од система није доступан

Ако ERP не одговара, поруџбина не сме да нестане. Треба је уписати у ред, извршити контролисане поновне покушаје и послати обавештење одговорној особи ако се проблем настави.

Подаци имају различиту структуру

Један систем може да користи одвојена поља за име и презиме, а други једно поље за име. SKU, мерне јединице, стопе ПДВ-а, временске зоне и адресе такође се често разликују. Ова пресликавања треба да буду део интеграције, а не да се препуштају запосленима.

Приступ је превише широк

API кључеви и лозинке не смеју да се уписују у код или шаљу имејлом. Користите шифровану везу, одвојене приступе за тестно и продукционо окружење, минимална овлашћења и процедуру за промену кључева. Код личних података треба проверити и рокове чувања, као и приступе запослених.

Када изабрати готов алат, а када развој по мери?

Make или Zapier су практични за обавештење, креирање задатка или пренос једноставног формулара. Они су добар начин да проверите идеју и аутоматизујете мали процес без дугог пројекта. Међутим, месечне накнаде, ограничења броја операција и зависност од спољне платформе треба узети у обзир код већег обима.

Готов додатак је одговарајући када продавница и рачуноводствени или курирски систем имају тачно подржан сценарио. Ако промените логику поруџбина, додате посебне цене за фирме или радите са више складишта, додатак се може показати као ограничење.

Интеграција по мери има смисла када грешка значи пропуштену продају, нетачно стање залиха или проблематичну фактуру. У почетку је скупља, али омогућава сопствену логику, контролу над подацима и бољи опоравак од грешака. Ако су вам потребни CRM процеси, можете размотрити и CRM систем по мери, уместо да се формулари расипају између имејла, табела и четова.

Како да процените да ли је интеграција успешна?

Поставите мерљиве критеријуме пре развоја. На пример, да све нове поруџбине стижу у ERP, да сваки lead има одговорну особу, да свака грешка буде видљива запосленом и да ниједно плаћање не креира две фактуре. Не мерите само да ли су подаци „стигли“, већ да ли се процес правилно завршава.

Код сложенијих процеса можете почети од готовог модела и прилагодити га. У демо ERP систему у једном окружењу можете видети контакте, пројекте, задатке, фактуре, календар и извештаје. Демо не замењује анализу ваших система, али помаже да размотрите који су вам објекти, улоге и операције заиста потребни.

Често постављана питања

Која је разлика између API-ја и webhook-а?

Код API-ја ваш систем шаље захтев да би примио или послао податке. Код webhook-а вас други систем аутоматски обавештава када се догоди догађај, на пример нова поруџбина или успешно плаћање.

Да ли могу да интегришем стари ERP без API-ја?

Понекад да — путем увоза и извоза CSV-а, приступа бази података, готовог конектора или посредничког модула. То је обично ограниченије од API-ја и захтева посебну пажњу посвећену дуплирању, безбедности и распореду размене података.

Колико траје једна API интеграција?

Једноставан сценарио између добро документованих система може да се реализује у кратком пројекту. Рок се продужава када је укључено више система, када документација недостаје, постоје специфична правила, треба мигрирати старе податке или су потребни админ панел, дневник и поновна обрада.

Ко треба да одржава интеграцију након пуштања у рад?

Са ваше стране треба да постоји конкретна одговорна особа, а са стране програмера или добављача техничка подршка. Спољни систем може да промени верзију API-ја, поље или начин аутентификације, па су мониторинг и обавештења део одржавања, а не додатак.