In real world, does anyone use Procurement application to track a request that was ordered from the service catalog?

[Suggy]

The doc here explains, about using Procurement application to track a request that was ordered from the service catalog.

Does anyone really use a procurement management flow when a user places an order for a single laptop or keyboard etc?

For me, Procurement and request fulfillment should be separate. Why should each order go via a procurement flow? Any reason ServiceNow has designed like this OOTB?

PS - I am specifically talking about ITSM procurement management flow.

[Scott Halverso1]

Yes, if you don't have an item in stock how else are you going to procure it?  By not integrating with the procurement product in ServiceNow you miss a natural integration point with the enterprise procurement tools.  Plus if you are an organization looking to improve the receiving process there is ootb functionality to streamline the receiving of serialized assets as well as software entitlements.  If you are looking to answer who, when and where an item was received, using the receiving functionality only works off of the procurement module.  Advanced shipment notices are another natural tie in to the procurement module too. It's a way to know the order is on the way.

[Suggy]

Hi @Scott Halverson For that, I can use the 'Create an inventory stock order request' where the order can be placed when you know that you are about to run out of stock soon.

So why should I go though Purchase order flow for a request placed by user each time. Also one of the issue/drawback that I see is posted here.

Let me know your thoughts on this.

[Scott Halverso1]

We see more and more orgs not maintaining stock (or very limited stock), but rather ordering on demand and drop shipping directly from the value added reseller to the employee.  We also have seen a rise in the number of integrations between the enterprise procurement tools and ServiceNow.  I think it has more to do with many of the ERP tools migrating to newer more flexible applications (i.e. workday financials, Ariba, Coupa, etc..)

[Joe Ryder]

My perspective is that a lot of organizations do not naturally use ServiceNow for procurement workflows because they don't know how to integrate into their current procurement system like Ariba or Coupa. If ServiceNow could move to a solution-based procurement product line like they do the SaaS integration portfolio, it would make much more sense to people and they may integrate more often. The issue with making it a standalone procurement process or one that is only superficially enrolled in the actual PO system is that there are lots of manual steps that would need to be completed in order to keep the procurement workflow moving.

The reason this is how ServiceNow has designed it, at least from a customer's perspective, is that they did not want to create an entire accounting and purchasing system from scratch, competing with existing companies that do that for a living. It's much easier to at least provide the functionality to handle increment/decrement as well as receiving, a huge pain point for the acquisition lifecycle.

I don't personally know the ratio of people that do and don't use it in ServiceNow's customer population, but I would focus more on, "Do those that use it have it fully working?" Lots of people could use the function and not really be using the full workflow. That's probably a higher percentage - those using it and not using it as intended - than those having it fully implemented.