Sourcing Requested Items will source from requested for's local stockroom. What about Remote workers

Brigham · ‎03-17-2023

We are looking at the Hardware Asset Refresh Order flow. This flow (among others) uses the Sourcing Request task to source the HW Assets needed to fulfill the request.

As per this article: https://docs.servicenow.com/en-US/bundle/utah-it-asset-management/page/product/procurement/concept/c... the Sourcing Request will always try to source from the Requested For user's 'local' stockroom. This assumes there is a stockroom for every location at the company, which is not a great assumption. Further what about Remote workers who many companies will list Location = Remote (or Location = Remote - State).

More and more staff are shifting to remote and there will never be a remote stockroom, certainly not one that would cover all the variety of Remote or satellite Location conditions.

Is this something ServiceNow is looking to enhance? TO offer the ability to choose a sourcing stockroom, for example. This also becomes important as more companies shift from maintaining large on-site inventories to 'just in time' delivery direct from manufacturers. We may have a Stockroom to represent that manufacturer, but that again will never be 'local' to the Requesters.

What is the best practice or suggested solution for this emerging scenario?

DavidWallace1 · ‎03-21-2023

This is something that I found odd as well when I first looked at it, and it still confuses me. In many organisations where locations are defined right down to floor or room in a building, the 'user' is 'never' going to be in the same location as the local stockroom. We are making use of transfer orders from a central stockroom to logically get the asset into the hands of the person doing the shipping of assets to remote people. This takes the asset out of stock and gets it into the right state to be shipped and deployed.

In the HAM flow for requesting hardware there is an SCTASK record created for deployment (but not in the refresh one strangely), I think the intention is that the deploy task is meant to cover build, ship and install activities. In my case I'm adding more tasks to spell these out, and because they will potentially be carried out by different teams.

I think overall the flows that come with HAM are only really a starter, and that it's expected that you will create and use your own based on the shipped ones with extra steps and logic. A big example of this is substitutes, at present you don't get any functionality for the substitutes defined against a product model - so if you have none of model ABC in stock, you don't get the opportunity to pick an XYZ that is specified as a substitute for ABC instead, you have to go and manually raise a Transfer Order etc...

Overall I get the impression that the product is still evolving pretty fast, and that new features (and plugs to holes like these) will be coming along thick and fast over the coming releases.

View solution in original post

DavidWallace1 · ‎03-21-2023

This is something that I found odd as well when I first looked at it, and it still confuses me. In many organisations where locations are defined right down to floor or room in a building, the 'user' is 'never' going to be in the same location as the local stockroom. We are making use of transfer orders from a central stockroom to logically get the asset into the hands of the person doing the shipping of assets to remote people. This takes the asset out of stock and gets it into the right state to be shipped and deployed.

In the HAM flow for requesting hardware there is an SCTASK record created for deployment (but not in the refresh one strangely), I think the intention is that the deploy task is meant to cover build, ship and install activities. In my case I'm adding more tasks to spell these out, and because they will potentially be carried out by different teams.

I think overall the flows that come with HAM are only really a starter, and that it's expected that you will create and use your own based on the shipped ones with extra steps and logic. A big example of this is substitutes, at present you don't get any functionality for the substitutes defined against a product model - so if you have none of model ABC in stock, you don't get the opportunity to pick an XYZ that is specified as a substitute for ABC instead, you have to go and manually raise a Transfer Order etc...

Overall I get the impression that the product is still evolving pretty fast, and that new features (and plugs to holes like these) will be coming along thick and fast over the coming releases.

Thomas Wright1 · ‎04-25-2024

It should be noted that this issue has now been solved in Vancouver and later releases with Service Locations. You can make, for example, one stockroom the "local" stockroom of the entirety of a country, so that as long as a user has a valid location where the parent hierarchy leads back to that country it will count as a local stockroom and you can directly consume stock from it, and then ship it out using a shipping vendor using a follow up task in the hardware request workflow/flow.

You no longer need to transfer it to some fake non-existent stockroom or butcher the use of the Requested for field so that the person in the warehouse is the Requested for so things appear as local stock for the person working on the sourcing task.

Robert Bracken · ‎12-23-2024

Very helpful, thank you for your comment.

Brigham · ‎03-21-2023

Thanks for your insights David. Yes I agree this area of ServiceNow is evolving rapidly. I had hoped to leverage as much OotB as possible to drive HAM adoption, but I get that customization of Flows is likely necessary. I was so happy with the Disposal Flow, I was hoping some of these others would be as clean for adoption.