Modul Procesy umožňuje prostřednictvím grafických uživatelských nástrojů modelování procesů. Pro jednotlivé modelované procesy je možno vytvářet sadu diagramů obsahující jako své prvky:

Modelované procesy a jejich prvky jsou evidovány v hierarchické stromové struktuře složek umožňující přehledný přístup k jednotlivým entitám modulu. Na základě vytvořených diagramů je možno generovat dokumentaci k jednotlivým modelovaným procesům ve formátu PDF. Veškeré texty vytvářené v modulu (popis procesu, názvy a popisy jednotlivých prvků diagramů, ...) je možno lokalizovat do jiných jazyků.

Modul Dávkový server poskytuje nástroje, umožňující uživatelům systému:

Modul Doplňkové informace poskytuje nástroje, umožňující uživatelům systému (implementátorům) prostřednictvím uživatelského rozhraní rozšiřovat množinu evidovaných údajů jednotlivých entit (tříd) systému. Rozšíření evidovaných údajů prostředky tohoto modulu je umožněno bez nutnosti modifikovat databázové struktury a business vrstvu systému.
Při definici doplňkových informací je umožněno řídit možnost evidence dané doplňkové informace ke konkrétní entitě systému v závislosti na údajích této entity (případně entit souvisejících). Například evidence doplňkové informace "datum konce placení" pro Pojistné smlouvy je potřebná pouze pro smlouvy některých Produktů. Definici doplňkové informace je tedy možno spojit s množinou číselníků a pro jednotlivé kombinace záznamů těchto číselníků je pak možno specifikovat, za má být doplňková informace pro danou kombinaci evidována (případně definovat další údaje pro tuto evidenci).
Hodnoty doplňkových informací jsou uchovávány s kompletní historií, tzn. při modifikaci je platnost původních záznamů ukončena a vznikají nové záznamy s novým obdobím platnosti.

Modul Algoritmus slouží k analýze, implementaci a tvorbě dokumentace systému Sirael. Modul umožňuje vytváření analytických modelů systému (UseCase model, Class model), implementaci systému (tvorbu Algoritmů a Formulářů) a vytváření on-line a tištěné dokumentace. Prostředky tohoto modulu jsou také hojně využívány ostatními moduly systému pro přizpůsobení systému potřebám konkrétního zákazníka.

1.1. UseCase model

Součástí modulu jsou nástroje pro pro vytváření UseCase modelu systému. Prostřednictvím entit UC jsou evidovány jednotlivé UseCasy - scénáře chování určité části (určité funkce) systému. Data, nad kterými jednotlivé scénáře pracují, jsou evidována prostřednictvím entity Entita. Tato umožňuje definovat hierarchii evidovaných údajů v podobě stromové struktury položek. Hlášení, která jednotlivé scénáře vyvolávají (chybová hlášení, dotazy k uživateli, ...), jsou evidována prostřednictvím entity Hlášení. Tato entita je využívána také pro evidenci "labelů" ve vytvářených Formulářích. Entita umožňuje překlad textů jednotlivých Hlášení do jiných jazyků, čímž je zajištěna možnost komunikace systému s uživatelem v jiných jazycích.

1.2. Class model

Modul poskytuje nástroje pro tvorbu Class modelu - modelu "business" tříd. Jednotlivé business třídy systému jsou evidovány prostřednictvím entity Třída. Součástí evidovaných údajů je také seznam atributů, metod, vazeb a validací (obecných kontrol, které musí objekty dané třídy splňovat) jednotlivých Tříd. Modul umožňuje také definovat specielní "doménové" datové typy a tyto následně používat jako datové typy atributů, parametrů metod, ... jednotlivých Tříd. Tyto jsou evidovány prostřednictvím entity Datový typ. Modul umožňuje také vytváření digramů Tříd pro grafickou prezentaci jednotlivých částí modelu. Jednotlivé diagramy jsou evidovány prostřednictvím entity Diagram tříd. Na základě vytvořeného modelu je možno provést export jednotlivých Tříd a vytvořit tak "kostry" tříd business vrstvy systému. Takto vyexportovaná data ("kostry" tříd) jsou pak použita v další implementaci business vrstvy, která je již prováděna "standardními" prostředky mimo modul Algoritmus.

1.3. Implementace

