Don’t believe everything you read, is a very common advice, however people intend to forget it. Last week (10-Sept-2008),  I read a story in Reuters and Forbes about the drop in the United Airlines parent company UAL (nasdaq: UAUA) share prices; an old story, originally published by the Chicago Tribune in December 2002, on the bankruptcy filing of UAL Corp, found its way to the Bloomberg financial news service, giving the impression that the story was current.

The result were hurtful the UAL share fell 76 percent. Although once the error was found the share recovered a large part of its original price, the damage was cut and clear. BTW, for those interested in UAL situation according to Forbes (08-Sept-2009), “It filed for Chapter 11 bankruptcy protection in December 2002 and emerged from it in 2006. Despite its struggles, the company has given no indication it plans another bankruptcy filing”I couldn’t avoid thinking about the difference between relying on primary data sources, vs. using data already processed. It reminds me of an ongoing debate over retrieving data in Revenue Assurance. There are two main approaches:
The first which I strongly support is that whenever possible, RA systems should get raw data from the primary data generating systems (switches, SS7 probes, billing systems, etc.).
The second approach advocates that in order to reduce costs, RA should try to get, whenever possible, data that was already put in some kind of data repository or Data Warehouse even if it is somehow processed data.Using primary data has it costs, but not using it might have unforeseen higher costs.  

Last week I participated in the IBC Revenue Assurance & Fraud management conference in Rio de Janeiro. At the conference I heard several RA vendors presenting, one of them gave a presentation in which he attacked the RA best practices and standards recommendation, published by different industry bodies. 

From what I heard and understood the presenter blamed these bodies of creating an unrealistic and detached standards and best practices recommendation. Therefore his recommendation was to be in contact with these bodies, to hear what they have to say, but in the end to do what fits best to your organization.
He also mentioned several times that although his company is a member of committees that published these best practices he found the need to say it.  It was very clear, even though I do not recall him saying it out loud that he included the work of the TMF, as part of these “not really serious” best practices.

I must say I took it personally, I am very proud to be part of TM Forum creating these best practices recommendations. I was offended for all the companies and persons that collaborated in this effort, and I was upset for the Service Providers that adopted these standards.
BTW, some Service Providers that already adopted part of the TMF best practices where right there in the conference room, one of them gave an excellent presentation, in which she emphasized how helpful it was to base hers corporation strategy on the TM Forum RA best practices recommendations.

I decided not to publish here the name of the vendor that attacked the best practices; I do not want to transform this methodological discussion into a commercial one.To conclude some recommendations to the attacking vendor (do not accuse me of not being an altruist)

1.      I think it isn’t such a good idea to attack best practices recommendation after a Service Provider tells a success story of adopting them.

2.      If you are a member, in a body, that according to you gives impractical recommendations, do something about it. Try to be more constructive, contribute to the community and help to formulate, what you consider to be, more practical and better recommendations.