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 або webhooks, як праходзіць аўтэнтыфікацыя доступу, ці ёсць тэставае асяроддзе і якія існуюць абмежаванні. У знешняга пастаўшчыка запытайце дакументацыю, прыклады запытаў і правілы ўнясення змяненняў у інтэрфейс.

3. 03
   Вызначэнне даных і адказнасці

   Супастаўце палі: нумар замовы, SKU, колькасць, цана, ПДВ, кліент, адрас і статус. Вызначце, якая сістэма можа змяняць кожнае значэнне і што адбываецца пры разыходжанні.

4. 04
   Стварэнне першага невялікага сцэнарыя

   Пачніце з аднаго патоку, напрыклад з перадачы новай замовы ў ERP або новага ліда ў CRM. Не ўключайце адначасова ўсе апавяшчэнні, справаздачы і выключэнні. Так лягчэй зразумець, ці правільная логіка.

5. 05
   Тэставанне на рэальных нестандартных выпадках

   Пратэстуйце адхілены плацёж, адсутнасць тавару, памылковы нумар тэлефона, вернутую замову, выдалены прадукт, разарванае злучэнне і паўторны webhook. Менавіта такія выпадкі паказваюць, ці гатовая інтэграцыя да працы, а не толькі ці працуе яна ў дэманстрацыі.

6. 06
   Маніторынг і перадача камандзе

   Забяспечце журнал запытаў, апавяшчэнне пра памылку і магчымасць паўторнай апрацоўкі. Каманда павінна бачыць, якая замова заблакіраваная, чаму яна заблакіраваная і як яе выправіць без умяшання ў базу даных.

Што часцей за ўсё ідзе не так?

Адзін запыт выконваецца двойчы

Webhook можа быць адпраўлены паўторна, калі атрымальнік не пацвердзіць яго своечасова. Таму кожная падзея павінна мець унікальны ідэнтыфікатар, а сістэма — правяраць, ці была яна ўжо апрацавана. Гэта асабліва важна для плацяжоў, рахункаў-фактур і адпраўкі пасылак.

Адна з сістэм недаступная

Калі ERP не адказвае, заказ не павінен знікнуць. Яго трэба захаваць у чарзе, выканаць кантраляваныя паўторныя спробы і паведаміць супрацоўніку, калі праблема не знікне.

Даныя маюць розную структуру

Адна сістэма можа выкарыстоўваць асобныя палі для імя і прозвішча, а другая — адно поле для імя. SKU, адзінкі вымярэння, стаўкі ПДВ, гадзінныя паясы і адрасы таксама часта адрозніваюцца. Гэтыя пераўтварэнні павінны быць часткай інтэграцыі, а не пакідацца на супрацоўнікаў.

Доступ занадта шырокі

API-ключы і паролі нельга захоўваць у кодзе або адпраўляць па электроннай пошце. Выкарыстоўвайце зашыфраванае злучэнне, асобныя доступы для тэставага і працоўнага асяроддзяў, мінімальна неабходныя правы і працэдуру замены ключоў. Пры працы з персанальнымі данымі таксама трэба перагледзець тэрміны захоўвання і доступы супрацоўнікаў.

Калі выбраць гатовы інструмент, а калі — індывідуальную распрацоўку?

Make або Zapier зручныя для адпраўкі апавяшчэння, стварэння задачы або перадачы простай формы. Гэта добры спосаб праверыць ідэю і аўтаматызаваць невялікі працэс без працяглага праекта. Але пры большым аб'ёме трэба ўлічыць штомесячныя плацяжы, ліміты аперацый і залежнасць ад знешняй платформы.

Гатовы плагін падыходзіць, калі ў крамы і бухгалтарскай або кур'ерскай сістэмы ёсць дакладна падтрыманы сцэнарый. Калі вы змяняеце логіку заказаў, дадаеце спецыяльныя цэны для кампаній або працуеце з некалькімі складамі, плагін можа аказацца занадта абмежаваным.

Індывідуальная інтэграцыя мае сэнс, калі памылка азначае страчаны продаж, няправільныя рэшткі або праблемны рахунак-фактуру. Спачатку яна каштуе даражэй, але дазваляе рэалізаваць уласную логіку, кантраляваць даныя і лепш аднаўляцца пасля памылак. Калі патрэбныя CRM-працэсы, можна таксама разгледзець CRM-сістэму на заказ, каб формы не былі раскіданыя паміж электроннай поштай, табліцамі і чатамі.

Як ацаніць, ці паспяхова прайшла інтэграцыя?

Вызначце вымяральныя крытэрыі яшчэ да распрацоўкі. Напрыклад, усе новыя заказы павінны трапляць у ERP, кожны лід павінен мець адказнага, кожная памылка павінна быць бачная супрацоўніку, а ніводны плацёж не павінен ствараць два рахункі-фактуры. Вымярайце не толькі тое, ці «дастаўлены» даныя, але і тое, ці завяршаецца працэс правільна.

Для больш складаных працэсаў можна пачаць з гатовай мадэлі і адаптаваць яе. У дэма-версіі ERP-сістэмы у адным асяроддзі можна ўбачыць кантакты, праекты, задачы, рахункі-фактуры, каляндар і справаздачы. Дэма не замяняе аналіз вашых сістэм, але дапамагае абмеркаваць, якія аб'екты, ролі і аперацыі вам сапраўды патрэбныя.

Часта задаваныя пытанні

У чым розніца паміж API і webhook?

Пры выкарыстанні API ваша сістэма адпраўляе запыт, каб атрымаць або адправіць даныя. Пры выкарыстанні webhook іншая сістэма аўтаматычна паведамляе вам, калі адбываецца падзея, напрыклад новы заказ або паспяховы плацёж.

Ці можна інтэграваць старую ERP без API?

Часам так — праз імпарт і экспарт CSV, доступ да базы даных, гатовы канектар або прамежкавы модуль. Звычайна гэта больш абмежаваны падыход у параўнанні з API і патрабуе асаблівай увагі да дублявання, бяспекі і графіка абмену.

Колькі часу займае API-інтэграцыя?

Просты сцэнарый паміж сістэмамі з добрай дакументацыяй можна рэалізаваць у рамках кароткага праекта. Тэрмін павялічваецца пры інтэграцыі некалькіх сістэм, адсутнасці дакументацыі, спецыфічных правілах, міграцыі старых даных і неабходнасці адміністрацыйнай панэлі, журнала і паўторнай апрацоўкі.

Хто павінен падтрымліваць інтэграцыю пасля запуску?

З вашага боку павінен быць прызначаны адказны, а з боку распрацоўшчыка або пастаўшчыка — тэхнічная падтрымка. Знешняя сістэма можа змяніць версію API, поле або спосаб аўтэнтыфікацыі, таму маніторынг і апавяшчэнні — гэта частка падтрымкі, а не дадатковая опцыя.