Az outsourcingról - a jövőd Bére!

Állást kínál

Üdv!

Kérdésem lenne, illetve javaslatokat ötleteket keresek a fenti témához.
Eléggé rendezetlen, és cégenként változó, mindenféle elvárási szintek vannak a nagyvilágban. Kellene valami vonalzó -gondolom nem csak nekem- ami mentén ezt az ügyfél felé, ill vállalási szinten is korrektül lehetne tálalni, és erről tárgyalni.
Mindezt nem csak a magam érdekében dobom fel természetesen, hanem mindenki más -akár céges döntéshozók-okulására is, legyen mit adott esetben eléjük tenni, és ne félmondatos vagy 5 sornyi anyaggal 2 óra gondolkozás után adaállni, és gyengén érvelni valamivel.

Tudtok-e ehhez segítséget, téma leírást, korrekt tartható szinteket biztosító, mindkét fél érdekei szemelőtt tartó ötleteket, időket, vagyis hogyan lehetne meghatározhatóvá tenni az efajta végzett munkát?
Akár 1-1 mondat/gondolat is előre viheti ezt a projektet.
Hosszú még az idő a nyugdíjig gondolom teljes HUP közönség számára, és ha eddig nem is, de a jövőben akár egy másik cégnél, vagy jó esetben saját keretein belül de mindannyian többször kénytelenek leszünk még tárgyalni erről a munkaadókkal, megrendelőkkel. Nem ártana, ha lenne egy közös ismert és használt séma ami alapján dolgozni, és becsülettel vállani lehet dolgokat, vagy urambocsá visszautasítani felkérést.
Higyjétek el, nem könnyű korrektül közérthetően megfogalmazni a fentieket. Ezért is kérdem a nagy közös tudatot! ;)

Általános helyzetben van 2 cég az egyik pl gumicsizmát és féldecit árul, a másik pedig számítástechnikával foglalkozik, és tutujgatja ez előbbi cég gépeit. Pl irodai gépeket, az internet hozzáférést, hálózat, nyomtatók, és mondjuk 1 szervert.
Ez egy darabig rendben van de egyszercsak jön egy okos ember és azt mondja, miután hosszú ideje nem volt különösebb rendszer krach;
Ok, fizetünk a számítástechnikusnak, de szeretném tudni, ugyan miért is fizetünk - mert ugye nem értek hozzá, ezért bíztam meg külön céget- de szeretném mérni, illetve a szerződésben látni, mit is takar a rendszer üzemképes állapotban tartása, illetve milyen pl javítási határidőket várhatok el, mert akkor ha hibázik, pl tudom csökkenteni ezt az összeget, amit hónapról hónapra kifizetek.

A probléma sajna most nálam is jelentkezett, hasonló a felállás fent leírtakhoz. Megtúrtam a netet, de okosabb sajna nem lettem, pedig sok cég anyagát láttam, és nem csak a publikusakat.

  • 2630 megtekintés

( SCD | 2007. 04. 03., k – 14:30 )

Hat szerintem ez elegge nehez dolog lesz. Altalanos tapasztalatom, hogy a cegeknek sokszor sajat maguknak sem sikerul megfogalmazniuk, hogy mire is van szukseguk. Az, hogy miert is fizet altalaban akkor kristalyosodik ki sok vezetoben amikor nem megy a rendszer es nem termel. Az uzemkepes allapot sokszor szubjektum, foleg, ha nincsen lepapirozva, hogy mit vagy koteles elvegezni, ez nalam a szoftvereknel okozott problemat.

( cln | 2007. 04. 03., k – 15:31 )

A dolog majdnemhogy arról szól hogy a megrendelőnek mennyi pénze van.
A egyik véglet amikor nincs pénze és csak a tűzoltást hajlandó kifizetni, alkalmi szervízeléssel. A másik amikor egy fix szervízdíjat fizet mondjuk 8 órán belüli javítással, hardver készletezéssel megfejelve.
A kettő között bármi előfordulhat.
Lényeges azonban az hogy a megrendelő mit vár el a szolgáltatótól és ezt részletesen, _írásban_ kell rögzíteni és azt is ha a szolgáltatást ilyen-olyan okból nem lehet elvégezni, milyen árengedményre lehet számítani.
Ez a részletes szerződés elég macerás lehet, de mindkét fél javára válik vitás esetekben.

