What You Need to Know Before Executing an Automated Test in Your WMS 

Published: April 17, 2013 – Updated: June 2020

I have been involved in many different kinds of projects in my six years of implementing supply chain systems, and very few of them invested in automated testing. While there is a lot to discuss and unravel in this topic, I will focus on my personal experience from a managerial point of view.

To Automate or To Not

Think about automating testing as a tool that hammers the system with real-life test cases without the need for a human to run it. The primary purpose of such an exercise is to validate the functionality and stress test the system in an attempt to fix business logic and increase the performance. Looking at this from a manager’s perspective, what would I need to worry about considering the great benefits of a successful automated test?

Focus on the main scenario, is it worth it to automate the testing of some value-added service in warehousing? In my years of implementation, I noticed that due to the nature of various industries and their lines of business, some customers invested in automated testing while others did not. I recommend customers with more than 1DC, and who are processing an upward of 10K order lines a day to think about automated testing.

Within the four walls of a warehouse, the scenarios are numerous, so focus on your critical path as time. Time is a highly valuable consideration and a commonly underestimated factor in many projects. Allocation, release, host interfaces, and MHE (material handling equipment) are significant candidates for automation testing.

Preparing a Data Set

When preparing to test, first prepare your data set needed. It may take a couple of iterations before you get a successful start to finish test. For example, during one of my projects, we ran an automated test for an automatic storage and retrieval system (ASRS).

By doing this, it meant populating thousands of locations with various-sized inventory and covering various pull and place scenarios. Initially, this data setup took a considerable amount of time. It became much easier during consecutive runs. The initial run required lots of effort to end up with a smooth, non-interrupted, and successful test.

Involve Operational Staff

Lastly, human error during a go-live is often hard to predict. In all my go-lives, there have been surprises. Users interact with the system using an RF device and the GUI screens. Most human errors are harmless. However, the remaining few that are harmful end up costing a lot. So, engage your operational guys and let them review the tests first.

By: Ashraf Haddad

There’s a Reason You Are Upgrading Your WMS

Upgrading a Warehouse Management System?

Published: April 17, 2013 – Updated: June 2020

Are you upgrading to a new WMS or improving the current version of your WMS? The inclination to recreate the current system, to have the processes, reports, and enhancements must work precisely the same is common. However, this might not be the best approach for every business.

Modifications are costly, more susceptible to bugs, and can impede upgrade paths. You are upgrading your system for a reason. If you want the new system to behave the same as the old one, then ask yourself why you are upgrading in the first place?

Before duplicating existing functionality, ask yourself:

Is this warehouse functionality still used?

I’ve found that when customers answer this question, they find that no one is using the functionality anymore. In past experiences, customers would ask to duplicate an existing report, integration transaction, or enhancements, and when trying to determine the requirements, no one knew its usage. If a system has been in place for many years, the need for this function may have faded out a long time ago.

Can I change my process to adapt to the system?

Operations don’t usually like to hear this, “There’s a reason we do things this way.” Software companies spend a lot of time and money on research and development on a product that can adhere to industry best practices. While some processes work for hundreds of other companies, there’s a good chance it will work for your operation as well.

Do I NEED this?

This question is another one that operations don’t like to hear, “If we are supposed to be upgrading to a better system, why should I lose functionality I currently have today?” It can be difficult to manage expectations, but if operations are forced to justify functionality, they often realize that while it may be ‘nice to have,’ it’s not necessary. In some cases, it may be best to wait and see what is actually needed.

Can this wait?

You won’t fully realize the intricacies of a new system until it has been up and running for a while. Too many times, I’ve seen large, budget-busting enhancements go wrong as soon as the operation realizes how the system really works. If something isn’t needed on day one, the results can be much better if you can wait to determine the best approach for moving forward. By waiting, it could determine that the change isn’t needed at all, or a completely different approach is necessary instead.

Is there a realistic ROI?

It’s possible to get the same answer when asking about the above questions, but when asking about justifying ROI, the answer can change. If a costly enhancement is needed to save a user 15 minutes a week, you may never realize the ROI before it’s time to upgrade again.

After asking these five questions, there will still be necessary enhancements. I’ve never been part of a WMS implementation that didn’t involve customization. Nevertheless, by keeping enhancements limited to necessities, there is a better chance at successful implementation.

Remember – With a new upgrade, you’ll be getting new functionality that can benefit your operation. Remind customers of this when making sacrifices to existing functionality. While a process may have to change in one area to adapt to the new system, there will be benefits to offset this in other areas. There’s a reason customers are upgrading their WMS, remind them of that.

By: Alex Wakefield

WMS Training: Success vs Chaos in the Warehouse

WMS Training Making an Impact

Published: April 17, 2013 – Updated: June 2020

