Vállalatirányításról közvetlenül - érthetően
Facebook
Linked In
Rss

Giller Tamás

COM_6565+800.jpg

Forrás: Computerworld

Fotó: Rózsa Zsuzsanna

Kulcs-Soft

erp_blog_banner_003.png

Giller Tamás

Több, mint 10 éves szakmai tapasztalat informatikai szolgáltatások területén: ERP, CRM, egyéb vállalati szoftverek bevezetése, tanácsadása, üzemeltetése.

Pénzügyi, üzleti és informatikai tudás!

Projektmenedzsment tapasztalat, NAV, ITIL szakvizsga!

Több mint 5 év vezetői tapasztalat (CFO, IT/IS).

A Piac & Profit valamint a Computerworld szakértő partnere.

ERP - múlt, jelen, jövő

csak-könyv_2.png

ERP - past, present, future

angol_könyv_reklám.png

A könyvemről

Kulcsár Tibor (Kulcs-Soft alapítója):

"Gratulálok a könyvedhez Tamás, nagyon jó volt! Még nem olvastam olyan könyvet az ERP-ről, amely ennyire szakszerű és olvasható lenne egyben. Annyira tetszik, hogy szeretném tananyaggá tenni a Kulcs-Soft-ban. Szeretnék 20 példányt rendelni belőle a kollégáim részére."

Hetyei József (Certified Management Consultant):

"A könyv stílusa kellemes, olvasmányos, jól érthető. A könyvben összefoglalt tapasztalatok hasznosak lehetnek mind az ERP rendszereket bevezető kkv-k, mind a számukra ilyen rendszereket szállító, azokat (bevezetés során és az után) támogató vállalatok számára."

Hoffer István (abas Magyarország ügyvezetője):

"A könyv második része, amely az ERP kiválasztásról és a bevezetéshez kapcsolódó projektről ad információkat, abszolút hiánypótló a magyar piacon. Én nagyon vártam már egy ilyen kiadványra."

Juhász Zsolt (rEVOLUTION Software Kft. ügyvezetője):

„Érdekes, olvasmányos, sok helyen visszaköszönnek az általam is hangoztatott gondolatok. A könyv végén nekem egy picit sok lett a kiegészítő téma, ez egy picit elviszi a fő téma súlyát. De örülök, hogy a könyv az ERP kérdés teljes szélességét felvállalja.”

Támogathatsz

Ha szeretnéd támogatni az ERPBLOG működését, akkor most megteheted.

Köszönöm, hogy támogattál!

Facebook

www.erpblog.hu

A nevem Giller Tamás. 2003 óta foglalkozom Informatikai Szolgáltatásokkal (ERP és CRM rendszerekkel). 2003 év elején közgazdászként diplomáztam a Pénzügyi és Számviteli Főiskolán majd a Summit Autó Magyarország ZRt.-nél - a Summit Solutions nevű üzletágnál - kezdtem dolgozni, saját fejlesztésű vállalatirányítási rendszerekkel. Két év után 2004 év végétől kezdve közel 1 évet töltöttem Ausztráliában, ahol pénzügy menedzsmentet hallgattam. 2005-től projektvezető lettem a Summit Autó Magyarországnál. 2006-tól a Karádi Rendszerháznál dolgoztam Microsoft vállalati termékekkel (Navision, CRM). 2008 és 2015 között a DLM Solutions Kft. üzletágvezetője voltam. Azóta pedig egy mezőgazdasági informatikával foglalkozó startup (Gremon Systems Zrt.) pénzügyi igazgatója vagyok. Szeretném megosztani veletek azokat a tapasztalataimat, amelyeket az informatika ezen speciális világában töltöttem, az elmúlt több mint 10 év során. Remélem a témák érdekesek lesznek és egy jó kis szakmai műhely alakul ki!

ITIL

 

Microsoft Business Solutions Specialist

specialist.png

Prezume