( sj | 2007. 04. 03., k – 16:25 )

SLA (=service level agreement) a te baratod. Ebben az ugyfel azt definialja, hogy az egyes szolgaltatasok milyen rendelkezesre allassal legyenek elerhetoek. Ha az ugyfel infotech-ben luzerhozza nem erto, akkor neked kell egy ilyet keszitened, mint javaslatot.

Pl. a nyomtato 98%-os rendelkezesre allasa eseten - egy non-stop kocsmanal - jo ~15 orat eshet ki a nyomtato havonta. Merd fel, hogy a penzedert mennyi energia/munka/ido/penz/... befektetest tartasz igazsagosnak, es aszerint tegy javaslatot. Aztan majd bizonyara jon az alku resze, amiben keszulj fel a szankciokra: mi lesz, ha valamelyik sla mutato nem eri el a kivant (m)erteket - pl. kevesebb fizetes, stb.

Ja, es mindezt (marmint a rendelkezesre allas mutatokat) illik merni, dokumentalni, es igeny eseten atadni a megbizonak, hogy pl. 2007.04. honapban xx.xx% volt a rendelkezesre allas.

ASK Me No Questions, I'll Tell You No Lies

( meditor | 2007. 04. 03., k – 19:12 )

Mondja a cégvezető: Alig látjuk magát, miért is fizetünk?
Mondom neki: Alig látnak? Akkor emelek 25 %-ot.

Megértette.

> Sol omnibus lucet.

( kojot | 2007. 04. 03., k – 20:49 )

Megolvastam a javasoltakat, nem mondom, hogy sokkal okosabb lettem. Egy kicsit....
Igen, lehet tallózgatni a javasolt linkekből, de még mindíg nem látni egy korrekt irányt. A legtöbb dokumentum valamiféle ISO-beli intergrálás előkészítése irányba mutat, és azt, h a nagy cégek igen erősen fényezik ebben a jelenlegi tevékenységeiket.
Az eset tanulmányok, no azok aztán főleg!
De lényegre vissza. A kis/közepes cégek számára ahol már van 5-10-20 gép hálózat, net, hálózatos alkalmazás ésatöbbi, ezekből nem profitálnak semmit sem, legfeljebb lesz egy igen cikornyás szerződésük, amit betesznek a páncél legmélyére.
De én pont nem erre keresek megoldást! Van a birtokomban egy 235 (!) oldalas szerződés! Ezzel odaállítok bárkihez, akkor igen fancsali képet fog hozzá vágni!
Való igaz, SCD megfogalmazása, hogy az ügyfél sem tudja meghatározni, h mire is van szüksége, de ehhez segítséget kell valahogy a kezébe adni.
TE, aki szolgáltatsz neki, ebben saját jól felfogott érdeked miatt kénytelen vagy számára közérthetően elmagyarázni egy LDAP/procmail fontosságát??? Biztos, hogy ezt akarod??? Nem!
Elbíbelődsz a szerverrel, a munkaállomásokkal, a user problémáival ami valóban nagyon sok esetben a tájékozatlanságuk miatt nem jól működik. Ez a munka, és a látványos része, a többi a háttérbeli nem látható mégis mérhetővé/értetővé kell tenned magad...

A kérdés inkább az, hogy mit és milyen szintig érdemes és/vagy szabad lepapírozni. Konkrétumok! De mik legyenek azok? Ne nagy cégben gondolkozz, hanem kicsikben, mert ők vannak többségben az országban, és előbb vagy utóbb de mind rájönnek, h nem akarnak a számítástechnikai problámákkal foglalkozni. A user annyit akar tudni, h bekapcsolja, működik. GÓL! Ha gondja van, és ügyes megoldja, ha nem akkor mi a telefonszám amit hívnia kell.
Előbb utóbb minden cég ebbe az irányba fog fordulni, és egy vidéki cég nem akar Bpesti multival foglalkozni, márcsak a kiszállási díj miatt sem. Aztán meg azért nem, mert sok a rossz tapasztalat a Bp központú országos cégekkel. Pereskedni meg nem akar. Tehát helyben akarja megoldatni a kis problémáit valakivel.
De ezeket a probléma forrásokat valahol értékeltetni kell vele úgy, h nem fullad bele a papírba, sem te, mert az egyszerű user lusta, ebből kell kiindulni. Lejegyzőkönyvezed 2x, 3x és aztán elege lesz belőle, h minden apró cseprő dologért A4 méretben kellett panaszkodnia.
A vezetés, pedig kitörli vele a hátsóját, Te meg erre dolgozol havonta felesleges órákat, miután elvégezted a valós munkát.
Tehát hol az egészséges és konkrét határ?

