\documentclass[11pt,final,oneside]{fithesis} % až budu chtít vysázet finální verzi, změním draft na final \usepackage{url} %\usepackage[plainpages=false, pdfpagelabels, colorlinks]{hyperref} \usepackage{czech} \usepackage{color} \usepackage{colortbl} \usepackage{graphicx} %\usepackage[unicode=true, colorlinks]{hyperref} % Pokud se překládá do PDF... % \pdfpkresolution1200 % Rastrové fonty do výstupního PDF vkládat v rozlišení % 1200 DPI. \usepackage[protrusion,expansion,step=1]{microtype} % Balík umožňující % používat zavěšování interpunkce % a expanzi fontů při překladu % pdf(CS)LaTeXem. \usepackage[pdftex=true, unicode=true, plainpages=false, pdfpagelabels=true, pdfborder={0 0 0}, pdfpagemode=UseNone, pdfstartview={XYZ null null 1}, pdfpagelayout=OneColumn, pdfdisplaydoctitle=true, bookmarks=true, bookmarksopen=true, bookmarksopenlevel=1, bookmarksnumbered=true ]{hyperref} % Balík pro podporu hypertextových odkazů. Měl by % být přidaný až jako poslední, protože redefinuje % větší množství základní příkazů a mohlo by tak % docházet ke konfliktům s jinými balíky. \thesistitle{Informační systémy \\ s~podporou CRM} \thesissubtitle{Magisterská práce} \thesisstudent{Petr Hauzar} \thesiswoman{false} \thesisfaculty{fi} \thesisyear{Květen 2010} \thesisadvisor{RNDr. Pavel Hajn} \thesislang{cs} \bibliographystyle{plain} \hypersetup{% pdfauthor={Petr Hauzar}, pdftitle={Informacni systemy s podporou CRM}, pdfsubject={Informacni systemy s~podporou CRM}, pdfkeywords={CRM, Customer Relationship Management, information system, IS, rizeni vztahu se~zakazniky, informacní system, Ruby, Ruby on Rails} } % Nastavení metadat pro PDF soubor. \begin{document} \FrontMatter \ThesisTitlePage \begin{center} \scalebox{.70}{ \includegraphics{zadani.png} } \end{center} \begin{ThesisDeclaration} \DeclarationText \begin{flushright} V Brně, \today{}\\ Petr Hauzar \end{flushright} \AdvisorName \end{ThesisDeclaration} \begin{ThesisThanks} Na~tomto místě bych rád poděkoval RNDr. Pavlu Hajnovi, že byl ochoten vést tuto práci a za~jeho připomínky. Dále pak své matce Zdeňce Hauzarové a dalším členům rodiny. \end{ThesisThanks} \begin{ThesisAbstract} Cílem práce je zmapovat problematiku Customer Relationship Management systémů, podchytit jejich základní vlastnosti a požadavky na~funkčnost takových systémů, následně pak navrhnout obecné principy pro~vytvoření CRM\footnote{CRM je běžně užívaná zkratka pro~Customer Relationship Management} systému. Dále zanalyzovat a~popsat současný systém pronajímání apartmánů v~USA, zanalyzovat chod a~potřeby konkrétní firmy, která se zabývá pronájmem apartmánů. Na~základě této analýzy a~v~souladu s~principy pro~vytvoření CRM vytvořit vhodný IS s~podporou CRM pro~uvedenou firmu. Modul CRM vytvořeného ISu by měl pokrývat oblast marketingu, získávání nových nájemníků a~vyhodnocování jejich spokojenosti. \end{ThesisAbstract} \begin{ThesisKeyWords} CRM, Customer Relationship Management, information system, apartment, IS, řízení vztahů se~zákazníky, informační systém, Ruby, Ruby on Rails \end{ThesisKeyWords} \tableofcontents \MainMatter \chapter{Úvod} \label{chap:uvod} \begin{flushright} Motto: \uv{Nastavení firemní struktury a procesů musí \\reflektovat skutečnost, že firmu živí zákazníci}.\\ \cite[strana 62]{chleb1} \end{flushright} Zhruba od~konce roku 2007 celým světem zmítá v médiích často zmiňovaná tzv. ekonomická krize. Ta více či méně postihuje národní ekonomiky, nejrůznější podnikatelské subjekty působící v~tržním (konkurenční) prostředí jsou vystaveni tlakům, které plynou právě z~takového konkurenčního prostředí, mnohem více než dříve. Ne zřídka se můžeme doslechnout či dočíst, že další podnik ukončil svoji činnost nebo je ve~velmi vážných problémech. Čili lze říci, že ikdyž krize byla odstartována v~bankovním sektoru, netrvalo příliš dlouho a rozlila se prakticky do~všech hospodářských odvětví. Kromě toho, že firmy najednou pracují s~velmi omezenými finančními prostředky, pociťují i~další důsledek krize -- pro~podnikatele je velice obtížné získávat nové zákazníky. Naopak velice často se stává, že lehce ztrácejí ty současné. Drtivá většina zákazníků se totiž snaží především šetřit své finanční prostředky a omezují své výdaje tam, kde to je jen trochu možné. Firmy by se tedy měly snažit vyjít co nejvíce vstříc alespoň svým současným zákazníkům, aby jim neposkytly důvod od~nich odejít a mohly tak s~nimi i~nadále rozvíjet oboustranně výhodnou obchodní spolupráci. To totiž může být pro~firmu klíčovou záležitostí, která může znamenat její přežití či pád. Takovému aktivnímu vystupování vůči svým klientům se říká řízení vztahů se~zákazníky. Společnostem, které uplatňují takové řízení vztahů ke~svým zákazníkům, se říká zákaznicky orientované. Samozřejmě není možné tvrdit, že by zákaznicky orientovaný přístup vznikl v~době současné světové krize nebo dokonce díky ní. Lze si totiž všimnout, že společnosti začínají klást důraz na~aktivní přístup k~zákazníkům v~posledních zhruba patnácti až dvaceti letech. Dopomáhá tomu široký rozmah dostatečně výkonných informačních technologií. Tyto systémy pak podporují efektivní zpracování obrovského množství dat, což umožňuje získávat potřebné informace buď v~dostatečně krátkém (či ideálně reálném) čase. Na tomto základě tedy mohou podnikatelské subjekty vytvářet dlouhodobé oboustranně výhodné vztahy nejen se~zákazníky, ale například i~s~odběrateli. Tyto vztahy jsou pak vnímány jako určitá konkurenční výhoda. \chapter{Přes marketing k CRM} \label{chap:marketing} \section{Historie} S~mou původní povrchní znalostí jsem měl pocit, že nejdříve byl marketing a z~něj pak vychází řízení vztahů se~zákazníky. Tedy na řízení vztahů v~současném moderním pojetí je možno nahlížet jako na~další evoluční krok marketingu, nicméně něco takového už tu kdysi bylo. Do~19. století, tedy v~době před~industrializací, pracovali řemeslníci ve~svých dílničkách, řemeslo se předávalo z~otce na~syna, resp. z~mistra na~učedníka. Roli tedy hrála tradice a kontinuální předávání cenných znalostí. Dílnu vedli vždy mistři -- profesionálové, kteří řídili všechny procesy spjaté s~chodem takového podniku. Od~nákupu materiálů od~dodavatelů, přípravu materiálu k~výrobě, samotnou výrobu a následně předání produktu svému zákazníkovi. Oni totiž své zákazníky znali, velice často osobně. Takže věděli nebo mohli dobře odhadnout, co jejich zákazník požaduje a jaké jsou jeho potřeby. Ačkoli si tyto údaje ve~většině případů pamatovali jen tak z~hlavy, rozhodně se dá hovořit o~jakémsi řízení vztahů k~zákazníkům. Snažili se maximálně vyhovět přesně jejich přáním, vždyť to byla jejich osobní vizitka. Toto je ale jen popis vztahu dodavatele ke~konečnému spotřebiteli. Avšak vytváření a udržování dobrých obchodních vztahů bylo prioritou také i~mezi samotnými živnostníky. Ti si totiž celkem dobře pamatovali i to, kdo jim dodal kvalitní zboží za~dobrou cenu a naopak. V manufakturách, a dále pak především s~příchodem průmyslové revoluce, se výrobní procesy výrazně změnily. S~objevením nových zdrojů energie (vynález parního stroje) se také objevily sériové a masové výroby. Viditelná změna byla například v tom, že dělníci v~takových továrnách už rozhodně do~styku se~zákazníkem nepřišli, takže oni sámi ani nebyli schopni určit, co zákazník potřebuje. Další změnou pak byla neschopnost přirozené poptávky pojmou vše, co se (efektivněji než dříve) vyrobilo. To dalo vzniknout útvarům, které se nejdříve zabývaly jen samotnou distribucí produktů, později pak hledaly možné zákazníky pro~své výrobky a služby. Těmto činnostem se pak začalo říkat marketing. V~takové továrně pak ale de facto všichni ztratili kontakt se~zákazníkem. Snad jen samotní prodejci mohli říci, že se setkávají se zákazníkem. Ti však jen nepatrně ovlivňovali řízení výroby, tedy pokud vůbec. Jak ale Storbacka a Lehtinen \cite[strana 16 ]{jarmo1} uvádějí, v~80. letech minulého století se pak situace začala opět měnit, jakoby zpět k~původním konceptům. Samotná oddělení v~organizaci měla být v~určitém kontaktu se~zákazníky. To mělo napomoci lépe porozumět požadavkům zákazníků. \section{Marketing a jeho typy} Marketing je slovo původem z~angličtiny, skládá se ze~dvou částí. Základem je market jako obchod a přípona -ing značící děj či probíhající akci, což je docela trefné. Existuje celá řada definic, zde uvádím definici dle Chlebovského \cite[strana 7]{chleb1}: \begin{quote} \clqq \textbf{Marketing} je společenský a řízený proces, kterým jednotlivci a~skupiny získávají to, co potřebují, prostřednictvím tvorby, nabídky a směny hodnotových produktů s ostatními\crqq. \end{quote} V~této definici je zmínka o~zákazníkovi a jeho potřebách, nicméně není to pravidlem, v~jiných definicích o~zákazníkovi není ani slova. Například podle Geffroye \cite[strana 15]{protivnik}: \begin{quote} \clqq \textbf{Marketing} je podle definice zaměření dílčích podnikových úseků na~odbytovou politiku a na~zvýšení odbytových možností\crqq. \end{quote} V~kontextu této práce je to zajímavý aspekt, v~praxi se totiž skutečně zákazníkem téměř nikdo nezabýval. Chlebovský \cite{chleb1} pak dále dělí marketing na tři základní typy. \begin{itemize} \item \textbf{Historický marketing} Organizace, které se drží tohoto způsobu vedení marketingu, vyrábějí to, co vyrobit umějí. \item \textbf{Klasický marketing} Základem je tzv. marketingový mix, což je jen slovní název pro 4P: \begin{itemize} \item \textbf{P}roduct - výrobek \item \textbf{P}rice - cena \item \textbf{P}lace - místo \item \textbf{P}romotion - propagace \end{itemize} Jedná se zatím o~nejběžnější formu formu marketingu.\\ \item \textbf{Moderní marketing} Tento způsob vedení marketingu se začal využívat v~posledních dvaceti třiceti letech.\footnote{Sám Chlebovský není ve~svých pracech jednotný, viz \cite[strana 12]{chleb1} \cite[strana 6]{chleb2}. Lehtinen a Storbacka však hovořili o~rozvinutí marketingu služeb již v~80. letech. \cite[strana 16]{jarmo1}} Změny jsou zachyceny v~následující tabulce. \\ \begin{figure}[ht] \begin{center} \scalebox{.45}{ \includegraphics{kop1.pdf} } \end{center} \caption{Změna podnikového prostředí.} \label{obr.zmena_pp} Zdroj: \cite{konference1}. \end{figure} Oproti klasickému marketingu se zde klade větší důraz na~orientaci~k~zákazníkovi. Proto se o~moderním marketingu mluví jako o~vztahovém marketingu. Základní kameny jsou 3C: \begin{itemize} \item \textbf{C}ustomer benefits - prospěch zákazníka \item Total \textbf{C}ustomer Cost - celkové náklady spojené s nákupem \item \textbf{C}onvenience - pohodlí zákazníka \end{itemize} \begin{figure}[ht] \begin{center} \scalebox{.50}{ \includegraphics{iev-mar.png} } \end{center} \caption{Vztahový marketing} \label{obr.marketing} \end{figure} \end{itemize} % >> Konec typů marketingu << Pro~úplnost vysvětlím další pojmy použité v~obrázku \ref{obr.marketing}. Interním marketingem se chápe např. vzdělávání a motivování pracovníků, komunikace s~managementem a ostatními zaměstnanci, prezentace firemních cílů a strategií. Externí marketing pak chápeme jako prezentaci organizace vůči okolnímu světu (typicky zákazníkům). Do~vztahového marketingu patří řada konceptů, v~této práci se však nadále budu zabývat pouze jedním z~nich. Tím je \textbf{řízení vztahů se~zákazníky}. \section{Customer Relationship Management} \label{def.crm} Řízení vztahů se~zákazníky se anglicky nazývá \textbf{C}ustomer \textbf{R}elationship \textbf{M}anagement. Dále v~tomto textu budu používat především zažitou zkratku \textbf{CRM}. Kromě motivací, které jsem již uvedl, se lze odkázat i~na~další, proč se CRM zabývat. Potřebu zesílit vztahy se~zákazníky dokazuje i~článek v~oddílu Byznys magazínu ComputerWorld \cite{compworld2}, ve~kterém se mimo jiného píše: \begin{quote} \clqq Kvůli nespokojeným zákazníkům přicházejí ročně tuzemské firmy na~tržbách o 19,3 miliardy korun. Částka představuje neuskutečněné nákupy, které by jinak spokojený spotřebitel u~firmy provedl.\crqq \end{quote} Tedy jedná se skutečně o~obrovskou částku a to se přitom mluví pouze o~České republice. Jak uvádí Lehtinen a Storbacka \cite{jarmo1}, společnost je orientovaná na~zákazníka, když ve~všech svých procesech v~největší míře zohledňuje aktuální potřeby svého zákazníka. Někdy se také užívá označení, že společnost je řízená zákazníkem. Dále pak, že cílem CRM je budovat a především kultivovat obchodní vztahy (k~zákazníkům) tak, aby se tak dosáhlo zvýšení jejich hodnoty a ziskovosti. Přesná definice CRM je dle Chlebovského \cite[strana 23]{chleb1} následující: \begin{quote} \clqq \textbf{CRM} je interaktivní proces, jehož cílem, je dosažení optimální rovnováhy mezi firemní investicí a uspokojením zákaznických potřeb. Optimum rovnováhy je determinováno maximálním ziskem obou stran.\crqq \end{quote} Při~striktním uplatnění CRM dojde v~podniku k~rozsáhlým organizačním změnám -- v~zodpovědnostech, výkaznictví, systému kontroly a v~dalších podnikových procesech. Na~základě toho, co už jsem uvedl a co uvádí Chlebovský \cite[strany 23, 24]{chleb1}, lze uvést čtyři nutné požadavky na úspěšné zavedení moderního CRM v~podniku: \begin{itemize} \item všichni zaměstnanci podniku se musí aktivně zúčastnit \item optimalizace procesů (např. integrace marketingu, podpory a prodeje v~jeden celek) \item výkonné technologie, ty umožňují oslovit velký počet zákazníků \item sběr, uchovávání a vyhodnocování dat (čas je kritický požadavek) \end{itemize} Původní marketingová koncepce segmentace trhu\footnote{Segmentace se chápe jako proces rozdělování zákazníků (i potenciálních) do~samostatných skupin na~základě shodných potřeb (pro~více informací viz například na~\cite{system1}). Protože každý zákazník může mít jiné potřeby, zjemňování pak může jít na samostatné zákazníky.} je v~myšlence CRM v~ideálním případě každý jednotlivý potenciální zákazník. Tyto tržní segementy pak pochopitelně musí splňovat alespoň minimálně podnikové cíle a musí být dosažitelné v~rámci rozumných nákladových parametrů (samozřejmě k~nim musí mít podnik přístup) \cite[strana 7]{burnett1}. Tyto segmenty je pak nutné přesně identifikovat a analyzovat, tzn. zaznamenat identifikační údaje o~zákazníkovi (jméno, příjmení, adresa...) a pak zjistit a porozumět jeho požadavkům a potřebám. To je však jen malá část nezbytných aktivit, následně je totiž nutné vytvořit odpovídající výrobky a služby, které pak klientské potřeby naplní. Jestliže se nějaká organizace rozhodne pro~CRM, pak patrně začne od~svých klíčových zákazníků. Ti jsou samozřejmě nejvýznamnější, takže jsou přirozeně první na~řadě, které si bude organizace hýčkat možnostmi CRM. Takovému systému se pak anglicky říká Key Customer Relationship Management -- \textbf{KCRM}.\footnote{Strategie použitá v~obecném CRM může být odlišná od~strategie pro~klíčové zákazníky, resp. KCRM může být striktnější, důslednější.} Typicky lze vidět tento přístup v~oblasti bankovnictví, významní zákazníci mající mnoha milionové účty jsou bankou náležitě hýčkáni. \subsection{Fáze vztahu} % ****************** ZAČÁTEK Fáze vztahu ************** \label{faze.vztahu} Vztahy vzniknout mohou, ale skončit musí. Vztah podniku s~jeho zákazníkem se běžně rozděluje na~několik fází, typicky se jedná o~vznik vztahu přes jeho rozvíjení až po~ukončení. Často se uvádí pojem životní cyklus zákazníka\footnote{Anglicky Customer Lifecycle}. Dá se říci, že se původně marketing zaměřoval jen na~získání zákazníků, tedy na~první fázi vztahu se~zákazníkem, nic víc. Druhá fáze bývala často podceňována (motto \uv{zákazníka jsme získali, proč se jím dále zabývat}). Mnoho organizací pak poslední fázi (ukončení vztahu) nebrala v~úvahu vůbec. Jak už bylo zmíněno výše, majoritní fáze jsou tři: \begin{itemize} \item \textbf{1. fáze: navázání vztahu} V~této fázi se sjednávají smlouvy a dohody, často neformálně (například když zákazník přijde do~obchodu a prodavačka ho pozdraví, alespoň jen pokynutím hlavy). Na~základě čeho však vůbec vztah započne je nejčastěji pro~zákazníka zajímavá informace a nejlépe z~důvěryhodného zdroje. K~informovanosti slouží například marketingové kampaně. V~zákaznickém přístupu organizace se však na~zákazníka nepohlíží jako na~pasivního příjemce reklamních informací, naopak se očekává intenzivní dialog. \begin{table}[htbp] \centering \begin{tabular}{|c|c|c|} \hline \multicolumn{3}{|c|}{\bfseries Vazby vznikající na základě} \\ \hline \bfseries jednání & \bfseries informací & \bfseries emocí \\ \hline produkty nebo procesy & zákony a smlouvy & sociální vztahy \\ geografické umístění & technologie & hodnotová kompatibilita \\ časová omezení & know-how & ideologická kompatiblita \\ \hline \multicolumn{3}{|c|}{\bfseries znamenají místo/podíl v~zákazníkově} \\ \hline \bfseries peněžence & \bfseries mysli & \bfseries srdci \\ \hline \end{tabular} \caption{Vznik vazeb vztahů a jejich význam} \end{table} \item \textbf{2. fáze: rozvíjení vztahu} Ideálně by se v~této fázi měl vztah prohlubovat a dojít tím k~růstu hodnoty tohoto vztahu. Vztah mimojiné znamená oboustrannou výměnu zdrojů a to vede k~tvorbě přidané hodnoty. Vztah by se měl upevňovat, protože jen pevný přetrvá i menší problémy. Čím dál častěji se ukazuje \cite[strana 85]{jarmo1}, že spokojenost zákazníka je nutná nikoli postačující podmínka. \item \textbf{3. fáze: ukončení vztahu} Zřejmě nejpodceňovanější fáze. Vztah jednou skončí, otázkou ale bývá proč. Důvod ukončení je nutné zevidovat, zanalyzovat a následně si z~něj vzít ponaučení. Podobně je potřebné zjistit, jakou ukončený vztah měl hodnotu a tedy jakou ztrátu to znamená pro~organizaci. \end{itemize} \begin{figure}[ht] \begin{center} \scalebox{.70}{ \includegraphics{faze_vztahu.png} } \end{center} \caption{Fáze vztahu} \label{obr.fazeVZTAHU} \end{figure} Často platí, že finančně nejnáročnější je právě první fáze, jinými slovy získat nového zákazníka. V~praxi má paradoxně největší pozornost, je běžné, že péče o~zákazníky (druhá fáze vztahu) má naopak malou pozornost a přitom stávající zákazník již organizaci přináší hodnoty, což se o~tom potenciálním říci nedá. K~fázi rozvíjení vztahu Lehtinen a Storbacka \cite{jarmo1} konstatovali toto: \uv{Aby k~nárůstu hodnoty vztahu skutečně došlo, musí společnosti soustředit více zdrojů na~fázi rozvíjení vztahu nežli na~fázi jeho zrodu}. Na~obrázku \ref{obr.fazeVZTAHU} jsou ilustrovány tři fáze vztahu. Jednotlivé fáze jsou zaznamenány v~modrých kroužcích. Lze si všimnout, že do~fáze 1. vedou dvě šipky, z~toho jedna šipka zvenčí. Ta značí příchod zákazníka ke~společnosti. Z~fáze 3. vedou dvě šipky, z~toho jedna vede ven. Ta naopak značí definitivní odchod\footnote{Každý odchod zákazníka od~společnosti je \uv{definitivní}, dokud se nevrátí. Možná je to úsměvné, ale takto se na~záležitost pohlíží.} zákazníka od~společnosti. Bod 4. označuje šipku (nikoli fázi). To je situace, kdy zákazník sice původní vztah již ukončil, ale po~čase se opět ke~společnosti vrátil. % ****************** KONEC Fáze vztahu ************** \subsection{Cíle zavádění CRM} % ****************** ZAČÁTEK Cíle zavádění CRM ************** Samotná realizace zavádění CRM v~sobě může zahrnovat strategie vedoucí k~různým cílům \cite[strany 11, 12]{burnett1}, často se jedná o: \begin{itemize} \item \textit{rozšíření podnikání o~nový výrobek}\\ Zákazníci mohou dokonce přímo spolupracovat na~návrzích nových výrobků či služeb, což může vést k~úspoře nákladů. \item \textit{zvýšení přidané hodnoty}\\ Produkt poskytuje zákazníkovi přidanou hodnotu a tu by pak měl také vnímat a ocenit. \item \textit{získání vedoucí postavení na~trhu}\\ Staví na~myšlence vedoucí postavení na~trhu = podíl na~trhu = objem prodeje = nejnižší jednotkové náklady. Ty totiž mohou být onou konkurenční výhodou. \item \textit{rozptýlení rizika a snížení zranitelnost podniku}\\ Pokud je organizace závislá na~jednom dvou odběratelích a sezónnost poptávky, koncepci CRM lze použít jako prostředek pro~rozšíření klientské základny. \item \textit{udržení stávajících zákazníků}\\ Stávající zákazník není jistota statického charakteru, takže si zaslouží stejnou péči (či dokonce lepší) než noví zákazníci. \item \textit{odrážení útoků konkurence}\\ Těsný vztah se~zákazníky znamená schopnost čelit konkurenci, jejich snahy získat naše zákazníky vycházejí naprázdno. \item \textit{řešení operativních problémů}\\ Například pokud se zákazník nachází mimo podnikový region, pomocí CRM lze řídit prodej, cenotvorbu, klientský servis, distribuci. \end{itemize} Obecně platí, že CRM se hodí pro~podniky zabývající se prodejem zboží nebo služeb (tím ovšem neříkám, pro~jaké typy se nehodí). Přínosy zavedení CRM samozřejmě závisí na~nejrůznějších faktorech, které je třeba zmapovat. K~tomu slouží různé metody, ty ale jsou již mimo vytyčené téma této práce. % ****************** KONEC Cíle zavádění CRM ************** % ****************** ZAČÁTEK Strategie CRM ************** \subsection{Strategie CRM} \label{crm.strategie} Zákazníci nejsou stejní, naopak jsou různí. Různé jsou jejich požadavky a potřeby, ale také očekávání od~svého dodavatele. Je nutné rozlišit jednotlivé vztahy k~zákazníkům a používat pro~ně různé procesy. Zvolení strategie CRM k~jednotlivým zákazníkům jasně a přehledně stanovuje \uv{pravidla hry}, jasně vymezuje role organizace i~zákazníka. Strategie vlastně určuje, jakým způsobem z~dlouhodobého hlediska přitáhnout organizaci zdroje zákazníka. Každý vztah se~zákazníkem si pochopitelně vyžaduje jistou investici s~tím, že se následně a~zcela přirozeně očekává její (zúročený) návrat. V~ekonomii se o~tomto tématu hovoří jako o~návratnosti vztahu (angl. Return On Relationship, zkratka ROR\footnote{V~této práci se taktéž věnuji frameworku Ruby On Rails se stejnou zkratkou. Pokud se v~textu kdekoli jinde objeví zkratka RoR, má se na~mysli právě Ruby On Rails.}). Často se definuje něco jako průměrný nebo typický klient. Přirozeně pak následuje volba obecné strategie, která má za~cíl pokrýt celou zákaznickou základnu (či její větší část). Taková generická strategie je pak tvořena těžkopádnými a komplikovanými procesy, které ve~finále neocení nikdo. Typicky pak vyhrazuje zdroje organizace zákazníkům, které je nevyužijí, nebo naopak nepřidělí zdroje zákazníkovi, který je potřebuje. Strategie by měla být customizována pokud možno pro~každého zákazníka extra a být tedy jedním z~rozhodovacích prvků pro~přidělování zdrojů. V~zásadě existují tři typy strategií CRM (Lehtinen, Storbacka \cite{jarmo1}): \begin{itemize} \item \textbf{strategie sponky -- sepnutí}\\ V~tomto typu se v~prvé řadě přizpůsobuje zákazník, ten upravuje své procesy tak, aby vyhovovaly organizaci. Jestliže se organizace snaží vyjít zákazníkovi maximálně vstříc, tento typ strategie není zcela ideální. \item \textbf{strategie zdrhovadla -- propojení}\\ Zde přizpůsobují své procesy jak zákazník tak i~organizace. Tento způsob vedení vztahu je však časově velice náročný, procesy se musí analyzovat a ladit na~obou stranách. \item \textbf{strategie suchého zipu -- přimknutí}\\ Organizace je ta strana, která mění své procesy a přizpůsobuje je procesům zákazníka. Pro~zákazníka je tento typ nejpohodlnějším řešením, nemusí se svými procesy dělat takřka nic. \end{itemize} Strategie k~zákazníkům je velice široké téma, které je mimo záběr této práce. Je zde však zmíněno pro~pochopení souvislostí, které bude vhodné později podchytit. % ****************** END Strategie CRM ************** \chapter{CRM systémy} \label{def.crm-systemy} Jak jsem již naznačil, celou oblast CRM v~organizaci tedy nelze jednoduše zúžit jen na~nějaký softwarový nástroj, ten je jen jakýmsi podpůrným elementem. Na~druhou stranu ale určitě platí, že v~dnešní době je využití IT pro~CRM kritickou záležitostí, bez těchto pokročilých technologií už to efektivně nejde. Pokud se teď omezím na~českou republiku a malé a středně velké podniky, pak informační systém je chápán především jako elektronický systém pro~vedení účetnictví, v~lepším případě doplněné o~nějaké specializované moduly. Do~určité velikosti firmy (ve smyslu počtu jejích zákazníků, velikost obratu, počtu zakázek) to nevadí, vlastně je to většinou naprosto dostačující. Takové systémy pak samozřejmě nezahrnují žádné nástroje pro~marketing, natož aby podporovaly plnohodnotné CRM. Podporu CRM nejčastěji supluje nějaký jednoduchý adresář s~primitivními funkcemi pro~správu kontaktů. Primitivní ze~dvou důvodů: za~prvé nejsou vůbec nutné tak složité funkce a za~druhé často v~těchto malých firmách ani nejsou lidské zdroje, které by jich byly schopné využít. Ovšem s~tím, jak firma roste, pak také roste nutnost přejít na~vyšší a sofistikovanější řešení. Systémy CRM (záměrně vynechávám slovo elektronické) se v~čase vyvíjely, na~začátku totiž stály ne-elektronické systémy. Jedním z~nich byla papírová kartotéka. Třeba taková, kterou byl pacient zvyklý vídat u~svého ošetřujícího lékaře. Klasická případ vypadal tak, že se sestřička zeptala na~jméno pacienta, pak přistoupila ke~skříňce, ve~které začala mezi dalšími zdravotními papírovými kartami pacientů hledat tu správnou. Postupem času se však situace významně změnila, s~příchodem výpočetní techniky přišly i softwarové adresáře. Typickým zástupcem je například program Outlook ze~sady MS Office. Outlook obsahuje nejen adresář, ale i~kalendář s~plánovačem, svou roli hrály i~další programy z~balíku MS Office. Pak přišly zajímavější programy pro~správu času a kontaktů, jednalo se už o~jakési informační systémy, které umožňovaly konkurenční přístup více uživatelů a jednodušší sdílení informací o~zákazníkovi. Rozsáhlé organizace, které to s~CRM myslí vážně, si pochopitelně nevystačí pouze s~jednoduchou správou kontaktů. Jsou nuceny využít mnohem lepší a výkonnější podporu CRM v~systémech, nejlépe takovou, kterou poskytuje současný technologický vrchol.\\ Pro~zajímavost uvádím přehled největších společností na~světovém trhu s~CRM. Údaje zveřejnila společnost Gartner.\footnote{Jedná se o~data získaná studií světového trhu CRM systémů za~rok 2008 \cite{gartner1}, zveřejněná v~červenci 2009.}\\ \begin{table}[htbp] \centering \begin{tabular}{|l|c|c|} \hline \textbf{Společnost} & \textbf{Zisk} & \textbf{Podíl na~trhu \%} \\ \hline SAP & 2,055 & 22.5 \\ Oracle & 1,475 & 16.1 \\ SalesForce.com & 965 & 10.6 \\ Microsoft & 581 & 6.4 \\ Amdocs & 451 & 4.9 \\ Ostatní & 3,630 & 39.6 \\ \hline \textbf{Celkem} & \textbf{9,147} & \textbf{100.0} \\ \hline \end{tabular} \caption{Zisky a podíly největších společností s~e-CRM za~rok 2008 (v~mil. US dolarů)} \end{table} CRM systémy využívající informační technologie se také uvádějí jako e-CRM\footnote{e-CRM je někdy uváděn jako eCRM} nebo CRM e-systémy. Ty nejnověji zahrnují i~využití mobilních zařízení, značí se m-CRM\footnote{m-CRM je někdy uváděn jako mCRM}. Z~osobní zkušenosti se s~m-CRM setkávám například u~e-shopu Cybex. Jestliže je zboží připraveno k~osobnímu odběru, automaticky mi přijde na~mobilní telefon upozorňující sms zpráva. Dodavatel tak na~své prodejně nemusí mít obrovské skladové prostory a zároveň zákazník je spokojen, když je ihned informován. Ten totiž nemusí díky své nevědomosti čekat déle, než je nezbytně nutné. \section{Informační oblasti podniku} \label{crm.infooblasti} Organizace pracují s~obrovským množstvím informací, které spolu nějakým způsobem souvisí. Podle těchto souvislostí lze podnik (v~kontextu CRM) rozdělit na~dvě základní informační oblasti. \begin{itemize} \item \textbf{Back-Office}\\ Oblast zahrnující činnosti podniku jako například výroba, nákup, řízení zásob, řízení lidských zdrojů, finance. Systémy určené pro~tuto informační oblast se jednotně nazývají ERP (Enterprise Resource Planning), tedy česky plánování zdrojů podniku. Pro~zákazníka interagujícího s~podnikem by měla být tato oblast skrytá a netransparentní. Není důvod, aby ji viděl. \item \textbf{Front-Office}\\ Na~rozdíl od~back-office je tato oblast podniku pro~vnější okolí podniku transparentní, zahrnuje totiž procesy spojené s~řízením vztahů se~zákazníky. Nejčastěji se jedná o~kanceláře, kam zákazníci mohou fyzicky přijít a tváří v~tvář hovořit se zástupci podniku. Dále pak telefonické centrum, webové rozhraní na~internetu, e-mailová komunikace, či komunikace poštou. Právě sem patří systémy CRM. Tato oblast vyžaduje podporu tří (někdy bývají zmiňovány čtyři) typů automatizací vnějších vztahů. A~protože systémy CRM mají plně pokrýt tuto oblast, jsou tyto automatizace vnějších vztahů shodné s~požadavky na~funkcionalitu CRM systémů. Zmíněné požadavky jsou zachyceny níže (v~podkapitole \ref{pozadavky}). \end{itemize} \begin{figure}[ht] \begin{center} \scalebox{.70}{ \includegraphics{FrontOffice.png} } \end{center} \caption{Informační oblasti podniku} \label{obr.informacnioblasti} \end{figure} V~ideálním případě jsou informace o~zákazníkovi soustředěny do~jednoho zákaznického záznamu\footnote{Jedním zákaznickým záznamem je myšlen soubor dat vztahující se k~danému zákazníkovi. Nejde tedy o~pouhou jednu položku v~tabulce.}, který je spravován (aktualizován) pracovníky Front-Office. Ale (v~korespondenci s~tím, co jsem psal už výše) přístup k~tomuto záznamu by měl být možný z~jakéhokoli funkčního úseku podniku. Jde totiž o~to, aby nebyly různé záznamy patřící jednomu konkrétnímu zákazníkovi uloženy na~více místech v~různých databázích. Například by bylo zcela zbytečné, kdyby jeden dodavatel podniku byl zároveň i~odběratelem a příslušná data byla uložena v~různých databázích jako samostatné záznamy a nebyly proti sobě v~žádné vazbě. Hledání v~takových datech a získat tak všechny souvislosti je potom naprosto frustrující, těžkopádné a zdlouhavé. O~efektivní a rychlé aktualizaci takových záznamů ani nemluvě. \section{Požadavky na~funkčnost} \label{pozadavky} Základní požadavky kladené na~tyto systémy bývají v~zásadě vždy stejné, spíše se liší pohled na~ně. Jestliže se bude jednat o~generický software, pak jsou podniky, které je hodlají implementovat, nuceny využít tento software tak, jak by vytvořen. Dále existují upravitelná (někdy se uvádí customizovatelná) řešení, například od~společnosti SAP či Oracle, u~kterých samozřejmě musí (resp. měl by) proběhnout proces tzv. customizace\footnote{Customizace znamená modifikace stávajícího systému na~základě požadavků zákazníka.} na~základě analýzy procesů v~organizaci, do~které je CRM systém dodáván. Jedná se ale o~rozsáhlá řešení pro~velké organizace, takže tomu odpovídá i~jejich cena (v~řádech od~statisíců korun). V~případě rozhodnutí nechat si vyvinout zcela vlastní řešení se taktéž bude jednat o~poměrně vysoké částky (v~porovnání s~běžně dostupnými generickými systémy), přestože výsledný CRM systém bude poměrně malý.\\ Současné pojetí řízení vztahů se~zákazníky tkví ve~třech (případně čtyřech) typech automatizací těchto vztahů. Nejčastěji jsou zmiňovány prodejní činnosti, servisní činnosti a zákaznická podpora, marketingové činnosti. Podle Chlebovského\cite{chleb1} by měl moderní systém s~podporou CRM zahrnovat všechny tři s~ještě jedním navíc - podporou elektronického obchodování. Na~všechny čtyři typy automatizací lze vlastně pohlížet jako na~jednotlivé moduly systému CRM. Takový pohled pak může pomoci při~samotném vývoji systému s~CRM. \subsection*{1. Automatizace prodejních činností} Anglicky též jako Sales Force Automation (zkratka SFA).\\Tento modul má za~cíl umožnit všem prodejcům/obchodníkům (i~těm externím) snadný a rychlý přístup k~důležitým informacím o~zákaznících. Dále pak by měl umožňovat time management (plánovač času) jednotlivých prodejců (například pro~zaznamenání údaje o~tom, v~jaký čas si zákazník přeje s~prodejcem hovořit). Navštívený zákazník může doporučit svého známého jako možného budoucího zákazníka, takže by měla být možnost vytváření záznamů o~nových dosud neidentifikovaných kontaktů a umožnění sledování další komunikace s~těmito potenciálními zákazníky. Prodejci by měli mít možnost efektivní spolupráce s~distributory pracující s~firemními produkty. Nakonec je nutno dodat, že všechny zmíněné funkcionality tohoto modulu by měli být lehce dosažitelné i~vzdáleně, tj. i~mimo kancelář. Často jsou prodejci nuceni přistupovat k~informacím, ikdyž jsou někde v~terénu. \subsection*{2. Automatizace marketingových činností} Anglicky též jako Marketing Automation (zkratka MA).\\Tento modul hraje důležitou roli při~tvorbě strategií vztahů k~zákazníkům se řeší v~tomto modulu. Základním kamenem je správa marketingových kampaní (anglicky Campaign Management). Na~počátku kampaně dojde k~segmentaci trhu nebo stávajících zákazníků, každá kampaň by měla být \uv{šitá na~míru} zákazníka, kterému je určena (například v~dopisu oslovení jménem cílového klienta). Oslovení zákazníků všemi možnými komunikačními kanály, preferují se pochopitelně moderní elektronické technologie. Po~ukončení kampaně je potřebné mít funkce pro~její vyhodnocení. Všechny tyto funkce a prostředky modulu by měly být provázány s~funkcemi modulu automatizace prodejních činností. Prodejci musejí mít ponětí o~tom, jakým způsobem byl osloven jaký (potenciální) zákazník, prodejci pak do~modulu marketingu posílají údaje o~konkrétních reakcích oslovených klientů. \subsection*{3. Automatizace servisních činností a zákaznické podpory} Anglicky též jako Field Service Automation (FSA), telefonické centrum, anglicky Call Centre (CC).\\Po~prodeji firemního produktu novému (či stávajícímu) klientovi je nutné mu poskytnout určitý komfort v~dalším kontaktu s~podnikem. Tento modul umožňuje správu servisních činností a s~tím úzce související správu zákaznické podpory. Jestliže má zákazník nějaký problém, obrátí se na~podnikovou podporu klientů (buď pomocí telefonu, e-mailu, anebo může například využít webového nástroje). Ti jeho požadavek vyřídí, buď pouhou odpovědí na~klientský dotaz či vytvoření události v~části správy servisních činností. Pak scénář pokračuje například tak, že servisní technik vyjede k~osobní návštěvě zákazníka a opraví mu poškozený produkt. Technici bývají v~kontaktu například mobilním telefonem či PDA. \subsection*{4. Elektronické obchodování} Anglicky Electronic Business (zkratky e-Business, E-B).\\Často bývá tento modul realizován jako řešení třetí strany. Slouží k~uskutečnění elektronického obchodu (typicky přes web, například v~e-shopech). Zcela automaticky vytváří a mění záznamy o~provedených transakcích, o~pohybech produktů na~skladech (upraví záznam toho produktu, ktery byl prodán), musí upozornit expedici na~vydání nového zboží a aktualizace dalších záznamů spojených s~obchodem. Takže je nevyhnutelně nutná úzká provázanost se~zbytkem informačního systému. \begin{figure}[ht] \begin{center} \scalebox{.60}{ \includegraphics{SchemaCRM.png} } \end{center} \caption{Schéma základních funkcí CRM Systému} \label{obr.schemaCRM} \end{figure} Nyní, když byly uvedeny hlavní požadavky na~funkce systému CRM, je zcela zřejmé, že papírové evidence, ale ani programy typu MS Outlook nemohou ani zdaleka nahradit sofistikované a komplexní nástroje pro~podporu CRM v~podnicích. \section{Struktura a typy CRM systémů} \label{typy.crm} CRM systémy lze také rozdělit podle typu jejich účelu. V~zásadě se vlastně jedná o~zjemnění rozdělení CRM systémů. V~různých pramenech lze narazit celkem na čtyři typy CRM, ale ne všechny uvádějí všechny čtyři základní typy. Většinou však rozhodně uznávají CRM operativní a analytický. Patrně je možné intuitivně odvodit účel jednotlivých subsystémů dle jejich názvů. \subsection*{Analytický CRM} Analytický subsystém mívá zajištěnu možnost pracovat jednak se~svými vlastními daty (v~operativní databázi), jednak také může přistupovat pomocí nástrojů data miningu\footnote{Data Mining neboli česky dolování dat zahrnuje metody, jak získávat data z~obsáhlých databází, např. z~Data WareHouse (DWH, česky datové sklady).} do~podnikových datových skladů. Data o~zákaznících se získávají průběžně či najednou na~základě studií a průzkumů trhu. Průběžný systém sběru dat mohou zajišťovat například prodejci a obchodní zástupci (jsou v~těsném kontaktu se~zákazníky). Na~takto získaných datech se pak provádí jejich podrobná analýza, provádějí se prognózy, odhalují se možné budoucí trendy, obchodní příležitosti. Několikrát zmíněná segmentace trhu patří právě sem. Další příkladem činností v~analytickém CRM je sledování a vyhodnocování úspěšnosti a efektivity marketingových kampaní. To je důležité zejména pro~jejich další optimalizaci. \subsection*{Strategický CRM} Na~straně \pageref{crm.strategie} se krátce zmiňuji o~tvorbě strategií vůči zákazníkům podniku. Je zřejmé, že tato aktivita bude patřit do~strategického subsystému CRM. Na~základě analýz dat z~analytického CRM můžeme sestavovat jednotlivé strategie pro~jednotlivé segmenty trhu, nejen k~získání nových zákazníků, ale především k~udržení těch stávajících. Řeší se reakce na~možné budoucí trendy. Dále se zde provádí základní cenotvorba, návrhy na~rozšíření portfolia služeb či produktů podniku, což pochopitelně koresponduje s~budoucími trendy na~trhu. Strategický CRM někdy nebývá považován jako samostatný subsystém. Pak jsou všechny činnosti, které sem patří, přeřazeny buď do~analytického CRM nebo do~operativního CRM. \subsection*{Operativní CRM} Tento subsystém za~cíl zajistit již přímou podporu obchodních a servisních procesů spojené se~zákazníky, jakožto i řízení marketingových kampaní. Patří sem například automatizovaná správa kontaktů, automatizovaná správa marketingových kampaní, tvorba cen na~míru zákazníkovi, podrobné profilování zákazníků, řízení telefonického centra, help desku. Na~základě historie komunikace zákazníka s~podnikem je možné, aby zákazník při~další formě komunikace (typy komunikace uvedeny v~kolaborační CRM) mohl bez~problémů komunikovat s~jakýmkoli ze~všech pracovníků help desku (pracovník si zobrazí historii a ví, s~kým hovoří a jaké jsou zákazníkovy problémy či připomínky). Dále sem také patří například automatizované webové rozhraní podpory. Pravděpodobně se jedná o~nejviditelnější CRM ze~všech zmíněných. \subsection*{Kolaborační CRM} Kolaborační ve~smyslu interakcí mezi podnikem a jeho zákazníky. Zahrnuje vlastně všechny možné komunikační kanály. Webové rozhraní podpory, telefonické hovory (včetně internetových volání typu VOIP či skype), e-mail, klasickou poštou (nejen dopisy, ale i~distribuce katalogů), sms zprávy (například když je nějaké objednané zboží připraveno k~odběru, zašle se sms zpráva na~mobilní telefon zákazníka), faxová zpráva (již je pomalu na~ústupu) nebo použití instant messengerů (například jabber či ICQ). Samozřejmě je zahrnuta i~osobní návštěva jak zákazníka v~klientském centru (jednoduše na~přepážce či v~zasedacím sále, pokud půjde o~velkoodbřeratele). Nelze samozřejmě tvrdit, že by se všechny uvedené technologie daly považovat za~elegantní a vhodné pro~obchodní jednání, nicméně jsou zmíněny jako možné prostředky komunikace. Pro~minimalizaci nákladů na~komunikaci, se preferuje elektronická komunikace. Ta umožňuje velmi snadnou evidenci (tvorbu historie komunikace), ale také sama o~sobě může být lehce zautomatizovaná (v~případě dodavatel -- pravidelný odběratel, kdy jejich systémy mohou spolu zcela zautomatizovaně interagovat). Někdy kolaborační CRM nebývá uváděn mezi typy CRM proto, že tento subsystém sám o~sobě nemá žádnou vnitřní logiku, jsou to jen komunikační kanály. \\ \begin{figure}[ht] \begin{center} \scalebox{.46}{ \includegraphics{typyCRM.png} } \end{center} \caption{Schéma typů CRM} \label{obr.typyCRM} \end{figure} Obrázek \ref{obr.typyCRM} ilustruje strukturu a způsob, jakým mezi sebou jednotlivé typy CRM komunikují. Dále pak jak je CRM napojené na~další interní systémy organizace (Back-Ofice a jeho ERP) a interakce se~zákazníky. Akce značí určitou (iniciální) aktivitu podniku vůči~vnějšímu světu, reakce pak značí odpovídající aktivitu zákazníků. \section{Chlebovského architektura} Na~strukturu CRM lze pohlížet i~z~jiného úhlu pohledu. Častými a běžnými požadavky na~architekturu CRM systémů je škálovatelnost, otevřenost vůči dalším (vnějším) systémům či případným budoucím rozšířením. Architektura musí pokrývat všechny procesy organizace vůči jejím zákazníkům, Chlebovský \cite[strany 10, 11]{chleb2} ji dělí na~čtyři základní vrstvy. Zdánlivě je schéma (ilustrace na~obrázku \ref{obr.chlebCRM}) jednodušší než které je uvedeno výše, spíše jde však o~hrubější pohled na~včlenění CRM systému v~organizaci. \subsection*{1. Komunikační kanály} Popis komunikačních kanálů se shoduje s~popisem vrstvy kolaboračního CRM (v~podkapitole \ref{typy.crm}, Kolaborační CRM). Patří sem tedy e-mailová komunikace, fax, telefonní spojení, osobní návštěva zákazníka na~přepážce, komunikace přes~WEB. \begin{figure}[ht] \begin{center} \scalebox{.50}{ \includegraphics{chlebarch.png} } \end{center} \caption{Chlebovského architektura CRM} \label{obr.chlebCRM} \end{figure} \subsection*{2. Firemní procesy} Sem patří kompletní systém CRM zcela propojený s~původními firemními procesy. Principiálně to vypadá tak, že požadavek zákazníka je zaznamenán jako objekt (hovor, e-mail, událost, příležitost). Tento zaznamenaný objekt je dále zpracován. Vše je napojeno na~firemní procesy, takže objekty mohou mířit nejen k~jiným uživatelům CRM, tak i~pracovníkům mimo CRM, kteří se ovšem na~příslušném procesu podílí. Informace o~zákazníkovi mají být přístupny každé osobě v~podniku, která zasahuje do~jakékoli fáze životního cyklu zákazníka. \subsection*{3. Integrační platforma} Samotný systém CRM je mocným nástrojem, ale bez potřebných informací k~ničemu, je nutné sdílet data napříč organizace. Pokud zákazník zavolá na~call centrum s~dotazem na~své pravidelné platby (například měsíční), pracovník centra musí být schopen rychle a snadno získat údaje ze~systému spravující účty podniku, aby mohl relevantně odpovědět. Je tedy nutné propojit CRM systém i~s~ostatními systémy (platby, faktury, sklady, nákup, lidské zdroje) v~rámci organizace, aby mohly vzájemně komunikovat.\\ \subsection*{4. Back Office} Právě zde leží ty ostatní podnikové systémy (obecně nazývané ERP), které by měly být propojeny jak mezi sebou, tak i~se~systémem CRM. CRM systém má mít možnost procházet daty v~těchto systémech, stejně tak systémy v~této vrstvě mají mít možnost procházet daty v~CRM. Back-Office je popsáno také v~podkapitole \ref{crm.infooblasti} \uv{\nameref{crm.infooblasti}} (na~straně \pageref{crm.infooblasti}). \section{Přehled CRM systémů v~ČR} V~tabulce \ref{tab.prehled_crm_v_cr} je zaznamenán přehled CRM systémů dostupných na~trhu v~České republice. Nemusí se nutně jednat o~samostatné informační systémy pouze pro~CRM, ale CRM může být součástí většího celku jako nástavba či modul. \begin{table}[htbp] \centering \begin{tabular}{|l|c|c|} \hline \textbf{Společnost} & \textbf{Název SW} & \textbf{Velikost~firmy} \\ \hline Abra Software & Abra G3 & malé, střední \\ Abra Software & Abra G4 & velké \\ Asseco Solutions & Helios Orange & malé, střední \\ Asseco Solutions & Helios Red & malé \\ Microsoft & MS Dynamix NAV & malé, střední \\ Microsoft & MS Dynamix AX & velké \\ Cígler Software & Money S4/S5 & malé, střední, velké \\ Minerva & QAD Entreprise App. & malé, střední, velké \\ Sprinx/Cígler & CRM S3 & malé \\ Oracle & EnterpriseOne CRM 8.11 & střední, velké \\ Oracle & Siebel eBusiness & malé, střední, velké \\ SAP & SAP CRM & malé, střední, velké \\ Sprinx & SprinxCRM & malé, střední \\ Lomar Info & myWAC & malé, střední, velké \\ Karat Software & Karat CRM & malé, střední, velké \\ \hline \end{tabular} \caption{Přehled vybraných CRM systémů v~ČR} \label{tab.prehled_crm_v_cr} \end{table} Jako zdroj posloužily přehledy uvedené na~stránkách System OnLine\footnote{System OnLine, konkrétně článek \uv{CRM systémy} na~adrese: \url{http://www.systemonline.cz/prehled-informacnich-systemu/crm-systemy/}. \cite{system3}} a v~časopisu Computerworld.\footnote{Computerworld, ročník XX, 25. 9. - 8. 10. 2009, číslo 16., strana 22. \cite{compworld3}} V~prvním sloupci jsou údaje o~výrobci (u~systému CRM S3 je výrobce Sprinx, ale dodavatel je Cígler Software). Ve~druhém sloupci je název softwarového systému a ve~třetím je uvedeno, pro~jak velké společnosti je softwarový nástroj určen. \chapter{Analýza vybraného podniku} Další částí této diplomové práce je~zanalyzovat procesy ve~vybraném podniku v~USA. Zvolená společnost se nazývá E-State Management, L.L.C., která se kromě správy a údržby nemovitostí a zeleně zabývá také pronájmem apartmánů. Cílem je zavést informační systém s~podporou CRM do~této společnosti a podchytit problematiku pronájmu apartmánů. Jak bude záhy vysvětleno, nejedná se o~společnost poskytující služby jako hotel či motel. Poznámka: Budu se tomuto tématu věnovat více ze~široka než jen v~kontextu CRM, protože budoucí informační systém by měl zahrnovat více funkcionalit, než jen pouze CRM. CRM je povinnou součástí systému, nikoli postačující. \section{Princip pronajímání apartmánů v~USA} V~češtině má slovo apartmán spíše význam hotelového pokoje, které si zájemce pronajme na~několik dnů a odjede. Mezitím se hotelová služba stará o~úklid, výměnu ručníků, povlečení v~posteli a o~další vymoženosti, které jsou v~ceně dočasného pronájmu zahrnuty. Anglické slovo apartment\footnote{Běžně užívaná zkratka slova apartment je \clqq apt.\crqq, takže se jí v~tomto textu přidržím.} je ve~slovníku Cambridge\footnote{Cambridge Dictionary, k~dispozici také online na~adrese \url{http://dictionary.cambridge.org/}} vyloženo jako termín užívaný především v~USA, britský ekvivalent je slovo flat. Flat už normálně překládáme do~češtiny jako byt (čili intuitivní představa, že apartment je v~češtině ve~významu hotelového apartmá (pro~bydlení na~několik dnů maximálně týdnů), není zcela přesná). Ve~spojených státech má stěhování velkou tradici. Dokonce tak velkou, že důvodem k~přestěhování nemusí být vážné důvody jako změna místa zaměstnání, sňatek, studium na~vzdálené škole, ale stačí jen chtít bydlet v~zrovna nově postaveném apartmánovém domě. Nejčastějším obdobím ke~stěhování zpravidla bývá přelom července a srpna. Samostatně stojící bytové domy (anglicky Apartment Houses) jsou většinou výjimkou a jedná se spíše o~domy vlastněné městem či jinou správní organizací. Pokud bytové domy staví soukromý vlastník, pak se nejčastěji jedná o tzv. Apartments Community\footnote{Při~hrubém pohledu to lze označit za~jakousi vzdálenou obdobu našich bytových družstev.} \footnote{Dále budu používat zkratku AC.}, kdy je postaveno více domů poblíž sebe (například na~jedné ulici). Děje se tak v~zásadě ze dvou důvodů. První důvod je ten, že domy stojící vedle (blízko) sebe lépe spravují. Opravář, který je zaměstnancem společnosti, nemusí projíždět celé město od~domů k~domu. Má to všechno v~jednom místě. Pro~nájemníky je ale důležitější druhý důvod. Je zažitým standardem, že u~každé AC stojí něco, čemu by se dalo říkat budova služeb. Jako naprosté minimum, které by tato budova měla poskytovat, je poloveřejná prádelna. V~USA jsou běžné veřejné prádelny, kam kdokoli přijde, vhodí minci a své prádlo do~automatické pračky a může si takto vyprat. Poloveřejná je zde v~takovém smyslu, že do ní může vstoupit pouze nájemník (či jeho rodinný příslušník) a prát si v~této prádelně. K~servisní budově se mohout vázat i~další služby, jako například tělocvična či samoobslužné umývání automobilů. Efektivní a takřka bezproblémové se jeví poměrně jednoduché přepsání přípojek plynu, elektřiny, telefonu (či spíše častěji internetu) a vodovodu. Nezřídka se stává, že v~jednom apartmánu bydlí nějaký nájemce, který se odstěhuje 31. července a do tohoto data jdou účty za~využití zmíněných zdrojů na~jeho jméno. A druhý den, tj. 1. srpna už se tam stěhuje a bydlí nový nájemce a veškeré přípojky jsou přepsány na~jeho nové jméno. Ačkoli se jedná o~dodavatelské společnosti, které jsou zcela mimo společnost poskytující apartmány, přesto tato společnost je jakýmsi zprostředkovatelem těchto služeb. Zájemce, který pochází z~jedné části státu a mající zájem o~apartmán na~druhé straně státu, bude mít jen stěží představu o~tom, jaká společnost v~cílové lokalitě distribuuje plyn či vodu. \section{Struktura společnosti} Americký typ společnosti L.L.C. Company je obdobou české společnosti s ručením omezeným. Má velice podobné vlastnosti, dokonce už i~z názvu je patrná podobnost. L.L.C. -- Limited Liability Company v~českém překladu znamená společnosti s~limitovanou odpovědností, což je prakticky totéž. Strukturu společnosti bude popsána z~pohledu personálního (pozice a jejich funkce) a z~pohledu lokace AC (rozdělením na~pobočky). \subsection*{Personální role} V~společnosti figuruje 7 rolí pracovníků. Dále společnost využívá externích pracovníků na~sezónní práce (například vymalování apartmánů), ti však nejsou přímo začleněni do~společnosti a ani nebudou mít přístup k~budoucímu informačnímu systému. Proto nejsou zahrnuti v~tomto popisu. \begin{itemize} \item \textbf{Vlastník} Na~vrcholu společnosti stojí jeden stoprocentní vlastník, který je zároveň něco jako šéf manažer. Posledních několik let se sám staví spíše do~role supervisora, který více kontroluje, než sám vykonává. Další jeho funkcí je podepisování šeků. \item \textbf{Šéf manažeři} Hned po~vlastníkovi jsou nejdůležitejší šéf manažeři společnosti. Tvoří ji dva lidé a jsou to vlastně oni, kdo fakticky řídí společnost. \item \textbf{Šéf technik} Je to člověk s~velkou praxí, který je správcem a oprávářem v~jedné osobě. Jeho náplní je udržování AC po~technické stránce. Jeho činnosti zahrnují od~sekání trávy, přes opravy závad a poruch v~jednotlivých apartmánech, až po výměnu žárověk na~ulicích náležící k~AC společnosti. Zároveň má po~ruce pomocné techniky. \item \textbf{Pomocný technik} Pomocné techniky si řídí sám šéf technik. Bývají zaměstnáni buď na~plný úvazek (full time) či brigádně (temporary job). Pomáhají šéf technikovi hlavně s~ne příliš komplikovanými pracemi (zametání sněhu na~chodnících AC či se~sekáním trávy). \item \textbf{Manažeři poboček (AC)} Každá pobočka AC má svého vlastního manažera, který má mít přehled o~tom, co se na~dané AC děje. Manažer tuto pobočku operativně řídí. Zabraňuje vznikání problému (například pokud vidí kontejner ze~tří čtvrtin plný, zavolá popeláře), sjednává nápravu vzniklého problému (například při~ucpaném záchodu zavolá šef technikovi). \item \textbf{Asistent manažer na~pobočkách (AC)} Jsou k~ruce manažerům poboček. V~případě, kdy nejsou manažeři v~kanceláři pobočky, by neměla zůstat kancelář prázdná, aby se zákazníci měli na~koho osobně obrátit. \item \textbf{Účetní} Tuto úlohu zastává jediná osoba, která je podřízena majiteli firmy a šéf manažerům. Kontroluje a zaznamenává platby nájemníků, vydává šeky k~proplacení a podobně. \end{itemize} \begin{figure}[ht] \begin{center} \scalebox{.50}{ \includegraphics{hierarchie_spol.png} } \end{center} \caption{Hierarchie v~podniku} \label{obr.hierarchSPOL} \end{figure} \subsection*{Pobočky} Již dříve zmíněné bytové domy (Apartment Houses) mají ve~vybrané společnosti vždy přízemí a jedno patro. V~každém podlaží se nachází dvě apartmánové jednotky, dohromady tedy na~jeden bytový dům připadají čtyři apartmánové jednotky. Společnost spravuje celkem 200 apartmánů. Ty jsou rozděleny do~tří AC, které jsou geograficky rozmístěny v~jednom městě. \begin{itemize} \item \textbf{Crosswinds AC} Je největší pobočkou ze~všech tří. V~servisní budově je umístěna kancelář majitele společnosti, kancelář účetní. Také je zde umístěna tělocvična a prádelna pro~nájemníky. V~celém AC je postaveno kolem 90 apartmánových jednotek. Zde je také umístěno hlavní technologické zázemí (podnikové servery a úložiště dat). V~zákaznické kanceláři jsou k~dispozici dva (případně i~tři\footnote{Bývají tři, výjimečně i~čtyři, zvláště v~době očekávaného zvýšeného náporu zákazníků se~zájmem o~prohlídku komplexu AC a apartmánů}) pracovníci. Typicky manažer AC a jeho asistenti. \item \textbf{Northwinds AC} Je starší a menší pobočkou (co do počtu apartmánů). V~zákaznické kanceláři bývají dva, někdy i~tři pracovníci. Nejčastěji manažer AC a jeho asistent. Počet apartmánů je zde zhruba 70. \item \textbf{Windgate AC} Je nejnovější postavený komplex budov mající čtyřicet docela dobře vybavené apartmány. Tento AC nemá svoji vlastní kancelář. Kancelář sdílí s~komplexem Northwinds, protože geograficky mají k~sobě velmi blízko. V~praxi to tedy vypadá tak, že pokud přijde potenciální zákazník (budoucí nájemce) a chce vidět apartmán ve~Windgate, pak přijede manažer (případně asistent manažer) z~AC Northwinds. \end{itemize} \section{Komplexy AC a apartmány} Jak již bylo popsáno, AC (Apartments Community) je komplex bytových (apartmánových) budov typicky příslušící jedné společnosti. Není výjimkou, že takový komplex budov má celou vlastní ulici. Každý komplex AC mívá své specifické vlastnosti, které bývají často dány svou geografickou polohou. Některé jsou u~lesa, proto se prezentují jako tichá a klidná místa, kde se hezky žije. Některé mohou být více v~centru, pak se prezentují jako místa, kde se nikdo nikdy nenudí. Od~těchto vlastností se pak odvíjí jakási všeobecná pravidla pro~bydlení v~těchto lokalitách, která jsou platná pro~všechny apartmány, které zahrnuje. Každá bytová budova (Apartment House) má několik apartmánů, v~případě vybrané společnosti jich má vždy čtyři. Každý apartmán má opět svá specifika. Nejčastějším typem dotazů, které zákazníci při~výběru apartmánu pokládají, je, jestli mohou mít domácího mazlíčka (nejběžněji jde o~psa nebo kočku). V~tom případě by manažer AC mohl automaticky nabídnout apartmán, kde už předtím nějaké zvíře pobývalo. Nebo naopak nájemníci předem nahlašují, že jsou alergičtí na~srst domácího zvířectva a že nemohou bydlet někde, kde už někdy předtím domácí zvíře žilo. Je tedy patrné, že jak AC, tak i~samotné apartmány mají nějakou svoji historii, kterou je velice vhodné průběžně zaznamenávat. Ve~výše popisovaném případě o~alergiích už by nešlo jen o~pouhou (ne)spokojenost zákazníka, ale v~horším případě o~jeho zdraví. \section{Fáze vztahu nájemníka} Celý cyklus, od příchodu zákazníka (tedy v~tomto případě nájemníka, anglicky tenant), jeho pobývání v~apartmánu a nakonec i~jeho odchod od~společnosti, je klasickým případem životního cyklu zákazníka (Customer Lifecycle). O~tomto tématu je v~obecné rovině pojednáváno v~podkapitole \ref{faze.vztahu} \uv{\nameref{faze.vztahu}} (na~straně \pageref{faze.vztahu}). \subsection*{Navázání vztahu nájemníka} Několik měsíců před samotným stěhováním se začnou budoucí nájemníci rozhlížet, kam by se mohli nově přestěhovat. V~ten moment dochází k~prvnímu kontaktu. Nejčastěji se jedná o~listování internetovými stránkami, kde naleznou prvotní informace o~společnosti a nabízených apartmánech k~pronájmu. Pokud je informace zaujmou, dojde následně typicky k~telefonickému rozhovoru, ve~kterém si potenciální nájemník sjedná schůzku s~některou z~pracovnic. V~případě, že je klient spokojen s~prohlídkou vybraného apartmánu a hodlá se v~něm usadit, je vyzván, aby vyplnil dotazník a předložil identifikační kartu (v~USA se nejčastěji jedná o~řidičský průkaz). Následně se podpisem uzavře nájemní smlouva\footnote{Pro~vyplnění smluv se používají univerzální šablony wordovského dokumentu, do~kterých stačí jen doplnit inicály nájemníka.}. Pak už nic nebrání tomu, aby se nový nájemník k~dohodnutému datu nastěhoval. \begin{figure}[ht] \begin{center} \scalebox{.50}{ \includegraphics{navazani_vztahu.png} } \end{center} \caption{Typický průběh navázání vztahu} \label{obr.nav_vztahu} \end{figure} Obrázek \ref{obr.nav_vztahu} ilustruje zmíněný scénář navázání vztahu čtyřmi kroky: \begin{enumerate} \item Zákazník je zaujat popisem komplexu a apartmánů (web lze nahradit jiným komunikačním médiem, například novinami, televizní upoutávkou\ldots). \item Následně dojde k~telefonickému kontaktu, ve~kterém je dohodnuta osobní návštěva. \item Na~osobní návštěvě si prohlédnou komplex AC a vybraný apartmán. \item Pokud se potenciální nájemník rozhodně kladně, dojde k~uzavření smlouvy. \end{enumerate} \subsection*{Rozvíjení vztahu} V~den stěhování do~apartmánu si nájemník vyzvedne u~manažera AC klíč. Pak jde manažer s~novým nájemníkem do~příslušného apartmánu, který společně procházejí. Cílem je, aby si oba apartmán prošli a v~případě, že by alespoň jeden z~nich nalezl vadu, závadu či jiný problém, bylo vše zaznamenáno do~přebíracího protokolu. Manažer má pak za~úkol sjednat co nejdříve nápravu. V~případě drobných závad se dohodne přímo se~šéf technikem, který pak zajistí odstranění vad, nebo v~případě závažných problémů kontaktuje manažera společnosti a dohodnou se na~dalším postupu\footnote{Závážných problémů by mělo být minimum, protože v~principu se apartmány dávají do~výborného stavu hned po~odstěhování původních nájemníků. Vše se pak ještě kontroluje.}. Poměrně často se stává, že se klíč ztratí. V~tu chvíli může nájemník osobně navštívit zákaznickou kancelář a po~ověření totožnosti mu bude ihned vydán nový klíč. Pokud ztráta klíče nastane mimo provozní hodiny kanceláře, může nájemník zavolat příslušnému manažerovi svého bydliště, který přijede do~zákaznické kanceláře a pak pokračuje scénář ověření totožnosti a vydání nového klíče. Existují samozřejmě další modelové situace, ale obecně mají pracovníci nakázáno, aby se maximálně snažili s~nájemníky, jakožto klienty společnosti, dohodnout, při~problémech nalézt shodu a vůbec jim vycházet vstříc. \subsection*{Ukončení vztahu} Pokud se nájemník rozhodne neprodlužovat nájemní smlouvu a odstěhovat se z~apartmánu pryč, oznámí termín stěhování manažerovi AC (případně asistent manažerovi). V~tento den se po~vystěhování nábytku z~apartmánu nájemník a manažer AC sejdou a opět si spolu celý apartmán projdou. Cílem je najít nově vzniklé vady či jiné problémy, které se zaznamenají do~předávacího protokolu. Následně pak manažer sjedná nápravu (podobný proces jako při~stěhování do~apartmánu). Vzniklé náklady jsou pak vymáhány po~původním nájemníkovi. \section{Uchovávání citlivých údajů} Především v~souvislosti s~kapitolou předchozí a následující, potažmo vůbec v~kontextu CRM, je vhodné poznamenat problematiku uchovávání citlivých osobních údajů. V~Evropě jsou celkem známy zákony o~ochraně osobních údajů, v~České republice jde především o~\uv{zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů}, a jak fungují. V~USA je situace poněkud odlišná. Jako ne-právník si zde nedovolím příslušné právní normy rozebírat, jen se pokusím \uv{vypíchnout} zásadní rozdíly. Může nastat celá řada událostí spojené s~apartmány a nájemníky. Pokud nejrůznější (jakékoli) události chceme zaznamenat v~souvislosti s~apartmánem, který je ve~vlastnictví společnosti, není pochopitelně v~ničem žádný problém. Uchovávání údajů v~souvislosti s~nájemníky může být mírně komplikovanější záležitostí. V~Evropě, jak bylo zmíněno, jde především o~způsoby získávání, uchovávání a zpracovávání osobních a citlivých údajů o~osobách v~souladu s~příslušnými zákony. Idea je taková, že by v~principu mělo být dohledatelné, jak kdo k~citlivým údajům přišel. V~USA se k~této problematice přistupuje dost odlišně. Tržní cena osobních a citlivých údajů je zde velmi nízká, což svědčí o~tom, že jsou lehce k~získání.\footnote{Vycházím z~vlastního pozorování, ale také z~informací z~přednášek Dr. Václava Matyáše \uv{PV080 Ochrana dat a informačního soukromí, Fakulta informatiky Masarykovy univerzity.}} Zákony upravují jen minimálně způsoby nakládání s~takovými údaji a když už se tak děje, jedná se spíše o~prosazování rovnoprávnosti ras, vyznání, přesvědčení a podobně. Výjimku tvoří například zdravotnická zařízení, která jsou naopak nucena zjišťovat, jestli se jedná o~afro-američana, bělocha či latino-američana, protože lidská těla různých ras mohou reagovat na~stejné léky odlišně (u~některých mohou vyvstat vážné zdravotní komplikace). Samozřejmě nenaznačuji, že je v~Evropě prosazování rovnoprávnosti podceňované, spíše je ochrana údajů v~USA pomíjená záležitost. Společnosti pronajímající apartmány si uchovávají kromě běžných údajů o~zákazníkovi také jeho Social Security Number (SSN, obdoba českého rodného čísla) a Driver's Licence Number (DLN, číslo řidičského průkazu).\footnote{Vlastnit vůz a řidičský průkaz je v~USA naprostou samozřejmostí a použití řidičského průkazu bývá považováno za zcela běžný způsob ověření identity majitele či prokázání jeho zletilosti.} Dokonce si tyto průkazy kopírují na~kopírce a uchovávají v~papírové ve~složce příslušného zákazníka. \section{Události a zákaznické požadavky} \subsection*{Mimořádné} Pracovníci zákaznické kanceláře, tj. manažeři AC a samozřejmě i~asistent manažeři, mají mimo jiných také za~úkol pravidelně procházet komplex AC a zjišťovat vady a problémy, nebo ještě lépe jim předcházet. Mají sledovat, kde je potřeba například vyvézt kontejnery s~odpadky, kde odmetat sníh, nebo kde vyměnit žárovku osvětlení v~budově či pouliční lampy. \subsection*{Rutinní} Kromě těchto mimořádných událostí (čímž prasklá žárovka či napadaný sníh zřejmě jsou) existují i~rutinní. Tráva se přes~léto seká každý týden, voda ve~fontáně se vyměňuje jednou za~měsíc, celoročně je úklid tělocvičny a prádelen jednou za~čtrnáct dní, roznos podnikového buletinu každý třetí týden a podobně. \subsection*{Mimořádné zákaznické} Pokud nájemníci v~něčem vidí problém, či zjistí závadu na~zařízení\footnote{Ve~standardní výbavě apartmánů bývá chladnička a myčka na~nádobí. O~tato zařízení se pak pochopitelně stará majitel apartmánu, tj. společnost nikoli nájemník.}, které je v~apartmánu ve~standardní výbavě, kontaktují pracovníka zákaznické kanceláře. Příslušný pracovník zjistí, v~čem by mohl být problém, a následně sjedná nápravu. Taktéž může v~apartmánu nastat nehoda způsobená přímo nájemníkem, například poškození zařízení nebo vybavení, vytopení či vyhoření apartmánu. V~těchto případech je proces obdobný, pochopitelně s~tím rozdílem, že po~odstranění závad a likvidaci nehod se účet spojené s~náklady předá nájemci, který událost způsobil. Další záležitost, kterou musí manažeři AC řešit, byť jen do~jisté omezené míry, jsou problémy v~mezilidských vztazích. Sice se takové vyskytují spíše výjimečně, přesto se může jednat o~důležitou informaci, kterou je vhodné mít zaznamenanou. \subsection*{Příslušné procesy} Jinými slovy tedy nastává jedna ze~tří možných situací, kdy se rozeběhnou procesy vedoucí ke~sjednání nápravy. První má~původ v~pravidelném opakování, druhá je mimořádná vyvolaná pracovníkem společnosti a třetí je mimořádná vyvolaná nájemníkem. Pracovník, který zjistil problém (příp. kterému byl problém ohlášen), následně kontaktuje buď přímo šéf technika, nebo v~případě závažných událostí nejdříve manažera společnosti. Manažer společnosti pak rozhodne, zda se k~nápravě přizve externí firma (pracovník), nebo zda je problém řešitelný vlastní silou. Každopádně manažer příslušné AC, ve~kterém událost nastala, sleduje průběh sjednávání nápravy. Na~požádání by měl být schopen říci, kdy bude problém odstraněn. Takový dotaz může vznést jakýkoli nadřízený, nebo přirozeně i~zákazník, pokud se jedná o~problém nahlášený právě jím. \section{Určení informačních oblastí podniku} \label{inf_obl_pod} Prvotním náznakem toho, kdo bude uživatelem budoucího CRM systému, je rozdělení společnosti na~informační oblasti tak, jak je uvedeno na~straně \pageref{crm.infooblasti}, v~podkapitole \ref{crm.infooblasti} \uv{\nameref{crm.infooblasti}}. Zaměstnanci, kteří spadnou do~oblasti Front-Office, jsou jasní kandidáti. Naopak u~zaměstnanců, kteří spadnou do~oblasti Back-Office není ihned zřejmé, zda vypadli z~kandidatury na~uživatele CRM systému. \begin{figure}[ht] \begin{center} \scalebox{.65}{ \includegraphics{inf_ob_pod.png} } \end{center} \caption{Role rozdělené do~informačních oblastí} \label{obr.inf_obl_pod} \end{figure} Každý komplex apartmánů (AC) má tedy svého přiřazeného manažera AC a několik asistent manažerů. Ti se starají o~bezproblémový chod a věnují se zákaznickým potřebám. Tito zaměstnanci jsou v~kontaktu se zákazníky (i~s~těmi potenciálními) nejčastěji. Dalšími pracovníky, kteří se setkávají s~klienty, jsou technici - ti v~případě potřeby přijdou až do~konkrétního apartmánu nájemce, kde pak řeší nějaký problém. Za~určitých okolností se může stát, že do~styku s~nájemníky přijdou i~manažeři společnosti. Často se tak děje spíše za~nepříjemných okolností, kdy se řeší stížnost na~některého z~podřízených pracovníků. Kdo prakticky vůbec nepřijde do styku s~klienty je majitel společnosti a účetní. Čili už je zřejmé, kdo do~jaké oblasti bude patřit. Ikdyž máme dvě zaměstnanecké role, tedy vlastníka společnosti a účetní, které nepřijdou do~přímého styku se~zákazníky, přesto s~nimi musíme počítat jako s~uživatelskými rolemi budoucího systému CRM. Obě role se podílí a zúčastní procesů, které souvisí se~zákazníky společnosti. Majitel se cití být v~roli supervisora, který má moc do~čehokoli zasáhnout, a účetní je pracovník, který dohlíží na~pořádek plateb nájemného klientů. \begin{itemize} \item \textbf{Front-Office} \begin{itemize} \item Manažer společnosti \item Manažer AC \item Asistent manažer AC \item Šéf technik \item Pomocný technik \end{itemize} \item \textbf{Back-Office} \begin{itemize} \item Majitel společnosti \item Účetní \end{itemize} \end{itemize} Zaměstnanci, kteří se v~rozdělení na~informační oblasti ocitli v~oblasti Front-Office, budou nejen běžnými uživateli systému, ale budou mít vysoká práva manipulovat se~záznamy zákazníků. Vysokými právy manipulace lze chápat vytváření záznamů, editování a aktualizování. Zaměstnanci, kteří propadli do~Back-Office (pouze dvě zmíněné zaměstnanecké role), budou mít minimálně právo nahlížet do~záznamů zákazníků. \section{Explicitně zadané požadavky} \subsection*{Požadavek 1:} Majitel společnosti, účetní a manažeři společnosti mají mít k~dispozici jednoduché přehledy nájemníků, u kterých není evidována přijatá platba, a to vždy za~posledních 40 dní. Tj. jeden měsíc běžné lhůty pro~zaplacení nájemného a deset dní \uv{k~dobru}. \subsection*{Požadavek 2:} Již byl popsán scénář, kdy nájemník ztratí klíč od~svého apartmánu. Před~vydáním nového klíče je potřeba ověřit, že nájemník skutečně bydlí v~příslušném apartmánu. Čili systém by měl umožňovat jednoduché vypisování seznamu nájemníků, hledání mezi nimi a ověřit příslušnost apartmánu. \subsection*{Požadavek 3:} Byl taktéž vznesen asi jeden z~nejčastějších požadavků na~informační systémy, zároveň ale docela vágní -- důraz na~jednoduchost ovládání. U~pana majitele společnosti jsem si všimnul, že celkem nerad píše na~klávesnici. Takže minimálně všechny přehledy a statistiky by měly být dostupné bez použití klávesnice, tedy co nejvíce klikatelné. \subsection*{Požadavek 4:} Kromě evidence apartmánů by měl být systém schopen evidovat i~jejich vybavení. Skladba vybavení bývá nejčastěji takové, že se nakoupí nějaké zařízení od~stejného výrobce a stejného typu ve~větším množství, které se následně montuje a připojuje do~jednotlivých apartmánů. Vypadá to tedy například tak, že apartmány patřící pod~jeden apartmánový komplex (community) jsou vybavena stejnými zařízeními. \subsection*{Požadavek 5:} Do~systému se budou uživatelé autentizovat běžnáým způsobem, tedy pomocí přihlašovacího jména a hesla, přičemž jako přihlašovací jméno bude použita e-mailová adresa příslušnéího zaměstnance. Systém byl měl alespoň v~základní míře evidovat provedené akce jednotlivými uživateli, to bude pak sloužit pro~kontrolu a přehled činností. \section{Požadavky na~CRM} Nedílnou součástí systému má být i~podpora Customer Relationship Management. Tento subsystém bude zcela provázán s~hlavním systémem, především pak (a zcela pochopitelně) s~evidencí nájemníků. Primárním cílem je, aby zaměstnanec společnosti měl při~kontaktu se~zákazníkem co největší množství informací snad k~dispozici, což pak umožňuje co nejlépe zákazníkovi vyhovět v~jeho přáních. Tento subsystém bude realizován tak, aby splňoval principy a vlastnosti CRM, které byly popsány v~kapitole \nameref{def.crm} (od~strany \pageref{def.crm}). \subsection*{Analýza trhu} Mělo by se jednat o~jednoduchý nástroj na~podporu analyzování trhu a evidování odhalených příležitostí. \subsection*{Marketing a získávání nových nájemníků} Subystém CRM by měl disponovat funkcemi pro~správu kampaní pro~získávání nových nájemníků. U~jednotlivých kampaní by mělo být zřejmé, jak velké finance na~ně byly vynaloženy. \subsection*{Vyhodnocování spokojenosti nájemníků} Kromě běžných informací o~zákazníkovi jako jsou evidence jeho plateb, údaje o~smlouvě, informace o~tom, kdy se skutečně nastěhoval, v~jakém apartmánu bydlí, je vhodné mít k~dispozici nástroj, který by nějakým způsobem hodnotil jejich spokojenost. % ****************** KONEC Analýzy systému ************** % ****************** ZAČÁTEK Návrh systému ************** \chapter{Návrh systému} \section{Rozdělení na~subsystémy} Celý systém bude rozdělen do~několika subsystémů. Do~budoucna však nebude problém rozšířit systém o~další části. Předběžně se počítá s~tím, že by se mohlo jednat například o~rozšíření o~subsystém správy dokumentů. Prozatím se se ale bude jednat o~následujících pět: \begin{itemize} \item BASE (základ systému) \item APTS (apartmánový subsystém) \item TENANTS (Subsystém nájemníků) \item CRM (Customer Relationship Management) \item BILLS (billingový) \end{itemize} Toto rozdělení je čistě logická analýzo-návrhářsko-programátorská záležitost. Na~uživatelském rozhraní vyvinutého systému to nemusí mít přímý viditelný vliv. Jinými slovy takovéto rozdělení systému na~menší podsystémy je jen pro~snadnější a přehlednější vyvinutí systému. Odkazy v~uživatelském rozhraní budou upraveny tak, aby odpovídaly potřebám uživatelů. Například vytvoření záznamů o~apartmánech (a jejich případná editace) bude intenzívní činností jen na~počátku, další práce s~nimi se bude vykonávat jen zřídkakdy, tudíž není důvod, aby existoval odkaz v~hlavní nabídce. \section{Základ systému} \begin{figure}[ht] \begin{center} \scalebox{.43}{ \includegraphics{zaklad_use.png} } \end{center} \caption{Případy užití v~základním subsystému (uživatelé)} \label{obr.zaklad_use} Pozn. zvětšenou ilustraci lze nalézt v~příloze na~straně \pageref{obr.zaklad_use_big}, obrázek \ref{obr.zaklad_use_big} \uv{\nameref{obr.zaklad_use_big}}. \end{figure} \begin{figure}[ht] \begin{center} \scalebox{.60}{ \includegraphics{zaklad_use2.png} } \end{center} \caption{Případy užití v~základním subsystému (aktivity)} \label{obr.zaklad_use2} Pozn. zvětšenou ilustraci lze nalézt v~příloze na~straně \pageref{obr.zaklad_use2_big}, obrázek \ref{obr.zaklad_use2_big} \uv{\nameref{obr.zaklad_use2_big}}. \end{figure} Jedná se o~podporu evidence uživatelů (teda zaměstnanců společnosti), definování uživatelských rolí a přiřazování je jednotlivým uživatelům. Tento subsystém bude mít na~starosti autentizaci uživatelů do~systému a jejich následnou autorizaci. Pokud běžný uživatel zapomene své heslo, manažer společnosti by měl být schopen heslo resetovat a přiřadit nové. Dále se zde bude nacházet správa provedených akcí jednotlivými autentizovanými uživateli. Obrázek \ref{obr.zaklad_use2} \uv{\nameref{obr.zaklad_use2}} na straně \pageref{obr.zaklad_use2} ilustruje případy užití právě při~práci se~záznamy akvitit uživatelů. Záznamy se budou vytvářet zcela automatizovaně, tudíž odpadají akce pro~vytvoření záznamu. Taktéž nemá smysl se zabývat editací takových záznamů, protože pak by zřejmě neodpovídaly skutečnosti. \subsection{Uživatelské role} V~podkapitole \ref{inf_obl_pod} \uv{\nameref{inf_obl_pod}} na~straně \pageref{inf_obl_pod} je společnost rozdělena na~informační oblasti a z~nich pak určeny možné uživatelské role. Libovolný uživatel v~systému může nabývat libovolné uživatelské role či jejich kombinací. Přiřazování rolí (stejně tak jako i~vytváření nových uživatelů) má na~starosti administrátor, majitel společnosti (Owner) a manažer společnosti (AC Manager). Obrázek \ref{obr.zaklad_use} \uv{\nameref{obr.zaklad_use}} zobrazuje některé uživatelské případy v~základním subsystému, konkrétně případy práce s~uživateli. Uživatel sám sobě může změnit heslo, uživatelé s~příslušným oprávněním pak mohou měnit/resetovat hesla jakémukoli uživateli. Případy užití \uv{Vytvoření nového uživatele} a \uv{Editace uživatele} jsou trochu komplikovanější a zahrnují více akcí, než diagram ukazuje. Konkrétně se jedná o~vyhledání a vypsání uživatelských rolí a následně při~ukládání změn jsou příslušné vazby mezi vytvořeným či editovaným uživatelem a dotčenými uživatelskými rolemi aktualizovány. Vytváření nových uživatelských rolí může být velmi komplikované, zvláště pak přiřazování konkrétních oprávnění k~těmto novým rolím. Proto se budou využívat pouze předem nastavené uživatelské role. Seznam schválených rolí je uveden v~tabulce \ref{tab.uziv_role} \uv{\nameref{tab.uziv_role}} na~straně \pageref{tab.uziv_role}. \begin{table}[htbp] \centering \begin{tabular}{|l|l|} \hline \textbf{Název role} & \textbf{Oprávnění} \\ \hline Administrator & Nejvyšší v~celém systému. \\ \hline Owner & Nejvyšší v~celém systému. \\ Company Manager & Prozatím stejná jako owner. \\ AC Manager & Apartmány, CRM, nájemníci. \\ AS Manager & Prozatím stejná jako AC Manager. \\ Accountant & Billingový subsystém, nájemníci. \\ Maintenance Supervisor & Apartmánový subsystém. \\ Maintenance Helper & Zatím stejná jako Maint. Supervisor. \\ \hline \end{tabular} \caption{Seznam uživatelských rolí} \label{tab.uziv_role} \end{table} Role administrátora je v~uvedené tabulce opticky oddělena od~ostatních, protože stojí jakoby trochu mimo. Uživatelský účet s~administrátorskou rolí by měl figurovat jako servisní účet, nikoli jako účet podobný účtu pro~výkonného zaměstnance společnosti. Stejně tak, jak se bude dále v~čase vyvíjet informační systém, budou se vyvíjet a více odlišovat i uživatelské role. \section{Apartmánový subsystém} Dle názvu je zřejmé, že se bude jednat především o správu apartmánů. Apartmány, jak bylo uvedeno výše, patří hierarchicky do~nějaké vyšší organizační jednotky společnosti. Může se jednat pouze o~nějakou (samostatně stojící) budovu, tedy apartmán je součástí této budovy, přičemž v~této budově může být apartmánů více. Nebo je apartmán součástí většího celku v~podobě apartmánových komplexů (apartments community), kdy samozřemě je apartmán opět v nějaké budově a tyto budovy tvoří zmíněný komplex, ale není zvykem rozlišovat samotné budovy, jen apartmány v~příslušném komplexu. A třetí případ je, že se v~rámci apartmánového komplexu rozlišují jak apartmány tak i budovy. \begin{figure}[ht] \begin{center} \scalebox{.65}{ \includegraphics{apt_hier.png} } \end{center} \caption{Apartmánové org. jednotky} \label{obr.apt_hier} \end{figure} \begin{figure}[ht] \begin{center} \scalebox{.90}{ \includegraphics{apt_class.png} } \end{center} \caption{Diagram třídy Apartment, Org\_Unit a Company (hierarchie)} \label{obr.apt_class} \end{figure} Kromě apartmánů a organizačních jednotek se zde nastavuje i~mateřská společnost. Prozatím bude vytvořena jedna společnost, na~kterou budou navázány organizační jednotky a tím pádem i~apartmánů. V~budoucnu bude hrát samozřejmě významnou roli nastavení společnosti, budou se k~ní přiřazovat taktéž uživatelé, kteří pak budou pracovat jen na~\uv{svém písečku}. Na~obrázku \ref{obr.apt_class} \uv{\nameref{obr.apt_class}} je znázorněn vztah mezi apartmánem a organizačními jednotkami (Org\_Unit), kde se využívá dědičnosti tříd. Apartmán si drží vazbu na~organizační jednotku a organizační jednotka si udržuje vztah ke~své nadřazené společnosti. Organizační jednotka ale sama o~sobě nemá žádnou roli, důležité jsou její \uv{děti}, které jsou tvořeny AC\footnote{Zkratka pro~Apartment Community.} (Community) či budovami (Building). Jinými slovy se dá říct, že každá organizační jednotka musí být určitého typu, buď AC nebo budovou. To dále umožňuje skutečnou hierarchii (tak, jak je znázorněna na~obrázku \ref{obr.apt_hier} \uv{\nameref{obr.apt_hier}}) i~mezi samotnými AC a budovami. Každý apartmán má své vybavení. Pokud je vybavení jedinečné (tedy nevyskytuje se v~žádném jiném apartmánu), lze toto vybavení evidovat v~poznámkách příslušného apartmánu (atribut Description). Pokud se jedná o~vybavení, které se vyskytuje v~mnoha apartmánech, například všechny apartmány v~jedné budově mají stejný typ mikrovlnné trouby od~jednoho výrobce, pak lze vytvořit záznam v~sekci Amenities. Při~editaci apartmánu pak mohu vybrat příslušné vybavení, které je pro~něj relevantní. \subsection{Hromadné vytváření apartmánů} Apartmánů v~rámci jedné budovy nebývá příliš mnoho, na~druhou stranu v~rámci apartmánových komplexů jich bývá hodně. Bude tedy zavedena funkce, která umožní hromadné vytváření apartmánů v~rámci přílušného (a nově vzniklého) AC. Tyto apartmány mívají společné znaky, například mívají všechny stejné názvy ulic společně s~mateřským AC. To je tedy atribut, který může být vložen automatizovaně a nemusí být vkládán ručně. Pochopitelně lze očekávat, že budou mít i~odlišné znaky (různá označení, číslo popisné\ldots), ale je jednodušší upravit jen tento atribut, než vypisovat všechny. Při~tomto hromadném vytvoření apartmánů se budou automatickyy vkládat jako označení (název) apartmánu text \uv{No} následované číslem. Toto číslo bude odpovídat iteraci vytvoření apartmánu, bude nabývat hodnot od~1 do~n, kde n značí počet apartmánů, kolik jich se má vytvořit. \section{Subsystém nájemníků} Jak je z~názvu patrné, jedná se především o~evidenci nájemníků, uzavřených smluv a událostí. Smlouvy se pořád budou uzavírat v~písemné podobě, čili evidence smluv bude spíše informativního charakteru o~tom, kdy byla smlouva podepsána, na~jaký apartmán a pro~jakého zákazníka. Taktéž bude uvedeno, k~jakému datumu se hodlá zákazník nastěhovat či vystěhovat. \begin{figure}[ht] \begin{center} \scalebox{.70}{ \includegraphics{contract_class.png} } \end{center} \caption{Diagram třídy Tenant\_Contract (Nájemní smlouvy)} \label{obr.contract-class} \end{figure} Na~obrázku \ref{obr.contract-class} \uv{\nameref{obr.contract-class}} jsou zobrazeny čtyři třídy. Asociativní třída Tenant\_Contract představuje nájemní smlouvu, která se váže k~příslušnému nájemníkovi, na~příslušný apartmán a záznam o~této smlouvě je vytvořen daným uživatelem. V~tabulce \ref{tab.tc-atributes} \uv{\nameref{tab.tc-atributes}} na~straně \pageref{tab.tc-atributes} jsou uvedeny všechny atributy\footnote{Systém je vyvíjen v~Ruby On Rails, který má tu vlastnost, že běžně používané atributy tříd (modelů) jako je ID (primární klíč), Created\_at (DateTime) a Updated\_at (DateTime) jsou při~jejich vytváření vkládány zcela automaticky, proto nejsou v~diagramu uvedeny.} třídy Tenant\_Contract. Atribut (Document\_Path) je uveden v~závorce proto, že sice ještě není implementován, ale přesto ji zde uvádím, protože brzy se začne pracovat na~funkcionalitě, kdy může být naskenovaná papírová smlouva nahrána do~systému a v~tomto atributu pak na~ni odkázano. Pokud tuto funkcionalitu stihnu dokončit brzy, mohu ji předvést při~obhajobě této práce. Čili atributy Move\_In a Move\_Out drží informaci o~tom, kdy se hodlá nájemník nastěhovat a vystěhovat. Držet informaci o~vystěhování má smysl, protože nejběžněji jsou smlouvy uzavírány na~jeden rok, po~té se nájemník skutečně odstěhuje. Atribut User\_id drží údaj o~uživateli, který záznam vytvořil. Tenant\_id a Apartment\_id drží vazbu k~příslušnému nájemníkovi a apartmánu. Atribut Note umožňuje zapsat poznámky ke~smlouvě a atributy Created\_at a Updated\_at evidují, kdy byl záznam vytvořen, resp. editován. Atribut Ident umožňuje zaznamenání vlastní identifikační číslo (znak) smlouvy. Společnost má uzavřené smlouvy nějakým způsobem označené (vlastní typ sériového čísla), tento atribut umožňuje vložení právě takového identifikátoru. Pokud při vytváření nového záznamu je tento atribut prázdný, tedy uživatel nezadal žádný identifikátor, je automaticky vložena hodnota atributu ID. \begin{table}[htbp] \centering \begin{tabular}{|l|l|} \hline \textbf{Atribut} & \textbf{Typ} \\ \hline ID (PK) & Integer \\ \hline Move\_In & Date \\ Move\_Out & Date \\ User\_id & Integer \\ Tenant\_id & Integer \\ Apartment\_id & Integer \\ Note & Text \\ (Document\_Path) & String \\ Ident & String \\ Created\_at & DateTime \\ Updated\_at & DateTime \\ \hline \end{tabular} \caption{Atributy třídy Tenant\_Contract} \label{tab.tc-atributes} \end{table} Dalším nástrojem v~tomto subsystému je správa událostí (events). Ta slouží k~zaznamenávání běžných či mimořádných událostí, aktivit a zpráv spojených buď s~apartmánem (do~prázdného apartmánu někdo prohodil cihlu oknem, okno je rozbité, musí se opravit), nebo s~nájemníkem (nájemník havaroval se~svým autem v~prostorách AC). Nebo je událost spojená jak s~apartmánem tak i~nájemníkem (případ, kdy se nájemník stěhuje do~aprtmánu či když ohlásí, že poškodil vybavení apartmánu). \section{Subsystém CRM} % ===== SUBSYSTÉM CRM ======= \begin{figure}[ht] \begin{center} \scalebox{.43}{ \includegraphics{crm_complet.png} } \end{center} \caption{Diagram tříd subsystému CRM} \label{obr.crm_complet} Pozn.: Žlutě označené třídy nejsou prozatím implementované. \end{figure} Subsystém sestává ze~čtyř částí. Správa kampaní a správa odezev\footnote{Raději se přidržím anglického slova feedback.} (feedbacks), správa příležitostí a správa reportů. \begin{table}[htbp] \centering \begin{tabular}{|l|l||l|l|} \hline \textbf{Atribut} & \textbf{Typ} & \textbf{Atribut} & \textbf{Typ} \\ \hline ID (PK) & Integer & & \\ \hline Name & String & Cam\_Status\_id & Integer \\ Cam\_Type\_id & Integer & Start\_Date & Date \\ End\_Date & Date & Budget & Numeric \\ Expected\_Revenue & Numeric & Actual\_Cost & Numeric \\ Expected\_Cost & Numeric & Objective & Text \\ Description & Text & Assigned\_To\_id & Integer \\ Opportunity\_To\_id & Integer & User\_id & Integer \\ Created\_at & DateTime & Updated\_at & DateTime \\ \hline \end{tabular} \caption{Atributy třídy Campaign} \label{tab.camp_attributes} \end{table} Správa kampaní patří mezi nástroje marketingu, slouží například k~získávání nových nájemníků, k~řízení použití médií k~informování o~probíhajících akcích a novinkách. Každou kampaň je potřeba následně vyhodnocovat na~základě zpětné vazby, k~tomu slouží správa feedbacks. Jakmile budou jednotlivé feedback zadávány do~systému a spárovány s~příslušnou kampaní, automaticky je možné sledovat její vyhodnocení. \begin{figure}[ht] \begin{center} \scalebox{.53}{ \includegraphics{camp_class.png} } \end{center} \caption{Diagram třídy Campaign (kampaň) a souvisejících tříd} \label{obr.camp_class} Pozn.: Na~obrázku nejsou uvedeny některé atributy, protože Ruby On Rails má tu vlastnost, že běžně používané atributy tříd (modelů) jako je ID (primární klíč), Created\_at (DateTime) a Updated\_at (DateTime) jsou při~jejich vytváření vkládány zcela automaticky, proto nejsou v~diagramu uvedeny. \end{figure} \begin{figure}[ht] \begin{center} \scalebox{.500}{ \includegraphics{rank_flags.png} } \end{center} \caption{Možnosti výběru hodnocení reportu (Report Rank)} \label{obr.ranks} \end{figure} Správa příležitostí (opportunities) se řadí spíše mezi nástroje podpory analýzy trhu, tedy přesněji řečeno umožňuje zaznamenávat aktuální a budoucí možné příležitosti relevantní předmětu podnikání společnosti. Příležitosti mohou být jak typu nové podnikání (New Business), tak i~úprava stávajícího (Existing Business). Je patrné, že pokud bude chtít společnost využít příležitosti, jedním z~možných způsobů jak se chopit této šance je vedení příslušné kampaně či více kampaní v~rámci dané příležitosti. Správa reportů je nástroj podobný správě událostí, přesto určité rozdíly lze najít. Účel reportů je zcela odlišný od~událostí. Zatímco u~událostí evidujeme pouze, že se něco stalo, bez jakéhokoli hodnocení, jestli se jedná o~pozitivní či negativní záležitost, u~reportů je tomu přesně naopak. Správa reportů je tedy nástroj pro~vyhodnocování spokojenosti nájemníků. Jestliže si nájemník na~něco stěžuje či naopak uděluje pochvalu, zaznamená se tento fakt jako report s~příslušným hodnocením (report rank). Hodnocení se udává ve~škále od~\minus3 do~+3. Tedy existuje sedm možných hodnot, kdy -- znamená neutrální hodnocení. Pokud bude chtít uživatel zadat odpovídající hodnocení, nevybírá si z~uvedených čísel hodnot, ale zástupných znaků. Pozitivní hodnocení značí bílá vlaječka, čím více bílých vlaječek, tím lepší pozitivní hodnocení. Analogicky pak s~černými vlaječkami. Viz obrázek \ref{obr.ranks} \uv{\nameref{obr.ranks}}. Pro~výpočet hodnocení množiny příslušných reportů se pak pochopitelně používají zmíněné číselné hodnoty od~\minus3 do~+3, přičemž neutrální hodnocení -- nabývá hodnoty nula. \section{Billingový subsystém} \label{sec.billing} Tento subsystém bude mít na starosti evidenci plateb nájemníků, vystavování faktur (z~velké části by to mělo probíhat automatizovaně), určování periody plateb jednotlivých nájemníků (někdo může platit měsíčně, jiný čtvrtletně). Prozatím ale bude tato část systému silně \uv{ošizena}, protože bude mít na~starosti jen evidenci plateb. Přijde platba, tak ji uživatel zaeviduje. Systém bude s~přijatými platbami nakládat tak, aby na~dobře viditelném místě vypisoval ty uživatele, u~kterých není evidovaná platba za posledních 40 dní. Tj. zhruba jeden měsíc, což je zcela v~pořádku (měsíční platby nájemného), a zpoždění deset dní a více, což už je potřeba hlásit. Předběžně se také počítá s~propojením s~nějakou vhodnou internetovou platební branou pro~možnost placení nájemného on-line. \chapter{Realizace informačního systému} % ===== REALIZACE ISu ======= \section{Použité IT technologie} Pro~pořádek teď budou ve~stručnosti zmíněny technologie, které jsou (resp. budou) využívány vybudovaným informačním systémem. V~prvé řadě je vhodné zmínit, že celkový vzhled aplikace vychází z~html/css šablony \uv{Pluralism}, která je volně ke~stažení na~stránkách FreeCSSTemplates.org.\footnote{Shlédnutí na~web stránkách [online], [cit. 2010-05-24]. \url{http://www.freecsstemplates.org/}} Podmínky užití se aplikují dle Creative Commons Attribution 2.5.\footnote{Shlédnutí na~web stránkách [online], [cit. 2010-05-24]. \url{http://creativecommons.org/licenses/by/2.5/}} \subsection{PostgreSQL} Jedná se o~open source databázi. Aktuální verze \uv{postgresu} vydána v~prosinci 2010 je 8.4.2 (informace platná 20. února 2010). Bylo zvoleno toto řešení z~důvodu množství vlastností, které mi přišly důležité. MySQL je sice databáze nesmírně rychlá, ale stabilita a podpora transakcí a dalších funkcionalit je prozatím spíše horší. Na~internetu je poměrně hodně nejrůznějších srovnání, ale objektivních a nezávislých pomálu. Vycházel jsem především z~přednášek a osobních rozprav s~techniky společnosti Seznam.cz, kteří vedli sérii přednášek na~Fakultě informatiky MU v~předmětu \uv{PV201 Portálové technologie v praxi}. \subsection{Ruby On Rails} Ruby je programovací a scriptovací jazyk. Ruby On Rails je framework určen k~vývoji webovských aplikací. Ačkoli je RoR\footnote{Místo zdlouhavého Ruby On Rails budu používat zkratku RoR.} poměrně novou záležitostí, je pomocí něj napsána celá řada známých webů. Mezi nejznámější bude pravděpodobně patřit jeden ze~současných hitů -- systém pro~mikroblogování Twitter.\footnote{Twitter [online] na~adrese \url{http://www.twitter.com/} [cit. 2010-02-20].} Aktuální verze Rails (platná 20. února 2010) je 2.3.5 vydána listopadu 2009. Tento rok by měla přijít zcela nová majoritní verze 3.x, která vznikne sloučení Rails a jiného původního frameworku Merb.\footnote{Informace lze nalézt online na~stránkách Merb. Adresa: \url{http://www.merbivore.com/} \cite{merb1}}. Také se jedná o~framework pro~jazyk ruby a sloučením si vývojářské týmy slibují převzetí těch nejlepších vlastností z~obou. RoR samotné je vyvíjeno agilní metodikou\footnote{Informace o~této metodice lze nalézt například na~stránkách Root.cz [online], na~adrese \url{http://zdrojak.root.cz/serialy/agilni-vyvoj/}. \cite{kne1}} a je určeno pro~agilní programování. Agilní metodikou bude vyvíjen i~informační systém s~podporou CRM, který je předmětem této práce. \begin{itemize} \item \textbf{Architektura MVC} \uv{Model -- View -- Controller}: V~modelu je uložena struktura dat aplikace včetně pravidel pro~práci s~nimi. Pohled (view) říká, jakým způsobem se mají zpracovaná data zobrazit. Kontrolér (controller) to všechno řídí.\footnote{Více informací online například na~stránkách Ruby On Rails na~adrese \url{http://guides.rubyonrails.org/} (v~angličtině) [cit. 2010-01-20]. Dále pak \cite{ror1}.} Pozn.: Ruby On Rails mají tu vlastnost, že běžně používané atributy tříd (modelů) jako je ID (primární klíč), Created\_at (DateTime) a Updated\_at (DateTime) jsou při~jejich vytváření vkládány zcela automaticky. Proto v~diagramech znázorněných v~této práci nejsou tyto uvedeny. \item \textbf{DRY} je zkratka anglickeho výrazu \uv{Don't repeat yourself}. Není třeba znovu psát kód, který už byl jednou napsán. Kromě zbytečného opakování již jednou napsaného je cílem také maximální jednoduchost, přehlednost a úspora. \item \textbf{COC} je opět zkratka, tentokrát výrazu \uv{Convention Over Configuration}. Tento přístup říká, že není potřeba konfigurovat něco, u~čeho je známa nejběžnější konfigurace.\footnote{Více informací k~DRY a CoC lze nalézt například na~stránkách Ruby On Rails, adresa: \url{http://wiki.rubyonrails.org/getting-started/overview/tenets}. [cit. 2010-02-20].} Jak už jsem několikrát zmínil, jedná se například o~přidávání atributů ID do~modelů jako primární klíč typu integer (na~databázové úrovni se jedná o~atribut entity). Čili pokud chceme tento atribut použít, není třeba tento fakt explicitně zadávat, naopak v~okamžiku, kdy si nepřejeme tento použít, musíme declarovat potlačení jeho vytvoření. \end{itemize} \subsection{Apache a linux} Ačkoli jsou Mongrel a Webrick web systémy určené pro~hostování RoR aplikací, rozhodl jsem se pro~univerzální web server Apache. Aby bylo možné apache pro~hostování RoR použít, je nutné doinstalovat tzv. mod\_rails plugin, znám také jako Passenger.\footnote{Informace dostupné online na~stránkách Phusion Passenger [online], [cit. 2010-02-10] na~adrese \url{http://www.modrails.com/}} RoR, Apache i~PostgreSQL jsou plně podporovány na~všech běžných linuxových distribucích. Zatím není rozhodnuto, na~které distribuci informační systém poběží, ale buď se bude jednat o~Debian nebo Ubuntu Server. Ačkoli se jedná o~různé distribuce, Ubuntu vychází z~Debianu, takže instalace a správa aplikací je velice podobná. Předběžně se ale počítá s~nasazením na~Debian. \subsection{Ruby Enterprise Edition} Ruby Enterprise Edition REE je výsledek práce nizozemské společnosti Phusion. Zajišťuje plnou kompatibilitu s~originálním vydáním Ruby On Rails a zároveň s~kombinací Phusion Passanger vysokou výkonnost.\footnote{Srovnání s~jinými systémy na~stránkách Phusion [online], [cit. 2010-05-24] na~adrese \url{http://www.rubyenterpriseedition.com/comparisons.html}} \section{Řízení přístupu, autorizace} Pro~podporu autentizace byl použit plugin Authlogic, pro~podporu autorizace pak plugin Declarative\_Authentication. Přístupu ke~zdrojům systému je řízen na~úrovních: \begin{itemize} \item Controller Zde je možné řídit přístup k~jednotlivým akcím (a tedy pokud není povolen přístup k~akci, není možné zobrazit ani příslušný view). \item Model Řízení přístupu až na~úroveň CRUD (Create, Read, Update, Delete) záznamů modelu. \item View Řízení toho, co se má nebo nemá zobrazit (například odkazy, statistiky jen pro~vedení společnosti nikoli pro~běžné zaměstance) \end{itemize} K~čemu uživatelé dle svých uživatelských rolí mají či nemají přístup je řešeno v~konfiguračním souboru authorization\_rules.rb. Zkrácený příklad nadefinování role autentizovaného uživatele (ve~vytvořeném systému všechny role dědí tuto roli, čili mají taktéž tato oprávnění): \begin{verbatim} role :auth_user do has_permission_on :roles, :to => [:index, :show] has_permission_on :dashboard, :to => :index has_permission_on :users, :to => [:index, :show] has_permission_on :users, :to => [:edit, :update] do if_attribute :id => is { user.id } end end \end{verbatim} Uživatel s~touto rolí může prohlížet uživatelské role, dále pak zobrazit úvodní stránku systému Dashborad, může prohlížet uživatele, ale editovat pouze sebe. Dotaz se tedy ptá, jestli id přihlášeného uživatele (current\_user) odpovídá atributu user.id (aktuálně editovaného uživatele). \section{Přehled funkcí} Na~základě analýzy a návrhu byly implementovány funkce, které umožňují využití systému tak, jak bylo zamýšleno (viz tabulku \ref{tab.func_overview} \uv{\nameref{tab.func_overview}} na~straně \pageref{tab.func_overview}). Jaké funkce systém nabízí si lze představit ze~seznamu kontrolérů. Každý controller ovládá množství akcí příslušných jak k~modelu, tak i~k~pohledům (views). Například controller Dashborad ovládá jednu akci pro~vypsání/zobrazení úvodní autentizované stránky systému a výpočet aktuálních statistik z~dat uložených v~modelech. Jiný controller, například Campaigns ovládá více akcí, konkrétně se jedná o~akce: \begin{itemize} \item Index (vypisuje úvodní stránku se~seznamem kampaní) \item Show (vypisuje zvolenou kampaň) \item New (vytváří prázdnou instanci objektu kampaň) \item Edit (vyhledá požadovanou kampaň pro~editaci) \item Create (ukládá nový záznam o~kampani) \item Update (ukládá změny v~záznamu příslušné kampaně) \item Destroy (odstraňuje zvolený záznam o~kampani) \end{itemize} Čili ikdyž controller Campaigns obsahuje více akcí, dá se obecněji říci, že jednou z~funkcionalit systému je správa kampaní. Tedy lze takto generalizovat. Seznam funkcí na~základě controllerů v~systému je vypsán v~následující tabulce \ref{tab.func_overview} \uv{\nameref{tab.func_overview}}. \begin{table}[htbp] \centering \begin{tabular}{|l|l|} \hline \textbf{Název} & \textbf{Popis} \\ \hline Amenities & Správa vybavení apartmánů \\ Apartments & Správa apartmánů \\ Buildings & Správa budov \\ Campaigns & Správa kampaní \\ Communities & Správa AC \\ Companies & Správa společností \\ CRM & CRM dashboard \\ Dashboard & Přehledová stránka \\ Events & Správa událostí \\ Feedbacks & Správa odezev \\ Home & Neautentizovaná část \\ Opportunities & Správa příležitostí \\ Org\_Units & Správa org. jednotek \\ Rec\_Pay\_Types & Správa typů přijatých plateb \\ Received\_Payments & Správa přijatých plateb \\ Reports & Správa reportů \\ Roles & Správa uživatelských rolí \\ Sec\_Records & Správa uživatelských aktivit \\ System & Přehled systému \\ Tenant\_Contracts & Správa nájemních smluv \\ Tenants & Správa uživatelů \\ User\_Sessions & Správa autentizace \\ Users & Správa uživatelů \\ \hline \end{tabular} \caption{Základní přehled funkcí systému} \label{tab.func_overview} Pozn.: Seznam je seřazen abecedně. \end{table} \section{GUI, popis vybraných částí systému} \subsection{Dashboard} Úvodní stránka (neautentizovaná část) obsahuje mimo jiného i~kolonku pro~zadaní uživatelského jména (dle specifikace se jedná o~emailovou adresu uživatele) a příslušné heslo. Po~autentizaci je uživatel automaticky přesměrován na~úvodní autentizovanou stránku samotného systému, viz obrázek \ref{obr.dashboard} \uv{\nameref{obr.dashboard}}. \begin{figure}[ht] \begin{center} \scalebox{.51}{ \includegraphics{dash_view.png} } \end{center} \caption{Úvodní autentizovaná stránka systému (Dashboard)} \label{obr.dashboard} \end{figure} Zcela nahoře nad~modrým pozadím se nachází hlavní menu. Mimo jiného se zde nachází i~jméno aktuálně přihlášeného uživatele. Uživatelské role Administrator, Owner a Company Manager pak také vidí odkaz do~systémové části, běžní uživatelé nikoli. Zcela napravo stránky se nachází kontextové menu, ze~stránky Dashboard se lze prakticky dostat kamkoli, nejčasti pak bude zřejmě využívána část Tenants, odkaz Tenant List (nájemníci). Číslice nalevo od~odkazů v~tomto menu značí, kolik záznamů se v~příslušné sekci nachází. Stránka Dashboard obsahuje přehled několika statistik jako jsou vytíženost apartmánů dle jednotlivých AC a budov, seznam nájemníků, kteří doposud nezaplatili tak jak měli (dle návrhu v~podkapitole \ref{sec.billing} \uv{\nameref{sec.billing}} na~straně \pageref{sec.billing}). Dále pak posledních šest aktivit provedené v~systému a zcela dole je pak seznam aktuálně přihlášených uživatelů.\footnote{Zjišťuje se podle poslední akce v~systému v~posledních deseti minutách.} \subsection{Tenants} \begin{figure}[ht] \begin{center} \scalebox{.55}{ \includegraphics{ten_view_sml.png} } \end{center} \caption{Ilustrace rozšířených detailů nájemníka} \label{obr.ten_view_sm} \end{figure} Úvodní stránka sekce Tenants zobrazí seznam nájemníků. Pokud přejdeme do~detailů některého nájemníka (klepnutím na~uživatelovo jméno), zobrazí se stránka podobná ilustraci \ref{obr.tenant_view} \uv{\nameref{obr.tenant_view}} na~straně \pageref{obr.tenant_view}. Stránka má v~horní části detailů uvedeny základní údaje o~nájemníkovi jako jsou jméno, příjmení, telefonní kontakt a další. Pod~těmito údaji se nachází seznam nájemních smluv, které má nájemník se~společností aktuálně uzavřené a platné. Níže pak lze nalézt informace o~posledních čtyřech přijatých platbách nájemníka. Ještě níže pak vyhodnocování spokojenosti nájemníka na~základě reportů v~posledním měsíci. Ve~zcela dolní části jsou pak uvedeny všechny nájemní smlouvy, které kdy byly uzavřeny. Reporty o~nájemnících se budou zadávat pravidelně (měsíčně) i~nepravidelně (například v~souladu s~mimořádnými událostmi). Pravidelné měsíční reporty by měly být zakládány v~okamžiku, kdy nájemník osobně přijde zaplatit měsíční nájemné,\footnote{Je to s~podivem, ale osobní náštěva kanceláře je zatím nejčastějším způsobem předání platby.} buď v~hotovosti (cash) nebo pomocí šeku (check). V~tu chvíli má zaměstnanec povinnost zeptat se nájemníka na~spokojenost s~ubytováním a na~ostatní záležitosti, které se~toho týkají. \subsection{CRM} Hlavní stránka CRM obsahuje tzv. Reporter. Ten zobrazuje statistiky a vyhodnocení kampaní, reportů a seznam příležitostí, které jsou aktivní (neexpirovaly). \begin{figure}[ht] \begin{center} \scalebox{.50}{ \includegraphics{crm_view_reporter.png} } \end{center} \caption{Ilustrace funkce Reporter CRM} \label{obr.crm_view_rep} \end{figure} Seznam kampaní se~statistikami je tvořen pouze kampaněmi, které jsou ve~stavu (mající status) started, completed, finished. U~kampaní s~jiným statusem nemají statistiky smysl, například u~kampaní, které se ještě nerozběhly. Nebo kampaně, které jsou již uzavřené, u~těchto již jsou statistky irelevatní. Pokud však i~přesto má uživatel zájem shlédnout odezvy a vyhodnocení některé z~uzavřených kampaní, pak si příslušnou kampaň samozřejmě může vyhledat přímo v~sekci kampaní (přes odkaz Campaigns). Statistiky reportů jsou setříděny podle AC (Community). Protože reportů může být mnoho, CRM Reporter vypisuje pouze reporty zadané za~posledních 24 hodin. Čili nevypisuje pouze jejich celkové hodnocení (Average Rank), ale přímo jejich seznam. V~sekci kampaní (Campaigns) lze v~detailech jednotlivých kampaní vidět v~horní části základní údaje o~kampani, jejích cílech, očekávaný přínos, očekávaná cena, aktuální cena a další. V~dolní části jsou pak uvedeny relevantní odezvy (Feedbacks) a na~závěr jejich zhodnocení, tedy zhodnocení celé kampaně. Viz obrázek \ref{obr.camp_view_full} \uv{\nameref{obr.camp_view_full}} na~straně \pageref{obr.camp_view_full}. \section{Požadavky na~SW a HW} \subsection{Server} Kromě dříve vyjmenovaných technologií nemá systém žádné zvláštní nároky. Běžně je uváděno, že na~provoz aplikace RoR je potřeba minimálně 50 MB operační paměti. To se jedná pochopitelně o~malé aplikace do~počtu pěti uživatelů. Tak jak se systém nastaven nyní a pro~potřeby společnosti se~zhruba 12 až 15 uživateli by mělo postačovat 300 MB operační paměti. Co se týče nároků systému řízení baze dat, situace je o~něco komplikovanější. Sice jsem dříve v~textu uváděl PostgreSQL, ale ve~skutečnosti není vyvinutý systém nijak vázán na~zmíněný PostgreSQL. Naprosto lehce lze změnit konfigurační soubor pro~použití databáze tak, že lze prakticky okamžitě využívat jiné systémy, jako například MySQL, Oracle, MS SQL nebo Informix. \subsection{Klient} Aplikace je založena na~web technologii, takže je pochopitelně nutné mít webový prohlížeč. Systém využívá některé unicode znaky, které jsou zobrazitelné např. jak ve FireFoxu, tak i~v~Opeře, bohužel Internet Explorer si s~tím nedokáže poradit. Dále pak dobré připojení k~počítačové síti, popřípadě k~internetu v~závislosti na~tom, kde bude běžící aplikace uložena, jestli v~podnikové síti či na~serveru internetu. Nároky na~šířku pásma připojení jsou poměrně nízké, mělo by postačit i~256 kb/s, ale připojení by mělo být bez~výpadků, protože některé části systému využívají AJAXové podpory, ikdyž zatím ve~velmi omezené míře. \section{Aplikace online} \label{apl_online} Aplikaci si lze vyzkoušet na~adrese: \url{http://85.135.106.70/}. Pro přihlášení použijte následující iniciály bez uvozovek. \begin{itemize} \item \textbf{Vedoucí práce} Login name: \uv{ph@vedouci.cz} (což figuruje jako fiktivní e-mailová adresa) Heslo: \uv{phvedouci} \item \textbf{Oponent} Login name: \uv{opo@oponent.com} (což figuruje jako fiktivní e-mailová adresa) Heslo: \uv{pan\_oponent} \end{itemize} Stejné iniciály se pak zadávají do~aplikace, kterou si lze i~nainstalovat. Více viz přílohu \ref{navod_instalace} \uv{\nameref{navod_instalace}} na~straně \pageref{navod_instalace}. \chapter{Závěr} Bylo za~úkol zaměřit se na~problematiku CRM systémů, zjistit jejich vlastnosti a definovat běžné požadavky, které jsou na~ně kladeny. V~současnosti můžeme pozorovat čím dál větší rozmah těchto systémů, společnosti po~celém světě se čím dál více orientují na~zákazníky nejen na~ty, které by mohly získat, ale především na~ty stávající. Více než kdy jindy v~historii se zvětšuje a zostřuje konkurenční prostředí na~trhu, nejen díky kvalitě (v~západních vyspělých státech), ale i~kvantitě (Čína, Indie). Samozřejmě nelze opomenout (snad již odcházející) světovou hospodářskou krizi. Všechny tyto atributy trhu vyvíjejí tlak na~společnosti, aby se více zajímaly o~to, co skutečně zákazník požaduje a potřebuje. Druhým cílem bylo pro~zvolenou společnost vyvinout systém, který by umožňoval evidovat apartmány a jejich vybavení, nájemníky a jejich platby, včetně podpory Customer Relationship Management. Tento subsystém CRM je naprosto provázán s~ostatními částmi systému, stal se tak jeho nedílnou součástí. Původně jsem zamýšlel, že v~době obhajoby již bude systém v~provozu a mohl bych tak ukázat přímo reálná data, ale prozatím nebylo možné se se~společností E-State Management, L.L.C. dohodnout. Nasazení proběhne až někdy v~průběhu července letošního roku. Nicméně již byla provedena ukázka systému ve~jmenované společnosti a v~současné době se jedná, kde bude systém umístěn, zda-li na~nějakém serveru v~internetu či na~serverech společnosti. Zavedení systému půjde pochopitelně ruku v~ruce s jistými modifikacemi firemních procesů, ale sami zaměstnanci začínají chápat, že se bude jednat především o~zrychlení a zjednodušení některých rutinních činností. Čili jak je asi zřejmé, další vývoj systému se obhajobou této práce nezastaví, je vůlí mou i~vedení zmíněné firmy, aby se v~něm pokračovalo. % *************** Bibliografické reference ***************** \begin{thebibliography}{xxx99} \markright{\bibname} \bibitem[Chl05]{chleb1} CHLEBOVSKÝ, Vít. \textit{CRM : řízení vztahů se~zákazníky.} 1. vyd. Brno : Computer Press, a. s., 2005. 190 s. ISBN 80-251-0798-1. \bibitem[Chl04]{chleb2} CHLEBOVSKÝ, Vít. \textit{řízení vztahů se~zákazníky ({CRM}): tvorba koncepce a její implementace.} Brno : Vysoké učení technické v Brně, 2004. 31 s. ISBN 80-214-2757-4. ISSN 1213-4198. \bibitem[Leh07]{lehtinen1} LEHTINEN, Jarmo R. \textit{Aktivní CRM: řízení vztahů se~zákazníky.} Alena Svozilová. 1. vyd. Praha: Grada Publishing a. s., 2007. 158 s. ISBN 978-80-247-1814-9. \bibitem[Gef01]{protivnik} GEFFROY, Edgar K. \textit{Zákazník - náš protivník, nebo partner?} Přeložil Jiří Pondělíček. 1. vyd. Praha : Management Press, 2001. 199 s. ISBN 80-7261-034-1 \bibitem[Leh02]{jarmo1} STORBACKA, Kaj, LEHTINEN, Jarmo R. \textit{řízení vztahů se~zákazníky (Customer Relationship Management).} Překlad: Bohumila Sedloňová. 1. vyd. Praha . Grada Publishing, spol. s r. o., 2002. 168 s. ISBN 80-7169-813-X. \bibitem[Nov06]{novy1} NOVÝ, Ivan, PETZOLD, Jörg. \textit{(Ne)spokojený zákazník - náš cíl?!} 1. vyd. Praha : Grada Publishing, a.s., 2006. 160 s. ISBN 80-247-1321-7. \bibitem[Wes03]{wessling1} WESSLING, Harry. \textit{Aktivní vztah k~zákazníkům pomocí CRM.} 1. vyd. Praha : Grada Publishing, a.s., 2003. 196 s. ISBN 80-247-0569-9. \bibitem[Bur02]{burnett1} BURNETT, Ken. \textit{Klíčoví zákazníci a péče o ně.} Překlad: Eva Nevrlá. 1. vyd. Praha : Computer Press, 2002. 382 s. ISBN 80-7226-655-1. \bibitem[But04]{buttle2} BUTTLE, Francis. \textit{Customer Relationship Management : Concepts and Tools.} 1st edition. Oxford : Elsevier Butterworth-Heinemann, 2004. 359 s. ISBN 0-7506-5502-X. \bibitem[Mat07]{system1} MATES, Jiří, ŠILLEROVÁ, Martina. Proč segmentovat? \textit{časopis IT Systems} [online]. Roč. 2007, č. 12 [cit. 2009-12-13]. Dostupný z~WWW: \texttt{<}\url{http://www.systemonline.cz/crm/proc-segmentovat-1.htm}\texttt{>} ISSN 1802-615X. \bibitem[Tom06]{system2} TOMÁŠKOVÁ, Daniela, Vass, Martin. Cesta k~úspěšnému řízení vztahů se~zákazníky. \textit{časopis IT Systems} [online]. Roč. 2006, č. 11 [cit. 2009-12-11]. Dostupný z~WWW: \texttt{<}\url{http://www.systemonline.cz/crm/cesta-k-uspesnemu-rizeni-vztahu-se-zakazniky.htm}\texttt{>}. ISSN 1802-615X. \bibitem[Hra09]{compworld1} HRADEČNÝ, Vítek. CRM, BI a řízení kampaní. \textit{ComputerWorld}. IDG Czech, a. s. Roč. XX, č. 17, 9. -- 22. 10. 2009, s 27. ISSN 1210-9924. \bibitem[Lou09]{compworld2} LOUDA, Pavel. Byznys. \textit{ComputerWorld}. IDG Czech, a. s. Roč. XX, č. 21, 4. -- 10. 12. 2009, s 7. ISSN 1210-9924. \bibitem[CIO09]{ciobw1} JIRÁSKO, Tomáš. IS v~malých společnostech. \textit{Cio Business World}. IDG Czech, a. s. 2009, č. 12, prosinec 2009, s 36. ISSN 1803-7321. \bibitem[SIC09]{konference1} BÁCA, Stanislav. Next B-2-B Collaboration - How SRM, SCM and CRM Can Create Efficient and Flexible Business. \textit{Systems Integration Conference Archive} [online]. Rok 2002 [cit. 2009-12-24]. Dostupný z~WWW: \texttt{<}\url{http://si.vse.cz/archive/presentations/2002/next-b2b-collaboration-how-srm-scm-and-crm-can-/create-efficient-and-flexible-business.pdf}\texttt{>}. \bibitem[Gar08]{gartner1} \textit{Gartner Says Worldwide CRM Market Grew 12.5 Percent in 2008.} [online]. Stamford, CT, USA: Gartner, Inc., July 15 2009 [cit. 2009-12-26]. Dostupný z~WWW: \texttt{<}\url{http://www.gartner.com/it/page.jsp?id=1074615}\texttt{>}. \bibitem[Kon09]{noviny1} \textit{Konkursní noviny} [online]. Praha : Cooper press s. r. o., 1998, 18. listopadu 2009 [cit. 2009-12-06]. Dostupný z~WWW: \texttt{<}\url{http://www.konkursni-noviny.cz/}\texttt{>}. \bibitem[Ham10]{hampejs1} HAMPEJS, Petr. Komerční firmy v česku jsou v adopci CRM pozadu za vyspělými zeměmi. \textit{ITBiz.cz} [online]. Stickfish s. r. o. 2. únor 2010. [cit. 2010-01-14]. Dostupný z~WWW: \texttt{<}\url{http://www.itbiz.cz/petr-hampejs-aktualni-trendy-crm}\texttt{>}. ISSN 1802-1581. \bibitem[Cam10]{cambridge1} \textit{Cambridge Dictionaries Online: Cambridge Advanced Learner's Dictionary} [online]. Cambridge University Press. 2010. [cit. 2010-01-16]. Dostupný z~WWW: \texttt{<}\url{http://dictionary.cambridge.org/Default.asp?dict=CALD}\texttt{>}. \bibitem[Vel09]{compworld3} VELECKÝ, Petr. ERP systémy pro SMB. \textit{ComputerWorld}. IDG Czech, a. s. Roč. XX, č. 16, 25. 9. -- 8. 10. 2009, s 20. ISSN 1210-9924. \bibitem[SOL10]{system3} CRM systémy. \textit{System OnLine}. [online] CCB spol. s r. o. 2001 -- 2010. [cit. 2010-02-19]. Dostupný z~WWW: \texttt{<}\url{http://www.systemonline.cz/prehled-informacnich-systemu/crm-systemy/}\texttt{>}. ISSN 1802-615X. \bibitem[MER10]{merb1} \textit{Merb}. [online] 2010. [cit. 2010-02-20]. Dostupný z~WWW: \texttt{<}\url{http://www.merbivore.com/}\texttt{>}. \bibitem[ROR10]{ror1} \textit{Ruby On Rails}. [online] 2010. [cit. 2010-02-20]. Dostupný z~WWW: \texttt{<}\url{http://www.rubyonrails.org/}\texttt{>}. \bibitem[PSQ10]{psq1} \textit{PostgreSQL}. [online] 2010. [cit. 2010-02-20]. Dostupný z~WWW: \texttt{<}\url{http://www.postgresql.org/}\texttt{>}. \bibitem[MOD10]{mod1} \textit{Phusion Passenger}. [online] Phusion, 2010. [cit. 2010-02-20]. Dostupný z~WWW: \texttt{<}\url{http://www.modrails.com/}\texttt{>}. \bibitem[Kne09]{kne1} KNESL, Jiří. Seriál Agilní vývoj. \textit{Root.cz}. [online] Internet Info, s.r.o., 11. 12. 2009. [cit. 2010-02-21]. Dostupný z~WWW: \texttt{<}\url{http://zdrojak.root.cz/serialy/agilni-vyvoj/}\texttt{>}. ISSN 1803-5620. \bibitem[RCS10]{rcs1} \textit{RailsCasts}. [online] 2010. [cit. 2010-05-28]. Dostupný z~WWW: \texttt{<}\url{http://www.railscasts.com/}\texttt{>}. \bibitem[FCT10]{fct1} Pluralism. \textit{FreeCssTemplates.org}. [online] 2010. [cit. 2010-05-28]. Dostupný z~WWW: \texttt{<}\url{http://www.freecsstemplates.org/preview/pluralism/}\texttt{>}. \end{thebibliography} %\bibliographystyle{plain} % bibliografický styl %\bibliography{citace} % soubor s citovanými % položkami bibliografie \listoffigures \listoftables \appendix \chapter{Případy užití v~základním subsystému} \begin{figure}[ht] \begin{center} \scalebox{.70}{ \includegraphics{zaklad_use2_big.png} } \end{center} \caption{Případy užití v~základním subsystému (aktivity)} \label{obr.zaklad_use2_big} \end{figure} \begin{figure}[ht] \begin{center} \scalebox{.65}{ \includegraphics{zaklad_use_big.png} } \end{center} \caption{Případy užití v~základním subsystému (uživatelé)} \label{obr.zaklad_use_big} \end{figure} \chapter{Ilustrace zobrazení detailů nájemníka} \begin{figure}[ht] \begin{center} \scalebox{.46}{ \includegraphics{tenant_view.png} } \end{center} \caption{Zobrazení detailů nájemníka} \label{obr.tenant_view} Pozn.: Ilustrace je bez~horní a boční lišty s~nabídkami. \end{figure} \chapter{Ilustrace hlavní stránky CRM s~Reporterem} \begin{figure}[ht] \begin{center} \scalebox{.40}{ \includegraphics{crm_full_view.png} } \end{center} \caption{Celkový pohled na~hlavní stránku CRM} \label{obr.crm_view_reporter_full} \end{figure} \chapter{Ilustrace detailů vybrané kampaně} \begin{figure}[ht] \begin{center} \scalebox{.40}{ \includegraphics{camp_view.png} } \end{center} \caption{Celkový pohled na~detaily vybrané kampaně} \label{obr.camp_view_full} \end{figure} \chapter{Ilustrace správy odezev (Feedbacks) kampaní} \begin{figure}[ht] \begin{center} \scalebox{.40}{ \includegraphics{fb_view.png} } \end{center} \caption{Celkový pohled na~odezvy kampaní} \label{obr.fb_view_full} \end{figure} \chapter{Návod na~instalaci systému} \label{navod_instalace} Stručný popis instalace systému na~linuxu. \begin{itemize} \item Instalace systému PostgreSQL a Ruby On Rails (dle oficiálních návodů na~stránkách projektů)\footnote{Na~stránkách \url{http://www.postgresql.org/}} \footnote{Na~stránkách \url{http://www.rubyonrails.org/}} \item Instalace vhodného Gemu pro~připojení k~PostgreSQL databázi (například \uv{ruby-pg}). \item Konfigurace souboru application/config/database.yml (konfigurace připojení k~databázi server host, port, název databáze, uživatelské jméno a heslo). \item Instalace gemu authlogic-2.1.3 a ostatních. V~adresáři \uv{Gems} na~přiloženém CD je příslušný gem. Od~23.~května není možné použít aktuální gem z~repozitářů, protože není kompatibilní s~předchozí verzí. Nekompatibilita byla nahlášena jako bug, ale zatím není opravena. Ostatní gemy se instalují jednoduše příkazem \uv{rake gems:install} spuštěný v~kořenovém adresáři aplikace (nahrají se z~internetového repozitáře). \item Vytvoření databáze a databázové struktury (příkazem \uv{rake db:create db:migrate}), nahrání zálohy databáze (záloha databáze je uložena v~adresáři \uv{BackUp} na~přiloženém CD, nahrát lze například pomocí aplikace pgAdmin. \item Spuštění aplikace (lze provést vestavěným webovým server Mongrel či Webrick, například příkazem \uv{script/server}). Pro~přihlášení do~aplikace se použijí inicály uvedené na~straně \pageref{apl_online}, v~podkapitole \ref{apl_online} \uv{\nameref{apl_online}}. \end{itemize} \chapter{Obsah přiloženého CD} Struktura je členěna na~čtyři adresáře. \begin{itemize} \item \textbf{BackUp} Obsahuje zálohu databáze PostgreSQL, která obsahuje vzorová data aplikace. \item \textbf{Gems} Obsahuje použité gemy v~aplikaci. \item \textbf{Source} Obsahuje samotnou vytvořenou aplikaci \uv{ApIS}. \item \textbf{Text} Obsahuje samotný text práce včetně zdrojového souboru pro~\LaTeX. \end{itemize} \end{document}