allocation planning at toysrus1

7/30/2019 Allocation Planning at ToysRus1

1/15

Allocation Planning at ToysRus

1 Supply Chain Characteristics and Business

Problem

Supply chain structure = Vendor DC (Multiple) Stores (Multiple)

Most vendors are in the far east, although there are a few vendors thatare domestic. The allocation planning system was for the BabiesRus(BRU) and KidsRus ( KRU) business units of ToysRus, which sellsapparel, footwear and accessories for kids and toddlers.

Business at BRU and KRU is highly seasonal the product mix that astore carrries for spring is very different from the mix in Fall or Winter.From a planning perspective, the business year is divided into fourseasons and each season is planned separately.

At BRU and KRU there are two types of items:

Replenished: These are typically basic / staple items like diapers

or even clothing basics which have relatively predictable demand atthe style / color / size level. These items ate forecasted at the store/style / color / size level in RDF (Retek Demand Forecasting) and thisforecast is used to drive replenishment planning on a pull basis.Approximately 20% of the items at KRU and BRU are replenished

items. Allocated: Example of allocated items are short life cycle products;

seasonal fashion, swim accessories etc. These items typically are very hard to forecast

and are extremely volatile. A different type of planning mechanism is needed for

allocated items, based on the idea of postponement making mix and productdifferentiation decisions as close to the point of realization of demand as possible. At

KRU and BRU, approximately 80% of items are allocated.

An additional complexity in the KRU and BRU supply chain is thepresence of long supply lead times. Most vendors are overseas vendorsbased in the Far east. Due to long manufacturing and procurement

lead times, orders have to be placed on these vendors, 9 monthsahead of the season. So, for an item that is carried in the Fall of 2005,orders will have to be placed at the end of Fall 2004.

These commitments are initially at the style level , and Toysrus has theflexibility of deciding the color mix and size mix on the PO later butthere are strict timelines even for these decisions based on thecontracts with the vendor. Once the timeline for making a particular

ToysRus Allocation Business Process 1/15

Sunil Soman 2/18/2005


2/15

mix decision has passed, ToysRus cannot revise the PO, even thoughthey may have new information that they will never be able to sell thatmuch.

In the presence of such large lead times, a postponement strategy has

to be adopted for allocated items wherein a PO is placed at a stylelevel 9 months ahead. When there is more information that is gatheredfrom the market, color mix and size mix decisions are made on the PO.Finally location mix decisions have to be made (how much of the POshould be sent to which DC and how much of the on-order at the DCshould be sent to which store)

Allocation Planning as defined by ToysRus is the problem ofdetermining the location mix how much inventory should bepositioned at which DC and store.

So although there is the problem of generating the PO and thenallocating it to the color/size level, this was out of scope for the projectthat Manu was invited to bid for. The generation of the PO is a directoutput of the assortment planning process, subject to category levelOpen to Buy constraints.

What they wanted Manu to do was physical allocation of a PO at style/color / size level or inventory to the DCs / stores.

Note that the definition of Allocation Planning may be very narrow

from a industry perspective where it might involve both product mix(size / color mix decisions) and location mix decisions (where to placethe inventory). Essentially, there are two separate problems here:

Generation of a procurement plan 1: This involves deciding howmuch should be procured from the vendor and when. This isbased on the assortment plan and we cant do this without reallygetting into assortment planning.

Physical distribution plan of inventory in the supply chain : This iswhat we were asked to do at ToysRus.

1 I dont know how we will ever be able to handle the generation of thePOs without really getting into assortment planning. So, one of the keyquestions here is do we just handle the physical allocation of POs tovarious locations in the supply chain or do we also do the POgeneration. It may be easier for us to handle the PO generation piecefor a catalog retailer.




3/15

2 Time Line of various decisions

The time line of various decisions in the replenishment process forallocated items is given below. Typically, when they place purchaseorders for allocated products on the vendor, one or at most two

