Spurt og Svarað

How does the AGR system tackle seasonality on item & store level?

Inventory Optimiser has a number of customers with highly seasonal items. Forecasts can be run on these items for certain predefined periods of time to eliminate faulty forecasts. The system has built in algorithms that will automatically detect seasonal patterns and apply the appropriate algorithm to the forecast. Order proposals will only be generated for the forecasted period and can be set to run on a pre-defined schedule through the automatic-order feature.

One of the systems main advantages is that it calculates forecasts and makes purchase recommendations on the lowest possible level. This means the system forecasts each item separately for each store and can therefore also make purchase recommendations on store level for each item. That is how we tackle different seasonality’s between stores. Stores will also have different lead times, depending on their regional position. The system will also calculate this into the purchase recommendations to secure optimal inventory levels.

How is the forecasting method chosen?

The system uses a system, which automatically selects the best forecasting method for each SKU at each location, thus on the lowest possible level.  The system tests dozens of forecasting methods on each item and then chooses the method that minimizes forecasting errors. Users therefore do not need to have advanced statistical knowledge to operate the forecasts. Examples of forecasting methods that can be used based on different types of data are:

  •    Exponential smoothing – covers a wide range of data characteristics
  •    Simple methods – for short or volatile data
  •    Curve fitting – identifies the general form of the curve that the data is following
  •    Low volume models – for low volume and/or sparse data
  •    Box-Jenkins – for stable data sets
How is the response time of AGR, how many transactions / SKU's can it handle?

The system is being used with customers that have more than a million SKU´s. Transactions do not affect the system because it works on daily level, not on transactions. The systems response time is measured through number of SKU´s needed to be replenished pr. location. A typical customer is generally running between 20 and 80 stores, each with 5 – 15,000 SKU’s. Larger users have up to 700 stores and millions SKU’s.

Does a ready integrator exist between Microsoft Dynamics NAV / AX and AGR?

There are standard integrators between Dynamics NAV / AX and AGR. Typical field integration and data transfer is usually not plug-and-play because of differences in NAV / AX setups. Therefore, we usually need to customize the standard integrators to some extent to integrate the systems at initial set up. Once the data connection has been integrated, the data flow is standard.

How does AGR handle new items that do not have any sale history?

It is possible to generate sales history from existing items, e.g. if the user believes the new item to have similar sales characteristics in sales as an existing one.  The sale history of the older item can thus be copied and used to generate forecasts for the new item.  See detail in handbook. The Manage by Exceptions module identifies and flags new items automatically. During the implementation process, customers can define automatic rules to deal with new items in the data transfer.

How do the forecasts use historical data?

The forecasts are generated based on the historical data, making obvious the importance of data quality.  The system needs two years of historical data to be able to analyse seasonal trends.  Working on less data, it will most likely use average forecasts until enough data has been sampled to work in seasonal factors.

Do you have ABC Pareto analysis?

Yes.  In the implementation phase we usually perform ABC analysis, and based on that, certain parameters are set, such as service levels and order frequency.  The system also includes an ABC analysis report which the user can generate.  We have been introducing a two folded ABC analysis, simultaneously taking into account turnover value and units sold which means each item gets 2 parameters, e.g. AA, AB, BA, BB. A standard ABC analysis could look like this example:

 

Item type Policy Method
A items

Typically 20% of items giving 80% of turnover.

Tight control.  Keep correct inventory at the correct time.

Historical data must be correct for better forecasts.

Frequent monitoring

Accurate forecasts, High service level, Order frequency  1-2 weeks.

B Items

Typically 30% of items giving 15% of turnover

Lean stock policy.  Use classic stock control. Not too much effort put into the purchasing process. Automatic control

Order frequency:  One month.

C Items

Typically 50% of items giving 5% turnover.

Many items

Low turnover value

Minimum supervision.  Supply to order where possible.  Large order.  Zero or high safety stock values. Automatic (control)

Infrequent ordering.

Order frequency:

Three months.

How do you define the order frequency?

