Informační systém pro sít ový marketing

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý Informační systém pro sít ový marketing DIPLOMOVÁ PRÁCE Bc. Petr Filla Brno, jaro 2013

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Bc. Petr Filla Vedoucí práce: RNDr. Vlastislav Dohnal, Ph.D. ii

3 Poděkování Poděkování patří společnosti Terra Group Investment, a.s., která informační systém používá a aktivně zapojila hlavní manažery a ředitele při sepisování specifikací a testování. Nedílnou součástí se stali kolegové při konzultacích během vývoje a odborné rady vedoucího práce. iii

4 Shrnutí V dnešní době je na trhu mnoho poradenských společností, které nabízí služby svých obchodních partnerů a odměnou za smlouvu, je provize dle sjednaných provizních listů. Tyto společnosti musí evidovat a vyplácet své obchodní zástupce, typovat a zpracovávat smlouvy, kontrolovat platby, evidovat a starat se o zákazníky. Systémy nabízené na trhu jsou zaměřeny na jednu oblast a individuální úprava pro jiné odvětví je většinou časově i finančně nákladné nebo jsou pro menší společnosti jednoduše příliš drahé. Celá práce spočívá v nalezení jednoduchého a obecného řešení vnitrofiremního informačního systému pro společnosti využívající sít ový marketing, které mají ve svém portfóliu více produktů. iv

5 Klíčová slova Sít ový marketing, obchodní skupiny, kariéry, smlouvy, uzávěrka provizí. v

6 Obsah 1 Úvod Sít ovýmarketing Co je sít ovýmarketing Historie Způsobodměňování Základní Načítací Ostatní Kariéra Provizní listy Systémynatrhu Systémy apoužitétechnologie Serveryasystémy Operační systémawebovýserver Databáze PHP Nástrojeatechnologie Klientskáčást Serverováčást Projekt Hlavní cíle projektu Strategievývoje Capability MaturityModel Řídící situace WorkBreakdownStructure Rizika projektu identifikaceařízení rizik Metriky Specifikace aanalýza Obchodní strukturaakariéra Obchodní zástupce Struktura Skupina Kariéra Pozice Způsobvyplácení Typyprovizí Výpočethodnotyprovize

7 5.2.2 Pozice přivyplácení Přímá provize ameziprovize Bringerbonus Tipař Dozor Provizní listy Uzávěrka afakturace Fáze uzávěrky Zpracování plateb Výpočetprovizí Faktury Nahrávání plateb Zpracování provizních reportů Chybné platby Smlouvy Stavy smluv Základní částismluv Vyhledávání smluv Reporty Manažerskástatistika Produkcestruktury Proplacenostsmluv Provize vuzávěrce Obchodní zástupci Návrh aimplementace systému Jádro Viditelnostobjektů Kariéra Smlouvy Strukuturaaplikace Objektyvdatabázi Názevobjektu Prefix objektu Postfixobjektu Složky Testováníaprovozaplikace Testovánídatabáze Testováníaplikační části Provoz Závěr

8 9 Přílohy CD

9 1 Úvod V dnešní době se společnost jen málokdy obejde bez použití infomačních technologií (IT). Velkou skupinu pak tvoří ti, kteří potřebují pro svůj každodenní chod informační systém (IS). Tato diplomová práce se zabývá IS společnostizeussolutions,s.r.o. 1 (ZEUS),kterásespecializujenasoftware v oblasti sít ového marketingu (MLM) a jejiž hlavním partnerem je společnostterragroup Investment,a.s. 2 odebírající všechnyprodukty. Společnost ZEUS solutions, s.r.o. vznikla z důvodu poptávky po aplikacích v oblasti energetiky. Na konci jara 2012, za podpory hlavního partnera, vznikl další projekt společnosti s názvem Zeus Informační Systém & Kalkulátor (ZISK) pro zázemí (BackOffice) zprostředkovatelských společností s následující funkcionalitou: evidence smluv dodavatelů s možností rozšíření mimo energetiku: Mobilní operátoři Zdravotní pojištění Voda Penzíjní připojištění zpracování smluv a jejich validace, počítání předběžných provizí, MLM struktura s kariérou + rozlišení obchodních struktur, provizní listy, nahrávání plateb a jejich kontrola, uzávěrka provizí a fakturace, reporty a cashflow, intuitivní používání a zvýšení efektivity práce uživatelů s IS. Více o sít ovém marketingu a projektu se dozvíte ve druhé a čtvrté kapitole. Použité technologie jsou popsané ve třetí kapitole a byly vybírány na základě zkušeností vedení společnosti ZEUS, vývojového týmu ze společnosti LiquidDesign,s.r.o. 3 (LQD) aposkytovateleserverůgts 4 :

10 1. ÚVOD aplikační část napsaná v PHP(ZEND framework), databáze PostgreSQL, ORM nástroj a framework od společnosti LQD, SOA architektura, podpora pro nasazení v klastru. Pro každou instanci aplikace v produkci jsou zprovozněny dva aplikační servery a dvě databáze (produkční a testovací). V páté kapitole je sepsaná specikace a analýza sít ového systému postaveného na modelu Bell LaPadula, který řeší viditelnost objetků, práva na objekty se řídí pomoci přiřazené role k přihlášenému uživateli[5]. Z tohoto důvodu jádro aplikace řeší celou správu MLM struktury. Největší a zároveň časově nejnáročnější částí aplikace je evidence smluv, pro kterou bylo nutné vytvořit správný datový model splňující následující požadavky: systém musí být schopen evidovat jakýkoliv typ smlouvy a různé kategorizace, zpracování smluv na BackOffice, spolupráce s dodavatelem a žurnál změn u smlouvy, specifický řetězec smlouvy pro párování plateb od dodavatele, silná validace a verifikace údajů podle stavů smlouvy, automatické přiřazování k provizním listům a výpočet předběžných provizí. Datový model byl vytvořen po měsících analýz formulářů různých dodavatelů a oblastí podnikání a dva měsíce testován v aplikaci Nabídkář 5, který podporuje obchodní činnost zástupců. Uzávěrka a fakturace je celá řešena databázově, aplikace pouze vypisuje údaje a vytváří potřebné reporty do pdf a excelu. O správnost výpočtu provizí se stará integritní omezení databáze, silná validace každého záznamu a kontrolní součty v databázových spouštích(triggers) nad tabulkami uzávěrky

11 1. ÚVOD Mezi další hlavní části patří generování sestav a manažerských reportů s formátováním výstupu do excelu, xml, csv, pdf a jiné. Architektura umožňuje definovat jakýkoliv report pro uživatele a webové služby, kde viditelnost reportů je řešena na úrovni rolí a bezpečnost dat má na starosti jádro aplikace (pozice ve struktuře a role přihlášeného účtu) a kontrolní mechanismus v databázi. Šestá a sedmá kapitola se zabývá implementací vybraných částí systému, popisuje způsob testování nových částí systému a provoz na produkčním serveru. 6

12 2 Sít ový marketing Multi-Level Marketing Zdroje informací pro popis sít ového marketingu pochází z otevřené encyklopediewikipedia 1, knihydonafailla[3] amultilevelmarketing.cz[9]. 2.1 Co je sít ový marketing Sít ový marketing neboli multi-level marketing (MLM) je forma přímého prodeje. Jeho podstatou je zkrácení distribučního řetězce na minimum. Výrobce nebo dodavatel služeb či zboží vytváří dodavatelské podmínky pro samostatné podnikání svých nezávislých vlastníků podnikání(nvp). Ti na základě toho mohou zprostředkovat příležitost stát se NVP dalším lidem, a tak vzniká víceúrovňová (multi-level) odběratelská sít (struktura), která je coby forma distribuce účinnější a levnější než klasický distribuční řetězec velkoskladů, velkoobchodů a reklam. Tato forma distribuce ponechává mnohem více finančních prostředků výrobci, který má tak větší prostor investovat do vývoje, technologií a vstupních surovin, čímž může oproti konkurenci dosáhnout vyšší kvality nabízených produktů či poskytovaných služeb distribuovaných právě prostřednictvím MLM. Zároveň tak výrobce může NVP nabídnout zajímavé motivační ohodnocení(marketingový plán) a významné konkurenční výhody. Zjednodušeně lze říci, že jde o jakousi kombinaci přímého prodeje a frenčízingu, pro kterou se také vžilo označení osobní frenčízing. O sít ovém marketingu se také hovoří jako o referenčním prodeji. Většina NVP totiž buduje svou sít především na základě doporučení lidem ve svém okolí, u kterých mají důvěru. Ta je jedním z hlavních předpokladů úspěšného podnikání v tomto oboru. Seriózní firmy, využívající MLM, jsou sdružené v mezinárodních asociacích DSA[6], DSEI[7], FEDSA[8], WFDSA[13] a také v národní asociaci AOP[10]. Členové asociace se zavazují přijetím členství k vysoké kvalitě svého zboží aslužebastejnětak sezavazují knormámetickéhochování. 2.2 Historie Historie popisuje tento způsob prodeje velice negativně, protože i zde muselo dojít k postupnému vývoji. Lidé mají začátky MLM spojené s nutností

