Customer order decomposing in multiple (>100) Resource Orders

Joshua Chen FX
Mega Sage

use case:
- managed services customer, they sell ''services'' as product, e.g. sd wan monitoring and installation
- 1 customer order = 1 PO > PS requires RS (Routers)

For quantity requirement, would you:
- enter the quantity at ordering

  • 1 order line > 200 product orders > 200 resource orders

OR
- have a CHAR = quantity on the PS and quantity mapping with the RS

  • 1 order line > 1 product order > 200 resource orders (quantity mapping)

    from a service assurance or day2 operations (MACD), would it make more sens to do it against 1 product inventory/install base item or 200 product inventories?
1 ACCEPTED SOLUTION

ShashankInamdar
ServiceNow Employee
ServiceNow Employee

@Joshua Chen FX Based on your description, you are selling a Managed Service Offering that entitles the customer to have an 'n' number of Routers. 

 

In this use case, it may be more appropriate to drive the 'n' quantity via characteristics rather than setting it against the Order Line Item.

 

The option of "200 product orders > 200 resource orders", seems unsuitable (although not invalid) because the product being sold is Managed Service and not the Router. The Router appears to be an entitlement.

 

As an example, are you selling 200 iPhones or a Corporate Mobility plan that entitles customer to 200 iPhones that you manage?

 

For MACD scenarios - do you have use cases of changing a particular Router inventory record of the 200 that would be created? This can be done using TMF652 - Resource Order Management, although not supported OOTB.

 

For Assurance use cases, each of the Router inventory record (corresponding to the RS) can be mapped against a CMDB CI record against which Incidents, Change Requests can be tracked and managed.

 

An alternative, as a food for thought, is not to define a Resource Spec in the P-S-R Catalog and instead create them directly in the CMDB CI. You need to consider what do you gain or lose by maintaining the Router record in the Inventory tables as well as in CMDB.

 

Look forward to your view!

View solution in original post

11 REPLIES 11

Mahesh_Krishnan
Giga Guru

Joshua:

I need some clarity here. If the customer is selling monitoring services what is that customer's customer ordering? Is the produce model you are trying to create for a customer ordering such monitoring services or are they actually ordering routers? Perhaps a dumb question but thought I would ask.

 

If we are talking about a customer who is offering monitoring services I would think they will need all the 200 routers in the install base and TNI data to then be able to raise tickets if any one of the routers has issues. I am not sure why you would need 200 POs; I am leaning more toward your 1 PO >> 200 Resource Orders model. Just my 2 cents.

Joshua Chen FX
Mega Sage

@Mahesh_Krishnan  

customer would order a product (managed services) from us.


- if that product cost 100$, then it would make sense to have quantity = 100 when we submit the order for a 10000$ total cost. In that case, OMT will decomposes the order line into 100 product orders  i think.

Mahesh_Krishnan
Giga Guru

I am not sure what creating 200 POs gets you? If it is all 1 order from a billing perspective. But will leave it to the other experts to weigh in. The other question I had was does a customer HAVE to order routers and managed services at the same time? What if a customer already has routers and want them to be managed? Does it make sense to create 2 separate POs - one for routers and another for managed services, and perhaps create a PO bundle of both these?

creating the 200 product orders is an OOTB functionality in servicenow when leveraging the api tmf622.
but you can try replicating it in your PDI, submit an order for 1 product offering, and change the quantity to 10, i should decomposes into 1 order line > 10 product orders.


yes, its a specific product offering, where we sell you the hardware but we also manage it. that router configuration and other characteristics will depend on what type of service level and other CHAR at the PS layer customer has selected.