Reference

Řešení

Na základě našich zkušeností s řešením podobných problémů jsme si uvědomili, že v budoucnu se požadavky na realizované řešení zvýší nebo změní. Proto jsme nabídli Zákazníkovi vývoj podle metodiky Agile, který umožňuje rychle přijímat potřebné na tomto místě funkční a upravit seznam požadavků na základě potřeb zaměstnanců a zpětné vazby získané od nich. Zákazník s radostí přijal naši nabídku.

Fáze 1. Základní automatizace

Bylo rozhodnuto začít s implementací obchodního procesu s běžnými prostředky Bitriks24. Uspořádali jsme briefing zaměstnanců a dohodli jsme se na tom, že se dohodneme, vezmeme-li v úvahu zvláštnost vnitřních pravidel společnosti a přání všech účastníků.

V závislosti na typu dohodnutého dokumentu a příspěvku, který inicioval jeho zaměstnanec, byly realizovány různé harmonizační řetězce. Stažený dokument byl umístěn na Bitrix disk. Dále proces shromáždil potvrzení (nebo odmítnutí) o souhlasu a připomínky, pokud takové byly.

Po dokončení první fáze jsme automatizovali řetězec schválení, ale samotný dokument byl na disku, Komentáře zůstaly uvnitř procesu a v oznámeních. Pokud však vyžadovaly další činy s dokumentem, například, předat v účetnictví (v počáteční fázi se Zákazníkem bylo rozhodnuto nezařadit ji v práci obchodního procesu), nebo poslat dodavatelům, pak pro to musel samostatně odesílat dokument, a samostatně tisknout potvrzení o harmonizaci a komentáře.

pro snadnou práci s archivem aplikací byl vytvořen univerzální seznam. Obchodní proces při spuštění do něj přidával novou nahrávku, než ji doplnil, jak se informace dostaly.

Tato implementace urychlila proces harmonizace, ale nebyla optimálně dokončena.

Fáze 2. Vývoj aplikace

Shromažďovat zpětnou vazbu od zaměstnanců, Zákazník požádal implementovat mechanismus, který umožňuje v důsledku formování získat jediný soubor, který obsahuje samotný dokument, a příběh o jeho vzniku. Protože původní dokument mohl být vložen do různých formátů (PDF, JPG, PNG, BMP), pak bylo rozhodnuto zastavit na formátu PDF, který umožňuje tvořit многостраничные dokumenty a má prostředky pro ochranu dokumentu, a také umožňuje použít digitální podpis.

Nejviditelnějším řešením byl vývoj aplikace pro Bitriks24 a aktivity * pro obchodní proces.

* - Aktivita obchodního procesu je volitelná jednotka, která je k dispozici v návrhu obchodních procesů a má vlastní parametry.

Aktiviti byl zodpovědný za propojení obchodního procesu s aplikací. Aplikace by měla být spojena s webovou službou, která tvoří výsledný dokument, a převést jej zpět do aktivity obchodního procesu.

Zpočátku jsme neuvažovali o umístění aplikace do cloudu Bitriks24, protože byla náročná na zdroje a vyžadovala práci se speciálními knihovnami, které umožňují upravovat a vytvářet PDF. Plánovali jsme umístit aplikaci na hostování, které má klient k dispozici. Ale ve fázi ladění se ukázalo, že ne všechny hostingy jsou připraveny k instalaci knihovny, které potřebujeme, a dát pokročilé oprávnění pro práci se souborovým systémem. A náklady na hostingové služby, které splňují naše požadavky, nejsou spokojeni se zákazníkem. Proto bylo nalezeno kompromisní řešení - v serverovém zákazníkovi byl umístěn jednoduchý webový server, na kterém jsme umístili naši aplikaci.

Po realizaci druhé etapy, bez ohledu na formát staženého dokumentu ovlivňují výsledný PDF soubor, začátek, který je дублировало zdrojový soubor (je-li nahrán obrázek, pak je umístěn na první stránce), a na následujících stránkách se s předem daným formátováním se zobrazily údaje shromážděné v dodavatelském dohodě. Čas odsouhlasení, údaje dohodnuté osoby a připomínky, pokud byly ponechány.

Fáze 3. Verze 2.0

Řešení se ukázalo jako úspěšné a začali jej aktivně využívat zaměstnanci společnosti. Počet dokumentů dohodnutých prostřednictvím obchodního procesu rychle rostl, vč. a díky úplnému odmítnutí vedení zákazníka od schválení v předchozím formátu.

