HTML

balansz

Angliába szakadva, hol az informatika, hol a tánc világában elveszve.

Friss topikok

  • FacebbokerPro: érdekes levezetése volt ez az eseményeknek :D (2012.12.09. 22:30) Mobil nélkül...
  • Judit77: ...Például ránk mindkét ok vonatkozik. Az érzelmi ok is, vagyis hogy menekültünk Magyarországról, ... (2011.03.30. 00:03) Szakmai tapasztalat otthoni értéke
  • Ecsedy Áron: @psuba: Köszi! Igazából amúgy már most az történik amit mondtál (kézbevétel). Pénz még lenne, csak... (2009.12.12. 03:38) Ördögi kör
  • veny: 2 hónapja se blog, se balansz, se bullshit. Mi lesz így velünk? :) (2009.04.14. 16:10) eMagyarorszag bullshit
  • veny: A nem olcsó és a drága azért szerintem nem ugyanaz... Luka sajnos határozottan drága, mind magya... (2009.02.01. 09:31) Gargalizáld

Random Flickr képem

Vigyázz, mit kívánsz

2008.08.04. 19:27 :: psuba

 Vigyázat, ez most okoskodás lesz.

A helyzet az, hogy kapcsolódik a múltkori tánc és olimpia témakörhöz, de igazából a legutóbbi megbízatásom kapcsán vetődött fel bennem a gondolat, hogy érdemes pár szót szólni a teljesítménymérésről.

A történet ott kezdődik, hogy a(z informatikai) szolgáltató éppen egy szolgáltatási szerződést csiszolgatott. Egyéb részleteket most nem tárgyalva, a lényeg az volt, hogy az ügyfél a bónusz - büntetés kapcsán azt kérte, hogy amennyiben egy hónapban másodszor áll le ugyanolyan technikai okból egy szolgáltatás, vagy harmadszorra bármilyen szolgáltatás bármilyen okból, akkor a szolgáltató fizessen büntetést (kicsit egyszerűsítek, de a lényeg ez volt). Miután részletesebben elbeszélgettem a szolgáltató ügyvezetőjével, aki felkért a szerződés és a szolgáltatási modell kidolgozására, kifejtette, hogy az ügyfélnek azért volt ez a kérése, mert őt csak az érdekli, hogy a szolgáltatások ne álljanak le, és kész. Ez persze tökéletesen érthető, csak van vele néhány probléma.

Lényeges probléma az, hogy nincsen feltétlenül a szolgáltató kezében az összes technikai részelem. És bár adott esetben jogos elvárás lehet a vevőtől, hogy a szolgáltató vállaljon felelősséget az alvállalkozókért, az informatikában ez gyakorlatilag azt jelentené, hogy például az ügyfél hibáiért, az ügyfél által kiválasztott szoftver-és harverelemek gyártóiért is a szolgáltató vállalná a felelősséget.

Emellett azonban van egy alapvetőbb probléma. Ez pedig az emberi természetből adódik. Abban a pillanatban, hogy definiálunk teljesítménymérésre valamilyen mutatókat, a továbbiakban az összes résztvevő ezeket a mutatókat fogja nagyítóval tanulmányozni, és e mutatók irányítják a szereplők lépéseit. Más szóval, már nem az lesz a résztvevők (a napi tevékenységet kontrollálók és azt végzők) fókuszában, hogy a mutatók kiválasztásakor eredetileg fontos célokat elérjék, hanem, hogy bebizonyítsák, hogy azok a fránya számok olyanok legyenek, mint amit mindenki elvár. Tehát: a definiált mutatók immáron a résztvevők szemében átváltoznak az alapvető céllá. Ezért rettentő fontos átgondolni, vajon mire inspiráljuk a definiált mérendőkkel a résztvevőket? 

Nézzük a konkrét esetet. A kért "büntetési feltétel" egyike úgy szólt, hogy hogy két egymást követő, ugyanolyan kiváltó okú incidens esetén jár a büntetés. Mire inspirálja ez a szolgáltatónál dolgozókat? Hát feltétlenül nem arra, hogy gyorsan megelőzzék a második kiesést - ennél sokkal egyszerűbb másféle kiváltó okot diagnosztizálni a második kiesésnél. Vajon ki fogja kétségbe vonni a technikus diagnisztikáját, főleg, ha (mint a legtöbb kiesés esetében) a kiváltó ok nem állapítható meg egyszerűen vagy egyértelműen, hosszadalmas diagnosztika nélkül? Ebben az esetben tehát a mérendő dolog éppen a vevő valós céljaival ellentétes irányba ösztönzi a szolgáltatót: a szolgáltató nem a pontos diagnosztikára és korrekt megelőzésre fog öszpontosítani.

A másik "büntetési feltétel" pedig úgy szólt, hogy egy hónapon belül három un. Severity 1 (kicsit leegyszerűsítve: legmagasabb prioritású) incidens esetén jár a kártérítés. Ebben az esetben azonban a Severity 1 definícióját megvizsgálva láthatjuk, hogy a definíció legalábbis kérdéses: például az üzletmenet jelentős kiesését szabja feltételül. Előre látható, hogy a szolgáltatási megbeszélések innentől kezdve a vevő és a szolgáltató között nem arról fognak szólni, hogy hogyan végezte a dolgát a szolgáltató, hanem arról, hogy az előző hónapban megtörtént kiesések vajon mennyire voltak "jelentősek". Ezen remekül lehet vitatkozni, de az biztos, hogy ez sem szolgálja a végcélt, azaz a minél kevesebb kieséssel járó működést.

A megoldás? A mérési feltételeket úgy kell kiválasztani, hogy jó keresztmetszetét adják a minőségi működés összes feltételének. Az egyszerűsítések, bár fontosak (hiszen nem lehet mindíg mindent mérni!), de vigyázni kell velük. Jelen esetben az történt, hogy a végcél érdekében a szerződésben több szolgáltatási folyamat több paraméterének a mérése - jelen esetben a probléma menedzsment megfelelő működése - lett behelyettesítve feltételnek a kiesésekhez. Másképp fogalmazva, a két, illetve három kiesés akkor járt a szolgáltatási büntetés kiszabásával, ha a szolgáltató nem követte megfelelő módon a probléma menedzsment folyamatot (amelynek célja legfőképpen a kiesések kiváltó okainak megfejtése és azok megszüntetése).

Hogy mennyire nem tudja észrevenni néha az ember a legfontosabb jelzésekről is lemarad, ha túlságosan koncentrál a mérendő dolgokra:

Szólj hozzá!

Címkék: informatika itsm szolgáltatás menedzsment

A bejegyzés trackback címe:

https://i-mrc.blog.hu/api/trackback/id/tr44600429

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása