Jak propojit firemní systémy bez drahých chyb

Když se objednávka z e-shopu přepisuje do účetnictví, obchodník hledá stav zákazníka ve třech aplikacích a sklad neví o změně až do dalšího rána, problém není v lidech. Problém je v tom, že systémy netvoří jeden provozní celek. Otázka, jak propojit firemní systémy, proto nezačíná výběrem integračního nástroje. Začíná tím, jaké rozhodnutí, proces nebo zákaznický krok má po propojení fungovat lépe.

Dobře navržená integrace neznamená, že je každý systém spojený s každým. Znamená, že správná data dorazí ve správný čas na správné místo a že je jasné, kdo za ně odpovídá. To zní jednoduše, ale právě v této disciplíně vznikají rozdíly mezi řešením, které firmě uleví, a dalším zdrojem provozních incidentů.

Nejdřív popište proces, až potom vybírejte technologii

Firmy často začnou seznamem aplikací: CRM, ERP, účetnictví, sklad, zákaznický portál, helpdesk. Takový seznam je užitečný, ale sám o sobě neříká, co integrovat jako první. Rozhodující je konkrétní tok práce.

Vezměme si B2B firmu, která přijme poptávku, připraví nabídku, uzavře objednávku, zajistí dodání a vystaví fakturu. V každém kroku vznikají data: kontakt, cena, položky, termín, stav zakázky nebo platební informace. Pokud se některý údaj přepisuje ručně, může vzniknout chyba. Pokud se nepředává vůbec, lidé jej dohledávají po telefonu nebo v tabulkách.

Nakreslete proto současný proces od prvního vstupu po výsledek. U každého kroku si položte tři otázky: odkud data přicházejí, kdo je smí změnit a co se stane, když se předání nepovede. Tím rychle odlišíte integrace, které šetří reálnou práci, od těch, které pouze vypadají dobře v architektuře.

Nejlepší první kandidáti bývají procesy s vysokým objemem, opakovaným ručním přepisem nebo citelnou cenou chyby. Například synchronizace objednávek do interního systému může mít větší dopad než automatické přenesení poznámek z CRM, i když druhá varianta vypadá jednodušeji.

Jak propojit firemní systémy bez zmatku v datech

Základní pravidlo zní: jeden údaj musí mít jeden hlavní zdroj pravdy. Neznamená to, že existuje jen v jednom systému. Znamená to, že je předem rozhodnuto, kde vzniká a odkud se smí aktualizovat.

Zákazník může být například založen v CRM, faktura v účetním systému a stav zásilky v logistickém systému. Pokud ale stejnou e-mailovou adresu může bez pravidel upravit několik aplikací, dříve nebo později se jejich stav rozjede. Integrace pak není příčinou problému, pouze jej rychleji rozšíří.

Před vývojem je dobré stanovit datová pravidla přímo a bez neurčitých formulací. Který systém zakládá nový kontakt? Co se má stát při duplicitě? Přepisuje změna adresy data všude, nebo se jen předá ke schválení? Má být smazání záznamu propagováno do dalších systémů? U citlivých dat může být správná odpověď, že se nepřenášejí vůbec.

Stejně podstatné je rozlišit, zda má být přenos okamžitý, nebo dávkový. Stav platby či dostupnost zboží mohou vyžadovat aktualizaci během sekund. Přehledové reporty obvykle snesou noční zpracování. Okamžité propojení je technicky náročnější na dostupnost, opakované zpracování a řešení výpadků. Nemá smysl ho stavět tam, kde firma reálně nepotřebuje data v reálném čase.

API, exporty a integrační vrstva nejsou totéž

Pokud oba systémy nabízejí kvalitní API, je přímé napojení často rozumný začátek. Je rychlé na pochopení a pro jeden dobře vymezený proces může být nejjednodušší řešení. Je ale potřeba znát limity API, způsob přihlašování, limity volání, verzování i to, zda dodavatel rozhraní dlouhodobě udržuje.

Někdy je správnější pracovat s pravidelným exportem souborů. Typicky u staršího ERP nebo účetního programu, kde rozhraní neexistuje či nepokrývá potřebné operace. Souborové předávání není automaticky špatně. Musí ale mít jasný formát, kontrolu úplnosti, zabezpečené uložení a mechanismus, který pozná, že se jeden soubor nezpracoval dvakrát.