Díky tomuto intenzivnímu použití se projevily slabé stránky řešení, které jsme realizovali:

• Při načítání objemových vícestránkových skenů smluv ve formátu PDF chyběla kapacita webového serveru nebo zpracování probíhalo poměrně dlouho
• Pokud byly dva dokumenty zpracovávány současně, byl zpracován pouze jeden z nich.
• V případě nedostupnosti webového serveru nebyly dokumenty odeslány ke zpracování a nemohly být znovu odeslány

Pokud během zpracování dokumentu došlo k nějaké selhání (soubor byl vytvořen nebo zdrojový soubor nemůže být správně zpracován), pak skript vrátit chybu, a proces завершался jen oznámí iniciátor o technickou chybu.

shromážděním těchto připomínek a přání jsme dospěli k závěru, že stávající řešení je třeba podstatně přepracovat. Nové schéma práce vypadalo takto:

• Pro zpracování prostorových dokumentů zvýšil množství paměti RAM na webovém serveru a optimalizoval samotný skript.
• Pro souběžné zpracování více dokumentů aktivity obchodního procesu bylo dokončeno-dostupnost serveru byla ověřena a odesílání bylo provedeno více než jednou, ale v několika pokusech s intervalem mezi nimi. Všechny odpovědi serveru byly uvedeny do protokolu obchodního procesu, což umožnilo přesněji sledovat průběh zpracování souboru.
• Funkce skriptu byla rozdělena na dvě hlavní funkce-příjem a přenos souborů a dat a přímo generování souboru. Po obdržení souboru a dat skript odeslal do aplikace B24 odpověď potvrzující příjem dat. Získaná data byla zapsána do databáze, odkud se pak dostala ke zpracování skriptem odpovědným za generování PDF. Výsledek byl odeslán zpět do aplikace Bitriks24, která zaznamenává stav úspěšného přenosu souboru. Posílání se uskutečnilo i v několika pokusech. teoreticky jsou možné poruchy přenosu spojené s dočasnou nedostupností Bitriks24.
• Pro sledování dokumentů zpracovávaných na serveru bylo vytvořeno webové rozhraní, které zobrazuje stav aktuálních dokumentů a umožňuje sledovat historii tvorby souborů. Webové rozhraní implementovalo funkce nuceného opětovného odeslání vytvořeného souboru do Bitriks24.
• Dostupnost serveru byla ověřena zasláním testovacího dotazu - pokud byl server nedostupný, bylo správci portálu zasláno oznámení.

V důsledku toho se podařilo zvýšit spolehlivost a transparentnost absolvování zpracování dokumentů - v protokolu business procesu byly viditelné všechny kroky zpracování a přenosu dokumentu, ale na straně webového serveru do webového rozhraní můžete sledovat stavy příjem, zpracování a odesílání dokumentů.

Stupeň 4. Vývoj

Krátce po zavedení přepracovaného řešení chtěl zákazník rozšířit možnosti obchodního procesu. Řešení vývojáře třetí strany bylo také implementováno jako aplikace Bitriks24 a má vlastní aktivitu pro obchodní proces. Taková aktivita byla přidána do obchodního procesu a uživatelé měli možnost dynamicky vytvářet chat pro diskusi o konkrétním dokumentu. Historie korespondence byla také zaznamenána v logu obchodního procesu.

Ve stejné fázi bylo do obchodního procesu přidáno účetnictví pro zpracování dohodnutých finančních dokumentů. Po odsouhlasení mohl iniciátor sledovat nejen stav odsouhlasení dokumentu, ale i stav placení faktur.

V důsledku toho zákazník obdržel řešení, které splňuje jeho potřeby. Čas dohodě snížena na 1-2 dny (dříve sladění by se mohlo protáhnout na týdny, ale některé dokumenty a vůbec терялись) díky pohodlí sledování stavu obchodních procesů a řadu upozornění odeslané zaměstnancům, od nichž je požadována reakce. Korespondence spojená s dohodou se nyní mohla uskutečnit ve formátu chatu mezi všemi účastníky dohody, což umožnilo zkrátit dobu odsouhlasení. V posledním vydání byla pravděpodobnost selhání softwaru nebo ztráty dokumentu minimalizována, protože většina akcí byla duplikována ve dvou systémech.

P.S.: S aktualizací mobilní aplikace Bitriks24 a vznikem funkčních obchodních procesů se doba sladění většiny dokumentů zkrátila na 1 pracovní den. Ti, kteří jsou nyní zodpovědní za harmonizaci, mohli reagovat operativněji.