The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
http://passionateaboutoss.com/oss-call-for-innovation/
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Who can make your OSS dance?

OSS tend to be powerful software suites that can do millions of things. Experts at the vendors / integrators know how to pull the puppet’s strings and make it dance. As a reader of PAOSS, chances are that you are one of those experts. I’ve sat through countless vendor demonstrations, but I’m sure you’ll still be able to wow me with a demo of what your OSS can do.

Unfortunately, most OSS users don’t have that level of expertise, nor experiences or training, to pull all of your OSS‘s strings. Most only use the tiniest sub-set of functionality.

If we look at the millions of features of your OSS in a decision tree format, how easy will it be for the regular user to find a single leaf on your million-leaf tree? To increase complexity further, OSS workflows actually require the user group to hop from one leaf, to another, to another. Perhaps it’s not even as conceptually simple as a tree structure, but a complex inter-meshing of leaves. That’s a lot of puppet-strings to know and control.

A question for you – You can make your OSS dance, but can your customers / users?

What can you do to assist users to navigate the decision tree? A few thoughts below:

  1. Prune the decision tree – chances are that many of the branches of your OSS are never / rarely used, so why are they there?
  2. Natural language search – a UI that allows users to just ask questions. The tool interprets those questions and navigates the tree by itself (ie it abstracts the decision tree from the user, so they never need to learn how to navigate it)
  3. Use decision support – machine assistance to guide users in navigating efficiently through the decision tree
  4. Restrict access to essential branches – design the GUI to ensure a given persona can only see the clusters of options they will use (eg via the use of role-based functionality filtering)

I’d love to hear your additional thoughts how to make it easier for users to make your  (their) OSS dance.

Linus’s Law of OSS defects

Given enough eyeballs, all bugs are shallow.”
Eric S. Raymond
, whose quote is now known as Linus’ Law in honour of Linus Torvalds.

In other words, if you have enough people looking at the code, someone will surely categorise the problem and then the community will also figure out a way to solve it.

The fragmentation of the OSS industry means that OSS eyeballs are spread across thousands of code bases. Based on the inverse of Linus’ Law, there’s an implication that OSS bugs are deep. In fact, there are so many defects and/or enhancements waiting to be resolved across our industry that only the highest priority tickets tend to get any eyeballs at all.

The open-source revolution has ensured that the code of the most important applications (I use the word “important” figuratively) get lots of eyeballs. It’s one of the reasons that I believe the next OSS revolution will come about when an open-source OSS (an OSS OSS??) starts getting a critical mass of eyeballs. That OSS OSS just needs to be compelling enough to draw the eyeballs to it.

This is one of the pillars in the Call for Innovation that will be released here on PAOSS shortly.

Call for Innovation by Swisscom, Telia and Proximus

Software Defined Networking (SDN) and Network Function Virtualization (NFV) are about to transform and disrupt the network operator industry.

That’s why Swisscom, Telia Company and Proximus, three leading telco providers from across Europe, are jointly issuing this unique Call for Innovation and invite startups and innovators developing “Next Generation Virtual Telco Functions & Services (SDN / NFV 2.0)” to apply until 23 October 2016.

The best startups will be able to pitch their solution in front of an expert jury and have the chance to be selected for a PoC project and future collaboration with all three telcos..
What we are looking for

The topics considered for this call are related to SDN/NFV development within the telecommunication industry. The baseline infrastructure for SDN/NFV is available and is largely based on the de-facto standards and open source-based systems of OpenStack/OPNVF/CloudFoundry. The next steps and next wave of innovations should be using that infrastructure for new networking functions, cloud-native implementation of existing network functions, and new Telco services we could offer in the market.”

From http://call-for-innovation.com/sdn-nfv

Let me start out with an apology. This is old news. The Swisscom / Telia Company / Proximus Call for Innovation closed nearly a year ago. However, I’m bringing it to your attention for what it means to the telco industry. It’s acknowledging that traditional suppliers to telcos are not always servicing the need for innovative approaches to the problems the telcos are facing. It’s targeting the long tail of innovation.

