Archive

Archive for June, 2011

Changing from Telco Grade to Web 2.0 Grade by fighting telecom myths

Most telecom operators are still thinking that software should be upgraded at most twice a year. Oracle RAC is the only valid database solution. RFQ’s bring innovation. If you pay higher software licenses, the software will have more features and as such will be better.

All of these myths will have to be changed in the coming 12 months if operators want to be stay on top of the game.

Upgrade twice a year

For telecom network equipment, two upgrades a year are fine. However for everything related to services that are offered to consumers or businesses, that means that operators are 180 times less competitive then their direct competition. The large dotcoms like Facebook and Google make software upgrades on a daily basis. 50% of all the files that contain Google software code change every month. Even if “a revolution” would happen and software upgrades would come every month, it would still mean a 30 times lag.

Operators need to start using cloud computing, even if they are private clouds, to deploy their back-office systems. The business needs software solutions to move at market speed. That means that if a new social networking site is hot, then it should be integrated into telecom solution offerings in days. Not in months or a year.

There are many techniques to make deployments more predictable, more frequent and more reliable. Offering extra features or integrations quickly can be done via plugins. You can have a group of early adopters, give feedback. If they don’t survive this feedback, kill them. If they do, scale up quickly.

Oracle RAC

Nothing bad about the quality of Oracle RAC but it is a very expensive solution that needs a lot of man-power to keep on running smoothly. Operators often pay a premium for services that could run equally well on cheaper or Open Source alternatives. Also NOSQL should be embraced.

If the cost of deploying a new service is millions, then only a couple of them will be deployed. By lowering hardware and software costs, innovative projects are more likely to see daylight.

RFQ’s and Innovation

It takes 3 months from idea to finalizing an RFQ document. 1,5 month to get a reply. 1,5 month to do procurement. Half a year in total. Not counting the deployment time which is likely to be another 6 months. The result is that the operator takes 12 months for any “new” system.

Now the question is if that system is really new. Because if an operator was able to define in detail what they want and how they want it, then the technology was probably quite mature to begin with. So operators spend fortunes installing yesterday’s technology 12 months late. Can anybody explain what innovation this is going to bring?

First of all operators should not organize multi-million RFQs for business or end-user solutions. These are likely to come late to market and can only be focused on mass markets.

Instead operators should focus on letting the customer decide what they want by offering a large open eco-system of partners the possibility to offer a very large list of competing services to their customers. The operator should offer open APIs to key assets (charging, numbering plans, call control, network QoS, etc.). As well as offer revenue share and extra services like common marketplaces and support 2.0 (social CRM, helpdesk as a service, etc.). This is called Telecom Platform-as-a-Service or Telco PaaS.

High licenses, more features, better

More features does not mean better. Most people want simplicity, not a long list of features. Easy of use comes at a premium price. Look at Apple’s stock price if you don’t believe it.

It is better to have basic systems that are extremely easy to use with open APIs and plug-ins. A feature by feature comparison will make you choose the most expensive one. However it is hard to put as a feature that the system needs to be easy to use.

In telecom, there is a natural tendency to make things hard. In Web 2.0 the tendency is the opposite. You can see the difference between Nokia and Apple. The Nokia phone would win every feature on feature comparison but the iPhone is winning the market battle…

Instead of organizing an RFP, let end-users and employees play around with early betas or proof-of-concepts. No training, no documentation. Let’s see which solution makes them more productive, the feature rich or the more straight forward. Just ask open APIs and a plugin-mechanism and you will be set…

Are telecom operators like stamp vendors in a world of email dominance?

After speaking with several cloud telephony startups, it looks like telecom operators are like stamp vendors in a world of email dominance. The Innovator’s Dilemma seems to be claiming another victim soon.

CxO’s in existing telecom operators should be really worried. The major telecom cashcows are in danger. Calls and SMS will be substituted by apps like Voxtrot, Skype, etc. Access networks will be under extreme load when heavy smartphone, tablet and M2M usage will become mainstream. Also aggressive bitpipe LTE providers can have a Ryanair effect on the telecom world. Finally business solutions like PBX, etc. look antiquated compared to solutions like Invox, OpenVBX, Ringcentral, etc.

So what should operators do?

First let’s talk about what they should not do. Business as usual is not the ideal strategy. Telecom assets are likely to be substituted in the next 2-3 years, just as location has already been substituted.

Embrace Over-the-Top Player

Only few operators have done so but the best strategy to avoid disruptive competition is to embrace disruptive players. Trying to compete with on-premise equipment against IP-based Cloud-driven PBX-like services is impossible. Allow over-the-top players to offer their solutions to your customers and integrate with your network and your billing systems. Allow end-users a choice of competing solutions.