The order frequency is often defined based on real world situations, e.g. based on routine visits of vendors or based on results of ABC analysis. The order frequency is a very important factor and must be decided carefully.

What results are your customers achieving?

Typical results are 20-40% reduction in inventory levels, reduction in stock-outs and lost sales and a dramatic reduction in manual work regarding the ordering process.  AGR Dynamics has many case studies available online to verify this.

How does AGR handle Cross Docking procedures?

The system does the forecasting down on store level, taking into account the whole lead time, e.g. from supplier to a cross docking warehouse and to the store. The handling of the physical order is all done within the ERP system, e.g. if it’s a Cross docking procedure.

Transportation and order constraints? Is it possible to utilise the system in filling up trucks, containers, minimum order amounts in value etc?

Yes, the system includes a module called constrained ordering. This module can be used to fill up any user defined constraint such that the shelf life of all items ordered should be the same.  The user can for example define a container that can carry a certain volume, weight and number of pallets.  Based on sales forecasts and the inventory status, together with data on the mass, volume, number of pallets and delivery times, the model calculates how much of each product should be ordered so as to utilize container space to the fullest and ensure similar shelf life of the goods in each container.

What about exception handling, e.g. is if an item is in danger of running out of stock before the next order is scheduled?

The Manage-By-Exception feature of the system can handle any exceptions that might arise.  Users can easily custom make their own reports and then saved and send them out by email. Examples of standard reports generated by this tool are:

  1.    Overstocked items
  2.    Understocked items
  3.    Items in danger of running out of stock before next delivery
  4.    Items with extraordinary sales activities
  5.    Items with high forecasting errors
What about poor sales history, e.g. extra high sales or stock-outs, that will obviously affect the forecast?

It is possible to „correct“  the sales history by graphically editing extraordinary points to more realistic values.  This can also be done to the data in table format.

It takes too much time to correct and monitor the sales history for all items. I won't have time to go through every single item. How can the system help me with that?

It is possible to define an exception report that identifies all items with high forecasting error due to „bad data“.  This way you don‘t have to go through each item, as it is enough to monitor just that report.

How does the system take into consideration min. order quantities and quantities per order units (e.g. number in a box)?

The system never suggests less than the min. order quantity.  Additional amounts will be in multiples of the order unit.

How do you make order proposals within the system?

It is most common that our users pre-schedule order proposals so they take place on defined intervals, e.g. orders are made for supplier A, B and C every other Monday etc.  When the buyer comes to work on Monday mornings they would review the proposals and then send them into the ERP system.

Information to suppliers, is it possible to give them access?

It is possible to allow suppliers to have read-only access to the system where they would only see their own items.  There they could see the inventory status and future forecasts helping them to prepare for future orders.

How are variants handled?

Each item within a variant will get a spate item number in the system. When data is transferred from the ERP system to the Inventory Optimiser, a predefined prefix is added to identify each item within the variant. For best performance, items should be replenished on the lowest possible level, so each item is viewed separately under the relevant supplier. Item groups can also be viewed separately representing, size, color, etc for giving oversight over stock levels, this is done as an Exception Management report.

How do you handle expiry dates?

The system can take expiry dates into consideration by extracting them in the data transfer. It will not account for expired items as part of current inventory levels.

How do you send order proposals to the ERP system?

Order proposals are confirmed in the AGR system and transported directly into the ERP system where they undergo their usual process. The actual data transfer is a matter of implementation.

How are optimal order proposals calculated?

The system dynamically calculates the reorder level and the safety stock, taking the service level, inventory status, lead times, min. order quantities and the items replenishment lead time into account. The following data influences the order proposal:

  • Delivery time and order frequency defines the time horizon of the calculation. The time horizon is equal to delivtime + order frequency because the current order will have to cover demand for that horizon.
  • Forecasts for the time horizon of the order.
  • Safety stock for the time horizon of the order.
  • Inventory level is subtracted from the proposal.
  • Undelivered Orders are subtracted from the proposal.
  • Minimum order quantity if order is lower than the min order quantity it is rounded up.
  • Min order qty. The order is rounded up to multiples of the min qty pr. unit.