2. Obsah
• Úvod do Asset Management (AM)
• CMDB v JIRA
• Co vše z AM lze zavést v JIRA?
• Propojení AM s JIRA Service Desk
• Enterprise AM v add-onu Insight
KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
3. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Co je to Asset Management?
• Správa assetů: „aktiv“ nebo „konfiguračních položek“ (CI)
• = hmotný i nehmotný provozní majetek (PC, licence, server...)
• Ale také dohled, audit, evidence, servis...
4. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Proč mít Asset Management?
• Evidence HW, SW a snadné sledování jejich stavu
• Zpřehlednění nákupu a údržby HW/SW
• Pohled na reálné využití provozního majetku
• Auditování změn HW/SW
• Lze zavést v JIRA!
5. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
AM v JIRA zvládá:
Evidovat
Nasazovat
Udržovat
Vylepšovat
Vyřazovat
6. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Tvorba inventáře – „CMDB“
1) Nový projekt
2) Typy aktiv
7. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Tvorba inventáře
3) Vhodná pole
4) Vhodné obrazovky…
5) Vhodná oprávnění…
6) Vhodné zabezpečení…
9. • Sledovat, přidávat a odebírat položky
• Rychle najít specifický „stroj“
• Vidět stav položek v různých kancelářích
• Vidět historii každého nástroje
KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Inventář hotov!
23. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Co je to CRM?
= Customer relationship management - Řízení vztahu s klientem
= Software k tomuto určený.
• Informace o zákaznících, o obchodech, kontaktech,
marketingu, komunikaci…
24. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Proč mít CRM?
• Evidence obchodních příležitostí
• Přehled nad portfoliem klientů
• Reporting o obchodní situaci firmy
• Všechna data o klientech na jednom místě
• Lze zavést v JIRA!
26. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Samostatný projekt
27. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Typy úloh
Organization – Data o firmě
Contact – Kontaktní osoba
Deal – Zakázka
Activity – Práce na zakázce
28. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Obsah úloh
32. KAMIL BEER • ATLASSIAN CONSULTANT • ONLIO
Děkuji za pozornost
Užitečné odkazy:
Prezentace ke sdílení http://www.slideshare.net/Onlio
Atlassian komunita CZ & SK www.linkedin.com/groups?gid=2648129
Editor's Notes
Vždy, když prezentuji novému zákazníkovi JIRA, na jednom ze slidů najde informaci o tom, jak se dá použít opravdu na leccos – v agilním vývoji, jako zákaznická podpora, pro bugtracking, pro sběratelské účely – ale málokdo si vzpomene – často včetně mě – že v JIRA se dá pohodlně zvládnout starat se o dva důležité procesy, které se hodí většině firem – asset management a CRM.
Díky, že jste přišli a za váš čas. Moje jméno je KB, v ATL týmu dělám bla a dnešní workshop je na téma, jak si s minimálními náklady zprovoznit v JIRA tyto dvě funkce. Po prezentacích a úvodu do problematiky bude prostor na diskusi a ukázku na živém prostředí.
První vstup se zabývá právě AM.
Meníčko
Představíme si metodiku samotnou – pro ty co neznají, a pro ty znají, připomeneme
Ukážeme si, jak ji implementovat do JIRA
Včetně provázání s Servisní částí
A řešení pro korporátní AM v podobě add-onu insight.
Asset management se dá vykládat různě. Jak už říká jeho název, jedná se o správu aktiv, jindy nazvaných jako assety, jindy CI, konfigurační položky. Pod nimi si lze představit hmotný i nehmotný provozní majetek firmy, který je potřeba nějakým způsobem evidovat, sledovat a udržovat jej. V oblasti IT jde často o to sledovat platnost licencí u SW, údržbu u hardwaru, poskytovat uživatelům podporu, řešit jejich servisní požadavky. Firmy si toto sledují třeba skrz excel nebo nějakou databázi, ale pokud jste zvyklí dosud vše řešit v JIRA, jde tam i toto.
Jaké výhody přinese, když si ve firmě zavedu asset management?
V první řadě vidím, jak je na tom jakýkoli stroj, licence, nebo jiný provozní nástroj firmy. Potřebuje do servisu? Přijde mi upozornění. Dobíhá mi licence? Budu upozorněný. Všechno vidím.
Potom, mám databázi nástrojů, ze které můžu vyvodit, jestli je třeba potřeba něco dokoupit, něco dosluhuje nebo je to třeba vyřadit. Síla v tom, že vždy vše vidíte.
Vidím hlavně to, co je reálně využívané a nevyužívané: třeba při onboardingu vidím, co můžu dát za laptop zaměstnanci, nebo taky vidím, kdo co vlastní, aby se někde nějaký stroj „neztratil“.
Historie HW/SW. Kolikrát byl v servise a s čím? Není to zas stejná chyba? Ve finále to také znamená, že nebude nástroj, který by nebyl evidovaný.
A nepotřebujete extra program. //// AM v JIRA můžete posadit vedle svých vývojových, účetních nebo výrobních projektů díky její flexibilitě a jakmile máte jednou systém, kde máte všechny své tickety, bugy a zdroje evidované vedle sebe, okamžitě máte nad vším přehled.
Atlassian sám ví, že termín AM je problematický a ve své příručce, jak AM provozovat, popisuje, že zvládne s nástroji firmy přinejmenším tyto úkony:
Evidovat – Jak je na tom co
Nasazovat – Kdo vlastní co
Udržovat – Servis, licence dobíhá
Upgradovat – Kontrolovat, vyměňovat, kdo má jak dlozho co
Vyřazovat – Víme, kde co skončilo
=> Pojďme.
Prvním krokem je tedy v tomto všem udělat pořádek. Abychom měli kde sledovat naše aktiva, assety, vytvoříme si na ně nový projekt v JIRA a k němu vytvoříme odpovídající typy úloh podle typů aktiv, co chceme sledovat. Takto vzniká tzv. konfigurační databáze neboli CMDB, která obsahuje jednotlivé assety, kterým se někdy říká CI, configuration items. Tyto mohou být hardware, software, cokoli potřebujeme.
Dále si zvolíme vhodná pole, co u našich aktiv chceme sledovat. V případě počítačů se nabízí například pole pro HW konfiguraci – počet jader, RAM, kapacita HDD, zatímco u monitoru můžeme sledovat třeba rozlišení; u licence zase její platnost nebo délku. Každý typ aktiva může mít zobrazené jiné údaje.
Každá JIRA úloha má pole řešitel a reportér. V našem případě jako řešitele dáme člověka, který má momentálně aktivum na starost – zaměstnanec, který ho používá, nebo servisní pracovník, co zrovna řeší jeho údržbu. Reportér může být správce aktiv, kterému pokaždé přijde upozornění o změnách.
No a jak se dá JIRA různě ohýbat, tak si třeba můžu nastavit do přechodů mezi workflow stavy různé obrazovky (workflow si ukážeme za chvíli), kde bude třeba povinné pole, kde vybereme servis, kam by měla položka jít, nebo kdo musí odsouhlasit nákup nové položky. Nebo mohu nastavit přístupová práva do projektu tak, aby nástroje nikdo jiný kromě IT oddělení nemohl editovat (ale mohl je vidět), nebo některé assety ani neviděl, třeba v případě licenčních kódů.
Další ze silných stránek JIRA, co poslouží AM, je právě její workflow, který se snadno přetvořit na životní cyklus položky v AM. Ve finále může vypadat například takto. Popsat.
A když určitá položka nefunguje, třeba mám vyřazený notebook, přesunu ho ve workflow v JIRA do stavu, ve kterém je. Je v servisu? Je vyřazený? Ztracený? Ani to neunikne.
V tomto bodě máme inventář hotov! Můžeme:
Co kdybychom chtěli, aby uživatel vždy viděl, co všechno vlastní? Administrátor JIRA může každému pracovníkovi nastavit na úvodní nástěnku právě takovou obrazovku.
Nebo co kdyby správce techniky chtěl vidět, kolik počítačů s jakou konfigurací je na skladě? Nebo cokoli jiného? Vždy si vytvoříme specifický filtr a výstup z něj si dáme na nástěnku. A tyto všechny údaje z filtrů se dají snadno překlopit do grafů a metrik v JIRA. Takto máte na jednom místě všechny údaje, co potřebujete.
Popiš reporty.
V tomto bodě máme inventář hotov a nyní se podíváme, jak ho lze využít v souvislosti s JIRA Service Desk.
V Service Desk si vytvoříte pro uživatele servisní portál, kde mohou ihned zadat požadavek na opravu, na nový notebook, nebo přístup na nějakou stanici. Zde si vyplní příslušný ticket...
Mám-li Service Desk, přijde mi do něj například ticket, že je třeba dát tiskárnu do servisu. Už když ho uživatel zadává, tak agentovi Service Desku napíše, co za stroj má, pokud to ví nebo to agent sám zkontroluje (např. filtrem přes uživatelské jméno, kdo vlastní daný asset) a buď manuálně agent nebo automaticky skript spojí jeho požadavek s daným PC. Ať už tedy řešíme servisní požadavek nebo pracujeme s assetem v JIRA, vždy uvidíme, jak jsou spolu propojeny. Takhle si správce nástrojů snadno udržuje přehled o tom, kdo požádal o co, kolikrát šel určitý počítač do opravy a proč.
Protože když jde počítač do servisu, určitě se hodí znát jeho historii; kolikrát tam a s čím tam byl, v jakém je stavu, nebo co má za HW. Nebo kdo ho vlastní, což prozradí JIRA úloha.
Zleva doprava vidíme, jak zákazník zadal ticket, z toho nám vznikl ticket v JIRA a ten zůstal evidovaný do úlohy s konfigurační položkou tiskárny, které se týkal. Propojení vidíme dole v „issue links“ mezi ticketem a assetem.
A ze všeho, co se u assetu dělo, vzniká záznam všech změn. Vidíme tam změny hardwaru, vidíme, jak přibývaly v čase servisní požadavky, je tam změna vlastníků a pohyb ve workflow.
Vidíme vždy předchozí a současnou hodnota. Toto je vždy v úloze a pomůže nám dosledovat, např. kolikrát byl PC v servisu, co se v něm měnilo za hardware a podobně.
Co jsme si ukazovali, dáme do JIRA bez jakéhokoli add-onu. Někdo by mohl namítnout, že toto je řešení pro malé, možná střední podniky, ale jak je to v případě enterprise řešení?
K tomuto slouží právě add-on Insight. Původně sloužil ke správě jakýchkoli objektů (např. do personalistiky nebo také jako CRM), ale je propagován jako sloužící k asset managementu. Je to add-on od firmy Riada, který funguje ve spojení jak s Service Deskem, tak s Core.
Insight pomáhá vytvořit kompletní konfigurační databázi. Volíme si zde typy assetů z předdefinované nabídky, propojení mezi sebou, pole, která budou relevantní.
Jeden náš projekt pro Asset management se jmenuje Object Schema. V něm si vedeme záznamy a propojení nejrůznějších objektů a hodnot, v tomto případě počítačů a software. Objekty a hodnoty, se kterými můžeme pracovat, vidíme vlevo. Je to jakýsi kořenový adresář. Objekty si mezi sebou můžeme libovolně propojovat, např. u objektu typu server chci sledovat objekt lokace a objekt server type.
Máme vybránu část „Server“, kde uvidíme, jaké položky – assety - obsahuje a napravo od toho už vidíme samotný popis, nápadně podobný úloze v JIRA.
Závislost mezi jednolivými položkami v asset managementu lze v Insight zobrazit i graficky. Zde například vidíme, jaké všechny údaje je třeba zadat pro server (vyplňujeme výrobce, uživatele, typ serveru) a jak mezi sebou souvisí zase ony.
V praxi se stane právě toto: u každého assetu nebo u každého stroje budete chtít sledovat různé údaje, ale insight promění tyto údaje na samostatné objekty, které zase mohou mít údaje svoje.
Příklad s objektu server, u kterého chceme sledovat umístění a typ serveru jsme si už zmínili. No a „umístění“ může zase mít zaznamenaný třeba údaj „Adresa“ nebo „Telefonní číslo“.
Synchronizace s JIRA Service Desk pak může vypadat třeba tak, že zatímco klient hlásí problém – zadává ticket na service Desku – můžeme mu na tuto obrazovku zadávání ticketu připravit Custom field, kde si vyhledá stroj, kterého se jeho ticket týká. Klasika: Nefunguje mi PC, tak najdu, který to je. Když si nevzpomenu, kliknutím na lupu se dostanu do průzkumníka strojů, kde si vyberu ten, co potřebuji. Tato hodnota už pak zůstane v ticketu v JIRA včetně dalších dat o vybraném stroji.
Tady už mám ukázku, jak takový vyplněný incident v JIRA Service Desk vypadá, když je v něm Insight pole. Insight nabízí různé typy polí, co jsou např. různě provázané mezi sebou, tady uvádím jednoduché pole, kde byl vybraný jeden stroj. Zadal jsem, že mě v zobrazení v JIRA úloze zajímají výrobce, místo a kdo ho používá.
Protože se jedná o enterprise prostředí, je jasné, že nestíháme kontrolovat každou položku jednotlivě. Můžeme si tedy nastavit u každého našeho typu assetu automatické upozornění, že například dochází licence, že je třeba dát nástroj do servisu a podobně. Toto může proběhnout formou e-mailu, formou vzniku JIRA issue, spuštěním skriptu a dále.
A samozřejmě, když nechcete databázi zadávat celou, můžete importovat z jiných systémů, kde sledujete buď lidské zdroje, assety, nebo jiná data. Máme tu LDAP, máme tu CSV, nebo třeba uživatele z JIRA. Jinými slovy, kde už máte nějakou strukturu, co byste chtěli sledovat v JIRA, můžete ji převést do formy, kterou využívá Insight.
Půjdeme úplně od základů: co je to CRM? Z anglického názvu se dostaneme k českému: řízení nebo správa vztahů se zákazníkem. Toto často znamená například přehled informací o obchodních případech a příležitostech, např. výběrových řízeních. Dále přehled dat o zákaznících, např. adresy nebo naše kontaktní osoby v určité firmy a jejich telefonní čísla. Průběh komunikace – mailovou historii – nebo přehled realizovaných a nerealizovaných obchodů.
Název CRM se též používá jako název pro nástroj pro uchování všech obchodních dat na jednom místě.
Evidence obchodních příležitostí – V jakém stavu je zakázka? Podařilo se realizovat? Kolik nám tento klient zadal poptávek? O jaké hodnotě? CRM si také můžete přizpůsobit na míru vašim zavedeným nejlepším metodám - best practices - kdy bude obchodní případ pokaždé následovat např. doporučený workflow.
Přehled nad zákazníky – Na základě záznamů uskutečněných nebo neuskutečněných zakázek u určitých klientů jde snadno přijít na silné a slabé stránky obchodních případů, co se povedlo, co ne a s kým. Nebo si lze jednoduše vést evidenci o tom, kolikrát se nám jaký klient ozval, s čím, a na základě toho opět identifikovat vhodné příležitosti.
Ba co víc: jestli a kdy se naposledy ozval obchodník zákazníkům – a pokud dlouho nevyvíjel činnost nebo firmu úplně ignoroval, v CRM to vidíme.
Reporting – CRM je kukátko do budoucnosti – a srovnání s minulostí a současným stavem zakázek. Vedoucí skrz report z CRM vidí, s jakými zakázkami a jakým finančním objemem pracuje, kde jsou možné potíže a úspěšnost a neúspěšnost získávání zakázek. Obchodní vedoucí zde může kontrolovat jednotlivé případy a práci jednotlivých obchodníků, případně zde evidovat a obhospodařovat nové příležitosti.
Data – Nakonec tato spíš pasivní funkce CRM zabezpečí, že nebude třeba vyhledávat pokaždé adresu, když budete fakturovat nebo plánovat schůze, vždy budete mít přehled o tom, kdo v evidované firmě s vaší firmou zastřešuje jakou část případu a další data, která by bylo jinak potřeba pracně dohledávat.
Zavedení tohoto v JIRA je velmi snadné.
Jde to dvojí cestou: Hotové CRM si zavedu v JIRA skrz add-on Kanoah CRM, avšak většina jeho nastavení se dá i samostatně nastavit v JIRA. Dnes si tedy ukážeme způsob, jak nám vznikne CRM i bez add-onu.
Abychom neměli CRM data rozházená po celé JIRA, založíme si na to samostatný projekt, který bude obsahovat výhradně tento typ úloh.
V tomto projektu si nadefinujeme typy úloh, které jsou čtyři:
Organization – Úloha, kde máme veškeré údaje o firmě: adresa, telefon, ičo, dič…
Contact – Úloha, kde máme údaje o kontaktní osobě v dané firmě. Typ úlohy Contact je podřazený typu Organization. Zde uvádíme např. telefon na tuto osobu, o jaký typ kontaktu se jedná (jestli technický, ekonomický či jiný), kdo ji zastupuje a podobně.
Deal – Úloha, která už popisuje samotnou zakázku. Zde uvádíme např. hodnotu zakázky, pravděpodobnost uskutečnění a fázi, ve které zakázka je.
Activity – Úloha, kam zapisujeme samotné práce na dealu. Hovory, e-maily a další činnost.
Všechny tyto úlohy jsou propojeny mezi sebou: v Organizaci jsou kontakty, organizace uzavírá dealy, a na dealech se vyvíjí aktivita. Takto dosáhnete toho, že skutečně budete mít vše kolem firmy na jednom místě.
Pro ukázku jsem si připravil, jak vypadá obsah úlohy contact a organizace. Organization sbírá data o firmě a Contact o člověku – právě pole jako IČO, telefon, web a další jsou příklad toho, že nejsou omezenyna Kanoah – jsou to pole, které si do JIRA můžete přidat i vy. A si i přidat svá, pokud chcete sledovat cokoli dalšího.
Dole vidíme v případě úlohy Organization, že se u firmy automaticky vytvoří řada linků jak na kontaktní osoby, tak na zakázky a další relevantní JIRA úlohy. Takto nám zůstane vše na jednom místě a neztratím přehled.
Zmínili jsme si i workflow, který může podpořit zavedené metody a firemní procesy. Na to si zase půjčuji typ úlohy Deal: můžete si nadefinovat stupnici stavů, odpovídající stavu zakázky v čase od nové zakázky, naplánované prezentace, zaslání smlouvy až po získání či ztrátu zakázky.
Workflow v Kanoah CRM, který jsem zde zveřejnil, má stupnici anglickou: tato zahrnuje stav nové zakázky, průzkumu, zda můžeme dodat řešení, uznání, že můžeme, prezentaci, odeslání nabídky a výsledek. V tomto workflow je možné se inspirovat nebo si vytvořit vlastní.
Dosud vše, co jsme si ukazovali, bylo dostupné jak ve vlastním projektu v JIRA, tak v add-onu Kanoah. Add-on má ale přeci jen několik dalších výhod, které v obyčejném JIRA projektu nenajdete. Patří mezi ně např. souhrnny Deals, Activities, Contacts a Organizations, které zobrazují kompletní seznam úloh. Zde třeba máme sekci deals, kde vidíme všechny zakázky v příslušných workflow stavech spolu s jejich peněžní hodnotou. Obdoba tohoto by se ale dala vytvořit v JIRA Software v Kanban boardu.
Jiný přehled nabízí záložka Activities, kde vidíme práce na jednotlivých zakázkách, všechny v podobě úloh, a vždy vidíme, ke kterému kontaktu, organizaci a zakázce patří.
Děkujeme za pozornost a za vaše dotazy. Pokud byste měli jakékoli další otázky, týkajících se produktů Atlassian, neváhejte se na nás obrátit telefonicky nebo mailově, které najdete na našich stránkách www.myjira.cz. Přejeme příjemný zbytek dne.