Mulesoft - BOM, Parent/Child SKU Relationships

[dmathias]

Hi, does anyone have any experience with deciphering and determining how to relate what appear to be parent/child SKUs in Flexera for Mulesoft (a Salesforce company)?  I know I've seen this kind of ambiguous roll up with Cisco products before, but I have no experience working with Mulesoft (reseller = Carahsoft) SKUs.

From the SKU structure, one can infer that the child SKUs are "lower" in BOM than the longer parent SKU, but I think it is inappropriate to think that the parent "contains" the child.

In these scenarios, do practitioners process both levels or ignore one in favor of the other?

We had previously submitted the SKUs to Flexera content team for processing, but I think they (as we Texans would say, "bless them for trying") probably profiled them incorrectly.

Detailed example from PO:

- Part No. 100-0001-67 (qty :1)
Anypoint Platform Base Subscription

Production vCore (qty : 2)
Pre-Production vCore (Qty : 4)
Salesforce.com, Inc. - 100-0001

- Part No. 100-0003 (qty :14)
Additional Production Core/vCore
MuleSoft - 100-0003
- Part No. 100-0003 (qty :4)
Additional Production Core/vCore
MuleSoft - 100-0003

Thanks,

David

NTT DATA Services

[Big_Kev]

Hello @dmathias 

This is really an interesting topic you have raised. I am happy to be proved wrong but in Flexera FNMS content library, the ARL library does has sort of "Hierarchy" (Parent--Child) logic and within those logic such as (Title Precedency or SoftwareTitleSuite etc), the parent does cover the installation reported from Child app etc. 

I don't recall in SKU library there are any 'Parent-Child' relationship and the product will further act differently if so.... that it means is that it purely depends on what 'application' the Flexera SKU library team determine to link inside the SKU.  Whether say the parent SKU Should contain the Child application from Child SKU as well ? 

Personally I am more interested to hear what you have found out from the Vendor's agreement of such interesting scenario that whether the Parent SKU (Parent entitlement can indeed cover the Child application/license consumption) ?? If that's document clearly in the vendor site, I think it's reasonable to ask SKU library team to update the SKU <> ARL Application linkage to reflect that accordingly.

HTH

Cheers

Kevin

[dmathias]

We have no guidance from the vendor or reseller at this point.  This is not an issue that is unique to Mulesoft/Salesforce.  The worst offender is likely Cisco in my personal experience.  I had occasion to look at the raw PO data for this SKU today: L-LIC-DNA-ADD.  We had already submitted this SKU to the content team, and they have processed it as Maintenance.  However, looking at the PO data I now see:

Cisco DNA Subscription License for Routing
Part number: L-LIC-DNA-ADD
PRODUCT INCLUDES: SDWAN-CLOUD, PNP-CAPVBOND,
SW-NETWORK-PNP-LIC, ISR4300-DNA, SVSDNA-
C-ADV, DNA-C-10M-A-3Y, C1-VWAAS-6000-T,
C1-ISRWAAS-2500-T

So, the parent SKU contains all those children SKUs.  Without the complete bill of materials, no one would ever be able to make sense of it, though.

Best, David

[Big_Kev]

Thanks @dmathias , this won't be too easy for SKU library team find out until the user inform them with information related attached. From the product level, I believe you will need to include the child application along with the parent SKU's application in your license (so it becomes a Bundle license) if suit here...manual process until the SKU update can be accepted by the library team I hope.

Cheers

Kev

[dmathias]

Yeah.  I imagine two scenarios: one where we know the BOM, as we do with the examples provided; and another where the BOM is not known, so submissions to the content teams get profiled incorrectly.  This, of course, complicates purchase data processing.  Automation may not be possible without verifying with reseller or other authoritative source that the SKU data is at the "lowest" level of BOM.