Allocation Comparison AS-IS vs OPT
6. Unit‐load Warehousing
6.2 Unit‐load warehousing Data architecture
The design and management of a unit‐load warehousing system, provided by the proposed procedure, are based on a set of real data instances able to describe the historical behavior of the storage system object of analysis.
This section aims defining a systemic data structure able to gather information from enterprises regarding with the production cycles, the inbound receiving processes, the demand and shipping rate, the historical inventory, and to store such information as input for the proposed design top‐ down procedure. The principle activity carried out at this step is the conceptual definition of the E‐R diagram.
Figure 71. E‐R diagram
As for the E‐R diagram illustrated in Chapter 4, this study is inspired by the observation and analysis of many different enterprise realities, which often face common warehousing issues in different ways, approaching different data source and DMBS with different tables or spreadsheets. The main functionalities provided by DBMS solution ensure data integrity and accuracy, and the storage and management of huge amount of data, easy accessible through SQL queries.
The proposed E‐R diagram, illustrated in Figure 71 bases on the contents of three main tables, which are named SKU, INVENTORY, INBOUND and OUTBOUND. These tables regard with the input data gathered and summarized by the enterprises WMS.
In follows, a summary description of each table is given, with the detail of the principle data fields.
SKU. This table represents the SKU master file, contains all available information regarding SKUs (e.g. code, carton volume, carton weight, description, demand class etc.) and usually counts ten thousands rows. The field description allows registering information of the name associated to the SKU code. The class of product might report the classification of the SKU turn over (i.e. A, B, C classes of Pareto curve) or the functional unit or manufacturing family of the item. Indeed, the proposed procedure and DST consider class‐of‐demand SKUs as categories of products that need to be store in different storage areas with particular storage modes. As instance, there is an implicit agreement among practitioners operating in an automated systems (i.e. made by ASRS and AGVs), which sees high turn‐over SKUs devoted
to drive‐in rack and slow‐moving SKU, recognized by small inventory, devoted to ASRS, in order to guarantee an high space efficiency. Hereby, the distinction appears in the SKU master file, which means that a pre‐selection of which SKUs should be addressed to each zone is already made.
OUTBOUND. This table represents the demand profile of a specific period of analysis (e.g. a year) and usually counts millions lines. Each tuple is composed by the due date of order, the order code, the SKU code and the picked quantity in terms unit‐load pallets. The field BatchCode is particularly interesting since allows to point out when the last pallet of a production lot of a generic SKU is retrieved and shipped, thereby releasing the related lane. INBOUND. This table reports the historical inbound profile composed by the incoming lots
received by manufacturing lines or docks. Each record is made by the received date, the batch code and the SKU code, as well as the unit‐load received quantities to be stored in the system. This table is fundamental for the implementation of the static pattern for the setting of the optimal lane depth for every SKU. INVENTORY. This table reports the inventory master file for SKUs. The historical stocks of the SKUs enable to assess the space efficiency and saturation performances of the designed unit‐load warehousing system in the third step of the procedure. LAYOUT. This is a fundamental table of the E‐R diagram since it contains a tuple (i.e. a row) per each depth of the lanes composing the storage system object of analysis. Indeed, in each tuple it reports the lane depth (i.e. the value called k in the pattern), the rack level (i.e. the value called z in the pattern) and the overall number of available lanes of each depth. This is a picture of the configuration of the storage system set at the second step of the procedure. Through this table the decision‐maker may also import an AS‐IS warehouse configuration, bypassing the first two steps, in order to measure the performance as a benchmark for furthr improvements. UL. This table indicates the type and size of unit load stored within racks. This table aims to define the aisle width in term of equivalent pallet locations, the so‐called a parameters of the proposed pattern.
Once the E‐R diagram is set, its implementation on a DBMS follows. As previously discussed in Chapter 4, here the proposed procedure is implemented through a DST. The application, developed in Visual Studio© environment and C# language as further described in Chapter 4, is based on object‐ oriented (OO) methodology and client‐server architecture built through a database management
system (DBMS). The adopted DBMS is Access™ since it is highly compatible with other Office tool such as Excel, particularly useful to export graphs or other output.
Without going in detail on the UML diagram and main software classes and entities, as for Chapter 4, the following section presents the principle GUIs of the platform in order to illustrate the functionalities and tools handled by the decision‐maker.
6.3 Unit‐load warehousing. GUIs
The management and control of the DST is allowed to the decision‐maker, through a set of developed GUIs, which lead the user through the analysis and support the interaction between the illustrated tool and the proposed top‐down procedure. GUIs enable the user to carry out analysis and decisions by utilizing the tool. In particular, the following sections deals with main DST modules, one per each of the previously discussed procedure steps.6.3.1 Lane setting module
This module supports the decision‐maker in defining the optimal lane depth for the considered SKU given a specific period. Such interval, defined by the calendar panels on the right of the interface, is assumed by the proposed DST as the filter to consider the inbound lots received by the either manufacturing lines or docks. The average value (in terms of pallet quantity) of incoming lots per a generic SKU i, the so‐called qi parameter of the pattern, contributes to the determination of theoptimal lane depth.