purchase orders for the entire season. So in the case where there aretwo purchase orders, there may be a PO that arrives before the seasonstarts and one PO that arrives in the middle of the season.

Trigger Decision

Pre-seasonactivities

9 months before theseason start

PurchaseCommitment made atthe Style level

8 months before theseason start ( I am notsure of this timing)

Purchase commitmentmade at the Style/Color level

7 months before theseason start (I am notsure of this timing)

Purchase order cut atthe Style / Color/ Sizelevel

8-10 weeks beforeseason start

DC splits given to thevendor. So ship tolocations are given tothe vendor

6-8 weeks beforeseason start Product ships from thevendor

2 weeks beforeseason (approx 4days- week before theproduct hits the DC)

Store level splits arepublished. Initial fillsto the store done.

In season activities

8-10 weeks before thearrival of an in seasonPO.

DC splits are given tothe vendor

4 days 1 weekbefore the PO hits theDC

Store level allocationspublished

Based on actual in-season needs

Store level allocationof any DC levelreserve inventory thatwas held back




4/15

They also mentioned that they are moving towards a Host DCconcept where the host DC is a DC at the port itself and then theactual DC allocation needs to made only right before the product hitsthe Host DC. So the vendor always ships to the host DC and not to

actual DCs. This will enable them to be more reactive.

Another thing they are looking at is the concept of total flow-through,where the product comes from the vendor to the DC complete withstickers/labels for specific store. This enables the product to be placedon a DC truck to be sent to the store immediately. But there is atradeoff associated with this the ability to postpone the store levelallocation decision is somewhat hampered.

3 Allocation Business Process at ToysRus

As mentioned above, there are two types of items at TRU2 - allocatedand replenished. Replenished items are planned using a forecast at astyle/color/size/ store level and these items have forecasteabledemand at this level. An algorithm like PLAN is more than enough formeeting the requirements here.

The distribution of allocated products is handled through the allocationbusiness process a process that determines specific unit quantitieswhen item is not a candidate for replenishment. These allocations arecreated from vendor to DC for initial and undistributed orders, as well

as DC to store when inventory is received and available in DC's.

The allocation business process is illustrated in the following flowcharts

Attach Scanned Flowchart here

Each of these flowcharts are explained in more detail in the followingsections

The flowchart titled Process 34 Allocation Level 2 describes theallocation business process at a high level. This is a self explanatoryflowchart. The main activities in this process are outlined in detail inthe following sections:

34.1 : Select Item3 to allocate

34.2: Determine Allocation Method

2ToysRus




5/15

34.3: Calculate Store / DC quantity

34.4: Analyze, Review and Approve Allocations

The Allocation business process is always user initiated there is no way to automate the

allocation, based upon business policies.

3.1 34.1 Select Items to Allocate

The flowchart titled Activity 34.1 Select Items to allocate is a Level3 flowchart that explains in detail the Select Items to allocate activityin the Allocation business process. Some explanatory notes on thisactivity are given below.

Activity #on

Flowchart

Description Comments

34.1.1 DetermineType ofAllocation

Here the type of allocation is specifiedby the user whether he needs to do avendor to DC or DC to store allocation.

The type is typically determined by atrigger:

PO could be allocated to DCs (withthe DC- store allocation being savedoptionally referred to as presetallocation in this document)

An ASN or Import notification

normally triggers a DC storeallocation

DC level inventory is normally

allocated only to stores

A planned markdown date from their

pricing tool could trigger a DC tostore allocation

To 34.2.3f Gather default

data

For some items, they have automated

DC to store allocation set up. This is onlydone for reserve inventory at DC. Forthese items, whenever inventory atstore hits a certain level, there would bean automatic push from the DC. They

3normally refers to the Stylemany a times style/ color, but never thestyle / color/ size




6/15

Activity #on

Flowchart


said some stores have storage issues, soinstead of pushing the entire seasons

requirements to the store, the storecould automatically get inventory on amore regular basis based on inventorylevels.