13 2. SÍŤOVÝ MARKETING nákupu zboží za nemalé peníze, které skladovali na vlastní náklady a poté nabízeli dům od domu. V dnešní době dokáží úspěšné firmy zájemcům o spolupráci nabídnout opravdu zajímavé podmínky. Patří sem například nízké, nebo nulové počáteční investice a on-line objednávkový systém pro nákup zboží od výrobce. Náklady tak jsou prakticky nulové, jelikož NVP není nucen si pronajímat skladovací prostory a držet zboží skladem. 2.3 Způsob odměňování Základní Základní systém vznikl v počátcích MLM a jeho struktura je nejjednodušší. Spočívá v tom, že za každé prodejní období ukončené uzávěrkou provizí (většinou měsíc) se sečtou prodeje (body) v sítích a podle algoritmu výpočtu odměn se zjistí odměny jednotlivých distributorů a pošlou se jim na účet. Body dosažené v tomto období se vynulují a další období se začíná od nuly Načítací Systémnačítací je druhý způsob a podstata systému spočívá v tom, že dosažené body za prodejní období se započtou i do následujících období. Člověk, který v jednom měsíci dosáhl určité bodové úrovně, již na ní zůstává navždy Ostatní Všechny další systémy jsou modifikací základního a načítacího systému a snaží se ho dle určitého modelu vylepšovat. Cílem je zvětšení možnosti výdělku a motivace sítí. 2.4 Kariéra Zakladní stavební kámen každého sít ového marketinu se nazývá kariéra, která přesně říká: jakým způsobem bude distributor odměněn, jak seurčuje pozice vmlm, jak často se vyplácejí provize, 8

14 2. SÍŤOVÝ MARKETING jakým způsobem probíhá prodej, jakým způsobem se tvoří obchodní sít, práva a povinnosti smluvních stran, způsob vyplácení, odkaz na provizní listy. Tyto základní body jsou stvrzeny podpisem smluvních stran bud v mandátní smlouvě, smlouvě o obchodním zastoupení(soz) nebo registrací distributora do sít ového marketinu a nabývají právní moci v den podpisu nebo registrace. U mnoha firem, které propůjčují svoji identitu přímo distributorovi, obsahuje smlouva také normy etického chování a konkurenční doložku. 2.5 Provizní listy Poslední a asi nejdůležitější částí sít ového marketingu jsou provizní listy, které udávají finanční ohodnocení za přinesený obchod. Pro obchodní struktury se může výše provize měnit nejenom pozicí v kariéře, ale také vlastní produkcí struktury (pozitivně i negativně). Dnes existují velké obchodní struktury, které si vybírají výrobce nebo dodavatele služeb přávě podle nasmlouvaných provizí. 2.6 Systémy na trhu V dnešním světe internetu je mnoho webových aplikací podporující prodej sít ovým marketingem, jsou to jednoduché sít ové systémy s jednoduchou kariérou a provizním modelem. Uživatel se jednoduše zaregistruje a za každý prodaný produkt dostává provizi. Člověk to může chápat jako internetový marketing spojený se sociální sítí. V této oblasti stojí za zmínku mezinárodní systémlyoness 2,kterýje jedenzmála dobřefungujících. Druhou skupinu tvoří společnosti, které odměňují své obchodníky, zaměstnance nebo smluvní partnery podle produkce, nejčastěji jde o banky, pojišt ovny, dodavatele energií, poradenské společnosti a mnoho dalších. Příklad: SwissLife Selekt(původně AWD), Partners, Axa, Centropol, v energetickém poradenství optimal-energy.cz a Energetická bilance. Všechny tyto společnosti mají vnitrofiremní provizní systém postavený na jedné kariéře s podporou jednoduchého rozpočítávání provizí

15 3 Systémy a použité technologie 3.1 Servery a systémy Informační systém bude postaven jako webová aplikace využívající servery s operačním systémem Linux[2], databázi, webový server s PHP, tato použitá architektura je známá pod zkratkou LAMP. Pro každou instanci aplikace v produkci budou zprovozněny dva aplikační servery a dvě databáze(produkční a testovací). Jelikož bude aplikace nasazována jako balíček, stačí pro vývoj aplikace jeden aplikační server s vývojovou databází. Vývoj bude probíhat v prostředí devportal.eu 1 na adrese dev.zeus-solutions.cz, produkční verze bude nasazena na servery společnosti ZEUS na adrese zisk.zeus-solutions.cz a test.zeus-solutions.cz pro testování uzávěrky a nových částí Operační systém a webový server Doména je spuštěna na stroji app-web.core.devportal.eu s operačním systémemcentosrelease ajádrem Linuxversion el5xen. Webovým serverem Apache 2.2 HTTP Server Databáze Jelikož je zapotřebí výkonný objektově-relační databázový systém s podporou procedurálního jazyka SQL, byla vybrána open-source databáze PostgreSQL 3 s více než15-ti letýmaktivním vývojem, dobřepsanoudokumentací a osvědčenou architekturou zajišt ující spolehlivost, integritu dat a korektnost. Dále běží na všech hlavních operačních systémech, včetně Linux, UNIX a Windows. Je plně ACID kompatibilní, má plnou podporu cizích klíčů, pohledy, triggery a uložené procedury (v několika jazycích). Navíc bez limitu velikosti dat podporuje ukládání binárních velkých objektů včetně obrázků, zvuků nebo videa. Nativní programovací rozhraní pro C/C++, Java,. NET, Perl, Python, Ruby, Tcl, ODBC je samozřejmostí. Databáze bude nasazena na stroj ve verzi a nainstalovány rozšiřující balíčky postgresql-contrib-9.2 a uuid-ossp pro podporu generování UUID objetku[11]

16 3. SYSTÉMY A POUŽITÉ TECHNOLOGIE PHP PHP 4 je skriptovací programovací jazyk, určený především pro programování dynamických internetových stránek. Díky jeho snadnému použítí se vyvinul a dnes nabízí velké množství nástrojů a rozšiřujících balíčků pro rychlé programování. Další důležité aspekty při výběru programovacího jazyka jsou zkušenosti vývojového týmu v daném jazyce, naprogramované knihovny, zastupitelnost programátora a jiné. Proto bylo PHP vybráno pro aplikační část informačního systému. 3.2 Nástroje a technologie Dnes se pro vývoj aplikací nepoužívají základní knihovny programovacích jazyků. Byly vytvořeny nástroje, které ulehčují práci návrhářům, programátorům a testerům. Proto je dobré se na začátku projektu podívat na možnosti vývoje aplikací a najít optimální řešení v různých knihoven a frameworků, kde je již řešena daná problematika a programátor se tak může věnovat psaní výkonného kódu. Zvládnutí MVC frameworků navíc urychluje tvorbu aplikací a hlavně usnadňuje udržbu aplikace po stránce časové i personální. Technologie byly vybírány na základě zkušeností vývojového týmu společnosti ZEUS, hlavního programátora ze společnosti LQD a poskytovatele serverů. Níže jsou uvedeny základní nástoroje a technologie použité ve vývoji systému Klientská část XML je obecný značkovací jazyk 5, který byl vyvinut a standardizován konsorciem W3C. Je zjednodušenou podobou staršího jazyka SGML. Umožňuje snadné vytváření konkrétních značkovacích jazyků (tzv. aplikací) pro různé účely a různé typy dat. HTML HyperTextMarkupLanguage 6 jeznačkovacíjazykprohypertext. JejednímzjazykůprovytvářenístránekvsystémuWorldWideWeb, který umožňuje publikaci dokumentů na Internetu a je standardizován konsorciem W3C. CSS jezkratkaproanglickýnázevcascadingstylesheets 7,českytabulky