A huge chunk of a Warehouse Management System (WMS) Implementation project is focused on development and optimization to create a powerful and dynamic system. The system should have all the value-added features and do everything under the sun except bring you your morning coffee. However, at the end of the day, the value-added is lost if little to no effort is put into training. Training Managers, Supervisors, SME’s, and Floor Personnel is an area that is time and time again overlooked during a project.

Transitioning to a new system is often a difficult change for everyone involved. Having a robust training program will prepare your workforce for the transition in a comfortable and confident manner.

Key Points

To breakdown the chaos, an implementation may cause a business the five W’s and an H assist in building out a training program.

WHO: Anyone who will be using BlueYonder’s (formerly JDA) WMS:

  • RF Operators who will be receiving and picking
  • Supervisors who will be supporting RF Operators, shipping and receiving clerks, Subject Matter Experts, trouble-shooters
  • Personnel who will assist during the Go-Live

WHAT: Once your processes are clearly defined, it is time to start planning for training. The topics that will be covered will depend on the position you are training. Different training plans are created based on groups and roles.

WHERE: A dedicated training room would be ideal but is not always feasible. The next best thing would be to set up a “conference room” training room or any other big office space that can hold a few people comfortably.

  • Remember that training should always be completed away from the user’s usual workspace. This way, they can focus without interruption by their routine day-to-day activities.

WHEN: You will want to train your SME’s early on in the process. This way, they will have enough time and hands-on experience to get a good understanding of how the system works and how it is configured. They will also have the knowledge to validate your SOPs and assist in Testing and UAT. As for your RF personnel, it is recommended to start training a few weeks before a go-live, so that they will be able to retain all this new information better.

WHY: There is a lot of complex functionality in a BlueYonder WMS. The better your staff is prepared, the more comfortable they will feel about adapting new methods and technology. Your team will have better morale and motivation, better efficiency, and productivity, all of which lead to cost savings!


  • Plan ahead to be sure that all users will receive a sufficient amount of training.
  • Set up your classroom with individual computers where the users can each get hands-on training.
  • Prepare your scenarios for training precisely as they will be performed in real life.
  • Use RFs or Scanners when possible. Create barcoded data so the users can scan as they would in real life.
  • Use existing paperwork to reference in your training; this gives the users a point of reference.
  • Keep classrooms smalls, on average, 5-6 people.

Success with WMS Training

Practicing is the hardest part of learning, and training is the essence of transformation. There are no shortcuts when it comes to training. Invest in your employees and watch it pay off.

By: Anna Lambidonis 

How Multi-Threading Enhances BlueYonder’s WMS Performance

- Updated : Updated June 2020

If you’ve ever spent hours allocating a 40K line wave or waited restlessly looking at the hourglass for your picks to get canceled, you are not alone. One way to tackle this is to take advantage of the multi-threading capabilities that the new MOCA architecture supports in BlueYonder WMS (formerly JDA).

Good News

With the introduction of next-generation MOCA (i.e., MOCAng ), some core WMS functionalities like allocation and pick release are still implemented in legacy C code became slow. This is mainly due to MOCA now being Java-based; native C components incur overhead from communicating back and forth with MOCA processes when trying to invoke SQL or other C components. As a result, we witness a general slowdown in elements like allocation and pick release, where the majority of code is still in C. The good news is that the new Java-based architecture of MOCA supports multi-threading, and with the right approach, there is an excellent opportunity for performance enhancement.

Multi-Threading in Allocation

One area to take advantage of multi-threading is allocation. The success of this approach has led products to include the feature in its 2012 release. Basically, instead of having one single-threaded process going through all shipment lines for a wave and allocating them one by one, we split these lines into multiple temporary waves, so each is processed by a separate thread within the MOCA server process. The key to success here is to split the wave in a manner that minimizes contention between threads. One logical way to split the lines is by part number, where we ensure that allocation threads are not competing for the same piece of inventory. At Longbow Advantage, we have witnessed impressive results with this approach. In some cases where allocation was taking over 1.5 hours to process 40K wave, we managed to reduce it to under 10 minutes.

Multi-Threading in Picks

Allocation is not the only place where multi-threading can be beneficial. Although an exception case, “Pick Cancellation,” is an activity that can be very time-consuming using the standard WMS approach. If we look at a trace of pick cancellation, we see that the standard logic serializes cancellation of picks one after the other and performs rollbacks when errors occur. A better approach would be to take advantage of the deferred execution mechanism in conjunction with multi-threading to achieve speedup.

Basically, instead of canceling the picks inline, we create deferred execution records for each cancellation and a set of background thread jobs. These threads will poll the table and look for documents to cancel. Again, the key here is to ensure that there is a minimum number of contention points between thread jobs. To control this, we can use a Key Value field within the deferred records to hash the record into threads where no two threads are trying to cancel the same set of picks. We again witnessed a remarkable improvement in performance using this approach, where we were able to cancel 40K picks in fewer than 20 minutes.