They didnt get into too much detail intothis. They did say that this is not exactlyorder up to and that this is a minor process that we

need to consider later.

34.1.2 View List of

Items toallocate

Here they envisioned the following process:

User signs on for area of responsibility ..forexample girls dept.

It is not likely that 2 people will work on the

same PO. Product areas are usually clearlydemarcated among allocators

They envisioned a screen which

showed the allocator a list of items towork on and an allocation statusassociated with each item:

Exceptions error, user must review. ASN

was outside variance

Pre-set saved store allocation. You did it 4

weeks ago when you did the vendor to DC

allocation, might want to redo it becauseof reality since it was done

Available havent worked it before

Unavailable problem with the order. DC

hold for receiving issues

Pending Vendor to DC. 6 items on PO.

Did 4 allocations of the 6. need to do the

other 2 later before release the PO

Note that in the case of Vendor to DC allocation,

you must have allocations for all the items on thePO released at one time via EDI. For DC to store,

allocation can be released one item at a time.

Desired capabilities in this view were:




7/15

Activity #on

Flowchart


Ability for User to sort/filter theallocation workload list based on

various factors such as: date (day,week, month), allocation status (notyet available, new, pending,),prioritization (exceptions,promotions, new stores), producthierarchy (item, subclass, class)

Ability to view purchase order information

such as PO status, ETA date, item details(Dept/class, retail, vendor, description,

received qty), promotional information,

comments etc., throughout the process

34.1.3 a - c Select item(s)to beallocated

If it is a vendor to DC allocation, theuser would select items from a PO

If its a DC to store allocation which isnot based on DC inventory, the userwould select items from an ASN orimport notification

If it is a DC to store allocation whichis based on DC inventory, the userwould select the item to allocate

Some of the requirements here were:

Ability to select multiple items, fromone purchase order, to be allocatedusing the same criteria settings.

Ability to combine multiple inventorysources for item to be allocatedtogether (Example: Allocate an itemfrom an ASN together with existinginventory from a DC).

Ability for user to enter units or % to

determine the quantity to be pulledfrom DC inventory.

Note that combining a march and aprilorder wouldnt be done, but mon andtues could ve done. The order might befor 10000, but on 2 separate ASNsbecause its on 2 containers, so user




8/15

Activity #on

Flowchart


might want to allocate both at the sametime.

34.1.3 d Reviewitem(s)selected toallocate

In the case of pending allocation, andpreset allocation, no selection isnecessary, only review is necessary.This is self explanatory

34.1.4 Specifyitem(s) aninventoryquantities tobe allocated

This has been explained in detail in Step34.1.3

Note that in the case of a ASN or Importnotice or DC inventory, the user need

not allocate the entire quantity for thatitem on the ASN to the stores. Thereshould be the ability for the user toselect only a portion of the ASN qty forallocation. Same goes for DC inventoryor import notification

After the specific items on the PO/ ASN/ Import notification / DCinventory and the quantities have been selected, the user now has tospecify the allocation method to be used. This is described in the

following section.

3.2 34.2 Determine Allocation Method

Activity #on

Flowchart


34.2.1 Pull inpending orpresetallocation

Pending allocations are work in processallocations. One of the things that theykept harping about is the ability to savework in process allocations. So the usermight not be done with the allocation foran item at the end of a working day hemight have saved the qty to be pulledand even selected the allocationmethod, but not ran the allocation yet.In this case, TRU didnt want the user to




9/15

Activity #on

Flowchart


re-do the first two steps when the usercame in the next morning. Rather, they

wanted him to start off where he left off.Allocation is manually intensive workand it is important that we have thecapability to save work in process.

Preset allocations are store levelallocations that were saved when theuser ran vendor to DC allocation. In thiscase, the user might want to rerun theDC to store allocations again

So, in the case of pending or presetallocations, if the stored allocationcriteria and allocation method areacceptable to the user, all he has to dois run allocations are review and analyseand approve the results4.

34.2.2 Selectallocationmethod

