Grand Princ Media – vydavatelství print i online médií

Datum: 18.02.2017

Na sklonku roku 2015 jsem byl osloven společností Grand Princ Media (dále jen GPM) s žádostí, zda bychom nemohli společně něco udělat s jejich informačním systémem. Nutno podotknout, že situace v GPM byla opět diametrálně odlišná než např. situace v advokátní kanceláři či People Management Foru, které jsou popsány na jiném místě zde na webu. Firmu obhospodařoval velice propracovaný systém Grand Master realizovaný na míru v průběhu předchozích zhruba 12 let. Bohužel přes veškerou snahu jeho autora systém zastarával, postrádal aktuální integrační schopnosti a v neposlední řadě nedisponoval uživatelsky příjemným UI. Náklady na jeho údržbu a rozvoj byly také neúměrné dnešním standardům.

Úvodní schůzka napověděla, že jsme schopni na trhu nalézt produkty, které by mnohem více vyhovovaly aktuálním požadavkům firmy na „svůj“ systém, a které by zároveň příliš nezatížily rozpočet. Zvolili jsme formu postupného analyzování aktuálních potřeb a následné přípravy kompletní architektury, která by posloužila jednak jako zadání pro customizaci budoucího systému, a jednak jako dokumentace pro aktuální mapu procesů i databázových struktur.

Změna myšlení jako důležitý start

Vůli společnosti „něco změnit“ jistě napomohla má známost s projektovým manažerem za GPM, Markem Jiranem. Věděl a ví, co ode mne může očekávat a byl připraven nové myšlenky podpořit. Přesvědčit jednatele a majitele GPM o správnosti těchto kroků se tak stalo o něco méně obtížným úkolem. Ukázalo se, že práce se stávajícím systémem se stala natolik náročná (především časově), že prakticky není na běžnou agendu využíván a „zkratky“ a „objížďky“ systému ve firmě natolik zakořenily, že se staly pro přijetí upravených procesů větší překážkou, než přítomnost zavedeného SW.

Stanovili jsme si tedy v malém projektovém týmu pravidelná setkání a věnovali zvýšené úsilí úvodní analýze, kde jsem identifikoval všechny důležité oblasti, které je potřeba pokrýt a naplánoval také způsob, jakým budou interně představeny. Marek zajišťoval projekt interně a zastupoval grafické oddělení. David, majitel a jednatel, pak představoval své manažerské potřeby a chybějící systémy kontroly. Často jsme na schůzky přibírali také Lucku, která jako ekonomka a asistentka majitele věděla o mnoha zákoutích více než ostatní.

„Jasně, že je lepší, kdybychom měli všechno v jedné aplikaci. Ale to nikdy nefunguje…“

I taková slova můžete slyšet při startu projektu od klíčových uživatelů. Uživatelů příliš dlouhou dobu uzavřených v bublině vlastní reality, které se za více než dekádu nepřizpůsobila. A nemyslím teď přizpůsobit se trendům. Myslím tím přizpůsobit se vlastním měnícím se požadavkům.

Ruku na srdce. Kolikrát už někdo splnil vaše požadavky a vy jste se přesto cítili tak nějak neuspokojeni?

Co z dosavadních procesů a SW zanechat, co naopak zahodit?

Nikdy není nutné zahodit vše dosud budované – firma působí na trhu přes deset let, takže „něco asi musí dělat dobře“. Úkolem člověka, který chce firmě OPRAVDU pomoci, není postavit na stůl řešení za milion a v padnoucím obleku za pomoci dokonalé powerpointové prezentace přesvědčit jednatele, že koupí téhle krabice vyřeší své problémy. Jeho úkolem je vzít to, co je dobré a doplnit to tím, co může po důkladné analýze doporučit tak, aby to jako celek přinášelo firmě přidanou hodnotu. A ano, samozřejmě splnilo požadavky. Ruku na srdce – kolikrát už někdo splnil vaše požadavky a vy jste se přesto cítili tak nějak neuspokojeni? Přílišný důraz na výkon, plnění plánů a fixování scopu (tedy obsahu zadání) odvrátil mnoho dodavatelů IT řešení jejich „poslání“ na trhu. Tedy dát firmě přidanou hodnotu.

„Úkolem člověka, který chce firmě OPRAVDU pomoci, není postavit na stůl řešení za milion a v padnoucím obleku za pomoci dokonalé powerpointové prezentace přesvědčit jednatele, že koupí téhle krabice vyřeší své problémy.“