Expose Assets

If you protect your assets from the rest of the world, then over-the-top players will find ways around them. Location has been substituted. There is a lot of effort being put in setting up micro-payment solutions. If operators want to keep an oligopoly on charging and billing then they should urgently open up both assets and make them available at very competitive prices.

Other assets to open up: numbering plans, call forwarding, subscriber data (either via opt-in or via anonymous aggregation), etc.

Assets should be made available with Web 2.0 APIs. New business models like freemium, subscription and advertisement should be put into competition with usage-based subscriptions.

Open marketplaces

End-users want choice and operators have been traditionally bad at offering it. Nobody wants a Facecopy, Smitter or a LinkedOn. End-users want the original. End-users want to choose themselves between competing products.

Open marketplaces in which developers, partners, end-users, etc. can sell solutions and services that are integrated with the telecom assets, should allow end-users to have an “App-Store”-like experience when they interact with their operator.

The operator should be a business enabler for small companies. Innovative products should be brought in via open communities and partners. The operator offers the infrastructure for small companies to act like global players: e.g. global sales channels, professional support, integrate assets once – deploy globally, etc.

Support 2.0

End-users, be it consumers or businesses, need support. Dotcoms have been traditionally limited when it comes to offering phone support. However a lot of people do not feel like writing a web-based support ticket. Here is where operators could excel. Operators could work on building global support communities in which small companies get access to “call centers as a service”, “professional helpdesk as a service”, etc. A 5 people company should be able to offer global support via local certified partners and a common infrastructure that is offered by operators.

Operators as business enablers

Operators will only be able to survive the Innovator’s Dilemma if they start refocusing their businesses. Instead of being a selector of hand-picked high-priced services, operators should move to open markets where competing services are offered by thousands of partners. The operator moves from offering the services to becoming an enabler for others to offer services that are either based on the communication infrastructure but could also not be based on them. Operators have brands, offer trust, offer phone support, have direct sales channels, know the local markets, etc. Global small dotcoms could save enormous investments if operators would open these non-technology assets towards them and enable dotcoms to become global businesses for as small as they are in the beginning…

Operators should act like VCs when it comes to innovation

Operators have an addiction to use RFQ processes. The problems with those processes are:

  • They take a long time.
  • They are not useful when technology is not well understood.
  • They are only applicable to solutions whereby there are multiple providers.

Basically an RFQ will always bring you yesterday’s technology. After integrating this technology, when you launch you will be working with the day-before-yesterday’s technology. Google and others are working on tomorrow’s technology. Launching an innovative service via an RFQ process is as such almost impossible.

If you want to launch innovative, and new revenue generating, services that bring you back into the game, then the first thing that you need to accept is that RFQ’s are not your answer. So what is the alternative?

Innovation is about trying and accepting failure as a natural step towards success. You need to do everything to quickly detect failure so you do not spend too much effort on such solutions. How can you do this?

Forget asking marketing experts or even doing market studies, etc. Do you know any expert that would have predicted the success of Facebook?

The answer is to form small teams, called tiger teams. 1 functional/sales expert and 5 technical experts is a nice size. These teams should be isolated from the rest of the organization. Ideally the teams are mixed with members from partners or suppliers that know about a specific domain.

Additionally the tiger teams should have access to some innovation framework that helps them use some of the internal assets without having to do real deep integrations.

Finally the tiger teams should have access to part of your website,e.g. labs.operatorname.com, where they can launch their creations and get immediate feedback from beta users.

Operators should invest in these teams as would a VC. You get a little bit of money in the first round. Just enough to get me a prototype in 1 to 3 months. Afterwards we look for 1 to 2 months to see if there are beta users that like the solution. If not, we kill it.

If the solution is interesting for end-users or businesses then the next round of spending should come. However ideally operators start working together with other operators that are not competing and jointly invest. This way, your tiger team might not have given any result this month but the tiger team of your neighbouring operator might. By jointly investing, the cost to get the first commercial version is a lot lower.

The tiger team should not switch off the beta and start working on version 1.0. Instead it should use a social CRM to get feedback from early adopters. The roadmap should be steered by the community of early adopters. The service should with their guidance go from alpha to 1.0 in a maximum of 6 months.

As soon as the service is live, then it should be extended to all the other operators that also invested in it. Via Cloud Computing, it would be possible that this service is only installed in one place and offered to multiple operators with a minimum integration. Partners could even take over all costs of operations in exchange of a revenue share.

Once version 1.0 is reached, it is time to focus on offering open APIs and plugins so the community can start extending the solution and not necessarly the operators.

%d bloggers like this: