Informační systém pro vedení agendy insolvenčních správců při řešení úpadku formou oddlužení

Mendelova univerzita v Brně Provozně ekonomická fakulta

Informační systém pro vedení agendy insolvenčních správců při řešení úpadku formou oddlužení Bakalářská práce

Vedoucí práce: Ing. Michal Hodinka

Jelínek Lukáš

Brno 2013

Rád bych touto cestou vyjádřil poděkování Ing. Michalu Hodinkovi za vedení, odborné rady a připomínky, které mi poskytl při zpracování bakalářské práce.

Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a použil pouze literaturu uvedenou v přiloženém seznamu. V Brně dne 20. května 2013

__________________

Abstract The bachelor’s thesis pays attention to the proposal of a partial information system for keeping the administration work for insolvency proceedings in the way of disencumbrance through a repayment plan. There has been suggested a system for a particular bureau of insolvency based on the SWOT analysis of information systems offered on the market, and the client’s requirements processed in the Enterprise Architect programme. The information system has been programmed by means of the PHP scripting language using the Nette framework and the MySQL database. This system respects the valid legislation, facilitating the work and saving the costs related to office work. Keywords Insolvency, disencumbrance, SWOT, Enterprise Architect, PHP, Nette Framework, MySQL

Abstrakt Předmětem bakalářské práce je návrh dílčího informačního systému pro vedení agendy insolvenčního řízení formou oddlužení způsobem splátkového kalendáře. Na základě SWOT analýzy informačních systémů nabízených na trhu a požadavků zadavatele zpracovaných v programu Enterprise Architect je navržen systém pro konkrétní insolvenční kancelář. Informační systém je naprogramován pomocí skriptovacího jazyka PHP za použití frameworku Nette a databáze MySQL. Tento systém respektuje platnou legislativu, usnadňuje práci a šetří čas i náklady spojené s administrativou. Klíčová slova Insolvence, oddlužení, SWOT, Enterprise Architekt, PHP, Nette Framework MySQL

Obsah

6

Obsah 1

2

Úvod a cíl práce 1.1

Úvod .........................................................................................................10

1.2

Cíl práce ...................................................................................................10

Insolvence, osobní bankrot 2.1

3

4

11

Osobní bankrot – oddlužení .................................................................... 11

Materiál a metodika zpracování

13

3.1

UML ......................................................................................................... 13

3.2

Enterprise Architect................................................................................. 14

3.3

Modely programu Enterprise Architect .................................................. 16

3.3.1

Use Case Model ................................................................................ 17

3.3.2

Eriksson-Penker Business Process Model .......................................18

3.3.3

Model požadavků ............................................................................. 19

3.3.4

Kontrolní model .............................................................................. 20

3.4

MySQL ..................................................................................................... 21

3.5

Insolvenční rejstřík ................................................................................. 22

3.6

Nette Framework a Model-View-Controller .......................................... 22

3.7

Situační analýza a SWOT analýza........................................................... 23

Analýza současného stavu

25

4.1

Osobní bankrot v číslech roku 2012 ....................................................... 25

4.2

SWOT analýza informačních systémů nabízených na trhu ................... 28

4.2.1

SWOT analýza vnějšího prostředí .................................................. 28

4.2.2

SWOT analýza vnitřního prostředí ................................................. 29

4.3

Analýza kanceláře insolvenčního správce .............................................. 32

4.3.1 5

10

Model požadavků ............................................................................ 32

Návrhová část

34

5.1

Use Case .................................................................................................. 34

5.2

Procesní model ....................................................................................... 36

Obsah

7

5.3

Kontrolní model .......................................................................................37

5.4

Použitá technologie ................................................................................. 38

5.5

Struktura informačního systému ........................................................... 38

5.5.1

Rozdělení informačního systému do modulů ................................ 39

5.5.2

Přihlášení do systému ..................................................................... 40

5.5.3

UPLOAD šablon .............................................................................. 42

5.5.4

DOWNLOAD šablon ....................................................................... 44

5.5.5

Fáze zpracování tiskových sestav ................................................... 45

5.5.6

Kontrola tiskových sestav ............................................................... 45

5.5.7

Napojení systému na Insolvenční rejstřík ...................................... 46

5.6

Uživatelské rozhraní ............................................................................... 47

6

Diskuse

48

7

Závěr

50

7.1

Využití informačního systému pro praxi ................................................ 50

8

Literatura

51

A

Přílohy na CD

54

Seznam obrázků

8

Seznam obrázků Obr. 1

Příklad Use Case modelu

18

Obr. 2

Příklad Business Process Modelu

18

Obr. 3

Příklad Modelu požadavků

19

Obr. 4

Hierarchie požadavků

20

Obr. 5

Příklad Kontrolního modelu

21

Obr. 6

SWOT analýza

24

Obr. 7

Rozdělení SWOT analýzy

24

Obr. 8

Graf podaných insolvenčních návrhů v roce 2012

26

Obr. 9

Graf rozhodnutí o úpadku v roce 2012

26

Obr. 10

Graf způsobu řešení úpadku v roce 2012

27

Obr. 11

Graf formy řešení oddlužení v roce 2012

27

Obr. 12

Model požadavků insolvenční kanceláře

32

Obr. 13

Use Case model insolvenční kanceláře

35

Obr. 14

Business Process Model insolvenční kanceláře

36

Obr. 15

Kontrolní model insolvenční kanceláře

38

Obr. 16

Přihlášení do informačního systému

41

Obr. 17

Použití hashovací funkce

42

Obr. 18

Nahrávání šablon

43

Obr. 19

Stahování nahraných šablon

44

Obr. 20

Fáze zpracování tiskových sestav

45

Obr. 21

Kontrola tiskových sestav – možnost stahování

46

Obr. 22

Kontrola tiskových sestav – možnost nahrávání

46

Seznam tabulek

9

Seznam tabulek Tab. 1

Osobní bankrot v číslech roku 2012

25

Tab. 2

Silné stránky informačního systému Insolvenční Správce

29

Slabé stránky informačního systému Insolvenční Správce

29

Tab. 4

Silné stránky informačního systému IS-IR

30

Tab. 5

Slabé stránky informačního systému IS-IR

30

Tab. 6

Silné stránky informačního systému Insolvenční kancelář

31

Slabé stránky informačního systému Insolvenční kancelář

31

Tab. 3

Tab. 7

Úvod a cíl práce

10

1 Úvod a cíl práce 1.1

Úvod

V každé zemi s tržní ekonomikou se setkáváme se svobodnou soutěží subjektů na trhu a v něm i s těmi, kteří na tomto trhu neuspěli. Pro řešení takových situací byla vytvořena právní úprava, která zároveň chrání práva jak dlužníka, tak věřitele. Touto úpravou je insolvenční zákon č. 182/2006 Sb. a Nařízení Rady č. 1346/2000 Evropského společenství (ES) o úpadkovém řízení. Řešením pro neúspěch občana se stal tzv. osobní bankrot. Ode dne 1.1.2008 využilo práva požádat soud o řešení svého úpadku tak velké množství občanů ČR, že tím byla vyvolána potřeba vytvoření informačního systému pro práci insolvenčního správce. Služby v oblasti správy insolvenčních případů pomocí softwaru jsou dnes nabízeny pouze ve dvou variantách.

1.2 Cíl práce Cílem této práce je vytvoření vlastního návrhu dílčího informačního systému pro správu insolvenčního řízení úpadku občanů tzv. oddlužení – osobní bankrot šitého na míru konkrétní insolvenční kanceláři. Cílem je vytvoření databáze jednotlivých dlužníků insolvenčních případů u daného insolvenčního soudu prostřednictvím činnosti insolvenčního správce. Práce vyžaduje zpracování různorodých informací, evidenci dat dlužníka i věřitelů a dodržování pravidel procesního řízení, dodržování zadaných pokynů soudem a dodržování lhůt dle zákona. Tato mnou vytvořená práce se zužuje na období vedení procesu oddlužení od jeho povolení soudem až do doby jeho schválení. Forma řešení úpadku byla mnou zvolena oddlužení způsobem splátkového kalendáře. Jde o nejčastější formu řešení v České republice.

Insolvence, osobní bankrot

11

2 Insolvence, osobní bankrot Právní úprava úpadkového práva pro Českou republiku Insolvenční zákon 182/2006 Sb., účinnost k 1.1.2008, ve svých ustanoveních předpokládá potřebnost informačního systému ve veřejné správě, jehož správcem je Ministerstvo spravedlnosti. Na tento informační systému lze navázat a z něho čerpat. Je zdrojem základních dat pro vlastní informační systém. Insolvenční rejstřík obsahuje seznam insolvenčních správců, seznam dlužníků a insolvenční spisy. Pro každého dlužníka se vede jeden insolvenční spis. Je veřejně přístupný, každý má právo do něj nahlížet a pořizovat si z něj kopie a výpisy (Kozák a další, 2008, § 419). Podání dodaná soudu v elektronické podobě jsou vkládána pomocí elektronického přenosu dat. Tímto přístupem byly definitivně prolomeny hranice mezi podáním tradiční písemnou formou, vedení spisového písemného materiálu a podáním elektronickým s možností elektronického spisu. Tím se otevřela příležitost pro informační systémy spolupracující v oblasti justice.

