Minden rendelés egyetlen idővonalon, a beérkezéstől a kifizetett számláig.
Az order to cash, a procure to pay és a szervizigénytől a számláig tartó folyamat az ERP, a CRM, a webáruház, a raktár, a szállítás és a pénzügy rendszerein fut át. Ezeket dokumentált API-kkal és eseményekkel kötjük össze, minden rendelésnek egyetlen állapotot adunk a rendszereken át, és minden kivételt egy MI-ügynökhöz küldünk, amely megoldási javaslatot készít egy ember jóváhagyására.
Szervezeteknek, amelyek Magyarországon és más uniós tagállamokban értékesítenek, vásárolnak és számláznak, országonként saját rendszerekkel, fuvarozókkal és számlázási szabályokkal.
07A folyamat áttekintése és az okok javításaSzemély
Egy vevői rendelést, beszerzési rendelést vagy szervizigényt egyszer rögzítünk az elsődleges rendszerében, és dokumentált API-kon és eseményeken keresztül juttatjuk el a többi rendszerbe. Az állapotesemények rendelésenként egyetlen idővonalat építenek. Ha egy lépés meghiúsul vagy kilóg a tűréshatárból, egy MI-ügynök összegyűjti az előzményeket, és megoldást javasol, amelyet egy ember hagy jóvá, mielőtt az elsődleges rendszerben végrehajtódik. A számlák strukturált formában mennek ki, a NAV felé az Online Számla adatszolgáltatással, a folyamatgazdák pedig áttekintik a folyamatot és az interfészek állapotát.
Előtte és utána
Mi változik a napi működésben
Ma
A rendszerrel
Ma
Ma: Minden átadásnál újra begépelve
A webáruházban vagy az értékesítőknél felvett rendelést újra begépelik az ERP-be, a szállítási és számlázási adatokat pedig kézzel másolják át a raktár-, szállítás- és pénzügyi rendszerekbe.
A rendszerrel
A rendszerrel: Egyszer rögzítve, mindenhol használva
Minden rendelés, szállítás és számla abban a rendszerben jön létre, amelyhez tartozik, és eseményként jelenik meg. A többi rendszer feliratkozik rá, ahelyett hogy újra begépelnék.
Ma
Ma: Tegnapi állapot
Az éjszakai kötegelt interfészek miatt az ügyfélszolgálat, a tervezés és a pénzügy ugyanannak a rendelésnek más-más, elavult állapotát látja. Ha egy vevő megkérdezi, hol tart a szállítmánya, visszahívást kap.
A rendszerrel
A rendszerrel: Egyetlen aktuális állapot
Minden rendelésnek vagy igénynek egyetlen idővonala van, amely az összes érintett rendszer eseményeiből épül. Az ügyfélszolgálat, a tervezés és a pénzügy ugyanazokat a tényeket látja, és ugyanígy egy állapotkérdésekre válaszoló ügyfélszolgálati asszisztens is.
Ma
Ma: Postafiókokban kezelt kivételek
A készlethiányt, az árbeli eltérést, a meghiúsult kiszállítást és a hibás számlaadatokat e-mailben és táblázatokban oldják meg, és utólag senki sem tudja megmondani, ki mit döntött.
A rendszerrel
A rendszerrel: A kivétel javaslattal érkezik
Egy MI-ügynök összegyűjti minden kivétel mögötti adatot, és megoldást javasol. Egy munkatárs egyetlen kivételkezelő felületen jóváhagyja, módosítja vagy elutasítja, a döntést pedig rögzítjük.
Ma
Ma: Egymásnak ellentmondó törzsadatok
Ugyanaz a vevő, szállító, termék vagy ár több rendszerben, eltérő értékekkel létezik, és senki sem felel azért, melyik a helyes.
A rendszerrel
A rendszerrel: Adatobjektumonként egy gazda
A vevőknek, szállítóknak, termékeknek és áraknak egyeztetett elsődleges rendszere és megnevezett gazdája van. A másolatokat és ütközéseket ennek a gazdának jelentjük, nem javítjuk csendben a későbbi rendszerekben.
Ma
Ma: Minden változás újabb interfész
Egy új értékesítési csatorna, piactér vagy jogi személy újabb pont-pont kapcsolatot jelent. A NAV-adatszolgáltatás és a külföldi leányvállalatok e-számlázási szabályai minden folyamatra újabb formátumot és csatornát tesznek.
A rendszerrel
A rendszerrel: Az új kapcsolatok ugyanazokat a szerződéseket használják
Egy új csatorna, jogi személy vagy e-számlázási hálózat egyszer kapcsolódik a dokumentált API-khoz és eseményekhez, nem minden rendszerhez külön.
Munkafolyamat
Hogyan fut a munkafolyamat
Ha az adatok rendben vannak, a fő ágon nincs szükség kézi munkára. Ha egy rendelés, szállítás vagy számla eltér, a kivételkezelési kör a bizonyítékokkal és egy javaslattal egy emberhez viszi, a jóváhagyott javítás pedig ugyanazon az integrációs rétegen folyik vissza.
A fő ág egy üzleti esemény elsődleges rendszerben való egyszeri rögzítésétől a többi rendszerbe API-kon és eseményeken keresztül történő továbbításon és a rendelésenkénti idővonal felépítésén át a számlázásig, a párosításig és a kiegyenlítésig tart. Azzal zárul, hogy a folyamatgazdák áttekintik a folyamatot, és kijavítják a kivételek okait.
Ha egy lépés meghiúsul, késik vagy kilóg a tűréshatárból, a kivétel az idővonal lépése után kilép a fő ágból. Egy MI-ügynök összegyűjti az előzményeket, és megoldást javasol, amelyet egy ember jóváhagy, módosít vagy elutasít. A jóváhagyott lépés az elsődleges rendszerben hajtódik végre, és új eseményként tér vissza a továbbítás lépéséhez.
A jóváhagyási lépés az emberi ellenőrzőpont: ember nélkül nincs pénzügyi könyvelés, ár- vagy hitelkeret-módosítás, és nincs ígéret a vevő felé.
01
1. lépés: Az esemény egyszeri rögzítéseRendszer
A webáruházból, piactérről, EDI-n vagy az értékesítőktől érkező vevői rendelés, a beszerzési rendelés vagy a szervizigény abban a rendszerben jön létre, amelyhez tartozik. Ez a rendszer üzleti eseményt tesz közzé CloudEvents-borítékban, AsyncAPI-szerződésben leírva. A papíron és PDF-ben érkező rendelések és szállítói számlák először az intelligens dokumentumfeldolgozáson mennek át.
02
2. lépés: Továbbítás API-kon és eseményekenRendszer
Az integrációs réteg a dokumentált API-jaikon (OpenAPI) keresztül juttatja el az eseményt a raktár-, szállítás-, pénzügyi és CRM-rendszerekhez. A fogadók idempotensek, így egy ismételt üzenet soha nem hoz létre második szállítmányt vagy számlát, a nem kézbesíthető üzenetek pedig egy hibasorban várnak az újrajátszásra.
03
3. lépés: Rendelésenként egy idővonalRendszer
Az összes rendszer állapoteseményeit (visszaigazolva, kiszedve, feladva, kiszállítva, számlázva, kifizetve) az üzleti hivatkozási szám alapján egyetlen idővonalba kapcsoljuk. Mérföldkő- és tűréshatár-szabályok jeleznek kivételt, ha egy lépés meghiúsul, késik vagy nem egyezik: készlethiány, az egyeztetett tűréshatáron kívüli ár, meghiúsult kiszállítás, a NAV-hoz továbbítandó hibás számlaadat vagy visszautasított e-számla.
04
4. lépés: Előzmények és javaslatMI-ügynök
Minden kivételnél egy MI-ügynök kiolvassa az érintett rendszerekből, amire szüksége van: a rendelést, a készletszintet, az ármegállapodást, a fuvarozó állapotjelentését és a vevő feltételeit. Indoklással és a felhasznált adatokkal együtt megoldást javasol, például helyettesítő terméket, javított árat, új szállítási időpontot vagy helyesbítő számlát.
Kivételág: Meghiúsult lépés vagy tűréshatáron kívüli eltérés
05
5. lépés: Jóváhagyás küszöbértékeken belülSzemély
Az ügyfélszolgálat, a logisztika vagy a pénzügy egy munkatársa a kivételkezelő felületen látja a kivételt, a bizonyítékokat és a javaslatot, és jóváhagyja, módosítja vagy elutasítja. A jóváhagyott lépést az elsődleges rendszer API-ján keresztül hajtjuk végre, amely a változást új eseményként teszi közzé.
Kivételág: Meghiúsult lépés vagy tűréshatáron kívüli eltérés· Visszatérés ide: 2. lépés
Emberi ellenőrzőpont
Az MI-ügynökök jóváhagyás nélkül soha nem könyvelnek pénzügyi tételt, nem módosítanak árat vagy hitelkeretet, és nem tesznek ígéretet a vevőnek. Lépéstípusonkénti küszöbértékek döntik el, ki hagy jóvá, és minden javaslatot és döntést naplózunk.
06
6. lépés: Számlázás, párosítás és kiegyenlítésRendszer
A kimenő számlák az ERP-ből indulnak: minden belföldi számla adatai valós időben a NAV-hoz kerülnek az Online Számla rendszeren keresztül, az ajánlatkérők EN 16931 szerinti e-számlát kapnak, az uniós partnerek pedig, ahol ezt előírják, Peppol BIS Billing 3.0 formátumot hozzáférési ponton keresztül. A beérkező szállítói számlákat a beszerzési rendelésekkel és az áruátvételekkel párosítjuk, az idővonalat pedig a banktól vagy a fizetési szolgáltatótól érkező fizetési állapot zárja le.
07
7. lépés: A folyamat áttekintése és az okok javításaSzemély
A folyamatgazdák és az integrációs csapat rendszeres ütemben áttekintik a kivételeket ok szerint, az interfészhibákat és a törzsadat-ütközéseket. Az okot ott javítják, ahol keletkezik, egy törzsadatrekordban, egy tűréshatár-szabályban vagy egy leképezésben, ahelyett hogy újra és újra ugyanazt a kivételt oldanák meg.
Összetevők
Mit építenénk meg
01
Eseményvezérelt integrációs réteg
Szerződésalapú API-k és események az ERP, a CRM, a webáruház, a raktár, a szállítás és a pénzügy között, OpenAPI- és AsyncAPI-leírással és CloudEvents-borítékkal, a meglévő integrációs platformján vagy felhőnatív módon építve.
Adatobjektumonként egyeztetett elsődleges rendszer és gazda, párosítási szabályok a vevőkre, szállítókra és termékekre, valamint jelentések a másolatokról és ütközésekről az illetékes gazdáknak.
Szolgáltatás, amely az eseményeket rendelésenként vagy igényenként egyetlen idővonalba kapcsolja, alkalmazza a mérföldkő- és tűréshatár-szabályokat, és megmutatja a folyamatot és a kivételeket a folyamatgazdáknak.
A kivételek sora az összegyűjtött előzményekkel és az MI-ügynök javaslatával, jóváhagyás, módosítás és elutasítás lehetőségével, a lépéstípusonkénti jóváhagyási küszöbértékeket ott érvényesítve, ahol a lépés végrehajtódik.
Online Számla adatszolgáltatás hibakezeléssel és újraküldéssel, EN 16931 szerinti e-számlák az ajánlatkérőknek, Peppol BIS Billing 3.0 UBL-ben az uniós partnereknek, küldés előtti validálással; a visszautasított számlák a kivételkezelő felületre kerülnek.
Interfészenkénti állapotfigyelés és riasztás, üzemeltetési kézikönyvek és a hibás üzenetek ellenőrzött újrajátszása, infrastruktúra kódként telepítve a saját felhőbérletében.
Beszerzési rendelések és szállítói visszaigazolások
Szervizigények és helyszíni munkalapok
Fuvarozói nyomkövetési és kiszállítási események
NAV Online Számla válaszüzenetek, e-számlák és állapotválaszok
Bankszámlakivonatok és fizetési értesítések
A megoldás magja
Összekapcsolt folyamatok
Kapcsolódó rendszerek
SAP S/4HANA értékesítés, beszerzés és pénzügyPlatformSAP
Salesforce Sales, Service és Commerce CloudPlatformSalesforce
Odoo értékesítés, készlet, beszerzés és könyvelésPlatformOdoo
Webáruház-platformok, piacterek és fuvarozói API-k
Raktár- és szállításirányítási rendszerek
NAV Online Számla, Peppol-hozzáférési pont, bankok és fizetési szolgáltatók
Termékinformáció-kezelés és az adatplatform
Kontrollok
Beépített kontrollok
Hozzáférési határok
Minden integráció és az MI-ügynök is rendszerenként saját szolgáltatásidentitással fut, csak a szükséges API-műveletekre korlátozva. Az MI-ügynök az előzmények összegyűjtéséhez több rendszerből is olvashat, írni azonban csak néhány jóváhagyott lépésen keresztül tud, amelyeket az elsődleges rendszer API-ja hajt végre, soha nem közvetlen adatbázis-hozzáféréssel.
Emberi felülvizsgálat
A jóváhagyási küszöbértékeket lépéstípusonként a folyamatgazdával határozzuk meg: mit javasolhat csak az MI-ügynök, mit hagy jóvá egy csapattag, és mihez kell második jóváhagyó. A pénzügyi könyvelések, az ár- és hitelkeret-módosítások és a vevőnek tett ígéretek mindig emberre várnak. Kis hatású, visszafordítható lépések, például egy hibás üzenet újraküldése, a gazda egyetértésével jóváhagyás nélkül is futhatnak.
Visszakereshetőség
Minden eseményt, javaslatot, jóváhagyást, elutasítást és végrehajtott lépést a rendelés vagy igény hivatkozási számához naplózunk, az MI-ügynök által felhasznált adatokkal, a modell és a prompt verziójával és a jóváhagyóval együtt. Egy vitatott számla vagy egy vevői panasz így lépésről lépésre visszakövethető.
Adatvédelem
A vevők és szállítók kapcsolattartási adatai csak azokba a rendszerekbe jutnak, amelyeknek szükségük van rájuk. Az idővonal üzleti hivatkozási számokat és állapotokat tárol, nem teljes rekordokat, a naplók pedig az Ön által meghatározott megőrzési időt követik. Az adatkezelés az egyeztetett régióban marad.
MI-átláthatóság
Az MI-ügynök javaslatait a kivételkezelő felületen ekként jelöljük, mellettük a bizonyítékokkal és az indoklással. Az elsődleges rendszerek maradnak a hiteles források: az idővonal azt mutatja, amit ezek jelentenek, és soha nem írja felül őket.
Mérőszámok
Mit mérnénk
Ezeket a mutatókat a felmérés során egyeztetjük Önnel, a kiinduló értékeket pedig a jelenlegi rendszer- és interfésznaplóiból vesszük, mielőtt bármi változna.
Mit mérnénk
Mutató
Miért fontos
Hogyan mérnénk
01Rendelési átfutási idő
Miért fontosEzt veszik észre először a vevők, és ez mutatja meg, hol várakoznak a rendelések.
Hogyan mérnénkA rendelés beérkezésétől a kiszállításig és a kifizetésig eltelt idő csatornánként és jogi személyenként, az idővonal eseményeiből.
02Kézi beavatkozás nélküli rendelések
Miért fontosMegmutatja, a folyamat mekkora része fut rendezett adatokon és egyeztetett szabályokon.
Hogyan mérnénkAzoknak a rendeléseknek és igényeknek az aránya, amelyek kézi lépés vagy kivétel nélkül jutnak el a kiegyenlítésig, az idővonalból.
03Kivételek ok szerint és a megoldás ideje
Miért fontosMegmutatja, mely okokat érdemes először javítani, és lépést tart-e a kivételkezelő felület.
Hogyan mérnénkKivételek száma okkódonként, és az észleléstől a végrehajtott megoldásig eltelt idő a kivételkezelő felület naplóiból.
04Visszautasított számlák aránya
Miért fontosA visszautasított számlák és adatszolgáltatások késleltetik a fizetést, és többnyire törzsadat- vagy leképezési hibára utalnak.
Hogyan mérnénkA kiküldött és fogadott e-számlák, valamint a NAV felé küldött számlaadatok közül a visszautasítottak aránya ok szerint, a hozzáférési pont és a NAV válaszaiból.
05Interfészhibák és helyreállítási idő
Miért fontosMegmutatja, megbízható-e az integrációs réteg, és gyorsan észreveszik és javítják-e a hibákat.
Hogyan mérnénkHibás üzenetek interfészenként, és a hibától a sikeres újrajátszásig eltelt idő az integrációs monitorozásból.
06Törzsadat-másolatok és ütközések
Miért fontosA legtöbb kivétel olyan adatra vezethető vissza, amely rendszerenként eltér.
Hogyan mérnénkNyitott másolatok és ütköző értékek adatobjektumonként és rendszerenként, a párosítási jelentésekből.
Kiinduló mérés nélkül nem tűzünk ki célértéket.
Bevezetés
Hogyan vezetnénk be
01. szakasz
Felmérés és folyamattérkép
Egy folyamat, például egy értékesítési csatorna order to cash folyamata, és egy kivételtípus. Feltérképezzük a rendszereket, az interfészeket, az adatgazdákat és a kivételek mai kezelését.
Lezárási feltételek
Folyamat, rendszerek és adatgazdák feltérképezve
Az első kivételtípus és a jóváhagyási küszöbértékek egyeztetve
Kiinduló értékek a jelenlegi naplókból
02. szakasz
Integráció és idővonal
Dokumentált API-k és események az érintett rendszerekhez, és a meglévő interfészek mellett, azokat nem módosítva futó idővonal.
Lezárási feltételek
Eseményszerződések közzétéve és verziózva
Az idővonal mintavételezett rendeléseken egyezik az elsődleges rendszerekkel
Újrajátszás és üzemeltetési kézikönyvek kipróbálva
03. szakasz
Próbaüzem a kivételkezelő felülettel
Az MI-ügynök a kiválasztott kivételtípusra javasol megoldást, és minden javaslatot ember hagy jóvá. Összevetjük a javaslatokat azzal, amit a munkatársak tettek volna.
Lezárási feltételek
A javaslatok minősége eléri az egyeztetett feltételeket
Küszöbértékek és jóváhagyók lépéstípusonként beállítva
A naplózást a pénzügy és a belső kontroll átnézte
04. szakasz
Kiterjesztés és kivezetés
Újabb kivételtípusok, csatornák, jogi személyek és folyamatok, például a procure to pay, mindegyik ugyanazokon a szerződéseken. A régi pont-pont interfészeket egyenként kapcsoljuk le.
Lezárási feltételek
Minden új folyamat ugyanazokon a szerződéseken és monitorozáson
Egyedi gyártású és alkatrészrendelések az ERP-től a raktárig és a fuvarozókig, a szállítói visszaigazolásokat és számlákat a beszerzési rendelésekkel párosítva.
Bekötési és szerelési igények követése a munkalaptól a helyszíni kiszálláson át a számláig, valamint keretszerződés alapján beszerzett anyagok víziközmű- és távhőszolgáltatóknál.
Karbantartási munkalapok, alvállalkozói megrendelések és számláik követése az igénytől a kifizetésig, útfenntartó vállalkozásoknál és városi közlekedési társaságoknál.
Procure to pay közszférabeli szervezeteknél, EN 16931 szerinti e-számlák befogadásával, a megrendelésekkel és az átvételekkel párosítva a kifizetés előtt.
Szemléltető példa
Élelmiszer-nagykereskedő order to cash folyamata
Helyzet
Egy élelmiszer-nagykereskedő webáruházon, üzletkötőkön és kiskereskedelmi láncoknak EDI-n keresztül értékesít, két raktárból. A rendeléseket újra begépelik az ERP-be, a fuvarozók e-mailben jelzik a kiszállítási problémákat, a hibás számlaadatokat a könyvelés kézzel javítja, mielőtt a NAV-hoz kerülnek, és a közintézményi vevők EN 16931 szerinti e-számlát kérnek.
Rendszer
A rendelések, a készlet, a szállítmányok és a számlák eseményként áramlanak a webáruház, az ERP, a raktárrendszer és a fuvarozók között, és minden rendelésnek egyetlen idővonala van. A számlaadatok valós időben mennek a NAV-hoz, a közintézmények EN 16931 szerinti e-számlát kapnak, a visszautasított adatszolgáltatások pedig a kivételkezelő felületre kerülnek.
Emberi kontroll
A készlethiány és a meghiúsult kiszállítás egyetlen kivételkezelő felületre kerül, ahol egy MI-ügynök helyettesítő terméket vagy új szállítási időpontot javasol. Minden javaslatot az ügyfélszolgálat hagy jóvá; az ármódosításokhoz és a helyesbítő számlákhoz pénzügyi jóváhagyás kell.
Amit mérnénk
A kézi beavatkozás nélküli rendelések aránya csatornánként, a kivételek ok szerint és a megoldás ideje, valamint a visszautasított számlák és adatszolgáltatások aránya.
Magyarország
Egy folyamat, több ország és számlázási szabály
Magyarországon minden belföldi számla adatai valós időben a NAV-hoz kerülnek az Online Számla rendszeren keresztül, az ajánlatkérők pedig 2019 óta kötelesek az EN 16931 szerinti e-számlát befogadni és feldolgozni; a kötelező strukturált e-számlázásról egyelőre koncepció készült, jogszabály még nem. A külföldi csoportok magyar leányvállalatai és a régió más országaiban is cégeket működtető magyar vállalatok gyakran ugyanazokat a folyamatokat futtatják eltérő ERP-példányokon, fuvarozókkal és bankokkal, miközben a csoport ERP-je más országok e-számlázási szabályait is követi. Olyan integrációs réteget tervezünk, amelyben az országonkénti formátum és csatorna ugyanazok mögött az események mögött áll, így egy új előírás új csatlakozót jelent, nem új folyamatot.
A 2025. szeptember 12. óta alkalmazandó adatrendelet szabályozza az adatkezelési szolgáltatások közötti váltást, ezért az eseményszerződéseket és az adatexportokat hordozhatóan tartjuk. A kivételkezelő felület MI-ügynökeit az MI-rendelet szem előtt tartásával tervezzük. Az integrációk naplózott hozzáféréssel és dokumentált összetevőkkel készülnek azoknak a vevőknek, amelyeknek a kiberbiztonsági törvény szerint igazolniuk kell az ellátási lánc biztonságát.
Nem. Az ERP, a CRM, a webáruház és a raktárrendszer mindegyike végzi a saját feladatát. Ezek köré integrálunk, egyeztetjük, melyik rendszer melyik adat gazdája, és a folyamatnak egyetlen idővonalat adunk rajtuk keresztül. Ahol egy régi rendelés- vagy ERP-rendszer akadályozza a változást, az örökölt rendszerek modernizálása először API-k mögé helyezi.
02Lecserélik az integrációs köztes szoftverünket?
Nem, ha jól végzi a dolgát. A már működő integrációs platformjára vagy üzenetközvetítőjére építünk, és ahol hiányzik, szerződéseket, monitorozást és újrajátszást adunk hozzá. Ahol nincs ilyen, felhőnatív megoldást építünk. Bővebben: integrációs munkáink.
03Önállóan is cselekedhetnek az MI-ügynökök?
Csak a lépéstípusonként egyeztetett küszöbértékeken belül, és csak kis hatású, visszafordítható lépéseknél, például egy hibás üzenet újraküldésénél. A pénzügyi könyvelésekhez, az árakhoz, a hitelkeretekhez és a vevőnek tett ígéretekhez mindig ember kell. Olvassa el, hol van szükség emberi jóváhagyásra az MI-ügynököknél.
04Hogyan illeszkedik ebbe az Online Számla és az e-számlázás?
Magyarországon 2021 óta minden belföldi számla adatait valós időben kell jelenteni a NAV-nak az Online Számla rendszeren keresztül, az ajánlatkérők pedig kötelesek az EN 16931 szerinti e-számlát befogadni. A kötelező strukturált e-számlázásról egyelőre koncepció készült, jogszabály még nem. Uniós szinten a „héa a digitális korban” (ViDA) csomag 2030. július 1-jétől a strukturált e-számlát teszi alapértelmezetté a tagállamok közötti B2B ügyletekben. A számlát a folyamat egy újabb eseményeként kezeljük: az ERP-ből indul, a NAV felé adatszolgáltatásként, a partner felé a szükséges formátumban megy ki, és ha visszautasítják, a kivételkezelő felületre kerül. Bővebben: Online Számla és Peppol.
05Hogyan kerülik el a pont-pont kapcsolatok újabb törékeny hálóját?
A rendszerek egyetlen rétegen keresztül tesznek közzé és fogadnak dokumentált eseményeket és API-kat, nem egymáshoz kötve. A szerződések verziózottak, a fogadók idempotensek, a hibás üzenetek újrajátszhatók, és minden folyamatnak megnevezett gazdája van. Egy új csatorna a meglévő eseményekre iratkozik fel, ahelyett hogy minden rendszerhez új kapcsolatot kapna.
06Hogyan néz ki egy első hatókör?
Egy folyamat és egy kivételtípus, például egy értékesítési csatorna order to cash folyamata, első kivételként a készlethiánnyal. Ezen igazoljuk az eseményeket, az idővonalat és a jóváhagyási folyamatot, mielőtt továbblépünk. Olvasson többet a munkamódszerünkről.
Beszéljünk a rendelési és számlázási folyamatairól
Válasszon ki egy folyamatot és azokat az országokat, ahol fut. Közösen feltérképezzük a rendszereket, az interfészeket és a kivételeket, és olyan első kiadást javaslunk, amely minden jogi személyénél működik.