Jakmile propojujete více systémů a procesů, dává smysl integrační vrstva. Ta přijme data, ověří je, přeloží je do formátu cílového systému a předá je dál. Výhodou je, že obchodní logika nezůstane rozptýlená v náhodných skriptech a každý nový systém nemusí znát detaily všech ostatních.

Nevýhodou je další komponenta, kterou je nutné provozovat, monitorovat a dokumentovat. Proto ji nestavíme jen proto, že zní architektonicky správně. Vyplatí se ve chvíli, kdy snižuje budoucí složitost, ne když má jen nahradit dvě jednoduchá API volání.

Počítejte s tím, že výpadek přijde

Integrace, která funguje jen tehdy, když jsou všechny služby dostupné, není připravená na běžný provoz. API může být nedostupné, síťový požadavek může vypršet nebo cílový systém může odpovědět chybou po tom, co data ve skutečnosti přijal. Bez promyšleného návrhu pak hrozí ztráta objednávky, dvojitá faktura nebo stav, který nikdo neumí vysvětlit.

Každý důležitý přenos proto potřebuje identifikátor, podle kterého lze dohledat jeho cestu. Potřebuje bezpečné opakování. Opakovaný požadavek nesmí vytvořit druhou stejnou objednávku. A potřebuje frontu či jiný mechanismus, který data podrží, pokud cílový systém zrovna neodpovídá.

Stejně důležité jsou upozornění. Nestačí sbírat technické logy, do kterých se nikdo nedívá. Odpovědný člověk musí dostat informaci, když přenosy opakovaně selhávají nebo když čeká nezpracovaný požadavek. V některých procesech dává smysl i interní obrazovka, na níž lze problémový záznam zkontrolovat, opravit a znovu odeslat bez zásahu vývojáře.

Tady se rozhoduje, zda je integrace jen jednorázově naprogramované spojení, nebo součást systému, za který někdo skutečně stojí i po spuštění. V Nextrey stavíme a provozujeme produkční software s tímto předpokladem: chyba se nemá skrýt, ale dát dohledat a bezpečně vyřešit.

Bezpečnost a oprávnění patří do návrhu od začátku

Propojené systémy často pracují s osobními údaji, cenami, smlouvami nebo účetními doklady. Každý přenos by měl používat jen oprávnění, která skutečně potřebuje. Integrace pro čtení objednávek nemá mít automaticky právo mazat zákazníky nebo měnit uživatele.

Přístupové údaje nepatří do zdrojového kódu, tabulky ani sdíleného e-mailu. Je potřeba je ukládat odděleně, pravidelně obnovovat a vědět, kdo k nim má přístup. U externích dodavatelů si ověřte, jak lze přístup odebrat, jak se auditují změny a zda jejich API podporuje oddělené účty pro jednotlivé integrace.

Pozor také na rozsah dat. Častá chyba je přenášet celý záznam zákazníka jen proto, že je to pohodlné. Ve skutečnosti může cílovému systému stačit interní ID, jméno a kontaktní údaj. Menší objem předávaných dat znamená méně rizik, jednodušší kontrolu i méně problémů při změně pravidel ochrany dat.

Dodávejte po částech, ale nemaskujte nedokončený proces

U většího propojení není rozumné čekat několik měsíců na okamžik, kdy se změní vše naráz. Lepší je vybrat jeden uzavřený pracovní tok, dodat ho do provozu, změřit dopad a pokračovat další částí. Získáte zpětnou vazbu od lidí, kteří s řešením pracují, a odhalíte výjimky, které v úvodním zadání nebývají vidět.

Postupné dodávání ale neznamená ignorovat celek. Už první část musí počítat s identifikátory, bezpečností, monitoringem a budoucími změnami. Jinak vznikne rychlé napojení, které se při druhém nebo třetím systému změní v těžko udržovatelný uzel.

Před spuštěním si připravte testovací data, včetně duplicit, neúplných objednávek, storen a výpadků. Ověřte nejen šťastnou cestu, ale i to, co uvidí účetní, obchodník nebo podpora ve chvíli, kdy předání selže. Provozní realita nezačíná až po předání. Je součástí návrhu.

Dobré propojení firemních systémů poznáte podle toho, že lidé přestanou řešit, kde data jsou. Mohou se soustředit na zákazníky, zakázky a rozhodování. Začněte jedním procesem, u kterého dnes vidíte konkrétní ztrátu času nebo riziko chyby, a navrhněte jej tak, aby obstál i ve chvíli, kdy některý systém zrovna nebude spolupracovat.