17 3. SYSTÉMY A POUŽITÉ TECHNOLOGIE kaskádových stylů. Je to jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML a XML. JavaScript je multiplatformní, objektově orientovaný skriptovací jazyk 8 a jsou jím obvykle ovládány různé interaktivní prvky GUI (tlačítka, textová políčka) nebo tvořeny animace a efekty obrázků. jquery je knihovna JavaScriptu 9, která řeší problematiku psaní scriptů pro různé prohlížeče. Základní výrazový jazyk je směsicí CSS selektorů, jednoduchých XPath a komunikace Ajax[16]. JSON je velmijednoduchýdatovýformát sesyntaxíjavascriptu Serverová část MVC Model-view-controller je softwarová architektura(návrhový vzor), která rozděluje aplikaci na tři nezávislé komponenty(datový model, uživatelské rozhraní a řídicí logika) tak, že modifikace některé z nich má jen minimální vliv na ostatní. ZendFramework Zend 11 jeplnohodnotnýopen-sourcemvcframework provývojwebovýchaplikacíaslužebvphp5.3.kódveframeworku je plně objektově orientovaný a má přes 15 miliónů stažení[1]. Smarty Smarty 12 je engine pro vytváření šablon pro prezentační vrstvu MVCvPHP, což znamená, že PHP kódaplikační logiky je oddělena od prezentace[12]. PHPPEAR PEAR 13 jeoficiální rozšíření PHPodalší knihovnykódu. STORM je ORM nástroj pro PHP od společnosti LQD. SOA je architektura pro integraci s jinými systémy. UML Unified Modeling Language je v softwarovém inženýrství grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů[4]

18 4 Projekt Společnost ZEUS solutions, s.r.o. vznikla před dvěma lety a důvodem byla poptávka po aplikacích v oblasti energetiky, pro evidenci obchodních zástupců, klientů a jejich smluv. Tento jednoduchý systém byl po roce používání rozšířen o kategorizaci smluv, vytváření nabídek s ceníky dodavatelů a pojmenován Nabídkář. Dne byla nasazena verze 4.0, podporující veškerou obchodní činnost uživatelů. Pro BackOffice byl použit IS externí společnosti, používaný ve finančním sektoru, který se měl starat o zpracování smluv, nahrávání provizních reportů a uzávěrku provizí. NIS, jak byl nazván tento systém správcem aplikace, ale nevyhovoval nárokům ani po roce drahé individuální úpravě, navíc byl pomalý, obtížně se používal a design připomínal 90.léta minulého století. Na konci jara 2012, za podpory nového partnera společnosti, vznikl nový projekt s názvem Zeus Informační Systém & Kalkulátor (ZISK), který má zajišt ovat vnitrofiremní IS poradenské společnosti, zvládnout problematiku komplexní evidence nejenom v energetice a zároveň se vyvarovat nedostatkům předchozího systému. Obr. 4.1: ZISK-UseCase 13

19 4. PROJEKT 4.1 Hlavní cíle projektu Do první fáze projektu byla zahrnuta: Evindence smluv a nabídek MLM, kariéra a správa obchodních zástupců Fakturace a uzávěrka provizí Výpočet provizí z provizních listů Reporty pro BackOffice a struktury Komunikace s ekonomickým systémem Use friendly UI Informování struktur Údržba, podpora BackOffice a rozvoj 4.2 Strategie vývoje Vzhledem ke zkušenostem týmu, povaze řídícího problému a čásové náročnosti se budou uplatňovat agilní způsoby vývoje a testování prototypů aplikace. Dlouhodobé plánování projektu se bude řešit iterativním vývojem(3-4 mešíce na jednu fázi), na střední a krátkodobé plánování se uplatní inkrementální vývoj SCRUM. Součástí první iterace je zahrnuta i údržba a rozvoj aplikace, což může velice negativně ovlivnit čas vývoje inkrementů. Podrobnosti o inkrementech a milnících budou evidovány v projektovém plánu. 4.3 Capability Maturity Model Pro zajištění kvality, dodržení stanovených funkčních a výkonových požadavků je třeba pracovat na vyspělosti organizace, jejiž úroveň můžeme měřit například pomocí Capability Maturity Model(CMM). 1. Zajistit úroveň 1 v prvním inkrementu(opakovatelný) Řízené požadavky Plánování 14

20 4. PROJEKT Identifikace a popis procesů a procedůr Plán pod kontrolou(proměnlivá kvality a ceny) 2. Úroveň 2(definovaný) Zajistit do druhé fáze (iterace) projektu Zlepšení a definice organizačního procesu, pravidelná školení, koordinace pracovních skupin Kontrola kvality a plánu 4.4 Řídící situace Každý projekt můžeme zařadit do jedné ze čtyř základních řídících situací, které jsou určeny úrovní jistoty produktu, procesů a zdrojů[15]. V této sekci jsou uvedeny situace tohoto projektu, u kterého se řeší na začátku návrhový a následně alokoční problém. 1. Návrhový problém (na začátku projektu) Z důvodu velikosti projektu a zkušenosti týmu Navrhnout projekt Identifikace milníků Rozdělení rolí a odpovědností Dostatečné časové a rozpočtové kapacity (nelze projekt urychlit) Cenové modely odhadované zdola-nahoru u outsourcingu Inkrementální vývoj Zdroje defektů specifikace a návrh obsahuje cca 80% defektů 2. Alokační problém Problém je dostupnost lidských zdrojů-> outsourcing Standardizace a popis procesů z důvodu zajištění jistoty produktu Lineární procesní model + prototypování Zapojení vedení a koncové uživatele 15

21 4. PROJEKT 4.5 Work Breakdown Structure Work Breakdown Structure (WBS) je technika používaná v projektovém managementu k rozložení cíle projektu na jednotlivé dodávané produkty. Jednotlivými elementy rozpadu jsou vždy produkty nebo výsledky činností. WBS musí vždy pokrýt celý cíl projektu a neřeší časové závislosti mezisvýmijednotlivýmielementy Databáze Datový model smluv/klientů/opm/dashboard a kategorizace MLM a kariéra + kanceláře Řízení přístupu pro MLS(multilevel systems) Provizní listy a výpočet provizí Způsob vyplácení Tiskové sestavy(doklady) a fakturace Platby a uzávěrka Reporty pro vedení a management struktur Testy jednotkové a integrační Kontrolní procedury a správa dat 2. Aplikační část Grafika a UI aplikace Dashboard Přihlašování a správa uživatelů Role uživatelů, práva pro role a řízení přístupu na objekty Typování a správa smluv a klientů Správa kariéry Provize u smluv Uzávěrka PDF formuláře smluv Faktury a brána s ekonomickým systémem Reporty a export Testy integrační, akceptační a výkonové

22 4. PROJEKT 3. Infrastruktura Server hosting Vývojové prostředí Zálohování Sledování zatížení serverů 4. Dokumentace a podpora aplikace Technický manuál Analýzy, návrhy a zprávy o projektu Tutoriály, směrnice a manuály pro BackOffice a uživatele Helpdesk a datový sklad 5. Procesy Projektování procesů ve společnosti(backoffice, kanceláře) Řízení procesů 4.6 Rizika projektu identifikace a řízení rizik Jelikož je ZISK složitý software, je zapotřebí soustředit pozornost během projektu na rizikové položky, které se musí nejdříve identifikovat a následně řídit. 1. Nedostatek pracovníků Outsourcing Liquid Design, s.r.o. Nezatěžovat ICT procesními úkoly a helpdeskem Školení a manuály pro BackOffice (definování procesů) 2. Neshody v požadavcích Zapojení vedení do projektu(konkrétně Ing. Petr Částek) Pravidelné kontrolní schůzky Prototypování nových částí aplikace 3. Změny v požadavcích a přecenění možností informatiky Do specifikací zahrnout i možné další případy s extrémy 17