The user needs to select an allocationmethod in the following cases:

If the allocation is a preset / pendingallocation, but the user now wants to

use a different allocation methodfrom the originally selected one

If the allocation is an exceptionallocation, but the originally usedallocation method is not acceptableto the user

All other cases, except when theallocation is an automated DC toStore allocation, in which case theparameters for the allocation arealready predefined.

34.2.3 a-e34.2.4 a-e

GatherDefault DataSelect/ Enter/

Each of these flows correspond to thefour different allocation methods thatTRU uses. We shall describe each of

4This implies that whenever preset allocations are saved by the user,we need to not only save the allocations themselves, but also the inputcriteria that were used for that allocation




10/15

Activity #on

Flowchart


Edit Allocationcriteria

these in more detail in the followingsubsections:

Assortment Plan Method Index Method

Manual Method

Copy like / ship like method

These two activities actually correspondto the preparation of data to be used foreach of the allocation methods. It isimportant to note that while we mightpull up data automatically from thedatabase, there is a high degree of user

interaction that goes on here. Forexample, for assortment plan method,we might pull up all the data that isrequired for the assortment planallocation algorithm, but the user mightedit the time buckets to be includedfrom the SMFP unit sales to be used as abasis for the DVR computation step ofthe assortment plan method.5

Note that the forecast sales method isnot really an allocation method. It isused for distribution planning ofreplenished items.

34.2.5 Set flag tosave DC toStoreallocations

This is if the user wants to save the DC-Store allocations that were calculatedwhen the DC-Vendor allocation wasbeing calculated for future use (presetallocations)

34.2.6 Save andsubmitallocationmethod and

Self explanatory. At this point, the useris ready to actually run the allocation

5This implies a key requirement the workbench that we designshould be able to pull up all the parameters required for the algorithmbased on user defined criteria. For example, use the SMFP unit salesfor March and April as a basis for allocation. Also, the user should beable to edit the parameters to be used for that instance of allocationwithout really editing the base data.




11/15

Activity #on

Flowchart


criteria forcalculation

3.2.1 Explanation of various allocation methods used

3.2.1.1 Assortment Plan Allocation Method

This method is only used for allocating the initial PO and initialreplenishment to the stores. This is not suitable for in-seasonallocations

As the name suggests, this allocation method tries to mirror the

assortment plan6 that was used to generate the purchase orderrequirement.

Based on the feed from the assortment planning system, we canfigure out how many assortment plans this item is a part of. Notethat although it would be ideal to do an assortment plan on a storeby store basis, it is not humanly possible to do a store levelassortment plan for every store in the chain

For this reason, an assortment plan is done for every category forevery store group that share certain attributes.

The concept of location grouping or store clustering is used tofacilitate this. Location groups are groups of stores that exhibitstrong performance identified around a particular product attribute(NY Yankees, Ethnicity, Preemie). Location groups will be used toplan the assortment at the store level and to assign particularproduct to the appropriate locations in order to maximize sales andperformance. Location groups are separated into "CorporateDefined" (Climate, Space, Ethnicity), where the attribute assigned tothe store pertains to all product categories and "User Defined" (SledStores, Osh Kosh Stores), where the attribute assigned to the storepertains to a specific product type. The width of the assortment(the number of items to include in the assortment) is thendetermined based on the attributes of the location group.

Within a location group, there could be several stores that exhibitdifferent sales potentials. While all stores within a location groupwill have the same width of assortment, the depth of anassortment would be planned based on the volume rank within the

6An item requirement on a PO could come from different assortmentplans, but they try to keep this separate




12/15

location group. So for example : Hot / Small KRU / Latino/ Osh-Koshwould all carry Osh Kosh Black Jackets but A stores within thatlocation group would have a depth of 72 units, whereas B storeswould have a depth of 54 units in that style.

So in the assortment planning allocation method, given an item that

