Освободете оборотния капитал от свръхнормативния запас.
marql намира запаса над целевото покритие по SKU и обект, оценява капитала в излишъка по вашите собствени себестойности и го превръща в план с отговорник, срок и дата за проверка.
Открито
2 728 €
капитал по себестойност
- приоритет в €
- изчислено от изходните данни
- ефект само след измерване
Екрани от демо тенанта Maison Marché. Интерфейсът се показва на английски във всички пазари; цифрите в него са генерирани.
Продава се. Запасът остава свръхнормативен.
В Maison Marché минералната вода не е мъртва наличност: последната продажба е днес. Но покритието е стигнало 110 дни при целеви буфер от 7 дни. marql изчисли излишъка спрямо буфера плюс срока на доставка, оцени по себестойност затворения в него капитал и предложи вариантите за действие.
- 110
- дни покритие
- 7
- целеви буфер
- 2 728 €
- капитал по себестойност
- 35
- дни отклонение
От отклонение до измерен ефект.
Сигналът, диагнозата, управленското действие и оценката на резултата са един процес — без разрив между анализа и това, което някой наистина прави.
Свръхзапасът се вижда преди затварянето на периода.
Ежедневната проверка по SKU × обект намира къде дните покритие надхвърлят целта и подрежда отклоненията по капитала, който всеки излишък държи.
Автоматичен мониторинг · SKU × обект
Показва причината за отклонението и вариантите за въздействие.
marql разделя мъртвата наличност от продаващ се SKU с прекалено покритие, като чете скоростта на продажби, метеорологичния фактор и наличността в другите обекти. След това предлага: спиране на зареждането, ускоряване на продажбите с промоция, преместване между обекти или промяна на прага.
7 прочетени фактора · изчислението е проверено спрямо данните
Препоръчаното количество идва от модел за наличности.
ShelfSense чете текущата наличност, средното дневно потребление (ADU), срока на доставка и целевия буфер. AI обяснява логиката; количеството излишък и капиталът в него се изчисляват детерминистично.
Наличност 4 625,6 · прогноза 39,2 единици/ден
Ефектът се признава само след контролния период.
След потвърждаване на действието marql фиксира базовия период и прозореца на измерване. Impact Ledger държи разделени шест състояния — «открито», «измерва се», «доказано», «без ефект», «неубедително» и «по-лошо» — и замразява оборота, спрямо който се мери ефектът, в момента на потвърждаване на решението, така че резултатът не може да бъде завишен после.
Базов период · контрол където има · история на промените
110 дни може да е верният отговор.
Изчислението по-горе не се оспорва: 4 076,8 единици са над целевото покритие, а капиталът в тях се оценява на 2 728 € по себестойност. Оспорва се дали това е грешка. В поне пет обичайни ситуации покритието е високо умишлено, а който все пак действа по сигнала, разрушава решение, което някой вече е взел правилно.
Сезонно натрупване
Купувате сезона, не седмицата. Покритие, измерено спрямо норма от 7 дни в средата на натрупване за пик след шест седмици, е аритметично вярно и операционно безсмислено — запасът е пред търсенето, не след него.
Същото SKU, същите седмици миналата година: ако темпото тогава е било няколко пъти по-високо от сегашното, покритието е натрупване. Ако миналата година изглежда като тази, не е.
Минимална заявка на доставчика
Когато MOQ е един палет, а обектът продава четиридесет единици на седмица, най-малката заявка, която доставчикът приема, вече е единадесет седмици покритие. С покупката няма нищо нередно. Нормата е писана за SKU-та, които могат да се заявяват в количеството, което реално ви трябва.
MOQ, разделено на средното дневно потребление. Ако само това надхвърля нормата, никоя приемана от доставчика заявка не може да я спази и нормата е това, което трябва да се промени.
Покупка при заключена цена
Потвърдено покачване, промоция при доставчика или валутна експозиция могат да направят покупката напред по-евтина от покупката до покритие. Запасът не е бездеен капитал; той е хеджиране с известна печалба и дата.
Икономията на единица спрямо разхода за държане на единица за периода на държане. И дали решението е записано някъде другаде освен в паметта на купувача — незаписано хеджиране не се различава от презаявка.
Предварително натрупване за планирана промоция
Покритие преди кампания, която има дата, механика и прогноза, не е излишък. То е кампанията. Сигналът е ранен, не грешен.
Промоция в календара, чиято прогноза изчерпва покритието, и назован отговорник за остатъка, ако не се продаде.
Умишлено покритие срещу риск от доставка
SKU с един единствен източник, забавяне на митница, доставчик, който вече два пъти не е спазил срок — допълнителните седмици купуват наличност, а липсата на основен артикул обикновено струва повече от държането му.
Дали срокът за доставка в системата е договореният или реално наблюдаваният. Норма, настроена по договор, който никой не спазва, всяка седмица ще отчита предпазливостта като разхищение.
Накратко
Нито един от тези случаи не връща парите: капиталът наистина е блокиран и в петте, и това си струва да се знае. Променя се само отговорът: «запазваме, и ето защо», не «освобождаваме». marql може да разпознае причината само там, където причината е в данните — промоционален календар, количество на заявка, наблюдаван срок за доставка. Където я няма, SKU-то се отбелязва, купувачът презаписва решението, и точно това презаписване е полезният запис.
Сигналът беше верен. Решението пак се провали.
Пет начина, по които решение за свръхнормативен запас се проваля, след като отклонението вече е потвърдено, в реда, в който се случват: погрешно прочетена причина, погрешна посока, погрешна цена, погрешна корекция и погрешно осчетоводяване. Те са конструирани, не наблюдавани — зад тях не стоят цифрите на никоя верига.
Едно действие за мъртъв запас и за бързо SKU
Два реда стоят един до друг в същия списък, и двата над 100 дни покритие. Едното не е продало единица от шест седмици. Другото продаде тази сутрин. Намалението разпродава първото и подарява маржа на второто, което щеше да се продаде на пълна цена — по-бавно, отколкото искахте, но на пълна цена. Спирането на зареждането решава второто и не прави нищо за първото, защото няма нищо заявено.
Прочетете причината, преди да изберете действието. Дата на последната продажба, изчерпване в рамките на прозореца и дали има нещо заявено: три полета, които разделят спряло SKU от свръхпокрито, и които сочат противоположни действия.
Прехвърляне към обект, който също не може да продаде
Излишъкът е реален и корекцията изглежда очевидна — преместете стоката в обект, който държи същото SKU. Само че получаващият обект е на 40 дни спрямо същата норма от 7 дни; той просто е по-малко очебийно погрешен. Стоката пристига, сигналът при подателя изгасва, а същият капитал остава блокиран един адрес по-нататък, вече с добавена цена на трансфера.
Трансферът се брои за корекция само ако собственото покритие на получаващия обект остава в неговата норма, след като стоката пристигне. Това е търсенето на този обект, не средното за мрежата. Ако нито един обект не издържа теста, това е проблем на цената или на заявката, не на разпределението.
Намаление, което струва повече от държането
Отбив, достатъчно дълбок да разпродаде четири хиляди единици за две седмици, подарява повече брутна маржа, отколкото излишъкът е струвал, за да се държи. В играта са две различни числа — капиталът в излишъка и колко струва на седмица да стои там — и отбивът трябва да победи второто, не първото. Спрямо капитала почти всяко намаление изглежда оправдано. Спрямо седмичния разход за държане, повечето дълбоки не са.
Сравнете подарената маржа с разхода за държане за периода, в който иначе бихте държали стоката, плюс риска от бракуване при изтичане на срок. При SKU с дълъг срок и без дата на годност «не правим нищо» често е най-евтиното налично действие.
Вдигане на прага вместо отмяна на заявката
Нормата е 7 дни, покритието е 110, а най-бързият начин сигналът да спре е да решите, че нормата е била грешна. Понякога е била — това е предходната секция. Но когато нормата е била вярна, преместването ѝ превръща проблем на заявката в проблем на отчетността: капиталът остава точно там, където беше, сигналът спира да идва, а следващата презаявка е невидима.
Промяната на прага е законен изход само когато е обоснована от търсене, срок за доставка или количество на заявка, и само когато остави запис кой я е сменил, от каква стойност и защо. Ако нормата се премести, а отворената заявка не, нищо не е решено.
Осчетоводяване на икономията преди затварянето на прозореца
Действието е изпълнено, покритието спада и 2 728 € се записват като възстановени. После се оказва, че седмицата, в която стоката се раздвижи, е седмицата, в която конкурент затвори за ремонт, или че гореща вълна продаде водата без чужда помощ. Приписването на това на решението надува регистъра, а всяка следваща записана цифра наследява грешката.
Базовият период и прозорецът на измерване се фиксират при потвърждаване на действието, никога не се избират, след като резултатът е известен. Impact Ledger трябва да има право да отговори «без ефект» и «недостатъчно данни» — регистър, който казва само «доказано», не измерва нищо.
Накратко
Нито един от петте не е грешка в аритметиката — сигналът беше верен във всички. Четири са погрешно действие, избрано от вярно число, а петият е вярно действие, записано нечестно. Затова съществуват секциите от двете страни на тази: една пита дали числото значи това, което изглежда, другата казва кой има право да действа по него.
Започнете с най-важното
Кои SKU затварят оборотен капитал, без да се въртят достатъчно бързо?
Има ли аномалии през последните 7 дни?
1 открита аномалия — няма активни сигнали.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01Къде е концентриран свръхзапасът — по SKU, категория и обект?
- 02Мъртва наличност ли е, бавнооборотен SKU или временен излишък?
- 03Къде спираме зареждането, къде намаляваме цената, къде промотираме, къде местим?
- 04Кои обекти могат да поемат SKU-то според търсенето и собствената си наличност?
- 05Колко оборотен капитал може да се освободи, без да се увеличат липсите на рафта?
- 06Направете плана: действие, отговорник, срок и дата за проверка.
Какво е нужно, за да се изчисли излишъкът.
Продажби по SKU × обект
Количество, приход, дата на последната продажба, обект и категория.
Наличност + себестойност
Без себестойност излишното количество може да се преброи, но затвореният в него капитал не може да се оцени — затова колоната с пари остава празна, а не оценена.
Срок на доставка + стока в заявка
Доставчик, отворени заявки, разпределителен център, срок на годност и кои премествания между обекти са реално възможни.
Как е изчислено
Сканирането, прозорецът и аритметиката.
Сканиране на ниво SKU обхожда дневните редове по продукт — продажби, себестойност, наличност — и назовава точно SKU-тата зад сумата, така че всяко носи собствения си дял, а не част от общо число.
Дневни редове по SKU в прозорец от 7–28 дни, като дължината зависи от проверката. Проверките за тренд сравняват два съседни прозореца с еднаква дължина.
- излишни единици = наличност − средно дневно потребление × (срок на доставка + целеви буфер)
- капитал в излишъка = излишни единици × себестойност за единица
- POS / ERP синхронизация
- product_sales_daily · inventory_daily
- SKU сканиране
- инцидент
- inventory_daily
- qty_in_stock, cost_value, category_name
- product_sales_daily
- items_count, cost, category_name
Двете уравнения по-горе възпроизвеждат екраните точно. Дните покритие не следват от тях: те не са наличността, разделена на прогнозата, отпечатана до нея, защото проверка за отклонение и модел за наличности четат потреблението в различни прозорци на същите дневни редове. Затова блокът отпечатва модела, а не едно деление — и затова числото, което получава, е капитал, оценен по себестойност, а не разход. Колко струва на седмица държането на този капитал е отделно число, и точно него трябва да победи едно намаление.
Проверете на вашите числа
Двете уравнения по-горе, с полетата на показ. Отваря се на данните на този плейбук, така че първата цифра, която показва, е тази от заглавието — променете което и да е поле и аритметиката следва.
- Излишни единици
- 4 076,8
- Капитал в излишъка
- 2 728 €
Не изчислява дните покритие и не изчислява колко струва на седмица държането на запаса. Първото иска прозореца на потреблението, който тази страница не е фиксирала; второто иска ставка за държане, а измислянето на такава, за да изглежда калкулаторът завършен, е точно видът число, което този плейбук съществува, за да откаже.
Действието има нужда от име. Името следва обхвата.
Цикълът завършва с действие, което има отговорник, срок и дата за проверка — а отговорникът е частта, която страницата оставяше празна. Кой точно се оказва въпрос не на старшинство. Какво може да реши една роля е ограничено от това какво вижда тя, а marql доставя три обхвата, които виждат различни неща: една и същата сутрин слага свръхзапас в един inbox и не го слага в друг.
Мениджър на обект
Само собствените обекти и част от отворените инциденти на мрежата. Това е и единственият обхват, който получава кохортни персентили — къде стоят маржът и средният бон на всеки обект спрямо анонимна мрежа от сравними обекти.
- Истината на място: дали стоката е физически там, дали може да се продаде и дали е в състоянието, в което системата я смята.
- Изпълнението на намаление или на едно рамо от прехвърляне, след като дълбочината и посоката са определени.
- Повдигането на контра-случай: промоцията, която никой не е записал, палетът, който не се разделя, доставката, дошла два пъти.
Прехвърлянето, дълбочината на намалението и прагът. Всяко от трите иска число извън този обхват — най-ясно прехвърлянето, чийто цял тест е как изглежда покритието на получаващия обект след това. А този обект не е в този inbox.
Дали покритието в собствените обекти се връща в нормата и дали повдигнатият контра-случай се е потвърдил.
Регионален мениджър
Група обекти, която носи инциденти, невидими за обхвата на обекта под нея — включително, в демо тенанта, свръхзапас в обект извън списъка на този мениджър на обект.
- Прехвърлянето, защото това е първият обхват, който вижда двата му края.
- Изборът между преместване на стоката и намаление — сравнението, на което стъпва режим на провал 02.
- Кой излишък на обект е проблем на мрежата и кой е локален.
Покупката, създала излишъка, и самата норма там, където се задава централно. Един регион може да пребалансира стока, която вече държи; не може да я раз-заяви.
Покритието в групата и колко от излишъка се е преместил, вместо да бъде намален в цената.
Собственик
Цялата мрежа, без кохортен блок — на този обхват не остава с какво да се сравняваш освен със себе си.
- Спирането на зареждането и отмяната на заявеното: единствените действия, които стигат до причината, а не до симптома.
- Прагът и записът кой го е преместил, от каква стойност и защо — режим на провал 04 е точно това, което става без този запис.
- Честността на регистъра: решението да не се записва икономия преди затварянето на контролния прозорец.
Точно това, към което този обхват все пак посяга — преценката дали конкретен палет в конкретен склад може да се продаде. Това е единственият факт, който най-малкият обхват държи, а най-големият не.
Освободеният оборотен капитал в мрежата и дали същото SKU се връща следващото тримесечие.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
Sofia Center
54 000 €−0%−2%Varna Mall
39 900 €+2%−0%Plovdiv East
39 500 €−16%−17%—Накратко
Това са трите обхвата, които продуктът доставя, а не твърдение как трябва да е организирана една верига. Верига с отдел покупки има място, което никой от трите не описва — category buyer притежава заявката така, както не я притежава никоя роля в обект — и този плейбук няма да измисля това място. Наложете собствените си длъжности върху обхватите, а не обратното: обхватът е това, което ограничава решението, и длъжност, която не вижда получаващия обект, не притежава прехвърлянето, както и да се нарича.
Всичко по-горе, в една таблица.
Нищо от това не се нуждае от marql. Сканирането, подреждането и регистърът са това, което продуктът автоматизира; методът отдолу са четири решения и около две дузини полета, и работи на хартия. Вземете го. Ако го въртите на ръка едно тримесечие и аритметиката продължава да си струва следобеда, който отнема, това е аргументът за автоматизация — а ако не си струва, сте похарчили следобед, не абонамент.
Мъртво е или само свръхпокрито?
Режим на провал 01 е едно действие, приложено към два различни проблема. Три полета ги разделят, и трите са в един експорт на продажби.
Кога това SKU се е продало последно в този обект?
- Не в рамките на срока на доставкаТретирайте го като мъртва наличност. Зареждането не е лостът — няма какво да се спира. Минете на част 03 и сравнете намаление с бракуване.
- Наскоро, с постоянно темпоСвръхпокрито е, не мъртво. Продължете.
Има ли още нещо заявено или в път?
- ДаТова е причината. Отменете или спрете първо нея — всяко друго действие лекува симптома, а следващата доставка го връща.
- НеИзлишъкът вече е на рафта. Продължете.
Прилага ли се някой от контра-случаите от секция 03 — натрупване, минимална заявка, заключена цена, планирана промоция, риск от доставка?
- ДаЗапишете кой, кой е решил и кога да се преразгледа. Никакво действие. Записът е това, което спира случая да идва като изненада всяка седмица.
- НеПродължете.
Има ли обект, чието собствено покритие остава в нормата му, след като получи излишъка?
- ДаПрехвърлете. Проверете покритието на получаващия обект след преместването, не средното за мрежата — това е режим на провал 02.
- НеРазпределението няма да реши това. Минете на част 03.
Един от пет края: отменяте заявката, прехвърляте, намалявате цената, бракувате, или записвате причина и не правите нищо.
Достижима ли е нормата въобще?
Контра-случай 02 във вид на работен лист. Един ред на клас SKU, не на SKU — отговорът е един и същ за всичко, което купувате на палет.
- Средно дневно потребление
- Единици на ден за прозорец, на който вярвате. Напишете прозореца до числото: без него числото не значи нищо.
- Срок на доставка
- Наблюдаван, не договорен. Ако последните три доставки са закъснели, наблюдаваният е реалният.
- Целеви буфер
- Дните покритие, които искате над срока на доставка. Той плюс срокът е това, спрямо което се мери излишъкът.
- Минимална заявка
- Най-малкото количество, което доставчикът реално приема, в същите единици като потреблението.
- MOQ ÷ средно дневно потребление
- Дните покритие, които най-малката законна заявка вече създава, преди някой да е презаявил каквото и да е.
- Достижима ли е нормата?
- Сравнете реда по-горе със срока на доставка плюс буфера. Ако е по-голям, никоя приемана от доставчика заявка не може да спази нормата — и нормата е това, което трябва да се промени, не купувачът.
Или норма, за която можете да търсите отговорност от някого, или норма, за която вече знаете, че е невъзможна и трябва да спре да вдига сигнали.
По-евтино ли е намалението от държането?
Режим на провал 03 във вид на работен лист — сравнението, което се пропуска, защото спрямо капитала всяко намаление изглежда оправдано.
- Единици над нормата
- Наличност минус средно дневно потребление по (срок на доставка плюс буфер), от част 02.
- Капитал в излишъка
- Тези единици по себестойност. Това е числото, с което намалението НЕ се сравнява.
- Разход за държане на седмица
- Колко струва седмично държането на излишъка — капитал, площ, застраховка, липси. Ако нямате ставка под ръка, напишете тази, която приемате, и я маркирайте като допускане.
- Седмици, колкото иначе бихте го държали
- При текущото потребление, колко време докато излишъкът се изчерпи сам.
- Разход за държане за този хоризонт
- Седмичният разход по седмиците. Това е числото, което намалението трябва да победи.
- Подарена маржа
- Отбив на единица по единиците, които очаквате да раздвижите, при дълбочината, която обмисляте.
- Риск от бракуване
- Нула при SKU с дълъг срок и без дата на годност. При всичко перишабилно — единиците, които вероятно ще изтекат, по себестойност.
Ако подарената маржа надхвърля разхода за държане за хоризонта плюс риска от бракуване, „не правим нищо“ е по-евтиното действие — и си струва да се запише като решение, а не като пропуск.
Фиксирайте измерването, преди да действате.
Режим на провал 05 във вид на работен лист, и единствената част със срок: всяко поле тук се попълва преди действието, защото щом резултатът е известен, никое от тях не може да бъде избрано честно. Подсказките казват какво изисква самият регистър на marql, така че таблица, водена по този стандарт, и продуктът, воден по него, отговарят на един и същ въпрос.
- Действието, в едно изречение
- Какво се прави, на кое SKU, в кои обекти.
- Отговорник
- Име, с обхват, който реално вижда какво иска действието — секция 07.
- База, замразена сега
- Числото, спрямо което ще се мери ефектът, записано и непреизчислявано после. marql го замразява в момента на потвърждаване на решението; в таблица замразяване значи да поставите стойността, а не да оставите формула, която ще се движи.
- Прозорец на измерване
- Точни дати след действието, избрани сега, а не когато числата започнат да изглеждат добре. Редовете в регистъра на marql вървят около четири седмици — достатъчно да поемат цели седмични цикли.
- Показателят
- Дни покритие на това SKU в тези обекти. Един показател — вторият е начинът, по който благоприятен резултат се избира след факта.
- Съпоставени контролни обекти
- Сравними обекти, които не получават действието. marql не обявява ред за доказан при по-малко от четири съпоставени контролни обекта; без такива въобще пада на собствената волатилност на единицата — по-слабо твърдение, което заслужава да бъде обозначено като такова.
- Прагът, който бие шума
- Тестът на marql е Student-t предиктивен интервал при едностранно α = 0,10 спрямо тези контроли. В таблица честният еквивалент е праг, записан преди да погледнете — всичко решено после е предпочитание, не резултат.
- Какво би анулирало прозореца
- Промоция, покриваща повече от половината от него, промяна на цена, промяна на доставчик, липса на стока или скок на отбивите. Всяко от тях и честната присъда е неубедително, не доказано.
- Какво се счита за „без ефект“ и какво за „по-лошо“
- И двете, записани преди да ги знаете. Протокол, който не може да излезе отрицателен, не мери нищо.
Ред, който може да се затвори в шест посоки — открито, измерва се, доказано, без ефект, неубедително, по-лошо. Ако последните три са недостижими във вашата версия, първите три не си струват.
Накратко
Това е целият метод. Това, което marql добавя, не е по-добро уравнение: върти сканирането всеки ден по всяко SKU и всеки обект, а не по това, което някой е забелязал, подрежда отклоненията по капитала в тях, за да отиде следобедът при най-голямото, и води регистъра така, че затворен ред да не може тихо да бъде отворен и „подобрен“. Аритметиката по-горе е същата и в двата случая.
09 · Границата на доказаното
Потенциал за освобождаване
≠ доказан ефект.
2 728 € е капиталът, който стои в запаса над целевото ниво, оценен по себестойност. Това не е колко струва на седмица държането на този запас, не е реализирана икономия и не е ROI на marql.
Доказан ефект се записва само след изпълненото действие, базовия период и затварянето на контролния прозорец. Ако данните са недостатъчни или резултатът е изкривен от външен фактор, Impact Ledger отбелязва ефекта като недоказан.
Откъде са екраните
Четирите повърхности, през които мина решението
Готови ли сте да видите
намерените евро?
Демото се води спрямо касите и счетоводството, които вече използвате. Оставете данните си и изберете час.