2.1 Osobní bankrot – oddlužení Oddlužení je forma řešení úpadku pro občana, subjekt nepodnikající, který již není schopen své závazky plnit v čase a má více jak dva věřitele, nalézá se v tzv. dluhové pasti. Insolvenční návrh podává dlužník sám a zároveň k němu připojuje i návrh na své oddlužení. Soud tento návrh přezkoumá, a pokud splňuje zákonem dané podmínky je povoleno oddlužení a v něm je ustanoven do své funkce insolvenční správce, který zahajuje svou práci správy nad dlužníkem. Způsoby řešení oddlužení jsou řešeny formou splátkového kalendáře nebo prodejem dlužníkova majetku. Návrh dlužníka nesmí sledovat nepoctivý záměr nebo hodnota jeho plnění, kterou by pro oddlužení obdrželi nezajištění věřitelé, bude nižší než 30% jejich pohledávek (Kozák a další, 2008, § 395). Řešení plněním splátkového kalendáře – při oddlužení plněním splátkového kalendáře je dlužník povinen po dobu 5 let měsíčně splácet nezajištěným věřitelům ze svých příjmů částku ve stejném rozsahu, v jakém z nich mohou být při výkonu rozhodnutí nebo při exekuci uspokojeny přednostní pohledávky. Tuto částku rozvrhne dlužník mezi nezajištěné věřitele podle poměru jejich pohledávek, způsobem určeným v rozhodnutí insolvenčního soudu o schválení oddlužení. Zajištění věřitelé se uspokojí ze zpeněžení zajištění (Kozák a další, 2008, § 399). Hodnoty získané dědictvím a darem je dlužník povinen zpeněžit a jejich výtěžek, stejně jako jiné mimořádné příjmy, použít k mimořádným splátkám nad rámec splátkového kalendáře (Kozák a další, 2008, § 412).

Insolvence, osobní bankrot

12

Řešení zpeněžením majetku – při oddlužení zpeněžením majetkové podstaty je dlužníku zpeněžen majetek a uspokojeni nezajištění věřitelé z jeho prodeje. Do majetkové podstaty nenáleží majetek, který dlužník nabyl v průběhu insolvenčního řízení poté, co nastaly účinky schválení oddlužení (Kozák a další, 2008, § 399). Pro tvorbu informačního systému je nutností vytvořit v databázi dlužníka kartu dlužníka, ve které budou evidovány veškeré příjmy a majetková podstata dlužníka pro sledování, zda plní podmínky dané zákonem. Této činnosti je povinen insolvenční správce, který následně doporučuje formu oddlužení a podává námitky, pokud dlužník podmínky nesplní. Aby bylo možné tyto podklady předložit k posouzení soudu a věřitelům, obesílá insolvenční správce v rámci součinnosti třetí osoby (katastrální úřad, bankovní domy, centrální registr vozidel atd.). Jemu sdělené informace jsou evidovány a jsou součástí databáze dlužníka. Při další práci insolvenční správce provádí i svá šetření a jednání s dlužníkem. Karta věřitele pak bude plně sledovat nároky věřitelů. Součástí zjištění skutečností osvědčujících úpadek je i majetková podstata a její složení s vyhodnocením tržních cen a prodejnosti. Tato má pak charakter informace pro rozhodnutí o vhodnosti řešení oddlužení formou splátkového kalendáře nebo prodejem majetku. Dílčí období od povolení oddlužení do jeho schválení je provázeno cílem insolvenčního správce splnit pokyny, které mu zadá insolvenční soud. Dále musí předložit podklady pro řádný průběh schůze věřitelů a přezkumné řízení, v němž budou zjištěny a potvrzeny pohledávky přihlášených věřitelů. Jednotlivé povinné práce insolvenčního správce v tomto období lze shrnout do několika bodů: • evidence dlužníka a jeho základní osobní údaje, • součinnost a zjišťování skutečností ověřujících pravdivost tvrzení obsažených v insolvenčním návrhu dlužníka, především jeho výše příjmů, • evidence věřitele a jeho identifikace, • přezkoumání jednotlivých nároků věřitelů přihlášených do insolvenčního řízení, • sestavení soupisu majetkové podstaty, • propočet výhodnosti způsobu řešení oddlužení dlužníka, • zpráva o hospodářské situaci dlužníka pro schůzi věřitelů, • přezkoumání jednotlivých nároků a jejich zaznamenání do přezkumných listů pro konané přezkumné řízení, • návrh stanovení zástupce věřitelů případně členů věřitelského výboru. Výsledkem soudního jednání je Usnesení o schválení oddlužení, které obsahuje způsob oddlužení, stanovení procentuálních nároků pro jednotlivá plnění pro nezajištěné věřitele, stanovení podmínek prodeje majetku zajištěného věřitele.


13

3 Materiál a metodika zpracování Pro tvorbu vlastního informačního systému byly po zhodnocení použity nástroje, které jsou volně dostupné ke stažení na internetu nebo ve verzi trial. Důvodem použití těchto nástrojů bylo, že jejich pořízení a užívání se obejde bez větších finančních prostředků a také skutečnost, že splňují požadavky pro tvorbu nového informačního systému.

3.1 UML Modelovací jazyk UML (Unified Modeling Language) je souhrnem grafických zobrazení k vyjádření analytických a návrhových modelů. Pomocí stejné formální syntaxe umožňuje modelovat jednoduché i složité aplikace, a proto přehledně a srozumitelně dokumentuje software a usnadňuje komunikaci mezi návrháři a zákazníky i mezi návrháři navzájem. Modely UML jsou pochopitelné i pro zadavatele aplikace, díky tomu umožní kvalitní vyjasnění požadavků uživatelů na vytvářený systém. Žádný modul nezachycuje systém jako celek, ale soustředí se vždy právě na konkrétní pohled na vyvíjený systém. UML je také jazykem pro vizualizaci, stavbu, specifikaci a dokumentaci softwarových systémů. Základem jazyka UML jsou CASE nástroje (Computer Aided Software Engineering). Jsou to nástroje pro podporu analýzy a návrhu aplikací. Při návrhu rozsáhlejších informačních systémů se bez použití těchto nástrojů nedá obejít. Díky Case nástrojům dochází k plnohodnotnému propojení jednotlivých technik UML, ke sdílení modelů mezi jednotlivými členy týmu a díky tomu i k podpoře týmové spolupráce. Většina dnešních CASE nástrojů podporuje také procesní modelování jako doplněk k technikám UML, díky tomu jsou ideálním nástrojem pro návrh informačních systémů. V rámci jediného prostředí dokáží identifikovat důležité diagramy UML (včetně procesního a datového modelu), které jsou potřebné pro analýzu a návrh informačních systémů. Široká škála firem si při navrhování středních a velkých informačních systémů vyvíjených týmy analytiků, designérů a programátorů již svou práci nedokáže představit bez podpory CASE nástrojů. Jedny z běžně užívaných CASE nástrojů jsou Rational Rose firmy Rational, Enterprise Architect firmy SparxSystems Software, Select Component Architect firmy Select Business Solution, PowerDesigner firmy Sybase, AllFusion firmy Computer Associates a další.


14

3.2 Enterprise Architect Enteprise Architect je nástroj pro tvorbu modelů založených na syntaxi UML. Nabízí vysoce kvalitní a výkonné prostředí pro řízení požadavků, návrh podnikové architektury, systémovou analýzu, strategické a business modelování (procesy, role, rizika apod.). Enteprise Architect podporuje tvorbu softwarového designu, generování kódu, zavádění systému do podniku, testování a mnoho dalšího. Podporuje i životní cyklus vývoje softwarových produktů. Je vhodný také pro nasazení v rozsáhlých týmech. (Dataprojekt s.r.o., 2013). Jak uvádí Sparx Systems (2013), v dnešní době má Enterprise Architect již více než 300 tisíc instalací po celém světě a je používán tisícovkou podniků od nadnárodních organizací až po menší nezávislé společnosti. Stal se také jedním z předních UML nástrojů pro vývojáře, poradce a analytiky. Výhody programu Enterprise Architect jsou: • modelování a řízení komplexních informací, • správa a sledování požadavků, • integrace týmů a sdílení jejich vizí, • navrhování a vývoj různorodých systémů s pomocí UML, • vizualizace, porozumění a možná kontrola komplexního často těžko pochopitelného softwaru, • navrhnutí uceleného životního cyklu řízení podniku, • sdílení a znovupoužití informací napříč různými nástroji programu. Enterprise Architect se odlišuje od ostatních nástrojů UML díky: • komplexnímu UML modelování, • vestavěnému řízení požadavků, • rozsáhlé podpoře projektového řízení zahrnující úkoly, kalendáře, • podpoře modelů založených na provádění testů řízení, • flexibilní možnosti dokumentace (HTML, RTF), • rychlosti, • dokáže snadno zpracovávat extrémně velké modely a množství uživatelů, • ceně (lze tímto programem vybavit celý vývojový tým, cena je efektivní z hlediska nákladů). Enterprise Architect dává možnost od počátku jednotlivých požadavků, až k zadání požadavku konečného, postupně tvořit proces, který lze analyzovat, testovat a implementovat. Enteprise Architekt prostřednictvím svých nástrojů, jako je např.


15

matice vztahů nebo hierarchický pohled, umožňuje kontrolu, zda je dodržen stanovený cíl (Dataprojekt s.r.o., 2013). Jak uvádí Enterprise Architect (2013) je Enterprise Architect určen pro různá odvětví IT. • Pro projektové manažery – Enterprise Architect poskytuje možnost sledovat celý proces vývoje od každého jednotlivého požadavku, přes analytické a designové modely až k testům a implementaci. Kdykoliv je možné provést efektivní ověřování, validaci a analýzu dopadu, a to prostřednictvím takových schopností nástroje Enteprise Architect, jako jsou matice vztahů nebo hierarchický pohled na element. • Pro analytiky požadavků – Řízení požadavků, které je součástí nástroje Enteprise Architect může být použito následovně: o Jednoduchým a přitom precizním způsobem zaznamenávat jednotlivé požadavky; o S použitím integrovaného workflow sledovat stavy požadavků (navržen, k revizi, schválen apod.); o Definovat a vytvořit hierarchický model požadavků; o Sledovat implementaci systémových požadavků (jejich přetvoření na odpovídající systémové modely); o Prohledávat a vytvářet reporty požadavků; o Provádět analýzy dopadu na navržené změny v požadavcích. Enterprise Architect nabízí veškeré potřebné funkčnosti pro správu požadavků, navíc obohacené o možnost propojovat požadavky s dalšími modely. • Pro týmy – Enterprise Architect pomáhá týmu vytvořit stabilní systém a je také nápomocný při řízení komplexnosti projektů v podniku. Díky funkčnosti pro reporting a dokumentaci se mohou sdílet vize napříč různými týmy. • Pro vývojáře – Enterprise Architect podporuje generování a zpětnou analýzu zdrojových kódů mnoha jazyků například C, C++, PHP, Java, Python, Delphi, ActionScript, Visual Basic a další. Obsahuje také editor zdrojových kódů, který umožňuje rychlou navigaci z modelů do zdrojového kódu, a to ve stejném uživatelském rozhraní s možností vytvářet a upravovat šablony pro generování zdrojových kódů, aby odpovídaly specifikacím podniku. • Pro správce projektových repositářů – Enterprise Architect je: o Rychlý a výkonný; o Je schopen nahrát extrémně rozsáhlé modely v několika sekundách;