Součástí modulu jsou také nástroje umožňující implementaci jednotlivých částí systému (kromě implementace business vrstvy, která je prováděna mimo modul Algoritmus). Prostřednictvím těchto nástrojů jsou vytvářeny jednotlivé Algoritmy a Formuláře. Pro snadnou tvorbu Formulářů je součástí také "kreslící" nástroj umožňující jejich vizuální návrh skládáním jednotlivých komponent (vstupních polí, labelů, tlačítek, ...).

1.4. Dokumentace

Modul umožňuje také tvorbu podkladů pro on-line a tištěnou dokumentaci. Jednotlivé části dokumentace jsou evidovány v Elementech dokumentace. Tyto elementární části je možné spojovat s vytvořenými Formuláři. Tato vazba následně umožňuje zobrazit určitou část on-line dokumentace při zobrazení (běhu) příslušného Formuláře. Jednotlivé vytvořené Elementy dokumentace je možno také dále sdružovat ve formě stromové struktury kapitol pro vytvoření tištěné dokumentace.

Modul Archivace poskytuje nástroje pro evidenci elektronických dokumentů (textových souborů, nascanovaných dokumentů, zvukových souborů, ...), které pojišťovna považuje za relevantní evidovat. Každý evidovaný dokument může obsahovat více fyzických souborů různého typu. Pro vlastní evidenci fyzických souborů je používán externí archivační systém. Ke každému dokumentu je možno evidovat množinu popisných údajů - klíčů (např. číslo jednací, číslo pojistné smlouvy, identifikace klienta, ...). Tyto klíče slouží pro automatické navazování dokumentů k entitám systému při jejich vzniku (archivaci).
Přístup Operátorů k jednotlivým Dokumentům evidovaným v systému je řízen prostřednictvím Oprávnění a jejich Parametrů. Může být tak například omezen přístup některých Operátorů k některým Druhům dokumentů (např. ne všichni operátoři mohou mít přístup k lékařským zprávám evidovaným u Pojistných smluv nebo Pojistných událostí).
Modul umožňuje také evidenci fyzického uložení papírových dokumentů, ze kterých elektronické dokumenty vznikly. Modul umožňuje definovat stromovou víceúrovňovou strukturu fyzického archivu (např. Budova A, Místnost 125, Skříň 3, Složka 5) a pro každý elektronický dokument je pak možno evidovat fyzické uložení jeho "zdroje". Umožněno je také evidovat uložení "u operátora" využívané v případě, že si Operátor daný papírový dokument z archivu vyzvedne.

Modul Workflow poskytuje nástroje umožňující sledování procesů probíhajících v systému. Jako příklady takovýchto procesů je možno uvést procesy "Zpracování pojistné události", "Zpracování návrhu pojistné smlouvy", "Zpracování dožití pojistné smlouvy", "Provedení neinkasní intervence" a podobně. Pro každý sledovaný proces je v modulu vytvořena entita Případ. K této entitě jsou pak evidovány Události, které v rámci probíhajícího procesu (Případu) nastaly a Úkoly, které mají být (nebo byly) provedeny.
Úkoly je možno vytvářet jak s vazbou k existujícímu Případu, tak i bez této vazby. Úkoly bez vazby na Případy mohou být tak například využity pro zaznamenávání a sledování "osobních" úkolů jednotlivých operátorů, které přímo nesouvisejí s nějakým procesem probíhajícím v systému. Pro jednotlivé evidované Úkoly je možno stanovovat množinu termínů pro jejich splnění a následně reagovat na jejich splnění resp. nesplnění v daném termínu. Reakce je realizována prostřednictvím uživatelsky modifikovatelných Algoritmů definovaných pro Definice úkolů (typů úkolů). Modul je také schopen, ve spolupráci s modulem Korespondence, upozorňovat úkolované operátory pomocí SMS nebo e-mailu na vznik nového úkolu.
Součástí modulu je také "interní komunikační systém" umožňující posílání textových zpráv mezi jednotlivými operátory systému. Tento může být využíván pro komunikaci namísto komunikace e-mailem nebo SMS zprávami.

Modul Správa systému poskytuje funkcionalitu potřebnou pro:

Správu systémových entit - v modulu Správa systému je evidována a spravována stromová struktura Nabídek provozního systému (menu). Dále je umožněno vytvářet a spravovat Číselné řady používané ostatními moduly systému.