ui.: (Urak aki nem látná, kicsit a jövőbe, jóelőre próbálok irányt mutatni/keresni annak aki fel akar készülni rá idejében!)

Nézz megy egy internet-szolgáltatás Általános szerződési fdeltételeit pl. Abban szépen le vagyon írva, hogy mi az, amit szolgáltat, az a teljesz szolgáltatási idő mekkora hányadában áll rendelkezésre, ezt a célértéket hogyan kell értelmezni, illetve mérni, hiba esetén milyen reakcióidőt vállalsz, a bekövetkező eseményeket ki, hogyan priorizálhatja, egyáltalán ki jelenthet be hibát, hány bejelentés kezelését tartalmazza a havi számla, stb, stb, stb. Egy jó szolgáltatás-katalógust, illetve SLA-vázat (hogy az a szolgáltatónak és az ügyfélnek is jó legyen) igen combos meló összehozni, de ha ezzel (IT-üzemeltetés másoknak) foglalkozol, akkor nagyon ajánlott/érdemes.
ITIL-ből mindenképp javaslom az incidens- illetve problémakezelés, valamint a változásmenedzsment témakörök erős tanulmányozását -- minimum ezeket, de a többi is nagyon hasznos.

Aki meg nem akar "papírozni", bármelyik oldalon, az a teljesítményt, illetve az elvégzett munkát sem óhajtja mérni. Márpedig anélkül nehéz bizonyítani (akár pro, akár kontra), hogy az adott szolgáltatás a szerződésben foglaltaknak megfelelt/nem felelt meg.

Igen, pont ezen volnék, ilyen anyagokat böngészgetek. Csak tudod pont azt akarom elkerülni, h se túl se alacsony ne legyen a mérce. A "nagyok" könnyen lazázhatnak, és átléphetnek olyan szinteket más egyéb külső dolgokra hivatkozva, amit a kicsiknek még le kell bontani, meg kell magyarázni.
Tehát, ha egy életszerű helyzetben gondolkoduk.
A GumicsizmábanFelest szolgáltató cégnél a vezetés 2 ember, 2 a marketing, 4 az adminisztráció, 1 ügyfélszolgálat és 1 titkárnő. 60 alkalmazott, és közel 3000 ügyfelet szolgálnak ki.
Vagyis mindössze 10 ember számtech igényét kell kiszolgálni, akik tudják mi a dolguk. Tehát viszon olajozottan megy a meló, de előfordulnak ugye itt is ilyen olyan problémák. No ilyen környezetben kell megfelelő leírást találni. Az ITIL sajna a százas, vagy nagyobb nagyságrendre húzható rá, nem egy ilyen környezetre. Csak egy két mondat emelhető ki belőle. Én viszont a többi mondatra is megfelelő választ keresek, mert nem az ügyfél elijesztése a célom.
Azért is fordulok a közhöz, h a későbbi közönség részére is mércét tudjunk esetleg most kitalálni/kidolgozni. Köszönöm a tippet, és várok még hasonlókat!

Az ITIL ráhúzható a kicsire is, csak tudni kell, hogyan. Előző hozzászólásomban, ha figyelmesen olvastad :) találtál néhány megválaszolandó dolgot. Azokra próbálj válaszolni, betartható, épkézláb értékeket kitalálva. Egy hevenyészett példa, összegeket nem írok: 