16

o Obsahuje vestavěné úložiště modelů; o Umožňuje efektivně spolupracovat s týmy po celém světě díky schopnosti spojovat jednotlivé modely. • Pro databázové specialisty – Enterprise Architect podporuje modelování databázových struktur a automatické generování DDL skriptů pro jedenáct databází (InterBase,DB2, Informix, MySQL, Sybase ASE, ASA, Oracle, MS Access, Ingres, MS SQL Server, Firebird, Postgre SQL). Další databáze mohou být vytvořeny pomocí šablon přímo uživatelem. Enterprise Architect dokáže také načíst (reverzovat) datový model přímo z relační databáze. • Pro analytiky business procesů – Enterprise Architect podporuje mnoho přístupů k modelování business procesů. Například BPMN 2, Eriksson-Penker Business Process Model, diagramy aktivit, objektové diagramy a další. Enterprise Architect propojuje UML 2.4 s podporou BPMN 2 a dalšími elementy pro řízení procesů a požadavků. Umožňuje například modelovat vztahy procesů mezi sebou a mnoho dalšího. • Pro specialisty na dokumentaci – Enterprise Architect poskytuje komplexní generátor dokumentace a reportů s plným WYSIWYG editorem šablon. Díky tomu mohou být generovány detailní reporty s informacemi ve formě, kterou podnik nebo klient vyžaduje. Distribuce prostřednictvím Internetu je zajištěna díky možnosti exportu do HTML. • Pro systémové architekty – Enterprise Architect je pro systémového inženýra jedinečný nástroj pro návrh komplexních systémů a jejich integraci. Integraci poskytují edice Enteprise Architect Ultimate a Enteprise Architect System Engineering, které podporují: o SysML; o Parametrické simulace modelů; o Generování spustitelného kódu; o Transformace z modelu do kódu pro jazyk "Hardware Description Languages" a ADA 2005. Enterprise Architect podporuje různé modely. Patří mezi ně například Business Process Model, Use Case model, Class model, Activity model, Sequence model, Component model a další. Výstupy jsou ve formátu RTF pro dokumentaci a ve formátu XML, díky kterému dokáže spolupracovat s ostatními programy (Enterprise Architect, 2013).

3.3 Modely programu Enterprise Architect V návrhu vlastního informačního systému byly popsány a použity pouze modely programu Enterprise Architect potřebné ke zpracování analýzy práce insolvenční


17

kanceláře. Tyto modely dostatečně analyzovaly potřeby, požadavky a celkový stav kanceláře pro administrativu insolvenčního správce. 3.3.1

Use Case Model