Whilst this is specifically seeking SDN/NFV innovations, what does a Call for Innovation look like for OSS? Keep an eye out here on PAOSS, as I’ll be publishing an OSS Call for Innovation shortly.

One of the biggest insights we had…

One of the biggest insights we had was that we decided not to try to manage your music library on the iPod, but to manage it in iTunes. Other companies tried to do everything on the device itself and made it so complicated that it was useless.”
Steve Jobs
.

How does this insight apply to OSS? Can this “off device” perspective help us in designing better OSS?

Let’s face it – many OSS are bordering on useless due to the complexity that’s build in to the user experience. So what complexity can we take off the “device?” Let’s start by saying “the device” is the UI of our OSS (although noting the off-device perspective could be viewed much more broadly than that).

What are the complexities that we face when using an OSS;

  • The process of order entry / service design / service parameters / provisioning can be time consuming and prone to errors,
  • Searching / choosing / tracing resources, particularly on large networks, can result in very slow response times,
  • Navigating through multiple layers of inventory in CLI or tabular forms can be challenging,
  • Dealing with fixed processes that don’t accommodate the many weird and wonderful variants that we encounter
  • Dealing with workflows that cross multiple integration boundaries and slip through the cracks,
  • Analysing data that is flawed generally produces flawed results
  • Identifying the proverbial needle in the haystack when something goes wrong
  • And many, many more

How can we take some of those complexities “off-device”

  • Abstracting order and provisioning complexity through the use of catalogs and auto-populating as many values as possible,
  • Using augmented decision support to assist operators through complex processes, choosing from layers of resources, finding root-causes to problems, etc,
  • Using event-based processes that traverse process states rather than fixed processes, particularly where omni-channel interactions are available to customers
  • Using inventory discovery (and automated build-up / tear-down in virtualised networks) and decision support to present simpler navigations and views of resources
  • Off-device data grooming / curation to make data analysis more intuitive on-device
  • etc

In effect, we’re describing the tasks of an “on-device” persona (typically day-to-day OSS operators that need greater efficiency) and “off-device” persona/s (these are typically OSS admins, configuration experts, integrators, data scientists, UI/UX experts, automation developers, etc who tune the OSS).

The augmented analytics journey

Smart Data Discovery goes beyond data monitoring to help business users discover subtle and important factors and identify issues and patterns within the data so the organization can identify challenges and capitalize on opportunities. These tools allow business users to leverage sophisticated analytical techniques without the assistance of technical professionals or analysts. Users can perform advanced analytics in an easy-to-use, drag and drop interface without knowledge of statistical analysis or algorithms. Smart Data Discovery tools should enable gathering, preparation, integration and analysis of data and allow users to share findings and apply strategic, operational and tactical activities and will suggest relationships, identifies patterns, suggests visualization techniques and formats, highlights trends and patterns and helps to forecast and predict results for planning activities.

Augmented Data Preparation empowers business users with access to meaningful data to test theories and hypotheses without the assistance of data scientists or IT staff. It allows users access to crucial data and Information and allows them to connect to various data sources (personal, external, cloud, and IT provisioned). Users can mash-up and integrate data in a single, uniform, interactive view and leverage auto-suggested relationships, JOINs, type casts, hierarchies and clean, reduce and clarify data so that it is easier to use and interpret, using integrated statistical algorithms like binning, clustering and regression for noise reduction and identification of trends and patterns. The ideal solution should balance agility with data governance to provide data quality and clear watermarks to identify the source of data.

Augmented Analytics automates data insight by utilizing machine learning and natural language to automate data preparation and enable data sharing. This advanced use, manipulation and presentation of data simplifies data to present clear results and provides access to sophisticated tools so business users can make day-to-day decisions with confidence. Users can go beyond opinion and bias to get real insight and act on data quickly and accurately.”
The definitions above come from a post by Kartik Patel entitled, “What is Augmented Analytics and Why Does it Matter?.”

Over the years I’ve loved playing with data and learnt so much from it – about networks, about services, about opportunities, about failures, about gaps, etc. However, modern statistical analysis techniques fall into one of the categories described in “You have to love being incompetent“, where I’m yet to develop the skills to a comfortable level. Revisiting my fifth year uni mathematics content is more nightmare than dream, so if augmented analytics tools can bypass the stats, I can’t wait to try them out.