Rendelkezésre             5*8             5*12       
állás, e-mail             (8-17)          (8-20)     
Reakcióidő e-mailre       4ó              2ó         
(visszahívás)                                                    
Rendelkezésre             5*12            5*12       
állás, telefon            (8-20)          (8-20)     
Helyszini megjelenés      6ó              4ó         
(rendelkezésre állási                                            
időn belül, legkésőbb)                                           
Havi díjban foglalt       4ó              8ó         
helyszini óra                                                          
További óradíj            xxxxFt          xxxxFt     
Távoli módosítás          4 alkalom       8 alkalom  
Incidenskezelés           4alkalom        8 alkalom
(Továbbiak T&M alapon, 
minimum 0,5 óra/alkalom)        
Frissítések               NBD             SBD
-----------------------------------------------------
Szerver esetén:           .... Ft/gép     .... Ft/gép
Munkaállomás esetén       .... Ft/gép     .... Ft/gép

Az egyes szolgáltatások vállalt rendelkezésre állását egyenként mellérakod, illetve a nem teljesülés esetén kötbérre vonatkozóan is megállapodtok; a lényeg, hogy valamennyi fogalmat egyértelműen tisztázni kell a szerződésben (pl. e-mail rendelkezésre állás: adott időintervallumban figyeljük a beérkező leveleket)

No ez az!

Pont ilyenekre gondoltam! Ui. ezek azok az általában nem deklarált vagy nehezen megfogalmazható dolgok, amiket az ügyfél egy webhosting esetén pl csont nélkül elfogad. Ott azt mondod, ennyi a dns, ennyi a webhosting havi díja ennyi emailt, tárhelyet tartalmaz, meg még 5 jellemző .. a végén pedig ott van, h jahh csókolom mindez a nap 24 órájában, az év minden napján rendelkezésre áll.
Éves hiba/akármi miatti állásidő miatt pedig 99%-os a teljesítés.
Ez utóbbi miatt az ü.fél lenyűgözve érzi magát,h hú de nagyon ki van szolgálva, mert x darab gép miatta folyton be van kapcsolva, dedikált szolgáltatás ésatöbbi, és nem kérdezősködik tovább, aláír!

Ugyanez kisvállalati környezetben nem érvényes. No és pont ez a keretrendszer kitalálása lenne az érdekes.
Márcsak jól megfontolt saját anyagi érdekeink miatt is. Ui egy korrekt érvrendszerrel, kidolgozott stratégiai tippekkel, kiszorítósdit is el lehet érni a nagyobb de a méret és döntéshozási korlátok miatt lassabb ISO9xxx-el hivalkodó nagy cégekkel szemben. Épp azért, mert rugalmasabban tudsz helyben reagálni a felvetődő problémákra. Főleg ugye ha linux mint fő szerver, ott lóg a neten, és azon gazdálkodsz az erőforrásokkal. Ez itt ugyanis egy igen komoly piaci rés!

Miért, kisvállalati környezetben mi van? Van mondjuk központi fájlszerver, van centralizált nyomtatás, van levelezés, van squid, meg vannak munkaállomások. Hmmm? Ezekre a szolgáltatásokra is lehet rendelkezésre állást vállalni... Hmmm?

Igen, és nem is gondolod mennyire komoly mai napság már ez a dolog!
Én azt szoktam mondani,-gyakorlati tapasztalataimból- hogy 5 gép vagy afelett igenis, feltétlenül legyen egy fix megbízható szerződése a cégnek szt. munkákra, pl általánydíjas szerződési formában. Csak ha ez megvan, akkor jönnek rá, hogy tényleg szükségük van rá, mert nem akarnak állandóan a gépekkel, azok nyavajáival szösztmötölni, ideiglenes megoldásokkal épphogycsak elvégezni a melót. Van egy olyan cég, ahol csak 3 fix gép van, meg egy pár öreg laptop, de annyi féle dolgot végeznek rajtuk, annyi mindent kell hónapról hónapra megoldani, -ami egyszerűen csak a természetes mindenapi munkájukhoz tartozik, tehát még nem is csak a hibákról beszélek-, hogy már oda is szerződést ajánlottam!
A vezető pedig rögtön ráharapott, tárgyalunk. Neki is olcsóbb, kevesebb a kieső idő ésatöbbi....

"Ugyanez kisvállalati környezetben nem érvényes. No és pont ez a keretrendszer kitalálása lenne az érdekes."

Gondolataim a témában....