Modul Účty, rezervy poskytuje nástroje, umožňující jednotnou evidenci různých druhů Rezerv k jednotlivým entitám systému. Modul umožňuje evidovat stavové Rezervy (evidovány jsou stavy v určitých časových okamžicích - například životní rezerva) a pohybové Rezervy (evidovány jsou jednotlivé pohyby (přírůstky a úbytky) rezervy - například RBNS). Další oblastí, kterou modul Účty, rezervy pokrývá, je správa Investičních fondů. Modul poskytuje nástroje pro:

Při vytváření záznamů Rezerv a správě Investičních fondů a účtů, zajišťuje modul také správné zaúčtování (vytvoření odpovídajících Účetních záznamů v modulu Finance).

1.1. Pojem 'korespondence'

Primárním úkolem modulu je evidence požadavků na klientský tisk a vytváření odpovídajících podkladů pro tiskový systém. S tím souvisí správa druhů dokumentů zasílaných klientům a (ve spolupráci s modulem Algoritmus) správa a využití Algoritmů, které pro jednotlivé druhy dokumentů vytvářejí kompletní podklady pro tisk.
Pojem "korespondence" byl zobecněn v tom smyslu, že za korespondenci považujeme nejen tištěný dokument, ale také e-mail a SMS.

1.2. Tiskový systém

Návrh předpokládá existenci interního tiskového systému integrovaného do systému Sirael a vedle toho návrh umožňuje spolupráci s externím tiskovým systémem. Standardně se předpokládá využití externího tiskového systému pro rozsáhlé tisky a využití interního tiskového systému pro on-line tisk a tisky menšího rozsahu. Nicméně u malé pojišťovny je možno uvažovat o provozu pouze s interním tiskovým systémem.
Od obou tiskových systémů očekáváme, že budou poskytovat funkcionalitu pro návrh designu, to znamená vytváření šablon a jejich správu. Modul Korespondence bude tiskovým systémům dodávat specifikaci požadovaného druhu dokumentu a datovou větu s údaji pro tisk (tzv. tiskovou větu). Na straně tiskových systémů očekáváme funkcionalitu, která pro požadovaný druh dokumentu vyhledá odpovídající šablonu a zkonstruuje výsledný dokument obsahující předané údaje.
Tiskový systém a modul Korespondence budou mít samostatné "nezávislé" verzování (tiskový systém verze šablon, modul Korespondence verze definic pro vytvoření tiskových dat). Standardně se předpokládá tisk z aktuální verze šablony (bez jejích explicitní specifikace). Při změně týkající se obou systémů musí být nasazení nových verzí synchronizováno. Pokud tiskový systém bude disponovat funkcemi pro tisk z neaktuální šablony, bude možno v případě potřeby požadovat tisk podle nastavení platných k určitému dni. Jak modul Korespondence, tak tiskový systém pak zpracují požadavek podle verzí platných k zadanému dni.
V případě, že je potřeba provést bližší specifikaci pro tisk a další zpracování dokumentu / dávky dokumentů (zda má být obálkováno, automatické vkládání příloh, údaje pro poštovní svazovky a průvodky apod.), jsou odpovídající parametry vyhodnoceny modulem Korespondence a připojeny k předávaným tiskovým větám.

1.3. Základní mechanismus korespondence

Funkce systému požadující korespondenci vytvářejí v modulu Korespondence entity Požadavek na korespondenci. Z údajů uvedených v požadavku je možno vyhodnotit, jaký druh dokumentu (v jaké variantě a časové verzi) má být vytvořen. V parametrech požadavku jsou pak specifikovány objekty, ke kterým se korespondence váže a odkud mají být extrahována potřebná data.
Modul Korespondence zajistí pro každý požadovaný dokument vyhledání konkrétních údajů, které mají být vytisknuty (resp. odeslány el. poštou) a uloží je do tzv. Tiskové věty. Tisková věta je vytvářena pokud možno bezprostředně před tiskem (resp. odesláním el. pošty), aby obsahovala aktuální údaje.
Jestliže má být tisk proveden v dávce, modul Korespondence použije vytvořené Tiskové věty k vytvoření datového souboru v dohodnuté struktuře (v případě zpracování dávky externím tiskovým systémem) nebo k dávkovému zpracování interním tiskovým systémem.
Kopie odeslaných dokumentů (pokud jsou k dispozici), mohou být ukládány do elektronického archívu (využitím modulu Archivace).