Elérhetőség

Ha kapcsolatba szeretnél velem lépni, mert véleményed van, meg akarsz osztani velem valamit, segítségre van szükséged, vagy van egy jó ajánlatod számomra, akkor ne habozz, írj nekem!

tamas.giller@gmail.com

ITIL összefoglaló

Search Clear

Friss topikok

Kiemelt partnerek

PP.jpg

Computerworld.gif

Partnerek

Bridge.pngdlm_1.pngk2d.png

xapt.pngkaradi_1.pngdyntell.png

kulcs.png 

ggx.png

abas.png  

2_2.png

 

  

KRONOS.jpg

 

 

weblogo.png

  

  

uj_SAP_logo.jpg

 

SymbolTechLogoNEW_240x240.png

 

llp_logo_standardcolour_clear_background.png

 

      UNIT4_logo_VT-SOFT.png

 

ifs_logo_180.png

 

TRL_logo_cegnevvel2.png

 

Hogyan NE jelentsünk be hibát!

2015.02.02. 07:00

Biztosan tudjátok, hogy a munkám során egy support központot (is) vezetek. Ez egy nem túl nagy support központ, összesen négyen látjuk el a feladatot és kb. 500-600 felhasználót szolgálunk ki. Megnéztem egy statisztikát is, a tavalyi évben (2014-ben) közel 400 bejövő hívást kezeltünk havonta, nem számítva a saját mobilhívásokat és bejövő e-maileket. Persze nem úgy kell elképzelni, hogy mind a négyen egyfolytában a telefon mellett ülünk és várjuk a hívást, de aki irodában van, azok közül bárki felveheti a telefont. Van egy dedikált ún. elsődleges supportot ellátó kolléga (1st line support), aztán van két tanácsadó kolléga és én (2nd line support) és ha nem tudjuk megoldani, akkor egy igénykezelő rendszeren keresztül (ticketing system) delegáljuk a problémát, feladatot a fejlesztés részére, akik így az ún. 3rd line supportot látják el.

tumblr_m7do1deqes1qa8nfxo1_1280.jpg

Ahogy egy korábbi cikkben is utaltam rá, az ügyfélszolgálaton mindig zajlik az élet. Most be szeretnék mutatni néhány tipikus hibabejelentési hiba típust, amit általában ügyfelek követnek el. Na nem azért, hogy kioktassak bárkit, de egy hibabejelentésnél az SLA-kban általán 1-2 óra szerepel, ha viszont a hibabejelentés nem pontos, hiányos, akkor nem valósulhat meg az SLA-ban vállalt határidő. Ilyenkor ráadásul nem is a szolgáltató hibája miatt nem valósul meg az SLA-ban foglalt határidő, hanem a bejelentő miatt. A következő néhány pontban tehát tipikus bejelentési hibákat szeretnék bemutatni. Az üzleti levelezéssel kapcsolatban már egyszer írtam, érdemes előtte végigolvasni.

1. Továbbküldés

Cégeken belül gyakran előfordul, hogy a munkatársak nem adhatnak le semmilyen hibát, változtatási kérést vagy új igényt közvetlenül a szolgáltató felé, helyette házon belül van egy koordinátor, akinek feladata lenne, hogy megszűrje a házon belüli hibákat, igényeket (kvázi egy kulcsfelhasználó), és csak azokat küldje meg a szolgáltatónak, amelyeket ő nem tudott kezelni. Hát ebben sajnos nem mindenki sikeres. Sajnos több esetben is előfordul, hogy ez a koordinátor egyszerűen továbbküldi a saját kollégája levelét anélkül, hogy megértené a problémát, vagy megpróbálná megérteni a problémát. Esetleg el sem olvassa. Vagy adott esetben nem is a szolgáltatóra tartozik az ügy. Például fordult már elő, hogy az iroda klímájával kapcsolatos problémát küldtek tovább nekünk, mi pedig természetesen nem a klímával, hanem a vállalatirányítási rendszerrel foglalkozunk.

