Future State for WMS Conference Room Pilots
In this series, we’ve hopefully convinced our readers why it is very important to do a good job in understanding the business requirements and documenting the “as is” or current state processes. At this point in a given project, the business has tested the implementation team’s understanding of the business requirements and current state processes and has given the implementation team the green light to move forward with the project. Now that our implementation team knows what the business does and how it does it, they are ready to create the Future State Description.
The Future State Description, often called the “to be” processes, is simply the design of how the new system will be used to solve the business needs. Every process that was uncovered in the Current State Description (CSD) should be mapped out in the FSD, unless of course the process can be eliminated by the new system or some process redesign. Every business requirement uncovered in the Business Requirement Description (BRD) should also be addressed in the Future State Description. Often it helps to make a matrix and create a cross-reference.
In order to build the Future State Description (FSD), your implementation team will need to know how the newer system works. There might be some training required before the team can begin if they have not worked with the new system before or have worked with a prior version. The software vendor or experienced software expert should also be consulting with the implementation team on features and functions (documented or undocumented) that will help the team design the best future state processes available and avoid costly system modifications. Experience and expertise is critical to this activity and can avoid costly rework down the road.
We strongly believe the FSD drives the configuration and that it is critical to have your FSD at least in draft form before actual configuration begins. This way you have a functional road map of what must be configured and how it will all fit together. Let’s take an example from our last post and show you again a process from the CSD:
When a trailer arrives at the receiving dock, the trailer is unloaded to the receiving dock and a pallet and or case count is manually taken to verify that the quantity delivered matches the quantity on the inbound shipping paperwork before the driver is released. Red cones are placed on each pallet to indicate the inventory is not available for put away. Inventory control will then verify the part numbers, quantities, lot numbers, etc., and assign LPNs to each pallet. Once all the pallets are identified and reconciled against the inbound receipt, the inventory will be released for put away by placing a green cone on each pallet. Current dock to stock time is 4 hours.
Many people who have worked in a warehouse will recognize this inbound process. We have seen many warehouses use the “cone” system and while it works, most people want to avoid it. Here is how the corresponding process in the FSD might look if we are implementing a system such as JDA RedPrairie® WMS:
Inbound receipts must be booked in advance and advance shipping notices with pallet LPN, part number, quantity, lot number, etc. will be communicated in advance to the warehouse and an electronic expected receipt will be created. The inbound receipt will be assigned a dock door and delivery window in the dock scheduling application. When the trailer arrives at the facility, the guard will verify that the inbound receipt exists in the system and direct the trailer to the assigned dock door. The trailer will be staged to the dock by scanning the LPN of each pallet as it is unloaded from the trailer. Once all the LPNs have been scanned off the trailer, the driver will be released. Inventory control will QA inbound pallets for accuracy based on the supplier and carrier’s past performance. Once QA is finished, inventory control will release the inventory from the dock which will create directed tasks to send lift trucks to put away the pallets. Estimated dock to stock time is 2 hours.
In this example, the implementation team has not only found a way to support the existing business process with the new software, but they have potentially improved the business process due to new features and functionality available in the new system.
The other nice side effect of a complete FSD is that it will make it easy to track the progress of configuration. Tracking configuration process sounds like it should be easy, but we have seen many times how this can be a challenge. Since each business process from the CSD needs to be covered in the FSD, it is reasonable to estimate and track configuration progress on a daily basis. Just assume a 1-to-1 ratio for your planning and tracking purposes.
Now that we have covered all of the secret ingredients for a successful CRP, we can break it down into a simple, four-step process that is easy to remember:
- Do your homework – BRD & CSD
- Design a good solution that you yourself will enjoy using – FSD
- Practice and prepare your presentation – CRP Scripts
- Knock them dead!
Missed other parts of How to Have a Great WMS Conference Room Pilot?