Skip to content

Customer Implementation Technical Guide

OrderFlow Ltd.

Document Version: 4.2.4

Document Built: 2024-02-16

This document and its content is copyright of OrderFlow Ltd. All rights reserved.
You may not, except with our express written permission, distribute, publish or commercially exploit the content.
Any reproduction of part or all of the contents in any form is prohibited.

Process Requirements Gathering

Process Requirements Gathering

The purpose of this part of the implementation is to get a shared understanding of the requirements for the key warehouse processes that will need to be set up as part of a typical new customer implementation.

Prerequisites

A working system using a model warehouse is useful as a starting point, as it data that can be used to demo and test some of the processes under consideration.

General Notes

In each area of the system where requirements need to understood and agreed, the objectives follow a similar pattern:

  • the OrderFlow Implementation Engineer should gain the best possible understanding of the customers business objectives and constraints
  • the customer should gain a sufficient understanding of the options available, in particular what can be supported via configuration, and what can be supported only via further development
  • the OrderFlow Implementation Engineer should understand what the customer's preferred options are
  • if necessary, any further scoping work for change requests should be initiated as part of this exercise
  • determine whether any missing features are considered essential for launch or can be delayed until after launch

Implementation Notes

In all cases, the process is very collaborative as it requires a lot of two way communication in trying to match what is needed with what is available. For this reason, it is normally recommended to cover these areas as part of a site visit to the customer during an early stage of the project.

Goods In and Putaway

Good-in and putaway are the main ways in which stock will need to come into the system.

Objectives

The aim of this part of the process is to ensure that:

  • the customer understands the options that are available.
  • come to an agreement on the approach to be used.
  • understand whether there are any requirements that are not supported out of the box, and whether any of these are blockers for launch.
  • document the choices in the customer implementation summary document.

Actions

The OrderFlow Implementation Engineer should demonstrate the options for receiving goods in. That demonstration should cover:

  • the basic approach used for deliveries received using the Desktop GUI.

  • options for setting up goods in versus explicitly chosen locations.

  • describe the use of licence plates when creating deliveries to be checked in using handhelds.

  • describe the main options for handheld delivery check-in:

    • directly to stock locations
    • via incoming location for putaway to stock
    • via incoming location for Just-in-Time (JIT) processing
    • via incoming for direct move to bulk pallet locations

The Implementation Engineer will be familiar with the process flow in each of these cases.

Further requirements that should validated, if desktop processing is to be used:

If any requirements are present which are not supported, then customer ticket should be raised for further requirements gathering.

Picking

The task here is to go through the different options for picking. In most environments, the default picking mechanism will be batch picking.

At this point you should be aware of whether handheld or report based picking is used. If customer has invested in HHTs, this is the preferred option.

Objectives:

to ensure that the customer understands the different options. to select the mechanism that will be used for picking at launch. If different approaches are to be used depending on circumstances, then the task here is to determine which is the primary picking mechanism to be used.

At this point we are not concerned about the detail of how shipments are assigned to batches. That is covered in section X.

Actions (HHTs)

Demo to explain the options for handheld batch processing: * pick to single mobile location * pick to subdivided cart with user selected locations * pick to subdivided cart with system selected locations (one per shipment)

The should determine what the desired short pick strategy is.

Actions Reports (HHT)

Here the customer needs to validate the paperwork that will be used.

Packing

Objectives

The key objectives in this area are to

  • ensure customer understands different options in terms of:
  • initiating a packing operation
  • auto printing
  • recording packaging usage
  • to document the customer choices

Note

Some of the packing options will be determined by choices for picking. For example, when using HHTs, the operator can initiate a pack by scanning the trolley containing the items picked. For report-based picking, the pack will normally be initiated by scanning the batch ID on the printed picking list.

Additionally, some of the packing options will be determined by the printing mechanism used. For example, it will not be possible to 'autoprint' both a despatch note and a label unless the print server is used.

Replenishment

This option only applies if the customer is planning to use bulk storage locations. This is typically a requirement for

  • for large warehouses
  • warehouses which use difficult to reach overhead locations
  • warehouses for which picking locations are at a real premium

The OrderFlow Implementation Consultant should explain how replenishment is configured, and initiate the setup of replenishment.

Returns

This functionality should be verified and set up if returns need to be supported into the warehouse.

If the customer has specific workflow in mind that they want to use to support returns, then this is an opportunity to discover what this is. You should be able to determine whether some kind of prior returns authorisation process is required, or whether it is acceptable to have unplanned returns.

You should also consider whether any external system or email notifications will be required if returns are received.

If either of these is the case, then it would be appropriate at this point to raise a ticket for scoping of these requirements and implementation of a solution. If not, then the task is really about explaining the built-in functionality, and the options around these.

Here, the key things to point out are the options around the returns process. Many of these options are encapsulated in the returns properties whose values need to be verified as part of the system implementation, and cover choices such as the returns conditions, default returns locations, etc.

Returns Properties