The simplest way to provide sku data is to populate this Microsoft Access database. It already has all the data fields defined and some simple error-checking. Once you have populated this database, export the result to a tab-delimited text file.

If you prefer to produce your data directly, you must produce a tab-delimited text file in which each row corresponds to a single, unique sku. Each row must contain the following entries with no null or blank entries. Optional columns may be omitted entirely.

• Unique sku identifier such as name or stock number. Type: Text
• Length of storage unit. Type: Number
• Width of storage unit. Type: Number
• Height of storage unit. Type: Number
• Case pack (number of selling units within a storage unit). Type: Integer
• Selling units (eaches) sold during time period. Type: Number
• Picks (orders, requests) during time period. Type: Number

This is the minimal required data.

In addition to the required fields, the program currently recognizes the following optional information:

• Text description of the sku, which can be useful in checking and recognition
• Group, such as product family or class, which you want stored together in bays
• Subgroup, which you want stored together on shelves
• Weight of a storage unit
• Maximum expected inventory level (number of storage units)
• Safety stock level: Number of storage units to protect against stockout while waiting for restock to the fast-pick area

If these optional fields are provided, the program will take them into account in slotting.

The data for these skus failed some simple plausibility tests:

• The unique sku ID must be non-null
• All case dimensions must have positive value (in particular, no dimensions equal 0, a common error)
• The number of picks cannot exceed the number of eaches picked
• The value of the reorder point cannot exceed the maximum on-hand cases

You can use any unit of measure you prefer—inchs, feet, centimeters—as long as you are consistent and use only your chosen dimension throughout the program. For example, if you give the dimensions of the sku storage containers in inches, then you must later the storage rack in inches.

No.

You have to tell the program how to interpret your data. You do this by preparing a file with the same name as your sku file but with the extension “schema”. For example, if your sku data was in a file named skus.txt then you should prepare a file named skus.schema and store it in the same directory. The program will help you do this if it does not find a schema file for the data you want to import.

A schema file simply tells the program how to interpret your sku data. Here is an example for the minimal sku data. You can copy this and paste it into a text file and name it to match the name of your sku data file:

  [skus]
  FILETYPE = VARYING
  FILEFORMAT = Ascii
  ENCODING = 8859_1
  LOCALE = en_US
  DELIMITER = "
  SEPARATOR = 0x9
  FIELD0 = ID,Variant.STRING,-1,-1,
  FIELD1 = Case Length,Variant.DOUBLE,-1,-1,
  FIELD2 = Case Width,Variant.DOUBLE,-1,-1,
  FIELD3 = Case Height,Variant.DOUBLE,-1,-1,
  FIELD4 = Case Pack,Variant.INT,-1,-1,
  FIELD5 = Eachs Sold,Variant.DOUBLE,-1,-1,
  FIELD6 = Picks,Variant.DOUBLE,-1,-1,