23 Konzultace vedení s ICT před odsouhlasením změn 4. Zděděný software ZEND Framework PHP a knihovna jquery Zvládnutí knihovem od Lequid Design, s.r.o. Aktivní začlenění do vývoje v outsorcingu 5. Architektura, výkon, kvalita Validace a verifikace kódu Inspekce 6. Testování Jednotkové Integrační Akceptační testy před nasazením Testování aplikace před nasazením uživateli 7. Plány, procesy, chyby Pravidelné kontroly milníků/plánů/procesů Identifikace a zvládnutí procesů ve společnosti Řešení chyb procesním způsobem 8. Zranění/ukončení/onemocnění/smrt klíčového pracovníka 4. PROJEKT 4.7 Metriky Metriky jsou základní body celkového hodnocení produktu, aby byl ZISK úspěšný, byly identifikovány základní metriky hodnocení. 1. Use Friendly UI Pohodlné, intuitivní a ergonomické UI bez grafických zbytečností Zajištění funkcí požadovaných od vedení a manažerů 2. Znovupoužitelnost kódu Procentuální zastoupení kódu umožňující použití pro další komponenty 18

24 4. PROJEKT 3. Udržovatelnost kódu Procentuální zastoupení opakujících se částí kódu Optimalizace kódu a odstraňování černého kódu 4. Testování kódu Procentuální zastoupení otestovaného kódu 19

25 5 Specifikace a analýza Jak bylo uvedeno v identifikaci rizik, jeden z největších problému projektů tohoto typu je špatná specifikace a analýza problematiky, jejiž oprava může být velmi drahá a dokonce může znamenat ukončení celého projektu. Před otevřením celého projektu sbírala společnost rok zkušenosti s procesy na BackOffice a způsob komunikace s partnery, během této doby řešila správu systému, který řešil danou funkcionalitu, a měla přístup k informacím od manažerů obchodních struktur. To vše vytvořilo základ pro jádro dobrého sít ového informačního systému. Analýza formulářů dodavatelů v oblasti energetiky, telekomunikací, pojištění, zdravotního pojištění a jiných tvoří další velkou část, která byla nezbytná před sepsáním specifikací. Další nezanedbatelný celek tvoří ceníky a provizní listy, ve kterých bylo nutné se zorientovat. 5.1 Obchodní struktura a kariéra Základem každého sít ového marketingu tvoří obchodní struktura a kariéra, podle které se řeší viditelnost a práva ve struktuře dle pozic a postavení. Jelikož každá struktura může mít svoje kariéry a podmínky s partnerem, musí být evidence velmi flexibilní. Obchodní strukturu tvoří obchodní zástupci nebo subjekty, kteří mají svého nadřízeného(sponzor), přiřazenou skupinu, kariéru, pozici a kancelář. Dle podmínek způsobu tvoření struktur pak vzniká stromová struktura, jejíž tvar a zanoření záleží na manažerovi nebo smluvně danému systému tvoření struktur Obchodní zástupce Obchodním zástupcem (OZ) se myslí uzel ve stromové struktuře, který je odlišen názvem a unikátnímu ID. ID je generované nebo přiřazené dle umístění ve struktuře a kariéře. Pro každého OZ platí: má svého nadřízeného(sponzora), musí mít vyplněný způsob vyplácení, zneaktivnění může proběhnout až poté, co byla danému OZ odebrána jeho podstruktura, obsahuje účty, pod kterými se přihlašují uživatelé do systému. 20

26 5. SPECIFIKACE A ANALÝZA U OZ se dalé ukládájí informace: jméno, přijmení, titul, adresa trvalého bydliště, korespondenční adresa, mobilní telefon a Struktura Sítě tvoří stromovou strukturu, kde kořenem stromu je daná společnost, která sít ový marketing provozuje. Kořen je také jediným uzlem, který má jako svého sponzora sám sebe Skupina Základní stavební kámen sít ového informačního systému, která odděluje obchodnískupinyakaždýozmusípatřitdojednéznich.prokaždouskupinu se definují: kariéry, pozice a hodnoty bodů provizní listy způsob ohodnocení produkce obchodních zástupců kanceláře a evidence asistentek produkty Kariéra Kariéra je vždy přiřazena ke skupině a určuje pozice, způsob počítání bodů a rozdělévání provizí. OZ musí být zařazen do určité kariéry, která může být platná pouze pro určitou podstrukturu Pozice Je daná procentuální neměnnou hodnotou 0-100% nároku z provize za obchod. Každý OZ musí mít přiřazenou pozici dle podmínek spolupráce. 21

27 5. SPECIFIKACE A ANALÝZA Způsob vyplácení Způsob vyplácení je mapování obchodních zástupců na ekonomické subjekty. Ekonomický subjekt je určen svým identifikačním číslem organizace (IČO) nebo rodným číslem. Provize v uzávěrce jsou přiřazeny obchodnímu zástupci a fakturovány dle jeho způsobu vyplácení na bankovní účet subjetku. 5.2 Typy provizí V sít ovém marketingu se platba, která příjde za obchod, rozděluje na provize dle struktury a pozic obchodních zástupců směrem nahoru od majitele obchodu po kořen struktury(kořen struktury je znám v MLM jako ředitelství). Jelikož struktura není statická, mohou existovat různé typy provizí, jejich základní rozdělení jsou uvedeny v této sekci. Jednotlivé systémy se nejvíce liší právě ve způsobu určení pozice obchodního zástupce při vyplácení obchodu. Způsob vyplacení obchodu patří mezi základní body pro obchodní strukury při výběru, do kterého sít ového marketingu se začlení Výpočet hodnoty provize Základní rozdělení způsobu výpočtu hodnoty provize: procenta platba se rozdělí na provize pomocí procent dle pozic fixní platba se rozdělí na provize pomocí fixních hodnot dle pozic ostatní kombinace výše zmíněných způsobů Protože fixní ohodnocování obchodů se většinou přepočítává na procenta, budeme dále uvažovat pouze s procentuálním způsobem výpočtu hodnot provizí Pozice při vyplácení Rozdělení způsobu vyplácení provizí podle pozice, na které byl obchodní zástupce, je určená dnem: podpisu smlouvy, zatypování smlouvy (den akceptace smlouvy partnerem), první příchozí platby, platby a uzávěrky. 22

28 5. SPECIFIKACE A ANALÝZA Přímá provize a meziprovize Přímá provize je provize, která náleží obchodnímu zástupci, který vlastní daný obchod, vypočet: platba* pozice. Meziprovize jsou provize patřící sponzorům dané struktury, která obchod vyprodukovala, vypočet: platba*(pozice- vyplacená procenta), pozice + vyplacená procenta nemohou být vyšší než 100%. Obr. 5.1: Provize a meziprovize diagram OZ je subjekt v MLM struktuře. OZ1jesponzoremOZ2aOZ 3. OZ3jesponzoremOZ4aOZ 5. Platba 1 je vyplacená na OZ 1, kterému je přiřazena přímá provize. Platba 2 je vyplacená na OZ 2, kterému je přiřazena přímá provize, OZ 1 má meziprovizi. Platba 3 je vyplacená na OZ 4, kterému je přiřazena přímá provize, meziprovize mají OZ1aOZ3. Pozice OZ a jejich procentuální ohodnocení je uvedené v tabulce 5.1, příklad výpočtu provizí v tabulce

