I fully support this perspective
@Jonathan Goldberg and wish to top up to further reinforce this terminology dilemma.
1) Business, Marketing, Sales teams use vocabulary that is customer and market friendly. Offers, Promotions, Products, Services, Contracts, Agreements... these are all used colloquially and often in a context at odds with the canonical information model provided by Frameworx. That is OK because the goals of those teams are to communicate outwardly to the market, not necessarily inwardly to the Provider's systems and data models.
2) It sure would be nice if the vocabulary aligned perfectly in the outward and inward perspectives mentioned above, but that is not going to happen.
3) The TMF Information Model is an abstract, conceptual model for representing the real world. No one expects any one vendor or system to implement a physical model that EXACTLY conforms to this model. Yes, some aspects of the model will appear because they represent "common sense ideas about the real world" however many concepts would be too cumbersome, non-performant or just plain awkward to implement EXACTLY as represented in the model. Consider the model as inspirational, directional, perhaps even aspirational.
4) Our job as Information Technology practitioners is to map our client's/employer's real world needs to the canonical model where we see TMF assets providing a benefit to our IT systems. Not surprisingly, the most common asset in use is the Information Model, with a fast follow by the Open API specifications.
5) For instance, A "Product Specification" is defined to meet certain modelling goals common to Digital Service Providers. There is no expectation that a business team adopt this terminology, nor is there necessarily an expectation that a system will realize a physical data entity called "Product Specification". The expectation is processes/systems map to the Information Model at the logical level - if they happen to map physically, that's great.
To further this example, a Provider may define a Product Specification "Internet Access" and associate it with 3 Product Offerings: "Internet Basic Service", "Internet Advanced Service", "Internet Premium Service". The customer interested in purchasing Internet service for their residence will purchase one of the 3 Product Offerings listed: say "Internet Advanced Service". This results in a Product Instance of "Internet Access" in the Provider's inventory that is described by/associated to the purchased Product Offering. associated with that customer who receives monthly bills with a line item "Internet Advanced Service". The customer knows they are using the provider's Internet service (they may not know the exact Product name), they know the branding of the Internet Access ("Internet Advanced Service") and they know absolutely nothing about the magic that happens in the network.
Net effect: the Provider sold a Service for accessing the Internet by exposing a Product Offering for a Product described by a Product Instance that in turn relies on Service and Resources in the network. The Provider's marketing team may even consider the Product Offering a promotion because they've adjusted the monthly price downward for competitive reasons or their ad campaign has been promoting this Product Offering as "your best value". Note the mix and match of vocabulary.
5) In my experience, giving business teams a peek into the underlying information model, in small and very targeted doses, can help, But don't expect those teams to jettison their vocabulary. For example, it is very difficult for most business people to understand the difference between a Product Offering and a Product instance and a Product Specification. It can be done, but tread carefully.
6) Regarding the idea of Product vs solution - I have seen no concept in the Information Model that fully expresses the concept of a solution. There is a Proposal concept, but that has different objectives. I have seen bundled Product Offerings and bundled Product Specifications represent standard configurations of services and devices, say for unified communications or premise security, but that does not quite match the generalized intent of a solution. I am sure TMF would accept proposals and draft designs for such a thing ;-)
I hope this rambling helps.
------------------------------
Greg Herringer
IBM Corporation
------------------------------
Original Message:
Sent: Jan 28, 2021 07:54
From: Jonathan Goldberg
Subject: How to identify if a solution is a product or a service?
Hi Johannes
The original post from Tiwa asked about the definition of these terms based on ODA, which is one of the TMF core assets (along with Frameworx, Open API, and more). I ask you again to distinguish between common, informal use of the terms (yes, telcos are called service providers, customers expect to receive service, etc.) as against the formal definitions of these terms within TMF core assets.
Within the formal TMF framework, the simplest residential home phone as against a complex business ICT solution for HQ and 5000 remote sites will both be seen as Products by the customer, instantiated in the telco network as Services, and using Resources (logical and physical). Of course, the complex solution will have 10000s products with relationships between them.
It's fine to have a discussion based on informal terminology, but then you will find it difficult to "benefit" from the TMF assets.
Hope it makes sense
------------------------------
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: Jan 28, 2021 03:00
From: Johannes Stumpf
Subject: How to identify if a solution is a product or a service?
Thank you Jonathan,
I may not be as familiar with the TMF Frameworx definitions as would be needed to judge this.
From a business customer market point of view, there are just two aspects I would like to highlight:
1. Telcos are sometimes referred to as "Service Providers" for a reason. In my eyes it means that Telcos must have productized "services", otherwise they cannot exist. At the same time it is my personal experience that customized solutions are sometimes required in order to fulfill the requests of business customers, especially in the international arena.
2. For a Telco to offer both, individualized and productized services, it is crucial to handle the difference in a disciplined way, applying strict rules. Otherwise they cannot survive.
I am happy to learn more about the exact wording used to describe the two business models that obviously exist in this inductry.
Kind regards
Johannes
Deutsche Telekom
------------------------------
Johannes Stumpf
Deutsche Telekom AG
Original Message:
Sent: Jan 27, 2021 15:08
From: Jonathan Goldberg
Subject: How to identify if a solution is a product or a service?
Hi Johannes and all
The terms Product and Service are well-defined in TMF Frameworx, and TMF assets (such as the Information Framework - SID, and the Open API) use these terms consistently. I tried to give a summary in my previous reply on this thread.
The term Solution is not currently defined or used in Frameworx, at least not in the data modeling parts, to the best of my knowledge.
There may not necessarily be a relationship between these formal terms on the one hand and informal notions used in common language (including telco marketing language) such as service, solution, and so forth. Similarly, terms used in regulatory or legal papers that this thread. All of these typically refer to things that are visible to end customers, i.e. Frameworx Product.
Hope this clarification helps.
------------------------------
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: Jan 27, 2021 02:44
From: Johannes Stumpf
Subject: How to identify if a solution is a product or a service?
I think this whole discussion uses the expressions "Service", "Product" and "Solution" in a wrong way.
Service is something which contains added value activity (human or automated), no matter if individual or productized.
A Service can either be a Product (it has been productized, predefined, listed in an catalog, will be produced in an automated way)...
... or can be an (individual) Solution, which usually is not produced in an automated way, thus has higher production cost.
From a customer point of view, Solutions and Products both solve a problem he has.
No difference if it is sold in a local or global market.
Johannes
Deutsche Telekom
------------------------------
Johannes Stumpf
Deutsche Telekom AG
Original Message:
Sent: Jan 25, 2021 07:21
From: Tiwalade Elegbede
Subject: How to identify if a solution is a product or a service?
Hi Everyone,
I am trying to distinguish between a product and a service based on ODA.
1. In the GB922 Service Domain Business Entities - Information Framework (SID) document it mentions that you can buy part of the Service to a supplier, is this only true for services or can it also apply to products? The wording used is "can buy part of the service to a supplier" not "can buy part of the service from a supplier" - not sure if there is a difference there as this is a recurring saying.
2. Other indicators such as if a solution focuses on the need to solve a problem this means it is a product and if it focuses on the relationship it is a service - is this always true?
3. If the solution is in the Global market is it always a service and if it is in the Local market is it always a product?
Sincerely,
Tiwa
#General
------------------------------
Tiwa
Vodafone Group
------------------------------