2. Csak hibaüzenet

A másik tipikus probléma amikor csak átküldenek egy hibaüzenetet a felhasználók és mellé csak annyit, hogy ez a hiba jelentkezik. De körítést már nem tesznek mellé, hogy a hiba akkor jelentkezik, amikor az adott modulban ezt és ezt csinálom. Pedig ezen információk nélkül a képernyőn megjelenő hibaüzenet nem ad elég támpontot, hogy segíthessünk, a segítségnyújtásnál viszont az idő a legfontosabb.

3. Hibaüzenet rosszul kiegészítve

Vannak olyan felhasználók, akik már profibbak és tudják, hogy egy hibaüzenet lejelentésénél a hibaüzenet mellé célszerű valamilyen kiegészítő információt is adni, de sokszor mégis hibáznak a felhasználók. A kapott hibaüzenetekről készült képernyőfotókat nézegetve vettem észre, hogy sokszor mérnöki pontossággal helyezik a felhasználók a hibaüzenetet egy olyan pontra a képernyőn, amivel hasznos információt takarnak el (például az alatta lévő képen látható számlaszámot, vagy munkalapszámot), de ezt az információt külön már nem írják le. Így előfordul, hogy kapunk egy hibaüzenetet, még azt is tudjuk, hogy számlázási gond van, de sajnos a hibaüzenet pont a számlaszámot takarja el (és a felhasználó nem mozgatja el és nem is írja le a levélben).

4. Válasz mindenkinek

Na ez még mindig a vesszőparipám, elég borzasztó, hogy olyan felhasználóknak is, akik napi szinten több tucat levelet írnak és a munkájuk szervers része az elektronikus levelezés, fel kell hívni a figyelmüket, hogy válasz esetén a "válasz mindenkinek" opciót használják. Hibabejelentésnél ugyan nincs ilyen opció, hiszen a felhasználó ír egy levelet a címzettnek. Viszont a címzett saját hatáskörben akár több munkatársat is rátehet a levelezésre és ezeket a személyeket az ún. CC mezőbe (másolat) teszi. A felhasználó viszont gyakran ilyenkor már nem "válasz mindenkinek" opcióban levelez tovább, megfosztva a többi felhasználót az értékes információktól, akik viszont enélkül nem tudnak segíteni.

5. Inkább írásban, mint telefonban

Én azt gondolom, hogyha egyértelműen hibabejelentésről beszélünk, akkor sokkal hatásosabb az írásbeli bejelentés (e-mail), hiszen ilyenkor csatolmányt, képernyő képeket és kiegészítő szöveget is a szolgáltató tudtára tudunk adni, ráadásul időbélyeggel ellátva (pontosan visszakövethező, hogy mikor adtuk le a hibát). Telefonon inkább konzultációt érdemes kérni, hogyha elakadt a felhasználó egy bizonyos dologban és tudja, hogy egy kis segítséggel tovább tudna lendülni a problémán, de nem hibával áll szemben, hanem inkább felhasználói hiányosság van a dologban.

És minden hibaleadás előtt egy tanács, amit én magam is meg szoktam fogadni: Próbálja meg újraindítani!

15 komment

Címkék: oktatás tanácsadás informatika érdekek ügyfelek

A bejegyzés trackback címe:

http://erp-blog.blog.hu/api/trackback/id/tr257079645

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.

annmbp 2015.02.03. 10:18:48

5-600 felhasználóból 400 havonta? Valami nagy baj lehet ennél a cégnél.
Jómagam 2000 körüli ügyfelet kezelek, hibajegyek száma havi 15-20.

Giller Tamás 2015.02.03. 10:52:51

Üdv!

