SID Q&A - Question 8

This is the eight in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.  

In this Q&A we discuss start to discuss ProductOfferPrice, the mechanism used in Frameworx SID to apply prices to ProductOfferings as well as ProductCatalogue.


So4It:  Now we come to the pricing of our Product Offerings.

As I understand it the ProductSpecificationCost is the cost for the operator to install the product it specifies into their network including maintenance etc.  The ProductOfferingPrice is partly based on it (since the price has to cover the cost of cause) but the ProductOfferingPrice is the end price to the customer, right?  So in practice one can skip ProductSpecificationCost and just have ProductOfferingPrice right? 

 

Andrew:  Correct on all counts. The ProductSpecificationCost is not mandatory and would only be used in situations where you were doing profitability analysis.

So4It:  The ProductOfferingPrice includes all types of price including one-time fee, monthly fee etc so when building a complete system the process of creating a ProductOfferingPrice the creator of the ProductOffering would check all the ProductSpecificationCosts, one-time and re-occurring, and create a ProductOfferingPrice that will cover it plus the profit?

Andrew:  Yes, theoretically – but practically the complete ProductSpecificationCost isn’t known – R&D costs, overhead costs etc may not be known. 

So4It:  I can see in the SID that a ProductSpecCharacteristicValue can affect the product offering price and I want to understand this relationship a bit more since I think we have that case.

"The customer selects mobile telephony with X Free traffic + a iPad mini with either 16 GB memory or 32 GB memory"

So of cause the price will be different and the question here is should we model this as 2 different product offerings or as one with the price depending on what ProductSpecificationCharacteristicValue the customer selected, 16 GB or 32 GB.

Can you please elaborate on how the ProductOfferingPrice would be structured for this case? Would these be 2 different ProductSpecifications or will it be one with a ProductSpecCharacteristicValue that decides if it is 16GB or 32GB?

Andrew:  I would model this as one ProductSpec with a ProductSpecCharacteristic of “MemorySize” with 2 ProductSpecCharacteristicValues of “16GB” and “32GB”.   I would however then create 2 ProductOfferings say “iPadMiniStd” and “iPadMiniDelux” the ProductOfferingProductSpecCharValueUse for “iPadMiniStd” would be associated with “16GB” and for “iPadMiniDelux” it would be associated with “32GB” (in the same way as my example using Widgets had “MonoWidget” associated with “black” and “white” while “RedWidget” was associated with “red”).  Then I would create separate prices for “iPadMiniStd” and “iPadMiniDelux”.  This of course requires the user of the pricing app to apply some common sense and it would be possible to make the “iPadMiniDelux” cheaper than “iPadMiniStd”. 

So4It:  One idea I’ve got since the reference between ProductOfferingPrice and ProductSpecification exists is to have a ProductOffering with a CompositeProductSpecification containing one ProductSpecification for the 16GB and one ProductSpecification for the 32 GB and then when the customer selects one we can use the price that is linked to the selected ProductSpecification seem logical ?

Andrew:  You could go to the extreme of making “iPadMemory32GB” and “iPadMemory16GB” different ProductSpecs each with its own ProductSpecificationCost and then have these linked to the “iPadMini” ProductSpec with a ProductSpecRelationship type of “alternatives” and then to build in pricing rules to ensure that a ProductOffering cannot have a ProductPrice of less than the sum of the ProductSpecificationCosts of the components without some sort of override – but that makes everything complex – but it is possible.

If you want to do what you are describing then I would use ProductOfferings rather than ProductSpecs and add ProductOfferings to a “basket” that has its price increase as you add options which are driven by the ProductOfferingRelationship rather than ProductSpecificationRelationship, rather than changing the price of the ProductOffering.  This would also help where a customer can choose to have multiple sub-component ProductOfferings.  Have you seen how Dell does its p.c. configuration pricing on its website?  It looks very much like this.

So4It:  So a question here is how does the reference between ProductOfferingPrice and ProductSpecification look like? ProductOfferingPrice and ProductSpecificationCharcteristicValue look like?  Will this be a ProdSpecCharValueUse maybe?

Andrew:  As I said above I wouldn’t use the ProductSpecification to drive the ProductOfferingPrice; if anything use the ProductOffering – but remember you are not changing the “price” you are changing the value of the CustomerOrder as the customer adds ProductOfferings to the order.  The unit price of the Product Offerings in the CustomerOrder remains the same (for all customers) but in the CustomerOrder there may be discounts applied as a result of the combination of products in the order or as a result of some sort of negotiated discount.  This is modelled on the CustomerOrder through the BusinessInteractionItemPrice.

So4It:  I mean how do you model this in real classes?

Andrew:  Look at the documentation on ConceptWave’s products and Dell’s and Amazon’s websites for real world examples of how product pricing and configurators work. 

In terms of real classes then I believe you should forget the ProductSpecificationCost – it is a “red herring” or something that is leading you off the correct way of implementing the pricing.  Use low level ProductOfferings “Options” that can be associated with higher level “EntryLevel” ProductOfferings and use the ProductOfferingPrice to accumulate the price on the CustomerOrder.  If discounts are applied then you can use BusinessInteractionItemPrice to record them. 

There is a very complex area of the SID call “Policy” which I am sure can be used to define the rule-base for this, but frankly, I’ve never used it and I think it is overly complex, and I’ve not confidence that it has ever been used in practice.

My advice is “KISS” (keep it simple, stupid).  The SID makes everything very complex to allow for every possible circumstance.  If you are building a specific app for say pricing and configuring end-user products then you can afford to model it in a simpler easier to use manner confident that it would never be used to price complex wholesale network bandwidth pricing products with SLAs and other penalties.

So4It:  Then we come to the GeographicArea and DistributionChannel.  As I see it a ProductCatalog has a SalesChannel and GeographicArea it is sold in and from that the price inherits them correct?

Andrew:  Correct.  See the diagram below

The key thing to notice in this diagram is that the ProductCatalogProductOffer which shows which ProductCatalog a Product Offer appears in is linked to the ProductOfferingPrice (though through a m:m association).  This therefore allows a ProductOffering to appear in multiple ProductCatalogs with different (or the same) prices in each.

So4It:  Why would we then keep these on the ProductOfferingPrice, is it because we might reuse the price in other ProductOfferings?

Andrew:  Yes, see my answer above.

So4It:  When it then comes to instantiating the product in the order manager I guess that the ProductOfferingPrice structure more or less becomes the same in the install base but as a Product Price instead correct?

Andrew:  ProductPrice is the price an individual customer paid, or has agreed to pay in the case of recurring charges or the price for Usage.  This can vary from the ProductOfferingPrice because of negotiated discounts etc.  So, yes, you are correct the installed base price is reflected in ProductPrice while the current “catalogue price” is the ProductOfferingPrice.