Je tomu asi půl roku, kdy jsem se začal zabývat metodikou ITIL. Byl jsem na stáži v jedné nejmenované společnosti, která zaobírá přední postavení ve vývoji SW na světě. Za úkol jsme měl vytvořit pracovní workflow pro jejich SW na základě metodiky ITIL.
Prvním problémem, se kterým jsem se při svém bádání setkal, bylo, že všude bylo o ITILu napsáno pouze něco ve smyslu: ITIL byl vyvinut ve spolupráci britské vlády a soukromého sektoru a je plně závislý na know-how každé společnosti. Na to jsem byl ale na počátku upozorněn, že stále ještě není tato metodika nikde přesně dokumentována (na rozdíl od metodiky RUP (UP) s kterou ITIL velice spolupracuje).
O čem tedy ITIL je? ITIL je velice rozsáhlou metodikou, která napovídá, jak lze řešit ve společnosti tok informací a dokumentů (document and information flow), tok práce (workflow) a strukturu společnosti (což je asi spolu s tokem práce na prvním místě).
Spolupráce s UP (RUP)
Jak jsem již naznačoval ITIL má velice blízko k vele známé metodice UP (nebo její komerční verzi RUP). Jak? metodika RUP řeší jak efektivně navrhovat SW. Jenže už bohužel neřeší takové drobnosti, jak nakládat s artefakty (výstupy) nebo jak nakládat se samotným SW po jeho uvedení do provozu. Což, a to si přiznejme, v našich luzích a hájích nepatří k silným stránkám společností. Z toho vyplývá, že ITIL tvoří jakýsi pomyslný background pro RUP.
Jak se to děje v praxi
V ČR se zatím metodika ITIL zatím moc neusídlila. Vidím pro to jeden velice podstatný důvod. Společnosti, které působí na českém trhu se dají rozdělit do dvou skupin: české (nebo v Česku vzniklé) a zahraniční (povětšinou korporace). U zahraničních korporací je metodika správy SW povětšinou výsledkem nějaké dlouhodobě tvořené firemní struktury (která v některých případech může mít něco společného s ITILem). U českých společností je většinou se zavedením takové metodiky veliký problém, jelikož se velice dynamicky vyvíjí a struktura společnosti se většinou mění z roku na rok. A zde začíná problém zvaný desorganizace práce. Původně malinkatá společnost o několika zaměstnancích (10–25) zaměstnanců většinou žádnou strukturu nemá (maximálně podřízenou RUPu). A lidé, kteří stojí na odpovědných místech se nehodlají zamýšlet nad nějakou hlubší organizací. Pak ale najednou společnost povyroste a ejhle má 150 zaměstnanců a na tvoření struktury je trochu pozdě (a řádně to pak bolí).
S tímto tvrzením asi někteří z Vás nebudou souhlasit, ale na vlastní oči sem viděl model „tady každý tak nějak ví co má dělat“ jak krásně (ne)funguje ve společnosti o 80 zaměstnancích.
Příklad nasazení ITILu?
Nejhezčím příkladem ITILu v praxi podle mě je správa neboli řízení SW po jeho nasazení. Pokud pracujete nebo jste pracovali ve společnosti, která se zabývá vývojem, pak jste se asi s těmito situacemi setkali. Když to přeženu tak to v klasické středně velké společnosti vypadá asi nějak takhle:
Uživatel SW má nějaký problém. Řeší to tak, že zavolá na HotLinku (pokud společnost něčím takovým disponuje, pokud). Tam pracovník/ce vyslechne co uživatel má za problém a pak vybere nějakého kolegu, který by tomu měl rozumět lépe a na toho to přepojí. Kolega si tento telefonní hovor převezme a i třeba problém vyřeší. Super. Ideální případ a tak to všichni máme rádi. Ale teď pár otázek: co když to ten kolega zrovna nedokáže vyřešit? Přepojí ho dál? Co když je problém většího charakteru? jak předá informaci? co když je kolega na dovolené? Co když se na ní chystá? Co když je problém v něčem úplně jiném než kolega myslel?
U jednoho problému se toho asi moc stát nemůže, ale ty z Vás, kteří někdy navrhly SW pro více než 100 stálých uživatelů vědí, že se problémy valí minutu za minutou, den za dnem. A to ještě třeba ani nemusíte zajišťovat HW (pak je to tedy mazec, vyměňování klávesnic a myší, zaseklé tiskárny, atd.). Udržet pak všechny informace o SW a HW v pořádku a přehledně není sranda. Vemte jen v potaz co to stojí za námahu udržet konfigurační DTB aktuální když se na SW stále něco aktualizuje v návaznosti na opravování chyb SW.
Strašně rád bych se zde rozepsal o tom jak se tyto situace dají elegantně řešit podle ITILu, ale jsem bohužel spřažen mlčenlivostí. Takže Vám jen velice doporučuji seznámit se alespoň lehce s touto metodikou, jelikož si myslím že Vám i Vaší společnosti může v delším horizontu přinést ovoce v podobě méně naštvaných zákazníků, méně hádek s kolegy, efektivnějšímu řešení problémů a hlavně více klidu k práci.
Všem co se sním již v praxi setkali fandím. A těm kdo ještě ne snad tenhle článek nasadí brouka do hlavy.
Momentálně za jednu z nejzajímavějších věcí na ITILu, které se chci věnovat více do hloubky, je jeho spolupráce s RUPem. Protože potencionál na spolupráci tam je obrovský. Pokud by to někoho také zajímalo stačí napsat a můžu výsledky pátrání zveřejnit zde.
Závěrem snad jen pár věcí (hlavně pro rýpaly). Ano metodika ITIL není převratnou novinkou, byla vyvinuta v 80-tých letech (takže je klidně možné že jste o ní slyšeli již před několika lety a jsem pro Vás prehistorický neandrtálec). ITIL řeší daleko více věcí než jsem zde popisoval. Určitě není pravdou že nikde v Čechách není používán (znám).
Dlouho jsem uvažoval, kterou odpověď v anketě zvolit, ale nakonec jsem stejně nevybral. Chápu, že ITIL má smysl a může být přínosný, nějaká pravidla prostě být musí, ale pokud se systém pravidel stane nepřehledným a příliš složitým, tak je to spíše ke škodě. U nás se už poměrně dlouho implementuje a ve společnosti o několika tisících zaměstnancích to opravdu bolí. Zatím mám pocit, že v některých případech složitá obluda jako ITIL spíš škodí.
[1]
Úplně chápu. Ale pokud se Vám to povede, věřím že to bude mít obrovský přínos. Ale na druhou stranu, jestli opravdu Vaše společnost má několik tisíc zaměstnanců a tato implementace se nedotáhne do konce a zůstane někde na půli cesty, tak tedy pán Bůh s Vámi. Ještě jeden dotaz. Máte to podpořeno nějakým komerčním SW nebo na to používáte vlastní?
Můj názor je, že je to celkem k PRDu.
"Vemte jen v potaz co to stojí za námahu udržet konfigurační DTB aktuální když se na SW stále něco aktualizuje v návaznosti na opravování chyb SW."
Tato věta mne obzvlášť fascinuje.
1. Vy nemáte vývojové prostředí?
2. Vy nemáte testovací prostředí?
3. Vy nemáte produkční prostředí?
4. Vy netestujete SW při převodu mezi nimi?
No jistě, pak máte problém. Na to, jak se co má dělat jsou normy, ne sbírky "dobrých" nápadů. Možná i ITIL někdy do toho doroste ( ISO 20 000), zatím je to ovšem jenom pokus a jeden neúsoěšný tu už byl ISO 15 000...
[3]
Myslím, že máš absolutní pravdu v tom, že částečné nebo neúplné nasazení metodiky ITIL je nesmysl (což je také největší problém ISO 20000 - ikdyž jsem po zhlédnutí této normy neměl úplně nejhorší pocit). ITIL je pro mě prostě celistvá metodika, která prostě nemůže být vykrádaná, jak se komu zlíbí.
A je obrovskou pravdou, že udržení ConfigDTB pokud někdo nemá perfektně propracovanou firemní strukturu je nemožné.
[5]
v tom je ten většinou problém. Implementovat nějakou metodiku na strukturu společnosti stojí totiž trochu šedé kůry mozkové, nemálo času a taky nějakou tu korunu. A to je ten důvod proč se do toho nikomu nechce. A povídejte někomu kdo sedí na penězích, že chcete implementovat metodiku struktury práce, když on za tí nevidí žádný přínos v krátké době. Tohle byl, je a asi i bude vždy problém. Ale lidé se učí z předchozích chyb. Takže se snad můžeme těšit.
pracuji v zahranici ve velke mezinarodni firme, ktera ma ITIL zavedeny, jede se podle toho na 100% stejne jako ISO 2000 a rekl bych ze je to znat - srovnavam s mezinarodni firmou v cechach kde jsem pracoval predtim. tady kazdy zamestnanec musi povinne projit certifikaci ITIL, ja ji delal cca pred pul rokem. urcite si myslim, ze je to prinos.
[8] corwin78
ještě jednou opakuji -- prostě Vám fandím. Z vlastním SW je to dvojsečné. Můžete buď dosáhnout daleko lepších výsledků (vzhledem k tomu jelikož prostě dělá to co po něm chcete) a nebo Vás může také pěkně stáhnout dolů (je nutno se mu věnovat, aby stále na 100% charakterizoval vaši činnost).
jako programator se zavisti zjistuji, ze jsem si zvolil spatne povolani. Dcera to udelala lepe, pracuje v Basileji, kde je mnozstvi farmaceutickych firem a ty musi byt ve vsem moznem certifikovany, aby mohly ty prasky prodavat. Tam je ITIL a i jine metedy nutnosti. A samozrejme se okolo toho mota rada firem, ktere nabizeji to poradenstvi ohledne techto metod, zavadeni a pod.
Ma to jednu velkou vyhodu. Takovy poradce (ja dceri ty penize preji) vlastne nemuze udelat chybu. Rozprostre vseobecne ladene folie a vyklada nezavazna fakta. A kdyz neco nefunguje, jak by si kdo predstavoval, tak se rekne, ze se patrne udelala nekde motivacni chyba, ze je to zavisle na lidskem faktoru a lide se neustale skoli a preskoluji a poradci nevi kam drive skocit.
Kdybych se jeste jednou narodil, tak budu poradce v nejkych metodikach.
nejako som neporozumel o co vlastne v prispevku islo.. skusim nejako zhrnut co som pochopil z clanku:
ITIL je nieco ako RUP
ITIL je ITIL
ITIL nie je nikde popisany
ITIL je velmi rozsiahla tematika
ITIL je dobry ked sa dobre namontuje
ITIL je ovela lepsi ako cokolvek ine a videl som to fungovat
ITIL tam fungoval dobre, ale nemozem povedat ako
ITIL je fakt dobry
presne tieto konstatovania mozem povedat uplne na cokolvek - pocnuc Cokoladovym Termixom cez Vazelinu az po Toaletny papier
Souhlasim s tim, ze od urcity velikosti firmy se proste musi zavest stabni kultura, protoze system, kde se kazdy zna s kazdym jde udrzet jen v malem poctu lidi a za podminky obrovskyho nadseni. Jakmile se na firmu nabali "cizi" lidi, kteri na firmu koukaji jako na zamestnavatele a ne na "moji firmu", nemuze zadnej garazovej system bejt efektivni.
Naopak, presne takhle vznikaj ty prototypy vecne prepracovanejch manazeru uspesne se rozviejicich ceskejch firem - maj napad, maj zakaznika, umej vyrobit, opecovavat i prodat, dokonce i expandujou, jen se u toho desne nadrou a ve vysledku nemaj takovej zisk, jakej by si za svoje nasazeni zalouzili...
Existuje spasny reseni - zazracna metodika, best pracitce nebo norma XY - at uz je to CMMI, ITIL, COBiT, ISO, (R)UP, nebo cokoliv jinyho... Jenze ta metodika bud spada do tridy obecnejch kecu (CMMI a spol.), ktery sice davaji smysl, ale netvori kucharku pro nasazeni, konzultant sam moc nevi, jak prevest reci do praxe a veskery certifikace, appraisaly a konzultace jsou drahy jak cert (nebo zoufale nekvalitni). Druha trida je velice konkretni (RUP a spol.), naopak svazujici predpis, podle kteryho se musi jet a ke kterymu se musej nasadit konkretni proprietarni SW (obtizne spravovatelny, uzivatelsky nepritulny a sakra drahy), styl rizeni firmy, dalsi hromada e-papirovani a vysledek je dost podobnej prvnimu pripadu.
Muj zaver z toho je:
- Ma smysl se zamejslet nad efektivitou procesu
- Ma smysl procesy optimalizovat
- Ma smysl sestudovat releventni best practices (ale nekdo s dobrym prehledem musi poradit jaky, jinak se v tom clovek utopi)
- Ma smysl si z best practices vybrat to, co se hodi a ma smysl (metodou gap analysis - najit uzky hrdlo, zjistit, proc to nefunguje a fixnout to za pomoci inspirace od best practices)
- Ma smysl si prizvat na pomoc externiho konzultanta (ale musi neco umet - leta praxe /idealni je dostat jeho CV/, reference, popovidani si o efektu s lidma od referencniho zakaznika; spis ma vseobecne poradit smer a doporucit literaturu, implementaci si firma zvladne lip a levnejc sama)
- Ma smysl implementovat zmeny inkrementalne po iteracich (zalepit nejhorsi diru, sledovat a pripadne doladit - pak teprv resit dalsi bottleneck)
- Ma smysl merit (ale metrika musi davat smysl)
- Ma smysl zlepsovat na zaklade mereni (bez mereni neni zpetna vazba a nejde posoudit navratnost procesniho zlepsovani)
- Ma smysl se zabejvat dopadem organizacni zmeny procesniho zlepsovani (a kriteriama uspechu tyhle zmeny)
Jeste neco: Typicky se stava, ze IT firma vi, ze neco neni v poradku a chce to zmenit, ale neni na zmenu pripravena - nema rezervovany lidsky kapacity a penize, ktery nutne spadnou do rezie organizacni/procesni zmeny. Firma tise ocekava, ze "to nekdo za ne vyresi" a ze "to vyresi bezbolestne a za chodu". To je cesta do pekel...
[15] sarimak
Ve spoustě věcech s tebou musím souhlasit, ale dovolil bych si v tomto zastat ITILu. Máš pravdu, že ITIL nikdy neříká jak máš co udělat. Nikdy se nestane, že bys měl konkrétní problém a ITIL pravil "udělej to tak nebo onak", lae na opak ITIL naprosto perfektně popisuje jak by ses měl zařídit, aby problémy nenastávaly a když už nastanou tak abys je dokázal efektivně a rychle řešit.
Tohle je možná největším problémem ITILu v Čechách. Vždyť přece (a tohle asi někteří uslyší neradi) největší devizou manažera není umět problémy řešit, ale umět jim předcházet. A takhle se přesně chová ITIL. Proto ho lidi přehlíží. Nezajímají se o něj, pak nastane problém, hledají východisko, vzpomenou si že nějaký ITIL existuje, ale žádnou odpověď nedostanou. Z toho pak pramení názory na něj.
Z clanku jsem dostal dojem, ze je nejaky tajemny ITIL, nikdo nevi co to je, a autor to nemuze rict protoze je vazan mlcenlivosti. Ale je pry uzasne uchvatny a uchvatne uzasny.
Kdyz se podivam na stranku Wikipedie o ITILu, zjistuju, ze tam je spousta blabolu a zadnou predstavu o tom nemam.
Přečteno 15 091×
Přečteno 14 498×
Přečteno 12 849×
Přečteno 9 903×
Přečteno 9 255×