Jak uvádí Sparx Systems (2000-2013), Use Case (případ užití) popisuje použití funkce nového systému a reprezentuje interakci mezi uživatelem (člověk, stroj) a systémem. Use Case (případ užití) znázorňuje logické seskupení procesů a komponentů k dosažení požadovaného výsledku. Pomocí aktérů definuje uživatele nebo systémové role, které se účastní procesu. Obsah Use Case modeluje: • obecné poznámky popisující Use Case, • požadavky – funkční požadavky poskytnuté konečným uživatelem pro Use Case, • omezení a pravidla – formální pravidla a omezení Use Case, vymezení toho, co může a nemůže být provedeno, • scénáře – formální, sekvenční popisy kroků, nebo tok událostí, ke kterým dochází v průběhu návrhu Use Case, • scénáře diagramů – sekvence diagramů, které popisují pracovní postup. Prvky Use Case modelu: • aktér – popisuje uživatele vně systému, který je v interakci s Use Case. Tímto uživatelem nemusí být pouze fyzická osoba, ale například i jiný systém či hardwarové zařízení. Jeho název pak vyjadřuje jeho roli v systému (Buchalcevová a další, 2007), • „část funkcionality systému, kterou využívá aktér a která plní určitý cíl.“ (Buchalcevová a další, 2007). Je charakterizována množinou scénářů případů užití prováděných za stejným cílem, tedy sekvencí kroků popisující interakci uživatele se systémem (Fowler, 2003), • typy vztahů mezi aktérem a Use Case - include (stejný případ užití na více místech při opakování, extend (nadstandardní případ užití při splnění dané podmínky) a generalizace/specializace. Tento poslední typ vztahu je používán také mezi aktéry, kdy umožňuje znázornit návaznost jednotlivých aktérů (Sparx Systems, 2000-2013b).


Obr. 1 Zdroj:

Příklad Use Case modelu Sparx Systems, 2000-2013b

3.3.2

Eriksson-Penker Business Process Model

18

Je model, který je snadno srozumitelný všem obchodním uživatelům, obchodním analytikům, kteří tvoří počáteční návrhy procesů, technickým vývojářům odpovědným za technologie, které budou provádět tyto procesy, a konečně obchodníkům, kteří budou řídit a sledovat tyto procesy (Sparx Systems, 2007).

Obr. 2 Zdroj:

Příklad Business Process Modelu Sparx Systems, 2007

Obchodní Proces (Businness Process) je soubor činností, jak uvádí Sparx Systems (2007), jejichž cílem je dosáhnout určitých výstupů pro konkrétní zákazníky nebo trh.


19

• Má cíl (goal) – objekty, představující cíle daného procesu. Cílem je např. spokojenost zákazníka a kvalitní produkce (Štencl, 2007). • Má konkrétní vstupy (input) – objekty, které jsou procesem spotřebovány nebo přetvářeny. Jsou jimi všechny druhy surovin, lidské zdroje nebo i informace (Štencl, 2007). • Má konkrétní výstupy (output) – objekty, které jsou výsledkem nebo produktem procesu (Štencl, 2007). • Využívá zdroje, podpůrné objekty (supply) – suroviny, informace, které jsou procesem užívány, ale nejsou spotřebovány ani přetvářeny (Štencl, 2007). • Má celou řadu činností, které jsou prováděny v určitém pořadí, událost (event) – uvádí objekt, který je předán do obchodního procesu k dalšímu zpracování (Sparx Systems, 2000-2013a). 3.3.3

Model požadavků

Shromažďování požadavků je zpravidla prvním krokem ke správnému vývoji řešení, ať už softwarové aplikace nebo obchodního procesu. Požadavky jsou v podstatě to, co systém musí řešit (Sparx Systems, 2013). Požadavky se dělí, jak uvádí Flek (2011) na: • funkční požadavky – určují, jaké chování nebo jaké služby bude systém nabízet, • nefunkční požadavky – specifikují vlastnosti nebo omezující podmínky daného systému. Požadavky mohou být seskupovány a organizovány v rámci diagramů potřeb. Požadavky jsou navzájem propojeny agregačním vztahem a tvoří hierarchii.

Obr. 3 Zdroj:

Příklad Modelu požadavků Sparx Systems, 2000-2011b

Je obvyklé vytvářet stovky požadavků uspořádaných do hierarchií v různé míře složitosti, jako je znázorněno na obr. 4 (Sparx Systems, 2000-2011b).


Obr. 4 Zdroj:

Hierarchie požadavků Sparx Systems, 2000-2011b

3.3.4

Kontrolní model

20

Je to model sloužící ke kontrole napojení jednotlivých požadavků mezi sebou a ke kontrole jejich užití tak, aby byly v systému naimplementovány a řešily zadání. Požadavky jsou implementovány podle modelů prvků, jako jsou např. Use Case. Existuje mnoho způsobů, jak zobrazit a zadat buď požadavek na funkci daného prvku, nebo vztahy mezi jednotlivými prvky, nebo další prvky, které rozvíjí zadané požadavky. Kontrolu mezi napojením všech prvků s cílem splnit zadané požadavky řeší Kontrolní model. Požadavek může být splněn jedním nebo více možnostmi řešení (Use Case) a dané řešení může realizovat jeden nebo více požadavků. Zatímco požadavek definuje zadání, které musí být splněno, samotné řešení (Use Case) je klíčem k definování a zobrazení, jak tato podmínka bude splněna.


Obr. 5 Zdroj:

21

Příklad Kontrolního modelu Sparx Systems, 2000-2011a

3.4 MySQL MySQL (My Structured Query Language) je relační databáze typu DBMS (database managment system) a vychází z deklarativního programovacího jazyka SQL (Structured Query Language). Tato databáze je šířena jako Open Source. MySQL je díky své rychlosti a jednoduchosti jedním z nejoblíbenějších databázových systémů. Do MySQL lze ukládat různá data (texty, soubory, obrázky atd.), s nimiž lze dále jednoduše pracovat (třídit, řadit, filtrovat apod.). Nejčastější užití MySQL je ve spojení s jazykem PHP, který umožňuje přístup k uloženým datům. Každá databáze v MySQL obsahuje tabulky, každá tabulka má sloupce a řádky a v každém řádku jsou záznamy předem určeného typu. Práce s tímto systémem se dá využít v C, C++, Java, Perl, PHP, Python, Visual Basic a v dalších. Pro jednoduchou správu MySQL databází se používá nástroj PhpMyAdmin. PhpMyAdmin je Open Source program napsaný v PHP a je to pokročilý nástroj pro kompletní správu MySQL systému přes webové rozhraní (Artic Studio, 2011).


22

3.5 Insolvenční rejstřík Insolvenční rejstřík je novým informačním systémem veřejné správy. Jeho základní úlohou je zajistit maximální míru publicity o insolvenčních řízeních a umožnit sledování jejich průběhu. Prostřednictvím insolvenčního rejstříku jsou zveřejňovány veškeré relevantní informace týkající se insolvenčních správců, dokumenty z insolvenčních spisů i zákonem stanovené informace týkající se dlužníků. Insolvenční rejstřík je veřejně přístupný (Ministerstvo spravedlnosti, 2008). Insolvenční rejstřík zajišťuje, jak uvádí Ministerstvo spravedlnosti (2008): • publicitu (každý včetně účastníků bude moci sledovat průběh insolvenčního řízení), • transparentnost (všechna řízení budou muset být zveřejňována), • veřejnou kontrolu (díky zveřejňování insolvenčních řízení je snazší přístup k informacím), • rychlost řízení (účastníci a zúčastněné osoby mají rychlejší přístup k informacím), • doručování (v některých případech se prostřednictvím insolvenčního rejstříku i doručuje).

3.6 Nette Framework a Model-View-Controller Jak uvádí Nette Foundation (2011), je Nette Framework velice výkonným frameworkem pro vytváření webových aplikací v PHP 5. Jedním z předností tohoto frameworku je znovupoužitelnost kódu, eliminace bezpečnostních rizik, výkon frameworku (rychlost zpracování dat), čistý a promyšlený objektový návrh využívající nových vlastností PHP 5, propracovaná podpora všech moderních technologií a koncepcí (Ajax/Ajaj, SEO, DRY, KISS, MVC, Dependency Injection a další), přehledná struktura kódu a další. Nette Framework vychází z architektury ModelView-Controller (MVC). Model-View-Controller (MVC) je softwarová architektura. Vznikla z nutnosti oddělení kódu obsluhy (controller) od kódu aplikační logiky (model) a od kódu zobrazujícího data (view). Díky tomu aplikace usnadňuje budoucí vývoj a umožňuje testování jednotlivých částí postupně a dochází ke zpřehlednění kódu. Jednotlivé části Model-View-Controller (MVC) jsou: • controller – řadič, který zpracovává požadavky uživatele a na jejich základě volá patřičnou aplikační logiku (model) a poté žádá o vykreslení dat (view). Obdobou v Nette Frameworku jsou presentery,


23

• model – funkční datový základ celé aplikace. Je v něm obsažena aplikační logika, jakákoliv akce uživatele představuje akci modelu. Model o existenci view nebo controller neví. Dochází v něm ke správě vnitřních stavů a vně nabízí pevně dané rozhraní, • view – je vrstva aplikace, která má na starost zobrazení výsledku požadavku. View obvykle používá šablonovací systém (vytvoření šablon v controlleru/presenteru) a ví, jakým způsobem se má zobrazit komponenta nebo výsledek získaný z modelu.

3.7 Situační analýza a SWOT analýza Situační analýza je rozbor postavení firmy a faktorů, které působí. Analýza se snaží podchytit všechny rozhodující vlivy, které vytvářejí podmínky pro podnikání, proto se zaměřuje nejen na vnitřní faktory (počet a kvalita pracovníků, vybavení, finanční zdroje), ale i na faktory vnější (konkurence, zákazníci, partnerské firmy, ekonomická situace státu, právní rámec). K účelu vyčlenění faktorů působících na danou firmu v daném období se užívá tzv. SWOT analýzy, rozbor slabých a silných stránek, příležitostí a rizik firmy (Strenghts, Weakness, Opportunities, Threats). Silné a slabé stránky se vztahují k mikroprostředí, snaží se rozpoznat činitele, které mohou mít nebo mají vliv na úspěch nebo naopak nezdar a které můžeme ovlivnit, protože pramení z vnitřního prostředí firmy (technologie a výrobní zařízení, personální faktory, kvalita managementu, kvalifikace, financování, marketingová síla firmy). Příležitosti a rizika vyplývají z makroprostředí firmy a to buď z makroprostředí vnějšího, které nemá firma možnost ovlivnit (ekonomický vývoj státu, legislativní opatření, ceny vstupů), nebo z makroprostředí vnitřního, jehož vývoj může firma ovlivnit pouze částečně (síla konkurence, dodavatelské vztahy, veřejnost, zákazníci), (Kolář a další, 2006).


Obr. 6

24

SWOT analýza

Jak je znáno, podstata metody spočívá v klasifikaci a taxonomickém ohodnocení čtyř skupin faktorů, přičemž analýzou vzájemné interakce jednotlivých faktorů silných a slabých stránek na jedné straně vůči příležitostem a nebezpečím na straně druhé lze získat nové kvalitativní informace o pozici analyzované firmy v konkurenčním prostředí. Přitom jsou faktory vyjadřující sílu nebo slabost vztahovány k vnitřní stránce firmy, příležitosti a nebezpečí pak k vnějšímu prostředí (Kašík, 1998).

Obr. 7

Rozdělení SWOT analýzy


25

4 Analýza současného stavu 4.1 Osobní bankrot v číslech roku 2012 Ministerstvo spravedlnosti ČR zveřejnilo na svých stránkách statistiky insolvenčních řízení za rok 2012 nárůst insolvenčních agendy oproti předchozím rokům o 33%. Nejvyšší nápor byl zaznamenán právě u Krajského soudu v Brně a Ostravě. Lze předpokládat, že v roce 2013 bude k insolvenčním soudům podáno více jak 38000 návrhů (Konkursní noviny, 2013). Tab. 1

Osobní bankrot v číslech roku 2012

Krajský soud Ostrava Krajský soud Brno Městský soud Praha Krajský soud Praha Krajský soud Ústí nad Labem Krajský soud v Hradci Králové Krajský soud v Českých Budějovicích Krajský soud Plzeň

Podané insolvenční návrhy 17088 15775 9641 7647 13749 10480 4761 8905

Rozhodnutí o úpadku 10781 5988 3385 4435 8883 7191 2570 6127

Úpadek dlužníka byl na základě podaného insolvenčního návrhu zjištěn pouze v 56% případů. Nejmenší podíl rozhodnutí o úpadku na počet podaných insolvenčních návrhů má Městský soud v Praze a Krajský soud v Brně. Smutný primát v rámci odmítání insolvenčních návrhů drží Městský soud v Praze, u kterého bylo odmítnuto 32% všech podaných insolvenčních návrhů a Krajský soud v Brně 27% odmítnutými insolvenčními návrhy. Věřitelské insolvenční návrhy představují jen necelých 10% všech podaných a 90% podává dlužník sám (Konkursní noviny, 2013).


Obr. 8

Graf podaných insolvenčních návrhů v roce 2012

Obr. 9

Graf rozhodnutí o úpadku v roce 2012

26

Z hlediska rozhodování o způsobu řešení úpadku dlužníka jde o způsob oddlužení, prohlášením konkurzu na majetek dlužníka nebo povolení reorganizace dlužníka.


27

Zcela dominantní řešení úpadku se svými 85% je oddlužení, konkurzem je řešen úpadek u 14% dlužníků a způsob reorganizace u 1% úpadku.

Obr. 10

Graf způsobu řešení úpadku v roce 2012

Z hlediska řešení formy oddlužení dlužníka zůstává převažující formou splátkový kalendář nad formou zpeněžení majetku dlužníka, a to v poměru 97% a 3%.

Obr. 11

Graf formy řešení oddlužení v roce 2012

Má práce vychází z výše uvedených předpokladů a je orientována na úpadek dlužníka a jeho řešení formou oddlužení pří způsobu řešení splátkovým kalendářem, což je nejčastějším řešením insolvence.


28

4.2 SWOT analýza informačních systémů nabízených na trhu S přibývajícím počtem insolvenčních řízení každý insolvenční správce uvažuje, jak co nejlépe zorganizovat práci ve své kanceláři. Optimálním řešením je nástroj pro evidenci a přehled dat, organizaci úkolů, termínů, pohled na všechna řízení. To vedlo ke vzniku nového nabízeného produktu na trhu tj. informačního systému pro práci insolvenčního správce. 4.2.1

SWOT analýza vnějšího prostředí

Marketing v oblasti informačního systému pro insolvenčního správce lze posoudit v analýze vnějšího prostředí příležitostí a hrozeb trhu. Marketingové příležitosti, tzv. oblast zákaznických potřeb, z jejichž uspokojování může vznikat profit (Kotler, 2001), lze obecně pro všechny informační systémy insolvencí shrnout do bodů: • přijetí nové legislativy v oblasti úpadkového práva – insolvenční zákon a řešení oddlužení občanů, • zpřísnění kvalifikačních předpokladů pro výkon insolvenčního správce a tím snížení počtu insolvenčních správců a zvýšení četnosti případů každého z nich, • prolomení tradiční písemné formy, vedení spisového materiálu s podáním elektronickým s možností elektronického spisu, příležitost pro informační systémy spolupracující v oblasti justice, • insolvenční rejstřík, veřejná databáze Ministerstva vnitra, • namáhavost vedení agendy insolvenční kanceláře tradičním způsobem, • navýšení četností případů nutí insolvenční správce řešit situaci přijetím nových pracovníků, což se projevuje ve zvýšení mzdových nákladů, které převyšují cenu dostupnou na trhu při řešení pomocí informačního systému, • hlubší a delší hospodářská recese a navýšení dluhových pastí v řadách občanů ČR. Marketingové hrozby, tzv. nepříznivé vývojové trendy ve vnějším prostředí, ohrožení prodeje nebo zisku (Kotler, 2001) lze obecně pro všechny informační systémy insolvencí shrnout do bodů: • rozšíření nabízených produktů bank řešících problémy zadlužených občanů revitalizace úvěrů, • vznik jednotného informačního systému státem – Ministerstvem vnitra, převzetí produktu do centrálního řízení, • změna v organizaci rozdělení četnosti insolvencí a přidělování řízení mezi insolvenční správce a jejich opětovný nárůst, čímž se objem práce sníží.


29

Na českém trhu jsou známy dva produkty. Pro jejich zhodnocení je použita analýza SWOT. Jde o komplexní zhodnocení silných a slabých stránek spolu s hodnocením příležitostí a hrozeb. 4.2.2

SWOT analýza vnitřního prostředí

Analýza vnitřního prostředí (silných a slabých stránek) informačního systému Insolvenční Správce: Tab. 2

Silné stránky informačního systému Insolvenční Správce

Silné stránky + + +

+

+ +

+

+

Tab. 3

Urychlení práce Tým spolupracovníků z řad IT specialistů a zároveň z řad bývalých soudních úředníků Komplexní software, není pouze evidencí jednotlivých případů, má vazby na předcházející případy Uživatelská podpora, školení, konzultace, přímá vazba na jednotlivé správce a jejich připomínky, které jsou zapracovávány v aktuálním čase do systému Modulový systém pro konkurzy, likvidace, oddlužení, jediný software, který se pokouší o řešení informačního systému pro likvidace Univerzálnost software pro práci v insolvenci určen pro práci všech insolvenčních správců, na všech soudech řešících insolvence Celá agenda u dodavatele na jednom místě on-line, v jednom místě s napojením z různých míst umožňuje kvalitní informační systém u správců, kteří mají více poboček v jednotlivých okresech Obsahuje systém organizér práce a termínů, zdárně je schopen kontroly plnění úkolů v čase s kontrolou plnění úkolů zadaných soudem ve vazbě na informační systém insolvenčního rejstříku

Slabé stránky informačního systému Insolvenční Správce

– – – –

Slabé stránky Jsou zbytečně evidovány skutečnosti, které zákon řeší ve vyjímečné situaci Není ponechána volnost uživateli samostatně dle svých znalostí doplňovat a vytvářet sestavy Členění přihlášených nároků věřitelů je nedostatečná, není upřesněna na zajištěné a nezajištěné, stejně jako vykonatelnost Nepřehledná grafika a úprava, sestavy jsou složité, obsahují více variací, které komplikují přehlednost


–

–

–

30

Chybí napojení na živnostenský a obchodní rejstřík, pouhé řešení ve vazbě na insolvenční rejstřík je nedostatečné Chybí databáze členů věřitelského výboru, databáze soudů a jejich asistentů, při komunikaci s věřitelským výborem je nutno manuálně vyhledávat Vedení práce a podřízenost uživatele vede k bezmyšlenkovitému pořizování dat, naopak při snaze vlastních vědomostí začlenit do systému narážíme na předem dané šablony

Analýza vnitřního prostředí (silných a slabých stránek) informačního systému IS-IR: Tab. 4

Silné stránky informačního systému IS-IR

Silné stránky + + + + +

+

+

+ + + Tab. 5

Urychlení práce Tým odborníků v IT spolupracujících s praxí reprezentující insolvenční správce Graficky velmi dobře upravený a přehledný Program si pamatuje věřitele z předchozího zadání, stačí zadat pouze IČ a program si věřitele vyhledá sám Samostatné vytvoření přezkumných listů, samostatné vytvoření soupisu majetkové podstaty Jednoduché ovládání – základní nastavení je předdefinováno, zapisují se pouze výjimky (např. je předdefinováno, že pohledávka je nepodřízená, peněžitá, bezpodmíněná) Program je napojený na insolvenční rejstřík a v situaci kdy dostaneme novou insolvenci, v kolonce nové spisy se zobrazí nové insolvenční řízení Automatické založení spisu (nemusíme vypisovat veškeré údaje o dlužníkovi-data jsou převzaty z insolvenčního rejstříku) Spolupráce více pracovníků na jednom spisu Modeluje základní součinnosti

Slabé stránky informačního systému IS-IR

– –

Slabé stránky Nelze nastavit (např. pro 5 oddlužení) hromadné vygenerování součinností pro banky, katastr, atd.. V programu nelze nastavit, které informace v soupisu majetkové podstaty chci a které nechci


– – –

–

–

–

31

Zbytečně podrobný soupis majetkové podstaty V přezkumných listech u podpisu soudce nevypisuje program jméno konkrétního soudce, který má dané insolvenční řízení na starosti Program nevypisuje do přezkumných listů splatnost – musí se dopsat manuálně Popírá-li insolvenční správce dílčí pohledávku, přičemž dílčí pohledávku uznává, program do přezkumných listů automaticky napíše, že insolvenční správce uznává celou pohledávku Má-li věřitel více dílčích pohledávek, uživatel programu musí manuálně překopírovat jednotlivé právní tituly do pohledávky, stejné i v případě rozhodnutí u vykonatelných pohledávek Celá agenda vedena na jednom místě pro jednu insolvenční kancelář, data v místě insolvenčního správce

Analýza vnitřního prostředí (silných a slabých stránek) informačního systému vlastní návrh informačního systému – konkrétní insolvenční kancelář. Tab. 6

Silné stránky informačního systému Insolvenční kancelář

Silné stránky + + + + +

+

+ + Tab. 7

Urychlení práce Základní informační systém předem vypracovaný při vlastní a konkrétní aplikaci u daného zákazníka Jednoduchá a přehledná grafika Vyžaduje aktivní přístup nikoliv pasivitu uživatele Program respektuje požadavek uživatele nad jeho podřízeností Informačního systému Vysoká variabilita a uplatnění vlastních znalostí uživatele dle vlastních požadavků s ohledem na specifika nejen jednotlivých soudů ale i jejich senátů Celá agenda vedena na jednom místě pro jednu insolvenční kancelář, data v místě insolvenčního správce Jednoduché ovládací prvky

Slabé stránky informačního systému Insolvenční kancelář

– – –

Slabé stránky Časová a finanční náročnost pro vývoj informačního systému, není vytvořen tým pracovníků, je řešeno samostatně Konkurence dvou celostátně působících informačních systémů Prozatím pouze orientován na problematiku oddlužení


– – –

32

Malá zkušenost a neexistující zpětná vazba od více uživatelů než od zadavatele Základní znalost insolvenčního zákona a jeho aplikací v praxi Malá zkušenost s tvorbou informačních systémů, ale je předpoklad z dalšího studia a zájmu o problematiku tyto zkušenosti získávat rozšiřovat a aplikovat pro zákazníka

4.3 Analýza kanceláře insolvenčního správce Byla provedena analýza kanceláře insolvenčního správce, která zajišťuje veškerou administrativu insolvenčnímu správci. Kancelář má ve své správě evidenci přidělených insolvenčních řízení v počtu 70. Převaha řízení je oddlužení splátkovým kalendářem a délka vedeného řízení je v průměru dvacátý měsíc řízení ze zákona stanovených 5 let. Uvedenou agendu obsluhují dva pracovníci, jeden pro správu oddlužení a komunikace s dlužníkem a druhý pro správu s věřiteli. Insolvenční správce je hlavním odborníkem v celkovém procesu řízení a využívá spolupráce se svými pracovníky a vytváří metodiku pro jejich práci. Současný stav je vedení jednotlivých spisů ručně při využití informací z insolvenčního rejstříku a práci na PC v programech Word, Excel. Analýza kanceláře byla zpracována v programu Enterprise Architect 10. 4.3.1

Model požadavků

Obr. 12

Model požadavků insolvenční kanceláře

Požadavkem je zpracování informačního systému, který má obsahovat databázi informací jak dlužníka, tak věřitelů a současně má zabezpečit kontrolu plnění lhůt a úkolů. Výstupem má být podklad pro dvě jednání konaná před soudem a to schůze věřitelů za účasti dlužníka a přezkumné jednání. Jednání schůze věřitelů rozhoduje z podkladů informačního systému a to dokumentu nazvaném Zpráva o hospodářské situaci dlužníka a dokumentu Sdělení o způsobu řešení oddlužení.


33

Jednání tzv. přezkumné vyžaduje doklady zvané přezkumné listy věřitelů, podle kterých je uznán nárok přihlášený věřitelem do insolvenčního řízení. K hlavnímu požadavku pro splnění cíle, databáze dlužníka, databáze věřitelů, kontrola lhůt a úkolů, byly zadány dílčí požadavky a to vytvoření databáze soudců a jejich úředníků s označením příslušných řízení, databáze konkrétních věřitelů daného dlužníka, majetková podstata dlužníka, příjmy dlužníka a přezkumné listy věřitelů.

Návrhová část

34

5 Návrhová část Návrh dílčí části informačního systému se zaměřuje na jednotlivé prvky a činnosti potřebné pro vedení administrativy při práci insolvenčního správce. Vlastní návrh informačního systému pro administraci řeší část insolvenčního řízení od povolení oddlužení do schválení oddlužení a kontrolu tohoto procesu. Celý informační systém je rozdělen do tří modulů, které pracují nezávisle mezi sebou (tyto moduly jsou dále popsány v kapitole 5.5.1). • Databáze dlužníků • Databáze věřitelů • Databáze soudců a jejich úředníků Nezbytné součásti informačního systému: • založení karty dlužníka, • založení karty věřitelů pro jednotlivé dlužníky, • UPLOAD jednotlivých šablon pro oddlužení (majetková podstata, přezkumné listy, Zpráva o hospodářské situaci, Sdělení o způsobu oddlužení), • DOWNLOAD a tisk tiskových sestav jednotlivých dlužníků pro následné odeslání na soud, • ukládání historie vložených souborů do systému, • sledování lhůt pro odeslání tiskových sestav, • kontrola nahraných a zpracovaných souborů, • kontrola stavu řízení dlužníka, • kontrola činnosti pracovníků.

5.1

Use Case

Po důkladné analýze chodu kanceláře insolvenčního správce a sepsání veškerých potřebných požadavků byl navržen diagram Use Case, ve kterém jsou zobrazeni jednotliví aktéři, jednotlivé případy užití (Use Case – definice činností plnící zadané požadavky) a veškeré návaznosti mezi nimi.

Návrhová část

Obr. 13

35

Use Case model insolvenční kanceláře

Uživatelé – aktéři (insolvenční správce, asistent pro komunikaci s dlužníky, asistent pro komunikaci s věřiteli). Insolvenčního správce, který svou odborností je hlavním článkem tvořícím obsahovou stránku informačního systému a na základě jeho pokynů a požadavků je informační systém aktualizován v souladu s legislativou prostřednictvím ostatních aktérů. Tato asociace mezi aktéry, tok informací probíhá nepřetržitě. Má do informačního systému plný přístup, jeho vlastní práce se systémem je zaměřena na využití informací a výstupů ze systému pro své další rozhodování a vedení insolvenčního řízení. Asistent pro komunikaci s dlužníky, který svou odborností je dílčím článkem v komunikaci s dlužníkem, zodpovídá za zavedení spisové značky dlužníka do systému, zadávání dat do informačního systému v databázi dlužníka a připravuje výstupy pro kompletaci podkladů pro řízení na jednání schůze věřitelů. Asistent pro komunikaci s věřiteli, který svou odborností je dílčím článkem v komunikaci s věřiteli, zodpovídá za zadávání dat do informačního systému v databázi věřitelů a připravuje výstupy pro kompletaci podkladů pro přezkumné řízení pro nároky přihlášené věřiteli a je garantem zadání termínů a úkolů do informačního systému tak, aby odpovídaly lhůtám vyplývajícím z insolvenčního zákona i vnitřním úkolům zadaných insolvenčním správcem.

Návrhová část

36

Scénář případů užití (Use Case) od uživatelů přes informační systém k zadanému cíli tvoří jednotlivé části informačního systému. Tyto dílčí částí informačního systému plní zadané požadavky a tvoří funkční celek. Dílčí část databáze dlužníka je částí, která obsahuje kartu dlužníka, veškeré informace o osobě dlužníka, identifikační údaje, bydliště, rodinné a majetkové poměry, kontaktní údaje, zadání spisové značky z databáze jednotlivých senátů soudu, určuje se i jméno soudce a soudního úředníka. Dílčí část majetková podstata je řešena formou šablony pro zadání do dokumentu. Jde o stejný druh šablony případ užití pro všechny zadané dlužníky. Dílčí část databáze věřitelů obsahuje veškeré informace o věřiteli, identifikační údaje, sídlo, bydliště, kdo jedná za věřitele, zastoupení, kontaktní údaje. Dílčí část přezkumné listy je řešena formou šablony pro zadání do dokumentu, ve kterém je řešen již konkrétní nárok věřitele a podmínky jeho přihlášení, které jsou specifické u každého dlužníka a výše odsouhlaseného nároku dlužníkem i insolvenčním správcem.

5.2 Procesní model

Obr. 14

Business Process Model insolvenční kanceláře

Procesní model na obr. 14 ukazuje vnější prostředí informačního systému pro insolvenční kancelář.

Návrhová část

37

Cílem informačního systému je vytvoření databáze dlužníka a jeho věřitelů při splnění podmínky dodržení insolvenčního procesu řízení a ním stanovených lhůt, stejně jako předložení daných výstupů v souladu se zákonem. Podpůrčí vstupy jsou charakteru, který je v informačním systému užíván a není dále zpracováván, (supply) jimiž jsou insolvenční rejstřík, obchodní rejstřík, samotný návrh dlužníka podaný na soud při zahájení řízení, součinnost jednotlivých institucí poskytujících informace o majetku dlužníka (katastrální úřady, centrální evidence vozidel, centrální evidence cenných papírů, stavy na jednotlivých účtech bankovních ústavů, pojišťoven, informace z finančních úřadů, sociální pojišťovna, jednotlivé zdravotní pojišťovny). Vstupy jsou charakteru, který je v informačním systému dále zpracováván a pro potřeby insolvenčního správce a další jeho činnosti (input), jimiž jsou potvrzení příjmu dlužníka jeho zaměstnavatelem, potvrzení rodinného stavu dlužníka, vlastní zjištění insolvenčního správce o majetkových poměrech dlužníka, přihláška věřitele do řízení označena číselnou řadou věřitele do řízení, doplnění přihlášky věřitele. Událostí (event), která je úvodní informací do informačního systému, je samotné zahájení insolvenčního řízení a Rozhodnutí soudu o povolení oddlužení. Tímto okamžikem je ustanoven do funkce insolvenční správce a pokyny soudu obsahují základní a neměnné požadavky na jeho práci. Každé z insolvenčních řízení je označeno spisovou značkou označující daný soud řešící insolvenci, senát a označení číselné dlužníka a rok zahájení řízení.

5.3 Kontrolní model Kontrolní model aplikovaný na konkrétní zadání (obr. 15) ověřil správnost napojení jednotlivých požadavků a to jak hlavního, tak dílčích na model případů užití prvků (Use case). Řešení předložené v této práci je jednou z možností řešení, jak splnit daný cíl.

Návrhová část

Obr. 15

38

Kontrolní model insolvenční kanceláře

5.4 Použitá technologie Vývoj informačního systému probíhal v prostředí webového serveru WAMP, který umožňuje vytvářet webové aplikace s pomocí Apache serveru (zde ve verzi 2.2.22), jazyka PHP (zde ve verzi 5.3.13) a jazyka MySQL (zde ve verzi 5.5.24). WampServer také umožňuje použít interní databázi, kterou lze spravovat pomocí nástroje phpMyadmin, který podporuje širokou škálu operací v MySQL (Mikláš, 2013). Pro Grafické prvky a celkový vzhled informačního systému bylo využito frameworku Bootstrap (verze 2.3.1), který podporuje novou formu stylování CSS3 a jazyk HTML5. Pro samotnou implementaci informačního systému bylo využito frameworku Nette (verze 2.0) a pro samotnou implementaci databáze v MySQL bylo využito nástroje phpMyAdmin, který je součástí balíčku WAMP server. Dále bylo využito vývojového prostředí (IDE) Netbeans (verze 7.0.1) a editoru PSPad (verze 4.5.6).

5.5 Struktura informačního systému Implementace dílčího informačního systému pro insolvenčního správce vytvořeného v jazyce PHP za pomocí frameworku Nette by svým rozsahem překročila rá-

Návrhová část

39

mec této práce. Proto další část této kapitoly popisuje hlavní prvky dílčího informačního systému, které řeší požadavky zadané insolvenčním správce. Tam, kde to vyžaduje detailnější vysvětlení, bude popis doplněn o zobrazenou implementaci. 5.5.1

Rozdělení informačního systému do modulů

Tak jak bylo v kapitole 5 uvedeno, je celý systém rozdělen do tří modulů, které pracují nezávisle jeden na druhém. Tyto moduly jsou však navzájem propojeny mezi sebou: • Databáze dlužníků – hlavní modul informačního systému – obsahuje řešení většiny požadavků insolvenčního správce. Dochází zde: o K založení dlužníka podle jeho spisové značky; o K založení karty dlužníka (jméno, bydliště, zaměstnání, zaměstnavatel, výše příjmu, přidělení soudce a insolvenčního správce, stav dlužníka a další); o K založení karty věřitele (přidání věřitelů z databáze věřitelů ke konkrétnímu dlužníkovi a kontakt na zástupce věřitele, je zde uvedena i výše pohledávky vůči dlužníkovi); o K možnosti stažení, následného nahrání a kontrole průběhu stavu zpracování šablon potřebných pro tisk tiskových sestav (Soupis majetkové podstaty, Sdělení ke způsobu řešení oddlužení, Zpráva o hospodářské situaci dlužníka); o Ke kontrole lhůt a termínů, které jsou zaslané soudem insolvenčnímu správci (povinností insolvenčního správce je tyto lhůty dodržovat); o Ke kontrole a následnému tisku tiskových sestav jednotlivých dlužníků pro následné odeslání na soud; o Ke kontrole činnosti zaměstnanců (dochází ke kontrole stavu zpracování a času zpracování šablon díky ukládání jména z přihlašování do příslušné tabulky); o Ke kontrole stavu řízení (kontrola je možná díky napojení informačního systému na veřejný insolvenční rejstřík ISIR). • Databáze věřitelů – dochází zde: o K založení věřitele (jméno, příjmení, fyzická/právnická osoba, rodné číslo/IČO, adresa); o K možnosti přidání zástupce věřitele. • Databáze soudců a jejich úředníků – dochází zde:

Návrhová část

40

o K založení soudce (jméno, číslo senátu); o K založení úředníků příslušného soudce (jméno, kontakt). 5.5.2

Přihlášení do systému

Přihlášení do informačního systému je možné díky naimplementovanému přihlašovacímu formuláři SignInForm a formuláři SignInFormSubmitted, který je zavolán při potvrzení formuláře SignInForm tlačítkem Odeslat. Formulář SignInFormSubmitted obsahuje také metodu remember, ve které je naimplementována funkce pro uložení přihlašovacích údajů. Při potvrzení tlačítka (Zapamatovat si), si funkce pamatuje přihlašovací údaje po dobu 30 dní, pokud toto tlačítko nepotvrdíme, funkce uchovává údaje po dobu 120 minut. protected function createComponentSignInForm() { $form = new UI\Form; $form->addText('username', 'Uživatel:') ->setRequired('Vyplňte prosím toto pole'); $form->addPassword('password', 'Heslo:') ->setRequired('Vyplňte prosím toto pole'); $form->addCheckbox('remember', 'Zapamatovat si'); $form->addSubmit('send', 'Sign in'); // zavolá metodu signInFormSubmitted() pro potvrzení $form->onSuccess[] = $this->signInFormSubmitted; return $form; } public function signInFormSubmitted($form) { $values = $form->getValues(); if ($values->remember) { $this->getUser()->setExpiration('+ 30 days', FALSE); } else { $this->getUser()->setExpiration('+ 120 minutes', TRUE); } try { $this->getUser()->login($values->username, $values->password); } catch (Nette\Security\AuthenticationException $e) { $form->addError('Uživatelské jméno nebo heslo není správné'); return; }

Návrhová část

41

$this->redirect('Main:home'); }

Nutné je správné vyplnění tohoto formuláře. Při odeslání prázdného formuláře dochází k upozornění uživatele, jak je zřetelné na obr. 16. Při odeslání nesprávných přihlašovacích údajů je programem zobrazena vyjímka (nachází se ve formuláři SignInFormSubmitted), která vypíše, že uživatelské jméno nebo heslo není správné.

Obr. 16

Přihlášení do informačního systému

V metodě startup dochází k ověření přihlášení uživatele, pokud uživatel není přihlášen (nebo nevyplní správné přihlašovací údaje), je zavolána příslušná akce in, která přesměruje stránku znovu na přihlašovací formulář SignInForm. protected function startup() { parent::startup(); if (!$this->getUser()->isLoggedIn()) { $this->redirect('Sign:in'); } }

Byla také naimplementována hashovací funkce, která zajišťuje zaheshování hesla, které si zvolí pracovník, aby bylo heslo naprosto chráněno před zneužitím. V této funkci byla využita utilita frameworku Nette pro generování náhodných znaků. Pracovník sdělí uživatelské jméno a heslo IT administrátorovi a ten, díky této funkci vloží do databáze zaheshované heslo (konkrétně do tabulky users příslušného řádku password). Po tomto vložení se může pracovník do informačního systému přihlásit.

Návrhová část

42

public static function calculateHash($password, $salt = null) { if ($salt === null) { $salt = '$2a$07$'. Nette\Utils\Strings::random(32) . '$'; } return crypt($password, $salt); }

Výsledné použití funkce administrátorem je znázorněno na obr. 17. Administrátor pro zavolání hashovací funkce musí zadat přesnou url adresu a také dodržet její strukturu. Tato funkce je uložena v adresáři app/model/Authenticator.php.

Obr. 17

Použití hashovací funkce

5.5.3

UPLOAD šablon

Nahrávání (Upload) šablon je jedno z hlavních požadavků, které má informační systém řešit. Nahrávání je naimplementováno v modulu Databáze dlužníků, jak je uvedeno v kapitole 5.5.1, konkrétně v sekci Majetek dlužníka, Přezkumné řízení a Schůze věřitelů. Dále v této kapitole je popsána sekce Majetek dlužníka. V sekci Majetek dlužníka se nachází šablona Majetek dlužníka, kterou si může uživatel stáhnout a dále s ní pracovat. Pod šablonou je tabulka pro nahrávání souborů. Při prvotním zobrazení sekce Majetek dlužníka je zobrazena pouze tabulka s možností nahrávání souborů. Jakmile je soubor nahrán, zobrazí se výsledná tabulka s nahraným souborem. Tato tabulka obsahuje název souboru, uživatele, který tento soubor nahrál a čas nahrání souboru (viz. Obr. 18). Jméno uživatele je okamžitě získáno z přihlašovacích údajů při nahrání souboru. To je zajištěno funkcí getIdentity, která je jedna z mnoha předdefinovaných funkcí frameworku Nette a zajišťuje získávání přihlašovacích údajů. V mém případě z tabulky users v databázi, kde se nachází řádek name (jméno) a řádek password (heslo) přihlášeného uživatele. Konkrétní získání jména uživatele je možné přes funkci getUser()-> getIdentity()-> name.

Návrhová část

43

Čas nahrání souboru je automaticky předán z aktuálního času při odeslání souboru a uložen do databáze díky řádku mcas (majetková podstata – čas), který je v databázi uložen jako timestamp a následně zobrazen uživateli.

Obr. 18

Nahrávání šablon

Zobrazení názvu nahraného souboru a celkové velikosti daného souboru je zajištěna díky funkci renderMajetek, která je naimplementovaná v MainPresenteru (app/presenters/MainPresenter.php), kde je název souboru a velikost souboru předávána z databáze (velikost souboru je zde upravena) a následně připravena na použití v šabloně pro zobrazení (view, kapitola 3.6). public function renderMajetek($id_dluznik) { $majetek = $this->dluznikRepository ->findOne($id_dluznik); $filesize = $majetek->file_size; If ($filesize < 1024) { $filesize = (int)$filesize . " B"; } elseif ($filesize < 1024*1024 ) { $filesize = (int)($filesize/1024) . " kB"; } elseif ($filesize < 1024*1024*1024) { $filesize = (int)($filesize/1024/1024) . "MB"; } else { $filesize = (int)($filesize/1024/1024/1024). "GB"; } $this->template->filename = $majetek->file_name; $this->template->filesize = $filesize;

Návrhová část

44

}

5.5.4

DOWNLOAD šablon

Stahování nahraných šablon je také jedním z hlavních požadavků, které má informační systém řešit. Stahování je naimplementováno v totožném modulu i sekcích jako nahrávání šablon (kapitola 5.5.3). Po nahrání souboru je možné tento soubor stáhnout (viz. Obr. 19) a následně upravovat.

Obr. 19

Stahování nahraných šablon

Díky naimplementování hlaviček (Headers) ve funkci renderDownloadMajetek a zavolání této funkce při kliknutí myši na nahraný soubor je možné vidět název, velikost a typ stahovaného souboru. public function renderDownloadMajetek($id_dluznik) $majetek = $this->dluznikRepository ->findOne($id_dluznik);

{

$httpRequest = $this->context->httpResponse; $httpRequest->addHeader('Content-length', $majetek ->file_size); $httpRequest->addHeader('Content-type', $majetek ->file_type); $httpRequest->addHeader('Content-Disposition', 'attachment; filename=' . $majetek->file_name); echo $majetek->file_content;

Návrhová část

45

exit; }

5.5.5


Při nahrání souboru, jak je uvedeno v kapitole 5.5.3 dochází jednak k zobrazení tabulky s nahraným souborem, uživatelem a časem nahrání, ale také k zobrazení tabulek pro ukládání informací o stavu nahraného souboru (viz. Obr. 20).

Obr. 20


Každá tabulka na obr. 20 má tlačítko Odeslat, pro konkrétní uložení změn fáze zpracování. Po odeslání je v konkrétní tabulce doplněno políčko uživatele i čas odeslání. Tyto políčka jsou stejným způsobem naimplementována, jako v kapitole 5.5.3 tabulka s nahraným souborem. 5.5.6

Kontrola tiskových sestav

Kontrola tiskových sestav je hlavním prvkem v celém informačním systému a je jedním z hlavních požadavků na informační systém. Nachází se v modulu Databáze dlužníka, konkrétně v sekci Úkoly. Informuje nás o tom, zda veškeré spisy k jednotlivému dlužníkovi jsou zpracovány a zda je mohou pracovníci insolvenční kanceláře vytisknout a zaslat na soud. Tisk a zaslání na soud je možný pouze, zdali jsou v této sekci veškeré spisy připraveny na tisk (tabulka konkrétní šablony a její fáze zpracování mají barvu zelenou). Kompletní zobrazení zpracování všech šablon připravených na odeslání na soud je součástí přiloženého CD. Pokud jeden spis z této sekce není připraven na tisk (tabulka konkrétní šablony a její fáze zpracování mají barvu žlutou nebo červenou), není tato tisková sestava připravena k vytištění a následnému odeslání na soud. V této sekci jsou zobrazeny názvy veškerých tiskových sestav (šablon), které mají být v informačním systému u konkrétního dlužníka nahrány a zpracovány. V této sekci tedy dochází ke kontrole nahrání a zpracování jednotlivých šablon.

Návrhová část

46

Cílem této sekce je zobrazení veškerých šablon a jejich stav (nahrání, zpracování). Tato sekce má i informační charakter. Informuje insolvenčního správce o: • průběhu zpracování jednotlivých šablon (nahrání, zpracování), • času nahrání a času fází zpracování jednotlivých šablon, • jménu pracovníka, který zodpovídá za nahrání a zpracování jednotlivých šablon. Implementace a zdrojový kód sekce Úkoly se nachází v přiloženém CD. Pokud je šablona nahrána, je možné i v této sekci šablonu stáhnout. Stačí kliknout myší na černé tlačítko se znakem pro stahování (obr. 21). Pokud soubor není nahrán, je možné v této sekci kliknout na bílé tlačítko se znakem nahrávání (obr. 22) a dojde k přesměrování na stránku, kde lze tuto šablonu nahrát.

Obr. 21

Kontrola tiskových sestav – možnost stahování

Obr. 22

Kontrola tiskových sestav – možnost nahrávání

5.5.7

Napojení systému na Insolvenční rejstřík

Pro budoucí potřebu informačního systému nahlížet a stahovat data z Insolvenčního rejstříku bylo naimplementováno napojení na tento rejstřík. Ministerstvo spravedlnosti spustilo 1.1.2008 na svém serveru justice.cz webovou službu insolvenčního rejstříku. Díky SOAP klientu se lze napojit na veřejně dostupné XML této služby, které se nachází na stránce: https://isir.justice.cz:8443/isir_ws/services/IsirPub001?wsdl.

Návrhová část

47

$soap = new SoapClient('https://isir.justice.cz:8443/ isir_ws/services/IsirPub001?wsdl');

Díky tomuto napojení dochází ke vzájemné komunikaci mezi insolvenčním rejstříkem a naimplementovaným dílčím informačním systémem pro insolvenčního správce. try { $soap = new SoapClient('https://isir.justice.cz:8443/ isir_ws/services/IsirPub001?wsdl'); var_dump($soap->__getFunctions()); $params = array('long_1' => 1148); $result = $soap->getIsirPub0012($params); print_r($result->result[1]->spisZnacka ); } catch (Exception $e) { echo '
IRIS služba právě není dostupná
'; print_r($e); }

5.6 Uživatelské rozhraní Stručný popis uživatelského rozhraní je uveden v kapitole 5.5.1. Ukázky uživatelského rozhraní jsou součástí přiloženého CD. Tyto ukázky se stanou součástí budoucí uživatelské příručky obsluhy softwaru.

Diskuse

48

6 Diskuse Informační systém, stejně jako jiné aplikace a produkty, prochází různými fázemi od okamžiku, kdy dochází k rozhodnutí o jeho nasazení až do ukončení jeho používání. Souhrnně jsou všechny fáze nazývány životním cyklem informačního systému (Rybička, 2009). V průběhu celé práce se postupovalo dle jednoho z modelů životního cyklu informačních systémů. Tímto modelem byl vodopádový model. Hlavní fáze životního cyklu jsou obsaženy i v mé práci. • Úvodní studie – nachází se v kapitole Úvod a Cíl. • Analýza – nachází se v kapitole Analýza současného stavu. • Návrh informačního systému – nachází se v kapitole Materiál a metodika zpracování. • Implementace – nachází se v kapitole Návrhová část. • Testování – základní verze informačního systému byla prezentována insolvenčnímu správci a testována zaměstnanci firmy dle jejich požadavků na informační systém. Vyskytla se řada připomínek, které byly za velmi krátkou dobu testování vyřešeny. Důkladnější testování bude nadále probíhat. • Provoz systému – tato fáze bude následovat po ukončení veškerých testů. Informační systém bude naplněn ostrými daty a dále testován pro další možná vylepšení. Po diskusi s budoucími uživateli bylo zjištěno mnoho dalších funkčních i technologických požadavků, které by mohl řešit informační systém. Již známými požadavky jsou: • rozšíření informačního systému o databázi oddlužení společného jmění manželů, • rozšíření o podklady při oddlužení způsobem prodeje majetku, • rozšíření období procesního řízení vedeného prostřednictvím kontroly a zpracování informačním systémem od schválení oddlužení do jeho splnění, • vypracování výpočtu a vzorce pro stanovení plnění ve prospěch oddlužení, • napojení informačního systému na bankovní úhrady on-line, • databáze plnění oddlužení po celou dobu plnění dlužníkem s následným vypracováním zpráv jako podkladu pro hodnocení dlužníka.

Diskuse

49

Je nesporné, že práce na informačním systému bude pokračovat s cílem vytvoření informačního systému za celé období řízení, tedy i po schválení oddlužení až do Rozhodnutí o osvobození dluhů daného dlužníka a pro více poboček insolvenční kanceláře.

Závěr

50

7 Závěr Práce splnila zadaný cíl vytvořit dílčí informační systém pro práci insolvenční kanceláře v rozsahu dvou pracovníků a insolvenčního správce. Informační systém velmi dobře a jednoduše, srozumitelně pro uživatele plní evidenci a kontrolu činností, které musí být splněny v období od povolení oddlužení do jeho schválení. Využívá a respektuje veškeré zvyklosti v konkrétní práci insolvenční kanceláře a v interakci podporuje vlastní tvořivost pracovníků zadavatele.

7.1

Využití informačního systému pro praxi

Informační systém po ukončení testování a zkušebního provozu je plně využitelný. Dnes již v písemné formě vedená insolvenční řízení budou nadále řešena původní formou, přidělená řízení nová budou již zaevidována do informačního systému a tento ihned využíván. Insolvenční kancelář rozšířila svoji působnost o další pobočku kanceláře a bez dílčího informačního systému množství dat v tak velkém rozsahu nelze již zpracovat.

Literatura

51

8 Literatura ARTIC STUDIO. Co je to databáze MySQL?. [online]. 2011 [cit. 2013-05-13]. Dostupné z: http://www.artic-studio.net/slovnicek-pojmu/databaze-mysql/ BUCHALCEVOVÁ, Alena; PAVLÍČKOVÁ, Jarmila; PAVLÍČEK, Luboš. Základy softwarového inženýrství - materiály ke cvičení. 1.vyd. Praha: Vysoká škola ekonomická, 2007. 222 s. ISBN 987-80-245-1270-9. DATAPROJEKT S.R.O. Popis aplikace Enterprise Architect. [online]. 2013 [cit. 2013-05-01]. Dostupné z: http://www.dataprojekt.cz/content/popis-aplikaceenterprise-architect Enterprise Architect. [online]. 2013 [cit. 2013-05-01]. Dostupné z: http://www.enterprisearchitect.cz/ FLEK, Miroslav. Požadavky na SW: Od zadání k architektuře aplikace. [online]. 2011 [cit. 2013-05-01]. Dostupné z: https://akela.mendelu.cz/~xflek1/ISP/2_Pozadavky_na_SW.ppt FOWLER, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language. 3. edition. Addison Wesley, 2003. 208 s. ISBN 0- 321-19368-7. KAŠÍK, Josef. Podniková diagnostika. Ostrava: Tandem, 1998, 343 s. ISBN 80902-1674-9. KOLÁŘ, Pavel, Monika VESELÁ. Ekonomie a ekonomika. 2., přeprac. a rozš. vyd. Praha: ASPI, 2006. ISBN 978-807-3572-181. Konkursní noviny: noviny pro konkurs, vyrovnání, likvidaci a exekuce. Brno: COOPER PRESS, spol. s r.o., 2013. ISSN 1213 - 4023. KOTLER, P. Marketing management (10. rozšířené vydání). Přel. V. Dolanský; Jurnečka. 1. vyd. Praha: Grada Publishing, 2001. 720 s. ISBN 80-247-0016-6. KOZÁK, Jan, Petr BUDÍN, Alexandr DADAM a Lukáš PACHL. Insolvenční zákon a předpisy související: Nařízení Rady (ES) o úpadkovém řízení: komentář. Vyd. 1. Praha: ASPI, 2008, xxii, 903 s. Komentáře nakladatelství ASPI. ISBN 978-807-3573-751. MIKLÁŠ, Michal. Úvod do PHP: Wamp Server. [online]. 2013 [cit. 2013-05-01]. Dostupné z: http://www.gjszlin.cz/ivt/esf/php/php-uvod-do-php.php MINISTERSTVO SPRAVEDLNOSTI. Insolvenční rejstřík. [online]. 2008 [cit. 2013-05-17]. Dostupné z: http://obcanskyzakonik.justice.cz/ejustice/insolvencni-rejstrik.html NETTE FOUNDATION. Dokumentace. Nette Framework [online]. 2011 [cit. 20134-11]. Dostupné z: http://doc.nette.org/cs/ RYBIČKA, Jiří. Informační systémy. [online]. 2009 [cit. 2013-05-01]. Dostupné z: https://akela.mendelu.cz/~rybicka/prez/infsyst.pdf SPARX SYSTEMS. Enterprise Architect 10: Reviewer’s Guide. [online]. 2013 [cit. 2013-05-01]. Dostupné z:

Literatura

52

http://www.sparxsystems.com/download/whitepapers/EAReviewersGuide.p df SPARX SYSTEMS. Example Diagram. [online]. 2000-2011a [cit. 2013-05-17]. Dostupné z: www.sparxsystems.com/enterprise_architect_user_guide/9.3/navigate_sear ch_and_trace/create_traceability_diagrams.html SPARX SYSTEMS. Model Requirements. [online]. 2000-2011b [cit. 2013-05-01]. Dostupné z: http://www.sparxsystems.com/enterprise_architect_user_guide/9.3/require ment_models/modeling_requirements.html SPARX SYSTEMS. The Business Process Model. [online]. 2007[cit. 2013-05-01]. Dostupné z: http://sparxsystems.com/downloads/whitepapers/businessProcessModelTut orial.pdf SPARX SYSTEMS. The Business Process Model: Eriksson-Penker Business Modeling Profile. [online]. 2000-2013a [cit. 2013-05-01]. Dostupné z: http://www.sparxsystems.com/business_process_model.html SPARX SYSTEMS. The Use Case Model. [online]. 2000-2013b [cit. 2013-05-01]. Dostupné z: http://www.sparxsystems.com/resources/tutorial/use_case_model.html ŠTENCL, Michael. Začínáme s BPM: Učební pomůcka. [online]. 2007 [cit. 201305-01]. Dostupné z: https://akela.mendelu.cz/~xstencl/vyuka/bpm/bpm_uvod.pdf

Přílohy

53

Přílohy

Přílohy na CD

54

A Přílohy na CD • Bakalářská práce ve formátu PDF • Ukázky uživatelského rozhraní informačního systému • Vygenerovaná databáze informačního systému v MySQL z nástroje PhpMyAdmin • Veškeré zdrojové kódy informačního systému • Veškeré soubory a složky frameworku Nette • Veškeré grafické soubory frameworku Bootstrap použité v informačním systému

Informační systém pro vedení agendy insolvenčních správců při řešení úpadku formou oddlužení

Recommend Documents

IRIS služba právě není dostupná