The concepts described by Kartik above would take those data learning opportunities out of the data science labs and into the hands of the masses. Having worked with data science labs in the past, the value of the information has been mixed, all dependent upon which data scientist I dealt with. Some were great and had their fingers on the pulse of what data could resolve the questions asked. Others, not so much.

I’m excited about augmented analytics, but I’m even more excited about the layer that sits on top of it – the layer that manages, shares and socialises the aggregation of questions (and their answers). Data in itself doesn’t provide any great insight. It only responds when clever questions are asked of it.

OSS data has an immeasurable number of profound insights just waiting to be unlocked, so I can’t wait to see where this relatively nascent field of augmented analytics takes us.

Deciding whether to PoC or to doc

As recently discussed with two friends and colleagues, Raman and Darko, Proofs of Concept (PoC) or Minimum Viable Product (MVP) implementations can be a double-edged sword.

By building something without fully knowing the end-game, you are potentially building tech-debt that may be very difficult to work around without massive (or complete) overhaul of what you’ve built.

The alternative is to go through a process of discovery to build a detailed document showing what you think the end product might look like.

I’m all for leaving important documentation behind for those who come after us, for those who maintain the solutions we create or for those who build upon our solutions. But you’ll notice the past-tense in the sentence above.

There are pros and cons with each approach, but I tend to believe in documentation in the “as-built” sense. However, there is a definite need for some up-front diagrams/docs too (eg inspiring vision statements, use cases, architecture diagrams, GUI/UX designs, etc).

The two biggest reasons I find for conducting PoCs are:

  • Your PoC delivers something tangible, something that stakeholders far and wide can interact with to test assumptions, usefulness, usability, boundary cases, etc. The creation of a doc can devolve into an almost endless set of “what-if” scenarios and opinions, especially when there are large groups of (sometimes militant) stakeholders
  • You’ve already built something – your PoC establishes the momentum that is oh-so-vital on OSS projects. Even if you incur tech-debt, or completely overhaul what you’ve worked on, you’re still further into the delivery cycle than if you spend months documenting. Often OSS change management can be a bigger obstacle than the technical challenge and momentum is one of change management’s strongest tools

I’m all for deep, reflective thinking but that can happen during the PoC process too. To paraphrase John Kennedy, “Don’t think, don’t hope, (don’t document), DO!” 🙂

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?

Increasing the percentage of digital revenues

Digital revenues
The diagram above comes from research by AT Kearney and Delta Partners courtesy of an article by Mark Newman of TM Forum.

It provides an interesting perspective on CSPs‘ ability to “compete” with a broader, more digitally native group of service providers.

The golden age for CSPs was when they transported data from point A to point B (ie data and voice services) and people performed the value-add on top of those communications (ie business development, marketing, etc). DSPs have disrupted this model by now providing the value-added as digital services on top of base comms services (ie the over-the-top play).

The breadth of OTT services means that CSPs can’t possibly create the whole long tail of offerings. However, like DoCoMo, they can create partnerships and/or platforms that support the long tail of third-party offerings. It’s no coincidence that DoCoMo is the clear leader in the graph above as they have a long history of deriving revenues from third-party partnerships.

The question for an industry where 3.8% of revenues are from digital sources is not so much how to transition to an OTT model themselves, but how to provide digital delivery platforms that support third-party revenue streams and to do so more profitably (for all parts of the supply chain).

In desperate search of OSS flow

Flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does, and a resulting loss in one’s sense of space and time.”
Wikipedia.

It’s almost definitely no coincidence that a majority of the achievements I’m most proud of within the context of OSS have been originated outside business hours. I strongly believe it all comes down to flow. In a day that is punctuated by meeting after meeting, there is no flow, no ability to get into deep focus. In the world of transaction-based doing, there is rarely the opportunity to generate flow.

Every OSS project I’ve worked on has been in desperate need of innovation. That’s not a criticism, but a statement of the whole industry having so many areas in which improvement is possible. But on your current and/or past projects, how many have fostered an environment where deep focus was possible for you or your colleagues? Where have your greatest achievements been spawned from?