has been selected by the user, we need to first figure out how manyassortment plans this item has been assorted in (based on locationgroups) . Then, for each location group, we need to identify allstores that belong to that location group. Then we need to calculatethe allocation quantity for each store and then calculate the DClevel allocation

Additionally, we also require the store level unit plan at the stylelevel from the merchandise planning system.(SMFP) It is importantto note that the user may edit the Store level SMFP data to be usedin the allocation based on latest info available. Or the user mayspecify the time buckets to be used as a basis.

The planned receipts per item per location group is also animportant input from the assortment planning system. This was theoriginal basis for the PO and we need this info to figure out thingswhen a PO comes from multiple assortment plans. But in the casewhere a PO comes from a single assortment plan, the POM(Purchase Order Management System) would have informationaround the assortment plan associated with the item.

The details of the assortment plan allocation method are outlined inthe spreadsheet attached below and is self explanatory

E:\Plan & Schedule\

Retail 73\Assortment

Note that size allocation to each store/ DC is done on the basis of achain wide size scale ratio. But this causes problems especially in in-season allocations. Would like more configurable size scale ratio (Iwould think they would have to factor this into their assortment plansin order to do this correctly)

Summary of Input Data from external systems and Userdefined inputs

From Purchase Order Management Systemo PO Info Header, Lines, ETA, Comments

o Assortment Plan associated with the items on the PO

From Assortment Planning System




13/15

o Location Groups

o Stores affiliation to location groups

o Planned receipts associated with the assortment plan

o Average per location group per rank for every item in the

assortment plan

o Item in/out date on the assortment plano Min Store Qty

From Merchandising Planning Systemo Monthly Unit Plans per store per style

o Dynamic Volume Rank Breakpoints

o Store Status (Closed / Open)

Relevant Data from Item Master and sourcing relationships andShipping pack qty

From Warehouse Mgmt Systemo Bulk ,On Order, ASN or Import Notification

o DC Inventory

3.2.1.2 Index Allocation Method

This is used for in-season allocation. The index method supports re-order allocation for short life cycle/ seasonal product. The method usesa stores weighted sales combination (plan and actual at item size levelor higher) to apply to an index chart to determine the stores ideal

inventory level

The basic idea here is that the user can assign weights to the itemsunit plan or actuals based on the time in the season (for example,earlier in the season the plan may have higher weightage over actuals,but later on it might be vice versa)

The calculations of the index method are shown in the spreadsheetattached below

E:\Plan & Schedule\

Retail 73\Index Meth

Summary of Input Data from external systems and Userdefined inputs

From Purchase Order Management System




14/15

o PO Info Header, Lines, ETA, Comments

From Merchandising Planning Systemo Monthly Unit Plans per store per style

Relevant Data from Item Master and sourcing relationships andShipping pack qty

From Store Inventory and POS Transaction Systemso Store Level Inventory

o Actual Unit Sales

From Warehouse Mgmt Systemo Bulk ,On Order, ASN or Import Notification

o DC Inventory

3.2.1.3 Manual Method

Manual method provides the user with flexibility to enter exact units (store / DC level) or

percent for a pre-determined quantity based on an external analysis or need

3.2.1.4 Copy Like / Ship Like Method

Copy Like Method provides the user with a quick method to use the criteria from an

appoved allocation as a basis for calculating the allocation for a new item

Ship Like Method provides the user with a quick method to use the exact store unit

quantities from a previously approved allocation. Proration will be done if the PO

quantity does not match.

3.3 34.3 Determine Allocation Method

This is where the user actually runs the allocation algorithm. This flowchart is selfexplanatory.

The store level allocations ate first calculated and then adjusted to min / max store

requirements

DC level allocations are then calculated by summing up the store level adjusted

allocations

DC level allocations are then rounded up to the shipping pack at the DC level




15/15

In some cases store modifications are required after DC adjustment is done

3.4 34.3 Analyze, Review and Approve Allocations

This is self explanatory and one should easily be able to follow this flowchart based onthe discussion above.



allocation planning at toysrus1

Documents