Leverage Multi-Threading

Taking advantage of the multi-threading capabilities of new MOCA architecture is by no means limited to the cases described above. We have successfully used it to improve the performance of integrator transaction processing, archiving, and much more. However, there are a couple of caveats that are worth outlining:

Contention: in general, as we increase the number of processing threads, we increase the opportunity for contention between threads. We usually need to identify the contention points and take measures to resolve them if possible. But keep in mind that the law of “diminishing returns” applies, and after a certain point adding threads will not produce any more gains.

Concurrency Issues: If concurrency issues still exist in standard WMS code, then a multi-threading approach will magnify them big time. Many threads are concurrently invoking the code that works correctly 99.95% of the time now. The likelihood of 0.05% happening becomes much higher.

Hardware Limitations: When trying to determine how many threads to use, we need to take into consideration available hardware, including the number of CPUs and memory.

Fine-tuning MOCA Parameters: Some of the parameters that we need to adjust to support multi-threading include:

  • Native process pool
  • Database connections
  • Maximum heap size for Java virtual machine

The next generation of MOCA provides exciting opportunities to improve WMS performance and take better advantage of your hardware server capabilities. With the right approach, you can take advantage of both and increase your ROI.

By: Nima Mohajerin

Keep Reading

8 Ways to Improve Your Warehouse Picking

- Updated : June 2020

Warehouse Order Picking

In a typical warehouse, order picking is the most manual, labor-intensive, and expensive operation. It can account for up to 60% of warehouse operating costs. Companies tend to focus on this area first because any improvement can positively impact their customer’s experience, for instance, transactions and delivery times.

If you’re consistently picking the right products and quantities, for the right customer, at the right time, with the right conditions, and at the lowest possible cost, then congratulations and keep up the good work! But for those of you who seem to miss one or multiple of those elements, you’re not alone.

In paper-based picking, it’s not uncommon to see errors due to omitting items, picking wrong items, or miscounting quantities. Any sound WMS system can offer solutions that reduce or eliminate these errors. BlueYonder (formerly JDA) WMS takes this further and provides a variety of picking options that can significantly improve productivity. These options are flexible and can work out of the box. However, if optimally configured and customized, these picking solutions will yield greater results.

It is well known that travel time makes up the most critical factor of the order processing time. It can be up to 50%, and it partly depends on factors difficult to change, such as building layout, existing racks, and equipment (pallet jacks, carts, etc.). This is why the objective should be improving travel time through improving picking strategies.

Eight Tips and Tricks

Based on my experience, I can share the following eight tips:

  1. Rely on System Verifications: Design your SOP to double-verify almost every step in the picking process, and you can loosen this later as needed. For example, utilize area pick verification flags to have users scan and verify LPN, quantity, item, etc. Count Back or Count Near Zero can also be used to count remaining inventory in a location in-line with picking.
  2. Touch Items Once: Focus on preventing errors during picking, and you won’t need further repacking, or shipping checking. Picked inventory should go on trucks touched only by pickers. Also, pick into shipping cartons instead of totes.
  3. Use Pre-Labeled Cartons: With modifications, you can enable relabeling system-generated carton numbers during cluster picking.
  4. Look for Family Groups: If you would like to make completing multi-line order picking via a short picking path, the norm and not the exception, then analyze how customers place orders to slot your pick faces and group your items. This can take time to complete but can be very rewarding, as it ultimately reduces travel distance, your picking enemy #1.
  5. Pick your Smallest Unit of Measure (UOM) First: You don’t want your easily picked full cases waiting for your time-consuming picks. Let the smaller picks lead the bigger picks.
  6. Consider Using Bulk Cluster Picking Instead of Cluster Picking: Bulk Cluster Picking provides the ability to scan a bath of carton (like cluster picking) but walk to every distinct location in the batch precisely one time. When you pick out of an area, you will scan the entire quantity needed for all of the cartons at one time instead of having to scan each pick individually. This is available in BlueYonder’s WMS (JDA) 2004.2 and up.
  7. Consider using Bulk Picking (new in 2012.1): This enables picking higher UOM, which fulfills multiple orders with a single pick. This not only frees up labor by combining the demand of multiple shipments into a single pick and reduces travel distance, but it can also reduce the number of replenishments to the pick face.
  8. Consider using Pick Stealing (introduced in 2008.1): Newly received inventory may sometimes represent an alternate source for picks that have yet to begin. Picks sourcing from interior storage could then be redirected to source from the receiving area instead. If the receiving area is adjacent to the picks’ destination, this redirection will reduce product movement and therefore improve operational efficiency. Keep in mind that cross-docking takes precedence over pick stealing, given that the former is pre-planned, and the latter is an ad-hoc process.

By: Abdullah Alkeilani

Keep Reading

PHP Code Snippets Powered By : XYZScripts.com
This site is registered on wpml.org as a development site.