Jason Fried of Basecamp and 37signals fame is an advocate of building an environment where flow can happen and starts with manager and meeting minimisation. The best managers I’ve worked with have been great at facilitating flow for their teams and buffered them from the M&M noise.

How can we all build an OSS environment where the thinkers get more time to think… about improving every facet of ideating, creating, building and implementing?

A new, more sophisticated closed-loop OSS model

Back in early 2014, PAOSS posted an article about the importance of closed loop designs in OSS, which included the picture below:

OSS / DSS feedback loop

It generated quite a bit of discussion at the time and led me to being introduced to two companies that were separately doing some interesting aspects of this theoretical closed loop system. [Interestingly, whilst being global companies, they both had strong roots tying back to my home town of Melbourne, Australia.]

More recently, Brian Levy of TM Forum has published a more sophisticated closed-loop system, in the form of a Knowledge Defined Network (KDN), as seen in the diagram below:
Brian Levy Closed Loop OSS
I like that this control-loop utilises relatively nascent technologies like intent networking and the constantly improving machine-learning capabilities (as well as analytics for delta detection) to form a future OSS / KDN model.

The one thing I’d add is the concept of inputs (in the form of use cases such as service orders or new product types) as well as outputs / outcomes such as service activations for customers and not just the steady-state operations of a self-regulating network. Brian Levy’s loop is arguably more dependent on the availability and accuracy of data, so it needs to be initially seeded with inputs (and processing of workflows).

Current-day OSS are too complex and variable (ie un-repeatable), so perhaps this represents an architectural path towards a simpler future OSS – in terms of human interaction at least – although the technology required to underpin it will be very sophisticated. The sophistication will be palatable if we can deliver the all-important repeatability described in, “I want a business outcome, not a deployment challenge.” BTW. This refers to repeatability / reusability across organisations, not just being able to repeatedly run workflows within organisations.

From pipeline to platform

Amazon established an architecture to leverage its assets for implementing a wide range of business models in a repeatable way for the retail industry. In most cases, Amazon is exposing product offerings it doesn’t actually own. It carries some inventory for third parties, but its main tasks now are vetting retail partners, ensuring product quality, giving partners access to the marketplace, and arranging payment and delivery of purchases. The company’s business model is to provide an ever-growing number of products through a broad, simple solution that’s fast, efficient and highly effective.
A similar level of speed and efficiency is possible when the same approach is applied to an operator’s architecture. Easy access, exposure of product information, a managed ecosystem of partners, a simple solution that hides background complexity – many of the same things that make it so easy to shop with Amazon – can transform the way our products are created, modified, assembled, offered, personalized and delivered. In other words, operators need architectures that support platform business models analogous to the Amazon architecture to onboard offers from many, connecting suppliers to consumers and monetizing the end solution with settlement of payments to those involved. Many platforms are possible because of technology, but they’re successful because of trust among ecosystem partners, curator and consumers
.”
From TM Forum’s “Digital Platform Reference Architecture Concepts and Principles” (IG1157 Release 17.0.0)

A recent post entitled, “I want a business outcome, not a deployment challenge,” discussed cloud deployment, hosted service offerings and trust – three important considerations to the Amazon-style platform play for future CSP business models.

Neither the architecture or the trust currently tends to exist to allow most telcos to follow a model where, “its main tasks now are vetting retail partners, ensuring product quality, giving partners access to the marketplace, and arranging [e-]payment and [e-]delivery of purchases.” Some telcos are already going down the path of complete transformation to services-driven platforms (ie SOA). This is as much for offering (web) services to internal silos as it is to external customers.

The real platform play will only happen when the “internal” services are also opened up to third-parties to provide, not just consume.

How would Einstein or Darwin manage an OSS?

Here are a few questions I reflect on:
– Am I excited to be doing what I’m doing or am I in aimless motion?
– Are the trade-offs between work and my relationships well-balanced?
– How can I speed up the process from where I am to where I want to go?
– What big opportunities am I not pursuing that I potentially could?
– What’s a small thing that will produce a disproportionate impact?
– What could probably go wrong in the next 6 months of my life?

Zat Rana
on here on Business Insider.