Minden support jellegű szolgáltatás alapja az igényfelmérés. Ez alatt azt értem, hogy ki kell menni ügyfélhez, és felmérni milyen szolgáltatásokat használ.

Fel kell mérni, hogy melyik egység kiesése, mekkora üzletmenet kieséssel jár.
Pl. ha a cég üzletmenetében fontos az email, mert naponta több millás ajánlatokat küldenek emailben, akkor azt be lehet sorolni mondjuk egy két órán belüli garantált megjelenés kategóriájába.

Ha Gizike gépe esik ki, és a repikaja megrendelés áll, akkor az lehet akár egy 8 órán belüli megjelenés is.

Nyilván, hogy melyik eszköz mennyire fontos, azt az ügyféllel közösen kell meghatározni, mert ő tudja, hogy az a tevékenység mennyire fontos neki.
A legegyszerűbb egyébként, ha felteszi a kérdést az ember pl. a mail szerver kapcsán: "Mekkora haszontól esik el kb. a cég, ha 1 napig nem megy az internetes levelezés?" - erre azért már jóval könnyebben tud válaszolni az ügyfél.

Érdemes azt is lefektetni SLA-ba, hogy az egyes komponenseknél mit értünk megfelelő működés alatt, mi tartozik bele a keretszerződésbe.
Pl. Ha csak a kliens gépek hardverére szerződünk, akkor az SLA-ban az van, hogy a gép működőképes, ha a windóz bebootol, be lehet jelentkezni, és a diszken nincs szektorhiba. Ezáltal elkerülhetjük azt, hogy ha Gizike beüt egy "format c:" -ot akkor azt a szerződés keretében kelljen megcsinálni, és ne extra óradíj legyen számlázva.

Ha megvannak a rendelkezésre állási csoportok, megvannak a garantált kiszállási idők, definiáltuk, hogy mi az a működő szolgáltatás, akkor lehet árat kalkulálni. Ezt szintén a fentebb említett csoportok alapján érdemes bontani.

Fontos, hogy az árkalkulációnál számoljunk az egyes eszközök hardware-értékével is, mert ha igen rövid a garantált megjelenési idő, akkor tartalékalkatrész raktárral is kell rendelkezni.

A korrekt ügyfélkapcsolat alapja az is, hogyha elvállalunk valamit, de nem sikerül betartani (pl. kicsúszunk a garantált megjelenési időből.) akkor benne legyen a szerződésben, hogy mekkora összegig vállaljuk a szolgáltatásért a garanciát. (Pl. max. a havi díj 3 szorosáig) és ezt milyen formában térítjük meg az ügyfélnek. (Havidíjban jóváírható, vagy pénzvisszafizetés, vagy ajándék hatputtonyos, akármi...)

( dii | 2007. 04. 04., sze – 00:15 )

Szia!

Mivel egy darabig én is ilyesmit csináltam, gyakorlati szemmel:

Vannak cégek, ahol nem sajnálják a pénzt és mindegy mi van leírva, ha baj van, akkor segíts, egyébként menjen rendben minden. Ha venni kell cuccot megveszik, ha fejleszteni kell megvan. Lehet jobbra balra dokumentálni, szerződni, ha jó a partner, megéri neki dolgozni, neked is neki is, nincs fillérezés. Asszondják errefelé, hogy "win win situation", mindenki boldog.

A másik eset a zsugori cég. Nem akar készenléti díjat, semmit sem fizetni, de ha baj van, akkor nagyon sürgős és nem tudnak nélküle élni. Plusz alkudoznak. Igazán röviden, ne állj szóba velük. Persze lesznek infóhuszárok, akik majd megcsinálják fillérért, de hidd el, hogy nem ér ennyit.

Ha mégis rákényszerülsz a kellemetlen a megbízóra és bizonyítani kell, háááát. Csúnyát mondok. A szerver mondjuk levelezik veled. Berohansz időnként, hogy a szerver üzenet küldött, például hogy meghibásodott az egyik RAID lemez. De ne aggódjanak, minden a legnagyobb rendben. 10 percet szöszmötölsz, azt lelépsz. Érezteted, hogy fontos vagy. Ez néhány balféknél bevállik. Érteni úgysem értenek hozzá. Sorry ha felháborítottam valakit :D

