Real Time Initiatives

Currently, a major concern at Building Products Plus is getting the inventory, and the company as a whole, into real-time.

Customization Pleases Customers and Attacks Inventory Accuracy
The difficulty with real-time inventory and information systems for this company stems from the inherent nature of a job-shop and custom production environment. Materials often enter the system as one SKU, change into three other SKUs, and might even leave without a SKU because of extreme customization and manufacturing. There is no SKU (other than a "special" code) for something that was cut, drilled, dried, treated, redried, and coated with a polymer coating before it was shipped.

Attempts are made to maintain a SKU throughout the process but often, especially with longer and more complex projects, that SKU is lost when the item begins to look like another SKU, at which point the existing materials are NOT removed from the system and other non-existant materials ARE removed from the system, resulting in a large positive qty of one SKU and a large negative qty of another. The difficulty is in ensuring that transactions occur in the system - which affects costing, pricing, inventory accuracy, and possibly even the customer's experience.

My current focus for achieving a real-time environment is split into four inter-connected areas.
1. Receiving
2. Treating Transactions
3. Cycle Counting
4. Kiln Transactions

Complexities
Each area has its own set of complexities. We have the hardware, including wireless barcoding equipment and a wireless canopy that covers approximately 20 acres. Receiving with the handhelds has been established as a way of business now. Kiln transactions are being entered on the handheld by myself right now. This is mostly because I am not comfortable with the level of training and understanding the workers in the yard have concerning the item codes, the way the kiln modules work, and ways in which the transactions actually affect the total system from inventory qty to financial impacts. Cycle counting is in its infancy and treating transactions are still entered into the system manually from handwritten purchase orders (the treating plant is a strategically located, but separate, company).

General Order of Transactions
In a simple environment, without customization, an ideal complete material flow for - say a 10x10-20 - from raw to finished good in our system would be thus:

1. The 10x10 is received via wireless handheld at the delivery truck as an untreated timber SKU, let's say U10x10. Inventory transx looks like "plus U10x10".
2. The timber is dried before treating and the transaction is accomplished via the wireless handheld at the point of entering the kiln. The adjustment to the new SKU occurs automatically in the system. The transx looks like "minus U10x10, plus D10x10".
3. The timber is then treated. This should be a transaction whereby a Purchase Order is created for the treating of the timber via the wireless handheld, which automatically emails/faxes the PO to the treating company and prints a copy of the PO for our office use. The adjustment to the SKU/inventory will be made at the time of receipt (back to step one) and looks like "minus D10x10 and plus T10x10".
4. The timber is sold (was probably already on order when we bought it). When the order is invoiced, this adjustment looks like "minus T10x10".
5. Cycle Counting is near-random and is intended to be an adjustment to "tidy-up" the accuracy of the inventory.