The link above provides some insights into the way some of the world’s greatest innovators have tackled the challenges that lay before them. It espouses the benefits of Reflective Thinking versus the current mindset of Doing Thinking, as discussed here earlier.

If you were to follow Zat Rana’s suggestion of allocating two hours a week to reflective thinking, what are the seed questions you could ask? Would the list above work as a starting point? Perhaps something more specific to your situation?

Here are a few other possibilities:

  • Do I know what (my) OSS will look like in 5 years
  • Am I satisfied that (my) OSS is actually helping outside operations
  • What tangents could (my) OSS take to improve the world
  • Where does complexity stem from that impacts (my) OSS
  • Which areas can I pare back with negligible impact
  • What is the OSS moonshot that changes the landscape forever
  • What is my lead domino(es) (ie What’s a small thing that will produce a disproportionate impact?)
  • Have I thought about what might impact business continuity
  • How can I impact the bigger bodies (eg CSPs, vendors, standards bodies) around me

Is commission management the key for next-gen OSS?

Relationships with the things we ‘consume’ (rather than ‘own’) are increasing, and are being governed by ongoing supply arrangements between customers and vendors. What sits at the heart of these relationships, from a financial perspective, is billing. The entity that has the billing relationship with the customer essentially ‘owns’ the customer – they have the right to communicate with the customer regularly, and this can form the basis of a far deeper customer relationship.”
David Werdiger
in his article “The Own-Lease-Rent-Subscribe Continuum“.

The snippet above is just a small part of a very interesting article about asset utilisation and ownership structures. The continuum that David speaks of is increasingly presenting opportunities towards the subscribe / consume end and breaking down barriers to entry for those with entrepreneurial spirit.

This has implications for our OSS from a number of angles. OSS are typically expensive to buy or build or run, as are the networks that they manage. As a result, in years past the only opportunities arising from these assets were for their owners, the communications service providers (CSPs).

The subscribe end of the continuum allows CSPs to share the capital risk with customers, which has traditionally been done via the selling of comms services. But with comms services commoditising, innovative subscription models become a more attractive way of sharing the risk. These include virtual network operators, off-payroll sales agents, managed service offerings and the like.

We’ve spoken previously about how APIs allow third-parties to uplift and upsell services offered by CSPs. From a similar, but slightly different perspective, efficient / effective commission management functionality within your OSS / BSS effectively extends and incentivises the sales arm of any business (whether internal or external). You don’t need as many (any?) salespeople on the payroll, but you are still selling… if you incentivise the commission management process and associated earnings.

Whether additional selling and consumption is supported via human interfaces such as portal / UI or via machine interfaces such as API / microservices, it’s ultimately the billing that allows ownership of the customer. CSPs still have a significant strength from their billing base and clever design of our OSS / BSS can help to leverage that further in the consumption economy.

Are we passing right past the importance of thinking?

Are we spawning a maelstrom, the butterfly effect from all of our doing?

Yesterday’s post pondered the question of whether we’re getting entangled in our frenzy for doing.

I’ve been privileged to have worked in a dozen countries or more and even more privileged to be an Australian. Less proud am I though of the way of working that seems to pervade our corporate icons. I’ve worked within the halls of the largest telcos, banks and enterprises in Australia as well as their counterparts internationally. In my experience, the Australian versions don’t tend to compare well when it comes to efficacy. Why?

For a start, every organisation in this category that I’ve worked with automatically supplies a case-load of meetings (I sadly admit to being partly to blame as a meeting initiator) upon joining. Wall-to-wall meetings allows lots of talking, lots of posturing, but little remainder for doing. And with all this focus on doing (see yesterday’s post, link above), the little time left has to be “seen to be doing.”

Is there any time left over for thinking? Or helping?

If yesterday’s post is indeed true, that we’re creating a spaghetti of complexity in our frenzy of doing, are we passing right past the importance of thinking?

When was the last time you spent half a day (or even half an hour) in a quiet corner of your workplace thinking about how to make a workable OSS solution simpler, more elegant, more intuitive? Or trying to resolve the organisation’s most challenging challenges?

