Kdy malá firma potřebuje systémového integrátora

Co systémový integrátor skutečně dělá

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 2 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.

Signály jsou vidět v běžné práci

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:

• Stejný údaj se zapisuje na 2 nebo 3 místa a při změně se musí ručně opravit všude.
• Zaměstnanec každé ráno porovnává objednávky, platby nebo stav skladu mezi 2 tabulkami.
• Na chybu upozorní až zákazník, účetní nebo pracovník expedice.
• Úprava formuláře v 1 aplikaci pravidelně naruší navazující zpracování v jiné.
• Dodavatelé si předávají problém s vysvětlením, že jejich systém data odeslal nebo přijal správně.

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čím technické řešení, nechám u procesu probíhajícího každý pracovní den po dobu 14 pracovních dnů zapisovat ruční zásahy. U každého záznamu potřebuji 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žím 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 zahrnu 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í.

Kdy už dává samostatná role smysl

Počet aplikací sám o sobě nerozhoduje. Za pracovní hranici považuji proces, který prochází alespoň 3 systémy, podílejí se na něm 2 dodavatelé a jeho přerušení blokuje objednávku, fakturu nebo obsluhu zákazníka. Není to technická norma. V takové situaci už potřebuji určit 1 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 1 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 bych si nechal připravit mapu toku dat na 1 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ň 5 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 shrnuji v 5 otázkách před prvním řádkem integračního kódu.

Kdy je integrátor zbytečný

Samostatná role integrátora není nutná u každého přenosu dat. Pokud 2 aplikace nabízejí vestavěné propojení a data proudí pouze 1 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 bych proces popsal na konkrétním případu a určil č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í.

S jakými rolemi se integrátor zaměňuje

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 zadávám jednoduchý praktický úkol. Vezmu 1 skutečnou objednávku a požádám 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.