29 Tab. 5.1: Pozice obchodních zástupců Pozice(název) Pozice (procenta) OZ 1 Ředitel 90% OZ 2 Manažer 65% OZ 3 Týmový manažer 70% OZ 4 Týmový manažer 70% OZ 5 Poradce 50% 5. SPECIFIKACE A ANALÝZA Tab. 5.2: Přepočítání přímých provizí a meziprovizí Platba 1 Platba 2 Platba 3 Hodnota 100 Kč 100 Kč 100 Kč OZ1 100 *0.9 = *( ) = *( ) = 20 OZ2 100 *0.65 = 65 OZ3 100 *( ) =0 OZ4 100 *0.70 = 70 OZ Bringer bonus Bringer bonus je zaujatost bringera na meziprovizích určitého manažera z dané MLM struktury. Používá se při finančních vyrovnáváních smluvních ujednání mezi OZ, kteří strukturu do obchodu přivedli nebo mají zásluhy na její produkci a nebo prodali, a sponzorem, který momentálně vlastní a pobírá meziprovize z produkce dané struktury. Vlastnosti: Bringer je obchodní zástupce v MLM struktuře (dále jen OZ) nebo subjekt, který si nárokuje procenta z meziprovizí daného manažera za platby spadající do určité podstruktury. Bringer bonus obsahuje bringera, manažera, majitele struktury a procento, kde: bringer dostává procenta z meziprovizí manažera manažer vlastní bringrované struktury vlastník vymezuje danou podstrukturu procento udává poměr, který se strhne z meziprovizí sponzora za danou strukturu 24

30 5. SPECIFIKACE A ANALÝZA Na každého manažera může být nastavený bringer bonus(1 a více). Meziprovize je vypočítaná podle pozic jednotlivých OZ a výši platby do struktury. Součet procent bringerů pro daného OZ nemůže být vyšší než 100%. Nastavení bringer bonusů je fixní pro jednotlivé uzávěrky. Obr. 5.2: Bringer bonus diagram OZ a Br. jsou jednotlivé subjekty v MLM struktuře. Br. 1 a Br. 2 jsou bringeři pro OZ 1, kterývymezuje struktury(oz 2, OZ3, OZ4, OZ5aOZ6). Br.2má nastavenoustrukturuoz2aoz3. Br.1má nastavenoustrukturuoz2aoz4. Platba1jevyplacenánaOZ2,kdejenastavenýBr.1aBr.2,meziprovize OZ1jsouponíženyoprocentaBr. 1aBr. 2nastavenánaOZ2. Platba 2 je vyplacená na OZ 3, kde je nastavený Br. 2, meziprovize OZ1jsouponíženyoprocentaBr.1nastavenánaOZ2aBr.2nastavenánaOZ3. 25

31 5. SPECIFIKACE A ANALÝZA Platba 3 je vyplacená na OZ 4, kde je nastavený Br. 1, meziprovize OZ1jsouponíženyoprocentaBr.1nastavenánaOZ4aBr.2nastavenánaOZ2. Platba 4 je vyplacená na OZ 5, meziprovize OZ 1 jsou poníženy oprocentabr. 1nastavenánaOZ4aBr. 2nastavenánaOZ2. Nastavení bringerů je uvedeno v tabulce 5.3, příklad výpočtu provizí v tabulce 5.4. Tab. 5.3: Nastavení bringerů pro OZ 1 Br.1 Br. 2 OZ 2 10% 10% OZ 3 nenastaveno-> 10% (OZ 2) 30% OZ4 40% nenastaveno->10% (OZ2) OZ5 nenastaveno-> 40% (OZ4) nenastaveno-> 10% (OZ2) OZ6 nenastaveno-> 40% (OZ4) nenastaveno-> 10% (OZ2) Tab. 5.4: Přepočítání meziprovizí OZ 1 Br. 1 Br. 2 OZ 1(meziprovize) Pl Kč 100 *0.1 = *0.1 = =80 Pl Kč 100 *0.1 = *0.3 = =60 Pl Kč 100 *0.4 = *0.1 = =50 Pl Kč 100 *0.4 = *0.1 = = Tipař Vyplacení procenta z přímé provize OZ tipaři, který dohodnul obchod. Tipař je osoba, která přivedla nebo se pasivně podílela na obchodě, a nárokuje si odměnu z přímé provize obchodního zástupce, který je vlastníkem daného obchodu a vyplácí se mu přímá provize. Vlastnosti: Tipař je obchodní zástupce v MLM struktuře(dále jen OZ) nebo subjekt, který si nárokuje procenta z přímé provize za platby na daný obchod. Tipař u smlouvy obsahuje tipaře a procento, kde: tipař nárokuje odměnu, 26

32 5. SPECIFIKACE A ANALÝZA procento udává poměr, který se strhne z meziprovizí sponzora za danou strukturu. Nakaždé smlouvěmůže býtnastavenýtipař (1avíce). Součet procent tipařů u smlouvy nemůže být vyšší než 100%. Tipař nezískává body do MLM. Provize pro tipaře se dále nerozděluje do jeho MLM struktury(stejně jako bringer). Nastavení tipaře se fixuje pro jednotlivé uzávěrky. Storno platba se strhává podle příslušné kladné platby. Obr. 5.3: Tipař diagram OZ a Tipař jsou jednotlivé subjekty v MLM struktuře, Obchod je zatypovaný obchod. Tipař je tipař nastavený u Obchod. OZ2másponzoraOZ1. Příchozí Platba přiřazena na Obchod, přímá provize OZ 2 je ponížena o procenta Tipaře. Nastavení tipaře je udeveno v tabulce 5.5, příklad výpočtu provizí v tabulce

33 5. SPECIFIKACE A ANALÝZA Tab. 5.5: Obchod s tipaři Tipař OZ 2 pozice Obchod 10% 90% (50%) Tab. 5.6: Přepočítání přímé provize Přímá provize Tipař OZ 2 Platba 200 Kč 200 *0.5= *0.1= =90 Storno -100 Kč -100 *0.5=-50-50*0.1= (-5) = Dozor Dozor má dva způsoby použití: 1. OZ v jakékoliv pozici a na jakémkoliv místě v síti pomáhá (poskytuje odborné, metodické a obchodní vedení) s uzavřením obchodu jinému obchodnímu zástupci, který je také na jakékoliv pozici a na jakémkoliv místě v síti. Oba obchodníci mají právo mezi sebou uzavřít Smlouvu o spolupráci o Dozoru, ve které je specifikován obchodní případ a obchodní podíl z dosaženého obchodního výsledku. Dozorující OZ v tomto případě nesmí obdržet vyšší než 60%-ní část. 2. Dozorem se rozumí také případ, kdy se dva nebo více obchodních zástupců dohodnou na společném uzavření obchodu. Na základě Smlouvy o spolupráci o Dozoru, ve které je specifikován obchodní případ spolupráci si vzájemně podělí odměnu z dosaženého obchodního výsledku. Vlastnosti: Rozdělení podílu za obchod mezi více OZ, kteří pomohli s uzavřením obchodu nebo se na něm společně aktivně podíleli. U smlouvy může být uvedeno libovolné množství OZ, kteří provádí Dozor nad touto smlouvou. Pro každého dozorujícího OZ je možno určit procento, které udává, jaká část z příchozí platby na tuto smlouvu se rozdělí. Dozorující OZ a jeho nadřízení v MLM struktuře získávají za obchod body. Součet všech dozorů nesmí převýšit 70%. 28

34 5. SPECIFIKACE A ANALÝZA 5.3 Provizní listy Tato část se zabývá evidencí finančního ohodnocování obchodů, které jsou smluvně zakotveny ve smlouvě o spolupráci s partnerem. Základní funkce provizních listů spočívá ve výpočtu předběžných provizí za obchod, kontroly plateb a počítání tzv. cashflow společnosti. Vlastnosti: Každý provizní list má svůj identifikující název a dobu platnosti oddo. Musí být univerzální pro všechny produkty. Snadná správa administrátorem. Balíčky dodavatelů jsou spárovány s provizními listy (alespoň jeden). Každý balíček má svůj výchozí provizní list. Provizní listy musí být rozlišeny pro jednotlivé skupiny. Kategorizace výpočtu podle datum zatypování smlouvy spotřeba počet odběrných míst komodita právnická vs. fyzická osoba skupina Přesnost výpočtu na dvě desetinná místa. Ochrana proti duplicitním záznamům. 5.4 Uzávěrka a fakturace Je to základní funkcionalita celého systému, která umožňuje vyplácení obchodních zástupců nebo celých obchodních skupin. Jedná se o algoritmus, který pracuje s nahranými platbami do struktury a rozpočítává je na provize. Uzávěrka pak uzavírá platby a provize pro danou podstrukturu. Jednotlivé provize subjektů jsou pak sečteny a tvoří report provizí přiložený 29