Does your corporate culture allow this to happen? During work hours?? Even if it did, would the culture allow it to be ripped to pieces in intellectual arm wrestling or democratic reasoning thereafter?

People pay for two things. What about OSS?

People pay for two things:
Results: You do something they couldn’t do for themselves.
Convenience: You do something they don’t want to do for themselves, or you make something difficult easier to do
.”
Ramit Sethi
.

I really like the way Ramit has broken down an infinite number of variants down to just two key categories. Off the top of my head, these categories of payment (ie perceived value) seem to hold true for most industries, but we can unpack how they align with OSS.

In traditional OSS, most of the functionality / capability we provide falls into the convenience category.

In assurance, we tend to act as aggregators and coordinators, the single pane of glass of network health and remedial actions such as trouble-ticketing. But there’s no reason why we couldn’t manage those alarms from our EMS and tickets through spreadsheets. It’s just more convenient to use an OSS.

In fulfilment, we also pull all the pieces together, potentially from a number of different systems ranging from BSS, inventory, EMS and more. Again, it’s just more convenient to use an OSS.

But looking into the future, with the touchpoint explosion, the sheer scale of events hitting our assurance tools and the elastic nature of fulfilment on virtualised networks means that humans can’t manage by themselves. OSS and high-speed decision support tools will be essential to deliver results.

One other slight twist on this story though. All of the convenience we try to create using our OSS can actually result in less convenience. If we develop 1,000 tools that, in isolation, do something they [our customers] don’t want to do for themselves, it adds value. But if those tools in aggregate slow down our OSS significantly, increase support costs (lifetime costs) and make them inflexible to essential changes, then it’s actually reducing the convenience. On this point I have a motto – Just because we can, doesn’t mean we should (build extra convenience tools into our OSS).

I’m an OSS, you need to trust me

We believe in nurturing a trust-based relationship with our partners to create effective innovative projects together.”

I won’t mention which vendor executive coined this phrase, but it’s representative of many vendors’ sentiments. Easy words to say, but harder to earn (individually or as an organisation) and harder still to prove to others.

OSS / BSS have typically used trust as an internal mechanism, a means to access (or restrict access to) our systems and their functionality. But a broader concept of trust is growing, one which OSS / BSS may choose to build upon.

You’ve heard of the Trust Economy, spawned from tech like Uber, AirBnB, etc, but in reality the economy has always been built on trust. It’s now a case of digital trust. In the global economy it’s harder to establish trust between partners who have never met.

In an OSS where functionality is built upon John Reilly’s Value Fabric, or supports any form of marketplace, then trust becomes an external construct (ie partners and customers). If our OSS are to become an external construct, revenue generators rather than cost centres, then this new layer of trust will begin to enter our universe.

This is where smart contracts and blockchain and associated identity / signatory management technologies intrigue me. How far away from reality are these technologies in our world of OSS?

The three big lies of the telecoms industry

What are the three big lies of the telecoms industry?
The first lie is that data monetisation is coming. Well we are still waiting.
The second is that we have billions of customers. Well are they really our customers or are they people who just tolerate us and are really customers of someone else?
The third lie is that we are utility so we have stable returns, and because we have spectrum allocations that is our safety net. EBITDA multiples for the telco industry were at around 6, while utilities were at multiples of 12 to 16, so it could not be said that telcos – which often had up to five competitors in markets – were utilities
.”
Alexey Reznikovich

Three valid points. OSS / BSS could be highly influential in whether these are actually lies or not.

Data:
If we think of data as carriage, that’s clearly not monetising for most telcos currently. Well, it does bring in revenues but at a diminishing rate per bit. If we think of data in terms of content (eg voice, video, text, etc), then there are some monetisation wins (eg Game of Thrones) but more content is coming on line so there is more supply, making the profitability tail longer. If we talk about data as insight (or supporting the generation of insights if selling analytics or API offerings) then this will never go out of fashion (although with more “insights” being generated, the bar will be raised on what is truly insightful)