Én nem azt írtam, hogy 400 hibajegy van :), hanem ennyi bejövő hívás (nagy különbség). És igen 400 bejövő hívás van egy ekkora hálózatnál. Ez egy vállalatirányítási rendszer, amire havi szinten kb. 500-1000 fejlesztési óra (új igény, változtatás) kerül ki. Rengeteg újítás, fejlesztés. És az ügyfelek nem szeretnek használati útmutató olvasni, sokat kérdeznek. Vagy mert érdeklődnek, vagy mert egyszerűen elakadtak.

annmbp 2015.02.03. 11:22:09

@Giller Tamás: áh, ok, így rendben van, ha folyamatosak a fejlesztések

wrstjnethn 2015.02.03. 14:14:51

4. pont: Ha ennyire gyakori, hogy az ügyfelek nem a válasz mindenkinek opciót választják, akkor ha választ várnak az ügyféltől, érdemes lenne a levél végére odabiggyeszteni, hogy:

"Kérem válaszát a 'Válasz Mindenkinek...' opció használatával küldje el Részünkre!"

Vagy részletesebb, jövőre nézve nevelő-magyarázó komment:

"Mivel a probléma megoldásán mostantól több kollégánk is dolgozik, kérem válaszát a 'Válasz Mindenkinek...' opció használatával küldje el Részünkre!"

Marketing válasz:

"Mivel a jelzett probléma mielőbbi megoldásán mostantól több szakemberünk is dolgozik, a gyors és hatékony problémamegoldás érdekében és a minőségbiztosítási rendszerünkben vállalt feldolgozási határidő betartásához kérem válaszát a 'Válasz Mindenkinek...' opció használatával küldje el Részünkre!"

Giller Tamás 2015.02.03. 14:27:56

@wrstjnethn: ezek valóban jó megoldások! A probléma az, hogy már eleve fel kell hívni rá az emberek figyelmét, olyanokét is, akik számítógépes munkát végeznek :).

kneissl 2015.02.03. 14:44:39

Ha feltételezzük, hogy nem magadnak írod a blogot, hanem számítasz pár olvasóra, akkor ...pl ...
...biztos, hogy mindenki (minden potenciális olvasó) tudja azt, mit jelent az "SLA" ?
;-)

Giller Tamás 2015.02.03. 15:31:22

@kneissl: Üdv! Kicsit meglepődtem, hogy mi ez a hirtelen érdeklődés a blogon, aztán egy olvasó mutatta, hogy a blog kikerült az Index2 címoldalra. Így nyilván több olyan olvasó is rákattintott, akik eddig nem jártak itt :), aminek nagyon örülök!!! A blogot - remélem - nem csak magamnak írom, de az SLA - Service Level Agreement (Szolgáltatási szintekről szóló megállapodás), már annyi cikkben és írásban megjelent, hogy ebbe nem írtam már le hogy micsoda, mert valóban a törzsolvasók tudják (nem tudtam, hogy Index2 címlap lesz :)).

De ha a blog keresőjébe beírod, hogy SLA, akkor több cikket is kapsz eredményül, például ezt: erp-blog.blog.hu/2013/10/15/szerzodes_menedzsment_contract_management és ebben le van írva pontosan mi is az.

De röviden annyi a lényeg, hogyha leszerződsz egy informatikai szolgáltatásra valakivel, akkor szinteket állapítanak meg, például hibajavítás 1 órán belül, vagy 2 órán belül, vagy távolról elháríthatatlan hiba esetén 2 órán belül helyszíni kiszállás, stb. Nyilván minél jobb szolgáltatást kérünk, annál drágább a szerződés és így többe kerül a díj.

Remélem azért máskor is benézel hozzám :)!

pythonozok · http://visszabeszelo.blog.hu 2015.02.03. 17:21:54

@Giller Tamás: a cím nálam kiverte a biztosítékot. Azt hittem, valamelyik "telko" szolgáltató helpdeskesének nyavalygását kell majd olvasni. Már épp készültem pár cifra válasszal, de így, hogy majdnem kolléga... :)
(Anno üzemeltettem, az elején mi voltunk a helpdesk is)

