Hub-and-Spoke Stockroom Model Demands Sub-Locations

While working on a ServiceNow IT Asset Management deployment for a Fortune 500 client, we ran into an issue trying to handle stockrooms with sub-locations within the stockroom. Being a large organization, our client uses a hub-and-spoke model for their stockrooms – one central stockroom that supplies assets to a number of local stockrooms.

Due to the size of the central stockroom, it’s imperative to use a hierarchical stockroom structure to increase visibility to the physical location of an asset within the central stockroom. The central stockroom that my team was working with already had an extensive hierarchy of locations. We were assigned with capturing this information on the asset form.

Why Not Use the Location Field?

Our team was wary of using the location field on the asset, due to the way that ServiceNow auto-populates the location field on the asset. Out of the box, ServiceNow will automatically populate the Location field of an in-stock Asset with the Location of the stockroom. Without rewriting the auto-population logic, any changes to the Location field would get overwritten.

Overwriting the auto-population logic would have been difficult to implement, and incurred maintenance costs during upgrades. Also, this was an intrusive change to the system, so we investigated alternatives.

What Not to Do: Stockroom Hierarchy

Our first effort was implementing a hierarchy within the stockroom field. We added a Parent field to the stockroom form, allowing a hierarchy to be created under the top-level stockroom. With this scheme, the stockroom field would be the lowest stockroom in the location hierarchy within the central warehouse. All stockrooms in the hierarchy had the same location for reporting purposes. Unfortunately, there were two major flaws with this approach.

To illustrate the issues, let’s use a simplified central warehouse, called “Hub Stockroom,” which has 2 places to keep inventory. We’ll call them “A” and “B”. Both A and B are stockrooms themselves, and both have the Hub Stockroom as their parent. In this example, we’ll say there’s a laptop in section A:

Hub Stockroom

In ServiceNow, this is what the stockroom hierarchy would look like:

In the Hub Stockroom, the laptop asset would have a status of In Stock, and a stockroom of A:

The major problem with implementing a stockroom hierarchy is that two major existing features break due to the laptop being in the “A” Stockroom instead of the “Hub” Stockroom.

Transfer Orders Break

The first way that the stockroom hierarchy breaks the out of box functionality is on transfer orders. In our example, let’s say that we wanted to create a transfer order to move the laptop from the Hub Stockroom to a “Spoke” stockroom. We would create a transfer order to go from Hub Stockroom to the Spoke stockroom. Out of the box, when a Transfer Order is created in ServiceNow, it will filter the assets that you can add to a Transfer Order Line to only show the assets that exist in the From Stockroom, which is usually a good thing. However, in this Stockroom Hierarchy model, the laptop would be in stock in the “A” stockroom, a child stockroom of the Hub Stockroom, so the laptop would not show as an option to be added to a transfer order line.

This leads to two clunky workarounds for members of the Hub Stockroom. They can either set the transfer order to originate from the “A” stockroom, which may be confusing to the stockroom that’s receiving the inventory (What’s the “A” stockroom?) The other workaround is for the members of the Hub Stockroom to go to the laptop asset and manually update the stockroom to the “Hub Stockroom.” This is a feasible solution for this small example, but the extra work adds up quickly, especially for the hub stockroom, which is probably processing dozens of orders a day.

Stock Rules Break

The hierarchical stockroom model also breaks stock rule functionality. In our example from above, let’s say that there is a stock rule that will transfer assets of the model of the laptop that is in the A stockroom to one of the “spoke” stockrooms. If the spoke stockroom is below the threshold, the stock rule will be triggered, and the stock rule will look for assets of that model type in the Hub Stockroom. However, in this example, the laptop asset in in the A stockroom, not the Hub Stockroom. The stock rule will look in the Hub Stockroom, not find any assets, and no transfer orders will be created until the laptop is moved into the Hub Stockroom.

Solution: “Substockrooms”

The solution that worked for us was creating a new field on the asset form called a “substockroom.” This new field has a business rule that only runs when the asset status is In Stock and the Stockroom type is a Central Stockroom. If the field is visible, the user can select a new stockroom to add clarity to the location of the specific asset. In the Hub Stockroom above, the laptop asset would have a Stockroom of “Hub Stockroom”, and the Substockroom field would be A:

Because the stockroom is the Hub Stockroom, the transfer orders and stock rules will work as expected.

Gap Identified: Hierarchical Stockroom Structures

I believe that hierarchical stockroom structuring is a gap that is currently missing from ServiceNow, as there is no obvious way to capture this information without adding new fields to the form. Through trial and error, we determined what we believe is the best way to overcome this issue. Hopefully this method will prove useful until ServiceNow is able to fix this problem.

This article has been cross-posted on my company’s blog here.