35 5. SPECIFIKACE A ANALÝZA k vygenerované faktuře. Z důvodu legislativních zákonů pro účetnictví jednotlivých států je uzávěrka a fakturace vždy pouze pro jednu měnu. Z důvodu přetížení pracovníků BackOffice v době uzávěrky je důležité, aby samotná uzávěrka byla pouze uzavřením provizí a ostatní probíhalo on-line před uzávěrkou Fáze uzávěrky Jelikož se jedná o složitý proces, je rozdělen do částí jdoucí postupně: 1. Vytvoření nové uzávěrky 2. Zahrnutí plateb do uzávěrek 3. Zpracování plateb v dané uzávěrce 4. Uzavření uzávěrky 5. Generování faktur a komunikace s ekonomickým systémem Zpracování plateb Zpracování plateb je odlišné od nahrávání plateb, které je úzce spojeno s provizními listy. Jedná se o část algoritmu uzávěrky, která se stará o: rozdělování plateb do uzávěrek, správa plateb a jejich přepočítávání, rozdělení do MLM struktury. Zde je jediné místo, kde bude možnost administrátorských zásahů do výpočtů uzávěrky pomocí předefinovaných funkcí v aplikaci. Vlastnosti: Každá platba je identifikovaná číslem (ID platby). Každá platba je přiřazena ke smlouvě a obchodnímu zástupci. Obchodní zástupce na smlouvě se může změnit. Záporné platby (storna) musí být mapovány na kladné platby. Storno je vždy přiřazeno k nejbližší (podle datumu) kladné platbě, která nebyla zatím stornovaná. 30

36 5. SPECIFIKACE A ANALÝZA zpracování plateb probíhá podle ID od nejmenší neuzavřené. Každá platba patří do určité uzávěrky. Uzavřená platba (ukončená uzávěrka) se nesmí již zpracovat. Řeší rozdělování plateb podle dozoru na smlouvě. Možnost řídit způsob zpracování platby. Hodnoty platby jsou uvedeny tabulce 5.7. Tab. 5.7: Platba hodnoty Hodnota Popis ID identifikace platby Partner identifikace partnera, který platbu vyplatil Uzávěrka aktuální zařazení do uzávěrky OZ přiřazený obchodní zástupce dle smlouvy v dané době Typ způsob zpracování plateb Hodnota hodnota provize Procento procentuální ohodnocení vyplaceného obchodu Zpracováno datum posledního zpracování Výpočet provizí Každé zpracování platby končí rozpočítáním do provizí. Vlastnosti: Každá provize je identifikovaná číslem (ID provize). Výpočet bude určen fixovanou strukturou v dané uzávěrce. Záporné provize se nemusí mapovat na kladné provize. Každá provize patří do určité uzávěrky. Uzavřená provize (vyplacená) se nesmí již přepočítat. Řeší vyplácení bringerů a tipařů. Hodnoty provizí jsou uvedeny v tabulce

37 5. SPECIFIKACE A ANALÝZA Tab. 5.8: Provize hodnoty Hodnoty Popis ID identifikace provize Typ informace o typu provize OZ přiřazený OZ majitel obchodu Hodnota hodnota provize Procento procentuální ohodnocení poměru provize a platby Uzávěrka vyplacení provize v uzávěrce Faktury Po uzavření uzávěrky se generují faktury a posílají se do ekonomického systému. Generování faktur je založeno na součtu provizí v dané uzávěrce pro daný subjekt určený podle způsobu vyplácení obchodního zástupce. Každá faktura musí být podložená seznamem provizí, tzv. report provizí, a jejích hodnoty jsou uvedené v tabulce 5.9. Tiskové sestavy pro: plátce/neplátce DPH faktura/opravný doklad právnická/fyzická osoba Tab. 5.9: Doklad hodnoty Hodnoty Popis ID identifikace dokladu Odběratel subjekt na dokladu Dodavatel subjekt na dokladu Položky dokladu text: Provize z uzávěrky ze dne: DD.MM.RRRR Vystavení dokladu datum vystavení dokladu Zaúčtování datum zaúčtování dokladu Splatnost datum splatnosti dokladu Vystaveno na OZ 5.5 Nahrávání plateb Nahrávání plateb je jeden ze základních procesů na BackOffice poradenské společnosti, který úzce souvisí s provizními listy a uzávěrkou. Celý 32

38 5. SPECIFIKACE A ANALÝZA proces začíná provizním reportem zaslaným od dodavatele, který obsahuje seznam plateb za sjednané obchody. Tento report se musí zkontrolovat vůči provizním listům, zda jsou platby v pořádku a nesprávně vyplacené obchody partnerem se odesílají na reklamaci. Tento proces je ovšem časově velmi náročný, neměnný a náchylný na lidské chyby, proto je důležité, aby byl zautomatizovaný systémem a probíhal formou kontroly pouze nesprávně vyplacených obchodů. Fáze nahrávání plateb: 1. Import plateb do systému 2. Přiřazení ke smlouvám 3. Kontrola plateb vůči provizním listům 4. Označení chybných plateb 5. Nahrání plateb do uzávěrky Zpracování provizních reportů Provizní reporty jsou zásílány dodavatelem v excelu. Jelikož každý dodavatel má jiný report, je potřeba vytvořit nástroj, který by se používal na BackOffice pro správu plateb, aby byl proces jednotný a nezáležel na partnerovi. Řešením je napsání Makra pro Microsoft Excel, která platby sjednotí do jednoho formátu a umožní lehce zpracovat reporty. Proces: 1. Překopírování reportu dodavatele do excelu s makry. 2. Vygenerování reportu v jednotného formátu z reportu dodavatele. 3. Generování importních scriptů do systému, formát platby je uvedený v tabulce Nahrávání chybných plateb ze systému a porovnání s určitým reportem, výsledek je nový report obsahující pouze dané chybné platby. 5. Označení reklamovaných plateb. 33

39 5. SPECIFIKACE A ANALÝZA Tab. 5.10: Formát platby Atribut Popis ID identifikace importované platby ID naklopení identifikace importu Dodavatel partner Kód textový řetězec identifikucíjí obchod EAN/EIC/ID Hodnota hodnota provize Procento procentuální ohodnocení vyplaceného obchodu OZ ID obchodního zástupce Typ určuje způsob kontroly plateb vůči provizním listům Datum datum zpracování platby Chybné platby Aby se lépe dohledávaly chyby, je potřeba při generování chybového reportu přidat informaci, udávající důvod neakceptování dané platby. Ty můžeme rozdělit do kategorií v tabulce Tab. 5.11: Chyby plateb Kód Chyba Popis 1 Špatný formát platby nevyplněná nebo chybná hodnota 2 Odběrné místo nenalezeno nenalezen párovací kód v systému 4 Smlouva nenalezena párovací kód nalezen bez smlouvy 8 Nalezeno více smluv více nevyplacených obchodů 16 Chyba v provizním listu chyba při výpočtu příchozí platby 32 Odlišná očekávaná provize chybně vyplacená provize 5.6 Smlouvy Evidence smluv je jednou z nejdůležitějších činností BackOffice společnosti zdůvodu: evidence klientů a jejich smluv, informování poradců o stavu smlouvy, kontrola uzavřených smluv, kontrola proplacenosti smluv, produkce struktur, 34

40 5. SPECIFIKACE A ANALÝZA zpracování smluv, validace a verifikace smluv, import smluv nových klientů, evidence smluv partnerů, evidence provizních listů ke smlouvám. A zároveň se jedná o časově nejnáročnější evidenční problematiku společnosti. Aby mohla být tato problematika řešena, je potřeba najít stavy smluv, které by kategorizovaly procesy u smluv. Dále smlouvy mohou být na mnoho produktů, je tedy potřeba systém navhrnout tak, aby bylo jednoduché přidat další produkt, vytvořit formuláře a snadno ho spojit s uzávěrkou a provizními listy. Seznam základních produktů: Elektřina Plyn Perlátory na vodu Individuální obchody Mobilní telefony Pojištění Zdravotní pojištění Aukce ajiné Stavy smluv Zprocesování smluv je zajištěno přiřazením stavu, ve kterém se nachází. Seznam stavů je uvedený v tabulce 5.12 a je určený procesem zpracování smlouvy na kancelářích a BackOffice. Názvy stavů se mohou měnit v závislosti na produktech, význam však zůstává stejný. 35

