0
Ft 0 tétel

Nincsenek termékek a kosárban.

Rendszerhibák kezelése vezetőként

Avagy mit tegyél, ha a legrosszabb pillanatban romlik el a cég egyik rendszere?

Amikor rendszerekkel dolgozik az ember, mindig fel kell készülni arra, hogy valami félremegy.

Az elején ez gyakoribb, amíg sok az új fejlesztés, majd beáll egy minimális szintre. Igen ám, csak amikor már megszokja az ember a “mostanában nem szokott gond lenni” állapotot, akkor jön az apokalipszis.

Na de hogy jutunk el a megoldásig egy szinte showstopper (IT) probléma kapcsán és mit tudunk tenni, hogy csökkentsük az esetlegesen károkat?

Először is ne essünk pánikba

A pánik a legnagyobb ellenség, ugyanis mindenféle pszicho blabla nélkül is teljesen egyértelmű, hogy ha pánikolunk, leblokkolunk és nem jönnek a megoldások.

Neked is volt már olyan, hogy 1-2 órával/nappal később rájöttél, hogy könnyebb és gyorsabb megoldás is lett volna valamire? Na ugye, pont erre gondolok. Ha nem esel pánikba, nagyobb az esély arra, hogy rögtön beugrik egy jó és hatékony megoldás, amivel sok időt és kellemetlenséget megspórolsz magadnak.

Értesítsük, akit kell

Hibázni mindenki szokott, így ha egyszer-egyszer valami félremegy, szinte biztosak lehetünk benne, hogy megértik az érintett felek. Persze ha minden héten történik valami, az nem annyira oké, de évi 1-2 hiba belefér.

Ha a hiba nem (csak) a szervezeten belül okozott gondot, akkor az érintett ügyfelek/partnerek felé kommunikáljuk tisztán a helyzetet, például így:

“Kedves XY, Egy technikai hiba miatt … történt a rendszerünkben. Már dolgoznak rajta a fejlesztők, amint megoldottuk a hibát, korrigáljuk a helyzetet. Köszönjük a türelmeteket előre is és elnézést kérünk az okozott kellemetlenségért. Köszönettel,”

Eközben pedig vegyük fel a kapcsolatot azokkal a kollégákkal vagy külső partnerekkel, akik megoldással tudnak szolgálni a helyzetre. 

Persze egy nyár közepi hétvégén például ez nem a legegyszerűbb, de ha korábban kialakításra került egy olyan jelrendszer, amivel ki tudjuk fejezni, hogy nagy baj van és nem szoktunk farkast kiáltani, akkor számíthatunk rá, hogy érkezik a segítség. Ilyen lehet valamilyen egyezményes e-mail tárgymező, a közös feladatkezelő rendszerben a feladat magas prioritása vagy bármilyen egyéb jelzés, ami megkongatja a vészharangot.

Ha nem oldódik meg a probléma záros határidőn belül

Szinte mindenre van alternatív megoldás, az egyedüli hátrány az időigény lehet. Ha egy olyan rendszer hibásodik meg, amit egy korábbi működés automatizálására fejlesztettünk ki (vagyis valamit mondjuk korábban táblázatokban kezeltünk, de fejlesztettünk helyette egy saját rendszert), akkor b terv lehet az, ha ideiglenesen visszatérünk a korábbi működésre.

Ebben a konkrét példában a számlázó rendszerünk hibásodott meg egy nyári vasárnap délelőtt a hónap utolsó napján, amikor mindig intézzük a számlázást az ügyfélkör jelentős részének. 

A hibajelenség az volt, hogy minden ügyfélnek 3-szor állította ki a számlát a rendszer, mert egy hiba miatt ennyiszer küldte el a parancsot a számlázó kliensnek.

Persze ez jó kis plusz forgalom papíron, de nyilvánvalóan hibás, hiszen a munkát egyszer végeztük el, így csak egyszer szeretnénk kifizettetni.

Mik voltak az alternatív megoldásaim?

A legkézenfekvőbb egy korábban alkalmazott tömeges számlázási megoldás visszaállítása lett volna. Ez egy olyan több hónappal ezelőtt frissített táblázat újbóli felelevenítését jelentette volna, amivel félautomatán elkészültek volna a számlák. A probléma az időigény lett volna, frissíteni benne az adatokat és a számlák elkészülte után rendszerek segítsége nélkül eljuttatni őket az illetékesekhez viszonylag hosszadalmas lett volna. Konklúzió: megvalósítható, de fájdalmas.

Ha az előző megoldás valamiért nem lett volna megvalósítható, akkor egy még korábbi működéshez nyúltam volna vissza, ami a számlák másolással történő kézi kiállítása lett volna. A nehézség ebben az lett volna, hogy ezt a megoldást utoljára 30 számlánál alkalmaztuk, utána álltunk át az előző pontban említett tömeges számlázásra, majd pedig a mostani automata verzióra. Tehát ez egy nagyon régi működést idézett volna vissza, ami bár megvalósítható lett volna, majdnem biztos, hogy a nap végére nem végeztünk volna vele.

