Ko reikalauti iš IT įmonių?

Metodikų gausa ir džiugina, ir liūdina. Džiugina, kad žmonės nesustodami ieško problemų sprendimų, o liūdina dėl to, kad jos būna neišbaigtos, nesuprastos arba blogai pristatomos. Bet kokiu atveju aš niekada nepraleidžiu galimybės susipažinti su metodikomis plačiau. Taigi gavau blogerišką pakvietimą iš TEO LT sudalyvauti BDC organizuotame G2G3 žaidime. Labai panašiame į šį:

Tai buvo ITIL‘u paremtas žaidimas-simuliacija ne profesionalams. Gal užuot sakius “ne profesionalams” reikėtų tiesiai šviesiai sakyti, kat tai žaidimas potencialiems klientams, kurie naudojasi IT kompanijų paslaugomis. Šiaip, kai kalbama apie ITIL, aš mėgstu paerzinti žinovus ir naiviai paklausti, kad taip ir nesupratau, kuo skiriasi Help Desk nuo Service Desk. Nes viską, ką išvardinate, gali padaryti abudu desk’ai. Bet čia buvo ne ta vieta, kur dėsto teoriją.

Pristatė, kad kalbėsime apie prekybos centrus, o prekybos centrai, kaip žinia, visas mokėjimo operacijas kompiuterizuoja. IT pasaulyje tai vadiname transakcijomis. Taigi organizatoriai padalino mus į klientus, užsakovus, IT vadovus ir inžinierius. Aš papuoliau prie inžinierių, todėl buvo lengva apsimesti, kad kol neįrodyta, kad mes esame kalti, tol esate patys kalti. Kažkoks kalambūras, na, bet kas esat susidūrę, tas susiprato. O kas nesuprato, bet labai knieti, galite peržiūrėti The IT Crowd.

Taigi žaidimas vyksta raundais, ir pirmo raundo metu mūsų IT įmonė uždirbo nerealų pelną: neuždirbome daugiau tik dėl to, kad IT vadai per daug išlaidavo. O, va, klientai patyrė beveik 5 mln. nuostolių, nes iš 96 tranksakcijų tik 18 buvo įvykdyta. Visos kitos kažkur pasimetė gedimuose.

Vidutinis incidento sprendimo laikas buvo beveik 9 minutės. O vienas roundas vyko 25 minutes. Jeigu išverstume į mėnesius, tai vieno incidento sprendimas trukdavo ilgiau negu 3 mėnesius. O kodėl taip vyko? Visų pirma, nebuvo jokių procesų, nebuvo prioritetų, net ir darbų pasiskirstymas buvo sąlyginis. O ir IT vadai dar nežinojo, ką galima daryti, o ko ne. Kadangi nežinojo, kad gali leisti pinigus visokiems niekučiams, todėl ir uždirbom nerealų pelną.

Toliau mums papasakojo pagrindines geriausias praktikas, ir mes puolėm uoliai jas bandyti, todėl trečiame raunde iš 96 transakcijų buvo įvykdytos jau 87, incidentų įvyko 11, beveik kas dvi minutes po incidentą. O paskutinį įvykusi incidentą išsprendėme per 20 sekundžių. Galima sakyti, kad sistemą jau atidirbome. Tiesą pasakius, trečiasis raundas jau reiškė trečius metus. Gaunasi, nepraėjo nė treji metai, ir ITišnikai išmoko dirbti.

Galiu padėkoti vedėjams už šauniai praleistą laiką, taip pat parodžiusiems, kaip galima lengvai paaiškinti IT įmonių klientams, ko reikia reikalauti iš IT įmonių ir į ką atkreipti dėmesį. Aišku, vieno žaidimo vargu ar užtektų, kad suprastumėte, kas yra ITIL, bet apie SLA jau susigaudysite.

Lieku prie savo nuomonės: visos metodikos skirtos tik vienam tikslui – savalaikiam pažadų vykdymui. Dažnai žodį „savalaikis“ mes užmirštame, ir tada metodikų naudojimas gaunasi daugiau mada, o ne nauda. Kai pradedame viską matuoti laike, išlenda labai daug problemų. Ir didelis kiekis problemų nužudo norą kažką daryti. Todėl mano moto – ten kur fokusas, ten yra rezultatai.

Iš manęs dažnai reikalauja, kad metodika nurodytų ne tik būtinybę tobulėti (tą daryti mus verčia poreikis per trumpesnę trukmę atlikti daugiau), bet ir tobulėjimo prioritetus. T.y. kur įdėjus mažiausias pastangas gautume didžiausia naudą (laiko trukmės sumažėjimą) arba bent pagerinimų seką. Deja, šio žaidimo metu atsakymo į šitą klausimą negavau, reiks toliau pačiam jo paieškoti.

Tik, va, su prioritetais neaišku, t.y. nuo ko pradėti paiešką?

