Amikor egy ügyfél többször is rákérdez, hol tart az ügye, a vezető joggal szeretne változást. Ha a válaszhoz külön táblázatokat kell megnyitni és több kollégát végigkérdezni, hamar felmerül: kellene egy jobb rendszer.
Lehet, hogy valóban kell. De mielőtt ajánlatot kérünk rá, érdemes megérteni, miért nehéz válaszolni az ügyfélnek. Hiányzik egy fontos rendszerfunkció? Vagy nincs egyértelműen meghatározva, ki viszi tovább az ügyet, és mikor?
A különbségnek pénzügyi következménye is van. Ha a fennakadás okát nem kezeljük, az új program költsége mellett a régi probléma is velünk maradhat. Ha viszont egy szükséges fejlesztést halogatunk, továbbra is fizetjük a kézi munka és az ismételt javítások árát.
Ugyanaz a panasz többféle okot takarhat
Nézzünk egy rövid, szemléltető helyzetet. Egy megrendelést napokig nem igazolnak vissza. Az értékesítő a rendszert hibáztatja, mert abból nem derül ki, mire vár az ügy.
Az egyik lehetséges ok, hogy az árengedmény jóváhagyója szabadságon van, és senki nem tudja, ki helyettesítheti. Ilyenkor először a döntési jogosultságot és a helyettesítést kell rendezni. Ha ezt a meglévő rendszer megfelelően támogatja, egy új program beszerzése az adott fennakadás miatt nem feltétlenül indokolt.
Más a helyzet, ha minden jóváhagyás megvan, de a rendelési tételeket kézzel kell átírni egy másik programba. Itt már meg kell vizsgálni az adatátadás technikai lehetőségeit is: egy világosabb munkaköri leírás nem továbbítja át az adatokat.
Néha egy egyszerűbb változtatás is elég a probléma megoldásához. Érdemes ezt megvizsgálni, mielőtt IT-fejlesztésbe kezdünk.
A fenti helyzetek kitalált, szemléltető példák. A következő két dokumentált esetben viszont megvizsgálták a működést, és különböző változtatásokkal értek el eredményt.
EDR: amikor a munkafolyamat rendezése elégnek bizonyult
Az EDR szoftverszolgáltatónál túl sok idő telt el az ügyfél kérésétől a teljesítésig. Az ASQ szakmai folyóiratának esettanulmány-összefoglalója szerint a munkalépések közötti késedelmek jelentették az átfutási idő ingadozásának fő forrását.
Átnézték, ki miért felel, és módosították a munkafolyamatokat, hogy kezelni tudják az egymással versengő prioritásokat. A változások elfogadtatásával is foglalkoztak. Az összefoglaló 93%-os javulást közöl az átfutási időben, és kifejezetten leírja: elkerültek szükségtelen technológiai megoldásokat. ASQ [1]
Ebben az esetben tehát dokumentált, hogy a szervezeti problémák kezelésével technológiai beavatkozást tudtak elkerülni. A tanulság számunkra az, hogy az új szoftver lehetőségét a késedelem okának ismeretében érdemes mérlegelni.
Wisconsin: amikor a folyamatjavításon túl fejlesztésre is szükség volt
A wisconsini természeti erőforrásokért felelős hatóságnál, a DNR-nél az irodák eltérően kezelték az engedélykérelmeket. Feltérképezték a munkát, egységesítették a lépéseket és tisztázták a szerepeket. Az EPA és az ECOS 2015-ös kiadványa a folyamatjavításhoz kapcsolja az általános engedélyek elbírálásának 30 napról 15 napra, az egyedi engedélyekének 105 napról 52 napra rövidülését.
A célok között azonban online benyújtás, ügyféloldali státuszkövetés és elektronikus fizetés is szerepelt. Ezekhez SharePoint-alapú rendszert alakítottak ki, az egyedi funkciókhoz fejlesztőt is bevontak. EPA–ECOS [2]
A gyorsabb ügyintézés és az online ügyintézés két külön eredmény. Az előbbin a munkafolyamat átalakítása segített, az utóbbihoz informatikai képességeket kellett létrehozni. Ez hatósági eset, de jól megmutatja, miért érdemes külön meghatározni, melyik igénytől milyen eredményt várunk.
Mitől lesz indokolt az egyik vagy a másik megoldás?
A saját vállalatunknál azt kell megvizsgálni, mi akadályozza a kívánt működést. Az alábbi szempontok a két esetből és az üzleti elemzés szemléletéből kiinduló gyakorlati értelmezések.
- Elég lehet a folyamat rendezése, ha a szükséges funkciók rendelkezésre állnak, de a feladatok gazdája, a döntési rend vagy az átadás feltételei nem világosak. Ezt az támasztja alá, ha a tisztázott működés a meglévő eszközökkel is teljesíti az előre meghatározott elvárásokat.
- Informatikai változtatás is indokolt lehet, ha egy szükséges képesség hiányzik, vagy a jelenlegi megoldás az elvárt mennyiséget, pontosságot, biztonságot nem tudja megfelelően kezelni. Ilyenkor azt is ellenőrizni kell, hogy beállítás, meglévő funkció vagy a rendszerek összekapcsolása megoldja-e a feladatot.
- Mindkettőre szükség lehet, ha előbb meg kell határozni a működés szabályait, és ezeket utána a rendszernek is támogatnia kell. Például a vállalat dönti el, ki milyen árengedményt engedélyezhet, a szoftver ezt követően irányíthatja a kérelmeket a megfelelő személyhez.
Az IT-fejlesztés szükségessége még nem jelenti a teljes rendszer cseréjét. Egy célzott módosítás is megfelelő lehet. Ezt a jelenlegi rendszer képességei, a kapcsolódó költségek és a vállalat elvárásai alapján lehet eldönteni.
Hogyan derítsük ki, mi történik nálunk?
Kezdjük néhány tényleges ügy útjával, és azokkal a munkatársakkal, akik dolgoztak rajtuk. A szabályosan lezajló esetek mellé válasszunk késő, javított és kivételes ügyeket is. Ez segít megtalálni a lehetséges okokat. Annak megállapításához, hogy melyik milyen gyakran fordul elő, már megfelelő mennyiségű és az adott működést jól tükröző adat szükséges.
Nézzük meg, mikor érkezett be a kérés, mikor lett meg minden szükséges információ, mikor dolgozott rajta valaki, és mikor várakozott. Egy ügy lehet napok óta nyitva úgy is, hogy ténylegesen csak rövid ideig foglalkoztak vele. Ebből még nem következik, hogy a rendszer lassú vagy a kolléga nem dolgozik megfelelően: a várakozás okát kell feltárni.
A külön Excel-listákat és az e-maileket is érdemes megérteni. Lehet, hogy egy hiányzó funkciót pótolnak. Az is lehet, hogy a program tudja a szükséges feladatot, csak nincs hozzá megfelelő hozzáférés, beállítás vagy felhasználói ismeret. Ugyanaz a kerülőmegoldás más-más teendőt indokolhat.
Ha a feltárt ok egy körülhatárolt területen biztonságosan kezelhető, egyeztetett próba segíthet. Előre határozzuk meg, mit várunk a változtatástól. Hasonló ügyeket, azonos kezdő- és végpont között mérjünk, és az átfutási idő mellett a hibákra is figyeljünk. A forgalom vagy az ügyek összetételének változása is befolyásolhatja az eredményt.
A szükséges pénzügyi, biztonsági és egyéb ellenőrzéseket a gyorsítás során is meg kell őrizni. Egy jóváhagyás indokoltságát például külön kell megvizsgálni, attól még lehet fontos, hogy időt vesz igénybe.
Mikor lesz a panaszból használható fejlesztési igény?
A „legyen gyorsabb az ügyintézés” fontos cél, de önmagában kevés egy megfelelő megoldás kiválasztásához. Ha adatátadásra van szükség, a következő kérdések már segítik a fejlesztőt és a megrendelőt is:
- Melyik rendszerből, milyen adatot és milyen esemény után kell továbbítani?
- Milyen gyorsan és mekkora mennyiségben kell működnie az átadásnak?
- Mi történjen hiányos adat vagy sikertelen továbbítás esetén, és ki kapjon róla értesítést?
- Hogyan ellenőrizzük majd, hogy az elvárt működés megvalósult?
Így már összehasonlítható megoldásokról lehet beszélni. Az informatikai szakemberek és a szállító fel tudják mérni a lehetőségeket, az üzleti oldal pedig meg tudja ítélni, hogy azok valóban kezelik-e a feltárt problémát.
A döntésben a teljes ráfordítás számít
A folyamat átalakítása sem ingyenes: egyeztetést, betanulást és vezetői figyelmet igényelhet. Egy új rendszer költségében pedig a licencen és a fejlesztésen túl az adatátvitel, a tesztelés, az oktatás, az üzemeltetés és a saját munkatársak ideje is szerepet kap.
Az előnyöknél ugyanez a pontosság szükséges. A felszabaduló munkaidő jelenthet kevesebb túlórát, több kiszolgálható ügyfelet vagy gyorsabb választ. Közvetlen pénzügyi megtakarítássá akkor válik, ha ennek feltételei is teljesülnek. A döntési anyagban ezért külön érdemes jelölni a mért tényeket, a becsléseket és a még ellenőrizendő feltételezéseket.
Egy megoldás akkor lehet jó választás, ha a várható előnyei a költségeivel, kockázataival és az átállás terhével együtt is indokolják. A szükséges biztonsági és megfelelési feltételeket eközben minden vizsgált lehetőségnek teljesítenie kell.
Miben segít az IT üzleti elemző?
Az IT üzleti elemző segít összekapcsolni a vezető üzleti célját, a munkatársak napi tapasztalatát és az informatikai lehetőségeket. Feltárja a problémát, megvizsgálja a megoldási lehetőségeket, és kidolgozza a szükséges változtatások elvárásait. Az alternatívák mérlegelése és a kockázatok vizsgálata az IIBA elemzési szemléletének is része. IIBA [3]
A munkája eredményeként a vezetés azt láthatja, melyik problémára milyen változtatást javasolnak, ezt mi támasztja alá, és miből derül majd ki, hogy bevált-e. Ehhez ugyanúgy hozzátartozhat egy folyamat rendezésének javaslata, mint egy szükséges fejlesztés megalapozása.
Ha nálatok is felmerült egy új rendszer vagy fejlesztés igénye, írd le, hol akad el a munka, és milyen eredményt szeretnétek elérni. A KOSLR folyamatelemzéssel és modellezéssel, valamint IT üzleti elemzéssel támogatja a helyzet feltárását és a változtatások előkészítését.
Ha a rendszerleváltásról már megszületett a döntés, a bevezetés előkészítéséről szóló cikkünkben az adatok, a rendszerkapcsolatok és az üzleti átvétel kérdéseit is végigvesszük.
Források és az esetek értelmezése
- Keith Trimarki: The Impact of Human Factors on Lead Time. Journal for Quality and Participation, 2016. július, 39. évfolyam, 2. szám, 4–12. oldal. Az EDR-esetnél a nyilvános kiadói összefoglalóra támaszkodunk, ez a 93%-os mutató részletes számítását és az elkerült technológiai megoldást nem ismerteti.
- EPA–ECOS: Lean and Information Technology Toolkit, 2015. december. Wisconsin DNR-esettanulmány: C függelék, a kiadvány számozása szerinti 56–59. oldal, a PDF 60–63. oldala.
- IIBA: Strategy Analysis – Task Cards, v2.0, 2025. Kapcsolódó feladatok: Analyze Current State, Define Future State, Assess Risks, Define Change Strategy.
A két esettanulmány más szervezetek korábbi tapasztalatát mutatja be. A gyakorlati döntési szempontok és a szemléltető rendelési helyzet a KOSLR magyarázatai. Az eredmények más vállalatoknál nem tekinthetők előrejelzésnek vagy megtakarítási ígéretnek. Forrásellenőrzés: 2026. október 29.