Inventory Manager

I run a layered approach built on ABC classification. A-items, the roughly 20% of SKUs that drive most of the value, get counted weekly. B-items get counted monthly, and C-items quarterly. On top of that cadence, I set a variance threshold: any count that comes back more than 2% off triggers a root cause investigation before we adjust the system. I have managed catalogues of over 8,000 SKUs this way and held accuracy above 98% for two years running. The other half of the job is discipline at the point of transaction: mis-scanned receipts and un-logged returns cause more drift than theft does in most warehouses I have worked in, so I spend real time training floor staff on scanning habits, not just counting more often.

A cycle count is a rolling, partial count done on a schedule, usually organised by ABC classification or by location, so the whole warehouse gets covered over weeks without ever stopping operations. A full physical count freezes all transactions and counts every SKU on a single day, which is disruptive but gives you a clean, complete baseline. I use cycle counts as the everyday accuracy mechanism and reserve a full physical for year end close, a system migration, or after a discrepancy pattern that cycle counts cannot fully explain. In my last role we moved from an annual full count to quarterly cycle counts covering the entire catalogue, which cut our shrinkage variance in half because problems got caught within weeks instead of once a year.

I start with historical sales data segmented by SKU and location, then layer in seasonality, promotional calendars, and any known supply constraints from procurement. For fast-moving items I use a rolling 13-week trailing average adjusted for trend, and for seasonal categories I compare year over year patterns rather than recent weeks alone. I set safety stock based on lead time variability and desired service level, not a flat buffer across every SKU. I also build in a manual override step: if marketing has a campaign planned or a supplier flags a delay, the forecast gets adjusted before it becomes a purchase order. Forecasting that ignores context from other teams tends to be technically correct and operationally wrong.

I use forecasting software with built in machine learning models to generate a first pass demand forecast, especially for high volume SKUs where patterns are stable enough for the model to add real value. I also use anomaly detection tools that flag unusual shrinkage patterns, like a location where losses spike outside the normal range, which helps me target audits instead of counting everything equally. Where I still rely on my own judgment is supplier negotiations, safety stock decisions for new or highly seasonal products with no clean history, and any adjustment that depends on context the software cannot see, like a supplier telling me a shipment will be two weeks late. I treat the forecast as a starting point I am accountable for, not an answer I forward without review.

During a cycle count I found that our system showed 340 units of a fast-moving SKU on hand, but the physical count came back at 210. That is a 38% variance on an item that represented a meaningful share of weekly revenue. I froze further picks on that SKU and pulled the transaction history for the prior six weeks. The root cause turned out to be a receiving error: a pallet had been logged under the wrong SKU code because two products shared a similar barcode prefix. I corrected the system count, reconciled the mislabelled SKU, and reran the numbers for both items to check for knock-on errors. To prevent a repeat, I added a secondary barcode check at receiving for any SKU pair with overlapping prefixes, which eliminated that specific error type going forward.

Ahead of our busiest quarter, forecasted demand for our top ten SKUs was running about 60% above the same period last year based on early sell-through data. I worked with procurement to move up purchase orders by three weeks and negotiated a partial pre-shipment with our main supplier to cover the gap. I also increased cycle count frequency on those SKUs from monthly to weekly during the peak window, since a stockout or a bad count matters far more when volume is high. We ended the quarter with a 99.2% in-stock rate on the top ten SKUs, against a company average closer to 95% for the rest of the catalogue, and I did not carry meaningful excess into the following quarter.

Procurement wanted to place a large order to hit a supplier's volume discount tier, but the quantity would have pushed us to nearly four months of coverage on a SKU with a shelf life risk due to a packaging change coming later that year. I put together a short comparison showing the discount saved us about 1,800 pounds, against a potential write-off risk on unsold units worth several times that if the packaging change landed before we sold through. I proposed a smaller order at a slightly lower discount tier plus a backup purchase option closer to the deadline. Procurement agreed once they saw the exposure laid out with numbers rather than as a general concern, and we avoided the write-off entirely when the packaging change did land on schedule.

I have worked in SAP for purchase order management and inventory valuation, NetSuite for day to day stock movement and cycle count scheduling, and Fishbowl at a smaller company where we needed tighter integration with QuickBooks. In SAP I built out reorder point rules at the material master level so the system flagged replenishment automatically instead of relying on manual review. In NetSuite I set up saved searches to surface any SKU with negative available quantity or a count variance above threshold, which became my daily first check. I am comfortable enough in each system to build reports myself rather than waiting on an analyst, which matters most in smaller operations where that support does not exist.

My starting formula is safety stock equals the Z score for your target service level, multiplied by the standard deviation of demand during lead time. For a 95% service level that Z score is roughly 1.65. I calculate lead time demand variability from at least six months of receiving data, not just average lead time, because a supplier that is usually fast but occasionally three weeks late needs more buffer than the average alone suggests. The reorder point is then lead time demand plus that safety stock figure. I recalculate quarterly, or immediately after a supplier changes their lead time performance, since a formula run once a year on stale data creates false confidence.

I start by pulling shrinkage data by location, SKU category, and shift to see where the pattern concentrates, since shrinkage that is evenly spread usually points to process error, while shrinkage clustered on one shift or one aisle often points to something more specific. I break causes into four buckets: theft, damage, administrative error, and misplacement, and I try to size each bucket using cycle count notes and any camera coverage available. Administrative error, like receiving mis-scans, is usually the largest and cheapest to fix, so I address that first with training and barcode checks. For anything that looks like theft, I loop in security and HR rather than acting alone. I track the shrinkage rate as a percentage of cost of goods sold monthly so I can see whether interventions are actually working, not just assume they are.