There are a series of training courses offered by the TM Forum (see http://www.tmforum.org/TrainingWebinars/TMForumTraining/5912/Home.html) that can lead to NGOSS "Knowledge Certification".
These courses are, I believe, excellent, and if combined with a visit to the TM Forum Management World conference can be highly rewarding and instructive experience.
However if you are looking for a 'lighter' and potentially cheaper alternative you may be interested in a 2 training course I am developing in which I introduce the major concepts within the SID and provide practical guidance on the use of the SID based on my real world experience.
This course is not based on the TM Forum courses and uses none of their material, nor will it lead to any sort of certification and is certainly not offered as an alternative to the TM Forum training. Rather I am trying to develop it into something that you might want all your architects to attend, and from their experience and what they learnt on the course you might then select a few to go forward for the full TM Forum training and certification.
This course is still a "work in progress" but if you are interested in more information on pricing and content then please do not hesitate to contact me (email: mcfadyen.andrew @ gmail.com).
22 January 2009
CFSs revisited
I see from the hits on my blog that most people find there way to it from Google where they have searched for “Customer Facing Service” (I am flattered and amazed to see that my blog is the first one returned by Google for that particular term”. I have also been asked for my list of CFSs... I am not sure that
a) I could give it out to you as it belongs to the organisation that I created it for
b) It would be particularly useful to you anyway...
However I would say a couple of things on this subject that may guide people struggling with the concept of CFS
1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.
2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.
3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that
a) the customer (or end user) experiences and recognises
b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.
c) is manageable through a single 'on/off switch' within the Network Management system.
For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.
One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.
On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.
There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.
Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.
The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.
By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.
The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!
a) I could give it out to you as it belongs to the organisation that I created it for
b) It would be particularly useful to you anyway...
However I would say a couple of things on this subject that may guide people struggling with the concept of CFS
1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.
2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.
3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that
a) the customer (or end user) experiences and recognises
b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.
c) is manageable through a single 'on/off switch' within the Network Management system.
For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.
One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.
On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.
There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.
Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.
The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.
By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.
The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!
Subscribe to:
Posts (Atom)