This tells the program that the sku data is a text file (“Ascii”) that the character encoding is “8859_1”; that the language is US English, with the appertaining conventions of punctuation and format; that strings are delimited by quotation marks ("); and that columns (field values) are separated by tabs (“0x9”). Then it lists the 7 fields provided, their names and data types.

The program will offer to write a schema file for you; but it relies on you to tell it what data fields to include. If you describe your data fields incorrectly, it will become confused.

This process is simplest if you use the prepared MS Access database to organize your data; export it to a tab-delimited text table; and then import it into the program, allowing the program to prepare your schema file.

Have you organized the fields in the correct sequence? Are all of your declared fields present (and only your declared fields)?

If you tried once and failed to import successfully because of an incorrect schema file, the program may be trying to re-use that (bad) schema file. Delete it and try again.

The program does not know you changed the value in a field until you press the Enter key or the Tab key to move the I-beam out of the field. Then the button “Accept Changes” will awaken; pressing this button will register your changes.

If you mistakenly enter values that are inconsistent, the program will guess what you meant and silently choose correct values. Thus, for example, if you specify that each shelf should be divided into 4 slots but each sku should be allocated at least 6 slots, the program will replace the 6 with 4, because otherwise nothing could be slotted.

The program allocates space in “slots”. By choosing a relatively small number, like 4, the program will allocate quarters of a shelf. By choosing a number like 100, the program will allocate space in tiny increments (0.01 of a shelf).

Once you have specified the slots per shelf, the program allocates each chosen sku some number of slots on a single shelf. Within this space, the storage containers are packed as tightly as possible.

If you are re-slotting an already-functional warehouse, you can estimate this from past performance. For example, if a standard worker makes 120 picks per hour, this represents about (120/60) = 30 person-seconds per pick. If your team of 5 workers restocks an average of 200 skus in 4 hours then on average 144 restocks require (5)(4) = 20 person-hours, or about (20/200) = 0.1 person-hour per restock, which is about 6 person-minutes or 360 person-seconds per restock.

If you are slotting a greenfield design, you will have to estimate rates of picking and restocking based on past experience, distances to be traveled, etc. In any event, the program allows you to explore how the slotting might change depending on the detailed labor economics.

Under the File Menu, select “Save scenario...”, which will save the skus, rack, and any slotting.

In describing the rack you can select any of several strategies for orienting slotted skus, such as

• “all”, which allows the program to choose any of the six possible ways to orient a sku on the shelf
• “this end up”, which keeps the dimension identified as height oriented vertically;
• “smallest dimension up”

The most direct solution is to edit the file of sku descriptions and list the preferred dimension as case height.

If you provide two optional pieces of sku data, the program will slot skus in groups and subgroups. Only skus in the same Group will be assigned within the same bay or section of rack; and only skus in the same Subgroup will be assigned within the same shelf.

Remember that, if you provide a Group or Subgroup field for any sku, you must provide them for all.

When you describe the rack you can set “Max shelf multiple” to some value greater than 1. This then allows the program to re-configure a bay by removing shelves to create taller shelf openings. For example, if you set this value to 2, then the program may remove a single shelf to leave a double-height shelf opening into which a larger storage container might be slotted (or a smaller container stacked).

The current version of the program does not support separate pick-clearances for individual skus. You will have to make a manual adjustment to the recommended slotting.

Prepare your input so that the Group field of each sku is the name of the vendor.

Save the results and import them into a spreadsheet; then make changes within the spreadsheet. (Note: The spreadsheet will not be able to check for fit our tabulate the economics.)

A future version of the program will support direct editing of the slotting plan.

The program has no knowledge of the layout of your warehouse. It knows only what individual storage racks look like, not where they are located in relation to each other. Consequently it does not know which sections of shelf are conveniently located. You must map the slotting plan onto physical sections of shelf.

Slot the warehouse and observe which skus are slotted into which aisles. Then re-slot each aisle separately, instructing the program to concentrate picking.

Suppose you are slotting 100 bays of rack and want the picking concentrated within 20 bays but evened out among those 20. First, slot your rack so that picking is concentrated and save the results. Pick out the skus assigned to the first 20 bays of rack and prepare them as a separate sku input file. Now re-slot those skus into 20 bays of rack, with picking evened out.

If you do not want separate forward and reserve areas, you must store all of each product in a single, reserved location. You can trick the program into doing this: You must provide an additional data field for the skus, Maximum Expected On-Hand Inventory, which tells the program how much space to reserve for each sku. Then, in describing the rack, set the time-per-restock to some impossibly large number, so that no reasonable solution could ever choose to restock. When you solve the problem, examine the result to see whether restocking was required; if so, you must increase the storage space.

When you describe the rack, set the number of slots per shelf to, say, 4. Then space will be allocated only in units of a quarter of a shelf, so that a sku might be allocated 0, 1, 2, 3, or 4 quarters of a shelf but no more. The resulting slotting will be flexible but not as space-efficient as possible.

If space is more important to you than flexibility, when you describe the rack, set the number of slots per shelf to some relatively large number, such as 100. Then the program will allocate space in units of 0.01 of a shelf. The resulting slotting will be very space-efficient but possibly less flexible, as it could be harder to incorporate new product.

Short answer: One shelf.

Longer answer: One shelf but you can remove shelves above and allow cartons to be stacked so that, in effect, you can fill a section of shelf.

Short answer: One slot.

Longer answer: Whatever value you set for the minimum number of slots.

The program can fail to slot as requested for any of the following reasons:

• The user might have requested that all sku's be slotted but this be physically impossible. In this case the program will halt and display a message that there is insufficient space to slot all the skus. The remedy is to allow the program to choose which skus to slot; or else to increase the storage space, such as by increasing the number of bays of shelving.
• The user might have mistakenly defined more sku groups than there are bays. Because a bay can contain only sku's from a single group, it will be impossible to slot all the groups. In this case only the first groups will be slotted. Similarly, the user might have defined more subgroups than there are shelves, in which case only the first subgroups will be slotted.
• The required packing accuracy might be set too small. This value is specified by the maximum number of shelves that can be left empty in the last bay. It is set so that the program does not waste time trying to fill the last small part of a shelf. If the value is set too small, the program will slot as best it can but will display a message that it may have underutilized the available space. This is expected to happen very infrequently as it requires somewhat pathological data.

No, restocking pallets requires a different labor model than the one offered by this version of the program. (Available on request)

Skus that are drawn in red require restocking; skus that are drawn in blue do not require any restocking because their entire warehouse supply is slotted in the fast-pick area. (You may observe this only if you have provided the optional sku data “Max On Hand Inventory”.)

If the sku is very thin, its rectangular outline might appear as a line segment and so the fill color is not visible.

The program's Exceptions Panel will tell you the reason. A sku can fail to be chosen if:

• its storage container does not physically fit on a shelf in any of the allowable orientations
• it is unable to economically justify its selection, which may be because of low popularity or large value of physical volume per pick or both.

If the given reason is “uneconomical”, the program has determined that the pick savings generated by storing that sku in the fast-pick area would be too diminished by the labor to restock it. Other skus can make better use of that space.

Skus are selected based on total labor costs, which includes both pick savings and restock costs. A sku that is of low popularity can nevertheless be a better economic choice if it rarely requires restocking.

The program computes labor efficiency a slightly different, more complicated way, to account for geometry and other, additional issues. These values tell you the relative strength of claim of each sku to space in the forward pick area.