Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Diplomová práce
Systémová podpora procesů advokátní kanceláře Bc. Martin Černý
Vedoucí práce: Ing. Pavel Náplava
7. května 2013
Poděkování Rád bych na tomto místě poděkoval Ing. Pavlu Náplavovi za vstřícný přístup a cenné rady při vedení mé práce. Dále děkuji Ing. Václavu Bahníkovi za odborné konzultace a oponenturu. Děkuji všem advokátům za čas a pozornost, kterou mi věnovali během konzultací. Děkuji své rodině za podporu během celého studia.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne 7. května 2013
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Martin Černý. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Černý, Martin. Systémová podpora procesů advokátní kanceláře. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.
Abstract This work focuses on system support for Attorneys-at-Law agenda. First part covers in-depth analysis of advocacy from ICT1 point of view. Consultations with Attorneys and background research are fundamental for the analysis. Overview of applications currently used by attorneys is followed by a list of specialized solutions offered by ICT providers. Outputs from the analysis are transformed into system requirements. These requirements are met by system functions for a general solution concept. The suggested system support contains five parts: Portal (universal user interface), Document Management System, Case Support (solution that improves individual law case handling), Conflict of Interest (new client check to avoid possible conflict of interest) and Auditor (automatic background check for people and companies) The general concept is transformed into a solution based on IBM technologies. Part of the work is a demo implementation containing Portal, Document Management System and Case Support. This demo solution was introduced to attorneys and their feedback and suggestions have been included in the work.
Keywords Attorney’s at law, System support, Enterprise Content Management, IBM, Advanced Case Management, Document Management System, Information system
1
Information and Communication Technologies
ix
Abstrakt Práce se zabývá systémovou podporou činností advokátní kanceláře. První část obsahuje podrobnou analýzu prostředí advokacie z pohledu informačních technologií. Základ analýzy tvoří konzultace s advokáty a rešerše odborné literatury. Systémy popsané a používané advokáty jsou doplněny o existující řešení IT společností, které se na advokacii specializují. Výstupy analýzy advokacie jsou převedeny na požadavky kladené na systémové řešení. Požadavky jsou naplněny obecným návrhem, nezávislým na dodavateli. Navrhovaná systémová podpora obsahuje pět prvků: Portál (univerzální uživatelské rozhraní), Systém na správu dokumentů, Podporu případů (řešení umožňující efektivně pracovat s jednotlivými právními případy), Konflikt zájmů (analýza potenciálního klienta, zda je možné ho zastupovat) a Auditor (automatizované řešení pro rešerši veřejně dostupných údajů o osobách a společnostech). Obecné řešení je v práci převedeno na návrh systému založeného na technologiích společnosti IBM. Práce obsahuje ukázkové řešení, které zahrnuje moduly Podpora případů, Správa dokumentů a Portál. Řešení bylo představeno advokátům a práce obsahuje zpětnou vazbu a návrhy na vylepšení systému. Klíčová slova Advokátní kanceláře, Systémová podpora, Správa podnikového obsahu, IBM, Advanced Case Management, Systém na správu dokumentů, Analýza obsahu, Advokátní kancelář, Informační systém
x
Obsah Úvod Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 2
1 Informační technologie v podniku 1.1 Informační systém . . . . . . . . 1.2 Procesy v informačních systémech 1.3 ICT služby . . . . . . . . . . . . . 1.4 Náplň mojí práce . . . . . . . . .
5 5 7 8 9
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2 Analýza advokacie z pohledu informačních technologií 11 2.1 Analýza advokátních kanceláří . . . . . . . . . . . . . . . . . 11 2.2 Popis jednotlivých typů případů . . . . . . . . . . . . . . . . 22 2.3 Existující systémová řešení . . . . . . . . . . . . . . . . . . . 35 3 Obecná architektura systému 3.1 Postup při návrhu systémového řešení . . 3.2 Definice požadavků na systémové řešení . 3.3 Návrh architektury . . . . . . . . . . . . 3.4 Závěr obecné architektury . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
41 41 42 47 55
4 Architektura IBM řešení 4.1 Portál . . . . . . . . . . 4.2 Podpora případů . . . . 4.3 Správa dokumentů . . . 4.4 Veřejně dostupné zdroje 4.5 Konflikt zájmů . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
57 58 59 60 60 61
. . . . .
. . . . . xi
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
4.6
Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5 Ukázkové řešení pro advokátní kanceláře 65 5.1 Hlavní funkce ukázkového řešení . . . . . . . . . . . . . . . . 70 5.2 Vytvořené Case type . . . . . . . . . . . . . . . . . . . . . . 72 5.3 Testování aplikace . . . . . . . . . . . . . . . . . . . . . . . . 85 6 Vyhodnocení využití ACM v advokacii 6.1 Konzultace se zpětnou vazbou . . . . . . . 6.2 Úpravy systému . . . . . . . . . . . . . . . 6.3 Zpětná vazba na upravený systém . . . . . 6.4 Vyhodnocení řešení ve vztahu k existujícím 6.5 Ekonomická stránka řešení . . . . . . . . .
. . . . . . . . . . . . . . . . . . aplikacím . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
87 87 89 92 93 94
Závěr
95
Literatura
99
A Seznam použitých zkratek
103
B Obsah přiloženého CD
105
xii
Seznam obrázků 0.1
Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1
Struktura ICT ve společnosti. . . . . . . . . . . . . . . . . . . .
6
2.1
Životní cyklus případu . . . . . . . . . . . . . . . . . . . . . . .
15
3.1 3.2 3.3
Obecná architektura řešení . . . . . . . . . . . . . . . . . . . . . Obsah správy dokumentů a obsahu . . . . . . . . . . . . . . . . Příklad konfliktu zájmů . . . . . . . . . . . . . . . . . . . . . .
48 51 53
4.1 4.2 4.3
Architektura řešení pomocí systémů IBM . . . . . . . . . . . . . Sekvenční diagram kontroly konfliktu zájmů. . . . . . . . . . . . Popis modulu Auditor. . . . . . . . . . . . . . . . . . . . . . . .
58 62 63
5.1 5.2 5.3 5.4 5.5 5.6
Struktura Solution v nástroji IBM Case manager . . . . . . . . Screenshot z aplikace IBM Content navigator s integrovaným ICM Screenshot doplňku "to-do", řešeného formulářem . . . . . . . . Diagram Case type Založení společnosti s ručením omezeným . Diagram Case type lividace s.r.o. . . . . . . . . . . . . . . . . . Diagram Case type Přihlášení ochranné známky . . . . . . . . .
67 71 71 73 77 82
6.1 6.2 6.3
Screenshot uživatelského prostředí se zvoleným "Properties"přístupem. 90 Screenshot uživatelského prostředí s upřednostněním dokumentů 90 Rozšířený to-do formulář . . . . . . . . . . . . . . . . . . . . . . 91
xiii
Seznam tabulek 2.1
Struktura advokátní kanceláře . . . . . . . . . . . . . . . . . . .
12
3.1 3.2
Přehled míry využití jednotlivých funkčních bloků. . . . . . . . Seznam dalších požadavků, které mohou být benefitem. . . . . .
46 47
5.1 5.2 5.3 5.4 5.5
Manifest agilního vývoje software [5] . . . . . . . . . . . . . . . Tasks pro Case type Založení společnosti s ručením omezeným . Roles pro Case type Založení společnosti s ručením omezeným . In-baskets pro Case type Založení společnosti s ručením omezeným Document types pro Case type Založení společnosti s ručením omezeným . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties pro Case type Založení společnosti s ručením omezeným Document types pro Case type Likvidace společnosti s ručením omezeným . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks pro Case type Likvidace společnosti s ručením omezeným Roles pro Case type Likvidace společnosti s ručením omezeným In-baskets pro Case type Likvidace společnosti s ručením omezeným . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document types pro Case type Likvidace společnosti s ručením omezeným . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties pro Case type Likvidace společnosti s ručením omezeným . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks pro Case type Přihlášení ochranné známky . . . . . . . . Roles pro Case type Přihlášení ochranné známky. . . . . . . . . In-baskets pro Case type Přihlášení ochranné známky . . . . . . Document types pro Case type Likvidace společnosti s ručením omezeným . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66 74 74 75
5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16
xv
75 76 76 78 79 80 80 81 83 83 84 84
Seznam tabulek 5.18 Možnosti výběru pro Properties pro Case type Přihlášení ochranné známky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.17 Properties pro Case type Přihlášení ochranné známky . . . . . . 85
xvi
Úvod Důvodem, proč jsem si vybral téma Systémová podpora procesů advokátní kanceláře, je kombinace mého studia. Paralelně se studiem Fakulty informačních technologií jsem začal studovat na Právnické fakultě Univerzity Karlovy v Praze. Získané vědomosti by mi mohly umožnit správně analyzovat činnosti advokátní kanceláře z pohledu systémové podpory. Během studia jsem získal možnost pracovat ve společnosti IBM Česká republika, mezinárodní korporaci, poskytující služby v oboru informačních technologií. Jsem zde specialistou na systémy orientované na správu podnikového obsahu (Enterprise Content Management = ECM). Mým úkolem je prezentovat technické možnosti řešení IBM možným budoucím zákazníkům. Při přemýšlení nad tématem své diplomové práce jsem se inspiroval příběhem, který se traduje o Tomáši Baťovi, který poslal do Afriky dva pracovníky, aby tam udělali průzkum trhu. Jeden pracovník po týdnu hlásil: „Není tady žádný potenciál, v Africe je zbytečné chtít prodávat boty, tady boty nikdo nenosí.“ Druhý mu hlásil: „Je tady obrovský potenciál, je to skvělá příležitost obsadit trh a měli bychom zde postavit fabriku, v Africe nikdo boty ještě neprodává a lidi žádné boty nenosí.“ IBM v současné době nenabízí ucelené řešení v oblasti ECM orientované na advokáty. Domnívám se, stejně jako druhý Baťův zaměstnanec, že je zde veliký trh i proto, že advokáti se do využívání informačních technologií zatím příliš nehrnou. Rád bych ve své práci zjistil, zda advokacie by mohla být takovou "Afrikou"pro informační systémy. Chtěl bych, aby moje práce byla přínosem jak pro advokáty tak i pro 1
Úvod informatiky. Mým výstupem bude obecný architektonický rámec a návrh řešení v technologiích IBM, zpracovaný na úrovni, která bude přijatelná pro běžného uživatele. Advokát, který si přečte moji práci, by měl získat povědomí, jak mu mohou informační technologie pomoci. Potencionální dodavatel informačních technologií zase získá představu o fungování advokátní kanceláře a může navrhnout plnohodnotný systém.
Cíle Cíle práce vyplývají z pokynů uvedených v zadání práce. • Analyzovat činnosti a procesy, které probíhají v typické advokátní kanceláři. • Vytvořit dokument, který je čitelný i pro běžné uživatele (technicky neznalé) a bude obsahovat informace o možném využití informačních technologií v těchto procesech. • Zmapovat existující systémy a navrhnout vlastní systém, který bude využívat technologii Advanced Case Management (ACM) od společnosti IBM. • V rámci možností vybrané procesy implementovat a otestovat. • Na závěr provést vyhodnocení využití technologie ACM vzhledem k již existujícím řešením.
Struktura práce Základ mého postupu je znázorněn na obrázku 0.1. Prvním krokem byla analýza prostředí advokacie z pohledu informačních technologií. Rozhodl jsem se provést analýzu formou konzultací s advokáty. Závěry z těchto konzultací jsou dále rozšířené o informace z odborné literatury. Výsledkem je popis fungování advokátních kanceláří, jejich struktury a přehled systémů, které dnes používají. Druhým krokem bylo vytvoření obecné architektury systému. Využil jsem získaných znalostí, abych správně identifikoval potenciál advokacie pro řešení nabízená informačními technologiemi. Tato část práce popisuje potřeby advokátů a správný systémový přístup k jejich řešení. Výstup je nezávislý na konkrétní technologii a může být základem pro řešení od jakéhokoliv dodavatele. 2
Struktura práce
Obrázek 0.1: Struktura práce
Třetím krokem, vycházejícím ze zadání práce, bylo hledat konkrétní řešení pomocí technologií IBM. Důvodem byla absolvovaná stáž a zkušenosti se systémy IBM. Během přípravy na vypracování této práce jsem podrobně nastudoval celou řadu technologií, které společnost IBM nabízí a úspěšně jsem získal mezinárodně uznávané certifikace na tři z nich. Jedná se o IBM Case Manager, IBM Filenet P8 a IBM Filenet BPM. Tyto systémy jsou základem řešení společnosti v oblasti správy podnikového obsahu (Enterprise Content Management). Myslím, že se mohou v oblasti advokacie uplatnit a mým cílem je tuto skutečnost ověřit. Výstupem je návrh systému, který by poskytl komplexní podporu advokátní kanceláři. Nejdůležitější funkce jsou zahrnuty v ukázkovém řešení. Závěrečným krokem bylo shrnutí výsledků práce a jejich analýza. Cílem bylo ověřit možnost využití mého návrhu v praxi. Využil jsem získaných kontaktů a oslovil některé z advokátů, abych získal zpětnou vazbu na ukázkové řešení, které jsem připravil. Vyhodnotil jsem také, zda IBM ACM technologie mají advokacii co nabídnout a jaké jsou výhody tohoto přístupu proti existujícím řešením.
3
Kapitola
Informační technologie v podniku Tato kapitola vysvětluje, jak zapadají informační technologie do struktury společnosti. Celý "ekosystém"společnosti je znázorněn na obrázku 1.1. Jednotlivé části jsou podrobně popsány dále.
1.1
Informační systém
Při systémovém řešení podpory procesů a činností advokátní kanceláře je třeba nejprve definovat, co se rozumí systémovou podporou. Systém umožňuje popsat a uspořádat informace. Jak dále dodává Gála [25]: “Systém je účelově definovaná množina prvků a množina vazeb mezi nimi, přičemž vlastnosti prvků a vazeb mezi nimi určují vlastnost (chování) celku.” Informační systém je dále definován takto: “Informační systém představuje konzistentní uspořádanou množinu komponent spolupracující za účelem tvorby, shromažďování, zpracování, přenášení a rozšiřování informací. Prvky informačního systému tvoří lidé, respektive uživatelé informací a informatické zdroje. Komponenta je tvořena jedním nebo vice prvky.” Systém tedy tvoří ucelenou strukturu, která umožňuje efektivní práci s informacemi. Netvoří ho pouze systémy (například počítačové), ale také lidé. Obvyklé druhy informačních systémů podle Gály [25]: 5
1
1. Informační technologie v podniku
Obrázek 1.1: Struktura ICT ve společnosti.
6
1.2. Procesy v informačních systémech • Neformální informační systém, který je reprezentovaný výměnou i zpracováním informací lidmi (word of mouth) a kdy vedle mluvy využíváme i další komunikační techniky (mimika, gesta apod.) • Formální informační systém, který je založen na formalizovaných pracovních a informačních tocích, realizovaných na základě popsaných politik, cílů, strategií, pravidel a předpisů • Informační systém založený na počítačích (computer-based). Ve své práci se zaměřuji na počítačově založený informační systém. Uvědomuji si, že systém nejsou nikdy jen počítače, vždy sem patří také lidé a existují i systémy, které počítače vůbec neobsahují. Vývoj informačních technologií proběhl teprve nedávno, práce s informacemi byla však důležitá vždy. Avšak představa, že systém vždy vyřeší problémy společnosti, je chybná. Systém slouží spíše jako podpůrný prostředek, neměl by společnost řídit. V mé práci se budu snažit, aby se jednalo o podporu a nikoliv o snahu měnit společnost, v tomto případě advokátní kancelář. Myslím, že riziko vzniká ve chvíli, kdy se ICT povyšuje na úroveň partnera pro management společnosti. O tomto tématu hovoří Voříšek [45], jako o jasném směru informatiky, tedy o takovém rozdělení, kdy vedoucí informačního oddělení spolupracuje na tvorbě strategie společnosti. Souhlasím, že je to správný směr, ale mělo by se k němu přistupovat opatrně, aby nedošlo k tomu, že nároky na zaměstnance ve vztahu k informačnímu systému budou neúnosně vysoké. Architektura systému musí být natolik flexibilní, aby společnost sama rozhodla, kde chce aplikovat striktně procesní přístup a kde je potřeba zaměstnancům nechat volnou ruku.
1.2
Procesy v informačních systémech
Další oblastí, kterou se zabývá moje práce, jsou procesy v informačních systémech. Popisuje je Voříšek [45], své teorie rozvinul i v rámci předmětu Řízení podnikové informatiky na Vysoké škole ekonomické v Praze, který jsem měl možnost absolvovat. Voříšek[45] definuje procesy takto: "Proces je účelně naplánovaná a realizovaná posloupnost činností, ve které za pomoci odpovídajících zdrojů probíhá transformace vstupů na požadované výstupy." 7
1. Informační technologie v podniku "Podnikový proces, resp. Byznys proces je proces, kterým podnik zajišťuje naplnění podnikových cílů, reaguje na významné události a zjišťuje produkci plánovaných výstupů." Procesy dále dělí na hlavní, řídící a podpůrné. Procesy v informačních technologiích (ICT procesy, ICT = Information and Communication Technologies), kterými se ve své práci Ing. Voříšek zabývá, řadí do role podpůrných procesů. ICT procesy představují podporu, kterou informační technologie poskytují hlavnímu procesu. Popisují, jak počítače, servery, systémy, aplikace a další přispívají ke snaze společnosti generovat zisk.
1.3
ICT služby
Moderní přístup k ICT procesům zahrnuje chápání informačních technologií jako služeb, které jsou ICT útvarem poskytovány byznysu. V této souvislosti již není důležité, jaké systémy společnost používá. Služby definují formu a rozsah funkcí, které ICT poskytuje a které byznys konzumuje. Definici služby poskytl například Booth, kterého Voříšek cituje [45]: "Služba je abstrakcí nějakého zdroje, kterou reprezentujeme schopnost zdroje zpracovávat úlohu s koherentní funkcionalitou z pohledu poskytovatele i příjemce služby. Aby služba mohla být použita, musí být realizována konkrétním agentem poskytovatele." Definici ICT služby pak doplňuje Skála, také citovaný v [45]: “ICT služba je konkrétní funkcionalita poskytovaná informačními a komunikačními technologiemi, která umožňuje chod konkrétního obchodního procesu.“ Důležitá je nově přidaná úroveň abstrakce, které dobře rozumějí běžní uživatelé i členové ICT týmu. Mnohem snáze pak mezi sebou komunikují. Služby lze snadno měřit a kontrolovat, zda jsou poskytovány v předepsané míře. Lze také rychle nahradit interní ICT podporu outsourcingem2 nebo hostovaným cloud3 řešením, kdy se výpočetní technika nachází v datovém centru, neznámo kde. 2 3
8
Informační technologie zajišťuje specializovaná společnost Společnost využívá systémy instalované u dodavatele, přistupuje k nim přes internet.
1.4. Náplň mojí práce
1.3.1
Příklad ICT služby
Protože pojem ICT služby může být pro netechnického čtenáře těžší uchopit, uvádím jednoduchý příklad. ICT službou může být například tisk dokumentů. Zaměstnanci potřebují tisknout dokumenty a ICT jim musí tuto službu zajistit. Podle přesnějších požadavků lze službu lépe definovat např.: kdo potřebuje tisknout barevně, kolik stran apod. Je v kompetenci ICT rozhodnout, zda pořídí sdílenou tiskárnu pro celé patro, nebo pět malých tiskáren, pro každého uživatele jednu. Důležité je, aby výsledné řešení trvale splňovalo parametry dohodnuté služby. Je také možné, že se ICT útvar rozhodne, že finančně nejefektivnější bude uzavřít dohodu s externí firmou, která dodá tiskárnu, zajistí její servis a bude účtovat organizaci cenu za jednotlivé výtisky. V každém případě bude uživatel konzumovat stejnou službu: "Tisk dokumentů".
1.4
Náplň mojí práce
Informační systém představuje fungování kanceláře jako celku. ICT služby v mojí práci budou představovat požadavky, které vzniknou analýzou prostředí advokátních kanceláří a funkce, které na jejich zajištění může poskytnout ICT útvar. Výsledná služba je spojením požadavků a způsobu jejich naplnění s definovanými parametry, podobně jako v příkladu s tiskovou službou. Advokátní kancelář by ji pak měla požadovat od svého ICT útvaru nebo od externího dodavatele. Výstupem architektury řešení je konkrétní skupina aplikací, kterou by ICT útvar mohl využívat k zajištění požadovaných funkcí, jak je znázorněno na 1.1 jako Apliace A nebo B.
9
Kapitola
Analýza advokacie z pohledu informačních technologií Prvním krokem k vytvoření kvalitního návrhu systémového řešení je pochopení oblasti, kde má systém pomoci. Práce obsahuje podrobnou analýzu advokacie s ohledem na informační technologie. Analýza sestává z následujících kroků: • Analýza advokátních kanceláří • Popis jednotlivých typů případů • Existující systémová řešení
2.1
Analýza advokátních kanceláří
Analýzu jsem začal konzultacemi ve čtyřech advokátních kancelářích, které fungují v České republice. Snažil jsem se oslovit kanceláře, které by měly o případné řešení zájem. Oslovená menší česká advokátní kancelář je ukázkou, jak kancelář funguje v případě, že informační systém založený na počítačích nevyužívá. Mezinárodní kanceláře již určitou míru podpory využívají, jejich advokáti mají s informačními technologiemi větší zkušenosti. Vybraná velká česká kancelář je jednou z kanceláří v ČR, která již zavádí informační technologie do svého fungování.
2.1.1
Menší česká advokátní kancelář
První návštěva se uskutečnila v menší advokátní kancelář působící v Praze. Kancelář zaměstnává přibližně 35 advokátů, setkal jsem se s asistentkou 11
2
2. Analýza advokacie z pohledu informačních technologií kanceláře. Ta zastává ve společnosti některé funkce, které lze zahrnout pod pojem informační systém. Musí mít výborný přehled o všech probíhajících právních případech a advokátům a dalším zaměstnancům dokázat pomoci, najít informaci či dohledat dokumenty a informace založené v archivech. Díky této pozici má velmi dobrý přehled o každodenním provozu advokátní kanceláře a poskytla mi možnost nahlédnout do tohoto světa. Cíle konzultace • Popis fungování advokátní kanceláře • Struktura advokátní kanceláře • Informační technologie, které kancelář využívá 2.1.1.1
Struktura advokátní kanceláře
Základní struktura kanceláře je zachycena v tabulce 2.1.
Partneři Advokáti
Právníci Senioři Junioři Senioři Junioři
Administrativa Asistentka Recepce Studenti Finanční oddělení
Koncipienti Tabulka 2.1: Struktura advokátní kanceláře Velmi podobnou strukturu jako tato kancelář sdílí i většina dalších s menšími odchylkami 4 . Základem je rozdělení na právníky a administrativní pracovníky. • Administrativa zajišťuje pouze podporu advokátům. Patří mezi ně například asistentka – osoba, se kterou jsem se setkal, dále recepce, studenti nebo finanční oddělení. Struktura administrativy se může lišit, ve větší kanceláři se mohou objevit další oddělení. • Výkonnou jednotkou advokátní kanceláře jsou právníci nebo přesněji advokáti. Všichni mají společné ukončené právnické vzdělání a aktivně se podílejí na případech, které kancelář řeší. 4
Rozdíl je v administrativě, větší kanceláře mají specializované účetní oddělení, podatelnu nebo vlastní IT útvar, menší kancelář často využívá i outsourcing.
12
2.1. Analýza advokátních kanceláří – Partneři jsou nejvýznamnějšími zástupci kanceláře a jsou jejími spolumajiteli. Dělí se na juniory a seniory, podle výše jejich podílu. – Advokáti jsou právníci, kteří působí v kanceláři a zatím se nestali spoluvlastníky - partnery, podle množství zkušeností se dělí na seniory a juniory. – Koncipienti jsou držiteli právnického titulu (Mgr.), vykonávají velkou část práce a získávají zkušenosti z praxe, které potřebují k dokončení právnického vzdělání (titul JUDr). 2.1.1.2
Existující systémy, které kancelář využívá
Administrativní činnost Advokátní kancelář působila ve vztahu k informačním technologiím velmi konzervativně. Administrativní zaměstnanci, kteří zajišťují podporu advokátům, používají několik oddělených systémů, které jim pomáhají udržet kancelář v chodu. Jedná se o tyto systémy: • Fakturace a vyúčtování (přehled odpracovaných hodin na klienta) • Účetní systém • Docházka Systém fakturace a vyúčtování zaznamenává činnost advokátů, každý advokát do něj zaznamenává, kolik hodin odpracoval na kterém případu. Účetní systém využívá pouze finanční oddělení a je zcela nezávislý. Docházka je odděleným systémem pro sledování fyzické přítomnosti všech zaměstnanců v kanceláři. Podpora činnosti advokátů Systémovou podporu práce advokátů představují pouze aplikace MS Office a souborový systém Windows. Pokud je potřeba využít databáze, vytvoří IT oddělení databázi v rámci aplikace MS Outlook, příkladem může být databáze klientů nebo podpora hlídaní vypršení časových lhůt. Archivace probíhá papírovou formou. Advokáti dále pracují se systémem ASPI, kterému se dále věnuji v přehledu systému 2.3.1 13
2. Analýza advokacie z pohledu informačních technologií Komunikace Pro interní komunikaci slouží e-mail a telefon, jiné formy komunikace například instant messaging 5 nebo sociální sítě 6 , nejsou podle konzultantky vhodné. Pro komunikaci mimo kancelář slouží firemní e-mail a datové schránky. Pro přístup do schránek je využívána samostatná aplikace, problémem je však nutnost konverze dokumentů a dalšího ověřování. Externí e-mailová komunikace probíhá nestandardně – veškerá elektronická pošta je směřována na recepci, kde administrativní pracovnice poštu čtou a distribuují adresátům. Pokud se zpráva týká případu, na kterém spolupracuje celý tým advokátů, je příchozí e-mail adresován pouze zodpovědné osobě, recepce zařídí, aby jej obdrželi všichni členové týmu. Recepce zároveň kontroluje, zda obsahem e-mailu není nová lhůta, pokud ano, zavede ji do MS Outlook databáze, která na nutnost dodržení lhůty včas upozorní. Recepce v takovém případě připomene adresátovi, že se blíží lhůta, kdy musí dodat příslušný dokument.
Práce s dokumenty Kancelář neprovádí v současné době audit přístupů a práce s dokumenty, vše je řešeno pouze na úrovni firemní etiky a pravidel. Pokud je potřeba provést schvalovací proces nad některými dokumenty, děje se tak podle zaběhlých pravidel pomocí e-mailu a osobního kontaktu. Pokud je potřeba, aby daný dokument podepsal partner kanceláře, zajistí si příslušný advokát vlastními silami, že jej včas získá. Zápisy porad nejsou žádnou formou evidovány v systémech, nedochází ani k vytváření povinných zápisů.
5
Instant messaging (IM) je termín spojený s moderní alternativou e-mailové komunikace, jde o obdobu chatu. Je možné komunikovat pouze s uživateli, kteří jsou "on-line"a připraveni odpovědět. Přínosem je rychlejší získání relevantních informací, odpověď na e-mail může dorazit až za několik dní. IM umožní osobě, která potřebuje informaci získat, oslovit toho, kdo je schopen v danou chvíli odpovědět. 6 Podniková sociální síť je platforma, která umožní sdílet nápady, dokumenty nebo jakékoliv další informace napříč organizací. Ukazuje se, že se jedná o jeden z nejlepších nástrojů na spolupráci, obzvlášť ve větších podnicích.
14
2.1. Analýza advokátních kanceláří
Obrázek 2.1: Životní cyklus případu
2.1.1.3
Průběh běžného případu
Komunikaci s klientem zajišťuje obvykle jeden z partnerů, pokud je však klient zvyklý jednat s konkrétním advokátem, je to samozřejmě možné. S novým klientem je sepsána rámcová smlouva o zastupování, posléze je uzavřena konkrétní smlouva k danému případu. Případ je vždy přiřazen jednomu z advokátů – seniorů. Ten případ zavede do systému a je za něj zodpovědný, vede tým dalších advokátů, koncipientů nebo studentů, kteří na něm spolupracují. Jeho zodpovědností je zajistit správné vykazování množství odvedené práce a převod do fakturace. Celý proces je zachycen na obrázku 2.1.
2.1.1.4
Výstup konzultace
Úspěšně jsem zachytil strukturu i běžné fungování advokátní kanceláře. Z konzultace jasně vyplynuly hlavní role jednotlivých osob v kanceláři. Prvním problémem případného systémového řešení je relativní konzervativnost. 15
2. Analýza advokacie z pohledu informačních technologií
2.1.2
Mezinárodní advokátní kancelář
Druhou navštívenou advokátní kanceláří byla pražská pobočka mezinárodní advokátní společnosti. Pražská kancelář čítá sedmdesát advokátů, celosvětově je to více než čtyři tisíce advokátů v sedmdesáti státech světa. Měl jsem možnost využít konzultace s jedním ze seniorních advokátů této kanceláře. Cíle konzultace • Specifika mezinárodní kanceláře • Ověření informací z předchozí konzultace – Plnění lhůt, – Informační prostředky využívané advokáty • Představa ideálního systému pro advokáta – Funkce takového systému 2.1.2.1
Specifika mezinárodní kanceláře
Prvním cílem bylo zjistit rozdíly fungování mezinárodní kanceláře oproti kanceláři, která působí pouze v České republice. Z pohledu systémových řešení je nejvýznamnější nutnost jednotného řešení pro všechny pobočky. Není možné změnit systémové řešení pouze v pražské pobočce, je třeba stejné řešení začít používat ve všech kancelářích. Každá kancelář musí také dodržovat nastavené standardy v oblasti bezpečnosti dat a dokumentů základem je kvalitní šifrování. 2.1.2.2
Závislost kanceláře na plnění lhůt
Dotazovaný advokát potvrdil, že lhůty jsou velice důležité, ale jejich význam pro jednotlivé advokáty se liší podle oblasti jejich působnosti. Ne každý advokát pracuje na případech projednávaných před soudem. Řada z nich se specializuje na sjednávání smluv či jiné oblasti obchodního práva, mimo oblast sporů. Advokát, se kterým jsem jednal, byl vzdělaný i v informačních technologiích, takže jsme mohli konzultovat přímo některé systémové otázky. 16
2.1. Analýza advokátních kanceláří 2.1.2.3
Informační prostředky využívané advokáty
V první řadě se jedná o řadu veřejně dostupných systémů, ze kterých je potřeba získávat informace. Jedná se o tyto zdroje: • Katastr nemovitostí [46] • Obchodní rejstřík [19] • Živnostenský rejstřík [18] • Aplikace Info soud [17] • Insolvenční rejstřík [20] Všechny pobočky této kanceláře používají jednotný systém pro správu dokumentů (Document Management System neboli DMS). Systémy DMS umožňují nadstandardní operace s dokumenty a informacemi, které je potřeba uchovat. Tvoří centrální úložiště, kam jsou informace a především dokumenty shromažďovány. Cílem je zajistit efektivní nakládání s dokumenty, vyhledávání, archivaci, analýzu dat, verzování nebo audit přístupu k dokumentům a informacím. Dalším významným systémem, jsou datové schránky - nástroj pro komunikaci s veřejnou správou. Dotyčný advokát sám musí pracovat s třemi datovými schránkami a v současné době nevyužívá, žádný systém, který by mu práci zjednodušil. Systém, který používají všichni advokáti této kanceláře, je systém ASPI, ten je ale využitelný pouze pro České prostředí. Systém nabízí judikáty 7 , aktuální znění norem (zákonů) a v omezené míře také šablony některých dokumentů (smluv). Více o systému v kapitole Existující systémová řešení 2.3.1. 2.1.2.4
Představa ideálního systému pro advokáta
Systém, který by vyhovoval dotazovanému advokátovi, je přehledná aplikace, kterou by ráno spustil a mohl s ní průběžně pracovat během dne. Neměla by ho omezovat, pokud nastane tlak na urychlené dokončení případů. Systém by uměl připomenout nutné kroky k dokončení typizovaných případů obchodního práva, a zaznamenával by, které kroky již byly dokončeny. 7
Judikát je soudní rozhodnutí, přesto že náš právní systém nezná institut precedentu, jsou rozhodnutí vyšších soudů pro soudy nižší závazné.
17
2. Analýza advokacie z pohledu informačních technologií Aplikace by měla přehledně zpřístupnit veškeré zdroje externích i interních informací, které advokát momentálně využívá (ASPI, Info soud, rejstříky, interní archiv případů). Zároveň by zajistila efektivní komunikaci v rámci organizace. Vše za dodržování nejvyšších bezpečnostních standardů. Typy případů vhodné pro systémové řešení Dle názoru zmíněného advokáta je vhodnou oblastí pro systémové řešení obecně obchodní právo, nikoliv právo trestní. Mezi typizované případy obchodního práva zahrnul: • Založení společnosti s ručením omezeným (s.r.o.) • Likvidace s.r.o. • Další typy společností – a.s., v.o.s. (méně časté) • Zástavní smlouvy • Převod nemovitosti • Nájemní smlouvy • Platební rozkaz / Vymáhání pohledávky • Veřejná zakázka • Rejstříková řízení • Ochranné známky 2.1.2.5
Výstup konzultace
Mezinárodní kancelář se skutečně ukázala být pro mou práci lepším zdrojem podnětů. Spolupráce advokacie a informačních technologií je zde na výrazně vyšší úrovni než v případě menší místní kanceláře, která si může dovolit IT přehlížet. Hlavním úspěchem je první nástin možného systémového řešení pro podporu procesů v advokátní kanceláři. Identifikoval jsem konkrétní typy případů, které by mohly být pro takové řešení vhodné i základní parametry systému.
2.1.3
Velká nadnárodní kancelář
Měl jsem možnost setkat se s advokátkou pracující v nadnárodní britské advokátní kanceláři, která celosvětově zaměstnává téměř tři tisíce advokátů. Zmíněná advokátka má mnohaleté zkušenosti a specializuje se na 18
2.1. Analýza advokátních kanceláří právo spojené s nemovitostmi. Sama přiznala, že k počítačům a informačním technologiím obecně nemá příliš blízko. Rozhodl jsem se využít jejích zkušeností, abych získal představu o konkrétních potřebách advokáta bez navázání na konkrétní systém, nebo informační technologie vůbec. Cílem je získat požadavky na systémové řešení, které sám odvodím z potřeb, které mi advokát popíše. 2.1.3.1
Systémy, které advokát v praxi používá
Začali jsme konzultaci přehledem systémů, které advokátka běžně využívá ve své praxi. Systém ASPI Prvním nástrojem je systém ASPI, tato aplikace se objevuje i v dalších konzultacích, věnoval jsem tématu zvláštní konzultaci a výsledek je v kapitole 2.3.1. Systém na správu dokumentů (DMS systém) Dalším nástrojem byla databáze dokumentů společná pro celou síť kanceláří. Celosvětově má kancelář tisíce advokátů, kteří do systému vkládají dokumenty. Pro většinu dokumentů, které advokát připravuje, tak obvykle lze nalézt podobný, který již někdo zpracoval. Nedostatkem je vyhledávání dokumentů, advokátka si udržovala vlastní databázi odkazů na dokumenty, které ji zajímají. Systém jí nedokázal nabídnout prostředí, kde by snadno našla dokument, který hledá. Databáze klientů kanceláře Tento systém je spojený s DMS systémem, obsahuje informace o jednotlivých klientech. 2.1.3.2
Představa ideálního systému pro advokáta
• Komunikace – Interní – Externí • Databáze dokumentů – Jednoduché vyhledávání – Verze dokumentů – Časové známky 19
2. Analýza advokacie z pohledu informačních technologií • Databáze klientů kanceláře • Zdroje volně dostupných relevantních informací – InfoSoud – Rejstříky (obchodní, živnostenský, insolvenční a další) • Informace z ASPI systému
2.1.4
Velká česká advokátní kancelář
Měl jsem možnost setkat se s partnerem z jedné z největších českých advokátních kanceláří a s členem jeho IT týmu. Kanceláře čítá více než 140 advokátů. Opět jsme se v rozhovoru zaměřili na možnost podpory advokátní činnosti ze strany informačních technologií. V současné době zavádí kancelář systém na správu dokumentů (DMS systém) a dle advokáta je spolehlivý systém pro správu dokumentů v kanceláři této velikosti zcela nepostradatelný. Probrali jsme možnost rozšíření tohoto řešení o další funkce, které by kanceláři pomohly. Vyšel jsem z předchozích konzultací a potvrdil, že typy případů zmíněné v předchozí konzultaci 2.1.2.4 jsou vhodné k systémovému zpracování. Práci advokáta popsal partner jako skládání lega: "Každý model je jiný, ale skládají se stále ze stejných kostek." Opravdu velký význam má rychlá navigace a vyhledávání v dříve zpracovávaných dokumentech, které se týkají podobného případu, jaký advokát právě řeší. Popis spolupráce IT a advokátní kanceláře se příliš nelišil od požadavků diskutovaných na předchozích konzultacích. Zajímavé byly dva nové body - problémy, které řeší každá advokátní kancelář (viz níže), ale významnější jsou pro větší kanceláře. 2.1.4.1
Systémová podpora kontroly střetu zájmů
Prvním problémem je vyloučení právního zastoupení v případě, že advokátní kancelář dříve spolupracovala s protistranou. Pokud nastane situace, kdy informace získané při předchozím zastupování protistrany představují nyní pro kancelář výhodu, musí zastoupení nového klienta odmítnout. Tento problém není jednoduchý, protože pokud má kancelář 140 advokátů, musí se u každého nového případu řešit, zda některý z advokátů nebyl v minulosti zástupcem protistrany. 20
2.1. Analýza advokátních kanceláří Vhodně navržený systém, který obsahuje informace o předchozích klientech, by tento problém mohl zjednodušit. Je potřeba mít na paměti, že zpravidla nestačí jen kontrolovat název firmy, střet zájmů může vzniknout například jen tím, že jeden z majitelů společnosti, která byla zastoupena naší kanceláří je společníkem v další firmě, která je účastníkem nového sporu. Je zapotřebí sledovat nejen klienty, ale také na ně napojené další subjekty. 2.1.4.2
Systémové řešení rychlých auditů
Druhým možným problémem realizace IT je zjišťování informací o všech subjektech, se kterými kancelář přijde do styku. Pokud advokát během řešení případu potřebuje znát více informací o určité osobě nebo společnosti, musí nejdříve projít celou řadu dostupných zdrojů informací (živnostenský rejstřík, obchodní rejstřík, insolvenční rejstřík a další), případně pokud to považuje za nutné, zadá tento úkol zvláštnímu týmu, který pro něj připraví zprávu o tomto subjektu. Systémové řešení tohoto problému by mohlo být součástí mnou navrhovaného řešení: advokát by v rámci aplikace zadal název společnosti a systém sám by shromáždil výsledky z relevantních zdrojů, zároveň by prošel databázi vlastních dokumentů kanceláře, a pokud již existuje podrobný audit, také by jej zobrazil, v opačném případě by advokátovi nabídl možnost zažádat o hloubkovou analýzu tohoto subjektu. 2.1.4.3
Výstup konzultace
Systém by měl představovat jednotné prostředí, které umožní řešení obvyklých případů a zjednoduší komunikaci mezi advokáty a dále zajistí podporu při kontrole nebezpečí střetu zájmů a při provádění auditu osob a společností.
2.1.5
Shrnutí konzultací v advokátní praxi
Proniknout do advokátních praxí tímto způsobem bylo pro mě velice zajímavé a poučné. Setkal jsem se s celou řadu zajímavých osobností a na fungování tohoto světa jsem získal zcela nový pohled. Prvním důležitým poznáním je, že systémové řešení podpory advokátní praxe je oblast, o kterou se advokáti, se kterými jsem měl možnost hovořit, živě zajímali. Uvědomují si, že i relativně konzervativní obory jako je advokacie se postupně vyvíjejí a bez použití nových technologií IT může jejich kanceláři “ujet vlak”. 21
2. Analýza advokacie z pohledu informačních technologií Avšak ne každá kancelář o systémovém řešení pomocí informačních technologií uvažuje - malé kanceláře mají také systémový přístup, ale na jiné úrovni. Teprve kanceláře střední velikosti (kolem třiceti advokátů) musí tuto otázku řešit. Kancelář obvykle nejprve sáhne po řešení na správu dokumentů (DMS systému), který vyřeší její nejpalčivější problém - nakládání s dokumenty. Všechny kanceláře vyžadovaly absolutní anonymitu, ale na mnoha bodech se nezávisle shodly. Jako dodavatele DMS systému volí renomované dodavatele, kteří jsou schopni zajistit nejvyšší bezpečnostní standardy. Ostatní systémy pak kancelář využívá od různých dodavatelů a žádná z kanceláří nevyužívala systém, který by přímo podporoval činnost advokátů procesním způsobem, tj. krok za krokem provázel advokáta splněním úkolu. Advokáti využívají především systémy spojené s podporou dokumentů, protože právě práce s dokumenty je základem advokátovy činnosti. Pokud kancelář cítí potřebu podpořit další činnost, například vykazování práce nebo komunikaci přes datové schránky, pořídí specializovanou aplikaci, která činnost podpoří. Oblast, kterou navštívené kanceláře systémově neřešily je systémová správa celého případu. Společně s advokáty jsem sestavil řadu typizovaných právních případů, které probíhají vždy podobným způsobem a jsou vhodné pro systémovou podporu. Dále jsem zjistil řadu funkčních požadavků, které by pro práci advokáta byly přínosem. Následuje Popis jednotlivých typů případů, který podrobněji popisuje specifické případy, jejichž řešení by mohlo systémové řešení usnadnit.
2.2
Popis jednotlivých typů případů
Tato část analýzy popisuje podrobně konkrétní typy případů, které by mohly být základem systémové podpory. Pro informačního technika není tato oblast příliš blízká. Je však důležité vědět, podle jakých principů advokáti pracují. To je ukázáno na konkrétních typech příkladů doporučených při konzultaci 2.1.2.4.
2.2.1
Popis metody zpracování jednotlivých případů
Výběr typů případů vznikl na základě konzultací s advokáty viz 2.1.2.4. Uvedené případy jsou z jejich pohledu vhodné pro podporu formou informačního systému. Mým cílem v této kapitole je popsat jednotlivé případy a ohodnotit jejich vhodnost pro systémovou podporu. V praktické části své 22
2.2. Popis jednotlivých typů případů práce některé z případů zahrnu do svého ukázkového řešení. Přehled případů zahrnutých do ukázky je uveden v tabulce 2.2.11 na konci této kapitoly. Analýzu jednotlivých případů jsem provedl ve třech krocích. Prvním krokem bylo získání základních informací o případech od advokáta, s kterým jsem konzultoval. V druhém kroku jsem se snažil získat co nejvíce informací o průběhu jednotlivých činností z veřejně dostupných publikací – komentářů k zákonům, renomovaných webových serverů a především publikací v knihovně právnické fakulty, do které mám jako zdejší student přístup. Na závěr jsem informace ze sekundárních zdrojů ověřil v primárním zdroji, tedy v konkrétním právním předpisu, který problematiku upravuje. Primární zdroj je důležitý pro případný další vývoj. Normy je nutné sledovat a reagovat na jejich změny. Moje výstupy jsou vždy ověřeny v účinné legislativě. Zde je potřeba upozornit na rozdíl mezi účinnou a platnou právní normou. Platný zákon, například nový občanský zákoník, je již schválenou úpravou, ale dokud nenabyde účinnosti, v tomto případě k 1. 1. 2014, řídí se právní úkony původní normou. Pro přehlednost jsem se rozhodl použít vždy aktuálně účinnou právní úpravu (vztaženo k datu obhajoby práce). Jednotlivé případy zkoumám relativně podrobně tak, aby tento materiál poskytl skutečně dobrý základ budoucího řešení. Výstupem jsou především dokumenty spojené s daným případem a posloupnost kroků daného případu.
2.2.2
Založení společnosti s ručením omezeným
Společnost s ručením omezeným (s.r.o.) je jedním z nejrozšířenějších způsobů podnikání. Akciové společnosti, veřejné obchodní společnosti a další formy podnikání jsou podle konzultací řešeny v podstatně menším rozsahu – soustředil jsem se na tento typ společnosti. Aby mohla společnost s ručením omezeným vzniknout, musí podle [43] být učiněny dva kroky – společnost musí být založena a musí dojít k jejímu zápisu do obchodního rejstříku, čímž skutečně vznikne jako subjekt v obchodním právu. Popis vzniku společnosti s ručením omezeným lze najít například v [10], z tohoto článku jsem vycházel, při své práci já.
23
2. Analýza advokacie z pohledu informačních technologií Kroky nutné k vzniku s.r.o. 1. Uzavření společenské smlouvy formou notářského zápisu, §57 [14] 2. Složení základního jmění společnosti nebo jeho části, §60 [14] 3. Získání živnostenských oprávnění (živnostenských listů atp.), 4. Zápis společnosti do obchodního rejstříku, 5. Registrace společnosti u finančního úřadu. Uzavření společenské smlouvy formou notářského zápisu Společenská smlouva, která obsahuje všechny náležitosti a je podepsána všemi společníky již sama "zakládá"společnost, ale založení není totožné se vznikem. Společenská smlouva musí obsahovat podle § 110 Obchodního zákoníku [14] následující: (a) firmu a sídlo společnosti, (b) určení společníků uvedením firmy nebo názvu a sídla právnické osoby nebo jména a bydliště fyzické osoby, (c) předmět podnikání (činnosti), (d) výši základního kapitálu a výši vkladu každého společníka včetně způsobu a lhůty splácení vkladu, (e) jména a bydliště prvních jednatelů společnosti a způsob, jakým jednají jménem společnosti, (f) jména a bydliště členů první dozorčí rady, pokud se zřizuje, (g) určení správce vkladu, (h) jiné údaje, které vyžaduje obchodní zákoník. Složení základního jmění společnosti nebo jeho části Způsob složení vkladů je určen společenskou smlouvou a pro systémovou podporu není způsob technického provedení zcela podstatný. Ve společenské smlouvě je určen správce vkladu, může jím být jeden z jednatelů nebo externí osoba. Správce založí v bance účet, který slouží ke složení vkladů jednotlivých společníků. Banka vystaví na jméno společnosti potvrzení o složení základního kapitálu. Složené peníze pak zůstanou deponovány na účtu do doby než správce vkladu dodá výpis z obchodního rejstříku, ze kterého je zřejmé, že společnost již vznikla. Následně je účet obvykle převeden na běžný podnikatelský účet. 24
2.2. Popis jednotlivých typů případů Získání živnostenských oprávnění (živnostenských listů atp.) Společnosti založené za účelem podnikání potřebují získat před svým vznikem živnostenské nebo jiné podnikatelské oprávnění [43]. Podmínky ohlášení jsou uvedeny v Hlavě I: Ohlašování živností, Zákona č. 455/1991 Sb., o živnostenském podnikání [13] Dokumenty spojené se založením společnosti • Společenská smlouva • Doklad o složení základního jmění • Potvrzení o živnostenském oprávnění • Výpis z obchodního rejstříku • Výpisy z rejstříku trestů jednatelů. • Potvrzení o užívacím právu pronajímatele prostor Zakládání dalších typů společností Tento typ případu jsem se rozhodl pro účely své práce vynechat – své řešení navrhuji pouze pro společnosti s ručením omezeným. Další typy společností se mohou lišit, ale princip zůstává zachován a flexibilita mého řešení by měla umožnit advokátní kanceláři, aby sama rozhodla, případně nastavila případy, které chce podpořit systémovým řešením. Přidat například podporu založení akciové společnosti bude relativně snadné.
2.2.3
Likvidace společnosti s ručením omezeným
Likvidace obchodní společnosti je dalším častým právním úkonem, který lze dobře podpořit vhodným systémovým řešením. Zánik společnosti může nastat z různých příčin, já se ve své práci soustředím na zánik společnosti s ručením omezeným, tzv. „s likvidací“. Společníci v takovém případě usilují o celkové ukončení aktivit společnosti a nechtějí nadále zodpovídat za její činnost. Důvodem tohoto rozhodnutí je opět výsledek mých konzultací, který ukázal, že právě tento případ je nejčastější a pro řešení nejvhodnější. Popis postupu lze nalézt například v [7]. Dále se problematikou zabývá [35], zde lze také nalézt vzorová podání. Dalším zajímavým zdrojem je [38], který popisuje podrobně rušení společností. 25
2. Analýza advokacie z pohledu informačních technologií Kroky nutné k likvidaci s.r.o. 1. Rozhodnutí vlastníků o vstupu firmy do likvidace (vč. notářského zápisu) 2. Jmenování likvidátora 3. Zapsání informace o vstupu do likvidace v OR 4. Protokolární převzetí firmy likvidátorem 5. Zpracování mimořádné účetní závěrky 6. Zjištění, zda firma není předlužená (pro případný návrh na vstup do konkurzního řízení) 7. Oznámení vstupu firmy do likvidace 8. Sestavení programu likvidace 9. Samotná likvidace a) Ukončení pracovních a jim obdobných poměrů b) Vypořádání pohledávek a závazků společnosti c) Zpeněžení majetku, pokud nebyl součástí konkurzu 10. Archivace firemních dokumentů 11. Sepsání závěrečné zprávy 12. Rozdělení likvidačního zůstatku mezi majitele firmy 13. Zpracování konečné účetní závěrky 14. Výmaz firmy z OR = zánik společnosti Rozhodnutí o zrušení společnosti Rozhodnutí o zrušení společnosti provádí příslušný orgán, pro společnost s ručením omezeným je to valná hromada, je ale možné podrobnosti vymezit ve společenské smlouvě, například určit, zda o zániku musí rozhodnout valná hromada jednomyslně nebo pouze nadpoloviční či kvalifikovanou většinou. 26
2.2. Popis jednotlivých typů případů Likvidace Likvidací je myšleno vypořádání majetkových vztahů společnosti, řeší se dluhy společnosti a její zbytková hodnota. Proces likvidace řídí likvidátor – může jím být najatý profesionál nebo jeden ze společníků. První otázkou, kterou musí likvidátor vyřešit je, zda není společnost předlužená, tedy zda její dluhy převyšují současnou hodnotu veškerého majetku. V takovém případě je vyhlášen konkurz, což je jiný typ případu, kterým se zde nezabývám. Likvidátor jedná jménem společnosti, ale pouze ve smyslu úkonů, které směřují k likvidaci společnosti. Likvidátor postupně řeší všechny závazky společnosti, tyto úkony probíhají nejméně několik měsíců, nezřídka rok i déle. Výmaz společnosti z obchodního rejstříku Výmazem je společnost opravdu zrušena, návrh na výmaz podává likvidátor do třiceti dnů od skončení likvidace. Jedná se o jednu z rejstříkových operací. Podrobnosti o rejstříkových řízeních v kapitole 2.2.9 Dokumenty spojené s likvidací společnosti: • Rozhodnutí o vstupu do likvidace • Jmenování likvidátora • Návrh na vstup společnosti do likvidace • Mimořádná a závěrečná účetní uzávěrka • Závěrečná zpráva o likvidaci • Návrh na výmaz společnosti z obchodního rejstříku Likvidace společnosti je rozhodně vhodným tématem na systémové zpracování. Doba běhu každého případu může přesáhnout i rok a může být náročné efektivně sledovat, které kroky již proběhly.
2.2.4
Zástavní smlouvy
Zástavní smlouva vzniká na základě občanského zákoníku. Jedná se o formu ručení dlužníka věřiteli, že dostojí svým závazkům. Speciální formou je hypotéka, případ, kdy předmětem zástavy je nemovitost. Přesto, že během konzultací byla zástavní smlouva jmenována mezi možnými kandidáty na podporovaný typ případu, po prostudování problematiky v [8], jsem přesvědčen, že její uzavření není třeba řešit tímto způsobem, jedná se pouze o zvláštní typ dokumentu. 27
2. Analýza advokacie z pohledu informačních technologií Zajímavou by mohla být zástavní smlouva, která nebyla dodržena, tedy postup při vymáhání pohledávky, tímto typem případů se zabývám v 2.2.7. Pro rozšířené řešení je i tento typ případu vhodný, ale pro základní demonstraci se příliš nehodí, klade na systém relativně malé nároky. Dokument Zástavní smlouva má podle [8] následující náležitosti: • Jednotlivé smluvní strany • Přesné označení zástavy a pohledávky • Závazek zástavce dát zástavnímu věřiteli určitou věc nebo jiný způsobilý předmět zástavního práva do zástavy. • Forma notářského zápisu
2.2.5
Převod nemovitosti
Převod nemovitosti je velmi častým typem obchodního jednání. Iniciuje jej uzavření platné kupní smlouvy dle § 588 občanského zákoníku [14]. Právě následný převod provedený příslušným katastrálním úřadem dokončí toto právní jednání. Převod provede úřad na základě návrhu, který mohou podat všichni účastníci jednání nebo některý z nich. Náležitosti návrhu upravuje §4 zákona č.265/1992 Sb. [15] (3) Návrh na zahájení řízení musí obsahovat (a) označení katastrálního úřadu, kterému je návrh určen, (b) jméno a příjmení, trvalý pobyt a rodné číslo fyzických osob nebo název, sídlo a identifikační číslo právnických osob, které jsou účastníky řízení (c) označení práv, která mají být zapsána do katastru. (4) Přílohou návrhu musí být (a) listina, na základě které má být zapsáno právo do katastru, (. . . ) (b) plná moc, je-li účastník řízení zastoupen zmocněncem, (c) výpis z obchodního nebo jiného zákonem určeného rejstříku, (. . . ) 28
2.2. Popis jednotlivých typů případů (d) listina prokazující oprávnění vlastníka nebo jiné osoby (. . . ) nakládat s předmětem právního úkonu (. . . ) (e) úředně ověřený překlad listiny, (. . . ), pokud tato listina není sepsána v českém jazyce.
2.2.6
Nájemní smlouvy
Nájemní smlouva je podobný případ jako smlouva zástavní, jedná se o specifický typ dokumentu – smlouvy, který musí obsahovat řadu náležitostí, ale její sepsání nepovažuji za vhodného kandidáta pro mé systémové řešení. Stejně jako zástavní smlouvu, jsem se rozhodl zařadit ji mezi specifické dokumenty. Případná porušení náležitostí vyplývajících z nájemní smlouvy bude možné řešit v rámci ostatních typů případu. Dokument nájemní smlouvy obsahuje náležitosti dle vzoru uvedeného v[22]: • Pronajímatele • Nájemce • Prohlášení pronajímatele, že je výlučným vlastníkem bytu. • Předmět nájmu (údaje o bytu včetně výbavy) • Nájemné • Práva a povinnosti spojené s nájmem bytu • Výpis z katastru nemovitostí • Protokol o předání bytu • Fotodokumentace bytového vybavení • Prohlášení stran a podpisy
2.2.7
Platební rozkaz / Vymáhání pohledávky
Vymáhání pohledávek je specifickou oblastí právní praxe. Žádná z kanceláří, kde jsem konzultoval, se nezabývá vymáháním drobných pohledávek systematickým způsobem. Tento model mi vysvětlil zkušenější kolega pracující v advokátní kanceláři, která se touto problematikou zabývá. 29
2. Analýza advokacie z pohledu informačních technologií Kancelář měla specializovaný systém napojený na pojišťovnu, která do něj zadávala dluhy po splatnosti, advokátní kancelář zajistila zaslání dvou upomínek, následně podala návrh na vydání platebního rozkazu – rozhodnutí soudu, že částka má být zaplacena. Systém byl přímo napojený na exekutora, který obratem začal s vymáháním pohledávky. Tato oblast právního podnikání stojí částečně mimo renomované kanceláře a rozhodl jsem se s ní nezabývat. Při vymáhání větších pohledávek se postupuje podobným způsobem. 1. Dvojí upomenutí dlužníka – dlužník je opakovaně upomínán, aby zaplatil svůj dluh. Důležitou součástí každé upomínky je povinné připojení postupu ke splacení dluhu – kolik a jakým způsobem zaplatit (například číslo účtu, variabilní symbol). Nestačí pouze informace, že dlužník dluží. 2. Pokud nedojde k nápravě, je podána žádost u místně příslušného soudu k vydání platebního rozkazu. Platební rozkaz je dalším dokumentem a je doručen dlužníkovi. 3. Pokud se dlužník dále zdráhá zaplatit, podá kancelář návrh na vydání exekučního rozkazu. Dokumenty spojené s případem: • Upomínka • Návrh na vydání platebního rozkazu • Platební rozkaz • Návrh na uvalení exekuce Problematika vymáhání pohledávek je určitě zajímavá z pohledu systémové podpory, protože přináší potenciálně vysoké zisky. Nemyslím si však, že je vhodné zahrnout podobná řešení do ukázkového řešení, ne každá kancelář se chce touto oblastí práva zabývat a při prezentaci řešení by mohlo dojít ke zbytečné negativní reakci ze strany advokátů, kteří tyto případy považují za méně etické nebo podřadné. 30
2.2. Popis jednotlivých typů případů
2.2.8
Veřejná zakázka
Veřejné zakázky jsou zajímavým tématem, jejich problematika je ale specifická. Dnes již existují specializovaná řešení v této oblasti. Mezi řešení, která jsou dostupná v české republice lze zahrnout: • Systém E-ZAK, společnosti QCM, s.r.o. [39] • Informační systém pro podporu procesu podávání přihlášek a hodnocení nabídek. dataPartner s.r.o.[11]
2.2.9
Rejstříková řízení
Obchodní rejstřík je jeden ze základních zdrojů hodnověrných informací o povaze a stavu konkrétních obchodních společností. Jedná se o veřejně dostupný institut, který umožňuje, aby každý, kdo má přijít do styku s existující obchodní společností, mohl ověřit základní informace, které jsou s ní spojeny. Prvním typem případu pro podporu ze strany systému bude zápis do obchodního rejstříku – jednostranný právní akt právnické osoby, která tak zpřístupňuje informace o svém fungování. Existují obecně dva druhy zápisů: konstitutivní a deklaratorní. Konstitutivní jsou tzv. právotvorné, jedná se o zásadní taxativně vymezené právní akty, které jsou natolik závažné, že k jejich završení dojde až ve chvíli, kdy je skutečnost zapsána v obchodním rejstříku. Deklaratorní zápisy naproti tomu pouze oznamují právní jednání, které již proběhlo a v rejstříku je tak uvedeno “zpětně”. Pro příklad uvádím některé druhy zápisů: • Konstitutivní zápisy – Prvozápis obchodní společnosti do rejstříku – Výmaz právnické osoby z rejstříku – Zápis obchodní firmy • Deklaratorní zápisy – Zápis změny v osobě statutárního orgánu (například jednatel obchodní společnosti) – Zápis změny v osobě společníka Zápis provede rejstříkový soud, u kterého byl podán návrh na zápis. Formuláře všech dokumentů jsou veřejně dostupné na serveru justice.cz [21]. Já popisuji zápisy spojené se založením a likvidací společnosti s ručením omezeným. 31
2. Analýza advokacie z pohledu informačních technologií Prvozápis obchodní společnosti do rejstříku Návrh na zápis do obchodního rejstříku se podává u příslušného rejstříkového soudu. Návrh na zápis podepisují všichni jednatelé, podpisy musí být úředně ověřeny. Náležitosti návrhu na prvozápis dle [26] Jako přílohy se k návrhu přikládají: • Za společnost – společenská smlouva nebo zakladatelská listina, – oprávnění k podnikatelské činnosti (živnostenské listy atp.), – listina osvědčující právní důvod užívání místností, a to výpis z katastru nemovitostí (. . . ), souhlas (spolu)vlastníka (. . . ). – doklad(y) o splnění vkladové povinnosti (potvrzení správce vkladů/banky, posudky znalců, atp.), • Za každého jednatele – výpis z Rejstříku trestů ne starší 3 měsíců – čestné prohlášení jednatele, že ∗ je plně způsobilý k právním úkonům, ∗ splňuje podmínky provozování živnosti podle (. . . ) ∗ splňuje podmínky podle § 38l obchodního zákoníku [14] Výmaz obchodní společnosti Návrh podává zpravidla likvidátor, využije k tomu opět formulář dustupný na serveru justice.cz [21]. Návrh na výmaz z OR obsahuje: • Příslušný rejstříkový soud • Navrhovatele • Údaje o vymazávaném subjektu • Návrh na zápis výmazu (tzv. petit) • Přílohy (uvedené dále) • Datum provedení zápisu 32
2.2. Popis jednotlivých typů případů
2.2.10
Ochranné známky
Ochranné známky jsou dnes velmi skloňovaným tématem, obzvlášť v oblasti informačních technologií, kde společnosti soupeří často spíše v soudní síni než ve vývojových odděleních. Připomínkou může být obrovský soudní spor mezi společnostmi Apple a Samsung kvůli patentům v oblasti tabletů (mobilních počítačových zařízení). Zabývá se jím zákon o ochranných známkách č. 441/2003 Sb. [16] Následuje citace z webových stránek úřadu průmyslového vlastnictví [44]: "Ochrannou známkou je označení grafického znázornění, tvořené zejména slovy, písmeny, číslicemi, barvou, kresbou nebo tvarem výrobku či jeho obalu, určené k rozlišení výrobků nebo služeb. Přihlášku ochranné známky k zápisu do rejstříku může podat jak fyzická, tak i právnická osoba. Úřad průmyslového vlastnictví provede formální průzkum, zda má přihláška zákonem předepsané náležitosti, a poté i věcný průzkum, při němž zjišťuje, zda předmětem přihlášky není označení, které je nezpůsobilé k zápisu do rejstříku. (...) Zápisem do rejstříku získává vlastník ochranné známky výlučné právo tuto známku používat. Platnost zápisu trvá 10 let, tuto dobu však vlastník může proti zaplacení poplatku prodloužit podáním žádosti o obnovu zápisu vždy o dalších 10 let." Základem žádosti je dokument "Přihláška ochranné známky"o jeho náležitostech je více uvedeno přímo v §19 zákona č. 441/2003 Sb. o ochranných známkách [16]. Další podrobnosti, stejně jako znění paragrafu uvedeného níže lze nalézt v [6]. § 19 Přihláška (1) O zápis ochranné známky do rejstříku se žádá přihláškou podanou u Úřadu; každá přihláška se může týkat jen jedné ochranné známky. (2) Přihláška musí obsahovat: (a) žádost o zápis ochranné známky do rejstříku, (b) jméno a příjmení fyzické osoby a adresu místa jejího trvalého pobytu, popřípadě adresu pro doručování, je-li přihlašovatelem fyzická osoba, nebo obchodní firmu, popřípadě jiný název a sídlo, je-li přihlašovatelem právnická osoba, (dále jen "údaje o totožnosti"), (c) údaje o totožnosti zástupce, je-li přihlašovatel zastoupen, 33
2. Analýza advokacie z pohledu informačních technologií (d) seznam výrobků nebo služeb, pro něž se požaduje zápis ochranné známky, (e) znění nebo plošné vyobrazení přihlašované ochranné známky. (3) Přihlašovatel ochranné známky je povinen ve lhůtě 1 měsíce ode dne podání přihlášky zaplatit správní poplatky (. . . ) (4) Seznam výrobků nebo služeb, pro něž se požaduje zápis ochranné známky, se v přihlášce uvádí v pořadí tříd mezinárodního třídění spolu s příslušným číslem třídy. (. . . ) (5) (. . . ) (6) Přihláška musí být podepsána přihlašovatelem nebo jeho zástupcem. (7) Další náležitosti přihlášky týkající se údajů o vyobrazení ochranné známky stanoví prováděcí právní předpis. Z §19 jasně vyplývají náležitosti, které je potřeba zjistit dříve než může být přihláška podána: • Jedna ochranná známka = jeden dokument přihlášky • Text žádosti • Údaje o přihlašovateli • Seznam výrobků a služeb (s jasně definujícím popisem) • Znění nebo plošné zobrazení ochranné známky Postup při získání ochranné známky je relativně snadný, advokát musí dohlédnout na dodání všech podkladů a následně vytvoří přihlášku a doručí ji na úřad průmyslového vlastnictví.
2.2.11
Závěr popisu případů
Jednotlivé typy případů jsem zhodnotil, zda je zahrnu do svého ukázkového řešení. Výstup je v tabulce 2.2.11. Řešení, které podporu případů zajistí, musí počítat se změnami v legislativě a být dostatečně flexibilní. Dalším krokem po zjištění potřeb advokátů a nastudování případů je analýza již existujících systémů, které jsou dostupné. 34
2.3. Existující systémová řešení Typ případu Založení s.r.o.
Součást řešení ANO
Likvidace s.r.o.
ANO
Zakládání spol.
dalších
NE
Zástavní smlouvy
NE
Převod nemovitosti
NE
Nájemní smlouvy
NE
Vymáhání pohledávky
NE
Veřejná zakázka
NE
Rejstříková řízení
ANO
Ochranné známky
ANO
2.3
ukázkového
Důvod Vhodné pro ukázku sledování kroků, delegaci činností a práci s dokumenty Vhodné doplnění zakládání společnosti Velmi podobné předchozím případům, méně časté Pouze specifický dokument - podobné Ochranné známce Pouze specifický dokument - podobné Ochranné známce Pouze specifický dokument - podobné Ochranné známce Existující specializovaná řešení Existující specializovaná řešení Zahrnuto v zakládání a likvidaci s.r.o. Ukázka jednoduššího případu
Existující systémová řešení
Kapitola shrnuje existující řešení, dostupná na trhu, která řeší požadavky advokátů. Jsou to systémy zmíněné advokáty a nabídka firem, které se na advokacii specializují. Bylo by totiž chybou snažit se s novým řešením nahrazovat všeobecně přijatý standard. Vyšel jsem z povědomí advokátů o systémech, které jsou k dispozici a z konzultace ve společnosti ASPI, která na trhu se systémy pro advokáty podniká. Advokáti nezmínili ucelené systémové řešení. Na internetu jsem nalezl několik systémů, které se podle své webové prezentace na práci s ad35
2. Analýza advokacie z pohledu informačních technologií vokátními kancelářemi specializují. Snažil jsem se společnosti přímo oslovit, bohužel jsem nebyl úspěšný. Žádná z oslovených společností mi neposkytla podrobnější informace nebo možnost systém vyzkoušet. Systémy, které používají konzultovaní právníci z mezinárodních kanceláří, jsou podobné. Základem je systém na správu dokumentů – DMS systém. Advokáti volí renomované dodavatele. Především šlo o aplikaci Microsoft Sharepoint. Svoje řešení nabízí v této oblasti celá řada společností včetně IBM (IBM Filenet P8). Většinu dalších funkcionalit, které advokáti využívají, představují oddělené, specializované programy (účetnictví, docházka, fakturace a další), každá kancelář využívala aplikace, které považovala za nejlepší pro své konkrétní potřeby. Výjimku tvoří systémy obsahující legislativní zdroje. Zde vede systém ASPI [2], byl zmíněn při všech mých konzultacích. Konkurencí je systém CODEXIS [3], který funguje na stejném principu a obsahuje, kromě českých dat i evropská. Omezím se na popis ASPI 2.3.1. Kvalita ASPI i všech konkurenčních systémů spočívá ve schopnosti doplňovat a aktualizovat databázi všech pramenů.
2.3.1
ASPI
Rozhodl jsem se navštívit zástupce společnosti Wolters Kluwer ČR, která dodává v ČR systém ASPI , abych zjistil, zda společnost nabízí i další systémy na podporu advokátů. Také jsem doufal, že odborník z praxe, který se skutečně zabývá prodejem IT systémů advokátním kancelářím, bude schopný poradit při návrhu mého systému. Konzultace pro mne nebyla bohužel tak přínosná, jak jsem doufal. Nesetkal jsem se s konstruktivním přístupem jako u advokátů. Zástupce WK zůstal u oblasti, které se ASPI věnuje, tedy katalogu judikatury, právních norem a vzorů. Shodli jsme se, že koncept systému, jak jej navrhuji, je zajímavý a systém ASPI je mu vhodným doplňkem. Z výsledku konzultace vyplynulo, že systém ASPI je schopný spolupracovat s dalšími systémy, které kancelář využívá, ale podobná spolupráce je možná jen u striktně vybraných systémů. Společnost ASPI se specializuje na nabízení především svého specializovaného řešení a do dalších oblastí příliš neexpanduje. 36
2.3. Existující systémová řešení
2.3.2
Společnosti specializující se na poskytování IT řešení pro advokacii
Následuje přehled společností, které se dle své webové prezentace specializují na služby pro advokátní kanceláře. U každého systému je uveden výčet jeho funkcí. Acta safe [1] • evidence spisů • termíny a události • fakturace • správa dokumentů • plánování práce Evolio [4] • vedení advokátního spisu • elektronická evidence všech dokumentů a pošty • tiskové výstupy do MS Word • evidence úkonů a nákladů advokáta • finance • týmová práce s úkoly • výkaz práce • podatelna • importy a exporty • elektronická podání na soud, ARES, registr úpadců atd. • připraveno k propojení na datové schránky 37
2. Analýza advokacie z pohledu informačních technologií SynopsIS [34] • evidence a správa zakázek (spisů, projektů apod.) • evidence a správa pohledávek • evidence úkonů, vykonané práce - timesheet • datové úložiště pro Vaše dokumenty související se spisy (zakázkami) • elektronická spisová služba (listovní zásilky, datové schránky, e-mail) • evidence vozidel, řidičů a jízd • evidence nákladů • evidence a správa výkazů a vyúčtování • adresář s možností členění do skupin • podrobné statistiky, přehledy a exporty do různých formátů Společnosti se zaměřují především na práci s dokumenty. Bližší informace lze nalézt na internetových stránkách jednotlivých společností. Mým cílem bylo zjistit, jak velké kanceláře tyto systémy používají a zda vyhovují jejich potřebám, a proto jsem oslovil všechny advokátní kanceláře, které byly uvedeny v referencích společností. Získal jsem však pouze jedinou referenci od kanceláře Továrek, Horká a partneři využívající systém SynopsIS. Problematikou informačních systémů pro advokátní kanceláře se zabývá ve své práci Černá [12]. Podrobněji popisuje existující systémy a doplňuje další řešení nabízená pro advokátní kanceláře. Žádný systém se ale nezabývá konfliktem zájmů, shromažďováním údajů o subjektech nebo podporou postupů při řešení případů. Specializují se spíše na vedení spisu a s tím spojenou agendu (archivaci, komunikaci a práci s dokumenty v rámci spisu). Černá [12] provedla také analýzu využití těchto systémů formou dotazníků a telefonických dotazů. Práce obsahuje odpovědi od osmnácti kanceláří především z Brna. Dvě třetiny kanceláří komplexní systém nevyužívají. Jedna kancelář používá systém Jurisdix AK [42], který je určen přímo pro advokátní kanceláře. Navštívil jsem internetové stránky produktu a profesionalita prezentace produktu neodpovídá renomovanému profesionálnímu řešení, na které by spoléhaly významnější advokátní kanceláře. Zbylých osm kanceláří využívá informační systém připravený na míru. 38
2.3. Existující systémová řešení
2.3.3
Shrnutí existujících řešení
Z existujících řešení mě nejvíce zaujal systém SynopsIS, bohužel odezva společnosti na spolupráci byla negativní, takže mohu vycházet pouze z webové prezentace a jediné reference. Zajímavým zdrojem je práce Černé [12], která provedla podobný průzkum (bez osobních konzultací), zaměřený na existující systémová řešení. Výsledkem je, že univerzální řešení nejsou úspěšná a kanceláře vyžadují řešení, která se přizpůsobí jejich potřebám. Robustní platformy IBM nebo dalších velkých společností by mohly těžit ze schopnosti připravit řešení "na míru"bez nutnosti samostatného vývoje. Jejich výhodou je jistota vysoké bezpečnosti a stability celého řešení, vycházející z investic věnovaných do vývoje těchto platforem. Práce má ověřit možnost vytvoření právě takového řešení v technologiích IBM ACM, protože však chci, aby práce nebyla plně svázána s konkrétními aplikacemi, navrhnu nejdřív obecnou architekturu, která může být základem řešení kteréhokoliv dodavatele. Spojení s Baťou v Africe ukazuje se, že situace v advokacii se skutečně v lecčems podobá době, kdy se Baťa snažil prorazit s obuví na černém kontinentu. Pokud dvě třetiny advokátů nevyužívají systémových řešení, přestože oblast jejich činnosti k tomu přímo vybízí, je nejspíš na vině neschopnost IT firem správně uchopit potřeby advokátů. IT odborníci zřejmě často neumějí advokátům vysvětlit, proč by měli systém využívat. Úspěšný dodavatel systému bude muset vyřešit stejnou otázku jako Baťa, když přemýšlel, jak Afričanům vysvětlí, že mají nosit boty. On uspěl a myslím, že je možné stejně přesvědčit i advokáty.
39
Kapitola
Obecná architektura systému 3.1
Postup při návrhu systémového řešení
Analýza advokátních kanceláří mi ukázala, jaké problémy advokáti denně řeší a jaké nástroje používají. Existující systémová řešení nepokrývají veškerou funkcionalitu, kterou by kancelář mohla využívat, případně není řešení pro advokáty dostatečně lákavé, protože nevědí, jak by jim mohlo pomoci. Ukázalo se, že požadavky se u jednotlivých kanceláří liší podle jejich zaměření. Systém musí být schopný se jim přizpůsobit. Dalším krokem je návrh takového systémového řešení, které by advokátům vyhovovalo. Nastudoval jsem problematiku systémové architektury v publikaci Systems Architecting: A Business Perspective od Mullera [37]. Základem je propojení požadavků zákazníka s realizací systému. Návrh architektury systému předchází implementaci systému, kterou provede podle architektonického rámce společnost s odpovídajícími možnostmi. Muller [37] představuje model CAFCR, který má vést k zmíněnému cíli, propojení zákaznických požadavků a návrhu řešení. Nejprve stručně popíšu tuto metodiku, následně definuji požadavky, které vycházejí z předcházející analýzy prostředí advokacie a vytvořím architektonický rámec systémového řešení, který odpoví na dané požadavky. Návrh systému připraveného k okamžitému nasazení překračuje rámec této práce, mým cílem je především poukázat na oblasti, které jsou z pohledu systémového řešení nejzajímavější a na ně se zaměřit. Pokud se však ukáže, že tento typ řešení je pro advokáty zajímavý a najde si zájemce o jeho implementaci, může práce dobře sloužit jako základ komplexního systému. Model CAFCR Cílem modelu je ukázat systém v kontextu, ve kterém je použit. Využívá k tomu pět oblastí, na které se architekt má zaměřit. 41
3
3. Obecná architektura systému Práce architekta spočívá dle [37] ve schopnosti nahlížet na řešení z různých pohledů a přecházet mezi nimi. Pohledy architekta • Customer objectives (zákaznické cíle), CO je zákazníkovým cílem, CO bude výsledkem, který je pro něj relevantní, jaké konkrétní zlepšení mu systém přinese? • Application (aplikace) JAK získá zákazník požadovanou funkcionalitu, ne na úrovni implementační, ale z pohledu zákazníka. Například, jak zajistím komunikaci s klienty? S pomocí emailového klienta. • Functional (funkce) CO musí obsahovat produkt, zde přecházíme z definice požadavků zákazníka na schopnosti zajištěné systémem. • Conceptual (koncept) JAKÁ je vhodná koncepce systému, aby naplňoval své funkce. • Realization (realizace) JAK konkrétně by měl být koncept realizován, tato část již spadá do další kapitoly - Architektura IBM řešení 4. Jednotlivé pohledy nepředstavují oddělené části návrhu, spíše aspekty, které je třeba mít na zřeteli během celého procesu návrhu architektury. Zevrubný popis této metodiky není součástí mé práce, čtenáře odkazuji na [37].
3.2
Definice požadavků na systémové řešení
Tato kapitola definuje požadavky na případné systémové řešení. V předchozích částech práce jsem analyzoval oblast advokacie z pohledu informačních technologií. Nyní je mým cílem převést tyto informace na souhrn požadavků, které by mělo naplňovat případné řešení. Výstupem je přehled funkcí, které by měl výsledný systém naplňovat. V modelu CAFCR se pohybujeme především v oblasti Customer objectives (Zákaznické cíle).
3.2.1
Hlavní funkce systému
3.2.1.1
Jednotné prostředí
První a snad nejdůležitější vlastností systému je jednoduchost a přívětivost k uživateli. Právníci advokátních kanceláří jsou velmi zřídka nadšenci informačních technologií, jak jsem zjistil během všech svých konzultací. Práce 42
3.2. Definice požadavků na systémové řešení advokáta je velmi vyčerpávající a časově náročná, zcela určitě nelze očekávat, že bude trávit čas nastavováním nebo laděním uživatelského prostředí či celého systému. Vše musí fungovat jednoduše a advokáta neomezovat v běžné činnosti. Cílem je, aby všichni pracovníci v kanceláři využívali stejné rozhraní. Nabídnout jediné prostředí, ve kterém zaměstnanci advokátní kanceláře naleznou veškerou požadovanou funkcionalitu (všechny další funkce, které navrhuji i přístup k dalším systémům, které kancelář již používá). 3.2.1.2
Podporované typy případů
Existuje celá řada typizovaných případů, kde je vhodné nasadit systémovou podporu, jsou podrobně rozebrány v kapitole 2.2. Advokáti řeší tyto případy relativně často a proto je vhodné je podpořit systémovým řešením, protože část jednoduchých úkonů může systém udělat sám, jinde pomůže v rychlejší odezvě nebo snazší delegaci. Důležité je, aby systém byl flexibilní, někdy advokát potřebuje provést založení společnosti velmi rychle a nechce žádné aktivity delegovat. Jindy potřebuje řešit důležitější věci a aktivity spojené se založením společnosti přenechá například právním koncipientům. Advokát, který případ řeší, by měl mít možnost zapojovat další spolupracovníky libovolně. Jednoduchý a přehledný seznam úkolů spojený s každým typem případu, který ihned ukáže, které kroky ještě chybí, by advokátovi rozhodně práci usnadnil. 3.2.1.3
Správa dokumentů
Dokumenty hrají v advokátní kanceláři ústřední roli, všechny aktivity a procesy jsou s nimi spojeny. Nejen advokáti s nimi přijdou do styku, ale také právní koncipienti a asistenti, denně pracují s dokumenty. Dokumenty je potřeba vyhledávat, označovat, kategorizovat. Je nutné společně s dokumentem ukládat informace o datu jeho vytvoření i o autorovi. Standardně k tomu slouží systémy na správu dokumentů (Document management system = DMS). Seznam základních funkcí DMS systému • pokročilá správa přístupu k dokumentům pomocí firemních politik. • automatické zálohování veškerých dokumentů. • spolupráce nad dokumenty a jejich verzování (uložení předchozích verzí) 43
3. Obecná architektura systému • full-textové vyhledávání • snadné vytváření dokumentových tříd • ukládání informací o dokumentech (autor, datum vytvoření. . . ) Systém musí v oblasti správy dokumentů splňovat dnešní bezpečnostní standardy. Zjistil jsem, že řada kanceláří již podobný systém využívá, nové řešení by mělo umožnit napojení na stávající systém a uchovat si tak atraktivitu pro širší spektrum potenciálních uživatelů. 3.2.1.4
Analýza konfliktu zájmů
Dalším problémem, který advokátní kanceláře často řeší, je konflikt střetu zájmů. Advokát nesmí zastupovat klienta v případě že během předchozí advokátní praxe získal informace, které by znevýhodňovaly protistranu. Pokud pracuje advokát v rámci kanceláře, je nutné, aby žádný z jejich advokátů v takovém postavení nebyl. Dříve než kterýkoliv advokát uzavře smlouvu o zastupování klienta, musí ověřit u všech ostatních advokátů dotyčné kanceláře, jestli nehrozí konflikt zájmů. Kanceláře již obvykle vedou databázi svých klientů, případně využívají CRM systém (Customer Relationship Management – Systém na podporu a správu vztahů se zákazníky). Nemají ale řešení, které by nacházelo vztahy mezi klienty a protistranou. Například existuje riziko, že jednatel protistrany je zároveň majitelem společnosti, kterou kancelář v minulosti zastupovala. Systém by měl umět toto spojení nalézt. 3.2.1.5
Napojení na veřejně dostupné zdroje informací
Systém by měl umožnit advokátům snadný přístup k veřejně dostupným zdrojům informací o právních subjektech. • Obchodní rejstřík [19] • Živnostenský rejstřík [18] • Insolvenční rejstřík [20] • ARES registr [36] • Info-soud [17] 44
3.2. Definice požadavků na systémové řešení Obchodní rejstřík je základním zdrojem informací o obchodních společnostech. Vede ho příslušný rejstříkový soud (krajský soud). Zapisují se zejména: firma, sídlo, předmět podnikání, identifikační číslo, statutární orgány a další. Živnostenský rejstřík spravuje Živnostenský úřad České republiky, zapisují se údaje spojené s provozováním živnosti, především informace o podnikateli (fyzická nebo právnická osoba), předmět podnikání, druh živnosti, provozovnu, informace o živnostenském oprávnění a další. Insolvenční rejstřík je veřejný seznam, do kterého se zapisují informace o fyzických a právnických osobách, které procházejí insolvenčním řízením. Vede ho opět příslušný rejstříkový soud. Registr ARES sdružuje celou řadu informací poskytovaných veřejnou správou o jednotlivých ekonomických subjektech. Jeho zajímavostí je poskytované XML8 rozhraní, snadno dostupné pro systémové řešení (i systém sám může snadno získat informace, které potřebuje). InfoSoud je portálem ministerstva spravedlnosti, kde lze nalézt informace o průběhu běžících i skončených soudních řízení. 3.2.1.6
Auditor
Automatizovaný auditor společností a osob – po zadání názvu nebo jména, případně dalších upřesňujících údajů, systém shromáždí informace o daném subjektu ze všech dostupných zdrojů. Mezi zdroje patří výše uvedené veřejné portály a interní audity nebo dokumenty spojené s danou osobou nebo firmou. Cílem je, aby pracovník v kanceláři mohl velmi rychle provést základní analýzu vyhledaného subjektu. Není subjekt v exekuci? Kdo jsou jeho vlastníci? Pokročilé analýzy firem mohou dál vytvářet zaměstnanci kanceláře (koncipienti nebo například studenti). Systémové řešení základní analýzy subjektů by představovalo významné snížení nákladů na pracovníky, kteří se musí dnes zabývat těmito jednoduchými činnostmi. 8
XML neboli Extensible Markup Language je univerzální komunikační jazyk používaný pro komunikaci systémů. Jako soubor formátu pdf otevře každý uživatel stejně, tak informaci formátovanou jako XML může každý systém snadno zpracovat.
45
3. Obecná architektura systému Jednotné rozhraní Partner Často Advokát Často Koncipient Často Student Často Asistent Zřídka
Případy Zřídka Často Zřídka Nikdy Zřídka
Dokumenty Konflikt zájmů Často Často Často Často Často Nikdy Zřídka Nikdy Zřídka Nikdy
Auditor Často Často Nikdy Nikdy Nikdy
Tabulka 3.1: Přehled míry využití jednotlivých funkčních bloků. V dnešní době také existuje celá řada zdrojů, které nejsou oficiálním zdrojem informací jako rejstřík ARES, ale data z nich jsou rozhodně zajímavá. Sociální sítě (Facebook, Twitter nebo LinkedIn) a internetové zpravodajské servery (idnes.cz, novinky.cz) obsahují velké množství nestrukturovaných informací o celé řadě subjektů. Prozkoumám i možnost zapojit do analýzy tyto zdroje, protože by bylo by zajímavé, kdyby advokát kromě informací z rejstříků dostal k dispozici také relevantní články o dané společnosti. Výsledné funkční bloky požadované advokáty: • jednotné rozhraní • podpora vybraných typů případu • integrovaná správa dokumentů • systém analýzy konfliktu zájmů • automatizovaný auditor Z přehledu vyplývá význam jednotlivých komponent systému pro kancelář. Jednotné rozhraní využijí všichni, automatizovaný auditor je spíše specialita pro výše postavené zaměstnance. Na druhou stranu právě analýza konfliktu zájmů a automatizovaný auditor tvoří přidanou hodnotu, která se zatím u žádného z konzultovaných advokátů v produkci nenachází.
3.2.2
Doplňkové funkce systému
Tyto požadavky zachycují některé funkce,se kterými jsem se setkal během konzultací, ale nejsou pro fungování systému nutné. Dobře se pro ně hodí anglický výraz „nice to have“. Jejich přehled uveden v tabulce 3.2 jako inspirace pro případné komerční řešení systému, kde mohou být benefitem, 46
3.3. Návrh architektury pro některé kanceláře. Někteří uživatelé mohou mít na systém specifické požadavky, které nejsou součástí základních požadavků, jejich uspokojení však může u dané skupiny zvýšit atraktivitu systému.
Požadavek Náhled na vytížení a výsledky advokátů (statistika). Propojení se systémem ASPI Napojení fakturace přímo na odpracované hodiny Kontrola lhůt – potřebná, ale spíše u sporních řízení Napojení na datové schránky E-mail jako součást jednotného rozhraní Vykazování odpracovaných hodin na případech (docházkový systém)
Uživatelé Partneři Advokáti a koncipienti Finanční útvar Asistenti Advokáti a asistenti Všichni uživatelé Všichni uživatelé
Tabulka 3.2: Seznam dalších požadavků, které mohou být benefitem.
3.3
Návrh architektury
Tato kapitola si klade za úkol odpovědět na požadavky definované v kapitole 3.2. Cílem je definovat, jak informační technologie tyto problémy řeší a vypracovat architekturu systému. Postupuji podle doporučení Mullera [37], pracuji se třemi pohledy – Application, Functional a Conceptual. Tedy jak bude systém splňovat požadavky zákazníka, co to znamená pro tvůrce produktu a jak by měl být produkt koncipován. Každá kancelář může požadovat rozdílnou míru systémové podpory, některé prvky může mít zajištěné vlastní aplikací. Architektura systému by měla být modulární, to znamená, že každý z funkčních požadavků bude řešen specializovanou částí systému. Výhodou řešení je nezávislost, například pokud advokátní kancelář již využívá existující systém na správu dokumentů, nemusí se snažit zavádět nový. V modulární architektuře může stávající řešení zapadnout do celkového rámce. Návrh řešení je zachycen na diagramu 3.1 47
3. Obecná architektura systému
Obrázek 3.1: Obecná architektura řešení
3.3.1
Jednotné uživatelské prostředí - modul portálu
Prvním požadavkem je jednotné uživatelské rozhraní, které budou využívat všichni zaměstnanci kanceláře. To poskytne přístup ke všem aplikacím a systémům, jež advokáti, asistenti nebo koncipienti používají. Tento druh aplikace se nazývá portál, hovoří o něm Gála [25]. Portál definuje následujícím způsobem: "Portál je množina technologií a aplikací tvořící univerzální rozhraní, jehož prostřednictvím je každému, koho se dotýkají činnosti organizace (zákazník, dodavatel, zaměstnanec apod.), umožněno účastnit se procesů organizace, přistupovat ke všem relevantním informacím, komunikovat s ostatními kooperujícími pracovníky a realizovat adekvátní aktivity spojené s podnikovými procesy" 48
3.3. Návrh architektury Je ale nutné umožnit přizpůsobení rozhraní různým pracovním rolím v kanceláři a jejich zaměření. Základ mají portály ve webových portálech zaměřených původně na vyhledávání a dnes již poskytující celou řadu funkcionalit, které uživatel internetu požaduje. Příkladem může být například portál Seznam [40], který kromě vyhledávání přináší: zprávy, předpověď počasí nebo televizní program. Portál v advokátní kanceláři umožňuje jednak přístup ke všem interním aplikacím společnosti, v případě tohoto konkrétního návrhu pak přístup k jednotlivým modulům, dále také k externím zdrojům (například portálu ARES). Portály dnes také patří k základním integračním prostředkům na úrovni přístupu k aplikacím, jak dále uvádí [25].
3.3.2
Modul podpory případů
Systém na podporu řešení jednotlivých případů zatím není mezi advokáty rozšířen. Proces je, dle definice Voříška [45], naplánovaný sled kroků, který transformuje zdroje na požadované výstupy, jenže v oblasti advokacie není zcela snadné převést jednotlivé činnosti na pravidelné procesní mapy. Každý případ sice obsahuje určitou sumu aktivit nebo úkonů, které je nutné provést, avšak přesný postup naplnění těchto aktivit a rozdělení práce mezi jednotlivé role jsou určeny až při řešení případu. Příkladem je založení společnosti s ručením omezeným: vyžaduje se společenská smlouva nebo zakládající listina. Tu mohou sepsat sami zakladatelé nebo ji připraví advokát, který může přenechat formulaci koncipientovi. Přístup se neliší podle kanceláří, ale podle jednotlivých případů a priorit. Řešení tedy musí být flexibilnější než standardní systémy na podporu podnikových procesů. Systém nesmí advokáta v jeho práci zdržovat, případ založení společnosti musí být schopný vyřešit sám ve velmi krátkém čase. Komplikované případy mohou vyžadovat spolupráci několika advokátů po celé měsíce. Podpora procesů by měla obsahovat následující funkce: • Interaktivní seznam úkolů pro každý typ případu, aby advokát viděl, které kroky je třeba provést. • Efektivní práci s dokumenty v rámci případu (připojení dokumentu k případu, prohlížení dokumentů, anotace) • Historii případu, tedy přehled již vykonaných aktivit • Flexibilní přidávání úkolů řešitelem, advokát může v rámci řešení případu požádat o spolupráci například koncipienta. 49
3. Obecná architektura systému
3.3.3
Modul správy dokumentů
Dokumenty tvoří základ práce v advokátní kanceláři, pracují s nimi všichni – advokáti, partneři, koncipienti, asistenti i studenti. Dnes jsou již běžným prostředkem pro řešení správy dokumentů specializované DMS systémy. DMS znamená Document management systém, neboli systém na správu dokumentů. O správě dokumentů hovoří Gála [25]: "Správa dokumentů a obsahu zahrnuje komplex nástrojů a přístupů umožňujících vhodně zachytit množinu nestrukturovaných a semistrukturovaných dat a dle potřeby ji nabídnout v požadované formě uživateli." Definice i obrázek 3.2 hovoří nejen o dokumentech ale i o jejich obsahu, protože společnost pracuje s více zdroji informací než jen s dokumenty. Dokument je základní jednotkou dat, evidovanou jako jeden celek. Může jím být text, obrázek nebo například video. Dokument je zapotřebí nejprve do systému vložit, tento proces může probíhat manuálně – například uložením dokumentu z MS Word přímo do DMS systému nebo procesem digitalizace. Digitalizace představuje proces převedení dokumentu do elektronické formy. Začíná obvykle naskenováním a rozpoznáním textu. V úložišti je pak uložen obsah dokumentu a informace, které dokument popisují. Data o datech neboli metadata. Může to být datum vytvoření, autor nebo informace o typu obsahu. Je potřeba správně zvolit úroveň podrobností a množství metadat, která ukládáme, některá lze pořídit automaticky, například zmiňovaný autor dokumentu, jiná ale musí uživatel do systému zadávat ručně, například položky faktury. Náhradou ale může být jiný přístup – analýza nestrukturovaného obsahu 9 . S analýzou je spojeno vyhledávání, pokud advokát bude vyhledávat dokument s konkrétním obsahem. Základní funkce systému lze podle Gály [25] identifikovat takto: • Verzování dokumentů, dokument se obvykle během svého životního cyklu mění a je důležité zachovávat i jednotlivé revize dokumentu. • Definice životního cyklu dokumentu, některé dokumenty je třeba v rámci organizace adekvátně zpracovat, DMS systém by měl tyto jednoduché procesy podporovat. 9
Disciplína, která se zabývá získáváním informací, které jsou obsaženy v textu dokumentů
50
3.3. Návrh architektury
Obrázek 3.2: Obsah správy dokumentů a obsahu podle [25] Uprostřed jsou vlastnosti společné DMS i správě obsahu, na stranách pak vlastnosti specifické pro dané řešení.
• Podpora vyhledávání, jednak podle atributů (metadat), zároveň podle obsahu (full-textové vyhledávání 10 ). • Personalizace, zamezení přehlcení informacemi. Každý uživatel má přístup k dokumentům, které potřebuje • Kastomizace, uživatel se musí s uživatelským rozhraním ztotožnit, mít možnost vytvářet si vlastní záložky nebo adresáře podle potřeby. 10
Na podobné principu fungují například webové vyhledávače - naleznou stránky, které obsahují hledané výrazy a seřadí je dle vlastního hodnocení kvality.
51
3. Obecná architektura systému
3.3.4
Analýza konfliktu zájmů
Všechny konzultované kanceláře již používaly nějakou verzi databáze klientů, je to nutný předpoklad fungování kanceláře. Řešení by ale mělo jít dál, pokud chce skutečně kvalitně podporovat procesy, které v advokátní kanceláři probíhají, důležité je sledovat vazby mezi klienty a dalšími subjekty, především kvůli riziku střetu zájmů. Neexistuje přesná hranice, kdy již jde o střet zájmů. Server Businessinfo [9] k tomu uvádí: "Advokát je povinen odmítnout poskytnutí právní služby, jestliže: 1. v téže věci nebo ve věci související již poskytl právní služby jinému, jehož zájmy jsou v rozporu se zájmy toho, kdo o poskytnutí právních služeb žádá, 2. osobě, jejíž zájmy jsou v rozporu se zájmy toho, kdo o právní služby žádá, poskytl již v téže věci nebo věci související právní služby advokát, s nímž vykonává advokacii ve společné advokátní kanceláři, nebo v případě zaměstnaného advokáta advokát, který je jeho zaměstnavatelem, anebo advokát, který je zaměstnancem stejného zaměstnavatele, 3. by informace, kterou má o jiném klientovi nebo o bývalém klientovi, mohla toho, kdo o poskytnutí právních služeb žádá, neoprávněně zvýhodnit, 4. projednání věci se zúčastnil advokát, případně osoba advokátovi blízká, 5. zájmy toho, kdo o poskytnutí právních služeb žádá, jsou v rozporu se zájmy advokáta nebo osoby advokátovi blízké." Advokát sám musí rozhodnout, zda hrozí porušení některého z pravidel. Soud případný problém přezkoumává až v případě námitky protistrany. Je tedy důležité mít kvalitní podklady pro rozhodnutí předem – zde se nabízí možnost pro kvalitní analytický nástroj, který dokáže obsáhnout vazby mezi klienty, případně i zkontrolovat veřejně dostupné rejstříky kvůli dalším návaznostem. Například zda jeden z bývalých klientů není přes majetkové poměry napojen na protistranu nového sporu, jak naznačuje diagram 3.3. 52
3.3. Návrh architektury
Obrázek 3.3: Příklad konfliktu zájmů Advokát do systému zadá protistranu nového případu a systém analyzuje veškeré dokumenty kanceláře, případně databáze na údaje o tomto subjektu. Odhalí tak, zda subjekt byl kanceláří zastupován nebo se objevil jako účastník, byť vedlejší, v některém z případů. Zjistí jeho vazby pomocí informací z rejstříku ARES, pomocí XML služeb a zkontroluje i napojení návazných subjektů na kancelář. Výstup analýzy pak advokát může sledovat přímo v systému
3.3.5
Modul veřejných zdrojů
Systém by měl umožnit advokátům snadno a jednoduše získat zdroje, které při práci běžně používají. Jedná se systémy uvedené v 3.2.1.5 Přístup k integrování jednotlivých systémů je možné řešit dvěma způsoby – jednodušší řešení znamená zahrnutí přístupu k těmto zdrojům do aplikace portálu. Advokát má v rámci svého přirozeného prostředí záložku, ikonu nebo odkaz, který uvnitř portálového okna otevře externí rozhraní webového portálu některé ze služeb. Systém ARES umožňuje dotazy na systém odesílat pomocí webových služeb – integračního prostředku na úrovni aplikace, bez nutnosti uživatel53
3. Obecná architektura systému ského zásahu. Systém ARES, zahrnuje informace z Obchodního rejstříku, Živnostenského rejstříku i Insolvenčního rejstříku. Portál infoSoud tímto způsobem přístupný není. Podle mého názoru je vhodné zvolit hybridní přístup – advokátům umožnit otevření jednotlivých zdrojů uvnitř portálové aplikace, aby mohli pracovat s rozhraním, na které jsou zvyklí. Zároveň by systém měl být schopný komunikovat s registrem ARES, pro funkci dalších komponent je to důležité. Jedná se o modul Konflikt zájmů, který díky datům z ARES může vyhledávat další vazby mezi subjekty a modul Auditor, který je přímo určen na automatizovaný sběr dostupných údajů o subjektu.
3.3.6
Modul auditor
Modul auditor dosud není v praxi využíván.Tento modul by měl na systémové úrovni procházet předem definované hodnověrné zdroje informací (registr ARES, renomované informační portály nebo sociální sítě). Data jsou analyzována a prohledána, zda neobsahují údaje o daném subjektu. Výstupem je celá řada údajů a informací o subjektu advokátova zájmu. Zdroje informací • Registr ARES • Webové informační portály (idnes, ihned,) • Sociální sítě (facebook, twitter a další.) • Interní dokumenty kanceláře Konkrétní výběr zdrojů záleží na každé advokátní kanceláři, podle jejího zaměření a uvážení. Dobře navržený systém analýzy obsahu, jak ho popisuje 3.3.7, ale dokáže víc než jen shromáždit informace. Aplikace, které dnes nabízejí společnosti na špičce ECM oboru (IBM, Microsoft a další podle [24]) jsou schopné data převést na konkrétní informace.
3.3.7
Analýza obsahu
neboli Content Analytics. Tento moderní fenomén je spojen se třemi moduly architektury a zaslouží si zvláštní pozornost. Definici tohoto pojmu přináši Gartner [23]: 54
3.4. Závěr obecné architektury "Content analytics defines a family of technologies that processes content and the behavior of users in consuming content to derive answers to specific questions. Content types include text of all kinds, such as documents, blogs, news sites, customer conversations (both audio and text), and social network discussions." Jedná se o nástroje schopné analyzovat obrovské množství informací z různých zdrojů a převést tato data na výsledky, které rozhodujícím způsobem mohou pomoci organizaci. Analýza zahrnuje textové i jiné dokumenty, webové stránky, blogy, přepisy komunikace se zákazníky nebo data ze sociálních sítí. Moduly Konflikt zájmů, Auditor a Veřejné zdroje souvisí s tímto tématem, proto by případná implementace měla podobnou funkcionalitu dodat. Síla těchto modulů závisí především na kvalitní analýze obsahu.
3.4
Závěr obecné architektury
Vytvořil jsem návrh řešení, které vychází z provedené analýzy. Definoval jsem požadavky, které jsou na řešení kladeny a navrhl, jak by mohlo vypadat systémové řešení. Obecnou architekturu může využít kterýkoliv dodavatel, který bude schopen splnit všechny požadavky. Zadáním mojí práce je ověřit, zda se pro tento úkol hodí technologie IBM, především pak Advanced Case Management, tím se zabývám v další části své práce.
55
Kapitola
Architektura IBM řešení Jedním z cílů mé práce je navržení systému, který bude využívat technologie IBM. Tato část práce převádí obecný model systému na aplikace IBM, zaměřené na správu podnikového obsahu (Enterprise Content Management = ECM). Cílem je doplnit architektonický rámec o návrh konkrétní realizace. Výsledkem bude struktura řešení pomocí technologií IBM. Skutečné produkční systémy vytváří celé týmy odborníků jak z řad byznysu, tak analytiků a programátorů. Chtěl bych ukázat, že v této oblasti existuje velký potenciál pro zapojení IBM. Návrh architektonického rámce počítá s modularitou, která není pro produkty IBM cizí. Tak, jak jsou moduly popsány v architektonickém rámci, budu je postupně převádět na systémy IBM. Celé řešení tak, jak je navrženo, lze v rámci produktů nabízených IBM zahrnout do oblasti správy podnikového obsahu (ECM). Tato skupina produktů obsahuje nástroje na správu dokumentů, jejich analýzu i pokročilou spolupráci. Více o ECM konceptu lze nalézt na internetových stránkách společnosti IBM [31]. Hlavním cílem ECM je jednotný přístup k informacím, které má společnost k dispozici, může se jednat o databáze nebo dokumenty všech možných typů. Díky ECM řešením má společnost obsah zcela pod kontrolou. Součástí mé práce je příprava ukázkového řešení, v němž chci ukázat základní funkce řešení a podpořit tak teoretický návrh praktickou ukázkou. Základ celé architektury je zachycen na obrázku 4.1 57
4
4. Architektura IBM řešení
Obrázek 4.1: Architektura řešení pomocí systémů IBM
4.1
Portál
IBM nabízí plnohodnotné portálové řešení prostřednictvím produktů IBM WebSphere Portal [33], pro naše použití je toto řešení zbytečně komplikované, prakticky veškerá práce uživatele je spojena s dokumenty. Za ideální považuji nástroj IBM Content Navigator [30]. Jedná se o uživatelské rozhraní používané pro přístup k IBM ECM systémům. Jeho hlavní výhodou je uživatelská přívětivost a velmi snadná rozšiřitelnost. Je možné ho standardně použít i pro přístup do systémů třetích stran. To podporuje požadavek na flexibilitu řešení v případech, kdy advokátní kancelář již využívá stávající systém, například pro správu dokumentů. Portál je podle mé analýzy jedním ze základních kamenů celého řešení, IBM Content Navigator bude součástí ukázkového řešení. 58
4.2. Podpora případů
4.2
Podpora případů
Aplikace, která bude podporovat advokáty při řešení jednotlivých případů, umožní sledovat průběh případu, delegovat úkoly, připojovat dokumenty spojené s případem. Zároveň nesmí advokáta zdržovat v práci. IBM vyvinula právě za tímto účelem svoji platformu IBM Advanced Case Management (dále ACM), aplikace IBM pro tuto platformu je IBM Case Manager (dále ICM). ICM slučuje celou řadu již existujících systémů pro analýzu, týmovou spolupráci a práci s dokumenty. IBM se snaží s platformou ACM zavést nový trend v řešení složitých případů, na které nestačí tradiční modelování procesů (Business process management neboli BPM). Celé řešení je založeno na modelu případu neboli Case. V práci se zmiňuji o dvou typech případů, advokátní případy označuji nadále: „případ“, případy v pojetí produktu ICM označuji anglickým výrazem: „Case“. Každý Case představuje incident nebo problém, který je potřeba vyřešit. Systém se specializuje na řešení podvodů v bankovnictví, podporu pojišťoven nebo zlepšení postupů ve zdravotnictví. Advokacie je další podobnou komplikovanou oblastí, případy, které advokáti řeší (například Založení společnosti s ručením omezeným nebo podání návrhu na ochrannou známku), přesně odpovídají modelu Case. Systém funguje tak, že pro každý případ, který je nutné vyřešit, je vytvořen nový Case a je mu přidělen řešitel, který je zodpovědný za jeho vyřešení. Řešitel má možnost využívat celou řadu nástrojů, které platforma obsahuje, aby dospěl k řešení. Může spouštět nepovinné úkoly dle vlastní rozvahy, komunikovat s dalšími pracovníky nebo naopak celý případ vyřešit sám. ICM představuje velice flexibilní nástroj, který umožňuje připravit takovou míru automatizace, která vyhovuje danému využití, velkou míru zodpovědnosti za způsob průběhu konkrétního případu je pak možné ponechat na řešiteli. Nevýhodou nástroje ICM je vlastní uživatelské rozhraní, v současné době není standardně používán nástroj IBM Content Navigator, což je požadavkem mého portálového přístupu. Na řešení ICM se v IBM specializuji, proto jádrem mé ukázky bude modul podpory případů implementovaný v produktu ICM. Dalším cílem, který bych rád splnil je integrace uživatelského rozhraní ICM do produktu IBM Content Navigator, aby zůstal zachován portálový přístup. 59
4. Architektura IBM řešení
4.3
Správa dokumentů
IBM nabízí jeden z nejpokročilejších DMS systémů – IBM Filenet P8. [32] Tento systém obsahuje veškerou požadovanou funkčnost, tak jak byla popsána v obecné architektuře u modulu správy dokumentů 3.2.1.3. Cílem práce není přesvědčit čtenáře o nadřazenosti produktu IBM Filenet P8, dle specifikací však plně odpovídá požadavkům, které jsou na DMS systémy dnes kladeny. Licence na IBM Filenet P8 je součástí produktu ICM, je pravděpodobné, že pokud se kancelář rozhodne využívat modul podpory případů, využije i DMS systém IBM. IBM Filenet je schopen spolupracovat s dalšími systémy DMS, například MS Sharepoint. IBM vedle správy dokumentů nabízí také možnost návrhu workflow orientovaných na dokumenty pomocí nástroje IBM Case Foundation (CF). Tam, kde ICM představuje zbytečně složitý nástroj (již zmíněné generování faktury nebo schvalovací procesy) je CF ideální alternativou. Správa dokumentů i nástroj CF jsou standardně plně integrovány s rozhraním IBM Content Navigator. Platforma IBM Filenet tvoří základ pro nástroj ICM, v ukázkovém řešení je tedy zahrnuta.
4.4
Veřejně dostupné zdroje
Napojení na systémy veřejné správy (ARES, Obchodní rejstřík, Živnostenský rejstřík, viz 3.2.1.5) jsem v architektuře řešil dvěma způsoby. První představuje odkaz v portálu na originální rozhraní. Druhý je přístup na systémové úrovni, bez účasti uživatele, za účelem přípravy analýz pro moduly Auditor a Správa klientů. Oba moduly lze v řešení IBM zajistit aplikací IBM Content Analytics (ICA). Tento nástroj (bývá součástí komplexních řešení ICM) představuje celý samostatný systém, který by v architektuře zastal funkci dvou modulů – konflikt zájmů a auditor. Já se u jednotlivých modulů soustředím na způsob, jakým ICA přistupuje k řešení daného požadavku. Podrobný návrh řešení v tomto nástroji není součástí mé práce a v ukázkovém řešení nebudou tyto moduly zastoupeny. Jedná se o koncept, který překračuje možnosti mé diplomové práce. Moduly Správa klientů a Auditor potřebují k fungování automaticky shromažďovat informace z různých zdrojů (internetové stránky, webové služby, dokumenty a další). ICA obsahuje nástroj nazývaný „crawler“, který prochází předem dané zdroje informací a připravuje tak zdroje pro analýzu. Síla každého řešení v aplikaci ICA závisí do značné míry na kvalitně navrženém crawleru, který pro analýzu připraví dostatečné podklady. 60
4.5. Konflikt zájmů
4.5
Konflikt zájmů
Advokátní kanceláře zpravidla mají svoji databázi klientů. Ta může být zajištěna v rámci aplikace správy vztahů se zákazníky (Customer relationship management = CRM) nebo je možné záznamy o klientech ukládat jako dokumenty, kdy každý klient má svůj dokument nebo složku, která funguje jako karta v kartotéce. Také lze vytvořit základní tabulku v databázi. Modul Konflikt zájmů hledá případná rizika při zastupování nových klientů. K tomuto účelu se hodí aplikace IBM Content Analytics (ICA). Jedná se o nástroj na analýzu nestrukturovaného i strukturovaného obsahu, více o této problematice jsem se již zmínil v rámci představení obecné architektury 3.3.7. Základem řešení je opět crawler popsaný v modulu Napojení na veřejně dostupné zdroje. Data jsou však podrobena jiné analýze. Aplikace vyhledává v dokumentech shodu u vybraných údajů – například: jména, IČ společností apod. Výhodou je schopnost analyzovat tímto způsobem nestrukturované dokumenty, například ICA dokáže najít v textu smlouvy, koho se týká. Aplikace dokáže porozumět obsahu textu, pochopí celé věty a pozná tak, zda je uvedené jméno důležité nebo ne (pozná například rozdíl mezi větami: „Jednatelem je pan Jan Novák“ a „Podepsán notář – Jan Novák“. Nástroj umí také komunikovat přes webové služby, může se tak spojit s registrem ARES a zjistit další výrazy, které by měl vyhledat. Příklad jak ICA funguje je znázorněn na obrázku 4.2: "Nový klient A chce zastupovat ve sporu se společností B. Advokát spustí modul Správa klientů a požádá o kontrolu společnosti B s ohledem na riziko konfliktu zájmů. ICA pak pomocí webové služby spustí dotaz v obchodním rejstříku s dotazem na společnost B, pak provede vyhledávání nad dokumenty, které shromáždil crawler. Výsledkem může být zjištění, že advokátní kancelář připravuje majetková přiznání pro majitele společnosti navázané na B a advokát musí zvážit, zda nehrozí riziku konfliktu zájmů." Protože nemám zatím praktickou zkušenost s nástrojem ICA, rozhodl jsem se tuto funkcionalitu do své ukázky nezahrnout. Je běžnou praxí, že při demonstraci řešení je prezentována pouze základní funkcionalita, pokročilé prvky, které jsou náročné na implementaci, jsou dodány až v případě nasazení řešení.
4.6
Auditor
Cílem tohoto modulu je automaticky shromažďovat informace o ekonomických subjektech tak, aby advokát rychle získal přehled o společnosti, po61
4. Architektura IBM řešení
Obrázek 4.2: Sekvenční diagram kontroly konfliktu zájmů.
tenciálním klientovi nebo protistraně. Hlavní výhodu představují ušetřené náklady, které doposud kancelář musela vynakládat na koncipienty, kteří shromažďovali informace o subjektech ručně. Řešením je aplikace IBM Content Analytics (ICA). Se správně navrženým crawlerem, popsaným u modulu Konflikt Zájmů 4.5, vznikne základna informací, kterou může později ICA prohledat a nalézt všechny relevantní informace spojené s předmětem hledání. V praxi například crawler během noci prochází webové portály, sociální sítě a další a vytváří si základ pro pozdější audity. Jakmile advokát zjistí, že potřebuje urychleně informace o konkrétní společnosti, spustí se analýza. Výstupem jsou všechny interní dokumenty, kde je zmíněná hledaná společnost, zároveň 62
4.6. Auditor názor na společnost publikovaný na sociálních sítích. Přidány jsou aktuální informace z veřejných zdrojů 4.4, které pochopitelně nejsou všechny procházeny crawlerem denně, ale jsou dotázány jen dle potřeby. Modul auditor je znázorněn na obrázku 4.3
Obrázek 4.3: Popis modulu Auditor.
63
Kapitola
Ukázkové řešení pro advokátní kanceláře Nejlepším způsobem představení navrhovaného řešení je ukázka aplikací již upravených na míru potenciálnímu klientovi. Technologie IBM jako je IBM Case Manager 11 (dále ICM). představují platformy, na jejichž základě lze vytvořit řešení pro konkrétní oblast, například advokacii. Tímto se odlišují od jednodušších aplikací, které stačí zakoupit a nainstalovat. Aplikace IBM je sice potřeba nejdříve upravit pro konkrétní implementaci, vynahrazují to však velmi vysokou mírou flexibility. Pokud má společnost specifické požadavky, je velmi pravděpodobné, že systém IBM bude možné upravit, aby je splnil. Jedním z cílů mé práce je vypracovat možné řešení v nástroji ICM, budu se tedy ve své ukázce zaměřovat především na tento nástroj a s ním spojený modulem Podpory případů. Velice důležitou součást tvoří také portál - jednotné uživatelské rozhraní a správa dokumentů.Všechny tyto prvky budou v ukázce pro advokáty zahrnuty.
5.0.1
Agilní metodika vývoje
Postup vývoje řešení pro ICM podrobně popisuje Redbook IBM [27]. Dokumenty Redbook, které jsou veřejně dostupné, představují jeden z nejlepších zdrojů, pokud jde o pochopení a využití IBM Softwaru. Dalším zdrojem je dokumentace, dostupná z [29]. V [27] je jako doporučený přístup k návrhu uveden agilní vývoj. Termín agilní vývoj jsem znal z předmětů, které jsem během studia absolvoval a rozhodl se zjistit o tomto způsobu vývoje více. Vyšel jsem 11
IBM používá výraz Advanced Case Management pro popis celé oblasti, systém samotný se nazývá IBM Case Manager.
65
5
5. Ukázkové řešení pro advokátní kanceláře z publikace [41] The Art of Agile Development, která vysvětluje principy agilních metodik. Zaměřil jsem se na principy, které mohu využít. Kniha mě dovedla k dokumentu Manifest Agilního vývoje software [5], který uvádím v tabulce 5.1, protože dobře vystihuje agilní přístup. Manifest Agilního vývoje software Jednotlivci a interakce před procesy a nástroji Fungující software před vyčerpávající dokumentací Spolupráce se zákazníkem před vyjednáváním o smlouvě Reagování na změny před dodržováním plánu Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick c
2001, výše zmínění autoři Toto prohlášení může být volně kopírováno v jakékoli formě, ale pouze v plném rozsahu včetně této poznámky. Tabulka 5.1: Manifest agilního vývoje software [5] Během práce na ukázkové implementaci se budu těmito principy řídit. Abych zapojil do návrhu zákazníky a interakci, jak manifest doporučuje, zařadím do své práce další konzultace s advokáty, kterým ukážu již připravené ukázkové řešení. Podle zpětné vazby pak navrhnu úpravy řešení.
5.0.2
Struktura řešení v IBM Case Manager systému
Funkce modulu Podpory případů jsem vysvětlil v 4.2. Zaměřím se nyní na podrobnější popis struktury řešení ICM, z níž vychází návrh celého řešení. Struktura vychází z dokumentu Redbook [27]. Pokročilé funkce a podrobnosti jsou popsány v dokumentaci [29]. Pro termíny, přímo spojené s aplikacemi IBM budu používat anglické termíny, odliším tak obecné a specifické výrazy. Řešení se v nástroji ICM nazývá Solution, každé Solution může odpovídat na řadu scénářů. Záleží na velikosti společnosti a rozsahu požadavků, zda se rozhodne veškerou funkcionalitu shromáždit v jednom Solution nebo 66
jí rozdělí do více nezávislých. Názorně je struktura Solution představena na diagramu 5.1.
Obrázek 5.1: Struktura Case Solution v nástroji IBM Case manager podle [27]
Každé Solution obsahuje dle [27] pět hlavních stavebních prvků: • Properties • Roles • In-baskets 67
5. Ukázkové řešení pro advokátní kanceláře • Document types • Case types Properties neboli vlastnosti jsou informace uložené v rámci případu, které slouží k jeho vyřešení. Může to být adresa zákazníka, velikost půjčky, cokoliv je nutné znát ke zdárnému vyřešení případu. Roles neboli role sdružují uživatele se stejnými cíli v rámci ICM, například „Obchodní zástupce“. Uživatelé, kteří jsou členy role, pracují s nástrojem ICM stejným způsobem (mají přístup ke stejné funkcionalitě přes stejné uživatelské rozhraní). Záleží na návrhu řešení, zda jsou později konkrétní úkoly přiřazovány pouze roli (každý člen může úkol splnit) nebo konkrétním uživatelům. In-baskets tvoří schránky, ve kterých se hromadí nesplněná práce, pro jednotlivé role (roles in-baskets) nebo pro konkrétní uživatele (personal inbasktes). Princip je velice jednoduchý, pokud má být dokončena konkrétní činnost, musí se o ní dozvědět ten kdo ji má za úkol zpracovat a k tomu slouží jeho in-basket. Document types Zde narážíme na spolupráci nástroje ICM s aplikací IBM Filenet P8 ve zkratce FN (DMS řešení, na kterém je ICM založeno). FN přiřazuje ukládaným dokumentům jednotlivé třídy, které dokument identifikují. Všechny pracovní smlouvy mohou mít třídu smlouva pracovní. S dokumentem je pak nakládáno právě podle třídy, která je mu přidělena, navíc jsou podle třídy k dokumentu přiřazena metadata (informace o dokumentu). Například může být u každé třídy „smlouva pracovní“ uveden údaj „výše odměny“, dokumenty pak lze lépe třídit, vyhledávat nebo s nimi dále pracovat. Document types v ICM jsou pouze přenesením této funkcionality do nástroje ICM. Pokud v rámci případu pracujeme s dokumentem, u kterého je potřeba uchovávat nějaká metadata, vytvoříme pro dokument jeho vlastní Document type. Case type jsou typy případů, představují nižší strukturální jednotku než je Solution. Solution může obsahovat celou řadu Case type. Case type je konkrétní typ problému, který má nástroj ICM řešit, může to být založení s.r.o. nebo likvidace pojistné události, podle oblasti, pro kterou je Solution připraveno, vztahy jsou ukázány na obrázku 5.1. 68
Každý Case type obsahuje: • Properties • Views • Case folders • Tasks Case type - Properties jsou podmnožinou dříve definovaných Properties v rámci celého Solution. Názorně to ukazuje 5.1. Case type - Views popisují způsob, jak budou Properties pro uživatele zobrazeny, například v základním přehledu jsou potřeba pouze ty nejdůležitější, v podrobnostech pak všechny. Je také možné Properties seskupovat a připravit tak pro uživatele přehlednější prostředí. Case type - Folders tvoří připravenou strukturu, do které je možné později vkládat dokumenty, pokud například u každého Case pracují řešitelé s e-mailovou komunikací, která je do Case vkládána automaticky, pomůže přehlednosti, když jsou emaily sdružené ve složce komunikace se zákazníkem a uživatel ví, kde tyto dokumenty hledat. Case type - Tasks jsou nejdůležitějšími prvky Case type, jsou to jednotlivé úlohy, které dohromady tvoří páteř průběhu každého Case. Task je úkol, který je přiřazen podle návrhu roli nebo konkrétnímu uživateli, každý Case type obsahuje nejméně jeden Task, který je nutné splnit. Některé tasks jsou povinné, jiné jsou iniciovány řešitelem pouze pokud je to nutné. Další jsou vytvářeny manuálně až za běhu případu, protože při návrhu řešení nebylo známo, že se potřeba podobné činnosti vyskytne takové Tasks jsou nazývány „ad-hoc“. Prostředí ICM umožňuje širší spektrum možností a nástrojů, pro základní přehled však výše uvedené stačí. Při návrhu řešení není efektivní postupovat přesně tak, jak je definována struktura celého Solution. Je výhodnější nejdříve definovat jednotlivé Case type, zjistit jaké Properties, roles a document types bude potřeba vytvořit. Při návrhu přímo vycházím z analýzy jednotlivých případů. 69
5. Ukázkové řešení pro advokátní kanceláře
5.1 5.1.1
Hlavní funkce ukázkového řešení Integrace ICM v prostředí IBM Content Navigator
Jedním z hlavních požadavků na celkové řešení je portál – jednotné uživatelské rozhraní. Ve svém návrhu počítám s aplikací IBM Content Navigator (ICN) jako s portálem, ale v současné době není podporována přímá integrace ICM a ICN. Navrhl jsem tedy v IBM řešení, které jsem společně s programátorem, který měl více zkušeností s vývojem pro ICN, uvedl do praxe. ICN aplikace je relativně snadno rozšiřitelná pomocí plug-in modulů. Navrhl jsem plug-in modul, který zobrazí uvnitř aplikace ICN libovolnou webovou stránku, jedná se o relativně snadné řešení, které nevyžadovalo delší vývoj. Technické podrobnosti vývoje plug-in modulů lze nalézt v [28]. Aplikace ICM standardně jako uživatelské rozhraní používá právě webovou stránku. Pro moji ukázkovou integraci, která si klade za cíl ukázat jednoduchost práce v nástroji ICN s přidanou hodnotou aplikace ICM stačí zobrazit celé řešení ICM jako externí webovou stránku uvnitř portálu ICN. Uživatel žádný rozdíl nepozná a není nutné přecházet mezi dvěma aplikacemi.
5.1.2
Řešení to-do doplňku
Další funkcí je sledování činností, které je třeba dokončit, aby mohl být případ uzavřen. Pro řešení používám nástroj IBM Forms, který umožňuje vytvářet interaktivní formuláře, které lze snadno integrovat do nástroje ICM. Výhodou je snadná úprava těchto formulářů. To je důležité pro celkovou flexibilitu řešení, vytvořit nový „to-do“ formulář dokáže administrátor systému během několika minut.
5.1.3
Ad-hoc a manuální úlohy
Požadavkem na systém je vysoká flexibilita vůči advokátovi, který řeší daný případ. Advokát rozhoduje, které kroky provede sám a které případně deleguje. V nástroji ICM toto řeší manuální a tzv. ad-hoc tasky. V obou případech může advokát přímo ze systému iniciovat provedení potřebné úlohy, aniž by byl nucen přerušit práci na případu (úlohy běží paralelně). Manuální Task je již připraven a stačí jej pouze spustit, u ad-hoc tasku může řešitel definovat sám jak osoby, které jsou za úlohu zodpovědné, tak instrukce k provedení. 70
5.1. Hlavní funkce ukázkového řešení
Obrázek 5.2: Screenshot z aplikace IBM Content navigator s integrovaným ICM. Case manager je zvýrazněn. Panel A - to-do formulář, B - Properties identifikující Case, C - Podrobné informace o Case, dokumenty s Case spojené, historie a panel ovládání tasks
Obrázek 5.3: Screenshot doplňku "to-do", řešeného formulářem
71
5. Ukázkové řešení pro advokátní kanceláře
5.1.4
Integrace MS Office s případy
Většina advokátů používá při práci nástroje MS Office a IBM ECM platforma je připravená na integraci s nimi. Díky aplikaci Filnet Integration for Microsoft Office (FIMO) je možné přistupovat k dokumetům uloženým v DMS systému Filenet přímo z MS Office aplikací. Jednotlivé Case jsou uloženy ve FN jako složky. Pro uživatele to znamená, že může přidávat dokumenty z MS Office aplikací přímo k danému Case a zároveň dokumenty z Case otevírat.
5.2
Vytvořené Case type
Strukturu popisu každého Case type jsem převzal z [27], přidal jsem prvky to-do formuláře a pro přehlednost také jednoduchý diagram Case type. Neexistuje přesná konvence, jak zachytit ICM Case v rámci diagramu, vyšel jsem ze standardů BPM a dbal především na srozumitelnost diagramu, podle "Jednotlivci a interakce před procesy a nástroje"z 5.1, před přesným sledováním konvencí.
5.2.1
Založení společnosti s ručením omezeným
Založení společnosti s ručením omezeným jsem si vybral, protože na něm lze dobře demonstrovat přínos, který chci se svým systémem dosáhnout. Advokát, který uzavře dohodu s klientem, sám iniciuje případ založení společnosti a vytvoří v nástroji ICM nový Case. Iniciátorovi je také přidělen Task založení s.r.o. – hlavní Task celého případu. Jakmile je dokončen, považuje se společnost za založenou a Case za dokončený, je zodpovědností řešitele, který Case založil, aby to tak skutečně bylo. Advokát má k dispozici manuální úkoly pro asistenty, které slouží k odeslání dokumentů na úřady a může vytvářet ad-hoc tasky, kterými deleguje činnost na své kolegy (například vytvoření návrhu přenechá koncipientovi). Využívá to-do formulář, podle kterého kontroluje, zda již proběhly všechny nezbytné úkony. 72
5.2. Vytvořené Case type
Obrázek 5.4: Diagram Case type
To-do formulář pro založení s.r.o. • Zakladatelská listina • Prohlášení správce vkladu • Potvrzení o užívání sídla • Podpisové vzory jednatelů • Výpisy z rejstříku trestů jednatelů • Proveden zápis do obchodního rejstříku • Provedeno přihlášení u FÚ
Tasks Všechny tasks jsou popsány v tabulce 5.2. 73
5. Ukázkové řešení pro advokátní kanceláře Task Založení s.r.o.
Vlastnosti Povinný, Automaticky spouštěný
Odeslání dokumentů
Nepovinný, Manuálně spouštěný
Doplnění dokumentu
Ad-hoc
Příprava dokumentu
Ad-hoc
Popis Hlavní úkol založení s.r.o. je jediný povinný, jeho splnění znamená, že společnost byla založena a případ je dokončen. Úkol pro asistenta, aby odeslal žádost o příslušné podnikatelské oprávnění Úkol pro konkrétního koncipienta nebo asistenta, aby získal od klienta nebo další strany chybějící dokument. Úkol pro koncipienta nebo advokáta, aby připravil návrh dokumentu, například návrhu na zápis do OR.
Tabulka 5.2: Tasks pro Case type Založení společnosti s ručením omezeným
Roles Role uvedeny v tabulce 5.3 Role Advokat (možný iniciátor)
In-basket Advokat
Asistent
Asistent, My work
Pravni koncipient (nedefinovany ucastnik)
Pravni koncipient, My work
Popis Hlavní role pro všechny advokáty v kanceláři Podpůrná role pro asistenty Role pro právní koncipienty
Tabulka 5.3: Roles pro Case type Založení společnosti s ručením omezeným
In-baskets In-baskets pro Case type založení s.r.o. uvedeny v tabulce 5.4 74
5.2. Vytvořené Case type In-basket Advokat
Asistent
Pravni koncipient
My work
Popis Společná složka pro všechny advokáty – informace, případně nepřiřazené případy a úkoly, které může zpracovat kterýkoliv advokát. Společná složka pro asistenty, většina úkolů pro asistenty je shromážděna zde, není důležité, který asistent práci provede (často také nejsou v práci všichni každý den, je efektivnější pracovat s abstraktní skupinou). Společná složka pro koncipienty, také ji lze využít, koncipienti nejsou plnohodnotní zaměstnanci a je dobré mít možnost oslovit všechny volné koncipienty zároveň. Osobní složka každého uživatele – sem je směřována práce, která má již přiděleného pracovníka.
Tabulka 5.4: In-baskets pro Case type Založení společnosti s ručením omezeným
Document types Document types pro Case type založení s.r.o. uvedeny v tabulce 5.5
Document type Dokument k případu
Properties ID Klienta, ID Případu
Popis Dokumenty přidávané k případu mají vlastní třídu, metadata stačí systémová
Tabulka 5.5: Document types pro Case type Založení společnosti s ručením omezeným
Properties Properties pro Case type založení s.r.o. uvedeny v tabulce 5.6 75
5. Ukázkové řešení pro advokátní kanceláře Property ID Klienta ID Případu Adresa navrhovatele Adresa správce vkladu Další účastníci řízení Instrukce IČ navrhovatele Jednatelé Jméno a příjmení navrhovatele Jméno a příjmení správce vkladu Název obchodní firmy Předmět činnosti Rejstříkový soud
Type String (64) String (64) String (1000) String (1000) String[](1000) String(1000) Integer String[](1000) String(100)
Společníci Sídlo společnosti
String[](1000) String(1000)
Popis Identifikace klienta Identifikace případu
String(100) String(200) String[](200) String(200)
Výběr z existujích rejstříkových soudů
Tabulka 5.6: Properties pro Case type Založení společnosti s ručením omezeným. String je řetězec znaků, Integer celé číslo, Boolean je logická proměnná - ANO/NE. Číslo v závorce udává počet přípustných znaků v řetězci. Značka[] znamená, že se jedná o Property, která může obsahovat více hodnot. Document type Dokument k případu
Properties ID Klienta, ID Případu
Popis Dokumenty přidávané k případu mají vlastní třídu, metadata stačí systémová
Tabulka 5.7: Document types pro Case type Likvidace společnosti s ručením omezeným
5.2.2
Likvidace společnosti s ručením omezeným
Zařadil jsem tento případ do svého řešení, abych vytvořil jednotnou ukázku – zabývám se více případy spojenými se společností s ručením omezeným. Postup likvidace je velmi podrobně popsán v rámci popisu případů 2.2.3. Proces likvidace záleží na osobě likvidátora, pokud je jím určen zaměstnanec 76
5.2. Vytvořené Case type
Obrázek 5.5: Diagram Case type likvidace s.r.o. kanceláře, je provedena interně, je ale možné, že společnost se rozhodne pro externího likvidátora nebo jím je jeden z jednatelů společnosti. To-do formulář (pro advokáta) • Rozhodnutí o likvidaci • Jmenování likvidátora • Potvrzení způsobilosti likvidátora • Vstup do likvidace • Provedení likvidace • Výmaz společnosti z OR
To-do formulář (pro likvidátora) • Zpracování mimořádné ÚZ (účetní závěrky) • Kontrola předlužení • Ukončení pracovních poměrů • Pohledávky a závazky • Majetek • Archivace dokumentů • Rozdělení likvidačního zůstatku • Konečná účetní závěrka • Závěrečná zpráva likvidátora
Tasks Všechny tasks pro Case type likvidace společnosti jsou popsány v tabulce 5.8. Roles Role pro Case type Likvidace společnosti s ručením omezeným uvedeny v tabulce 5.9 77
5. Ukázkové řešení pro advokátní kanceláře
Task Likvidace s.r.o.
Vlastnosti Povinný, Automaticky spouštěný
Provedení likvidace Odeslání návrhu na výmaz z OR
Nepovinný, Manuálně spouštěný Nepovinný, Manuálně spouštěný
Příprava účetní závěrky Kontrola předluženosti společnosti Doplnění dokumentu
Nepovinný, Manuálně spouštěný Nepovinný, Manuálně spouštěný Ad-hoc
Příprava dokumentu
Ad-hoc
Popis Hlavní úkol založení s.r.o. je jediný povinný, jeho splnění znamená, že společnost byla založena a případ je dokončen. Úkol pro likvidátora, aby provedl likvidaci Úkol pro asistenta, aby odeslal návrh na zápis společnosti do obchodního rejstříku Úkol pro auditory (interní útvar) Úkol pro auditory (interní útvar) Úkol pro konkrétního koncipienta nebo asistenta, aby získal od klienta nebo další strany chybějící dokument. Úkol pro koncipienta nebo advokáta, aby připravil návrh dokumentu, například návrhu na zápis do OR.
Tabulka 5.8: Tasks pro Case type Likvidace společnosti s ručením omezeným
78
5.2. Vytvořené Case type Role Advokat (možný iniciátor)
In-basket My work
Likvidator
Likvidator, My work
Auditor
Auditor, My Work
Asistent
Asistent, My work
Popis Hlavní role pro všechny advokáty v kanceláři Interní útvar specializující se na likvidace Interní útvar provádějící audity Podpůrná role pro asistenty
Tabulka 5.9: Roles pro Case type Likvidace společnosti s ručením omezeným In-baskets In-baskets pro Case type Likvidace společnosti s ručením omezeným uvedeny v tabulce 5.10 Document types Document types pro Case type Likvidace společnosti s ručením omezeným uvedeny v tabulce 5.11 Properties Properties pro Case type Likvidace společnosti s ručením omezeným uvedeny v tabulce 5.12
79
5. Ukázkové řešení pro advokátní kanceláře
In-basket Likvidator Auditor Asistent
Pravni koncipient
My work
Popis Společná složka pro likvidátory – likvidace se ujímá volný likvidátor Společná složka pro auditory – audit provede volný auditor Společná složka pro asistenty, většina úkolů pro asistenty je shromážděna zde, není důležité, který asistent práci provede (často také nejsou v práci všichni každý den, je efektivnější pracovat s abstraktní skupinou). Společná složka pro koncipienty, také ji lze využít, koncipienti nejsou plnohodnotní zaměstnanci a je dobré mít možnost oslovit všechny volné koncipienty zároveň. Osobní složka každého uživatele – sem je směřována práce, která má již přiděleného pracovníka.
Tabulka 5.10: In-baskets pro Case type Likvidace společnosti s ručením omezeným
Document type Dokument k případu
Properties ID Klienta, ID Případu
Popis Dokumenty přidávané k případu mají vlastní třídu, metadata stačí systémová
Tabulka 5.11: Document types pro Case type Likvidace společnosti s ručením omezeným
80
5.2. Vytvořené Case type
Property ID Klienta ID Případu Instrukce
Type String (64) String (64) String (1000)
Rejstříkový soud
String (250)
Navrhovatel
String (250)
Obchodní firma
String (250)
Adresa sídla
String (250)
IČ
Integer
Spisová značka
String(64)
Text návrhu
String(1000)
Likvidátor
String(250)
Datum zápisu
Date
Popis Identifikace klienta Identifikace případu Specifikace Ad-hoc tasku Výběr ze všech rejstříkových soudů Jméno a příjmení / Obchodní firma a IČ + adresa Název firmy, které se likviduje Údaje o likvidované společnosti Údaje o likvidované společnosti Údaje o likvidované společnosti Petit návrhu na výmaz z OR Jméno a příjmení + Adresa bydliště Datum ke kterému má být zápis provedeni
Tabulka 5.12: Properties pro Case type Likvidace společnosti s ručením omezeným. String je řetězec znaků, Integer celé číslo, Boolean je logická proměnná - ANO/NE. Číslo v závorce udává počet přípustných znaků v řetězci. Značka[] znamená, že se jedná o Property, která může obsahovat více hodnot.
81
5. Ukázkové řešení pro advokátní kanceláře
5.2.3
Přihlášení ochranné známky
Návrh vychází z případu popsaného mezi jednotlivými případy 2.2.10. Případ je relativně jednoduchý, stačí podat na úřadě průmyslového vlastnictví přihlášku se všemi náležitostmi. Stejně jako v předchozích případech bude hlavní roli představovat iniciátor, který do systému založí případ, může to být jeden z advokátů nebo také partner.
Obrázek 5.6: Diagram Case type Přihlášení ochranné známky
To-do formulář pro Case type Přihlášení ochranné známky • Podklady pro návrh (technická vyobrazení, popis) • Podání návrhu • Ochranná známka zaregistrována Tasks Všechny tasks pro Case type Přihlášení ochranné známky jsou popsány v tabulce 5.13. Roles Role pro Case type Přihlášení ochranné známky uvedeny v tabulce 5.14 In-baskets In-baskets pro Case type Přihlášení ochranné známky uvedeny v tabulce 5.15 82
5.2. Vytvořené Case type
Task Přihlášení známky
ochranné
Odeslání dokumentu
Vlastnosti Povinný, Automaticky spouštěný
Doplnění dokumentu
Nepovinný, Manuálně spouštěný Ad-hoc
Příprava dokumentu
Ad-hoc
Popis Hlavní úkol založení s.r.o. je jediný povinný, jeho splnění znamená, že společnost byla založena a případ je dokončen. Úkol pro likvidátora, aby provedl likvidaci Úkol pro konkrétního koncipienta nebo asistenta, aby získal od klienta nebo další strany chybějící dokument. Úkol pro koncipienta nebo advokáta, aby připravil návrh dokumentu, například návrhu na zápis do OR.
Tabulka 5.13: Tasks pro Case type Přihlášení ochranné známky
Role Advokat (možný iniciátor)
In-basket My work
Partner Asistent
Partner, My work Asistent, My work
Právní koncipient (nedefinovaný účastník)
Pravni koncipient, My work
Popis Hlavní role pro všechny advokáty v kanceláři Může být iniciátorem Podpůrná role pro asistenty Role pro právní koncipienty
Tabulka 5.14: Roles pro Case type Přihlášení ochranné známky.
83
5. Ukázkové řešení pro advokátní kanceláře In-basket Asistent
Pravni koncipient
My work
Popis Společná složka pro asistenty, většina úkolů pro asistenty je shromážděna zde, není důležité, který asistent práci provede (často také nejsou v práci všichni každý den, je efektivnější pracovat s abstraktní skupinou). Společná složka pro koncipienty, také ji lze využít, koncipienti nejsou plnohodnotní zaměstnanci a je dobré mít možnost oslovit všechny volné koncipienty zároveň. Osobní složka každého uživatele – sem je směřována práce, která má již přiděleného pracovníka.
Tabulka 5.15: In-baskets pro Case type Přihlášení ochranné známky Document type Dokument k případu
Properties ID Klienta, ID Případu
Popis Dokumenty přidávané k případu mají vlastní třídu, metadata stačí systémová
Tabulka 5.16: Document types pro Case type Likvidace společnosti s ručením omezeným Document types Document types pro Case type Přihlášení ochranné známky uvedeny v tabulce 5.16 Properties Properties pro Case type Přihlášení ochranné známky uvedeny v tabulce 5.17 Property Druh ochranné známky
Provedení
Výběr hodnot slovní/obrazová/kombinovaná/slovní grafická/prostorová/barva nebo kombinace barev barevné/černobílé
Tabulka 5.18: Možnosti výběru pro Properties pro Case type Přihlášení ochranné známky 84
5.3. Testování aplikace Property ID Klienta ID Případu Instrukce
Type String (64) String (64) String (1000)
Ochranná známka v běžném písmu Druh ochranné známky Provedení Kolektivní známka Přihlašovatelé
Boolean
Zástupce přihlašovatele Právo přednosti podle MS Znění ochranné známky Seznam výrobků a služeb
String(1000)
Popis Identifikace klienta Identifikace případu Specifikace Ad-hoc tasku
String (64)
Výběr z5.18
String (64) Boolean String[] (1000)
Výběr z5.18
String(1000)
Jméno, příjmení případně obchodní firma, IČ a adresa Údaje o případném zástupci Přednost podle mezinárodní smlouvy
String(250) String[](250)
Tabulka 5.17: Properties pro Case type Přihlášení ochranné známky. String je řetězec znaků, Integer celé číslo, Boolean je logická proměnná - ANO/NE. Číslo v závorce udává počet přípustných znaků v řetězci. Značka[] znamená, že se jedná o Property, která může obsahovat více hodnot.
5.3
Testování aplikace
Testování svého řešení jsem provedl ve dvou krocích. Prvním bylo vlastní vyzkoušení. Vybral jsem vzorové případy z [26] a [35], týkající se zakládání a likvidace společností. Postupoval jsem podle popsaných případů a zadával do svého systému údaje a prázdné atrapy dokumentů. Ukázalo se, že případy jsou správně implementovány, provedl jsem ještě drobné změny ve struktuře uživatelského rozhraní, aby byla práce snazší. Podrobný popis všech nastavení, která je v systému třeba provést, aby řešení fungovalo podle očekávání přesahuje rozsah této práce. Uvedu příklad, který dobře ilustruje problémy, se kterými jsem se setkal. Při spuštění úkolu pro koncipienta, aby připravil specifický dokument se koncipientovi nezobrazoval to-do formulář. Systém nepočítá s tím, že by 85
5. Ukázkové řešení pro advokátní kanceláře se stejným formulářem (zčásti vyplněným) pracovalo více uživatelů. Musel jsem vytvořit vlastní systémové kroky, které vždy při otevření úkolu koncipientem přiřadili již rozpracovaný to-do formulář a koncipient tak viděl, jaké kroky již proběhly. Nejedná se o vadu systému, řešení je schopné se přizpůsobit podle požadavků, jen je zapotřebí aplikaci správně nakonfigurovat. Jakmile jsem takto otestoval řešení sám, pokračoval jsem druhým krokem v duchu agilních metodik. Principy Manifestu agilního vývoje 5.1, se kterými se plně ztotožňuji, jsou: "Spolupráce se zákazníkem před vyjednáváním o smlouvě"a "Reagování na změny před dodržováním plánu". Nesnažil jsem se navrhnout ideální řešení sám, ale provedl jsem další konzultace s advokáty. Advokáti vyslovovali připomínky nejen k mé aplikaci, ale vyjádřili svůj názor na celý systém. Tato zpětná vazba je zahrnuta do následující kapitoly Vyhodnocení využití ACM v advokacii 6. Video s ukázkou práce v připraveném řešení je součástí přiloženého CD.
86
Kapitola
Vyhodnocení využití ACM v advokacii Při vývoji svého řešení jsem postupoval podle Manifestu agilního vývoje [5] a jedním z nejdůležitějších principů je provázání vývoje se zpětnou vazbou klienta. Nástroj IBM Case manager je pro tento způsob práce přímo navržen, změny celého řešení lze provádět během hodin, minut, dokonce přímo při ukázce zákazníkovi. Tyto výhody řešení se plně projeví při ukázce řešení u advokáta.
6.1
Konzultace se zpětnou vazbou
Oslovil jsem dva advokáty, první byla advokátka se spíše odmítavým postojem k informačním technologiím. Druhým je advokát, který si rozšířil vzdělání o základy informačních technologií.
6.1.1
První konzultace se zpětnou vazbou
Advokátku z britské advokátní kanceláře, se kterou jsem již konzultoval viz 2.1.3, jsem si vybral kvůli jejímu poněkud odmítavému postoji k informačním technologiím. Cílem konzultace bylo zjistit, jak bude advokátka na ukázku řešení reagovat, co jí bude vadit a zda lze některé části zlepšit. Advokátce jsem představil koncept svého řešení jako celek a pak s ní procházel aplikací. Prvním pozitivním poznatkem bylo, že pochopení smyslu a rozložení prvků v systému nebylo velkým problémem. Dobře jsem zvolil ukázkové případy, protože jsem byl schopen na nich ukazovat všechny schopnosti systému. Zároveň si však advokátka dokázala představit využití systému u výrazně složitějších případů, jako je např. fúze společností. 87
6
6. Vyhodnocení využití ACM v advokacii Systém jako celek odpovídal řešení, které kancelář skutečně používá, většina funkcí byla podobná. Soustředím se nyní na jednotlivé funkce, které jsme rozebrali podrobněji, a ke kterým měla advokátka výhrady nebo návrhy na změnu. To-do formulář: tato funkce se advokátce zamlouvala, považovala ji za hlavní výhodu oproti řešení, které nyní používá. Hlavním důvodem je, že celou řadu činností za ní dělají studenti a koncipienti, kteří mohou snáze opomenout některý krok. Rozšířila by formulář o možnost zobrazení doplňujících informací k jednotlivým úkolům a o odkazy na ukázkové dokumenty. Práce na případu: advokátka považovala za nadbytečné zadávat do systému některé podrobnosti k případům. Podle návrhu řešení obsahuje každý Case řadu Properties, které definují případ. Cílem je, aby pracovník, který dostane za úkol zpracovat přidružený dokument, mohl všechny důležité informace o případu získat přímo ze systému. Advokátka namítla, že je jednodušší otevřít daný dokument a informaci nalézt v něm. Ukázal jsem, že moje řešení s tímto počítá, jednotlivé vlastnosti jsou označeny jako nepovinné. Uživatelské prostředí jsem během ukázky upravil, aby odpovídalo její představě. Později jsem řešení upravil tak, aby advokát sám mohl zvolit, zda chce využít možnost zadat údaje do systému nebo budou pouze v dokumentech. Nemyslím, že by bylo vhodné některé z Properties z řešení odebrat, pokud totiž údaj nebude sdělen písemně, ale například telefonicky, může být potřeba ho do systému zadat, protože v žádném dokumentu k nalezení nebude. Automatické generování dokumentů: novým návrhem advokátky byla funkce automatického generování dokumentů, tedy vytvoření například návrhu na zápis do obchodního rejstříku podle parametrů případu. Tato oblast stojí za prozkoumání, ale já jsem ji do svého řešení úmyslně nezahrnul. Generované dokumenty závisí na správnosti šablony, formuláře se rychle mění a bez pravidelné kontroly může dojít k tomu, že šablony zastarají a dojde k chybě. Technicky ale podobné řešení vytvořit lze, například s využitím IBM Forms, které jsou již v řešení zastoupeny to-do formulářem. Moduly auditor a konflikt zájmů: tyto součásti systému nebyly implementovány a mohl jsem pouze představit své návrhy. Obdobu modulu na kontrolu konfliktu zájmů kancelář advokátky již používá (přesto že během původní konzultace nebyla zmíněna). Je to velmi důležitá součást fungování 88
6.2. Úpravy systému velké kanceláře a pro kanceláře, které ji zatím nemají rozhodně zajímavé řešení. Modul auditor byl pro advokátku novým nápadem a zaujal ji, dokázala si představit, že by tak ušetřila část své práce i práce podřízených kolegů.
6.2
Úpravy systému
Před druhou plánovanou konzultací jsem upravil některé prvky, které nevyhovovaly při první konzultaci, podle principů agilního vývoje software [5].
Rozvržení uživatelského rozhraní: dotazovaná advokátka preferovala přístup uchování informací v dokumentech bez převodu do systému, který je nadbytečnou zátěží. Jde o konflikt mezi systémovým přístupem a požadavkem uživatele. Systémový přístup preferuje, soustředit všechny informace o případu do systému, protože jejich rozdělení mezi více dokumentů znamená nejednotnost a nebezpečí chyby. Advokát jako uživatel však nechce údaje v systému, protože je zvyklý mít je v dokumentech. Zde se naplno projevuje síla nástroje IBM Case Manager, který přináší takové řešení, jež vyžaduje zákazník. Do uživatelského rozhraní jsem zakomponoval jak rozhraní pro převod informací z dokumentu do případu 6.2, tak prohlížeč dokumentů, který použije uživatel v případě, že potřebuje informace nalézt přímo v dokumentech 6.2. 89
6. Vyhodnocení využití ACM v advokacii
Obrázek 6.1: Screenshot uživatelského prostředí se zvoleným "Properties"přístupem. Data je nutné zadat přímo do systému, není pak potřeba nahlížet do dokumentů.
Obrázek 6.2: Screenshot uživatelského prostředí s upřednostněním dokumentů. Informace není nutné převést do systému, zůstávají v původních dokumentech, které jsou k příapdu připojeny. Protože dotazovaná advokátka je představitelkou konzervativního přístupu, nemyslím, že by bylo vhodné na její popud odebrat z řešení možnost 90
6.2. Úpravy systému zadat parametry do systému přímo. Budu tuto problematiku zkoumat i při další ukázce řešení jinému advokátovi. To-do formulář: návrhy advokátky na rozšíření mne zaujaly a přidám je do řešení, vytvořím nový formulář pro Založení společnosti s ručením omezeným, který bude obsahovat jak podrobnosti k úkolům, tak odkazy na ukázkové dokumenty 6.2.
Obrázek 6.3: Rozšířený to-do formulář. Obsahuje popisky a vzorové dokumenty dostupné po kliknutí na daný úkol. Po první prezentaci řešení jsem zjistil, že mám mezery ve schopnosti správně advokátovi ukázat konkrétní výhody systému. Kolega v IBM mi doporučil připravit několik „challenges“, neboli výzev, na které systém odpovídá. Jedná se o konkrétní situace, které systém umí vyřešit. Uživateli lze předvést, jak výzvu v systému zvládne. Dále uvádím mnou připravené tři návrhy výzev. Výzva: Stav případu před skončením hovoru Klient zavolá advokátovi a dožaduje se okamžité informace o stavu svého případu. Moje systémové řešení umožní advokátovi, aby stav případu zjistil během okamžiku. Systém obsahuje interaktivní vyhledávání Case podle všech parametrů, například lze najít všechny případy, které má na starosti daný advokát. 91
6. Vyhodnocení využití ACM v advokacii Případ není třeba ani otevírat, aby advokát mohl prohlížet přílohy, procházet historii nebo spouštět úlohy spojené s případem. V rámci ukázkového řešení lze snadno ukázat, jak během práce na založení s.r.o. může advokát bez přerušení práce zjistit stav konkrétního návrhu na ochrannou známku. Výzva: Transfer případu Každý advokát se věnuje celé řadě případů zároveň. Převedení jeho agendy na kolegy (například pokud onemocní) může být velmi obtížný úkol, pokud jsou data o případu rozeseta v DMS systému, na pevném disku advokátova počítače nebo jinde. Ucelený Case, tak jak s ním počítá platforma IBM Case Manager, je možné převést na jiného uživatele během chvilky, a může to udělat jak řešitel sám, tak administrátor. Výzva: Delegace úkolů jedním kliknutím Dnes je zcela běžné, že část práce provádí za advokáta koncipient nebo student. Úkolování probíhá přes email, jenže množství informací k případu je značné a advokát nemá čas přidávat k emailu všechny dokumenty nebo instrukce. Obvykle je na koncipientovi, aby si našel v DMS systému informace, které potřebuje a dokument připravil, jak má být. Tento postup může fungovat, ale hrozí nebezpečí duplicity a chybné práce s dokumenty. Moje řešení tento problém odstraňuje – pokud je delegován nějaký úkol, může být dané osobě zpřístupněn celý Case nebo jeho část. Důležité je, že bude pracovat vždy se správnými dokumenty a zároveň nové dokumenty přidávat na správné místo.
6.3
Zpětná vazba na upravený systém
Druhou konzultaci mi poskytl advokát, rovněž z mezinárodní kanceláře, který má k informačním technologiím bližší vztah. Ukázkové řešení hodnotil velmi pozitivně, líbil se mu koncept uceleného případu, který obsahuje všechny dokumenty, informace i historii k dané kauze. Potvrdil moje stanovisko, že míra informací, kterou je vhodné uchovávat v systému proti uchování v dokumentech, se může lišit podle preferencí kanceláře i jednotlivých advokátů. Celé řešení včetně modulů konfliktu zájmů a auditora považuje za užitečné. Měl k systému několik zajímavých doplnění a připomínek. To-do formulář advokátovi se líbila základní myšlenka, tedy jednoduchý přehled úkonů, které je potřeba udělat. Funkce, které jsem doplnil po poslední konzultaci, doporučil prezentovat pouze jako prostředek, který 92
6.4. Vyhodnocení řešení ve vztahu k existujícím aplikacím si plně přizpůsobí kancelář (právní poradenství totiž může nabízet pouze certifikovaný odborník). Vysvětlil jsem, že moje řešení plně počítá s tímto postupem, kdy teprve konkrétní kancelář řekne, které případy a jak chce podpořit. Cílové kanceláře: podle zmíněného advokáta má navrhovaný systém velkou šanci na úspěch u kanceláří, které řeší větší množství podobných případů. Většinou se jedná o úkony podobné těm, které zmiňuji v popisu jednotlivých případů 2.2. Další možnou oblastí by mohli být notáři a exekutoři, kteří také řeší typizované případy. Jako téma k zamyšlení mi advokát doporučil napojení mého řešení na archiv. Poslední verze IBM Case Manager je schopna provádět export každého hotového Case v předem daném formátu. To představuje další výhodu celého řešení, každá kancelář již nějak řeší archivaci svých případů (papírovou nebo digitální formou). Rozšíření celého návrhu, případně i ukázkového řešení, je jedním z prvních kroků, které mohou být učiněny, pokud bude řešení převzato IBM a využito při oslovení zákazníků.
6.4
Vyhodnocení řešení ve vztahu k existujícím aplikacím
V kapitole Existující systémová řešení 2.3 jsem popsal již nabízené aplikace. Část funkcí systémů nabízených dnes advokátům je podobná mému řešení. Žádný z konzultovaných advokátů se však o těchto systémech nezmínil. Podle mého názoru je jedním z důvodů rozdílnost požadavků jednotlivých kanceláří, univerzální řešení nenajde příliš zastánců. Tento fakt potvrzuje dobrou použitelnost mého řešení, úprava aplikace postavené na technologiích IBM je snadná a každá kancelář může využívat přesně takovou míru systémové podpory, jakou potřebuje. Princip Case, tedy sdružování všech informací o případu do jediné jednotky, se kterou je možné pracovat, je pro advokáty novým prvkem. Systém umožňuje s Case provádět celou řadu operací – prohlížet historii, spouštět úlohy, předávat si celý Case. Tento přístup odlišuje mnou navržené řešení od samostatných DMS systémů, které některé kanceláře používají. Zároveň je ale moje řešení schopno plně spolupracovat s již zavedenou správou dokumentů. Moduly založené na analýze nestrukturovaného obsahu (Konflikt zájmů a auditor) jsou atraktivním rozšířením ukázkového řešení. S aplikací na řešení konfliktu zájmů se již někteří advokáti setkali, ale ne tak komplexně, 93
6. Vyhodnocení využití ACM v advokacii jako to navrhuji (s využitím informací z ARES rejstříku k nalezení dříve neočekávaných spojení). Auditor pak představuje něco zcela nového – možnost ušetřit náklady vynaložené na čas studentů a koncipientů, kteří provádějí rešerše společností. Během konzultací se zpětnou vazbou jsem našel další funkce, které by bylo možné k řešení přidat a zvýšit atraktivitu řešení (například napojení na archiv). Tato funkce velmi zaujala jednoho z konzultovaných advokátů, když jsme spolu hovořili o fungování archivace. Řešení umožní aktivně pracovat s případem, když je ještě „živý“ a po dokončení všechny dokumenty a údaje jedním kliknutím nechat zabalit do jednoho dokumentu a archivovat systémovou nebo papírovou formou. Státní správa dnes poněkud neohrabaně pracuje na digitalizaci. Elektronická komunikace přes datové schránky je dnes značně nepraktická. Dokumenty po vyjmutí z datové schránky ztrácejí své ověření. Legislativa se v této oblasti dnes vyvíjí a je pravděpodobné, že v horizontu pěti let bude situace zcela jiná. Dodavatel, jenž bude mít v tu chvíli připravené a vyzkoušené řešení, které bude možné rozšířit o každou další elektronickou službu státní správy, má velkou šanci na úspěch.
6.5
Ekonomická stránka řešení
Cílem mojí práce není vyhodnotit návratnost nebo finanční dopady zavedení podobného řešení. Mohu ale konstatovat, že řešení navržené podle mnou připraveného modelu nebude advokáty zatěžovat zbytečnou prací. Řešení však může významně ušetřit čas níže postavených pracovníků kanceláře (studentů a koncipientů), kteří mohou postupovat podle připravených kroků. Významné je snížení rizika chyby při práci s dokumenty. Důležitým bodem je zvýšení spokojenosti klientů díky okamžitě dostupným informacím o stavu jejich případu. Důležitým faktorem nabízeného řešení bude jeho cena. Je na každém dodavateli, aby vyhodnotil cenu již existujích řešení a připravil konkurenceschopnou nabídku. Ve společnosti IBM řeší tuto otázku specializovaní obchodníci a já nemám možnost do této oblasti jakkoliv proniknout.
94
Závěr Závěrem bych rád shrnul výsledky, kterých jsem dosáhl a ukázal, že advokacie může pro dodavatele informačních technologií představovat "Afriku", o které mluvil Baťův pracovník, kterého zmiňuji v úvodu své práce. Prvním cílem práce bylo analyzovat činnosti a procesy, které probíhají v advokátní kanceláři. Tento cíl byl splněn. Absolvoval jsem řadu zajímavých konzultací a pronikl mnohem lépe do oboru, který mě stále zajímá – advokacie. Advokáti se ukázali jako nanejvýš konzervativní uživatelé. Pokud se má prosadit systémová podpora procesů advokátní kanceláře, musí se jednat o špičkové řešení. Těžkopádné systémy, které věří, že uživatel se časem přizpůsobí, nemají šanci. Analýza obsahuje také existující systémy využívané advokáty a specializovaná řešení nabízená IT společnostmi, čímž je naplněn cíl zmapování existujících systémů. Druhým cílem bylo vytvořit dokument čitelný pro běžné uživatele. Práce tvoří ucelený dokument, který ukazuje možnosti, které advokátním kancelářím nabízí informační technologie. Při psaní práce jsem zvolil méně technický styl, abych tento cíl úspěšně naplnil. Třetím cílem bylo mapování existujících řešení a návrh vlastního řešení. Existující řešení jsem zahrnul do analýzy. Návrh mého řešení měl být dle zadání spajtý pouze se systémem IBM ACM. Já jsem tuto část práce dále rozšířil o obecný návrh, který je na platformě nezávislý. Našel jsem několik konkrétních problémů, kde by systém mohl dobře fungovat a navrhl řešení, které každý z problémů obslouží. Portál představuje jednotné uživatelské rozhraní, kterému advokát snadno porozumí. Správa dokumentů pomůže kanceláři efektivně organizovat dokumenty. Podpora případů zahrnuje správu všech informací a dokumentů spojených s danou kauzou. 95
Závěr Konflikt zájmů usnadní přijímání nových klientů. Auditor nabídne advokátovi možnost rychle zjistit všechny dostupné informace o fyzické osobě nebo společnosti. Veřejné zdroje pak doplní portál o přístup k veřejným aplikacím, které advokát již používá. Kompletní architekturu lze naplnit pomocí technologií společnosti IBM, jednotlivé moduly lze přímo realizovat v aplikacích IBM ECM. Další potenciální dodavatelé musí zvážit, zda dokážou implementovat všechny moduly. Výsledné řešení musí být především flexibilní, protože každá kancelář bude mít odlišné požadavky, což je hlavní deviza řešení IBM, jedná se o platformy, které lze snadno a podrobně přizpůsobit. Čtvrtým cílem byla implementace a testování mého řešení. Vybral jsem část komplexního systému vhodnou pro implementaci v IBM technologiích, zaměřil jsem se na modul podpora případů a připravil ukázkové řešení v nástroji IBM Case Manager. Testování jsem pak provedl ve dvou krocích nejdříve jsem sám systém procházel a podle ukázkových případů ze sbírek simuloval činnost advokáta. Později jsem se vrátil k principům agilních metodik a zapojil do testování advokáty, kterým jsem řešení představil a požádal je o zpětnou vazbu. Cíl implementace a testování byl splněn. Posledním cílem bylo provést vyhodnocení přínosů mojí aplikace. Pokud má být řešení úspěšné, je zapotřebí advokáty přesvědčit, že systém přesně řeší jejich problémy a že práce s ním bude snadná a příjemná. Advokáti přijali moje řešení pozitivně a doporučili řadu vylepšení. Během představování systému advokátům jsem pochopil jeho nejsilnější stránky pro tuto oblast a zpracoval je. Mohu na ně poukázat v dalších prezentacích a "na živo"je ukázat. Největší výhodou nástroje IBM Case Manager, kterou bych zdůraznil, je jeho vysoká flexibilita. Snadno jsem upravoval uživatelské prostředí přímo během prezentací a ukázal advokátovi, že jeho specifické požadavky, lze snadno doplnit. Při porovnání mého řešení jsem mohl vyjít z široké analýzy, kterou jsem provedl na začátku své práce, díky které není moje řešení pouze variantou existujících aplikací. Otázkou zůstává způsob, jakým by měl být systém advokátům nabízen. Následující roky zřejmě přinesou celou řadu změn v oblasti digitalizace veřejné správy. S každým dalším krokem v této oblasti bude systémové řešení tohoto typu lákavější. Partneři v kancelářích však hledí především na okamžité finanční přínosy. Kancelář, která řeší velké množství podobných případů (například zakládání společností), by mohla řešením ušetřit náklady díky zrychlení těchto operací. V příštím roce začne platit také nový občanský zákoník, který změní způsob řešení celé řady případů. Advokáti by mohli uvítat možnost zjednodušit si práci systémem, který je prací na případech provede. 96
Práci bych rád zakončil parafrází příběhu z úvodu práce, zprávou "pro Baťu": "Je tady potenciál a příležitost obsadit trh. Měl by být vyvinut plnohodnotný systém. IT společnosti často neumějí oslovit advokáty jejich jazykem. Advokáti nevědí, jak by jim systém pomohl a raději řešení nepoužívají."
97
Literatura [1] AiP Safe: Acta Safe | Advokátní kancelář | Systém pro vedení kauzy a spisu. [online], [cit. 2013-04-08]. Dostupné z: http:// www.actasafe.cz/ [2] ASPI: Webová prezentace systému ASPI. [online], 2013 [cit. 2013-0417]. Dostupné z: http://www.systemaspi.cz/ [3] ATLAS: ATLAS consulting spol. s r.o. | CODEXIS. [online], 2013 [cit. 2013-04-17]. Dostupné z: http://www.atlascon.cz/software/ codexis [4] AVE Soft: Software Evolio - Advokátní kancelář | AVE Soft. [online], [cit. 2013-04-08]. Dostupné z: http://www.avesoft.cz/produkty/ evolio-advokatni-kancelar/ [5] Beck, K.; Beedle, M.; van Bennekum, A.; aj.: Manifest Agilního vývoje software. [online], 2001 [cit. 2013-04-14]. Dostupné z: http:// agilemanifesto.org/iso/cs/ [6] BÁLKOVÁ, S.: Ochranná známka a průmyslový vzor - jejich ochrana a padělání. Ostrava: Ostrava: Key Publishing, vyd. 1. vydání, 2011, ISBN 978-808-7255-520, 142 s. [7] BusinessInfo.cz: Obchodní společnosti - zrušení. [online], 2009 [cit. 2013-04-07]. Dostupné z: http://www.businessinfo.cz/cs/clanky/ obchodni-spolecnosti-zruseni-opu-4600.html [8] BusinessInfo.cz: Zajištění závazků - pokračování dokumentu. [online], 2009 [cit. 2013-04-07]. Dostupné z: http://www.businessinfo.cz/cs/ clanky/zajisteni-zavazku-pokracovani-opu-4611.html 99
Literatura [9] BusinessInfo.cz: Poskytování právních služeb - smlouvy s advokáty. [online], 2010 [cit. 2013-04-14]. Dostupné z: http: //www.businessinfo.cz/cs/clanky/opu-pravni-sluzby-smlouvyadvokat-4754.html [10] BusinessInfo.cz: Obchodní společnosti - založení a vznik. [online], 2012 [cit. 2013-04-07]. Dostupné z: http://www.businessinfo.cz/cs/ clanky/obchodni-spolecnosti-zalozeni-vznik-opu-4645.html [11] DataPartner: Webová prezentace společnosti dataPartner s.r.o. [online], 2011 [cit. 2013-04-07]. Dostupné z: http://www.datapartner.cz/ [12] ČERNÁ, A.: Informační systém pro právní kanceláře. [online], 2009 [cit. 2013-04-26]. Dostupné z: http://is.muni.cz/th/172898/fi_b/ [13] Česko: Zákon č. 455/1991 Sb., o živnostenském podnikání. 1991. [14] Česko: Zákon č. 513/1991 Sb., obchodní zákoník. 1991. [15] Česko: Zákon č. 265/1992 Sb., o zápisech vlastnických a jiných věcných práv k nemovitostem. 1992. [16] Česko: Zákon č. 441/2003 Sb., o ochranných známkách. 2003. [17] Česko: infoSoud informace o průběhu řízení. [online], [cit. 2013-04-06]. Dostupné z: http://infosoud.justice.cz [18] Česko: Živnostenský rejstřík. [online], [cit. 2013-04-06]. Dostupné z: http://www.rzp.cz/ [19] Česko: Obchodní rejstřík a Sbírka listin. [online], [cit. 2013-04-06]. Dostupné z: https://or.justice.cz/ias/ui/rejstrik [20] Česko: Oficiální server českého soudnictví. [online], [cit. 2013-04-06]. Dostupné z: http://portal.justice.cz/ [21] Česko: Internetový portál Ministerstva spravedlnosti české republiky. [online], [cit. 2013-04-07]. Dostupné z: http://www.justice.cz [22] eurekonom.cz: Vzor nájemní smlouvy. [online], 2010 [cit. 2013-04-07]. Dostupné z: http://www.euroekonom.cz/vzor-najemni-smlouva.php [23] Gartner, I.: Gartner it-glossary Content Analytics. [online], 2013 [cit. 2013-04-12]. 100
Literatura [24] Gilbert, M. R.; Shegda, K. M.; Chin, K.; aj.: Magic Quadrant for Enterprise Content Management. [online], 2012, [cit. 2013-04-12]. Dostupné z: http://www.project-consult.de/files/Oracle_Gartner-MagicQuadrant-ECM_20121018.pdf [25] GÁLA, L.: Podniková informatika. Grada, druhé vydání, 2009, ISBN 978-80-247-2615-1, 496 s. [26] HOLEJŠOVSKÝ, J.: Vzory podání společnosti s ručením omezeným ve věcech obchodního rejstříku. C.H. Beck, beckovy příručky pro právní praxi. vydání, 2004, ISBN 80-717-9874-6., 473 s. [27] IBM: Advanced Case Management with IBM Case Manager. [online], 2012 [cit. 2013-04-14]. Dostupné z: http://www.redbooks.ibm.com/ redbooks/pdfs/sg247929.pdf [28] IBM: Customizing and Extending IBM Content Navigator. [online], 2012 [cit. 2013-04-14]. Dostupné z: http://www.redbooks.ibm.com/ redbooks/pdfs/sg248055.pdf [29] IBM: IBM Case Manager Version 5.1.1 Information Center. [online], 2012 [cit. 2013-04-14]. Dostupné z: http://pic.dhe.ibm.com/ infocenter/casemgmt/v5r1m1/index.jsp [30] IBM: Content Navigator. [online], [cit. 2013-04-12]. Dostupné z: http://www-142.ibm.com/software/products/us/en/contentnavigator/ [31] IBM: ENTERPRISE CONTENT MANAGEMENT. [online], [cit. 2013-04-12]. Dostupné z: http://www-142.ibm.com/software/ products/cz/cs/category/SWN00 [32] IBM: Filenet P8 Platform. [online], [cit. 2013-04-12]. Dostupné z: http: //www-142.ibm.com/software/products/cz/cs/filep8plat/ [33] IBM: Softwarový produkt Web Portal od WebSphere. [online], [cit. 2013-04-12]. Dostupné z: http://www-01.ibm.com/software/cz/ websphere/portal/ [34] KOMPL: Správa zakázek, spisů a pohledávek | Informační systém SynopsIS. [online], 2013 [cit. 2013-04-08]. Dostupné z: http: //www.synopsis.cz/ 101
Literatura [35] KRATOCHVÍLOVÁ, H.: Zrušení firem: likvidace a úpadek : se vzory podání. Praha: C. H. Beck, první vydání vydání, 8 2002, ISBN 80-7179675-1, 175 s. [36] Ministerstvo financí ČR: Administrativní registr ekonomických subjektů. [online], 2012 [cit. 2013-04-14]. Dostupné z: http:// wwwinfo.mfcr.cz/ares/ares.html.cz [37] MULLER, G.: Systems Architecting: A Business Perspective. CRC Press, 2011, ISBN 1439847622. [38] pravniradce.ihned.cz: K postavení likvidátora. [online], 5 2011 [cit. 2013-04-07]. Dostupné z: http://pravniradce.ihned.cz/c151924580-k-postaveni-likvidatora [39] QCM: EZAK elektronický nástroj pro správu veřejných zakázek. [online], 2011 [cit. 2013-04-07]. Dostupné z: http://www.ezak.cz/ [40] Seznam: Internetový portál seznam. [online], [cit. 2013-04-12]. Dostupné z: http://www.seznam.cz [41] SHORE, J.; Chromatic: The Art of Agile Development. O’Reilly Media, 2007, ISBN 0596527675. [42] Smitka, D.: Smitka software. [online], 2009 [cit. 2013-04-26]. Dostupné z: http://www.jurisdix.cz/jurisdix.htm [43] Šteininger, V.: Založení a vznik společnosti s ručením omezeným. rigorózní práce, Univerzita Karlova v Praze, 2011. [44] Úřad průmyslového vlastnictví: Úřad průmyslového vlastnictví | Hlavní stránka. [online], 2008 [cit. 2013-04-09]. Dostupné z: http: //www.upv.cz/cs.html [45] VOŘÍŠEK, J.: Principy a modely řízení podnikové informatiky. Prague: Oeconomica, 2008, ISBN 9788024514406, 446 s. [46] úřad Zeměměřický: Nahlížení do katastru nemovitostí. [online], 2013 [cit. 2013-04-06]. Dostupné z: http://nahlizenidokn.cuzk.cz/
102
Příloha
Seznam použitých zkratek ACM Advanced Case Management ARES Administrativní registr ekonomických subjektů BPM Business process management CRM Customer Relationship Management CF IBM Case Foundation DMS Document management system ECM Enterprise Content Management FN IBM Filenet P8 GUI Graphical user interface IČ Identifikační číslo ICA IBM Content Analytics ICN IBM Content Navigator ICM IBM Case Manager IM Instant messaging IT Information technologies ICT Information and comunication technologies MS Microsoft 103
A
A. Seznam použitých zkratek OR Obchodní rejstřík XML Extensible markup language ŽR Živnostenský rejstřík
104
Příloha
Obsah přiloženého CD
readme.txt ................................ stručný popis obsahu CD DPČernýMartin2013.pdf ................. text práce ve formátu PDF latex DPČernýMartin2013.tex...zdrojová forma práce ve formátu LATEX citace.bib .................. citované zdroje ve formátu BibTeX pictures ..............obrázky a diagramy použité v textu práce přílohy ............................................přílohy k práci video.mp4 ........................................ video ukázka 105
B