Giller Tamás 2015.02.03. 20:50:49

@pythonozok: Örülök, hogy megváltozott a véleményed :). De a hozzászólásoknak mindig örülök, én nem vagyok letéteményese a biztos tudásnak. Én csak tapasztalok sok mindent és azt leírom :). A lényeg az lenne, hogy ne csak én írjam le :) hanem ti is!

Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:40:20

"És minden hibaleadás előtt egy tanács, amit én magam is meg szoktam fogadni: Próbálja meg újraindítani!"
- Hehehe... szóval windows. Vagy Java. Én számítógépen dolgozom. Volt h egyszer rácsodálkoztunk egy tervezett áramszünetnél, hogy bazz, másfél éve hívtunk utoljára IPL-t.

Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:45:44

Én még a 90-es évek elején voltam tanfolyamon, hogy kell kezelni a felhasználókat, a nyikorgó "ljuzereket".
Komolyan az egyik első kérdés amit oktattak, hogy melyik gép előtt ül és az be van-e kapcsolva? :-))

Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:47:48

Aztán tényleg volt ilyen. Én rendszergarázda voltam, nem szupportos, de én hülye felvettem egy telefont. Egy nagyhatalmú csávó üvöltött velem, hogy szar minden és nem megy. Kiderült - több rendszer is volt biztonsági okok miatt, teljesen elkülönült hálózatban - hogy a másik rendszernél próbálkozott. :-)

Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:58:28

@annmbp: "hibajegyek száma havi 15-20. "
De jó neked. Nekem csak mint renccer garázdának küldi a szupport másolatban a cuccost és kapok vagy százat naponta. Igaz eg része jogosulcság ügy, amihez közöm nincs.

mt-03 2015.02.04. 08:43:37

mivel tobbek kozt en magam irom a rendszerunket, ezert a hibajegyek beerekezesenel arra tudok tamaszkodni amit magamnak a hibajelentesben elhelyezek (szerencsere ugyfellel kozvetlenul nem nagyon beszelek, nem is szeretek;). ez sztem nagyon fontos dolga a programozonak hogy olyan hibat legyen kepes kikopni a rendszer amibol o hozzaadott info nelkul meg tudja oldani az ufsz a hibat. pl itt emlitett dolgok kozul nem a felhasznalotol varom hogy a szamlaszamot vagy barmifele azonositot megmondjon. ezeket beteszem a hibauzenetbe. de ezen kivul ezer mas hasznos infot is, sot olyan hibastacket hasznalunk
amiben minden benne van, az is hogy miket nyomkodott es oda hogy jutott el, rengeteg debug informacioval megspekelve. minel kevesebb plusz bekerincselendo info legyen az ugyfeltol (amikre raadasul soxor rosszul emlexik) mert ez van hogy inkabb megteveszt mint segit.
a hibauzenetink minidg ket halmazbol allnak, egyik a kultur ami megmondja emberi nyelven a usernek hogy mi a gixer, ha lehet beirom hogy mivel tudja megoldani (nem a helpre meg a user manualra mutogatok), e mellett van egy hatterinfo ami szamunkra info. mikor o a hibat elkuldi akkor ezt csak ugy tudja megtenni hogy az egesz infohalmazt elkuldi, nincs kimasolok egy darabot es csak azta, ez le van tiltva. altalaban a kepernyo menteseket is letiltom. az nem hibajegy hogy atkuld egy kepernyot. sot igazabol a kepernyomentest en keszitem el a hibauzenet feldobasa elotti pillantrl igy nincs letakart mezo sem. ezt osszedobom neki egy bejelento mailba es neki csak ra kell nyomnia a kuld gombra, esetleg irhat hozza meg rizsat.
hat ja a hatekony hibakaezeles mar onmagaban egy muveszet :)