Customers:
Alexey’s note here that our customers just tolerate us and are really customers of someone else possibly has some merit. It’s the reason why the OTT play has been so successful. I still have the sense that there is an implicit trust in our service providers, due to the long subscription/billing history, media / shareholder attention on them and regulation that governments place on them (even if not an implicit trust in their customer service). Not all OTT players have the same track record of regulatory governance. Some OTT providers are invisible, hidden somewhere out on the cloud. I feel that this could represent a strong opportunity in a world where crypto-currencies carry vastly more value than they do today.

Utilities:
This comes down to the business model of any given Telco and / or the regulatory frameworks they operate within. They could opt to go down the path of ubiquitous data (like ubiquitous voice of the distant past), or like most, they can go down the path of being a digital service provider. To be honest, there are probably quite a few incumbent providers that are probably more closely aligned to utility than DSP in the collective way of thinking within their workforce. That often transfers to their mindset in building OSS.

Channelling “Intel Inside” to improve the brand recognition of your OSS

During Intel’s marketing of “Intel Inside” they taught consumers to look for the Intel Inside logo as an assurance of quality. Consumers eventually came to see “Intel Inside” as a standard and began asking the question: “Why doesn’t your product use Intel processors?” This standard became so important that today it is one of the world’s largest co-operative marketing programs,where hundreds of computer companies license the use of the Intel Inside® logos.
The ingredient must be highly differentiated in order to add value to the overall brand. This means the ingredient should have a separate name and logo and overall purpose, because the added value comes from the extra identity. First and foremost, brands should not create confusion in the market. The main brand should be well established in the market before employing an ingredient branding strategy because the consumer needs first understand the core brand and then find additional value in the ingredient
.”
From an article about Ingredient Branding on Disenthrall.co.

When you think about the chips inside the multitude of electronic devices you own and use, how many brands could you identify? How many chipsets are differentiated enough to sway your decision on the device itself?

According to FastCompany, “If one thing distinguishes Intel’s innovative thinking, it is their 1990s strategy of branding a semiconductor chip as a valuable feature that consumers would look for when they purchased a computer. The campaign’s two decades of ubiquity make us forget this now, but at the time it was an incredibly novel approach to marketing. People bought computers because of the software, the specs, or a friend’s recommendation. Who cared about who made some tiny chip inside the box that you couldn’t even see?
But with the proliferation of PCs, and with consumers at a loss in trying to figure out what made one better than the other, Intel saw an opportunity, and so it took a major risk. Intel’s leadership was convinced this was the way to grow market share…

The “Intel Inside” initiative has arguably been the most successful ingredient marketing exercises in history. They’ve made the invisible visible.

To many users/customers, the achievements of our OSS are invisible, with other components getting the credit for outcomes that are heavily underpinned by our OSS. The challenge for us, just like Intel, is to differentiate and improve the value of our brand. We get the flak for when things go wrong (often through no fault of our own), but we rarely get the credit for the things that work – for the services activated, for the problems resolved, for the equipment ordered, for the new services enabled, for the insights gleaned, etc.

The question for us all is how to make those accomplishments, that differentiation, the brand value visible. [Note that I’m referring to the brands of internal OSS suites here, not just external vendor products]

If we think about making the invisible visible to key execs / sponsors / stakeholders, we need to think about how they tend to interact with OSS. I would surmise that in most cases they interact via reports. Assuming you’re confident that you’ve nailed the content of your reports, that they’re succinct and valuable to those stakeholders, is there any reason why we couldn’t put our equivalent of the “Intel Inside” badge on the reports?

But first, are you confident that the badge is a badge of honour? Will your brand instil in customers a sense of quality, assuredness and innovation?

…And it works with Alexa

In the past we’ve posed the concept of using a search front-end as a user friendly interface to the OSS of the future.

This UI would have the ability to poll all of the disparate systems that make up an OSS / BSS stack and curate responses. The front-end would need to be smart, but I wonder whether its clever curation of data would actually reduce the hard integration between lower-level systems.

And then you bolt Alexa onto it, using custom skills and leveraging the vast library of existing Alexa skills such as chat bot automation

Do you have a whole lot of swivel-chairing going on between your OSS tools? Do you regularly need to combine your OSS / BSS data with other data sourced from the public domain (eg share prices, customer activities, competitor slip-ups, etc)?

Let Alexa fill in the gaps. 🙂