komentarų yra lygiai 10

  1. Kiekvienam lietuviui po partiją, o kiekvienam IT’niškui po metodiką :)

  2. Ir kaip jūs spėjat į visus kviečiamus renginius sulakstyti, o po to dar ir review padaryti čia : )

    • Deja nespejam, todel daug pasiulymu sudalyvauti praleidziame. Nors tikrai noretusi sudalyvauti. Siuo konkreciu atveju, teko aukoti savaitgali.

  3. RascalLT

    Service desk’as tik priima skambučius, bet nėra pagal apibrėžimą įpareigotas teikti pagalbą.

  4. bss

    service desk kaip tik turi daugiau atsakomybiu – ne vien tik paswordu resetinimas :) tai yra centrinis taskas tarp techniku ir kliento. SD taip pat uzsiima incidento owninimu, eskalavimu, taipogi jei leidzia kompetencija gali padeti useriui kazka sutaisyt/sukonfiguruot.

    be ITIL ar panasios metodologijos didele IT paslaugu imone – tai didelis jovalas :) nesakau kad su ITIL yra tvarka, taciau bent jau yra i ka atsiremti.

    beje, kas nezino ITIL sukure britai po Folklendu salu karo su Argentina. Britai nusiunte savo moderniausia karine technika, taciau pasirode kad suvaldyti siai socio-techninei sistemai reikalingi aiskiai apibrezti procesai, terminai ir pan

    • Del Folklendu, tai mums irgi sia istorija papasakojo. Panasu ITIL turi savo legendu :)
      Kodel yra du desk’ai siulau paziureti placiau. Ne vien i skirtumus, bet ir valdymo modeli.

  5. www.like.lt

    kaip ir suspejat jus visur tiek prirasyti :)

  6. Shar

    Call Center = priima ir paskirsto skambučius, bet savarankiškai pagalbos neteikia

    Help Desk = registruoja tik gedimus ir sprendžia tik incidentus

    Service Desk = registruoja gedimus, užklausas, prašymus gauti informaciją, prašymus keisti ir t.t. (tikras Single Point of Contact visiems gyvenimo atvejams)

    ITIL sąsajos su Folklendų salų konfliktu yra abejotinos ir labiau panašios į legendą. Kur kas svarbiau yra tai, kad ITIL sukūrimą inicijavo ir iki šiol tobulina UK valstybinė institucija, kurios pavadinimas yra Office of Government Commerce, kas Lietuvoje atitiktų Viešųjų pirkimų tarnybą.

    G2G3 pirmąjį ir dar stalo žaidimą pagamino Microsoft Operations Framework kursui (oro uosto darbo imitavimas).

    Getronics kompanija buvo pirmoji, kuri ITIL v2 pagrindų kursą pradėjo dėstyti vien tik G2G3 elektroninio žaidimo pagrindu (traukinių eismo imitavimas).

    • Skirtumu tarp desk galima rasti. Bet visvien islieka klausimas, kam juos reikejo isskirti? Cia labai idomus klausimas, nes atsakymas paaiskina dar keleta ITIL esanciu anomaliju :)

  7. “Tik, va, su prioritetais neaišku, t.y. nuo ko pradėti paiešką?”

    Išsakysiu 2 mintis šia tema. Valdyti prioritetus, laiką = valdyti savo gyvenimą (vadovams plius dar ir kitų 😉
    Ar kas to moko? Arba kitaip, ar kas geriau žino už save patį? Turbūt dėl to, tiek knygų apie sėkmę prirašytą, kad kiekvienas rašė apie _savo_ sėkmę! kuri kitiems nebūtinai tinka

    Kita mintis iš laiko valdymo metodikų…. yra toks Mark Foster. Iš kur atsiranda prioritetai? Iš prisiimtų įsipareigoimų, per didelių įsipareigojimų, nei galėtum įvykdyti (apie priežastis kitą kartą). Taigi, prioritetai _nesvarbu_ !!! Kodėl? todėl, kad teks įsipareigojimą įvykdyti, net jei jam priskirsi mažą prioritetą… Kartais įsipareigojimai sprogsta, t.y. patys sau pakelia prioritetą, kai pradeda degti… Ir iš kitos pusės, įsipareigojimas, net ir pats mažiausias graužia “iš vidaus” psichologiškai. Ką daryti? Mažinti per didelį įsipareigojimų kiekį. Mark Foster siūlo užsirašyti visus darbus ant lapo (kas lygu įsipareigijimai) ir juos įvykdyti sekančią dieną. Kodėl sekančią? Pirma, bus puikus per 1 dieną prisiimtų įsipareigojimų vaizdas. Be to, taip lengviau susitarti dviem savo asmenybės tariamom pusėm: reaktyviąjai (kūniškai), kuri nėra protinga, tačiau greita ir protingai, kuri nėra greita ir jos ne visada kūnas klauso…

Jūsų komentaras