41 Tab. 5.12: Stavy smluv Kód Stav Popis 1 Nabídka vytvoření nabídky pro klienta 2 Nová vytvoření smlouvy z nabídky 3 Přijata BO verifikovaná smlouva 4 Vratka smlouva vrácená k opravě 5 Vpořádku aktivní smlouva 6 Storno ukončená smlouva chybou 7 Ukončená ukončená smlouva 8 Koš zahozené nabídky 5. SPECIFIKACE A ANALÝZA Obr. 5.4: Stavy smlouv- workflow 36

42 5. SPECIFIKACE A ANALÝZA Základní části smluv Analýza formulářů a evidenčích problémů ukázala, že každá smlouva se dá rozdělit do částí, které jsou kromě služeb téměř totožné. 1. Informace pro Backoffice Dodavatel smlouva daného partnera Balíček zařazení do balíčku partnera Provizní list mapování na provizní list Doba platnosti doba platnosti smlouvy Datum platnosti upřesňující doba platnosti Datum podpisu datum podpisu smlouvy Místo podpisu místo podpisu smlouvy Datum zatypování datum zatypování smlouvy Obchodník majitel obchodu Stav stav smlouvy 2. Info o procesování smluv žurnál Datum a čas kdy byla změna provedena Uživatel kdo provedl změnu Ze stavu původní stav smlouvy Do stavu nový stav smlouvy Popis textový popis důvodu změny 3. Přílohy 4. Klient Typ klienta Název název společnosti Jméno a příjmení jméno podnikatele, osoby IČ/datum narození Telefon 5. Trvalé bydliště a korespondenční adresa 37

43 5. SPECIFIKACE A ANALÝZA 6. Platební podmínky 7. Služby specifikace služeb na smlouvě Kód textový řetězec identifikucíjí obchod EAN/EIC/ID Množství Popis textový popis služby Vyhledávání smluv Aby práce s vyhledáváním smluv byla co nejjednodušší, musí mít aplikace při výpisu smluv aktivní základní filtr, který bude urychlovat práci zejména asistentkám a zaměstnancům na BackOffice. Pokročilé hledání bude zajištěno rozšiřujícím vyhledáváním. 1. Základní filtr Typ smlouvy jaký produkt se vyhledává Obchodník vybraný obchodní zástupce, který sepsal smlouvu Struktura vybraný obchodní zástupce s týmem Vytvořeno od datum vytvoření smlouvy od určitého data Vytvořeno do datum vytvoření smlouvy do určitého data Stav stav smlouvy 2. Rozšiřující vyhledánání Dodavatel smlouvy daného partnera Klient název klienta Kód obchodu identifikující kód Datum zatypování datum akceptace obchodu partnerem 38

44 5. SPECIFIKACE A ANALÝZA 5.7 Reporty Jednou z velmi důležitých funkcí IS pro ředitele a manažery jsou reporty, které jim poskytují důležité informace pro rozhodování. Pro poradce jsou zase důležitější seznamy jejich obchodů a informace o proplacenosti. Tyto data musí být přesná a odpovídat realitě, což je u některých reportů jako například WORKFLOW report obtížné. Zárověň jsme v sít ovém marketingu, takže generovaná data musí podléhat MLM struktuře. Požadavky na reporty: Snadno dostupné a lehce srozumitelné uživatelům IS Intuitivní vyplňování vstupních parametrů Generováníjak nastránkutakiexportdoxls Kontrola práv na data podle MLM struktury Určování práv na reporty podle pozice OZ i přímo danému uživateli Snadné vytváření reportů 39

45 5. SPECIFIKACE A ANALÝZA Manažerská statistika Základní report obsahující informace o obchodech, majiteli obchodu a výši provize. V tabulce 5.13 jsou uvedeny vstupní parametry reportu a v tabulce 5.14 výstupní hodnoty vegenerované sestavy. Tab. 5.13: Vstupní parametry Parametr Popis OZ vybraný obchodní zástupce ze struktury Struktura vybraný obchodní zástupce s týmem Dodavatel smlouvy daného partnera Stav stav smlouvy Klient fulltextové vyhledávání klientů Kód fulltextové vyhledávání obchodu EAN/EIC/ID ID smlouvy vyhledávání ID smlouvy Vytvořeno filtrování podle datumu vytvoření smlouvy Zatypování filtrování podle datumu zatypování smlouvy Tab. 5.14: Výstupní hodnoty Hodnota Popis ID smlouvy identifikační číslo smlouvy Stav stav smlouvy OZ obchodní zástupce(vlastník smlouvy) OZ - ID ID obchodní zástupce Dodavatel smlouva partnera Zákazník jméno klienta Kód řetězec identifikucíjí obchod EAN/EIC/ID Tarif tarif smlouvy Spotřeba spotřeba zákazníka Provize vypočítaná provize za smlouvu Body vypočítané body za smlouvu 40

46 5. SPECIFIKACE A ANALÝZA Produkce struktury Report obsahující informace o produkci obchodních zástupců a jejich týmů za určité období. Je to základní report pro určování povýšení/ponížení pozic obchodních zástupců. V tabulce 5.15 jsou uvedeny vstupní parametry reportu a v tabulce 5.16 výstupní hodnoty vegenerované sestavy. Tab. 5.15: Vstupní parametry Parametr Popis OZ vybraný obchodní zástupce ze struktury Struktura vybraný obchodní zástupce s týmem Stav stav smlouvy Vytvořeno filtrování podle datumu vytvoření smlouvy Zatypování filtrování podle datumu zatypování smlouvy Tab. 5.16: Výstupní hodnoty Hodnota Popis OZ obchodní zástupce(vlastník smlouvy) OZ - ID ID obchodní zástupce OZ - skupina skupina obchodního zástupce OZ - kancelář kancelář obchodního zástupce Smlouva- typ typ smluv Smlouva- stav stav smluv Počet smluv- OZ počet smluv obchodního zástupce Počet smluv- struktura počet smluv obchodního zástupce s týmem Provize - OZ suma provizí obchodního zástupce Provize - sruktura suma provizí obchodního zástupce s týmem Body- OZ suma bodů obchodního zástupce Body- struktura suma bodů obchodního zástupce s týmem 41

47 5. SPECIFIKACE A ANALÝZA Proplacenost smluv Report obsahující informace o produkci obchodních zástupců a jejich týmů za určité období. Je to základní report pro určování povýšení/ponížení pozic obchodních zástupců. V tabulce 5.17 jsou uvedeny vstupní parametry reportu a v tabulce 5.18 výstupní hodnoty vegenerované sestavy. Tab. 5.17: Vstupní parametry Parametr Popis OZ vybraný obchodní zástupce ze struktury Struktura vybraný obchodní zástupce s týmem Dodavatel smlouvy daného partnera Zatypování filtrování podle datumu zatypování smlouvy Tab. 5.18: Výstupní hodnoty Hodnota Popis Smlouva- typ typ smluv ID smlouvy identifikační číslo smlouvy OZ obchodní zástupce(vlastník smlouvy) OZ - ID ID obchodní zástupce Zákazník jméno klienta Datum zatypování datum akceptace smlouvy partnerem Kód řetězec identifikucíjí obchod EAN/EIC/ID Spotřeba spotřeba zákazníka Provizní list provizní list smlouvy Proplaceno vyplacené peníze Proplaceno- procenta procento vyplacených peněz 42

48 5. SPECIFIKACE A ANALÝZA Provize v uzávěrce Report obsahující informace o provizích v dané uzávěrce. V tabulce 5.19 jsou uvedeny vstupní parametry reportu a v tabulce 5.20 výstupní hodnoty vygenerované sestavy. Tab. 5.19: Vstupní parametry Parametr Popis OZ vybraný obchodní zástupce ze struktury Struktura vybraný obchodní zástupce s týmem Uzávěrka uzávěrka provizí Tab. 5.20: Výstupní hodnoty Hodnota Popis Pořadí provize pořadí provize dané platby Zákazník jméno klienta Kód kód smlouvy EAN/EIC/RČ Platba hodnota platby Platba - typ typ platby OZ obchodní zástupce(vlastník smlouvy) OZ - ID ID obchodní zástupce Provize - procenta procenta z platby Provize hodnota provize Provize - typ typ provize Vyplaceno- subjekt provize vyplacená na subjekt Vyplaceno- IČO IČO subjektu 43