1.4. Modifikace tiskové věty

Modul Korespondence dovoluje nadefinovat korespondenci, která umožní uživateli provádět změny v jednotlivém konkrétním dokumentu. V definici Druhu dokumentu je stanoveno, zda je uživateli povoleno vložit vlastní text. Při vytváření Požadavku na korespondenci je pak uživateli umožněno zapsat text, který je uložen jako součást požadavku a při generování dokumentu vložen na stanovené místo v šabloně.
Při vytváření Požadavku na korespondenci může volající funkce pro tato místa nadefinovat defaultní text, který je v příslušném "formuláři" předvyplněn a může být při uživatelské modifikaci editován.

1.5. Režimy zpracování

1.5.1. Tisk

Modul Korespondence umožňuje:

Pozn. Volba mezi režimy zpracování (interaktivní vs. centrální) nemá přímou souvislost s možností modifikovat dokument. Je možno provést uživatelsky modifikaci a pak nechat dokument projít centrálním zpracováním. Naopak je možno nechat interaktivně vytisknout nemodifikovaný dokument. Určitá spojitost je pouze v tom, že u dokumentů s obsáhlejší modifikací je možno předpokládat, že uživatel bude chtít vidět náhled dokumentu, aby mohl ještě provést korekturu, a proto interaktivní zpracování u těchto dokumentů bude požadováno častěji než u jiných.

1.5.2. Elektronická korespondence

U elektronické korespondence je při vytváření požadavku také možno nastavit příznak interaktivního zpracování, který dovolí uživateli prohlédnout si (případně modifikovat) sestavenou elektronickou zprávu dříve, než je odeslána, a "odsouhlasit ji".
Možnost náhledu představuje u elektronické korespondence jediný rozdíl mezi oběma režimy, protože všechny požadavky jsou zpracovány ihned (nečekají na pokyn operátora tisku).

Modul Pojistné události poskytuje nástroje pro evidenci a správu pojistných událostí. Zpracování pojistné události je obvykle zahájeno přijetím a zpracováním Hlášenky. Na jejím základě je následně vytvořena (zaregistrována) jedna nebo více Pojistných událostí. Modul umožňuje evidovat Pojistné události tří typů:

Pro registrované Pojistné události jsou v systému následně sledovány jednotlivé Likvidační zprávy. Tyto entity evidují údaje o jednotlivých provedených procesech likvidace nad Pojistnými událostmi. Na základě provedené likvidace vznikají procesem revize (odsouhlasení) odpovídající záznamy v modulu Finance, prostřednictvím kterých je provedena výplata pojistného plnění.

Modul umožňuje sdružování jednotlivých Pojistných událostí do Centrálních událostí. Takto jsou spojovány Pojistné události vzniklé na základě jedné příčiny (příčinné skutečnosti). Modul také podporuje sledování Katastrofických událostí a (ve spolupráci s modulem Zajištění) jejich správné zohlednění při komunikaci se zajistiteli.
Součástí modulu Pojistné události jsou také funkce pro podporu opakujících se výplat (rent, důchodů, ...). Modul zajišťuje také správné zdanění vyplacených finančních prostředků a (prostřednictvím modulu Finance) odvod daní odpovídajícím finančním institucím. Oblast daní je však velmi závislá na "místních zákonech" a obvykle tedy bude řešena až v rámci implementace systému u zákazníka.
Vzhledem k tomu, že procesy spojené se správou Pojistných událostí mohou být velmi variabilní v závislosti na požadavcích zákazníka, umožňuje modul Pojistné události (podobně jako modul Produkt) definovat uživatelem systému chování jednotlivých procesů - tedy vytvořit Formuláře, prostřednictvím kterých budou jednotlivé procesy zpracovávány. Součástí prvotní instalace systému je sada univerzálních procesů (Formulářů) umožňujících unifikovanou správu obvyklých typů pojistných událostí.

Společnost AIS Software, a.s. je úspěšná firma s čistě českým kapitálem. Byla založena v roce 1995 v Brně. Náš informační systém je používán ve velký českých i slovenských pojišťovnách.
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram