- Customer Facing Services
- Resource Specifications
- A Price Plan
A Customer Facing Service is defined in SID as: “A Customer Facing Service is an abstraction that defines the characteristics and behaviour of a particular Service as seen by the Customer. This means that a Customer purchases and/or is directly aware of the type of Service and is in direct contrast to a Resource Facing Service which support Customer Facing Services but are not seen or purchased directly by the Customer.”
The key point to this definition is the word seen. The Customer (or more precisely the End User Party Role) perceives the service “Outbound Voice Call”, for example, as nothing more than that. The End User does not perceive the switching, encryption, error correction, radio frequency hops, base station transfers, multiplexing and demultiplexing that may go on in the background.
The Product Offering is thus defined in terms of the Services that an End User perceives, values, and may be charged for.
The SID does not contain the concept of Supplementary Service, which is after all a network (GSM) related artefact and should not (in the ideal world) be used when describing or pricing products and services to Customers and End Users.
Clearly defining a Product Offering, for example “3G Anytime” solely in terms of the services perceived by the End User will not help when the Product Offering is sold (as a Product Offering Subscription) to be provisioned in the network or on the Billing System, but that is precisely the objective of the SID. By allowing an Offering to be defined independently of how it is implemented as a step in the direction of Service Oriented Architectures Holy Grail – Loosely Coupled Architecture, where each domain defines what it wants in the way of services, not how the services are to be implemented or built.
Clearly a Customer Facing Service such as “Outbound Voice Call” has to be provisioned in the network as a range of low level services managed by dedicated hardware such as the MSC. These services are defined as Resource Facing Services (and I will be discussing these RFSs in a later blog).
So, we can define a Product Offering as a collection of Customer Facing Services, the Specifications of the Resources required by the Product Offering (and the CFSs) such as the telephone number (MSISDN), type of SIM, type of Handset etc and the Prices to be charged for the Product Offering and the CFSs it offers (Note: An “Outbound Voice Call” or “Send Text Message” can be charged at different rates in different Product Offerings).
I hope you will agree that this sounds sensible, but what exactly is a CFS? Is a “Voice Call” a CFS, or is “Making a Voice Call” a separate CFS from “Receiving a Voice Call”. When one tries to list CFSs it becomes incredibly difficult to actually decide what is and is not a CFS and why.
While working with Belgacom Mobile (Proximus) Eric Borremans and I faced this problem. We needed an objective way of defining what a CFS was and a set of rules to allow us to determine whether a candidate service was a CFS, and if it wasn’t a CFS, then what actually it was.
The trick was to focus back on the definition of CFS, and it comes back to the word “seen” in the definition of CFS, or perhaps more precisely “perceived”. If a End User cannot perceive the difference between two related services, then probably the two services are components of the same CFS. If on the other hand the End User can tell the difference then, probably (as there are other pragmatic criteria to be applied) these two services are separate CFSs.
For example – can an End User tell the difference between making a voice call and receiving one? To me this is a definite “Yes”. The phone rings when a call is made and when answered there is someone on the other end of the line to talk to. On the other hand when making a call the line has to be activated (by picking up the receiver, or pushing a button on the handset), the number dialled and then after hearing the ring tone the phone maybe answered.
On the other hand, can an End User tell the difference between making a voice call to a fixed line number as opposed to a mobile number? In my opinion, these are the same CFS, handled by different RFSs (to do the switching). One could argue that a knowledgeable End User can by knowing something about the numbering plan in the country, but the call is perceived (heard) in the same way during the call. It is also possible that a call to a fixed line number terminates on a mobile phone and vice versa through call forwarding, hunting groups and the like. When it comes to paying for the call the difference between fixed and mobile voice calls may also be perceived as they may be charged for differently, but that is after the event (for Postpay customers at least). So it comes down to perception during the use of the service, not prior or after the event knowledge that counts.
However if one extends this simple rule to a complex service like “Voice Mail” things become complex and uncomfortable. Clearly an End User can perceive the difference between “Listen to a Voice Mail Message” and “Delete a Voice Mail Message”, but then Voice Mail decomposes into about 10 or more CFSs that are never ‘unbundled’ – one could never imagine selling a Product Offering that allowed someone to “Delete a Voice Mail Message” but not to “Listen to a Voice Mail Message”. An additional rule needs to be defined to allow these type of services that are perceived differently to be bundled together into a pragmatic CFS.
Actually Eric Borremans and I came up with 3 rules and a method to apply these rules that allowed Eric to draw up a list of 60 or so CFSs that described every Service that Belgacom Mobile sold and managed. This list has been successfully implemented within Belgacom Mobile in the area of service management and has been used to define all of the Product Offerings they sell.
27 comments:
Please let me know what the "three rules and a function" are, I am very keen to hear from you...
I think if you read my post on this subject carefully you should be able to derive the rules ;-)
You say "then probably the two services are components of the same CFS". This begs the question of how you classify these (component) Services. These cannot be CFSs; I don't think they are RFSs. Are they serives at all? Maybe "Service Components" ?
The SID only gives you three options, Product Offering, CFS or RFS. CFSs aren't recursive (no hierarchy, all CFSs are equal), so the way I look at it is if it isn't a Product Offering and it isn't a CFS then the only thing it can be is an RFS - no matter how ugly that looks. On the other hand the thing that ends up as an RFS is probably a pretty technical service as it can't be perceived by the customer. But it is a free world - if you have found another way of managing these three then I would be very interested to hear it.
Well I disgaree with the statement that CFSs can't have hierarchy. It is worth looking at SID documentation which shows that the CFS is derived from the Service Specifications where the Service Specifications itself is hierarchical (or recursive).
The matter of the fact is Having Hierarchical model adds extra felxibility to the modelling capability.
Good point - yes the SID does allow a hierarchy on CFS, and taking one like Voice Mail, which could be broken down into a set of sub CFS there seems to be a good reason for this. But in my experience that leads to complexity and also allows for less than clear definitions for the CFSs as all the detail of what the CFS does is hidden in the hierarchy. What I should have said perhaps was "the CFSs can be in a hierarchy, but I don't think it is necessary to use it."
Very well written blog.. I am doing a project for a telecom company, which wants me to suggest how they can manage their customer facing services.. Can you please broadly cover what all services, you think, form a part of CFS for a telecom company, apart from calling services.. Do you think IT, HR, procurement, finance, network management etc. should be included. Thanks. Looking forward to your reply.
Juhi raises an interesting question - I will answer this in detail with a new blog posting. For now all I will say is "when you have got a new hammer everything looks like a nail"!
Is there not a fundamental problem with hard-typing services as either RFS's or CFS's (that is, a service is either one or the other, but not both)? In an environment where a service provider may provide traditional retail services to retail markets, and also provide services to service aggregators to create higher-level "mash-ups," you could easily envision a service that needs to be an RFS used only by self-branded retail CFSs, but also need to simulataneously be CFSs that are consumed by the service aggregator customer.
Does it not make more sense that instead of subtypes, the "resource-facing" and "customer-facing" designations should be roles played by the service, that the "customer facing" role is enacted to offer the service to a Product Catalog, and that a service may have an RFS role in relation to a "retail market" product catalog, and a CFS role in relatio to a "wholesale market" product catalog?
I agree that in the complete value-net to the end consumer, that service is still an RFC (because it is not visible to the end consumer, only to the service aggregator), but if I understand TMF and PSA, as an RFS it would never be offered by the Service Catalog to be a customer offering (to the aggregator) via the Product Catalog.
Hmmm.... but if you don't 'hard-type' them then what is the point in using the SID which is the latest in the line of data models that attempt to just that with all the information in the enterprise.
However I do understand your issue - but I think the SID does allow you to do what you want to do by the use hierarchies of Product Offerings or CFS's. You can build up families and hierarchies of Product Offerings or CFS starting with very 'primitive' ones that, with the Product Offering you can say is only for sale to the wholesale. These can then be bundled into more 'end-user' friendly product offerings which are then marked for sale to the market.
There is nothing wrong with your approach of using roles for services - except it isn't the way SID models the solution to the problem you've highlighted.
Can i please get an example of a telco product to practically understand difference between commercial product catalog and technical product catalog. Lets take example of a Voice Service that is part of Product X. What product to service mapping should be kept in Commercial PC and what information should be there in Technical PC to be used by provisioning layer?
Thanks
The SID doesn't directly support the concept of "Technical Product Catalogue" and "Commercial Product Catalogue". The Commercial side of a Product is represented by ProductOffering which defines the commercial name, brand and price of a product together with any commercial bundling.
The Technical aspects of the Product is given by the ProductSpecification which defines how the product is delivered in terms of the hardware and software (ResourceSpecifications) delivered by the product (e.g. Apple iPhone, SIM, MSISDN) and the CustomerFacingServices delivered by the Product.
In your example you talk about Product X; let's say that is Product X is the ProductSpecification. It is sold as 4 ProductOfferings: X-Home, X-Soho, X-Retail, X-Corporate. The basic Resources and Services delivered by X are the same for all 4 versions of X, just the pricing and quantities involved are different.
X is made up of a set of Resources (e.g. Handset, line, phone number, phone directory entry) (actually the specification of X is made up of ResourceSpecifications) and services, or rather CustomerFacingService Specifications. If X is delivering voice services you simply may have 2 CustomerFacingService "Recieving Voice Calls" and "Making Voice Calls"
The details on how these services are provisioned is provided by the mapping between the CustomerFacingServiceSpec (what the customer percieves) and the ResourceFacingServiceSpec (how the service is provided by the network).
Nice enlightening article. By three rules & functions do you mean CFS - "Seen/Perceive" for end user, CFS that cannot sell independently are essentially same CFS component? What is third?
Also in today's triple play world, we cant just model product without hierarchy. Example there are 4 products from operator - High Speed Internet, Home Phone, TV. These can be sold separately or together as bundle. In this case I feel the hierarchy may be - "Offer" may contain 1 or more "Product Offering" may contain 1 or more "CFS" may contain 1 or more "RFS". Let me know your views.
Also can you share your blog on RFS.
and logistics?, are there CFS of service for delivery (urgent, two point os delivery,...), or maybe, the process or subprocess, of logistic, with the information thet we have in attibute or in characterics, can determinate if the delivery is urgent.., or maybe the unknown productofferingTERM can help us, for make this services.
what do you think about...
So far as Logistics are concerned, it is difficult to know where to end and whether "Business Services" such as logistics and even billing should be modelled. My "gut" feeling is that these generic non-telco services should not be modelled as CFSs as they are not provisioned on the network and generally that is what the CFS is all about: how to map what is provisioned to what the Customer experiences. However if something like Logistics meets the 3 criteria and it makes your life easier to map it as such, then do it, though I think it would be something more like a "Business Facing Service".
I did some work on "Business Facing Services" which married up with ITIL a long time ago and I know people within the TMForum are looking at these right now.
Further to the Logistics comment please see my post http://telecomseim.blogspot.co.uk/2009/09/services-and-customer-facing-services.html
Sunil, the three rules are
1. Seen/Perceived
2. Managed seperately (i.e. if I turn off this service do I turn off that one too)
3. Sold seperately
I didn't say the Products cannot have a hierarchy, there are in fact two ways of building Product hierarchies - through the ProductSpecification (Composite/Atomic) and through the ProductOffering Bundle. The Specification is used to build a "Bill of Materials" type hierarchy where low level products are combined to create higher level ones, while the ProductOffering bundling is used to show how independent products can be sold together (perhaps at special prices). I think your example of quad/triple play you would be talking about ProductOffeting bundles.
A ProductOffering may be the commercial instanciation of one and only one ProductSpec
A ProductSpecification may be sold as one or more ProductOfferings
Each Product is the Customers instance of one and only one ProductOffering
Each Product is the Customers instance of one and only one ProductSpecification
Each ProductSpecification may deliver one or more CFSSpecs
Each CFSSpec may be used in one or more ProductSpecifications
Each CFSSpec may be delivered by one or more RFSSpecs
Each RFSSpec may be delivering one or more CFSSpecs
For more on RFSs see http://telecomseim.blogspot.co.uk/2010/10/resources-and-service-part-2.html
If i´ve a product specification that agregated two or more cfs spec. what do you think about this (in one catalog, or in two catalog [product vs. service+resource])?
In other plane, if i make productspecfication COMPOSITE, is ONLY because the cfs contribute with an adventage in activated,..., correct?, and this productspecifiationCOMPOSITE used one CFSSpec (atomic or composite?)
If i agregated cfs in composite CFS spec, must be servicepackagespec for this?
Thank you for your HELP
If a ProductSpecification "aggregates" (or contains) one or more CFSSpecs and/or one or more ResourceSpecifications only it is an Atomic ProductSpecification. An atomic ProductSpec is atomic because it does not aggregate any ProductSpecs. On the other hand Composite ProductSpecification aggregate ProductSpecifications (only).
and then.., what´s COMPOSITEProdSpec?, i belived it was the way with implemented the acess a set of services, that when the process "used it" received an adventage, for example are activated or delivered in the same operations.
In other words, i make composite pspecifcation when the service designer give me a CFS different and better that the CFS that he gives to the Atomic pspecification.
one AtomicPSpec has n AtomicCFSSpec
but... and the compositePsSpec ?, has.. how and which CFSSpec?
and.. how ordered the execution of the actions&methods of the CFS (simple or composite)? how the process known when the actions of the cfs end? flags of workflow?
THANKs!!!!!
A COMPOSITEProdSpec (CompositeProductSpecification) is one sub-class of the abstract class ProductSpecification. The other sub-class is AtomicProductSpecification. A CompositeProductSpecification has a 1:m relationship with ProductSpecification so that a CompositeProductSpecification contains one or more ProductSpecifications which in turn may be AtomicProductSpecifications or CompositeProductSpecifications.
A ProductSpecification (CompositeProductSpecification or AtomicProductSpec) may deliver one or more CustomerFacingServiceSpecs which in turn may be Atomic or Composite.
There is no restriction on AtomicProductSpecs only delivering AtomicCustomerFacingServiceSpecs or CompositeProductSpecs only delivering CompositeCFSSpecs.
Andrew, I must say that you simplify a lot with your plain and simple english. Are you still around for some the doubts which I have ?
Hi Andrew, You have cleared a lot of doubt. I have been going through the SID product domain and have been wondering if you are able to answer some of my questions.
Thanks
Nancy
Hi everyone, if you have some detailed questions about the blog or want advice about your use of SID then please use my email address given in my profile (top right of this page).
Hi Andrew,
Thanks for such a useful blog. I am new to SID and am trying to understand the boundaries between the various entities. I am having trouble understanding what is the difference between Product and ProductOffering entity as defined by SID. Would it be possible for you to help with an example?
Hi Rohan
A Product Offering is something sold by the CSP - For example a Product Offering could be a bundle of say a handset, SIM, and a tariff that defines the number of free minutes, MBytes etc at a given price and available to a given market, for example Retail as opposed to Enterprise or SME. Lets call the Product Offering ACME+ 2017 - it is marketed and advertised by the CSP.
If you go and buy ACME+ you are the owner of a Product: "Rohan's ACME+" and it will be associated to your Customer Account and the handset and SIM now own.
Post a Comment