You do not need a data warehouse to start forecasting. You need three columns and a few decisions about how to treat the messy parts of your history.
The minimum
- Date — when the transaction happened, at the finest granularity you have
- Item identifier — SKU, product code, or whatever your systems use consistently
- Quantity — units sold, not revenue
That is enough to produce a first forecast. Everything below improves it.
The columns worth adding
Location or channel. Demand patterns differ by warehouse, store and sales channel. If you plan at that level, forecast at that level.
Price. Price changes explain a large share of demand variation in most categories. Without price, the model attributes the effect to seasonality and gets the next cycle wrong.
Promotion flag. A promotional period behaves differently from a baseline period. Marking it lets the model separate the two instead of averaging them.
Customer. For B2B, demand is often concentrated in a few accounts whose behaviour is worth modelling separately.
The decisions that matter more than the model
Returns. Decide whether a return reduces the demand of the original period or the period it was recorded in. Either is defensible; mixing both is not.
Stockouts. A period with no inventory records zero sales, but demand was not zero. Left uncorrected, the model learns that the item is dying. Flag those periods so they can be treated as missing rather than as real zeros.
Item code changes. When a product is recoded, its history splits into two short series and both become harder to forecast. Maintain a mapping from old codes to new ones.
Aggregation level. Daily history aggregated to weekly is usually easier to forecast than raw daily data, and weekly is often what the planning decision needs anyway. Aggregate to the level of the decision, not below it.
Intermittent demand. Items that sell in a handful of periods per year need different handling than fast movers. Identify them explicitly rather than letting one approach cover both.
How much history
Two full seasonal cycles is a reasonable target: with monthly data, roughly two to three years. Less than one full cycle means the model cannot distinguish seasonality from trend, and the forecast will be confident and wrong at the first seasonal turn.
Short history is not a blocker. It is a reason to lean on models that borrow structure from similar items rather than models that rely on a single series.
A practical starting point
Export what you already have, at the finest granularity available, without cleaning it first. Getting a baseline and a set of error metrics tells you which data problems are actually costing you accuracy, which is more useful than cleaning everything on principle.