Objednávka projde 4 aplikacemi, ale chyby v přenosu mezi nimi stále hlídá člověk v Excelu.
Systémový integrátor je člověk nebo tým, který zajistí, aby si firemní aplikace předávaly potřebná data a aby za celé propojení někdo nesl odpovědnost.
Nemusí to být programátor, který vytvoří propojení mezi dvěma aplikacemi. Integrátor sleduje celý proces. Zjišťuje, kde údaj vzniká, kdo ho může změnit, která aplikace má při rozporu přednost a co se stane při chybě. Teprve potom řeší technické propojení.
Typickým příkladem je zpracování objednávky. Objednávka vznikne v e-shopu, přenese se do účetního programu a zapíše se do CRM pro správu obchodu a vztahů se zákazníky. Nakonec se podle ní založí požadavek v systému expedice. Každý dodavatel může oprávněně tvrdit, že jeho část funguje. Zákazník přesto může dostat zboží na starou adresu, protože nikdo neurčil, která aplikace vede hlavní evidenci adres.
Integrátor stanoví pravidla pro práci s daty, způsob jejich předávání a odpovědnost při výpadku. Samotné API neboli rozhraní pro komunikaci aplikací je pouze prostředek. Nerozhodne, zda se má opravená faktura přepsat, zablokovat, nebo poslat účetnímu ke kontrole.
Potřeba integrátora se většinou neprojeví jednou chybovou hláškou. Ukazuje se v práci, kterou lidé pravidelně vykonávají mezi aplikacemi:
Excel v takové situaci nebývá příčinou problému. Slouží jako ruční kontrola mezi aplikacemi a postupně se stane trvalou součástí provozu.
Než doporučíme technické řešení, necháme u procesu, který běží každý pracovní den, zhruba tři týdny zapisovat ruční zásahy. U každého záznamu potřebujeme znát výchozí aplikaci, cílovou aplikaci, přenášený údaj, čas opravy a následek chyby. Takové období ukáže opakované zásahy v denním procesu, ale nevypoví spolehlivě o měsíčních nebo sezónních událostech. U méně častého procesu proto měření prodloužíme tak, aby zahrnulo několik jeho běhů a odpovídající část sezóny. Méně časté chyby s nákladným následkem zahrneme do posouzení podle dřívějších provozních záznamů, i když se během sledování neopakují. Bez tohoto měření lze automatizovat levný úkol, zatímco nákladná chyba zůstane bez řešení.
Počet aplikací sám o sobě nerozhoduje. Za pracovní hranici považujeme proces, který prochází alespoň tři systémy, podílejí se na něm dva dodavatelé a jeho přerušení blokuje objednávku, fakturu nebo obsluhu zákazníka. Není to technická norma. V takové situaci už je potřeba určit jednu odpovědnou osobu za celý tok dat.
Integrátor dává smysl také před výměnou účetního systému, CRM nebo e-shopu. Nejdřív je potřeba zjistit, co je na stávající aplikaci napojené. Jinak se nový systém spustí a po několika dnech začne chybět export, který už nikdo nevyrábí, nebo přestane fungovat automatizace používající neplatné údaje. Výběr mezi jedním podnikovým systémem a několika propojenými aplikacemi tuto potřebu sám neřeší. Odpovědnost za data na rozhraních musí být jasná v obou variantách.
Před zahájením vývoje je dobré nechat si připravit mapu toku dat na jedné stránce. U každého údaje musí být uvedeno, kde vzniká, kde se smí měnit a která aplikace má při rozporu přednost. Součástí má být alespoň pět zkušebních situací: běžná objednávka, opravená adresa, duplicitní odeslání, výpadek cílové aplikace a opakování přenosu po jejím obnovení. Tyto situace ukážou, zda návrh počítá také s chybami a opakováním přenosu. Stejný princip shrnujeme v pěti otázkách před prvním řádkem integračního kódu.
Samostatná role integrátora není nutná u každého přenosu dat. Pokud dvě aplikace nabízejí vestavěné propojení a data proudí pouze jedním směrem, nemusí kvůli němu vzniknout samostatná role integrátora. Odpovědnost za hlavní evidenci, obnovu přenosu a řešení chyb však musí převzít správce procesu nebo jeden z dodavatelů. Propojení lze nejdřív vyzkoušet na omezeném vzorku dat. Kontrola se pak řídí četností procesu. U denního přenosu může zahrnout několik běžných provozních cyklů, u měsíčního nebo sezónního přenosu musí sledování pokrýt více opakování a odpovídající část sezóny. Teprve potom lze podle ručních oprav, chyb v provozních záznamech a neúspěšných obnov rozhodnout, zda jsou potřeba další úpravy nebo samostatný integrátor.
Zapojení integrátora nepomůže ani ve chvíli, kdy se samotný proces mění každý týden. Automatizace by pouze rychleji prováděla pravidla, která ještě nikdo neschválil. Nejdřív je dobré popsat proces na konkrétním případu a určit člověka, který smí rozhodovat o výjimkách. Kontrola zadání před návrhem softwaru bývá levnější než pozdější oprava databáze a oprávnění.
Správce IT se obvykle stará o účty, zařízení, přístupy a provoz. Dodavatel softwaru zná svůj produkt. Projektový manažer hlídá úkoly, termíny a rozpočet. Analytik popisuje proces a požadavky. Integrátor může některé z těchto činností dělat také, jeho hlavní odpovědnost je však jinde. Zajišťuje, aby celek fungoval také na hranicích mezi systémy a dodavateli.
Při výběru integrátora se vyplatí zadat jednoduchý praktický úkol. Vezměte jednu skutečnou objednávku a požádejte o zakreslení její cesty, určení hlavní evidence a popis postupu při výpadku. Pokud odpověď začne seznamem technologií, ale chybí v ní vlastník dat a způsob opravy, neřeší odpovědnost za celý proces. Provoz pak dál závisí na několika dodavatelích a ručně vedené tabulce.
U jednotného měsíčního hlášení zaměstnavatele může úřad vadné podání odmítnout. Příprava firemního softwaru proto začíná kontrolou dat a testováním, ne úpravou konečného formuláře.
Stejnou obchodní nabídku lze připravit ve Wordu i v aplikaci napojené na několik zdrojů dat, ale zásadní rozdíl je v tom, kolik práce převezme automatizace.
Rychlá podpora nevyřeší chyby, které vznikají už v nabídce, objednávce nebo fakturaci. Zákaznickou zkušenost proto musí firma řídit napříč odděleními.
Napište nám, co u vás řešíte. Ozveme se do jednoho pracovního dne.
