Thanks for the thoughtful feedback Matthieu.
As you have seen in IG1261, the first chapter describe meta-patterns for product modelling ranging from collapsed to balanced and the pros and cons of adopting such patterns. I have not seen any other document in the TM Forum library that addresses modelling patterns at this level. In my work at various CSPs a lot of time is spent coaching practitioners on model practices: the SID has lots of detail but lacks (and deliberately so) guidance on building up a set of reusable modelling patterns beyond the canonical pieces and parts.
I caution against conflating user experience design concerned with navigating an online Product Offering catalog with Product Offering modelling because the navigation UX requires a combination of categorization, recommendation engine, qualification and user journeys and these domains are related to but not exclusive to Product Offering modelling. As you see in IG1261, the CSP's Product Offering designers need to balance the needs to attribute Product Offerings with need to be able to readily identify discrete Product Offerings in a catalog and this balance must account for the capabilities and limitations of the chosen software platform selected for Configure, Price, Quote, and Billing and Inventory. And this balance may be different for Product Offerings that represent discrete tangible Goods vs individual Services vs Bundled Services. Modelling 1:1 Product Offering to SKU is a legitimate choice provided the modelling team has assessed the pros and cons associated with the selected software platforms and the target user journeys.
Original Message:
Sent: Jun 09, 2023 06:18
From: Matthieu Hattab
Subject: TMF620 | Product offer modelling for device variants
Hi Greg,
I've seen how SKUs are modelled in IG1261, but it's a bit "old school" and you feel the weight of old billing or stock management systems that have a very "flat" product catalogue: Each variant of charvalues (Red-128GB, Red-256 GB...) ends up in an unique product offering. This solution is denormalising offers.
A modern design should focus more on customer experience. Normalise product offerings and allow the definition of multiple variants (and each variant could be a SKU, for tangible goods) for a single product offering. The offer configurator control the customisation.
Apple phones are now modelled in this way (only on apple website)
2 great examples is provided in the SID, which show how to model variants. It's important to remember that variants are not always SKUs we sell "services" too:
- GB922 Common: Toyota Yaris is offered with various body and roof colours. You will see that creating a product offering for each variation of colours is not user-friendy. you could still create multiple products with, for instance, a limited choice of colours if you wanted to.
- GB922 Product: shipping options. This is not about SKU but about valid combination of shipping method and delivery times (see Figure Pr.04-I01)
At the end, the SID teams has already thought about a solution and entities and attributes already exist in the SID. (it's missing a connection with prices, though)
the question is to represent it in TMF620 and avoid workarounds and technical debts in the long term
I will come back after next wek with example and designs.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jun 08, 2023 16:40
From: Greg Herringer
Subject: TMF620 | Product offer modelling for device variants
You may find some useful examples/ideas in IG1261 for this analysis.
------------------------------
Greg Herringer
IBM Corporation
Original Message:
Sent: Jun 08, 2023 08:27
From: Matthieu Hattab
Subject: TMF620 | Product offer modelling for device variants
I see the JIRA task was initiated because of a logistic need. I think it can also support marketing needs, especially when we want to create an offer with specific variant with specific prices. I will create some mockups to illustrate these.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jun 08, 2023 06:22
From: Jonathan Goldberg
Subject: TMF620 | Product offer modelling for device variants
This issue has been identified in ODA and Open API working groups, we have an open change request on TMF620
https://projects.tmforum.org/jira/browse/AP-3772
Each combination of characteristic values gives a specific stock item (SKU/EAN).
The main issue is whether a product specification is created per characteristic combination (i.e. spec is equivalent to single SKU), or rather do you prefer to have a single specification with multiple values for each characteristic and make the distinction at offering level (i.e. spec is equivalent to multiple SKUs), using the charvalueuse to restrict the values in the offering context.
My inclination is to allow multiple SKUs per spec, so that the implementation will have the flexibility to decide.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Jun 07, 2023 13:22
From: Matthieu Hattab
Subject: TMF620 | Product offer modelling for device variants
Hello,
I want to reopen this question because I don't think it was properly answered.
the question was about variants, which is different from ProductSpecificationCharacteristic.
Variants define combinations of characteristic values. In GB922 "Common" TM Forum uses the example of the Toyota Yaris body part colours:
The only combination of colors for body and roof colors are:
Black / Blue
Blue / Green
Black /Pink
So this car has 3 product colour variants
the entity needed to create these relationship is called: "EntitySpecCharValueUseRelationship" (wich we can subclass as "ProductSpecCharValueUseRelationship")
In GB922 Product a similar example is provided to create relationships between charValues of Shipment Type and Delivery Time characteristics (without reference to EntitySpecCharValueUseRelationship, though)
I think this a very important entity, our industry use often it. to take @Amita Kuvalekar initial question, here is a example:
ephone is sellable in these variants of colour and storage:
- gold only available in 500 GB and 1000 GB
- blue available in any storage (128, 256, 500, 1000 GB)
- etc
This needs to be represented in API TMF620. The offer configurator (TMFC0027) ODA component needs to know about these variants to assist customer during order capture.
Moreover, these variants need to be connected to productOfferingPrice:
gold / 1000 GB : $1299,-
blue / 1000 GB : $1199,-
As far I have seen, most, if not all CRM/BSS/Core commerce application support such business capabilities and we see on all webshops.
Will TMF620 V5 support this?
Snapshot of SID definition:
| BE Name |
Attribute Name |
Documentation |
| EntitySpecCharValueUseRelationship |
|
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among CharacteristicSpecValues. |
|
charValueRelationshipType |
A categorization of the relationship between values, such as aggregation, migration, substitution, dependency, exclusivity.A categorization of the relationship, such as aggregation, migration, substitution, dependency, exclusivity. |
|
validFor |
The period for which the relationship is applicable.The period for which the relationship is applicable. |
| EntitySpecCharUseRelationship |
|
A aggregation, migration, substitution, dependency, or exclusivity relationship between/among CharacteristicSpecifications. |
|
charRelationshipType |
A categorization of the relationship, such as aggregation, migration, substitution, dependency, exclusivity. |
|
charSpecSeq |
The order in which a CharacteristicSpecification appears within another CharacteristicSpecification that defines a grouping of CharacteristicSpecifications.
For example, a grouping may represent the name of an individual. The given name is first, the middle name is second, and the last name is third.
The order in which a CharacteristicSpecification appears within another CharacteristicSpecification that defines a grouping of CharacteristicSpecifications.
For example, a grouping may represent the name of an individual. The given name is first, the middle name is second, and the last name is third. |
|
validFor |
The period for which the relationship is applicable.The period for which the relationship is applicable. |
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jul 20, 2021 00:53
From: Amita Kuvalekar
Subject: TMF620 | Product offer modelling for device variants
Dear TM Forum,
We are looking for your guidance about the product offer modelling for the device variants.
It is a very common use case to define multiple variants of a mobile device, based on some properties like color, storage etc.
What is the TMF recommended modelling for these variants?
------------------------------
Amita Kuvalekar
Sterlite Technologies Limited
------------------------------