Esettanulmányok

Amikor a webshop és az ERP ugyanazt a készletet próbálja vezetni

A kiinduló helyzet ismerős: a webshopban vannak a termékek és rendelések, az ügyviteli rendszerben pedig újra fel kell vinni a partnereket, az árakat és a készletmozgásokat. Amíg kevés a rendelés, ezt kézzel még el lehet fedni. A növekedéssel azonban megjelennek a duplikált adatok, az eltérő készletállapotok és az olyan hibák, amelyeket már nem lehet egyszerűen visszakeresni.

A megoldási irány Shopify–Dolibarr integráció külső azonosítókkal, naplózással és újrapróbálható hibakezeléssel. A technikai kapcsolat önmagában nem oldja meg a folyamatot: előbb ki kell mondani, melyik rendszer az ár, az adózás és a készlet gazdája.

Ami nehéz: a sikertelen szinkronizációt nem szabad csendben újraküldeni. Tudni kell, mi ment át, mi maradt ki, ki dönthet az eltérésről, és hogyan előzzük meg a duplikált rendelést.

Amit ebből bizonyítani lehet: az integráció tervezésének része az adatgazda, az azonosítás, a naplózás és a hibakezelés. Konkrét ügyfélmutatót vagy megtakarítást itt nem állítunk.

Projektmunka, amely elveszik a feladatok között

A szolgáltató cégnél a projekt, a feladat, a ráfordított idő és a számlázás gyakran külön táblázatokban vagy külön gondolkodási lépésekben él. Ilyenkor a vezető látja, hogy dolgozik a csapat, de nehezebben látja, melyik projekt tart a tervhez képest, mennyi idő lett számlázható, és hol csúszik el a jövedelmezőség.

A bevezetési irány a projekt-, feladat-, időráfordítási és számlázási folyamatok összehangolása. Nem az a cél, hogy minden munkanaphoz újabb adminisztráció társuljon, hanem hogy a már szükséges adat egyszer kerüljön be, és később használható legyen.

A kritikus pont: a folyamatgazdák és a mérföldkövek tisztázása nélkül a rendszer csak részletesebb naplója lesz a bizonytalanságnak. A tervezett és tényleges ráfordítást, valamint a számlázhatóságot együtt kell visszanézni.

Amit ebből nem állítunk: nem ígérünk automatikus jövedelmezőség-javulást. Az eredmény a folyamat fegyelmétől, az adatok minőségétől és a használattól függ.

Amikor az ERP-bevezetés túl nagy lendülettel indul

A projekt nem feltétlenül azért akad el, mert rossz a szoftver. Elég egy túl nagy kezdő hatókör, rendezetlen törzsadat, későn tisztázott integráció vagy az, hogy a napi munkát végző felhasználók csak a végén találkoznak az új rendszerrel.

Ilyenkor a folytatás nem az újabb funkciók bekapcsolásával kezdődik. Először kisebb szakaszra kell bontani a célt, kijelölni a folyamatgazdákat, megtisztítani és próbaimportálni az adatokat, majd valósághű tesztesetekkel és oktatással újra felépíteni az indulást.

Miért őszinte ez a példa? Mert nem nevezzük sikernek azt, amit nem mértünk meg. Ez nem egy konkrét ügyfél története, hanem a bevezetési kockázatokból összeállított tanulságos forgatókönyv. A tanulsága mégis valós: a Dolibarr bevezetése üzleti változás, nem puszta telepítés.

Amikor a megrendelés után még mindenki mást tud

Egy műhely- vagy helyszíni munkánál a megrendelés önmagában kevés. A teljesítéshez szükséges helyszín, időpont, kapcsolattartó, megjegyzés és munkafázis gyakran külön e-mailben vagy papíron jelenik meg. Ilyenkor nem az információ hiányzik, hanem nincs egy helyen.

A munkalap-modul a megrendelés hitelesítésekor munkalapot és PDF-et hozhat létre, státusszal, megjegyzéssel, időponttal és korlátozott műhelyjogosultsággal. A cél nem a több adatbevitel, hanem hogy a teljesítéshez szükséges adat ne vesszen el útközben.

Tanulság: a jogosultságot és a felelőst már a tervezéskor meg kell határozni. Ha mindenki mindent módosíthat, a munkalap nem lesz megbízhatóbb a papírnál.

Amikor a bizonylatok három helyen várják az egyeztetést

A könyvelőirodai munkában a NAV Online Számla adatai, az RLB-ben lévő tételek, a beküldött bizonylatok és az e-mailek nem mindig ugyanabban az ütemben érkeznek. A hiányzó vagy párosítatlan dokumentumok felderítése ilyenkor sok kézi összevetést igényel.

A DoliPractice iránya read-only adatforrásokkal, hiány- és eltérésfigyeléssel, PDF-feldolgozással és jóváhagyás utáni RLB-import-előkészítéssel számol. A rendszer nem hoz önálló végleges könyvelési döntést és nem módosítja közvetlenül a külső adatforrásokat.

Tanulság: pénzügyi folyamatnál az automatizálás értéke nem az, hogy „mindent magától könyvel”, hanem az, hogy az ember hamarabb észreveszi, mit kell ellenőriznie.

Amikor a számla elküldése még nem jelenti a folyamat végét

A NAV Online Számla-kapcsolatnál nem elég egy beküldő gomb. Meg kell különböztetni a sikeres, hibás, módosított és technikailag érvénytelenített állapotokat, és vissza kell tudni keresni, mi történt egy adott számlával.

A DoliNavSzamla megoldási iránya a beküldést, módosítást, technikai érvénytelenítést, státuszkövetést és tranzakciónaplózást rendezi össze a Dolibarr-folyamattal.

Tanulság: az integráció akkor tekinthető késznek, ha a hibaállapotok és a visszaellenőrzés is megtervezett részei, nem csak az első sikeres beküldés.

Amikor ugyanahhoz a járműhöz kétféle adat tartozik

Több járműnél hamar kiderül, hogy a rendszám, alvázszám, kilométeróra-állás, státusz és fénykép külön nyilvántartásokban szerepel. A probléma nem látványos, amíg egy szervizelés, költség vagy felelős visszakeresése szükségessé nem teszi.

A FleetManager a járműadatokat és kapcsolódó információkat egy helyre rendezi, a duplikált rendszámok és alvázszámok rögzítésének megelőzésével.

Tanulság: a törzsadat minősége funkció. Egy új riport nem javítja ki a kettős vagy ellentmondó azonosítókat; ezt már a rögzítéskor kell kezelni.

Amikor minden hibajegy fontos, de egyiknek sincs gazdája

Ügyfélszolgálatnál és üzemeltetésnél a beérkező kérés gyorsan elveszhet az e-mailek között. A státusz, prioritás, felelős, határidő és vállalt válaszidő nélkül nehéz megmondani, mi várakozik és mi csúszott meg.

A Smart ticketing és SLA-kezelés a hibajegy teljes életciklusát, a felelőst és a vállalt válasz- vagy megoldási időt teszi követhetővé.

Tanulság: az SLA nem pusztán határidő-mező. Csak akkor működik, ha van felelős, prioritás, értesítés és olyan folyamat, amelyben a késés láthatóvá válik.