Kevésbe időigényes, ugyanakkor presztízsvesztést kockáztató megoldásként dönthettem volna a számlázás halasztása mellett. Persze azt gondolná az ember, hogy “mit számít, hogy 31-én vagy elsején számlázok”, ugyanakkor a számviteli törvények mellett az ügyfelekre is figyelni kell, vagyis ez több szempontból sem lett volna ideális. Arról már nem is beszélve, hogy a cash flow-ba is beleszól egy kitolt fizetési határidő, hiszen az 1 nappal később kiállított számlák ellenértéke várhatóan 1 nappal később is érkezne be. Nem világvége hangulat, de eltérne a megszokottól.

Mindhárom megoldás lett volna, ha a szükség úgy hozza, de szerencsére nem így lett.

Lelövöm a poént: szerencsére a fejlesztőt el tudtam érni és sikerült megoldani a problémát, mert egy apró hiba okozta. De ez most csak egy eset, számtalan helyzet és hibatípus léphet fel, a fejlesztő (csapat) pedig nem mindig érhető el és egyáltalán nem biztos, hogy napon belül orvosolható a probléma. Éppen ezért fontos, hogy a lehetőségeinkhez mérten próbáljuk elkerülni a hasonló helyzeteket. Mutatom hogyan!

Előzzük meg a problémát

Aki valaha részt vett már IT fejlesztésben az tudja, hogy a teszt a lelke mindennek. Mindig teszteljük a megoldást előbb stagingen, vagyis leegyszerűsítve fejlesztői környezetben. Ehhez amennyire lehet próbáljuk lemodellezni a valóságot, hogy a legtöbb várható hiba még itt kibukjon és javítani lehessen.

Ha itt már minden rendben van, a legújabb fejlesztés kiélesítés után kicsiben modellezzük a lehetséges scenariokat, mert így ki fognak bukni olyan hibák is, amikre korábban nem gondoltunk vagy nem jöttek elő.

Fejlesztés után óvatosan használjuk a rendszert

Ha nemrég valamilyen fejlesztés történt, úgy készüljünk a folyamatainkkal, hogy a tesztek ellenére esetlegesen felmerülő akadályokra is legyen b tervünk. Erre én mindig figyelek, ennek ellenére is felmerülhet hiba, ahogy ebben az esetben is történt.

A mi esetünkben a kárt az segített csökkenteni, hogy pár héttel korábban volt egy, a számlázót érintő fejlesztésünk, így bár már túl voltunk minden teszten, elsőre a biztonság kedvéért csak néhány ügyfélnél engedtem, hogy számlázzon a rendszer. 

Jól is tettem, hiszen így hamar ki is bukott a hiba, több verziót kipróbálva is ugyanez a jelenség lépett fel. Ha pedig megvan a hiba oka és van akkora szerencséd, hogy a fejlesztő is elérhető, akkor viszonylag könnyű dolgod van. Ha nem derül ki a hiba oka, vagy nem lehet hamar javítani, akkor vissza kell nyúlni a korábbi működéshez ideiglenesen. 

Férj hozzá a céges rendszerekhez mobilról is

Ha minden kötél szakad, cégvezetőként hajnalban egy durva ivós este után is helyt kell állni egy lakatlan szigeten egy szál félig feltöltött mobillal. Na jó, kis túlzással, de tényleg.

A legfontosabb kontaktok és rendszerek mindig legyenek könnyen elérhetőek, hogy ha baj van, értesíteni tudd azt, akit kell és minimális szinten bele tudj nyúlni a működésbe.

Persze az sem utolsó szempont, hogy lehetőleg ne a fontos időpontokban legyél elérhetetlen, de ezt már mindenkinek magának kell mérlegelnie.

A helyzet tanulsága

Nehézségek mindig adódhatnak, bármennyire is felkészültek vagyunk. Bíznunk kell a rendszereinkben, hiszen ha mindent jól kipróbáltunk, a meghibásodás esélye minimális, de olykor egy-egy elgépelt kódrészlet is komoly fennakadást okozhat. 

Éppen ezért mindig legyen “vészforgatókönyv”, amit ha sosem kell elővennünk, az sem gond, mert nem kért enni addig sem, de amikor mégis kell, abban az egy pillanatban nagyon is hasznos lesz!

Ezek is érdekelhetnek

Automatizálás felsőfokon, avagy te még nem automatizálsz?

Tele van a net tanácsokkal az automatizálás kapcsán. Írják, hogy automatizálj, alakíts ki folyamatokat, stb. Mégis valahogy senki nem magyarázza el igazán jól, hogy miről is van szó pontosan és hogy ezt nem csak nagyban lehet elkezdeni. Mire gondolok? Mutatom! Mi az az automatizálás és miért hasznos? Automatizálásnak tekinthető (szerintem legalábbis) minden olyan dolog, amit […]

Fiatal Női Vezetők
Szia, Lea vagyok! A Fiatal Női Vezetők azért jött létre, hogy 5 év cégvezetői tapasztalatát megoszthassam veled. Így előre fel tudsz majd készülni bizonyos szituációkra a saját vállalkozásodban.  Ha bármiben tudok neked segíteni, keress bátran, addig is jó böngészést kívánok!
usercart
error: Védett tartalom
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram