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!

A Rendszerhibák kezelése vezetőként bejegyzés először Fiatal női Vezetők-én jelent meg.

Mi az az automatizálás és miért hasznos?

Automatizálásnak tekinthető (szerintem legalábbis) minden olyan dolog, amit ahelyett, hogy kézzel csinálnánk, részben vagy egészben egy rendszerre (gépekre vagy szoftverre) bízunk. Miért?

Azért, mert belőlünk csak egy van. Az idő pedig véges, így a monoton, ismétlődő feladatokkal felesleges egyesével foglalkozni, ha van rájuk más megoldás.

Ehhez viszont nem árt, ha vannak jól definiált folyamatok. Vagyis tudjuk, hogy milyen lépés után mi jön, mert ezek alapján fogunk tudni sablonokat, feltétel alapú működéseket kialakítani.

Nagyban kell gondolkodni?

Nem feltétlenül, szerintem már az elejétől kezdve érdemes apró lépéseket felokosítani. Az elején lehet sablonokat, ingyenes szoftvereket használni, később pedig áttérni komolyabb rendszerekre.

Mi lehet segítség például:

1. Email sablonok: Ismétlődő kérdésekre érdemes egy olyan sablongyűjteményt kialakítani, ahonnan átmásolva minimális módosítással személyre szabva már mehet is a válasz.
2. Kanban: Ez inkább egy nézet, vizuális megjelenítés, de sokat gyorsít a munkán, ha nem kell fejben tartani, hogy mi hol tart. Ehhez hasznos programok például az Asana vagy a Trello, amikben egyeztetéseket is folytathatsz különböző feladatok kapcsán a munkatársakkal és az ügyfelekkel is.
3. Táblázatok: Na nem 100 különböző össze-vissza jegyzetelt dologra gondolok, hanem olyan összefoglaló, képletes táblázatok, amiket egymással megosztva szerkesztetek.
4. CRM: Ha a megfelelő rendszert választod ki és kicsiben megtanulod használni, amikor nagyobbra nő a cég, végtelen időt takarítasz meg vele, emelett csökkented a kollégák hibázásának lehetőségét.
5. Saját fejlesztés: Ha már pontosan tudod, hogy mire van szükséged és kitapasztaltad a meglévő rendszerek működését, beépíthetsz a többi rendszerrel kommunikáló saját, egyedi fejlesztéseket is, amik még tovább gyorsítják a munkát.

Több konkrétumra vágysz? Mutatom a példákat az egyes rendszerek használatára.

Email sablonok

A levelezőtől függőn elmentheted a sablonokat közvetlenül a rendszerbe, de egy Drive doksit is nyithatsz, amiben témakörönként gyűjtöd az egyes szituációkra vonatkozó válaszokat. Ezek lehetnek ügyfél kérdések (mikor mire számíthatnak, milyen határidők vonatkoznak rájuk, mit lehet és mit nem, stb), munkatársak számára különböző témakörök kifejtése (például szabadságolás, munkabeosztás, kifizetések ütemezése, stb), partnerek számára az együttműködés lépéseinek leírásai és így tovább. 

De lehetnek teljesen egyszerű “köszi” sablonjaid is, hogy ne kelljen mindig begépelni, hogy köszönöd, vagy hogy “nagyon szívesen”. 

Ha az emailezést jellemzően CRM-ből végzed, akkor nem is kell egy külön helyre lementeni a sablonokat, illetve a rendszer tud emailt küldeni helyetted bizonyos feltételek mentén. Erről később.

Kanban

A kezdetek kezdetén ezt kombináltam az email sablonokkal és a táblázatokkal. Ez addig működött, amíg 10-30 ügyfél volt, de ennyien is kitöltötték a teljes hónapot. Miért? Mert bár tényleg átláthatóbbá teszi a folyamatokat és a megfelelő szoftvereket használva a kollégákat és ügyfeleket is be tudod vonni a munkába, mégsem teljesen automata, inkább csak egy vizuális segédeszköz.

Táblázatok

Amíg kevés kollégánk és ügyfelünk volt, elboldogultunk a munkakiosztás terén néhány megosztott táblázattal. Egy idő után azonban ez amellett, hogy HR kihívásokat hozott (neki miért van több/kevesebb feladata, miért más a határidő, miért ő kapta azt az ügyfelet, stb), kezelhetetlenné vált az ügyfél- és munkatárs szám növekedésével. 

A táblázatok hasznosak kimutatások készítésére, de nem praktikus dolgozni bennük a legtöbb esetben. Érdemesebb inkább egyfajta felülnézeti képként tekinteni rájuk és más eszközökből ide, egy helyre kivezetni az adatokat, amiket megfelelő hozzáértéssel értékes információ bázissá alakíthatunk.

Vezethetjük táblázatban a pénzügyeket (beérkező és kimenő számlák, bérek, költségek, stb), de amit csak lehet, ne kézzel vigyünk fel egyesével, hanem exportként érkezzenek az adatok automatikusan vagy legalább tömegesen.

CRM

A 3 évvel ezelőtti CRM bevezetés volt számunkra a legnagyobb kihívás, de egyben a legjobb megváltás is. 

Egy darabig elzárkóztunk a témától, mert nem nagyon volt olyan, aki be tudta volna mutatni, hogy valójában mire is képes egy ilyen rendszer. Ennek részben az is volt az oka, hogy amikor belefogtunk, még nem igazán volt gyakori a KKV szektorban a használatuk. Ezt igazolja számtalan kimutatás, aki kíváncsi rá, érdemes utánaolvasni. Emellett az ebben a témában írt mester szakdolgozatomhoz összesen 1 kompetens konzulenst találtam az egész egyetemen. És még számára is tudtam újat mondani.

Sokan úgy tekintenek egy CRM rendszerre, mint egy telefonkönyvre. Persze nem is minden rendszer alkalmas tényleges komplex használatra. Például volt olyan szoftver, amiben extra fejlesztést igenyelt volna az, hogy emailezni tudjunk (?!?!).

Ugyanakkor egy jól kitalált szoftver ennél sokkal több. Mivel ez itt nem a reklám helye, nem írom le, hogy mi melyik rendszert használjuk. Ugyanakkor annyit elmondhatok róla, hogy a legnépszerűbb és legkomplexebb magyar eszközről van szó. 

Nézegettünk nemzetközi CRM-eket is, de soknál beleütköztünk nyelvesítési hiányosságokba, amik később a kollégák számára okoztak volna nehézséget. Találkoztunk funkcionalitási hiányokkal vagy túl komplex, ugyanakkor nem hasznos kezelő felületekkel kellett volna együtt élnünk.

Ha részleteiben is kíváncsi vagy a témára, ez a podcast jól összefoglalja az előbb leírtakat.

Saját fejlesztés

Sokan beleesnek abba a hibába, hogy jól kitalált, sokak által használt rendszerek helyett saját fejlesztésbe fognak. Miért? Mert azt gondolják, hogy az sokkal jobban igazodik majd az igényeikhez. Ez azonban könnyen tévútra vihet. Egyrészt végtelen fejlesztői munkaórát igényel, amihez fejlesztőt nehéz találni és drága is. Emellett folyamatosan karban kell tartani és lekövetni a technikai fejlődést további fejlesztői munkaórák árán.

Saját fejlesztésű rendszer azoknak való, akik funkcióigényben tényleg kinőtték a kész rendszereket vagy van már annyi tapasztalatuk a munkafolyamataikról, ami mentén “gazdaságosan” lehet célmegoldásokat fejleszteni. Ez valójában több milliárdos forgalmú cégeknél valós eshetőség. Egy KKV szereplő életében döntően nincs olyan feladat, ami egyedi fejlesztést igényelne, mert bérelhető CRM ne tudná megoldani.

Mi természetesen beleestünk az imént említett hibába. Úgy gondoltuk a kanban és táblázat időszak után, hogy majd mi feltaláljuk a spanyol viaszt. Alias egy olyan nyilvántartó rendszert, amiben levelezni is lehet és mindent is csinál helyettünk. Hamar beleütköztünk abba, hogy egy fejlesztő számára egészen másképp kell elmagyarázni az elképzeléseket, mint egy hétköznapi beszélgetés során. Emellett azt is megtanultunk, hogy az “ez itt legyen és ide kattintva ez történjen” nem egy sor kódból készül el. 

Ugyanakkor jó tanulópénz volt, mert a CRM irányába terelt minket. Illetve később megtanultunk rendesen levezényelni saját fejlesztéseket hatékonyan és közel hibamentesen. 

Dokumentálj

Ha az elején elkezded dokumentálni a folyamataidat és azt, hogy mit milyen rendszer támogat és hogyan, akkor később nem fogsz úgy járni, mint sokan (és egy időben mi is), hogy egy átalakításnál nincs hova nyúlni. 

Márpedig ha jól csinálod a “bizniszt”, előbb utóbb lesznek kollégáid, akiknek kell egy írásos segédlet. Emellett folyamatosan változik a munka felépítése és ehhez kell igazítanod a folyamataidat.

Hogyan tudsz dokumentálni? Használj egységes elnevezéseket, rövid leírásokat, amik mentén könnyen megtalálod, hogy az adott funkció hol jelenik meg és mire jó. Ezután megnevezheted, hogy kiket érint az adott működés, esetleg van-e hozzá kapcsolódó másik elem, amit szintén érint egy esetleges változás. Minél jobban követhető a dokumentációd, annál könnyebben megtalálod majd benne azt, amire éppen szükséged van.Kérdésed van a témában? Keress bátran a kapcsolat oldal segítségével, Instagramon vagy Facebookon. Másokat is megkérdeznél? Lépj be a csoportba és tedd fel a kérdéseidet!

A Automatizálás felsőfokon, avagy te még nem automatizálsz? bejegyzés először Fiatal női Vezetők-én jelent meg.