Pokud společnost využívá Google services, spravuje své účty pomocí gmailu a velká produkční data ukládá a zálohuje prostřednictvím google drive, proč ne? Otázka použití samostatného účetního SW, v tomto případě Pohoda, je již poněkud problematičtější. V případě GPM šlo ovšem o opodstatněné důvody zachování tohoto software v architektuře systému a v seznamu klíčových faktorů pro výběr budoucího jednoduše přibyl řádek nutnosti integrace. V podstatě to dopředu diskvalifikovalo systému bez hotového převodního můstku. To ovšem nevnímám jako velký problém, spíše jako pozitivní důsledek fáze vstupní analýzy.

Jak jsem již nastínil výše, větší oříšek byla analýza procesů. Klíčovým procesem společnosti je zakázka – resp. způsob získávání zakázek a s tím propojené odměňování obchodních zástupců pomocí provizního systému a kontrola efektivity práce OZ. Zde musely nastat změny radikální, zatímco např. proces výroby většiny inzertních i redakčních formátů mohl zůstat v nezměněné podobě (pouze podpořen novým SW), ovšem s úpravou procesu výroby jednotlivých titulů jako celku.

Rozbor transformačních míst aneb ptejme se lidí, jak jim můžeme pomoci

Jako v mnoha jiných prostředích jsem se i zde setkal s počátečním přesvědčením, že lidé ve vedení společnosti či projektu „vědí dobře, jak by měl systém fungovat“. Je to překážka, to jistě. Za mě ale převažuje spokojenost s tím, že si alespoň uvědomují, že sami nedokážou vhodně zvolit, „jak toho docílit“.

„Transformační místa – uživatelé – nejsou stroje dokola opakující naprogramovaný úkon. Oni u své práce přemýšlí a často nabízí unikátní pohled na low-level úrovni detailu, který manažer prostě nemá.

Naštěstí David i Marek jsou oba lidé otevření novým myšlenkám a netrvalo tak dlouho, než pochopili, že se zaměstnanců GPM nejenže ptát můžeme, ale dokonce musíme. Transformační místa – uživatelé – nejsou stroje dokola opakující naprogramovaný úkon. Oni u své práce přemýšlí a často nabízí unikátní pohled na low-level úrovni detailu, který manažer prostě nemá. Když David cítil, že jeho obchodní zástupci nepracují efektivně, vymýšlel různé mechanismy, jak jinak oceňovat jejich práci. Vymýšlel personální změny a robustní změny v provizním systému, a to vše bez většího efektu. Myslel to dobře – chtěl je lépe ohodnotit, ale chtěl a potřeboval, aby přinášeli do firmy více zakázek. Byl však uzavřený v bublině svého podniku a potřeboval pomoci.

My jsme do procesu přinesli profesní zkušenosti z různých projektů a diskuzi s dotčenými uživateli na téma, co by jim pomohlo dělat jejich práci lépe. Na základě těchto vstupů jsem připravil refaktorovaný návrh procesů a návrh architektury systému, který tyto procesu naplno podpoří. A uživatelé to ocenili.

Žil, byl, jeden proces…

Proces zakázek žil svým životem – obchodní zástupci mají své portfolio klientů a pro jednotlivá vydání všech časopisů v portfoliu smlouvají inzertní zakázky jednorázové, ale i na delší časová období v různém počtu opakování a také s určitými slevami. Zakázky (a svůj čas na nich strávený) by měli evidovat. Stejně tak by měli aktivně spravovat své klienty a získávat nové tam, kde to je možné a vhodné. To se bohužel takto ideálně nedělo.

Následně se má paralelně spustit proces fakturační, proces výrobní a proces ohodnocování obchodních zástupců. Ty jsou úzce vázané na kvalitu vstupu z předchozího procesu. Zatímco však proces výrobní probíhal v pořádku, resp. samotné výstupy byly v požadované kvalitě, a fakturační proces nevybočoval z běžných standardů, v hodnotícím procesu jsme identifikovali několik zádrhelů.

Identifikovali jsme klíčová místa volatilit – procesů, které podléhají změnám a je třeba jim věnovat speciální pozornost.

Zmapoval jsem tedy zakázkový proces a navrhl jeho průběh tak, aby byl v teorii schopen transformovat vstupy na požadované výstupy a to v očekávané kvalitě.

Pro každou část procesu jsme pak navrhli směrnice, kterými se dotčená transformační místa musí řídit a také nastavili mechanismy, jak toho docílit a jak to kontrolovat.

Můžeme tak proces rozdělit do několika bloků, pro které se pokusím výše uvedené v krátkosti shrnout:

Kontakt s klienty – bude umožněn pouze z firemního zařízení připojeného k informačnímu systému. Aktivity zařízení jsou logovány a snadno dohledatelné. Při každém telefonátu či odeslaném emailu se tvoří kontaktní jednání, které spadá pod existujícího či nového klienta. Jde-li o nového klienta, pomůže systém v jeho založení a krátké kontrole aktuálního stavu dané společnosti + kontrole toho, zda nejde pouze o jinou společnost spadající pod stávajícího klienta. Zároveň se tato informace poprvé zakládá do provizního systému. Dále byl zaveden mechanismus, který požaduje od OZ určitý počet kontaktů s dosud nezaloženými klienty po určený časový úsek. Také s určitými bonusy.
Realizace zakázky – v případě, že zakázka je realizována, dojde k jejímu vygenerování (v podstatě „na tlačítko“) do systému (či úpravě stávající zakázky), čímž se zároveň spouští proces fakturační dle dodaných hodnot. To všem může OZ udělat v klidu následně u pevného PC či přímo z přenosného zařízení v případě, že je třeba jednat rychle či je OZ stále na cestách (což je ideálnější varianta). Spustí se také výrobní proces, který vrací do zakázky první verzi podkladů. OZ zaštiťuje korekturu dat i kontrolu dat finálních.
Následný servis – OZ také stojí za následným servisem – a to jak co se týče fakturace, tak i vyhodnocení úspěšnosti zakázky. Spouští se také procesy pro tisk a distribuci. Ukončení zakázky je evidováno i do IS. Zde jsou nastaveny mechanismy, které neumožní pokračovat procesu ohodnocení OZ v případě, že nesplnil požadavky zakázkového procesu (např. na následný servis klientovi).
Organizační zajištění – ve spolupráci s výrobou bylo upraveno organizační schéma pro zajištění těchto procesů. Grafici a pracovníci DTP nemohou fungovat zároveň jako korektoři a nemohou napřímo komunikovat s klienty o každé drobné úpravě. Byla posílena důležitost manažera produktu (každého z magazínů) a byla nastavena jasná vztahová matice mezi OZ – GRAFIKOU – PRODUKCÍ, kde vztahy nejvíce „haprovaly“.
Technické zajištění – informační systém měl také zajistit efektivnější předávání dat. Od OZ do systému vstupují již přesné požadavky na inzertní formáty v kombinaci s informacemi o tom, v jaké velikosti / čísle a titulu se má objevit. Protože společnost nechtěla využívat robustní DMS (a ani jsem jí to nedoporučoval), archivace zůstala na úrovni googleservices, ovšem byl nastaven přesný proces pro tuto archivaci a do systému byl připraven způsob nalinkování finálních dokumentů.

Druhou Achillovou patou byl proces ohodnocování práce obchodních zástupců. Názory ze dvou stran, vlastně očekávatelné, se značně lišily.

Dostáváme málo peněz a jsme nemotivováni.

Přinášíte málo zakázek a tím pádem nemohu odměny navýšit.

Mým úkolem nebylo a není soudit, ani brát v potaz emoce. Pouze data ze systému, která je třeba podložit a vyhodnotit čistě pragmaticky s ohledem na očekávané výstupy. Jak to tak ale bývá, pravda byla někde uprostřed. Příliš složitý provizní systém OZ příliš demotivoval a naopak je sváděl k tomu, aby systém obcházeli. To se samozřejmě nelíbilo vedení. Bylo potřeba jej nastavit tak, aby obě strany byly spokojené a všechny transakce tekly transparentně přes systém.

Proces není v tomto modelu příliš komplexní (on ani v realitě není definován příliš mnoha činnostmi). Průchod je tak poměrně očekávatelný. Sleduje se období dle zadaného případu a následně se počítá provize s ohledem na výši jednotlivé zakázky a výstupů z procesu budgetování. Následně po schválení je spuštěn proces přijaté fakturace.

Mnohem důležitější jsou ovšem hlediska (dohromady 4, pro výpočet provize) a vazby na „okolí“ v systému. A to zejména tři třídy:

Ceník

Každý záznam této třídy určuje cenotvorbu pro jednotlivé tituly. Může být navázán na titul nebo na číslo (pokud není ceník navázán na číslo, bere se ceník z nadřízeného titulu. Naopak pokud číslo obsahuje navázaný ceník, nebere se v potaz ceník navázaný na nadřízený titul). Cena se stanovuje pro jednotlivé nabízené typy inzerátů – veškeré případné slevy a akce se také váží právě zde (vhodné i pro opakované nabízení). Ceník může být vázán také na klienta – při splněné vazbě klient / titul se pak aplikuje právě tento ceník.

