There are two different models for organizing your hub and spoke distribution architecture, Flexible and Strict. In this article, we will review how to create a Strict Architecture and detail the user experience in both Demand Planning and Purchasing Automation modules.

Strict architectures are best suited for distributors that have a very clear hierarchy of locations and want to enforce how items are purchased and dispersed throughout those locations. This approach requires a central purchasing and planning organization, adding some overhead but offering significant benefits. Distributors using a strict model typically excel at meeting supplier targets, thereby reducing freight and shipping costs. They also manage to carry less overall inventory by optimizing across their entire network instead of individual locations.

Choosing a Strict architecture significantly impacts both Planning and Purchasing. In Planning, dynamic min/max values are based on aggregate usage along each step of the replenishment path, ensuring optimal stock levels at each location. In Purchasing, Recurrency generates recommended purchase quantities based on these min/max values, with a workflow designed for replenishing hubs and transferring to spokes.

To effectively implement a Strict Hub and Spoke model, follow these steps:

To do this, you’ll need to change the following settings in the Settings Page:

In order to create replenishment plans that optimize across your network of locations, you need to first define replenishment paths which define how items should move through these locations. Replenishment Paths can set at a location, supplier, or item level, or a combination of all three. To learn more about how to configure Replenishment Paths, visit this support article.

You should still review min/max recommendations regularly and either accept or modify Recurrency’s recommendations.

Note: Purchase recommendations for understock items will only be made for Hub locations. You will see a warning on Spoke locations to purchase into your Hubs.

Replenishment Paths will update the lead times for all locations downstream of the Purchase Location. Using Replenishment Paths with a Strict Hub and Spoke will also aggregate usage at all locations upstream of the Requirement Location.

For lead times, take the following example:

In this example, the item is purchased into Los Angeles, transferred to San Francisco, and the remaining volume is transferred to Sacramento. At the Purchase Location, Recurrency still uses Smart Lead Times to calculate the lead time from the supplier to the Purchase Location. For each downstream location, the lead time is based on the transfer time between those locations. For San Francisco, it takes 3 days for items to be transferred from LA. Then another day for those items to be transferred to Sacramento, which results in 4 day lead time for Sacramento. Hovering over the replenishment paths or inspect the Lead Time for any item will show this breakdown.

For usage, we can take the same example, but look at each location’s individual demand and how Recurrency will aggregate that demand:

In this case, Sacramento and San Francisco both have usage, but Los Angeles has none. Usage is aggregated from the Requirement Location up into the each node in the path, all the way to the Purchase Location.

Historical usage data is a critical component in Recurrency’s Demand Forecasting solution, which generates forward-looking demand forecasts and demand pattern classifications. These values are then used to create dynamic min/max recommendations for your inventory. Recurrency will still generate Min/Max values for every item-location pair to detail the amount of inventory that should be held at each location.

In both cases, the Min/Max define the minimum/maximum quantity of an item that should be on hand at a given location. When inventory levels fall below the Min, the Max determines how much you should replenish.

There is some nuance to understanding how to interpret these Min/Max settings at a Purchase Location vs. a Requirement Location:

The Purchasing workflow can also be separated into purchasing for Purchase Locations and Requirement Locations.

Recurrency’s purchasing works on a per-supplier, per-location basis. For Purchase Locations, the workflow is straightforward:

For more details on how to create a Purchase Order, visit this link.

Recurrency aggregates usage from all downstream locations into the purchase location, so you only need to review the min/max at the purchase location to determine purchase quantities.

For the Requirement Locations, Recurrency does allow you to create Purchase Orders directly to a supplier at any location. For Requirement Locations, this should largely be unnecessary because you can transfer the inventory from your Replenishment Location.

To do this, you’ll still use the Purchase Order creation process, but instead of setting Purchase Quantities, you’ll set Transfer Quantities.

For details on making transfers, visit How to Make Transfers in Purchase Orders.

The most common Strict Architecture configuration is that every Requirement Location has a specific Replenishment Location. Some of those Replenishment Locations are also Purchase Locations. Everything a Requirement Location needs comes from its Replenishment Location.

You can make this more complex where specific items or suppliers for a given location follow a different path, including direct purchase into that location.

For example:

In this case, for all suppliers except for SP-1, San Francisco should create transfer orders to pull from Los Angeles.

For SP-1, San Francisco can create a Purchase Order based on the Min/Max values for the items from that supplier. Since the items from this supplier have been removed from the replenishment path through Los Angeles, these Min/Maxes only take into account what San Francisco needs (and also use a Supplier lead time and safety stock instead of a Transfer lead time and safety stock).

By following this structured approach, you can ensure efficient inventory management and optimized purchasing in a Strict Hub and Spoke architecture.