Sme zatial mala firma... Sice nadnarodna, ale zatial mame tak 68 - 75 zamestnancov... V poslednom case uz stracam prehlad.
Nas core business je ITSM a Business 2 Business... Kuk www.SolveDirect.com
Tak to je hodně zajímavé. S nasazením ITILu přišla mateřská firma (protože jsou na to tak zvyklí a zapadá jim to do nějakýho většího celku), nebo to bylo lokální rozhodnutí (udelane i presto, ze cilene pro tak malou firmu)?
P.S. CUBE vypada hezky
Inak ITIL v zmysle Incident, Change a Release vidim uplne vazne ako formalizovany common sense...
No mě by právě zajímalo, jestli máte z ITILu jenom tohle, nebo i ostatní části. (tj. jestli jste do toho šli opatrně a s rozvahou, nebo na plno a tudíž možná trochu riskantně...)
Service operation je (mam z toho dojem) jasna prvni volba pro implementaci. V textu, kterej mam pred sebou, do toho radi: incident mgmt., event m., request fulfillment, problem mgmt., access mgmt. To jsou vsechno veci, ktery firma bude delat, at chce nebo ne, takze tam je zavedeni nejake metodiky celkem bezbolestny a s pomerne jasnym prinosem.
Zajimavejsi to uz zacina byt u s. transition - pises, ze mate change a release mgmt. Jeste se tam radi asset a config mgmt. a knowledge management. To predpokladam mate nejakym zpusobem taky. Otazka je, jak moc formalne podle ITILu... ale to neni az tak dulezity.
Po sem mi to prijde smysluplny v podstate pro firmu libovolne velikosti.
Otazka je, jak moc prinosny by bylo pro mensi firmu formalni zavadeni napr. veci ze service design...
Teď jak to po sobě čtu, přijde mi, že se ptám už trochu moc na tělo (na vaše interní záležitosti), to nechci, nerad bych ti působil nějaký potenciální problémy
, tak toho raději nechám, počkám si, kdo se ozve dál a kdyžtak bych se k tomu ještě vrátil.
Problem management je z mojho pohladu tiez relativne len rozsiahlejsi incident.
No vidíš, to je fajn, že to zmiňuješ. Praktická implementace PM mi třeba hodně vrtá hlavou právě proto, že mi PM přijde principielně hodně odlišnej od IM. V rámci IM by afaik mělo jít o co nejrychlejší obnovení dodávky služby, ne o vyřešení příčiny (tu totiž v téhle fázi nemusím znát a i když ji znám, je věcí change mgmt-u ji odstranit). Čili úplně prakticky: vím, že když nefunguje web XY, musí se restartovat apache. Proč padá neřeším.
Hlavní rozdíl mezi PM a IM vidím v tom, že IM má jasnej vstupní bod - volá zákazník, zaměstnanec vyplní hlášení, nějaká sonda spustí event, že něco není v daných mezích atd. Oproti tomu PM je definovanej (opět cituju) jako "the unknown cause of one or more incidents", takže mi trochu chybí nějaký jasně měřitelný vstupní bod - je jasný, že někdo s hlášením problému přijde (např. service desk, když se nějaký incident stává často), ale neumím si představit nějaké obecné kritérium, podle kterého by se dalo přesně stanovit, kdy už se má problém vytvořit.
Nevím, jestli se vyjadřuju srozumitelně, prostě myslím, dokdy je problém fakt "unknown" a nikdo ho neřeší a na základě čeho se rozhodne, že teď už by ho někdo měl odhalit. Na základě čeho můžu změřit, že to rozhodnutí přišlo ve správnou dobu? (Když říkám "změřit", nemyslím to doslovně...) Kdo tohle kritérium stanoví a je za něj zodpovědný?
Další věc, která mi není úplně jasná, jsou vedlejší efekty workaroundu použitého při řešení incidentu. Třeba jsem četl příklad: přestane fungovat tiskárna, zákazník volá na desk, ten problém ověří a jelikož je to akutní, povolí uživateli tisk na jiné tiskárně, na které by normálně tisknout nemohl. Tím desk incident vyřešil a asi by měl zavřít incident. Jenže 1. vznikla změna konfigurace a 2. trvá původní příčina. ...no a teď moc nevím, jak takovou situaci popsat, kam zapadá, kdo má na starosti její vyřešení atd. Např. někdo by měl odpovědně rozhodnout, jestli je tu situaci potřeba vrátit do původního stavu, nebo jestli tenhle workaround takhle může zůstat. (v tomhle konkrétním případě asi ne...) - a logicky by to měl být někdo, kdo dobře zná parametry té služby - kdo to je a jak se o takové situaci dozví? Pak tady je taky problém množiny "povolených workaroundů", ale to už by se asi v literatuře našlo.
-------
Takových konkrétních otázek bych určitě postupně vymyslel víc, nechci s nima otravovat, proto právě hledám nějakou literaturu představující praktickou implementaci, abych nad každou blbostí nemusel tápat, ale mohl bych se podívat, jak to v nějakém konkrétním případě mají (nebo nemají) vyřešeno...
Zobrazit příspěvky