49 5. SPECIFIKACE A ANALÝZA Obchodní zástupci Report obsahující základní informace o obchodních zástupcích struktury. V tabulce 5.21 jsou uvedeny vstupní parametry reportu a v tabulce 5.22 výstupní hodnoty vegenerované sestavy. Tab. 5.21: Vstupní parametry Parametr Popis OZ vybraný obchodní zástupce ze struktury Struktura vybraný obchodní zástupce s týmem Tab. 5.22: Výstupní hodnoty Hodnota Popis OZ obchodní zástupce OZ - ID ID obchodní zástupce Aktivní aktivní účet Skupina zařazení do skupiny Kariéra zařazení do kariéry Pozice přiřazená pozice Kancelář zařazení do kanceláře Nadřízený OZ sponzor obchodního zástupce Nadřízený OZ- ID ID sponzora obchodní zástupce Login login účtu Jméno jméno obchodního zástupce Příjmení příjmení obchodního zástupce Telefon telefon obchodního zástupce obchodního zástupce Subjekt vyplácení provize vyplacená na subjekt IČO IČO subjektu Plátce DPH informace o plátci DPH 44

50 6 Návrh a implementace systému Z důvodu ochrany know-how a důvěrných informací vlastněné společností ZEUS solutions, s.r.o., smluvního zavázání mezi ZEUS solutions, s.r.o. a Terra Group Investment, a.s. o ochraně know-how a osobních údajů podle zákona č. 101/2000 Sb. jsou v kapitole uvedeny vybrané části systému. Aplikační část uzávěrky je řešená pouze v databázi stejně jako generováním reportů a logování změn záznamů[14]. 6.1 Jádro Jádro ZISKu je postaveno na modelu Bell LaPadula, viditelnost objetků se řídí podle zařazení do struktury tak, že každý vidí své objekty a zároveň vše ve své podstruktuře. Práva na objekty jsou řešena na úrovni role přihlášeného uživatele. Z důvodu bezpečnosti má každý objekt v databázi vygenerované místo sekvenčního primárního klíče UUID pomocí funkce public.uuid_generate_v4() v databázi PostgreSQL. Obr. 6.1: ERD MLMstruktura Popis obrázku 6.1: Struktura je strom, u kterého každý uzel představuje obchodního zástupce. uuid: primární klíč 45

51 oz: ID obchodního zástupce jméno: název obchodního zástupce sponzor: nadřízený obchodního zástupce 6. NÁVRH A IMPLEMENTACE SYSTÉMU Uživatel je účet, pod kterým se uživatelé systému přihlašují. uuid: primární klíč struktura: cizí klíč, zařazení účtu do struktury login: přihlašovací jméno heslo: přihlašovací heslo role: cizí klíč, přiřazená práva aktivní: přiřazená práva mobil: mobilní číslo pro autentizační sms Role určuje práva na objekty. uuid: primární klíč Obchodník, Manažer, Ředitel, BackOffice, Admin, Superadmin, Reporty Objekty jsou ostatní objekty v systému závislé na struktuře. uuid: primární klíč struktura: cizí klíč, zařazení do struktury Viditelnost objektů U každých objektů, které jsou závislé na struktuře, se musíme dotazovat na viditelnost. Jedná se o náročný dotaz, který se stále opakuje. Možnosti implementace: 1. Jednoduchý Každý objekt má zařazení do strukuty, procházíme vybranou strukturu po jednotlivých uzlech a dotazujeme se na objekty. Vylepšením je použití structure IN (?,?,...) ve WHERE klauzuli SQL. Tento způsob je nevyhovující z důvodu výkonu databáze. 2. PATH Pro každý uzel ve struktuře generovat řetězec obsahující uuid všech uzlů podstruktury. Dotaz je structure LIKE %PATH% ve WHERE klauzuli SQL. Tento způsob je nevyhovující z důvodu zvětšujících se délky PATH při růstu struktur. 46

52 6. NÁVRH A IMPLEMENTACE SYSTÉMU 3. Rekurze Využití rekurze implementované v databázi. Tento způsob je nevyhovující z důvodu počtu objektů. 4. Trasování stromem U uzlů struktury ukládat ID levé části a pravé části při trasování. Trasování je procházení stromem do hloubky od kořene po nejlevější možné cestě. Tento způsob je náchylný na změny ve struktuře. 5. Odstranění rekurze - implementováno Vytvoření cache tabulek, které obsahují uzel ve struktuře, úroveň a uzel v podstruktuře/nadstruktuře. DotazjeINNERJOIN nacache tabulku strukuryvsql. Tento způsob je rychlý a změny ve struktuře nejsou náročné. Obr. 6.2: Vytvoření cache tabulky Obr. 6.3: Funkce pro odstranění rekurze 47

53 6. NÁVRH A IMPLEMENTACE SYSTÉMU Kariéra Kariéra musela být zahrnuta do jádra aplikace z důvodu vazeb mezi strukturou a kariérou. Obr. 6.4: ERD Kariéra Struktura představuje obchodního zástupce. skupina: cizí klíč, zařazení OZ do skupiny kariéra: cizí klíč, zařazení OZ do kariéry pozice: cizí klíč, zařazení OZ napozici Skupina je základním rozdělením struktur. uuid: primární klíč struktura: cizí klíč, zařazení skupiny do struktury Kariéra určuje způsob ohodnocování obchodních zástupců. uuid: primární klíč skupina: cizí klíč, zařazení do skupiny body: hodnota jednoho bodu v kariéře počítání provizí: způsob počítání provizí Pozice určuje vyplácení obchodního zástupce. uuid: primární klíč kariéra: cizí klíč, zařazení do kariéry procenta: ohodnocení pozice 48

54 6. NÁVRH A IMPLEMENTACE SYSTÉMU 6.2 Smlouvy Datový model smluv vychází z popisu domény na obrázku 6.5, zároveň je spojen s uzávěrkou přes produkty na smlouvě. Obr. 6.5: ERD Smlouvy Struktura představuje obchodního zástupce. Zákazník je fyzická nebo právnická osoba. uuid: primární klíč jméno: jméno organizace nebo osoby IČ/datum narození: identifikace zákazníka bydliště kontakt: , telefon Smlouva je smlouvní dokumentace obchodu. uuid: primární klíč struktura: cizí klíč, zařazení smlouvy do struktury zákazník: cizí klíč, zařazení smlouvy k zákazníkovi Produkty určuje předmět smlouvy. uuid: primární klíč smlouva: cizí klíč, přiřazení ke smlouvě kód: unikátní klíč, specifický řetězec produktu provize: výše provize za produkt 49

55 6. NÁVRH A IMPLEMENTACE SYSTÉMU 6.3 Strukutura aplikace Zde je popsaná struktura aplikace s moduly a podmoduly, na které se přiřazují práva k jednotlivým rolím. 1. Jádro levý slide-box a hlavička Ovládání jádra ZISKu(práce s MLM strukturou), viz obr. 6.8 Informování uživatele o pozici ve struktuře, viz obr Smlouvy 3. Lidé Rozdělení smluv do stavů a jejich vyhledávání, záznamy zobrazené podle vybrané MLM struktury, viz obr. 6.9 Editace části smlouvy: BackOffice, Smlouva, Elektřina, Plyn adozor,viz obr a6.11 Administrace obchodních zástupců, způsobu vyplácení, účtů abringerů,viz obr Reporty 5. Role Generování reportů za systému, viz obr Přiřazování práv na moduly s podmoduly jednotlivým rolím 6. Faktury Tiskové sestavy faktur pro obchodní zástupce z uzávěrek Obr. 6.6: Hlavička ZISKu 50

56 6. NÁVRH A IMPLEMENTACE SYSTÉMU Obr. 6.7: Evidence obchodního zástupce 51

57 6. NÁVRH A IMPLEMENTACE SYSTÉMU Obr. 6.8: Práce v MLM struktuře Obr. 6.9: Přehled smluv v určitém stavu 52