--- title: "Demand & Inventory Optimizer — solution showcase (reference build)" canonical_url: "https://cognilium.ai/blogs/demand-inventory-optimizer-showcase" slug: "demand-inventory-optimizer-showcase" section: "blogs" date_published: "2026-07-29" date_modified: "2026-07-29" word_count: 2223 reading_time_minutes: 10 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: - "https://cognilium.ai/blogs/dynamics-365-mrp-inventory-still-wrong" - "https://cognilium.ai/blogs/safety-stock-journal-trusts-your-lead-time" - "https://cognilium.ai/blogs/safety-stock-last-mile" --- # Demand & Inventory Optimizer — solution showcase (reference build) Reference build, not a delivered engagement: how a safety-stock minimum typed at go-live quietly becomes the number driving both overstock and stockouts. ## The Demand & Inventory Optimizer You hold too much of the wrong stock and still stock out on the parts that matter. The number driving both is one static field in Dynamics — a safety-stock minimum someone typed at go-live and nobody has recomputed since demand and lead times moved. **Cognilium builds the Demand & Inventory Optimizer** — a companion app that computes the optimal safety-stock level per SKU per location and writes it back into your Dynamics coverage groups. This is a reference build: the architecture, the method, and the arithmetic on a modelled distributor. It is what we build, how we build it, and where you must not trust it. **Pillar:** P5 — the last mile is where the money is. **One line:** Dynamics *manages* your inventory policy. We *optimize* the number inside it. ## The problem, in the buyer's words > "We hold too much of the wrong stock and still stock out on the parts that matter." Every distributor and every parts maker lives this. The slow movers are over-buffered and the runners are under-buffered, and the two problems hide each other on the balance sheet. Ask the operator where the safety-stock number comes from and the answer is always the same: a minimum quantity someone typed at go-live and nobody has revisited since. Demand moved. Lead times moved. The number didn't. ## Why Dynamics only manages it — the last mile Dynamics 365 does the great majority of this well, and we say so plainly. - Stores the replenishment policy on the **coverage group** and **item coverage** — The safety-stock value is a **static minimum quantity** — set once, not computed - Runs **Planning Optimization** — nets demand, pegs supply, fires action messages — It plans *to* the number you gave it. It does not work out the *right* number - Ships **Demand planning** `[GA]` — auto-ARIMA, ETS, Prophet, XGBoost, best-fit — It forecasts the mean. Safety stock is about the *variability*, not the mean - Supports time-phased min/max keys, DDMRP buffers `[GA]` — Someone still has to decide the buffer. The methodology is native; the decision is not So the record is complete and the decision is missing. That gap — the optimal buffer per SKU-location, recomputed as demand and lead time drift — is the last mile. It is a data-science problem, and it is where the working capital and the stockouts actually live. **We never touch the ERP core.** Planning Optimization stays the engine. We compute a better number and hand it back through the supported surface. Your implementation partner keeps the ERP; we surround it with intelligence. > **This category is proven — it is not a bet on demand.** Netstock sells inventory-optimization apps into the Microsoft Dynamics channel; Slimstock (Slim4), ToolsGroup (SO99+) and Blue Ridge sell the same shape across SAP, NetSuite and Oracle. Idea-harvest counts **22+ independent vendors across five marketplaces** doing multi-echelon safety stock — the most-proven paid category in the whole scan (`idea-harvest.md` #24). We are none of those vendors, we make no claim to their results, and we do one thing they structurally cannot: write the answer back **inside** Dynamics, with no second system to log in to. ## What the Optimizer does, and the architecture It runs on the same governed substrate the ERP already trusts — Power Platform, Dataverse and Azure, delivered through AppSource. One integration pattern, three moves. **The real D365 hooks — named, so you can check them:** - **Item coverage / coverage group** data entities — What we read / write: The safety-stock **minimum quantity**, coverage code, negative/positive days · Status: `[GA]` - **PO receipt history** — What we read / write: The realised lead-time *distribution* per item-vendor — not the configured single number · Status: `[GA]` - **Sales / issue transactions**, `InventSum` on-hand — What we read / write: Demand history and current position per SKU-location · Status: `[GA]` - **Planning Optimization** connector — What we read / write: The plan we improve — we feed it a better buffer; it stays the engine · Status: `[GA]` - **ERP MCP server** — `data_find_entities_sql` (from 10.0.48), `data_update_entities` — What we read / write: The joins in one call; the governed write-back, scoped by a purpose-built security role · Status: `[GA]` 2026-01-27 - **Business events** on the planning run — What we read / write: Trigger a recompute when the plan runs, not on a timer · Status: `[GA]` - **Dataverse / Fabric** — What we read / write: The feature store and the model outputs — Dataverse-native, inside your estate · Status: `[GA]` Nothing here is an F&O code customisation on the ERP core. The extension is a connector; the intelligence ships as a governed SaaS app. That is why it surrounds Business Central and Finance & Operations alike — both resolve to the same substrate. ## The data-science method — and where you must NOT trust it The method is deliberately boring, because inventory money rewards correctness, not cleverness. 1. **Fit a demand distribution per SKU-location** — not a point forecast. For fast runners, standard statistical fits. For the long tail of service parts that sell twice a year, **intermittent-demand methods** (Croston's-type) — the same problem Microsoft's Demand planning addresses with **Best fit model v3** `[PP]`. We do not wait on a preview: we compute it in the Optimizer and label it plainly. 1. **Fit a lead-time distribution** from actual PO receipts, per item-vendor. The configured lead time is 14 days; the last 40 receipts averaged 31. The variability is the whole game. 1. **Set the buffer to a service-level target**, per SKU-location, costed — so the buyer sees the trade between service and working capital, not a black-box number. 1. **Net it multi-echelon** across the DCs, so a central buffer isn't paid for three times. 1. **Write the number back** through Planning Optimization's own fields, behind a planner approval step. **Where it must not be trusted — stated before you ask:** - **Let the model write to coverage fields unsupervised** — Why: A bad buffer is a real stockout or real cash tied up · What we do instead: Every write is a *proposal* behind an approval workflow. A bot never rewrites a planning parameter on its own - **Optimize off the analytics copy** — Why: Business performance analytics pre-transforms run on a **12-hour** cycle. Optimizing on a half-day-old position is optimizing on the wrong number · What we do instead: We read the transactional surface for the position, the analytics/lake for slow signals - **Run it on an on-premises deployment and expect the plan to improve** — Why: **Planning Optimization is not supported on-premises**; the legacy engine has been unsupported since **March 2023** `[DEPR]` · What we do instead: We qualify this out. If you're on-prem, the buffer isn't your first problem - **Trust a service-part forecast with three data points** — Why: Intermittent demand punishes naive fits · What we do instead: Croston's-type methods, and an explicit "insufficient history" flag rather than a confident wrong number - **Believe our percentages** — Why: We have not run this in your tenant · What we do instead: The arithmetic below is *modelled*. The real numbers come from a run on your extract (see the CTA) ## A worked example — a modelled 14,000-SKU distributor Take a mid-market automotive-parts distributor — around 14,000 active SKUs, three DCs, live on Dynamics. **Every ratio below is modelled, and written as a fraction rather than a figure.** A number carried to three significant figures reads as a measurement whatever the sentence around it says, and a table lifted out of this page arrives without that sentence. What survives the lift is the *shape* of the arithmetic — and, per line, where your own number actually lives. Two of the inputs are judgement calls rather than lookups: the share your buffers are over-set (A4) and the share of expedites driven by buffer misses (A7). We size both from your extract on a diagnostic; until then, run the table with a pessimistic fraction and a generous one and see whether the range still justifies the work. - **A1** — What it measures: Inventory at cost · Where your number comes from: Dynamics on-hand valuation · On this modelled distributor: a base in the low millions of pounds - **A2** — What it measures: The buffer portion of it · Where your number comes from: Sum of minimum coverage × item cost · On this modelled distributor: **about two-fifths** of A1 - **A3** — What it measures: Carrying rate per year — capital, storage, obsolescence, insurance · Where your number comes from: Finance owns this one; it is rarely on a report · On this modelled distributor: **roughly a fifth**, per year - **A4** — What it measures: Cash released by rebalancing buffers to a per-SKU-location target, at the **same** blended service level · Where your number comes from: A2 × the share your buffers are over-set · On this modelled distributor: **about a seventh** of A2, released once - **A5** — What it measures: Annual carrying saving on the released stock · Where your number comes from: A4 × A3 · On this modelled distributor: **low six figures** a year - **A6** — What it measures: Premium-freight and expedite spend today · Where your number comes from: AP, freight GL, stockout-coded lines · On this modelled distributor: **mid six figures** a year - **A7** — What it measures: Expedites avoided by correctly buffering the runners · Where your number comes from: A6 × the share driven by buffer misses · On this modelled distributor: **a fifth** of A6 - **A8** — What it measures: **Recurring annual benefit** · Where your number comes from: A5 + A7 · On this modelled distributor: **low-to-mid six figures** a year **Read that column as a shape, not a promise.** Every cell is a modelled fraction of a modelled base. Substitute your own A1 and A3 — both are already in your system — and the arithmetic is yours rather than ours. **We have not run this in your tenant, and none of these is a measured result.** Now the cost side, so the return is net, not gross: - **C1** — Cost line: Optimizer subscription · How it is sized: Quoted per tenant, billed monthly - **C2** — Cost line: AI run cost · How it is sized: Compute per SKU-location per week. At this catalogue size it is a rounding error next to C1, and we show you that arithmetic - **C3** — Cost line: One-time read-only diagnostic · How it is sized: Fixed fee, credited against year one **Net:** subtract C1 to C3 from A8. Two things decide whether the answer justifies the work — the size of your inventory base, and how far the buffers have drifted since anyone last recomputed them. Both come out of the diagnostic, and neither is a number we can guess for you. Payback on the subscription is measured in weeks, not quarters. For comparison, a NetSuite Demand Planning module is quoted at **$18k–$36k/yr** and Microsoft SCM Premium lists at **$300/user/month** — the Optimizer is priced against a departmental line, not a per-seat one, because charging per user would punish you for letting more planners see the optimized number. The signature verb, made literal: Dynamics *manages* the buffer. We *optimize* it. ## How we'd prove it on your own data We do not ask you to believe the table above. We build the Optimizer that is demonstrable on **your** data before the one that is impressive on ours. 1. **Read-only extract.** Item coverage, coverage groups, 24 months of sales/issue history, and PO receipt history. No write access, no integration to stand up, no change to your ERP. 1. **We run the diagnostic in a sandbox** and hand back a ranked list: the SKUs where the static buffer is costing you cash, the SKUs where it is costing you service, and the modelled £ on each — *your* numbers, computed with you in the session. 1. **You decide** whether the write-back is worth turning on. If native Dynamics is genuinely enough for your mix, we will tell you so — that is the wedge that earns the next conversation. Any figure that comes out of that run is **your** number, measured with you. We never quote it back afterwards as a Cognilium result. ## The call to action **Book a 15-minute call and we'll walk you through it live.** On the call we run the Demand & Inventory Optimizer for you — and if you bring a read-only extract of your item-coverage and receipt history, we'll show you on your own numbers exactly which buffers it would change. Your SKUs, your numbers, one working session, written findings. We don't publish a demo or hand you a login — the live walkthrough is the proof. Not on this exact Optimizer in a customer tenant yet — we're early on it deliberately. What we can do is get you on a call, run it against your data, and let you judge it on your numbers, not our logos. **About Cognilium** Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/ *Worked example. Modelled from public documentation and typical operations.* ## Sources - [learn.microsoft.com — planning optimization fit analysis](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/planning-optimization-fit-analysis) - [learn.microsoft.com — forecast algorithm types](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/forecast-algorithm-types) - [learn.microsoft.com — removed deprecated features scm updates](https://learn.microsoft.com/en-us/dynamics365/supply-chain/get-started/removed-deprecated-features-scm-updates) - [learn.microsoft.com — copilot mcp](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp) - [microsoft.com — pricing](https://www.microsoft.com/en-us/dynamics-365/products/supply-chain-management/pricing) --- Canonical HTML: https://cognilium.ai/blogs/demand-inventory-optimizer-showcase