![]() |
|
||||||||
|
||||||||||||||||||||||||||||||||||||||
![]() |
11/06/08
If you are evaluating warehouse software solutions and returns functionality is a key value driver for savings through the use of a new application, be prepared to be disappointed. Most warehouse software providers do not provide a dedicated returns module capable of supporting serious returns functionality capable of efficiently processing between 15-30% volume compared to outbound sales. Distributors to large retailers who contractually can return any product they purchase free of penalty OR retailers who face season product rotation know this all too well. Attempting to sell a generic receiving module as a viable option to adapt to these high volume returns needs is not practical for many reasons as a detailed review of the differences between receiving and returns will show: 1. Terminology. 2. Supporting Operational Process 3. Supporting Warehouse Staff The clear diversity of required data elements, supporting operational processes, and required resource staff between standard receiving and returns processing highlighted above cannot be realistically supported by the same series of software processing screens. If returns is a process that can be improved through value-driven processes, take the time required to ensure that you are not solving a returns issue with a receiving solution. Trackback address for this postTrackback URL (right click and copy shortcut/link location) Feedback awaiting moderationThis post has 17 feedbacks awaiting moderation... Comments are not allowed from anonymous visitors. |
|