Datatemplate voor order-to-cash-verwerking van verkooporders
Datatemplate voor order-to-cash-verwerking van verkooporders
Dit is onze generieke datatemplate voor process mining voor Order to Cash: verwerking van verkooporders. Gebruik onze templates voor specifieke systemen voor gerichter advies.
Selecteer een specifiek systeem- Benoemt de belangrijkste data-attributen voor een volledig event log.
- Beschrijft de belangrijkste activiteiten en mijlpalen in het proces.
- Een algemeen startpunt voor process mining dat je aan elk systeem kunt aanpassen.
Attributen voor order-to-cash-verwerking van verkooporders
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment in het verkooporderproces plaatsvond. | ||
| Beschrijving De activiteitsnaam beschrijft een stap of mijlpaal in de levenscyclus van een verkooporder, zoals 'Verkooporder aangemaakt', 'Kredietcontrole uitgevoerd' of 'Goederen verzonden'. Elke activiteit staat voor een afzonderlijke handeling op de verkooporder en vormt een bouwsteen van de proceskaart. Voor analyses is dit attribuut onmisbaar om de procesflow zichtbaar te maken, veelvoorkomende routes te herkennen en afwijkingen van de standaardprocedure op te sporen. Aan de hand van de volgorde van activiteiten kunnen analisten bottlenecks, herstelwerk (zoals herhaalde activiteiten voor het wijzigen van een verkooporder) en afwijkingen van de compliance-eisen vinden. Dit attribuut vormt de basis voor dashboards zoals 'Procesconformiteit en -afwijkingen' en KPI's zoals 'Herstelwerkpercentage verkooporders'. Waarom dit belangrijk is Dit attribuut bepaalt welke stappen het proces bevat. Zo kun je de proceskaart weergeven, procesflows analyseren en herstelwerk of afwijkingen opsporen. Waar vind je dit? Vaak afgeleid uit statuswijzigingen van documenten, event logs of transactiecodes in de verkoop-, leverings- en facturatiemodules van het bronsysteem. Voorbeelden Verkooporder aangemaaktGoederen verzondenBetaling ontvangenVerkooporder geannuleerd | |||
| Tijdstip van gebeurtenis EventTime | De exacte datum en tijd waarop een activiteit of gebeurtenis plaatsvond. | ||
| Beschrijving Het tijdstip van de gebeurtenis is een timestamp die het exacte moment van een activiteit vastlegt. Dit attribuut geeft het proces een tijdscontext, zodat alle gebeurtenissen bij een verkooporder chronologisch kunnen worden gerangschikt. Deze timestamp is nodig voor alle tijdsanalyses. Je gebruikt hem om doorlooptijden tussen activiteiten te berekenen, de duur van afzonderlijke stappen te bepalen en vertragingen of bottlenecks op te sporen. De KPI 'Doorlooptijd van orderafhandeling' wordt bijvoorbeeld berekend als het verschil tussen het tijdstip van de laatste leveringsactiviteit en dat van de eerste orderaanmaakactiviteit. Dashboards zoals 'Overzicht doorlooptijd verkooporder' zijn volledig afhankelijk van dit attribuut. Waarom dit belangrijk is Deze timestamp is nodig om prestatiemetrieken zoals doorlooptijden en duur te berekenen en bottlenecks op te sporen. Waar vind je dit? Meestal te vinden bij elke transactie of statusupdate, vaak aangeduid als aanmaakdatum, wijzigingsdatum of boekingsdatum. Voorbeelden 2023-03-15T09:30:00Z2023-04-01T14:05:10Z2023-04-10T11:00:00Z | |||
| Verkooporder-ID SalesOrderId | De unieke identificatiecode van een verkooporder. Deze dient als primaire case-ID voor het Order-to-Cash-proces. | ||
| Beschrijving De verkooporder-ID vormt de basis voor process mining in Order to Cash. Deze unieke code identificeert elke procesinstantie, van aanmaak tot afsluiting. De ID fungeert als primaire sleutel die alle bijbehorende activiteiten, gebeurtenissen en datapunten met elkaar verbindt. Zo ontstaat een compleet beeld van het traject van één order. Met dit attribuut kun je tijdens analyses de levenscyclus van elke verkooporder reconstrueren. Je kunt de volgorde van gebeurtenissen volgen, de tijd tussen activiteiten meten en metrieken per order berekenen. Voor de KPI 'Doorlooptijd van orderafhandeling' groepeer je bijvoorbeeld alle activiteiten op basis van hun verkooporder-ID en bereken je het tijdsverschil tussen de eerste en laatste gebeurtenis. Waarom dit belangrijk is Deze ID is belangrijk om afzonderlijke orders door het proces te volgen en doorlooptijden, bottlenecks en afwijkingen per case te analyseren. Waar vind je dit? Meestal te vinden in de kopgegevenstabel van verkooporderdocumenten in het bronsysteem, zoals een ERP- of CRM-systeem. Voorbeelden SO-001234598004567ORD-2023-54321 | |||
| Bronsysteem SourceSystem | Geeft aan uit welk informatiesysteem de data afkomstig is, bijvoorbeeld een ERP-, CRM- of verouderd platform. | ||
| Beschrijving Het attribuut Bronsysteem geeft aan in welk registratiesysteem de gebeurtenisdata is aangemaakt. In moderne organisaties loopt een end-to-end-proces zoals Order to Cash vaak door meerdere applicaties, bijvoorbeeld een CRM-systeem voor het aanmaken van orders en een ERP-systeem voor de afhandeling en facturering. Bij analyses helpt dit attribuut om de technologische omgeving van het proces te begrijpen. Je kunt er integratiepunten en mogelijke problemen met de consistentie van data tussen systemen mee opsporen. Door activiteiten per bronsysteem te analyseren, zie je of bepaalde processtappen anders verlopen of meer vertraging oplopen in het ene systeem dan in het andere. Waarom dit belangrijk is Dit geeft context over de herkomst van de data. Dat is belangrijk in omgevingen met meerdere systemen, zodat je de herkomst van data kunt volgen en procesvariaties per systeem kunt opsporen. Waar vind je dit? Deze informatie wordt vaak toegevoegd tijdens de data-extractie (ETL) of is een standaardveld in datawarehouses. Voorbeelden SAP S/4HANASalesforce Sales CloudOracle NetSuite | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor het laatst is vernieuwd of uit het bronsysteem is opgehaald. | ||
| Beschrijving Dit attribuut bevat de timestamp waarop de data voor het laatst in de process mining-omgeving is geladen. Het geeft aan hoe actueel de geanalyseerde data is en verschilt van het tijdstip van de gebeurtenis, dat vastlegt wanneer de bedrijfsactiviteit daadwerkelijk plaatsvond. Deze informatie wordt meestal niet gebruikt voor een directe analyse van de procesflow, maar is wel belangrijk voor datagovernance en betrouwbare bevindingen. Analisten en gebruikers kunnen hiermee beoordelen hoe actueel de inzichten zijn. Als de laatste data-update bijvoorbeeld een week geleden was, moet je daar rekening mee houden bij conclusies over de huidige prestaties. Waarom dit belangrijk is Dit geeft aan hoe actueel de data is, zodat analyses op recente informatie zijn gebaseerd en conclusies relevant blijven. Waar vind je dit? Dit wordt meestal aangemaakt en opgeslagen door de data-extractietool (ETL) of het process mining-platform tijdens het inladen van de data. Voorbeelden 2023-10-27T02:00:00Z2023-10-26T02:00:00Z2023-10-25T02:00:00Z | |||
| Gebruikersnaam UserName | De naam of ID van de gebruiker, medewerker of systeemagent die de activiteit heeft uitgevoerd. | ||
| Beschrijving Het attribuut Gebruikersnaam geeft aan welke persoon of geautomatiseerde agent verantwoordelijk was voor een activiteit. Dat kan een verkoopmedewerker zijn die de order heeft aangemaakt, een kredietmanager die deze heeft goedgekeurd of een systeemgebruiker die automatisch een betaling heeft geboekt. Met dit attribuut kun je het proces vanuit menselijk perspectief analyseren. Je kunt de werkverdeling bekijken, prestaties van teams of personen vergelijken en opleidingsbehoeften opsporen. Het is ook belangrijk voor compliance en het auditspoor. Door activiteiten per gebruiker te analyseren, zie je wie betrokken is bij herstelwerk of gedrag dat niet aan de regels voldoet. Dit attribuut vormt bovendien de basis voor de KPI 'Percentage handmatige tussenkomst'. Waarom dit belangrijk is Geeft aan welke persoon of welk systeem een activiteit uitvoert. Zo kun je de werkverdeling, teamprestaties, automatiseringsgraad en compliance analyseren. Waar vind je dit? Vaak te vinden in transactielogs of wijzigingsgeschiedenis van documenten, bijvoorbeeld onder 'Gemaakt door' of 'Gewijzigd door'. Voorbeelden John.SmithBATCH_USERAlice.JonesUSER_API | |||
| Klantidentificatie CustomerIdentifier | De unieke identificatiecode of naam van de klant die de verkooporder heeft geplaatst. | ||
| Beschrijving Dit attribuut identificeert de externe partij voor wie de verkooporder wordt verwerkt. Het kan een uniek klantnummer, een bedrijfsnaam of een andere code zijn waarmee je de klant kunt onderscheiden. Met process mining kun je de data op basis van klantidentificatie segmenteren. Analisten kunnen de proceskaart filteren om te zien hoe het proces voor een specifieke klant verloopt, of procesflows van verschillende klantgroepen vergelijken, zoals strategische klanten en incidentele kopers. Zo komen aangepaste processen aan het licht en kun je klanten opsporen die vaak procesafwijkingen of vertragingen veroorzaken. Dat levert waardevolle informatie op voor klantrelatiebeheer. Waarom dit belangrijk is Hiermee kun je processen voor verschillende klanten of klantgroepen filteren en vergelijken, om aangepaste processen of problematische accounts op te sporen. Waar vind je dit? Te vinden in de kopgegevens van de verkooporder, gekoppeld aan de stamgegevens van de klant in het ERP- of CRM-bronsysteem. Voorbeelden CUST-10023Global Corp Inc.758991 | |||
| Orderwaarde OrderValue | De totale geldwaarde van de verkooporder, meestal uitgedrukt in de valuta van het document. | ||
| Beschrijving De orderwaarde is de totale financiële waarde van de verkooporder. Deze financiële metriek geeft aan hoe groot elke case is. Met dit attribuut kun je processen analyseren op basis van waarde en problemen prioriteren door te kijken naar orders met een hoge waarde. Analisten kunnen bijvoorbeeld onderzoeken of zulke orders langere doorlooptijden hebben of vaker herstelwerk vereisen dan orders met een lagere waarde. Je kunt er ook de financiële gevolgen van procesinefficiënties mee berekenen, zoals de totale waarde van orders die door een specifieke bottleneck vertraging oplopen. Zo onderbouw je de businesscase voor procesverbetering. Waarom dit belangrijk is Maakt analyse op basis van waarde mogelijk. Zo kun je procesverbeteringen prioriteren voor orders met een hoge waarde en de financiële gevolgen van vertragingen berekenen. Waar vind je dit? Beschikbaar in de kopgegevens van de verkooporder, vaak berekend als de som van de nettowaarden van alle orderregels. Voorbeelden 15200.50500.00125000.75 | |||
| Productidentificatie ProductIdentifier | De unieke code of naam van een hoofdproduct of dienst op de verkooporder. | ||
| Beschrijving De productidentificatie, zoals een materiaalnummer of SKU, geeft aan wat er wordt verkocht. Een verkooporder kan meerdere producten bevatten. Dit attribuut staat vaak voor het hoofdproduct of kan voor analyses op hoofdlijnen worden samengevoegd tot een productcategorie. Met dit attribuut kun je het Order-to-Cash-proces vanuit productperspectief bekijken. Uit de analyse kan blijken dat bepaalde producten samenhangen met langere afhandelingstijden, vaker problemen bij de levering of meer annuleringen. Deze informatie is belangrijk voor supplychainplanning, voorraadbeheer en de productportfoliostrategie. Als een productlijn bijvoorbeeld steeds vertraging oploopt bij de stap 'Vrijgegeven aan magazijn', kun je de voorraadniveaus of de plaatsing in het magazijn onderzoeken. Waarom dit belangrijk is Hiermee kun je de procesprestaties voor verschillende producten of productgroepen analyseren en productspecifieke bottlenecks of problemen opsporen. Waar vind je dit? Te vinden op het niveau van de orderregel. Voor analyses per case kan dit attribuut staan voor de belangrijkste orderregel of een afgeleide productcategorie. Voorbeelden PROD-5540-XLMAT-009871SVC-CONSULT-HR | |||
| Verkoopkanaal SalesChannel | Het kanaal waarlangs de verkooporder is ontvangen, zoals internet, directe verkoop of een partner. | ||
| Beschrijving Het verkoopkanaal geeft aan waar of hoe een order is geplaatst. Dat kan via een online portaal, een direct verkoopteam, een EDI-koppeling met een partner of een winkel. Door het proces per verkoopkanaal te analyseren, zie je verschillen in efficiëntie en procesconformiteit. Orders via internet kunnen bijvoorbeeld grotendeels geautomatiseerd en snel worden verwerkt, terwijl directe verkoop meer handmatige wijzigingen en langere goedkeuringsrondes met zich mee kan brengen. Met deze analyse kun je de procesflow per kanaal verbeteren en middelen doelgerichter inzetten. Het verkoopkanaal is ook een belangrijke dimensie voor dashboards zoals 'Bottlenecks in orderafhandeling'. Waarom dit belangrijk is Hiermee kun je de procesprestaties per kanaal vergelijken en verschillen in efficiëntie, automatisering en procesconformiteit opsporen. Waar vind je dit? Deze informatie staat meestal in de kopgegevens van de verkooporder en is vaak een verplicht veld bij het invoeren van een order. Voorbeelden WebportaalDirecte verkoopEDIPartnernetwerk | |||
| Bevestigde leverdatum ConfirmedDeliveryDate | De leverdatum die het bedrijf aan de klant heeft bevestigd en toegezegd. | ||
| Beschrijving Na controle van de voorraad en productieplanning geeft het bedrijf een bevestigde leverdatum door. Dit is de toezegging aan de klant en de interne maatstaf voor de prestaties van de orderafhandeling. Met dit attribuut kun je de interne efficiëntie beoordelen. Voor de KPI 'Percentage tijdige leveringen' vergelijk je de bevestigde leverdatum met de werkelijke leverdatum om te bepalen of het bedrijf zijn toezegging is nagekomen. Grote verschillen tussen de gewenste en bevestigde leverdatum bij veel orders kunnen wijzen op structurele problemen met de berekening van de beschikbare voorraad of de capaciteitsplanning. Waarom dit belangrijk is Dit is de toezegging van het bedrijf aan de klant en de interne maatstaf voor tijdige levering en betrouwbare orderafhandeling. Waar vind je dit? Te vinden in de planningsregels van de verkooporder. De datum wordt vaak bijgewerkt na een beschikbaarheidscontrole of productieplanningsrun. Voorbeelden 2023-11-182023-12-012024-01-15 | |||
| Geautomatiseerd IsAutomated | Een aanduiding die aangeeft of een activiteit automatisch door het systeem of handmatig door een gebruiker is uitgevoerd. | ||
| Beschrijving Dit booleaanse attribuut maakt onderscheid tussen taken die door gebruikers worden uitgevoerd en taken die automatisch door het systeem worden afgehandeld, bijvoorbeeld via achtergrondtaken, API’s of RPA-bots. Een kredietcontrole kan bijvoorbeeld automatisch verlopen, terwijl het opheffen van een kredietblokkade meestal handmatig gebeurt. Voor initiatieven rond digitale transformatie is het belangrijk om het proces vanuit automatisering te bekijken. Deze aanduiding is de belangrijkste databron voor het berekenen van de KPI ‘Percentage handmatige interventies’. Zo zie je welke processtappen grotendeels automatisch verlopen en waar nog handmatig werk nodig is. De analyse laat zien waar verdere automatisering mogelijk is om kosten en fouten te beperken en doorlooptijden te verkorten. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en geautomatiseerde taken. Dat is belangrijk om de mate van automatisering te meten en mogelijkheden voor procesverbetering te vinden. Waar vind je dit? Deze informatie is af te leiden uit het attribuut ‘Gebruikersnaam’, bijvoorbeeld door systeemgebruikers zoals ‘BATCH_USER’ te herkennen, of uit specifieke velden in event logs die de uitvoeringscontext vastleggen. Voorbeelden truefalse | |||
| Gewenste leverdatum RequestedDeliveryDate | De leverdatum die de klant voor de order heeft aangevraagd. | ||
| Beschrijving Deze datum geeft aan wanneer de klant de levering verwacht. De datum wordt aan het begin van het proces vastgelegd en is de belangrijkste maatstaf voor de tevredenheid van de klant over de levertijd. Bij procesanalyses vergelijk je de gewenste leverdatum met andere belangrijke datums, zoals de bevestigde en werkelijke leverdatum, om het serviceniveau te meten. Deze datum is een belangrijke invoer voor het dashboard 'Prestaties van tijdige levering'. Je gebruikt hem om te bepalen of de levering op tijd was, vanuit het oogpunt van de klant. Verschillen tussen de gewenste en bevestigde leverdatum kunnen ook problemen met planning en roostering aan het licht brengen. Waarom dit belangrijk is Geeft de leververwachting van de klant weer en vormt de basis voor het meten van tijdige leveringen en klanttevredenheid. Waar vind je dit? Meestal te vinden in de kopgegevens of orderregels van de verkooporder. De datum wordt ingevoerd wanneer de order wordt aangemaakt. Voorbeelden 2023-11-152023-12-012024-01-10 | |||
| Orderstatus OrderStatus | De status van de verkooporder op het moment van de gebeurtenis, zoals 'Open', 'In behandeling' of 'Voltooid'. | ||
| Beschrijving De orderstatus geeft op een bepaald moment een beeld van de fase waarin de verkooporder zich bevindt. Het is een categorie die de huidige status van de order samenvat. De volgorde van activiteiten geeft een gedetailleerde proceskaart. Met het attribuut Orderstatus maak je een eenvoudiger overzicht op hoofdlijnen. Je kunt bijvoorbeeld filteren op alle orders met een bepaalde status, zoals 'Geblokkeerd vanwege kredietcontrole'. Door te analyseren hoelang orders in verschillende statussen blijven, kun je ook bottlenecks opsporen, bijvoorbeeld orders die te lang op goedkeuring wachten. Waarom dit belangrijk is Geeft een samenvatting op hoofdlijnen van de status van een order. Je kunt ermee filteren, statussen analyseren en orders opsporen die in een bepaalde fase vastlopen. Waar vind je dit? Dit is een standaardveld in de kopgegevens van de meeste verkooporderdocumenten in ERP- en CRM-systemen. Voorbeelden OpenIn behandelingKredietblokkadeVoltooidGeannuleerd | |||
| Reden voor afwijzing RejectionReason | Een code of omschrijving die uitlegt waarom een verkooporder of orderregel is geannuleerd of afgewezen. | ||
| Beschrijving Wanneer een verkooporder wordt geannuleerd of een artikel wordt afgewezen, geeft de reden voor afwijzing context bij deze uitkomst. Mogelijke redenen zijn bijvoorbeeld ‘Geannuleerd door klant’, ‘Onjuiste prijs’ en ‘Niet op voorraad’. Dit attribuut is essentieel om de oorzaken van procesproblemen te analyseren. Door te kijken hoe vaak verschillende afwijsredenen voorkomen, kan een bedrijf structurele problemen opsporen. Veel annuleringen vanwege een onjuiste prijs kunnen bijvoorbeeld wijzen op problemen met het opstellen van offertes of met stamgegevens. Deze analyse helpt om het percentage ‘In één keer goed’ te verhogen en verspilling in het proces terug te dringen. Waarom dit belangrijk is Legt uit waarom orders mislukken en helpt de onderliggende problemen met prijzen, voorraad of klantcommunicatie op te sporen. Waar vind je dit? Dit gegeven staat meestal op het niveau van de orderregel. Bij annulering van een artikel wordt een code gekozen uit een vooraf bepaalde lijst. Voorbeelden Verzoek van klantProduct uit assortimentPrijsfoutKredietlimiet overschreden | |||
| Uiterste betaaldatum PaymentDueDate | De datum waarop de klant de factuur uiterlijk moet betalen. | ||
| Beschrijving De uiterste betaaldatum wordt berekend op basis van de factuurdatum en de afgesproken betalingstermijn van de klant. De datum bepaalt wanneer de betaling uiterlijk binnen moet zijn en speelt een belangrijke rol in het debiteurenproces. Dit attribuut is belangrijk voor de analyse van het financiële deel van de Order-to-Cash-cyclus. Het is de maatstaf om te bepalen of een betaling op tijd was en vormt een directe invoer voor de KPI 'Percentage tijdige betalingen'. Het dashboard 'Doorlooptijd van factuur tot betaling' gebruikt deze datum om betaalgedrag te analyseren en het werkkapitaal te beheren. Door vertragingen tussen het aanmaken van de factuur en de betaling met deze datum te vergelijken, kun je klanten opsporen die laat betalen. Waarom dit belangrijk is Deze datum is belangrijk voor financiële analyses en vormt de basis voor het berekenen van het percentage tijdige betalingen en het beheren van debiteuren. Waar vind je dit? Meestal te vinden op de klantfactuur. De datum wordt afgeleid van de factuurdatum en de betalingstermijn in de stamgegevens van de klant of de verkooporder. Voorbeelden 2023-12-152024-01-302024-02-28 | |||
| Werkelijke leverdatum ActualDeliveryDate | De datum waarop de goederen daadwerkelijk bij de klant zijn afgeleverd. Hiermee is het deel van het proces dat over de orderafhandeling gaat voltooid. | ||
| Beschrijving De werkelijke leverdatum is de timestamp waarop de succesvolle levering van de goederen aan de klant wordt vastgelegd. Deze datum is vaak gebaseerd op een Proof of Delivery van de vervoerder. Dit attribuut is de definitieve maatstaf voor een geslaagde orderafhandeling. Je gebruikt het om het 'Percentage tijdige leveringen' te berekenen door de datum te vergelijken met zowel de gewenste als de bevestigde leverdatum. Door het tijdsverschil tussen de activiteit 'Goederen verzonden' en de werkelijke leverdatum te analyseren, krijg je ook inzicht in de prestaties van logistieke partners en verzendmethoden. Waarom dit belangrijk is Dit is het definitieve bewijs dat de order is afgehandeld. Je hebt deze datum nodig om het percentage tijdige leveringen en de totale doorlooptijd van orderafhandeling nauwkeurig te berekenen. Waar vind je dit? Vaak afkomstig uit een extern logistiek of verzendsysteem en teruggekoppeld naar het ERP-systeem. De datum kan worden afgeleid uit de timestamp van de activiteit 'Goederen geleverd'. Voorbeelden 2023-11-172023-12-022024-01-14 | |||
Activiteiten voor order-to-cash-verwerking van verkooporders
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling ontvangen | Deze activiteit geeft aan dat de betaling van de klant voor een factuur is ontvangen, verwerkt en toegewezen. Dit gebeurt meestal in de debiteurenmodule en sluit de openstaande financiële post af. | ||
| Waarom dit belangrijk is Dit is de laatste stap die waarde oplevert. De tijd tussen facturering en betaling meten is belangrijk voor de analyse van Days Sales Outstanding en de efficiëntie van de cash conversion cycle. Waar vind je dit? Dit is een expliciete financiële boeking, vastgelegd aan de hand van de vereffeningsdatum van de debiteurendocumenten of het aanmaken van een betalingstoewijzing. Vastleggen Gebruik de boekingsdatum of vereffeningsdatum van het financiële document waarmee het openstaande factuurbedrag wordt voldaan. Gebeurtenistype explicit | |||
| Factuur aangemaakt | Deze activiteit staat voor het aanmaken van de klantfactuur voor de geleverde goederen of diensten. Dit is een financiële transactie die de schuld van de klant formeel vastlegt en de betalingstermijn laat ingaan. | ||
| Waarom dit belangrijk is De tijd tussen verzending en facturering, ook wel de vertraging tussen facturering en betaling genoemd, heeft direct invloed op de cashflow. Door deze tijd te analyseren, kun je vertragingen in het facturatieproces opsporen. Waar vind je dit? Dit is een expliciete gebeurtenis, vastgelegd aan de hand van de aanmaaktimestamp van de factuur of het facturatiedocument in de financiële module. Vastleggen Gebruik de aanmaakdatum en -tijd van het factuurrecord in de debiteuren- of facturatietabellen. Gebeurtenistype explicit | |||
| Goederen verzonden | Deze belangrijke gebeurtenis markeert het moment waarop de verpakte goederen zijn verzonden en het magazijn fysiek hebben verlaten. Dit is een belangrijke logistieke en financiële mijlpaal die vaak het facturatieproces in gang zet. | ||
| Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het meten van de prestaties van tijdige levering en de doorlooptijd van de orderafhandeling. De tijd tussen het aanmaken van de order en de verzending is een belangrijke prestatie-indicator. Waar vind je dit? Dit is meestal een expliciete gebeurtenis in de verzend- of logistieke modules, vaak aangeduid als ‘Post Goods Issue’ of ‘Ship Confirmation’. Vastleggen Gebruik de timestamp van de verzendbevestiging of goederenafgifte. Deze staat meestal op het leverings- of afhandelingsdocument. Gebeurtenistype explicit | |||
| Verkooporder aangemaakt | Deze activiteit markeert het moment waarop een verkooporder in het systeem wordt aangemaakt. De aanvraag van een klant voor goederen of diensten wordt hiermee officieel vastgelegd. Dit is het startpunt van het Order to Cash-proces. | ||
| Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. Door de tijd vanaf dit moment te analyseren, kun je de totale doorlooptijd van de orderafhandeling en de efficiëntie van de eerste gegevensinvoer meten. Waar vind je dit? Deze gebeurtenis wordt meestal vastgelegd met de aanmaaktimestamp van de hoofdrecord van de verkooporder of in het bijbehorende transactielogboek. Vastleggen Zoek de eerste timestamp die hoort bij het aanmaken van een nieuw verkooporder-ID in de orderkop- of documenttabel van het systeem. Gebeurtenistype explicit | |||
| Verkooporder geannuleerd | Deze gebeurtenis staat voor de annulering van een verkooporder voordat deze volledig is verzonden en gefactureerd. Dit is een alternatieve, niet-succesvolle afsluiting van het proces, die in verschillende fasen kan plaatsvinden. | ||
| Waarom dit belangrijk is Dit is een belangrijke uitkomst waarbij het proces misloopt. Door te analyseren wanneer en waarom orders worden geannuleerd, kun je problemen met klanttevredenheid, voorraadbeschikbaarheid of invoerfouten opsporen. Waar vind je dit? Meestal vastgelegd met een specifieke status, zoals 'Geannuleerd' of 'Afgewezen', op de kop van de verkooporder of op de orderregels. Vastleggen Leg de timestamp vast waarop een annuleringsreden of de definitieve status 'Geannuleerd' aan het verkooporderdocument wordt toegekend. Gebeurtenistype inferred | |||
| Verkooporder gesloten | Dit is de laatste activiteit voor een succesvol verwerkte order. De order is volledig verzonden, gefactureerd en betaald. Deze status geeft aan dat er geen verdere transacties voor de verkooporder worden verwacht. | ||
| Waarom dit belangrijk is Deze activiteit markeert de succesvolle afronding van het proces. De totale tijd tussen aanmaak en afsluiting is de end-to-end-doorlooptijd van een perfect afgehandelde order. Waar vind je dit? Meestal af te leiden uit een eindstatus op de kop van de verkooporder, zoals 'Gesloten' of 'Voltooid', nadat alle onderliggende transacties zijn afgerond. Vastleggen Bepaal de timestamp waarop de algemene status van de verkooporder wordt bijgewerkt naar de definitieve, afgeronde status. Gebeurtenistype inferred | |||
| Verkooporder goedgekeurd | Deze mijlpaal geeft aan dat de verkooporder alle benodigde interne controles heeft doorstaan, zoals krediet- en configuratiecontroles, en officieel is bevestigd voor afhandeling. Dit gebeurt vaak via een expliciete goedkeuringsactie of statuswijziging. | ||
| Waarom dit belangrijk is Dit is een belangrijk controlepunt dat bepaalt wanneer de orderafhandeling kan beginnen. Door de tijd tot de goedkeuring te analyseren, kun je vertragingen in de controle en beoordeling van orders opsporen. Waar vind je dit? Dit wordt meestal vastgelegd als een specifieke status, zoals ‘Goedgekeurd’, ‘Bevestigd’ of ‘Geboekt’, in het statusveld van de verkooporder of in de workflowgeschiedenis. Vastleggen Zoek de timestamp waarop de status van de verkooporder verandert naar een status die aangeeft dat de order klaar is voor afhandeling, zoals ‘Goedgekeurd’ of ‘Geboekt’. Gebeurtenistype inferred | |||
| Creditnota aangemaakt | Deze activiteit vindt plaats wanneer een creditnota aan een klant wordt verstrekt, meestal vanwege retouren, prijsverschillen of andere correcties. De creditnota draait een eerder gefactureerd bedrag geheel of gedeeltelijk terug. | ||
| Waarom dit belangrijk is Door te analyseren hoe vaak en waarom creditnota's worden verstrekt, kun je structurele problemen met productkwaliteit, verzendnauwkeurigheid of prijsfouten opsporen. Dit is een belangrijke aanwijzing voor procesproblemen. Waar vind je dit? Dit is een expliciete financiële gebeurtenis, vastgelegd aan de hand van de aanmaaktimestamp van de creditnota in de facturatie- of debiteurenmodule. Vastleggen Gebruik de aanmaakdatum en -tijd van het creditnotadocument. Dit is meestal gekoppeld aan de oorspronkelijke verkooporder of factuur. Gebeurtenistype explicit | |||
| Factuur naar klant verzonden | Dit is het moment waarop de aangemaakte factuur naar de klant wordt verstuurd voor betaling. Dat kan via e-mail, elektronische gegevensuitwisseling of per post. | ||
| Waarom dit belangrijk is Hiermee begint officieel de betalingstermijn van de klant. Vertraging tussen het aanmaken en versturen van de factuur kan de cash conversion cycle negatief beïnvloeden. Waar vind je dit? Afkomstig uit logs van het outputmanagement, communicatiegegevens of een specifieke statusupdate van het factuurdocument. Vastleggen Leg de timestamp vast uit het outputlog van het systeem, waaruit blijkt dat het factuurdocument succesvol is verzonden. Gebeurtenistype inferred | |||
| Goederen geleverd | Deze activiteit geeft aan dat de zending op het opgegeven adres bij de klant is afgeleverd. Deze informatie wordt vaak bijgewerkt op basis van data van een externe logistieke vervoerder of een handmatige bevestiging. | ||
| Waarom dit belangrijk is Door leveringen te volgen, krijg je een volledig beeld van de klantervaring en kun je de totale doorlooptijd van orderafhandeling nauwkeurig meten. Waar vind je dit? Meestal afkomstig uit gegevens van externe vervoerders die teruggekoppeld worden naar het kernsysteem, of uit een bevestiging van de 'Proof of Delivery'. Vastleggen Leg de timestamp van de leveringsbevestiging door de vervoerder vast, of de timestamp van een handmatig ingevoerd 'Proof of Delivery'-record. Gebeurtenistype explicit | |||
| Goederen verpakt | Deze activiteit markeert het einde van het verpakkingsproces. De verzamelde artikelen worden samengevoegd, verpakt en klaargemaakt voor verzending. Vaak wordt ook een pakbon aangemaakt en worden de verzendgegevens definitief vastgelegd. | ||
| Waarom dit belangrijk is Door de tijd tussen het verzamelen en verpakken te analyseren, kun je de indeling van werkplekken en de verpakkingsprocedures verbeteren. Dit is ook een belangrijke stap om te controleren of de order klopt voordat die wordt verzonden. Waar vind je dit? Deze gebeurtenis kan als aparte status in een WMS worden vastgelegd of worden afgeleid uit de aanmaaktimestamp van een pakbon. Vastleggen Zoek de timestamp waarop de status van het afhandelingsdocument verandert naar ‘Verpakt’, of gebruik de aanmaaktimestamp van de pakbon. Gebeurtenistype inferred | |||
| Goederen verzameld | Deze activiteit geeft aan dat alle artikelen voor de order op hun magazijnlocaties zijn verzameld. Meestal wordt dit vastgelegd wanneer een magazijnmedewerker bevestigt dat het verzamelen is afgerond. | ||
| Waarom dit belangrijk is De verzameltijd meten is belangrijk om de efficiëntie van het magazijn te analyseren en bottlenecks in de fysieke orderafhandeling op te sporen. Waar vind je dit? Meestal vastgelegd in een module van een Warehouse Management System of af te leiden uit een statusupdate van het leverings- of afhandelingsdocument. Vastleggen Leg de timestamp vast waarop de status van de bijbehorende picklijst of het afhandelingsdocument wordt bijgewerkt naar ‘Verzameld’ of ‘Voltooid’. Gebeurtenistype inferred | |||
| Kredietcontrole uitgevoerd | Deze activiteit geeft aan dat de kredietwaardigheid van de klant bij de order is gecontroleerd. Dit kan een automatische systeemcontrole of een handmatige beoordeling zijn. Vaak wordt daarna de kredietstatus van de order bijgewerkt. | ||
| Waarom dit belangrijk is Deze stap vormt vaak een bottleneck. Door de duur en uitkomsten te meten, kun je de efficiëntie van het kredietbeheer en de invloed ervan op de totale doorlooptijd van de order analyseren. Waar vind je dit? Vaak af te leiden uit een statuswijziging van de verkooporder, het opheffen van een kredietblokkade of een registratie in een specifiek logboek voor kredietbeheer. Vastleggen Leg de timestamp vast waarop het veld voor de kredietstatus van de order wordt bijgewerkt naar ‘Goedgekeurd’ of ‘Gecontroleerd’, of waarop een kredietblokkade wordt opgeheven. Gebeurtenistype inferred | |||
| Verkooporder gewijzigd | Deze activiteit staat voor een belangrijke wijziging in een verkooporder nadat die is aangemaakt, bijvoorbeeld een wijziging van aantallen, artikelen, prijzen of gewenste datums. Meestal wordt dit vastgelegd in auditsporen of wijzigingslogboeken van het systeem. | ||
| Waarom dit belangrijk is Door wijzigingen in orders te volgen, kun je herstelwerk opsporen, oorzaken van inefficiëntie begrijpen en meten hoe vaak orders in één keer goed zijn. Veel wijzigingen kunnen wijzen op problemen met de nauwkeurigheid van de oorspronkelijke order. Waar vind je dit? Afkomstig uit wijzigingslogtabellen of auditsporen van het systeem, of bepaald door verschillende versies van het verkooporderdocument met elkaar te vergelijken. Vastleggen Filter de wijzigingslogboeken van het systeem op updates van belangrijke velden in de orderkop of orderregels. Gebruik de timestamp van de wijziging als tijdstip van de gebeurtenis. Gebeurtenistype explicit | |||
| Voorraad gereserveerd | Deze activiteit markeert het moment waarop de benodigde voorraad voor de verkooporderregels is toegewezen of gereserveerd. Zo zijn de artikelen beschikbaar voor deze specifieke order en kunnen ze niet aan iemand anders worden verkocht. | ||
| Waarom dit belangrijk is Door voorraadreserveringen te volgen, kun je de beschikbaarheid van materialen en mogelijke voorraadgerelateerde vertragingen analyseren. De tijd tussen de goedkeuring van de order en de reservering kan problemen met de bevoorrading aan het licht brengen. Waar vind je dit? Dit is vaak een automatische systeemgebeurtenis. De reservering wordt vastgelegd in voorraadtransactietabellen of blijkt uit een statuswijziging op de verkooporderregel. Vastleggen Leg de timestamp vast uit het voorraadtransactielogboek die hoort bij de reservering van voorraad voor de specifieke verkooporderregel. Gebeurtenistype explicit | |||
| Vrijgegeven aan het magazijn | Deze activiteit markeert de officiële overdracht van de verkooporder aan het magazijn voor de fysieke verwerking. Het magazijnteam kan nu beginnen met het verzamelen en verpakken van de artikelen. | ||
| Waarom dit belangrijk is Dit is een belangrijk overdrachtsmoment tussen afdelingen. Door de tijd voor deze stap te analyseren, kun je bottlenecks in de communicatie tussen verkoop en logistiek opsporen. Waar vind je dit? Deze gebeurtenis wordt vaak vastgelegd wanneer een picklijst wordt aangemaakt of wanneer de orderstatus wordt bijgewerkt naar ‘Klaar om te verzamelen’ of ‘Vrijgegeven’. Vastleggen Zoek de timestamp waarop de status van de verkooporderregel verandert naar een status die aangeeft dat de order klaar is voor verwerking in het magazijn. Gebeurtenistype inferred | |||
Extractiegidsen
Extractiemethoden verschillen per systeem. Lees voor gedetailleerde instructies
Klaar om te beginnen?
Je kunt een gids voor een specifiek systeem volgen of deze generieke template aanpassen. In beide gevallen kun je nu aan de slag met het verbeteren van de order-to-cash-verwerking van verkooporders.
Verbeter de verwerking van verkooporders vanaf vandaag
Krijg meteen inzicht, beperk vertragingen en verbeter je cashflow.
Geen creditcard nodig. Je bent binnen enkele minuten aan de slag.