Cât valorează o zi de raft gol.
marql găsește SKU-urile ajunse la zero care încă se vindeau și evaluează absența după vânzările tale, nu după cost. De aici ecranul se oprește, iar playbook-ul mai face doi pași: prin marjă și prin substituție. La final pune cele trei opțiuni reale una lângă alta — plătești ca să ajungă mai devreme, absorbi golul sau îl ocolești printr-un înlocuitor.
În pericol
381 €
pe săptămână, din care 38 € se răscumpără
- din vânzări, nu din cost
- merge pe casă și stoc
- recuperabil ≠ în pericol
Capturile sunt din piața demo Mercado Claro și au fost făcute pe 1 septembrie 2026. Interfața rulează aici în temă întunecată, iar marql AI răspunde în spaniolă; playbook-ul 01 arată o altă piață, în temă deschisă. Cifrele sunt generate, iar tenantul își avansează propriul ceas, așa că acestea sunt instantanee, nu constante.
Raftul e gol. Cererea, nu.
La Mercado Claro o referință e la zero în Madrid · Malasaña. Granola artesanal, a doua zi consecutiv. marql o evaluează după vânzările magazinului și arată ≈381 € pe săptămână în pericol până la reaprovizionare. Aici se oprește produsul și de aici începe decizia. Pentru că 381 € nu e ce pierde rețeaua și cu siguranță nu e cât merită plătit unui curier. Între cifra de pe ecran și cifra pe care un achizitor poate pune mâna stau două înmulțiri, iar fiecare dintre ele o micșorează.
- 381 €
- vânzări săptămânale în pericol
- 223 €
- marjă în interiorul lor
- 38 €
- atât valorează două zile
- 2
- zile consecutiv
De la un raft la zero la o decizie cu preț.
Patru etape. A treia se sare de obicei, și tocmai ea contează: opțiunile nu costă la fel, iar cea mai ieftină e adesea să nu faci nimic și să scrii de ce.
Un SKU care se vindea e acum la zero.
În fiecare zi scanarea compară stocul cu istoricul vânzărilor și scoate SKU-urile care au produs venit în ultimele 30 de zile și azi nu mai au stoc. Rândurile se adună într-un incident per magazin, nu în câte unul per SKU. Sunt așezate pe benzi după felul banilor: o scurgere săptămânală care se repetă, vânzări care se epuizează, capital blocat. Bara de sub fiecare rând arată cât. Ruptura de stoc are banda ei, cu 381 € — sub trei scurgeri care costă mai mult pe săptămână și peste supra-stocul căruia îi e dedicat primul playbook de aici.
Scanare zilnică · un incident per magazin · lungimea barei = bani în joc
Ziua de absență primește o cifră, din vânzări și nu din cost.
Rata vine din vânzările recente ale SKU-ului însuși, nu dintr-o medie pe categorie și nu dintr-un preț de listă. Tocmai de aceea acesta e singurul playbook care merge doar cu o casă de marcat și un flux de stoc: până aici nu sunt necesare date de cost. Cifra e săptămânală, pentru că aceea e perioada incidentului. Transformarea ei în zi rămâne treaba cititorului, nu o cifră inventată de produs.
Din vânzările SKU-ului · fără date de cost
Separă o referință care s-a oprit de una care s-a stins.
marql verifică dacă e ceva comandat, dacă același SKU e pe stoc în altă parte din rețea și dacă magazinul s-a mai golit înainte. O repetare la aceeași adresă e o problemă de aprovizionare îmbrăcată în problemă de raft. Produsul arată numărul în loc să-l lase pe seama memoriei, iar diferența e între a rezolva o ruptură și a plăti lunar pentru aceeași.
Comandat · în altă locație · număr de repetări
Disponibilitatea refăcută nu înseamnă venit recuperat.
După confirmarea acțiunii, marql fixează perioada de bază și fereastra de măsurare. Fereastra trebuie să depășească vârful: primele zile după reumplere vând cererea adunată cât raftul a fost gol și înfrumusețează orice decizie măsurată față de ele. Merită spus exact unde stă asta. Pe acest tenant registrul de impact e un raport datat, așezat printre vizualizările salvate, cu date la 10 august 2026 — nu o suprafață vie care se actualizează sub ochii tăi. O revizuire pe care trebuie s-o deschizi rămâne o revizuire. Una pe care n-o deschide nimeni, nu.
Raport datat · bază înghețată la confirmare · fereastră peste vârf
Zero poate fi cifra corectă.
Aritmetica nu e pusă la îndoială: SKU-ul se vindea și nu mai are stoc. Se pune la îndoială dacă are cineva de ce să acționeze. În cel puțin cinci situații obișnuite raftul gol e exact ce s-a urmărit, iar cine plătește acolo pentru livrare mai devreme plătește un cost în plus ca să desfacă decizia altcuiva.
Referința se epuizează intenționat
Un SKU scos din listă ajunge la zero exact după plan. Numai că planul stă în capul achizitorului sau într-un fișier pe care produsul nu l-a văzut niciodată. Semnalul vede o referință care s-a vândut bine 28 de zile și apoi s-a oprit — iar o epuizare controlată arată din date exact așa.
E ceva comandat și se vinde deja un înlocuitor în aceeași subcategorie? La o epuizare planificată nu există nici comandă deschisă, nici gol în venitul subcategoriei: succesorul îl preia deja.
Sezonul s-a încheiat, iar fereastra n-a aflat încă
Rata citește vânzările recente. La o referință sezonieră, fereastra calcă peste sfârșitul sezonului și continuă să citeze o cerere care deja a plecat. Raftul e gol pentru că nu cumpără nimeni, nu pentru că n-a ajuns marfă.
Același SKU, aceleași săptămâni de anul trecut. Dacă și atunci ritmul cădea la fel, sezonul s-a terminat. Dacă anul trecut se vindea încă în acest punct, nu s-a terminat.
Înlocuitorul e deja pe raft, dar cu alt cod
O schimbare de gramaj, o schimbare de furnizor sau o reformulare dau aceluiași produs un SKU nou. Codul vechi coboară la zero și rămâne acolo, ceea ce e corect. Cererea continuă neatinsă la un cod de bare distanță.
Venitul subcategoriei în aceleași zile. Dacă subcategoria e plată cât timp SKU-ul e la zero, cererea nu a plecat. S-a mutat, și nu e nimic de recuperat.
O serie limitată care nici nu urma să fie reaprovizionată
O achiziție punctuală, un sfârșit de serie la furnizor, o colaborare cu dată de încheiere tipărită. Epuizarea e rezultatul pentru care s-a făcut achiziția, iar alerta descrie un succes.
A fost reaprovizionarea posibilă vreodată? Există o fișă de furnizor cu termen, sau comanda inițială era tot? Un SKU fără cale de recomandă nu poate fi grăbit la niciun preț.
Raftul e gol, depozitul nu
Scanarea citește cantitatea înregistrată, iar aceasta e exact zero. Stocul care stă fizic în spate neînregistrat sau e trecut pe altă locație arată identic cu stocul care nu există. Într-o rețea reală e cel mai frecvent dintre cele cinci cazuri și cel mai ieftin de rezolvat.
Mai apar vânzări pe un SKU pe care sistemul îl dă la zero? Combinația e imposibilă și lămurește întrebarea fără ca cineva să iasă din birou. Dacă s-au oprit și vânzările, verificarea e ca cineva să meargă în depozit. Răspunsul intră în registru, pentru că un zero fantomă neconsemnat revine în fiecare săptămână.
Pe scurt
Niciunul dintre aceste cazuri nu face venitul să reapară acolo unde chiar era în pericol. Se schimbă altceva: la patru din cinci acțiunea devine „nu face nimic și scrie de ce”, iar la al cincilea „du-te și uită-te” în loc de „plătește ca să vină mai repede”. marql recunoaște un motiv doar când motivul e în date: o comandă deschisă, o subcategorie plată, o fișă de furnizor. O epuizare care stă în capul achizitorului îi rămâne invizibilă, iar tocmai suprascrierea care o consemnează e lucrul util.
Raftul era gol. Decizia a eșuat oricum.
Cinci feluri de a greși după ce semnalul a fost corect, în ordinea în care apar: banii greșiți, urgența greșită, adresa greșită, victoria greșită, contabilitatea greșită. Scenariile sunt construite, nu observate — în spatele lor nu stau cifrele niciunei rețele.
Costul suplimentar socotit față de venit, nu față de marjă
381 € pe săptămână fac un curier de 100 € să pară o alegere evidentă. Numai că decizia nu recuperează 381 €. Ea recuperează marja brută a unităților care altfel nu s-ar fi vândut deloc, iar la marjele acestui tenant asta înseamnă circa 223 €. Din ele se ia apoi doar partea care nu pleacă spre alt produs, câștigându-și marja oricum. Două zile dintr-o săptămână de șapte valorează în jur de 38 €. Curierul iese pe pierdere, iar pe ecran nimic nu sugerează asta.
Înmulțește înainte să decizi: vânzări în pericol ori marja, ori partea care nu s-ar înlocui, ori zilele câștigate, împărțit la șapte. Rezultatul e plafonul costului suplimentar. La această referință el e a zecea parte din cifra din titlu, nu jumătatea ei.
Grăbirea unei cereri care deja a plecat
Un produs de bază lipsește de nouă zile. Costul suplimentar se plătește în ziua a opta, paletul ajunge în a noua, iar clienții care îl căutau în prima săptămână și-au refăcut de mult coșul în altă parte. Unitățile sosesc; cererea nu vine înapoi cu ele. Grăbirea răscumpără zilele pe care le taie de la începutul golului, nu pe cele deja consumate.
Se numără zilele câștigate, nu zilele lipsă. Dacă livrarea urma să ajungă vineri și costul suplimentar o aduce miercuri, socoteala merge pe două zile. La o referință absentă mai mult decât un ciclu de cumpărare, ia o rată de recuperare mai mică decât valoarea implicită din calculator.
Reparat la raft, când cauza e în amonte
Un magazin se golește, primește un transfer și se golește iar peste trei săptămâni. Fiecare răspuns în parte a fost corect, dar niciunul n-a ajuns la cauză: o cantitate de comandă sub ritmul real al magazinului, un termen de livrare lăsat la o valoare implicită pe care n-a verificat-o nimeni, sau o rută care ocolește adresa aceea. Costul suplimentar se plătește lunar, iar defectul nu iese niciodată la iveală, pentru că fiecare eveniment se închide singur.
Numără evenimentele per magazin pe 30 de zile înainte să alegi acțiunea. O repetare nu e o ruptură de stoc, ci un defect de achiziții sau de logistică care se dă drept ruptură. Grăbirea lunară e un abonament la simptom.
Înlocuirea cu un produs mai slab, trecută drept economie
Clientul e îndrumat spre articolul de alături, totalul de casă al zilei se ține, iar incidentul se închide ca rezolvat. Înlocuitorul are însă marjă mai mică. Rețeaua a schimbat o absență cu marjă mare pe o prezență cu marjă mică, și nimeni n-a notat diferența. Linia de venit a rămas plată — exact de aceea nimeni nu s-a uitat la linia de marjă.
Substituția e o acțiune firească și are un preț: diferența de marjă pe unitate între cele două SKU-uri, înmulțită cu unitățile. Dacă diferența nu se știe pentru că lipsesc prețurile de cost, atunci substituția e o acțiune neevaluată și se consemnează ca atare, nu ca o victorie.
Măsurarea care prinde vârful de după reaprovizionare
Raftul se reumple și primele zile vând cererea adunată. Față de zilele acelea, orice acțiune pare un triumf. Față de luna următoare, referința e de unde a plecat, iar registrul a înregistrat deja recuperarea.
Baza și fereastra se fixează la confirmarea acțiunii, niciodată după ce cifrele sunt cunoscute. Fereastra e destul de lungă cât să prindă cicluri săptămânale întregi, nu zilele imediat de după reumplere. Registrului trebuie să i se permită să răspundă „fără efect” și „date insuficiente”. Un registru care spune doar „dovedit” nu măsoară nimic.
Pe scurt
Patru din cinci sunt o acțiune greșită aleasă după o cifră corectă. Al cincilea e o acțiune corectă consemnată necinstit. Forma e aceeași ca în playbook-ul 01, pentru că e același eșec de curaj în același punct al ciclului. Cele mai grele sunt primul și al treilea: unul se sprijină pe bani care nu sunt chiar acolo, celălalt tratează în continuare o problemă la adresa greșită.
Începe cu cea care contează
Care dintre rafturile goale de azi merită reumplute mai devreme, contra cost?
Sunt anomalii în ultimele 7 zile?
1 anomalie detectată — nicio alertă activă.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01Ce SKU-uri sunt azi la zero, deși au produs venit în ultimele 30 de zile?
- 02Cât aduce fiecare pe zi de vânzare și ce marjă are?
- 03Pentru care dintre ele e ceva comandat și pe când e promis?
- 04Care sunt pe stoc într-o locație destul de apropiată pentru transfer?
- 05Ce magazine s-au golit de mai multe ori în ultimele 30 de zile și cu ce?
- 06Scrie planul: acțiune, responsabil, termen și fereastra în care va fi judecat.
Ce e nevoie ca să evaluezi o zi de absență.
Stoc disponibil pe SKU × locație
Un instantaneu zilnic, nu o numărătoare live. Fără el playbook-ul nici nu pornește. O conexiune doar de casă adesea nu îl aduce, iar asta e primul lucru de verificat, nu ultimul.
Vânzări pe SKU × locație
Cantitate, valoare și dată, măcar pentru ultimele 28 de zile. Tocmai ele pun preț pe zi, și de aceea playbook-ul merge fără date de cost.
Marja brută a SKU-ului
Fără ea absența se numără oricum și se ordonează după venit, dar plafonul a ceea ce merită plătit ca s-o scurtezi nu se calculează. Atunci rubrica de decizie rămâne goală, în loc să se umple cu o medie pe rețea.
Termen de livrare și ce e comandat
Furnizor, comenzi deschise și data de livrare observată. De ele depinde câte zile cumpără efectiv un cost suplimentar, iar acela e multiplicatorul în jurul căruia se învârte toată decizia.
Cum s-a calculat
Scanarea, fereastra și socoteala.
Cu cuvintele produsului însuși, din blocul pe care îl tipărește sub incident: scanarea parcurge rândurile zilnice ale fiecărui produs — vânzări, cost, stoc — și numește exact SKU-urile din spatele banilor, astfel încât fiecare articol își poartă propria contribuție în euro, nu o parte dintr-un total.
Rânduri zilnice pe SKU, de regulă o fereastră de 7 până la 28 de zile, în funcție de verificare. Verificările de tendință compară două ferestre alăturate de aceeași lungime. Cifra e săptămânală, pentru că aceea e perioada incidentului.
- marjă în pericol pe săptămână = vânzări săptămânale în pericol × marjă brută
- recuperabil = marjă în pericol pe săptămână × (1 − rata de substituție)
- cât valorează o zi câștigată = recuperabil ÷ 7 × zile câștigate
- Sincronizare POS / ERP
- product_sales_daily · inventory_daily
- scanare pe SKU
- incident, grupat pe magazin
- inventory_daily
- qty_in_stock
- product_sales_daily
- product_ext_id, revenue
Două lucruri pe care blocul acesta nu le netezește. Primul: costul nu apare printre coloanele citite de verificare. Tocmai de aceea playbook-ul merge pe o casă și un flux de stoc, și tot de aceea pasul cu marja de mai jos e cifra ta, nu a produsului. Al doilea: cele două ecrane nu se potrivesc. Pe 1 septembrie 2026 incidentul arăta ≈381 € pe săptămână la Granola artesanal. În același minut, întrebată despre același SKU, marql AI răspundea ~316,80 € pe săptămână — circa 53 € pe zi la o cerere medie zilnică de 9,6 unități și un preț de raft de 5,50 €, înmulțite cu șase zile în loc de șapte. Diferența e de vreo 65 € la o cifră de 381 €. Niciun număr nu e inventat, iar pagina nu va alege un favorit. Notează însă că o decizie de mărimea asta n-ar trebui luată pe o cifră care se mișcă cu o șesime, în funcție de ecranul pe care o citești.
Verifică pe cifrele tale
Cele trei ecuații de mai sus, cu câmpurile la vedere. Calculatorul pornește de la cifrele acestui playbook, așa că primul lucru pe care îl arată sunt cei 381 € din antet, transformați în numărul pe care se ia efectiv decizia. Schimbă orice câmp și socoteala te urmează.
- Marjă în pericol pe săptămână
- 223 €
- Merită plătit, cel mult
- 38 €
Două dintre cele patru câmpuri sunt presupuneri, nu citiri. Marja pornește de la 58,5 %, media combinată a acestui tenant, pentru că la acest SKU incidentul nu are coloană de cost; pune-o pe a ta. Rata de substituție pornește de la 40 %, pentru că o cifră plauzibilă e mai utilă decât un gol, și e singurul număr de aici pe care nimeni nu îl poate căuta fără date pe linii de bon. Calculatorul nu evaluează costul suplimentar: acela vine ca ofertă de la furnizorul sau curierul tău. Și nu știe dacă zilele introduse sunt zile de lipsă sau zile câștigate. Exact asta e modul de eșec 02.
Trei opțiuni, trei birouri diferite.
Cele trei acțiuni din acest playbook aparțin la trei perimetre diferite și niciunul nu le poate lua pe celelalte două. E neobișnuit, pentru că de regulă deciziile se adună într-un singur loc, și explică de ce un raft gol primește atât de des răspunsul pe care îl poate da cel mai apropiat om, nu pe cel corect. Produsul nu lasă asta pe seama obiceiului: fișa de comandă de mai jos poartă cantitatea, marcajul de timp al buffer-ului din care vine și propoziția „doar proprietarul sau directorul de operațiuni poate crea o ciornă de comandă”. Perimetrul se aplică, nu se sugerează.
Manager de magazin
Doar magazinele proprii. Singurul perimetru care deține un fapt pe care nu îl are nimeni altcineva: dacă raftul și depozitul se potrivesc.
- Contra-cazul 05: mersul în depozit și consemnarea a ceea ce s-a găsit acolo.
- Substituția la raft — încotro se îndrumă cererea și către ce SKU viu anume.
- Dacă referința poate fi vândută fizic: deteriorată, greșit etichetată, expirată.
Costul suplimentar de grăbire și transferul. Amândouă sunt cheltuieli făcute în afara acestui perimetru, contra unui beneficiu măsurat înăuntrul lui, și niciuna nu apare măcar în acest inbox.
Zilele dintre zeroul înregistrat și raftul reumplut. Și dacă zerourile fantomă raportate au rămas raportate.
Manager regional
Un grup de magazine. Primul perimetru care vede același SKU pe stoc la o adresă și lipsă la alta.
- Transferul, pentru că acesta e primul perimetru care îi vede ambele capete.
- Alegerea între mutare și așteptare — o comparație care trebuie să includă și ziua pe care o ia transferul.
- Care raft gol e problema rețelei și care e locală.
Achiziția care a creat golul și termenul față de care s-a comandat. Regiunea mută stocul pe care îl are deja; nu poate face să sosească mai mult.
Zilele de absență din grup și cât din ele s-au închis prin mutare, nu prin plata vitezei.
Proprietar
Toată rețeaua. Singurul perimetru care vede același magazin golindu-se iar și iar, nu un magazin golindu-se o dată.
- Costul suplimentar de grăbire: singura acțiune de aici care cheltuie bani ca să cumpere timp.
- Cantitatea de comandă și termenul din spatele modului de eșec 03 — cauza, nu simptomul.
- Decizia de a absorbi golul și de a o consemna ca decizie, nu ca scăpare.
Singurul fapt pe care îl deține cel mai mic perimetru: dacă paletul e în depozit. Orice cost suplimentar plătit pe un zero fantomă a fost aprobat aici și putea fi oprit doar la celălalt capăt.
Cost suplimentar cheltuit față de marjă recuperată. Și dacă magazinele golite de două ori s-au golit și a treia oară.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
Chisinau Central
54 000 €−0%−2%Balti Nord
39 900 €+2%−0%Soroca
39 500 €−16%−17%—Pe scurt
Acestea sunt cele trei perimetre pe care le aduce produsul, nu o afirmație despre cum ar trebui organizată o rețea. O rețea cu un birou central de reaprovizionare are un post pe care niciunul dintre cele trei nu îl descrie, iar playbook-ul nu îl va inventa. Suprapune-ți propriile titluri peste perimetre, nu invers. Și observă că aici acțiunea cea mai ieftină stă la cel mai mic perimetru — invers față de obișnuit, și tocmai de aceea se sare peste ea.
Tot ce e mai sus, pe un singur tabel.
Nimic din toate astea nu cere marql. Produsul automatizează scanarea zilnică pe toate SKU-urile și locațiile. Metoda în sine e trei decizii și vreo douăzeci de câmpuri, iar pentru un magazin se face de mână într-o după-amiază. Ia-o. Dacă socoteala îți schimbă în mod repetat ce ai fi făcut, acela e argumentul pentru automatizare.
E gol raftul, sau e gol registrul?
Contra-cazul 05 și modurile de eșec 02 și 03, adunate într-un singur arbore. Se parcurge înainte de orice discuție despre bani, pentru că trei dintre cele patru finaluri nu costă nimic.
A vândut acest SKU ceva de când cantitatea a trecut pe zero?
- DaGreșit e registrul, nu raftul. Găsește stocul, corectează cantitatea și consemnează cauza. Un zero fantomă neconsemnat revine în fiecare săptămână și costă de fiecare dată un cost suplimentar.
- NuRaftul chiar e gol. Continuă.
Se aplică vreunul dintre contra-cazurile din secțiunea 03 — epuizare intenționată, sezon încheiat, înlocuitor sub alt cod, referință care nu urma să revină?
- DaConsemnează care anume, cine a decis și când trebuie revizuit. Nu acționa. Consemnarea e cea care oprește lucrul ăsta să apară ca surpriză în fiecare săptămână.
- NuCererea e reală și neservită. Continuă.
De câte ori a ajuns acest magazin la zero în ultimele 30 de zile?
- De mai multe oriTratează tiparul, nu evenimentul. Compară cantitatea de comandă cu ritmul real al magazinului și termenul cu cel observat, înainte să cheltui ceva pe viteză. Acesta e modul de eșec 03.
- O datăUn eveniment izolat. Treci la partea 02.
Există același SKU pe stoc într-o locație destul de apropiată pentru transfer, fără s-o lase pe aceea descoperită?
- DaCompară transferul cu costul suplimentar din partea 03. Transferul ia și el o zi, iar acoperirea locației care trimite trebuie să reziste.
- NuAlegerea e între grăbire și absorbție. Mergi la partea 02.
Unul dintre cinci finaluri: corectezi cantitatea, consemnezi un motiv și nu faci nimic, repari cauza din amonte, transferi, sau pui preț pe așteptare în partea 02.
Cât valorează o zi de absență
Modul de eșec 01 pus pe hârtie: cele trei înmulțiri dintre cifra de pe ecran și cifra pe care se ia decizia. Fiecare rând e mai mic decât cel de deasupra, și exact în asta stă ideea.
- Vânzări săptămânale în pericol, așa cum le arată incidentul
- Direct din incident sau dintr-un export de vânzări. Până aici nu sunt necesare date de cost: verificarea care ridică alerta nu citește o astfel de coloană.
- Cererea medie zilnică și prețul de raft
- Notează-le pe amândouă. La SKU-ul din demo sunt 9,6 unități pe zi la 5,50 €, de unde vin cei ~53 € pe zi. Aceeași înmulțire arată și dacă cifra săptămânală de pe ecranul tău a fost calculată pe șase zile sau pe șapte.
- Vânzări săptămânale în pericol, puse de acord
- Cererea zilnică ori prețul, ori șapte. Dacă nu se potrivește cu ce a arătat incidentul, ai găsit aceeași nepotrivire pe care a găsit-o playbook-ul. Notează pe care o folosești și de ce, pentru că tot ce urmează o moștenește.
- Marja brută a SKU-ului
- Marja SKU-ului însuși, nu a categoriei și nu a rețelei. Dacă lipsesc prețurile de cost, oprește-te aici și ordonează după venit. O marjă estimată transformă un plafon într-o ghiceală cu virgulă.
- Marja în pericol pe săptămână
- Vânzări în pericol ori marja. Grăbirea recuperează asta, nu rândul de deasupra.
- Partea din cerere care se înlocuiește
- E o presupunere și pe fișă trebuie marcată ca atare. Fără date pe linii de bon nimeni nu o poate căuta. Produsele de bază cu un vecin apropiat pe raft se înlocuiesc masiv; o referință pentru care oamenii vin special aproape că nu se înlocuiește.
- Marja recuperabilă pe săptămână
- Marja în pericol ori unu minus partea care se înlocuiește. Împarte la șapte și înmulțește cu zilele pe care costul suplimentar le cumpără cu adevărat. Tocmai acel rezultat, nu rândul de aici, se compară cu costul suplimentar.
O singură cifră: cât costă cu adevărat o săptămână de raft gol, în marjă recuperabilă. Și rata zilnică dedesubt.
Merită cât costă sosirea mai devreme?
Bifurcația propriu-zisă. Trei opțiuni, o comparație și un al patrulea rând pe care mai nimeni nu-l scrie: și inacțiunea are un preț, adesea cel mai mic de pe pagină.
- Data de livrare fără intervenție
- Cea observată, nu cea contractată. Dacă ultimele trei livrări au întârziat, cea observată e cea reală.
- Data de livrare cu costul suplimentar plătit
- Confirmată cu furnizorul sau cu curierul, nu presupusă. O dată neconfirmată nu cumpără nimic.
- Zile câștigate cu adevărat
- Diferența dintre cele două rânduri de mai sus. Nu zilele deja petrecute fără stoc: acelea sunt pierdute la orice preț. Acesta e modul de eșec 02.
- Plafonul costului suplimentar
- Marja recuperabilă pe săptămână din partea 02, împărțită la șapte și înmulțită cu zilele câștigate. Orice ofertă peste acest rând pierde bani chiar și când funcționează. La SKU-ul din demo sunt circa 38 € pentru două zile, față de 381 € pe ecran.
- Costul suplimentar ofertat
- Costul total al sosirii mai devreme, cu tot ce adaugă ruta grăbită: încărcătură parțială, livrare în afara programului, șofer.
- Costul transferului, dacă e posibil
- Transportul, ziua pe care o ia și marja riscată la locația care trimite. Un transfer care golește alt raft a mutat problema, nu a rezolvat-o.
- Decizia și prețul ei
- Grăbire, transfer, înlocuire sau absorbție. Și numărul care a făcut-o cea mai ieftină dintre cele patru. Absorbția e și ea o decizie cu preț, iar scrierea acelui preț e ce o face decizie.
O acțiune aleasă împreună cu socoteala care a ales-o, și un preț consemnat pentru opțiunea neluată.
Fixează măsurarea înainte să acționezi.
Modul de eșec 05 pus pe hârtie. Singura parte cu termen: fiecare câmp se completează înainte de acțiune, pentru că odată știut rezultatul niciunul nu mai poate fi ales cinstit. Indicațiile spun ce cere registrul marql, așa că o fișă ținută la standardul acesta și produsul răspund la aceeași întrebare.
- Acțiunea, într-o propoziție
- Ce se face, pe ce SKU, în ce locație și la ce cost.
- Responsabil
- Un nume cu un perimetru care chiar poate duce acțiunea la capăt — secțiunea 07. Aici cele trei opțiuni sunt la trei perimetre diferite.
- Bază, înghețată acum
- Cifra față de care se va măsura efectul, scrisă și nerecalculată ulterior. Pe un tabel, înghețarea înseamnă să lipești valoarea, nu să lași o formulă care se va mișca.
- Fereastra de măsurare
- Date exacte, alese acum. Începe după ce trece vârful de după reaprovizionare, nu în timpul lui, și acoperă cicluri săptămânale întregi. Măsurarea peste vârf e modul de eșec 05.
- Metrica
- Zile fără stoc pe acest SKU în această locație. O singură metrică. A doua e felul în care îți alegi ulterior rezultatul convenabil. Venitul e o alegere proastă aici, pentru că se mișcă din motive pe care acțiunea nu le-a provocat.
- Control potrivit
- Locații comparabile care nu au primit acțiunea. marql nu declară un rând dovedit sub patru magazine de control potrivite. Fără ele cade pe volatilitatea proprie a unității, ceea ce e o afirmație mai slabă și se marchează ca atare.
- Ce ar anula fereastra
- O promoție pe SKU sau pe cel mai apropiat înlocuitor al lui, o schimbare de preț, o schimbare de furnizor, sau o a doua ruptură în interiorul ferestrei. La oricare dintre ele, verdictul cinstit e „neconcludent”, nu „dovedit”.
- Ce înseamnă fără efect și ce înseamnă mai rău
- Amândouă, scrise înainte să le știi. Aici „mai rău” chiar se poate întâmpla: un cost suplimentar plătit care a cumpărat mai puține zile decât s-a ofertat a dat bani degeaba.
Un rând care se poate închide în șase direcții: găsit, în măsurare, dovedit, fără efect, neconcludent, mai rău. Dacă ultimele trei sunt de neatins în varianta ta, primele trei nu valorează nimic.
Pe scurt
Asta e toată metoda. marql nu adaugă o ecuație mai bună. Rulează scanarea zilnic pe toate SKU-urile și locațiile, nu pe raftul pe lângă care a trecut cineva. Grupează rândurile pe magazin, ca o repetare să se vadă ca tipar și nu ca nouă incidente separate. Și ține registrul, ca un rând închis să nu poată fi redeschis pe tăcute și înfrumusețat. Socoteala de mai sus e aceeași în ambele cazuri, iar rata de substituție rămâne un număr pe care niciunul dintre noi nu îl poate măsura.
09 · Linia la care se oprește dovada
Venit în pericol
≠ recuperare dovedită.
381 € sunt vânzări săptămânale în pericol pe un SKU într-o locație. E cifra pe care o poartă incidentul însuși, vizibilă pe ecranul din capul paginii. Nu e o pierdere: o parte din cerere cumpără altceva în aceeași vizită și își câștigă marja oricum. Cât anume e singurul număr de aici pe care nimeni nu îl poate măsura fără date pe linii de bon. marql nu îl are, de aceea calculatorul îl cere în loc să îl afișeze.
Nu e nici marjă. Grăbirea recuperează marja brută a unităților care altfel nu s-ar fi vândut deloc, adică circa 223 € la marjele acestui tenant. Partea recuperabilă din ele, pe zilele pe care costul suplimentar le cumpără cu adevărat, e în jur de 38 €. Cifra de pe ecran și cifra pe care un achizitor pune mâna diferă de zece ori, mereu în aceeași direcție.
Și nu e un efect dovedit. Acela se înregistrează abia după ce acțiunea e executată, baza e înghețată, iar fereastra de control s-a închis dincolo de vârf. Când datele nu ajung sau un factor exterior a distorsionat rezultatul, registrul marchează efectul ca nedovedit. Tenantul demo își avansează propriul ceas, deci fiecare cifră de aici e un instantaneu, nu o constantă.
Ce face totuși produsul — iar ecranul de mai jos e cel mai limpede exemplu — e să tipărească condițiile lângă citire: cât din zi a trecut cu adevărat față de cât se aștepta la ora asta, și câte locații au raportat în general. O cifră de ritm fără aceste două rânduri nu se poate citi, iar majoritatea dashboard-urilor le omit pe amândouă.
De unde vin ecranele
Cele trei suprafețe prin care a trecut decizia
Vrei să vezi
euro pe care i-a găsit?
Demoul pornește de la casele de marcat și contabilitatea pe care le folosești deja. Lasă-ne datele și alege o oră.