Ukázka definice hlavních atributů třídy Ceník.

Budget

Záznam třídy budget určuje finanční ohodnocení jednotlivých čísel (případně titulů, pokud se delší dobu nemění) pro výpočet ohodnocení OZ z hlediska finančního limitu čísla.

Dlouhodobé smlouvy vážeme přes objednávky na jednotlivá čísla, do kterých jsou vázány (implicitně se váže stejný formát inzerátu, lze ovšem následně měnit pro každé číslo zvlášť)

Reciproční objednávky je možné navazovat jako objednávky s nulovou hodnotou (a hodnotou „reciproční“ na „ano“) nebo s plnou hodnotou a řešit účetně vzájemným zápočtem s protihodnotou.

Ukázka definice hlavních atributů třídy Budget.

Provizní systém

Provizní systém sbírá data z ostatních tříd, aby vypočetl výši provize pro jednotlivé OZ na každé z čísel titulů a zároveň sledoval jejich součet napříč časem. Provizní systém je vždy generován pro zaměstnance na jeden kalendářní měsíc, po který načítá uzavřené objednávky.

Ukázka definice hlavních atributů třídy Provizní systém.

Závěrem…

Jak je vidět z předchozích ukázek, navzdory svému přesvědčení jsem ponechal jeden bod otevřený – a to koeficient. Možná se tak zdá, že porušuji vlastní pravidla. Ale jak jistě tušíte, není tomu tak J. Otevřeným bodem zůstaly jeho HODNOTY, nikoliv vstupy pro něj nutné a způsob výpočtu.

Definice 4 hledisek a sestavení vhodné rovnice nebylo zrovna jednoduché, ovšem prostředí jsme připravili tak, aby úpravy koeficientu spočívali pro uživatele „pouze“ v úpravě hledisek v systému (např. za zakázku se zcela novým klientem nebude procento vyšší o 20%, ale jen o 10%) – vzorec je automaticky přepočítáván ode dne změny (a i to lze změnit a přepočítat například i zpětně, nebo naopak až od příštího období). Co je důležité – celkový počet hledisek jsme snížili z 9 na 4, která mohou ovlivnit výši provize ze základních X%.

Hledisko – nového klienta / vlastního titulu / Výše slevy (nárůst na max X+6% v případě splnění jedné z těchto podmínek)
Hledisko budgetu – dle míry splnění celkového budgetu daného čísla se provize zvyšuje. V případě plnění nad 100% nastaveného budgetu se navíc zohledňuje i poměr plnění OZ na budgetu.
Hledisko časového rámce – s ohledem na datum vystavení a zaplacení faktur.
Hledisko ceny celostrany upravuje výši provize dle celkové ceny, za kterou je prodány jedna celostrana při daném inzerátu.

Zbytečná komplexita totiž přináší zbytečný zmatek v hlavách uživatelů a správců a po čase také v praxi neschopnost takovéto části systému efektivně spravovat. Přiznám se bez mučení, že sám bych ještě ubral. I takovéto zeštíhlení však s odstupem času považuji za úspěch.

Jaký další negativní dopad může mít vysoká komplexita? Zde platí jednoduchá rovnice:

Vyšší míra customizace = Vyšší pořizovací cena systému

Není na tom nic objevného. „Krabici“ zaplatíte za fixní cenu, za kterou se ji rozhodl dodavatel prodávat. Customizace většinou probíhají na bázi hodinové sazby konzultantů, případně vývojářů. A ta není zrovna nízká. Opatrně tedy s poměrem toho, co můžeme převzít a co potřebujeme NUTNĚ upravit na míru. A co vám s tím pomůže?

Ano, správně. Další důvod, proč potřebujete POŘÁDNOU analýzu a design (=technologický návrh). Protože jen v těchto fázích dokážete systém rozřezat na dřeň a následně ušetřit statisíce i miliony při výběru systému a implementaci. Nenechte se odradit tím, že musíte zaplatit „za papír“ a ještě nemáte žádný funkční produkt. Pokud si najdete opravdu dobrého analytika/architekta, ty peníze se vám vrátí násobně. Pokud jej tedy najdete a najmete, máte skoro vyhráno. Vaším nejsložitějším úkolem tak bude jej najít a přesvědčit, aby s vámi spolupracoval.