A magyar valóság ez. A legveszélyesebb kategória az info_huszár.
Elviszi az orrod elől a pénzt, de rendet raknod végül neked kell
- megteszed a további megbízás reményében - majd ha rend van
(= minden simán megy) akkor ejtenek.

Le az infohuszárokkal!

> Sol omnibus lucet.

Igen ez sok esetben egy általános szerződési feltételekkel működik is. De az élesedő szem nem mindíg a megfelelő helyre fókuszál... Ebben az esetben is így volt/van, ami miatt elindítottam ezt a fórumot.
Az én alap hozáállásom az, h a rendszergazda, legyen korrekt minden körülmények között. JOGILAG is!

Az infóhuszárokról csak annyit, h sajna én is találkozom ilyenekkel, csak én kispistikéknek hívom őket. Azért mert valaki látott már linuxot, és mert sikerült feltelepítenie attól még nem rendszergazda. Az ilyeneknek valójában fingjuk sincs róla mit is kellene teljesíteni, de mindenképp. De a csilivili az kilóg a szerver szájából! ;)
Szerintem pl. lásd ezt http://ad.adverticum.net/b/cl,1,6022,154570,219792/click.prm
Aki használt és rajzolt párszor painbrushban, az, attól nem képzett reklámgrafikus!
De ezt el is kell tudni mondani, és az ü.féllel meg kell értetni! JAhh és a legfontosabb, h megfelelő korrektségű szerződéssel rendelkezz! Ő a megrendelő, a fizetőképes partner, akkor tegyen meg az ember minden korrekt lépést az érdekében. De ez jelen esetben sem egyszerű. Sajna előre látható lesznek még ilyenek szép számmal, és akkor más is csak vakargathatja a fejét, h í"ugyanmitiskéne" ehhez összeírni, h megnyugtassam a kedélyeit.

( kojot | 2007. 04. 04., sze – 20:12 )

Pl ilyenek is ide férnek, de sajna ez csak az általános...
***Számítógép karbantartás magában foglalja a következő szolgáltatásokat:
➢ A számítógép teljes körű javítását, mind hardver, mind szoftver szinten
➢ Meghibásodott periféria, kártya, illesztő, vagy fődarab cseréje, amennyiben
szükséges egyéb szakszervizben való javíttatása, mely külön számlatételt képez,
jelen szerződés kereteibe nem tartozik.
➢ A felhasznált vagy cserélt alkatrészek külön számlatételt képez, jelen szerződés
kereteibe nem tartozik.
➢ Szándékos rongálás, vagy számítógép felhasználó által történő félre konfigurálása
és/vagy hasonló jellegű hibák javítása-helyreállítása külön számlatételt képez, a
jelen szerződés kereteibe nem tartozik.
*** Szerver karbantartás esetén:
➢ A megállapodott tároló egység biztonsági mentése meghatározott időközönként a
rendelkezésre álló technikai eszközökkel.
(Egyéb archiváló eszközt csak külön megállapodás esetén biztosítja a szolgáltató.)
➢ Biztonsági megoldások bevezetése és működtetése szükség szerint.
➢ A rendszergazda által meghatározott intézkedések-javaslatok be nem tartása
és/vagy megkerülése, vagy bármely ez irányú viselkedéből-használatából eredő kárt
helyreállítása a megrendelőt terhelik, amely nem tartozik jelen szerződés
tárgykörébe.
 Számítógép újratelepítés évente maximum egy alkalommal, amennyiben az technikailag
indokolt.
 Eszköz-Áru rendelés-beszerzés:
➢ A szolgáltató a termék vételárának 60%-át, mint előleget kérheti, melyet a
megrendelés késedelmes visszavonása esetén nem fizeti vissza.
 Hiba átadás átvétel, visszajelzés:
➢ Telefonon, e-mailban egyaránt közöltnek tekintendő, de minden problémát a
megrendelő egy, a helyszínen elérhető füzetben (pl.: indigós átírótömb) köteles
részletesen feljegyezni. A hibásnak vélt gép, bejegyzés vagy hibaleírás nélkül
hibátlannak minősül.
➢ A bejutást a javítás helyszínére a megrendelő a egyeztetett időpontban biztosítja,
vagy egyéb bejutási lehetőséget biztosít.

( kojot | 2007. 04. 04., sze – 20:16 )

Hűűűűű!

Jó sokan olvastátok, legalábbis tekintették meg, a teljes idejáró közönség nagy része ha jól emléxem a számadatokra.
De kicsit mintha megtorpant volna a dolog, pedig leglább annyira fontos az üzemeltetés, mint az ismeretek cseréje, és a hírek!

Csak egy tipp: mivel normális informatikus és ügyfél eredendően lusta, és szívesebben dolgozik, mintsem dokumentálással tölti idejét, érdemes megfontolni egy bugreport rendszer (akad jópár opensource, egész kellemesek!) üzemeltetését. Kölcsönösen jó: ügyfél nem unja meg olyan gyorsan, nem kell lapokat teleírnia, nyomonkövethető (x időpontban adta le, y időpontban került fel hibalistára prioritás besorolással, z időpontban érkezett rá érdemi válasz), elszámolható, statisztikát lehet belőle gyártani stb; akár még azt is lehet itt közölni, hogy éppen milyen háttértevékenységek zajlanak, mikor és meddig (pl. 13:25-14:40 ldap karbantartása, hibamegelőzés kiesett hálózati szolgáltatással kapcsolatban stb.), hány embert vett igénybe. Nagyon sok cégvezető csak a tömörített és látványos adatokat szereti, lehetőleg összevethető formában, erre alkalmas lehet egy standard kategóriákkal operáló statisztika. Ha meghagyod a lehetőséget ügyfélnek adott hiba lezárására, megjegyzés hozzáfűzésére, akkor még lobogtathatod is az örömtől ragyogó szmájlikat cégvezető előtt :) Mindehhez általában egy webszerver, adatbázis, alkalmazás, valamint böngésző és internet kell ügyfél oldalán - egyik sem túl nagy igény.

Problémák, amik ezzel kapcsolatban megfontolandóak: "Nem megy a zinternet"... "Nem me gyaszámítógép", vagy egyszerűen az, aki hibát jelenthet (ha mindenki, akkor a piszlicsáré baromságokat is incidensként jelentik, ami a havi elszámolásban randán bír mutatni (28 incidnes volt, ebből 10 a díjban foglalt, 18 meg olyan, amikor Mancika nem találta az "any" billentyűt), az nincs gépközelben...

Lehet ilyen megoldást csinálni, de a hibajelzést más útvonalon is kell fogadni, illetve az események hiztory-ja ne legyen teljesen publikus, még az ügyfél felé sem(!).

Hibabejelentést csak X.Y.-tól, e-mailben (ttf. hogy nem e-mail hamisító társulatot vezet :-)) vagy telefonon fogadsz el (ha ismered, akkor a hangja alapján, ha meg nem, akkor rákérdezel,hogy kivel beszélsz). Ha az adott havi "keret" (havi díjban foglalt incidensek száma) elfogyott, akkor figyelmezteted erre a bejelentőt, és jelzed, hogy ez már pluszban fizetendő esemény.

A "nem megy a levelezés", "nem megy az internet" és hasonló dolgokra a jó megoldás az, hogy pontosan le kell írni, hogy milyen szolgáltatásai vannak az általad felügyelt/karban tartott rendszernek, és azokra te milyen rendelkezésre állást, hibaelhárítási időt vállalsz, illetve nem teljesítés esetére milyen kötbér illeti meg az ügyfelet.

Az incidenskezelés historyja meg azért ne legyen teljes egészében elérhető az ügyfél számára, mert kerülhet bele olyasmi is (PEBKAC esetén pláne...) amit annál diplomatikusabban kell kezelni... Legyen "képben" az ügyfél arra nézve, hogy mikor jelentette be a hiubát, mikor kezdted megcsinálni, mikor kontaktoltál hibalehárítás közben vele vagy valaki mással a cégétől, meg hogy mikor lett készre jelentve, illetve a készre jelentés az ügyfél által elfogadva. Ezen felül az egyes tevékenységek leírása ie kerüljön bele, de legyen lehetőség privát, az üf.által nem látható megjegyzések leírására is.