OSS come in all shapes and sizes

As the OSS vendors / suppliers page here on PAOSS shows, there are a LOT of different OSS options, making it an extremely fragmented market. But there’s something of a reason for that fragmentation – customer requirements for OSS come in all shapes and sizes. Here are four of the major categories that I’ve been lucky enough to work on.

Tier 1 telcos – the OSS of these organisations tend to be best classified as having to cope with scale. Scale comes in multiple dimensions. The number of network devices under management tend to be large, as do the types of device. The number of subscribers and customer services tend to be large, not to mention having large amounts of change occurring on a daily basis. The number of process variants and system integrations also tend to be large. And being at scale means that they’re more likely to be able to justify the cost of customisations and automations – either to off-the-shelf products or via purpose-built tools. Budgets, both CAPEX and OPEX, also tend to be large. Except where niche slices of the total OSS suite are being delivered, the vendors that service this market are also large in terms of revenues, but also in their number of services staff available to service the customer’s unique needs. In the case of the telco, the business (and revenue model) is built around the network so it gets the clear attention of the organisation’s executives.

Enterprise customers – these OSS tend to be at the other end of the spectrum, even when the enterprise is large (eg banks). Networks tend to be more homogeneous, being IT/IP-centric. Services tend to be less customer-specific (ie for journaling costs at a business unit level rather than individual subscribers) but follow ITSM process models, so the service management daily delta is not at the same scale as the Tier 1 telco. For enterprise customers, the network is rarely core business, even if it is mission-critical to the business. As such, attention and budgets tend to be much smaller. In turn, this means that the smaller, self-service or open-source OSS products / suppliers tend to be present in this segment.

Then there are two categories of organisation that fit between the two previous ends of the spectrum:

Tier 2/3 telcos, MVNOs and data centres – Similar to the Tier-1 telco, just not at the same scale, which has implications on the nature of their OSS. They generally need all the same types of OSS tools as the T1s, just not catering for the same number of variants. Due to cost constraints, there may be one or a few significant OSS building blocks such as inventory, assurance or orchestration, but often there will also be enterprise-grade and/or open-source products in their OSS stack. CAPEX and OPEX budgets are smaller, so clever jack-of-all-trades OSS experts are often on the operational teams delivering sophisticated solutions on shoe-string budgets. Some of the best OSS experts I’ve come across can trace their roots back to these origins.

Utilities – the OSS of these organisations are a fascinating mix of the first two categories above because enterprise-grade OSS often aren’t really fit-for-purpose and carrier-grade OSS doesn’t quite suit either. Except in the case of multi-utilities (eg power + telco), these organisations tend to have very little service management change, mainly because they tend to have few to no external customers. This makes them similar to enterprise OSS. But like telcos, they often have networks that are more varied than your typical IT/IP-centric networks under management in enterprise-land. They often have less common network topologies and protocols, including older and even proprietary models that enterprise-grade OSS rarely support without expensive mediation. Just like the enterprise, the telco network (and hence the OSS) of a utility is not core business and can’t be justified through driving incremental revenues. However, it is generally mission-critical to the core business (eg tele-protection circuits are in place to ensure resilience of the electricity supply across the power network). As such, telco Network health / reliability and asset management tend to be the main focus of these OSS. And whereas telcos can delegate some responsibility for network security to their customers (using the dumb-pipe excuse), utilities bear full responsibility for the security of their telco networks and the critical infrastructure that these networks and OSS tools support.

These are only broadly general categories and there are more than 50 shades of grey in between. Are there any other broad categories that you feel I’m missing?

What to read from a simple little OSS job advertisement from AWS

Not sure if you noticed, but AWS posted this job advertisement on LinkedIn a couple of days ago – Business Portfolio Leader – Telecom OSS/BSS Solutions.

The advertisement includes the following text:
Amazon Web Services (AWS) is leading the next paradigm shift in computing and is looking for a world class candidate to manage an elite portfolio of strategic AWS technology partners focused on the Operation support System (OSS) and Business Support System (BSS) applications within telecommunications segment. Your job will be to use these strategic partners to develop OSS and BSS applications on AWS infrastructure and platform.”

How do you read this advertisement? I have a few different perspectives to pose to you:

I can’t predict AWS’ future success with this initiative, but I’m assuming they’re creating the role because they see a big opportunity that they wish to capture. They have plenty of places they could otherwise invest, so they must believe the opportunity is big (eg the industry of OSS suppliers selling to CSPs is worth multi-billions of dollars and is waiting to be disrupted).

OSS/BSS are typically seen by CSPs as a very expensive (and risky) cost of doing business. I’m certain there’s a business model for any organisation (possibly AWS and its tech partners) that can significantly improve the OSS/BSS delivery costs/risks for CSPs.

The ad identifies CSPs (specifically the term, “major telecom infrastructure providers”) as the target customer. You could pose the concept that the CSPs won’t want to support a competitor in AWS. The CSPs I’m dealing with can’t get close to matching AWS cost structures so are partnering with AWS etc. Not just for private cloud, but also public and hybrid cloud too. The clip-the-ticket / partnership selling model appears to be becoming more common for telcos globally, so the fear-of-competition barrier “seems” to be coming down a little.

The other big challenge facing the role is network and data security. What’s surprised me most are core network services like directory services (used for internal authentication/AAA purposes). I never thought I’d see these outsourced to third-party cloud providers, but have seen the beginnings of it recently. If CSPs consume those, then OSS/BSS must be up for grabs at some CSPs too. For example, I’d imagine that OSS/BSS tools were amongst the 1,000 business apps that Verizon is moving to AWS.

The really interesting future consideration could be the advanced innovation that AWS et al could bring to the OSS space, and in ways that the telcos and OSS suppliers simply can’t. This recent post showed Google’s intent to bring AI to network operations. It could revolutionise the OSS/BSS industry. Not just for CSPs, but for their customers as well (eg their enterprise-grade OSS). Could it even represent another small step towards the OSS Doomsday Scenario posed here?

And just who are the “strategic partners” that AWS is referring to? I assume this old link might give at least one clue.

I’m certainly no Nostradamus, so I’d love to get your opinions on what ramifications this strategic hire will have on the OSS/BSS industry we know today.

How to kill the OSS RFP (part 3)

As the title suggests, this is the third in a series of articles spawned by TM Forum’s initiative to investigate better procurement practices than using RFI / RFP processes.

There’s no doubt the RFI / RFP / contract model can be costly and time-consuming. To be honest, I feel the RFI / RFP process can be a reasonably good way of evaluating and identifying a new supplier / partner. I say “can be” because I’ve seen some really inefficient ones too. I’ve definitely refined and improved my vendor procurement methodology significantly over the years.

I feel it’s not so much the RFI / RFP that needs killing (significant disruption maybe), but its natural extension, the contract development and closure phase that can be significantly improved.

As mentioned in the previous two parts of this series (part 1 and part 2), the main stumbling block is human nature, specifically trust.

Have you ever been involved in the contract phase of a large OSS procurement event? How many pages did the contract end up being? Well over a hundred? How long did it take to reach agreement on all the requirements and clauses in that document?

I’d like to introduce the concept of a Minimum Viable Contract (MVC) here. An MVC doesn’t need most of the content that appears in a typical contract. It doesn’t attempt to predict every possible eventuality during the many years the OSS will survive for. Instead it focuses on intent and the formation of a trusting partnership.

I once led a large, multi-organisation bid response. Our response had dozens of contributors, many person-months of effort expended, included hundreds of pages of methodology and other content. It conformed with the RFP conditions. It seemed justified on a bid that exceeded $250M. We came second on that bid.

The winning bidder responded with a single page that included intent and fixed price amount. Their bid didn’t conform to RFP requests. Whereas we’d sought to engender trust through content, they’d engendered trust through relationships (in a part of the world where we couldn’t match the winning bidder’s relationships). The winning bidder’s response was far easier for the customer to evaluate than ours. Undoubtedly their MVC was easier and faster to gain agreement on.

An MVC is definitely a more risky approach for a customer to initiate when entering into a strategically significant partnership. But just like the sports-star transfer comparison in part 2, it starts from a position of trust and seeks to build a trusted partnership in return.

This is a highly contrarian view. What are your thoughts? Would you ever consider entering into an MVC on a big OSS procurement event?

How to kill the OSS RFP

TM Forum is currently investigating ways to procure OSS without resorting to the current RFI / RFP approach. It has published the following survey results.
Kill the RFP.

As it shows, the RFI / RFP isn’t fit for purpose for suppliers and customers alike. It’s not just the RFI/RFP process. We could extend this further and include contract / procurement process that bolts onto the back of the RFP process.

I feel that part of the process remains relevant – the part that allows customers to evaluate the supplier/s that are best-fit for the customer’s needs. The part that is cumbersome relates to the time, effort and cost required to move from evaluation into formation of a contract.

I believe that this becomes cumbersome because of trust.

Every OSS supplier wants to achieve “trusted” status with their customers. Each supplier wants to be the source trusted to provide the best vision of the future for each customer. Similarly, each OSS customer wants a supplier they can trust and seek guidance from.”
Past PAOSS post.

However, OSS contracts (and the RFPs that lead into them) seem to be the antithesis of trust. They generally work on the assumption that every loophole must be closed that a supplier or vendor could leverage to rort the other.

There are two problems with this:

  • OSS transformations are complex projects and all loopholes can never be covered
  • OSS platforms tend to have a useful life of many years, which makes predicting the related future requirements, trends, challenges, opportunities, technologies, etc difficult to plan for

As a result, OSS RFI/RFP/contracts are so cumbersome. Often, it’s the nature of the RFP itself that makes the whole process cumbersome. The OSS Radar analogy shows an alternative mindset.

Mark Newman of TM Forum states, “…the telecoms industry is transitioning to a partnership model to benefit from innovative new technologies and approaches, and to make decisions and deploy new capabilities more quickly.”
The trusted partnership model is ideal. It allows both parties to avoid the contract development phase and deliver together efficiently. The challenge is human nature (ie we come back to trust).

I wonder whether there is merit in using an independent arbiter? A customer uses the RFI/RFP approach to find a partner or partners, but then all ongoing work is evaluated by the arbiter to ensure balance / trust is maintained between customer (and their need for fair pricing, quality products, etc) and supplier (and their need for realistic requirements, reasonable payment times, etc).

I’d love to hear your thoughts and experiences around partnerships that have worked well (or why they’ve worked badly). Have you ever seen examples where the arbitration model was (or wasn’t) helpful?

Why does everyone know an operator’s business better than the operator?

The headline today blatantly steals from a post by William Webb. You can read his entire, brilliant post here. All quotes below are from the article.

William’s concept aligns quite closely with yesterday’s article regarding external insights that don’t quite marry up with the real situation faced by operators.

At the Great Telco Debate this week there was no shortage of advice for operators. Some counselled them to move up the value chain or branch out into related areas. Others to build “it” so that they would come… But there were no operators actually talking about doing these things.”
Funny because it’s true.

In most industries the working assumption is that a company knows its customers better than outsiders… But this assumption of knowing your customers seems not to hold in the mobile telecoms industry. It appears that the industry assumes that the mobile operators do not know their customers, but that they – the suppliers generally – understand them better.
Interesting. So this is a case of the suppliers purportedly knowing their customer (the operators) but also their customer’s customer (the end-users of comms services). This concept is almost definitely true of network suppliers. I don’t feel that this is common for OSS suppliers though. In fact it’s an area that could definitely be improved upon – an awareness of our customers’ customers.

At the Great Telco Debate, Nokia spoke about how the telcos needed to be bold, to build networks [eg 5G] for which there was no current business plan on the basis that revenue streams would materialise. Telling your customer to do something which cannot be justified economically seems a risky way to ensure a good long-term relationship.

I actually laughed out loud at the truth behind this one. So many related stories to tell. Another day perhaps!

The operators have been advised for decades that they are in a business that is increasingly becoming a utility and that they need to “move up the value chain” or find some other growth opportunity. This advice seems to be predicated on the view that nobody wants to be a utility, that it is essential for organisations to grow, and that moving around the value chain is easy to do. All merit further investigation. Utility businesses are stable, low-risk and normally profitable. Many companies do not grow but thrive nevertheless. But most problematic, mobile operators have been trying to “move up the value chain” for many years, with conspicuous lack of success.”

The CSP vs DSP business model. There is absolutely a position for both speeds in the telco marketplace. Which is better? Depends on your investment objectives and risk/reward profile.

Most operators, sensibly, appear to be ignoring all this unsolicited advice and getting on with running their networks reliably while delivering ever-more data capacity for ever-lower tariffs. Of course, they listen to ideas emanating from around the industry, but they know their business, their financial constraints, and their competitive and regulatory environment.”

As indicated in yesterday’s post, every client situation is different. We might look at the technical similarities between projects, but differences go beyond that. A supplier or consultant can’t easily replace local knowledge across financial and regulatory environments especially.

OSS answers that are simple but wrong vs complex but right

We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills…”
John F Kennedy
.

Let’s face it. The business of running a telco is complex. The business of implementing an OSS is complex. The excitement about working in our industry probably stems from the challenges we face, but the impact we can make if/when we overcome them.

The cartoon below tells a story about telco and OSS consulting (I’m ignoring the “Science vs everything else” box for the purpose of this post, focusing only on the simple vs complex sign-post).

Simple vs Complex

I was recently handed a brochure from a consulting firm that outlined a step-by-step transformation approach for comms service providers of different categories. It described quarter-by-quarter steps to transform across OSS, BSS, networks, etc. Simple!

The problem with their prescriptive model was that they’d developed a stereotype for each of the defined carrier categories. By stepping through the model and comparing against some of my real clients, it was clear that their transformation approaches weren’t close to aligning to any of those clients’ real situations.

Every single assignment and customer has its own unique characteristics, their own nuances across many layers. Nuances that in some cases are never even visible to an outsider / consultant. Trying to prepare generic, but prescriptive transformation models like this would seem to be a futile exercise.

I’m all for trying to bring repeatable methodologies into consulting assignments, but they can only act as general guidelines that need to be moulded to local situations. I’m all for bringing simplification approaches to consultancies too, as reflected by the number of posts that are categorised as “Simplification” here on PAOSS. We sometimes make things too complex, so we can simplify, but this definitely doesn’t imply that OSS or telco transformations are simple. There is no one-size-fits-all approach.

Back to the image above, there’s probably another missing arrow – Complex but wrong! And perhaps another answer with no specific path – Simple, but helpful in guiding us towards the summit / goal.

I can understand why telcos get annoyed with us consultants telling them how they should run their business, especially consultants who show no empathy for the challenges faced.

But more on that tomorrow!

The Theory of Evolution, OSS evolution

Evolution says that biological change is a property of populations — that every individual is a trial run of an experimental combination of traits, and that at the end of the trial, you are done and discarded, and the only thing that matters is what aggregate collection of traits end up in the next generation. The individual is not the focus, the population is. And that’s hard for many people to accept, because their entire perception is centered on self and the individual.”
FreeThoughtBlog.

Have we almost reached the point where the same can be said for OSS workflows? In the past (and the present?) we had pre-defined process flows. There may be an occasional if/else decision gate, but we could capture most variants on a process diagram. These pre-defined processes were / are akin to a production line.

Process diagrams are becoming harder to lock down as our decision trees get more complicated. Technologies proliferate, legacy product lines don’t get obsoleted, the number of customer contact channels increases. Not only that, but we’re now marketing to a segment of one, treating every one of our customers as unique, whilst trying not to break our OSS / BSS.

Do we have the technology yet that allows each transaction / workflow instance to just be treated as an experimental combination of attributes / tasks? More importantly, do we have the ability to identify any successful mutations that allow the population (ie the combination of all transactions) to get progressively better, faster, stronger.

It seems that to get to CX nirvana, being able to treat every customer completely uniquely, we need to first master an understanding of the population at scale. Conversely, to achieve the benefits of scale, we need to understand and learn from every customer interaction uniquely.

That’s evolution. The benchmark sets the pattern for future workflows until a variant / mutation identifies a better benchmark to establish the new pattern for future workflows, which continues.

The production line workflow model of the past won’t get us there. We need an evolution workflow model that is designed to accommodate infinite optionality and continually learn from it.

Does such a workflow tool exist yet? Actually, it’s more than a workflow tool. It’s a continually improving loop workflow.

That’s not where to disrupt your OSS

The diagram below comes from an actual client’s functionality usage profile.
Long tail of OSS

The x-axis shows the functionality / use-cases. The y-axis shows the number of uses (it could equally represent usefulness or value).

Each big-impact demand (ie individual bars on the left-side of the graph) warrants separate investigation. The bars on the right side (ie the long tail in the red box) don’t. They might be worth investigating if we could treat some/all as a cohort though.

The left side of the graph represent the functionality / use-cases that have been around for decades. Every OSS has them. They’re so common and non-differentiated that they’re not remotely sexy. Customers / stakeholders aren’t going to be wowed by them. They’re just going to expect them. Our product developers have already delivered that functionality, have moved on and are now looking for new things to work on.

And where does the new stuff reside? Generally as new bars on the right side of the graph. That’s the law of diminishing returns territory right there! You’re unlikely to move the needle from out there.

Does this graph convince you to send your most skilled craftsmen back to do more tinkering / disrupting at the left side of the graph… as opposed to adding new features at the right side? Does it inspire you to dream up exciting cohort management techniques for the red box? Perhaps it even persuades you to cull some of the long-tail features that are chewing up lifecycle effort (eg code management, regression testing, complexity tax)?

If it does convince you, don’t forget to think about how you’re going to market it. How are you going to make the left side sexy / differentiated again? Are you going to have to prove just how much easier, cheaper, faster, more efficient, more profitable, etc it is? That brings us back to the OSS proof-of-worth discussion we had yesterday. It also brings us back to Sutton’s Law – go to where the money is.

The OSS proof-of-worth dilemma

Earlier this week we posted an article describing Sutton’s Law of OSS, which effectively tells us to go where the money is. The article suggested that in OSS we instead tend towards the exact opposite – the inverse-Sutton – we go to where the money isn’t. Instead of robbing banks like Willie Sutton, we break into a cemetery and aimlessly look for the cash register.

A good friend responded with the following, “Re: The money trail in OSS … I have yet to meet a senior exec. / decision maker in any telco who believes that any OSS component / solution / process … could provide benefit or return on any investment made. In telco, OSS = cost. I’ve tried very hard and worked with many other clever people also trying hard to find a way to pitch OSS which overcomes this preconception. BSS is often a little easier … in many cases it’s clear that “real money” flows through BSS and needs to be well cared for.”

He has a strong argument. The cost-out mentality is definitely ingrained in our industry.

We are saddled with the burden of proof. We need to prove, often to multiple layers of stakeholders, the true value of the (often intangible) benefits that our OSS deliver.

The same friend also posited, “The consequence is the necessity to establish beneficial working relationships with all key stakeholders – those who specify needs, those who design and implement solutions and those, especially, who hold or control the purse strings. [To an outsider] It’s never immediately obvious who these people are, nor what are their key drivers. Sometimes it’s ambition to climb the ladder, sometimes political need to “wedge” peers to build empires, sometimes it’s necessity to please external stakeholders – sometimes these stakeholders are vendors or government / international agencies. It’s complex and requires true consultancy – technical, business, political … at all levels – to determine needs and steer interactions.

Again, so true. It takes more than just technical arguments.

I’m big on feedback loops, but also surprised at how little they’re used in telco – at all levels.

  • We spend inordinate amounts of time building and justifying business cases, but relatively little measuring the actual benefits produced after we’ve finished our projects (or gaining the learnings to improve the next round of business cases)
  • We collect data in our databases, obliviously let it age, realise at some point in the future that we have a data quality issue and perform remedial actions (eg audits, fixes, etc) instead of designing closed-loop improvement cycles that ensure DQ isn’t constantly deteriorating
  • We’re great at spending huge effort in gathering / arguing / prioritising requirements, but don’t always run requirements traceability all the way into testing and operational rollout.
  • etc

Which leads us back to the burden of proof. Our OSS have all the data in the world, but how often do we use it to justify and persuade – to prove?

Our OSS products have so many modules and technical functionality (so much of it effectively duplicated from vendor to vendor). But I’ve yet to see any vendor product that allows their customer, the OSS operators, to automatically gather proof-of-worth stats (ie executive-ready reports). Nor have I seen any integrator build proof-of-worth consultancy into their offer, whereby they work closely with their customer to define and collect the metrics that matter. BTW. If this sounds hard, I’d be happy to discuss how I approach this task.

So let me leave you with three important questions today:

  1. Have you also experienced the overwhelming burden of the “OSS = cost” mentality
  2. If so, do you have any suggestions / experiences on how you’ve overcome it
  3. Does the proof-of-worth product functionality sound like it could be useful (noting that it doesn’t even have to be a product feature, but a custom report / portal using data that’s constantly coursing through our OSS databases)

Sutton’s Law of OSS

Willie Sutton was an accomplished bank robber, particularly during the 1920s and 1930. Named after Willie, Sutton’s Law effectively states, “I go to where the money is,” which was supposedly Sutton’s response to a reporter’s question asking why he robbed banks instead of easier targets.

Interestingly for the OSS industry, we seem to follow the inverse of Sutton’s Law. We go to where the money isn’t. In other words, we mostly attempt to build business cases around the “cost-out” model, helping our customers achieve cost savings. These savings are in the form of automations that lead to reductions in head-count, cost of doing business, etc. Think about the common buzz-words – AI, machine learning, virtualisation, etc. Are they Sutton, or inverse-Sutton?

Truth be told, we do still go to where the money is because our customers (the network operators) are willing to spend money to save even more money. But you can see where I’m coming from can’t you?

Let me pose a question for you? Who is more likely to be comfortable spending money, someone who is confident in making money from the investment or someone who is going to save money from an investment?

I’d back Sutton’s Law and respond with the former. But we don’t tend to follow Sutton’s Law very often. It can often be challenging because so many of the benefits of our OSS and BSS are intangible. We’re seen as cost centres because we don’t do a good enough job of showing how important we are at operationalising everything that happens in a service provider’s network (and business).

At TM Forum’s DTA event a couple of weeks ago, I was pleased to see that some of the big telco API initiatives (eg Telkomsel, Telstra’s Network as a Service [NaaS] and China Mobile’s Data Security and Privacy Management Framework) are starting to make a real impact. The API model represents our strongest industry-wide push towards revenue-based business cases in years (that I can remember anyway).

Monty Hong of Telkomsel (Indonesia) made a presentation that provides a useful guide for future telco value-stream / revenue-models, effectively showing Sutton’s Law at play:
http://passionateaboutoss.com/how-oss-bss-facilitated-telkomsels-structural-revenue-changes.

The API model is an interesting one though. As well as revenue-in, it also potentially represents a cost out model (ie reduced cost of sales), a platform play (ie leveraging the network effect by allowing partners to build their own revenues on top), but on the downside also potentially triggers revenue cannibalisation.

Personally, I’m considering Sutton’s Law more in terms of our customers’ customers (ie end users of communication services, like the gamers in the Monty Hong link) rather than customers (ie the comms service providers that want to reduce costs).

I’d love to hear about your perception of Sutton’s Law in OSS. Where do you think the money is?

The culture required to support Telkomsel’s OSS/BSS transformation

Yesterday’s post described the ways in which Telkomsel has strategically changed their value-chain to attract revenues with greater premiums than the traditional model of a telco. They’ve used a new digital core and an API framework to help facilitate their business model transformation. As promised yesterday, we’ll take a slightly closer look at the culture of Telkomsel’s transformation today.

Monty Hong of Telkomsel presented the following slides during a presentation at TM Forum’s DTA (Digital Transformation Asia) last week.

The diagram below shows a graph showing the need for patience and ongoing commitment to major structural transformations like the one Telkomsel underwent.

Telkomsel's commitment to transformation

The curve above tends to represent the momentum and morale I’ve felt on most large OSS projects. Unfortunately, I’ve also been involved in projects where project sponsors haven’t stayed the journey beyond the dip (Q4/5 in the graph above) and haven’t experienced the benefits of the proposed project. This graph articulates the message well that change management and stakeholder / sponsor champions are an important, but often overlooked component of an OSS transformation.

The diagram below helps to articulate the benefits of an open API model being made accessible to external market-places. We’re entering an exciting time for OSS, with previously hidden, back-end telco functionality now being increasingly presented to the market (if even only as APIs into the black-box).

Telkomsel's internal/external API influences

Amongst many other benefits, it helps to bring the customer closer to implementers of these back-end systems.

How OSS/BSS facilitated Telkomsel’s structural revenue changes

The following two slides were presented by Monty Hong of Indonesia’s Telkomsel at Digital Transformation Asia 2018 last week. They provide a fascinating insight into the changing landscape of comms revenues that providers are grappling with globally and the associated systems decisions that Telkomsel has made.

The first shows the drastic declines in revenues from Telkomsel’s traditional telco products (orange line), contrasted with the rapid rise in revenues from content such as video and gaming.
Telkomsel Revenue Curve

The second shows where Telkomsel is repositioning itself into additional segments of the content value-chain (red chevrons at top of page show where Telkomsel is playing).
Telkomsel gaming ecosystem

Telkomsel has chosen to transform its digital core to specifically cater for this new revenue model with one API ecosystem. One of the focuses of this transformation is to support a multi-speed architectural model. Traditional back-end systems (eg OSS/BSS and system of records) are expected to rarely change, whilst customer-facing systems are expected to be highly agile to cater to changing customer needs.

More about the culture of this change tomorrow.

OSS that capture value, not just create it

I’ve just had a really interesting first day at TM Forum’s Digital Transformation Asia (https://dta.tmforum.org and #tmfdigitalasia ). The quality of presentations was quite high. Some great thought-provoking ideas!!

Nik Willetts kicked off his keynote with the following quote, which I’m paraphrasing, “Telcos need to start capturing value, not just creating it as they have for the last decade.”

For me, this is THE key takeaway for this event, above any of the other interesting technical discussions from day 1 (and undoubtedly on the agenda for the next 2 days too).

The telecommunications industry has made a massive contribution to the digital lifestyle that we now enjoy. It has been instrumental in adding enormous value to our lives and our economy. But all the while, telecommunications providers globally have been experiencing diminishing profitability and share-of-wallet (as described in this earlier post). Clearly the industry has created enormous value, but hasn’t captured as much as it would’ve liked.

The question to ask is how will our thinking and our OSS/BSS stacks help to contribute to capturing more value for our customers. As described in the share of wallet post above, the premium end of the value chain has always been in the content (think in terms of phone conversations in days gone by, or the myriad of comms techniques today such as email, live chat, blogs, etc, etc). That’s what the customer pays for – the experience – not the networks or systems that facilitate it.

Nik’s comments made me think of Andrew Carnegie. Monopolies such as the telecommunications organisations of the past and Andrew Carnegie’s steel business owned vast swathes of the value chain (Carnegie Steel Company owned the mines which extracted the raw materials needed to make steel, controlled the transportation used to deliver the materials and the product, and ran the mills used for steel production). Buyers didn’t care for the mines or mills or transportation. Customers were paying for the end product as it is what helped them achieve their goals, whether that was the railway tracks needed by the railroads or the beams needed by construction companies.

The Internet has allowed enormous proliferation of the premium-end of the telecommunications value chain. It’s too late to stuff that genie back into the bottle. But to Nik’s further comment, we can help customers achieve their goals by becoming their “do-it-yourself” digital partners.

Our customers now look to platforms like Facebook, Instagram, Google, WordPress, Amazon, etc to build their marketing, order capture, product / content delivery, commercial transactions, etc. I really enjoyed Monty Hong‘s presentation that showed how Telkomsel’s OSS/BSS is helping to embed Telkomsel into customers’ digital lifestyles / value-chains. It’s a perfect example of the biggest OSS loser proof discussed in yesterday’s post.

The biggest OSS loser

You are so much more likely to put effort into something when you know whether it will pay off and what the gains will be. Not knowing how things will turn out undermines your motivation and makes you delay taking action.”
Dr Theo Tsaousides
in his book, Brainblocks.

Have you seen the reality TV show, “The Biggest Loser?” I rarely watch TV, but have noticed that it’s been a runaway hit in the ratings here in Australia (and overseas apparently). Why has it been so successful and what does it have to do with OSS?

Well, according to Dr Tsaousides, the success of the show comes down to the obvious body-shape / fitness transformations each of the contestants makes over each season of the show. But more specifically, “You need to watch only one season from beginning to end and you will start craving to be a contestant on the show, regardless of your current weight… Seeing the people’s amazing transformation over a few months is a much more convincing way to start working out and eating well than being told by your doctor that you need to lose weight and about the cardiovascular advantages of exercise. Forecasting a positive outcome, especially when dealing with something new and unfamiliar, leads to action.”

Can you see how this might be a useful technique when planning an OSS transformation?

Change management is always a challenging task on any large OSS transformation. It’s always best to have the entire OSS user population involved in the change, but that’s not always feasible for large groups of users.

It’s one of the reasons I’m always a big advocate for getting a baseline, sandpit version of off-the-shelf OSS stood up and available for the user population to start interacting with. This is particularly helpful if the sandpit is perceptibly better than the current one.

To paraphrase, “Forecasting a positive outcome (via the OSS sandpit), especially when dealing with something new and unfamiliar (the future state after OSS transformation), leads to action (more excitement, engagement and less pushback from the user population during the course of the transformation).”

Do you think the biggest loser technique could work on your next OSS transformation?

Are telco services and SLAs no longer relevant?

I wonder if we’re reaching the point where “telecommunication services” is no longer a relevant term? By association, SLAs are also a bust. But what are they replaced by?

A telecommunication service used to effectively be the allocation of a carrier’s resources for use by a specific customer. Now? Well, less so

  1. Service consumption channel alternatives are increasing, from TV and radio; to PC, to mobile, to tablet, to YouTube, to Insta, to Facebook, to a million others.
    Consumption sources are even more prolific.
  2. Customer contact channel alternatives are also increasing, from contact centres; to IVR, to online, to mobile apps, to Twitter, etc.
  3. A service bundle often utilises third-party components, some of which are “off-net”
  4. Virtualisation is increasingly abstracting services from specific resources. They’re now loosely coupled with resource pools and rely on high availability / elasticity to ensure customer service continuity. Not only that, but those resource pools might extend beyond the carrier’s direct control and out to cloud provider infrastructure

The growing variant-tree is taking the concept beyond the reach of “customer services” and evolves to become “customer experiences.”

The elements that made up a customer service in the past tended to fall within the locus of control of a telco and its OSS. The modern customer experience extends far beyond the control of any one company or its OSS. An SLA – Service Level Agreement – only pertains to the sub-set of an experience that can be measured by the OSS. We can aspire to offer an ELA – Experience Level Agreement – because we don’t have the mechanisms by which to measure or manage the entire experience yet.

The metrics that matter most for telcos today tend to revolve around customer experience (eg NPS). But aside from customer surveys, ratings and derived / contrived metrics, we don’t have electronic customer experience measurements.

Customer services are dead; Long live the customer experiences king… if only we can invent a way to measure the whole scope of what makes up customer experiences.

Introducing our OSS expert registry, for making connections in the OSS industry

Here at Passionate About OSS, we’re passionate about making OSS happen. We have an extensive network of contacts. We just naturally tend to find ourselves making connections between the many experts in our network. Connecting those who are hoping to find an OSS expert with an OSS expert hoping to be found.

We’ve just introduced a new free-of-charge OSS expert registry to help people find OSS experts when they need to. This registry is intended to cover the buy-side and sell-side of the OSS market. Click on the link above to check it out.

Facebook’s algorithmic feed for OSS

This is the logic that led Facebook inexorably to the ‘algorithmic feed’, which is really just tech jargon for saying that instead of this random (i.e. ‘time-based’) sample of what’s been posted, the platform tries to work out which people you would most like to see things from, and what kinds of things you would most like to see. It ought to be able to work out who your close friends are, and what kinds of things you normally click on, surely? The logic seems (or at any rate seemed) unavoidable. So, instead of a purely random sample, you get a sample based on what you might actually want to see. Unavoidable as it seems, though, this approach has two problems. First, getting that sample ‘right’ is very hard, and beset by all sorts of conceptual challenges. But second, even if it’s a successful sample, it’s still a sample… Facebook has to make subjective judgements about what it seems that people want, and about what metrics seem to capture that, and none of this is static or even in in principle perfectible. Facebook surfs user behaviour..”
Ben Evans
here.

Most of the OSS I’ve seen tend to be akin to Facebook’s old ‘chronological feed’ (where users need to sift through thousands of posts to find what’s most interesting to them).

The typical OSS GUI has thousands of functions (usually displayed on a screen all at once – via charts, menus, buttons, pull-downs, etc). But of all of those available functions, any given user probably only interacts with a handful.
Current-style OSS interface

Most OSS give their users the opportunity to customise their menus, colour schemes, even filters. For some roles such as network ops, designers, order entry operators, there are activity lists, often with sophisticated prioritisation and skills-based routing, which starts to become a little more like the ‘algorithmic feed.’

However, unlike the random nature of information hitting the Facebook feed, there is a more explicit set of things that an OSS user is tasked to achieve. It is a little more directed, like a Google search.

That’s why I feel the future OSS GUI will be more like a simple search bar (like Google) that will provide a direction of intent as well as some recent / regular activity icons. Far less clutter than the typical OSS. The graphs and activity lists that we know and love would still be available to users, but the way of interacting with the OSS to find the most important stuff quickly needs to get more intuitive. In future it may even get predictive in knowing what information will be of interest to you.
OSS interface of the future

OSS collaboration rooms. Getting to the coal-face

A number of years ago I heard about an OSS product that introduced collaborative rooms for network operators to collectively solve challenging network health events. It was in line with some of my own thinking about the use of collaboration techniques to solve cross-domain or complex events. But the concept hasn’t caught on in the way that I expected. I was curious why, so I asked around some friends and colleagues who are hands-on managing networks every day.

The answer showed that I hadn’t got close enough to understanding the psyche at the coal-face. It seems that operators have a preference for the current approach, the tick and flick of trouble tickets until the solution forms and the problem is solved.

This shows the psyche of collaboration at a micro scale. I wonder if it holds true at a macro scale too?

No CSP has an everywhere footprint (admittedly cloud providers are close to everywhere though, in part through global presence, in part through coverage of the access domain via their own networks and/or OTT connectivity). For customers that need to cross geo-footprints, carriers take a tick and flick approach in terms of OSS. The OSS of one carrier passes orders to the other carrier’s OSS. Each OSS stays within the bounds of its organisation’s locus of control (see this blog for further context).

To me, there seems to be an opportunity for carriers to get out of their silo. To leverage collaboration for speed, coverage, etc by designing offerings in OSS design rooms rather than standards workshops. A global product catalog sandpit as it were for carriers to design offerings in. Every carrier’s service offering / API / contract resides there for other carriers to interact with.

But once again, I may not be close enough to understanding the psyche at the coal-face. If you work at this coal-face, I’d love to get your opinions on why this would or would not work.

Extending the OSS beyond a customer’s locus of control

While the 20th century was all about centralizing command and control to gain efficiency through vertical integration and mass standardization, 21st century automation is about decentralization – gaining efficiency through horizontal integration of partner ecosystems and mass customization, as in the context-aware cloud where personalized experience across channels is dynamically orchestrated.
The operational challenge of our time is to coordinate these moving parts into coherent and manageable value chains. Instead of building yet another siloed and brittle application stack, the age of distributed computing requires that we re-think business architecture to avoid becoming hopelessly entangled in a “big ball of CRUD”
.”
Dave Duggal
here on TM Forum’s Inform back in May 2016.

We’ve quickly transitioned from a telco services market driven by economies of scale (Dave’s 20th century comparison) to a “market of one” (21st century), where the market wants a personalised experience that seamlessly crosses all channels.

By and large, the OSS world is stuck between the two centuries. Our tools are largely suited to the 20th century model (in some cases, today’s OSS originated in the 20th century after all), but we know we need to get to personalisation at scale and have tried to retrofit them. We haven’t quite made the jump to the model Dave describes yet, although there are positive signs.

It’s interesting. Telcos have the partner ecosystems, but the challenge is that the entire ecosystem still tends to be centrally controlled by the telco. This is the so-called best-of-breed model.

In the truly distributed model Dave talks about, the telcos would get the long tail of innovation / opportunity by extending their value chain beyond their own OSS stack. They could build an ecosystem that includes partners outside their locus of control. Outside their CAPEX budget too, which is the big attraction. They telcos get to own their customers, build products that are attractive to those customers, gain revenues from those products / customers, but not incur the big capital investment of building the entire OSS stack. Their partners build (and share profits from) external components.

It sounds attractive right? As-a-service models are proliferating and some are steadily gaining take-up, but why is it still not happening much yet, relatively speaking? I believe it comes down to control.

Put simply, the telcos don’t yet have the right business architectures to coordinate all the moving parts. From my customer observation at least, there are too many fall-outs as a customer journeys hand off between components within the internally controlled partner ecosystem. This is especially when we talk omni-channel. A fully personalised solution leaves too many integration / data variants to provide complete test coverage. For example, just at the highest level of an architecture, I’ve yet to see a solution that tracks end-to-end customer journeys across all components of the OSS/BSS as well as channels such as online, IVR, apps, etc.

Dave rightly points out that this is the challenge of our times. If we can coherently and confidently manage moving parts across the entire value chain, we have more chance of extending the partner ecosystem beyond the telco’s locus of control.

Pitching an OSS? Don’t call it OSS.

If you asked me how to sell cybersecurity, I wouldn’t call it cybersecurity.” The raw truth of the statement hit me like a lightning bolt between the eyes. Cybersecurity might loosely describe what we do, and we tell people it’s what we’re selling, but it’s not what people buy.
Safety. Assurance. Peace of mind. Confidence. These are the kinds of things that people buy, concepts which ordinary people can understand and relate to because they are feelings which they have experienced themselves. Cybersecurity is not a next gen firewall, or multi-layered endpoint protection with machine learning and threat sandbox technology. Cybersecurity is not risk management or ISO27001 policies. Cybersecurity is being able to use the Internet in any way I can imagine without having to worry I might lose my family photos, get robbed, or get in trouble with my boss. If you could (honestly) sell me “worry free Internet”, I’d buy it in a heartbeat, and so would everyone you know
.”
Corch X
, here.

Sound familiar?
If you asked me how to sell OSS, I wouldn’t call it OSS. Doh! Now you enlighten me… after I’ve already chosen the domain name, PassionateAboutOSS.com. After I’ve already written over 2,000 posts on topics like orchestration, microservices, cloud-native, DevOps, and every other technical buzzword. Time to start again from scratch.

One thing in my favour is that you, the audience I’m interacting with, also speaks in the same jargon. These are the terms we use to communicate with each other. To get things started. To get things done. To get things delivered.

That’s all fine if we’re only interacting with like-minded OSS experts. However, of the thousands of people who interact with our OSS / BSS, only a small percentage are OSS experts. A majority of people use the tools rather than designing, building or commissioning them.

The people who use the tools have a huge range of job roles and reasons for needing to use our OSS / BSS. Just like with cybersecurity, the core reasons could be Safety. Assurance. Peace of mind. Confidence. But they might also include Speed. Efficiency. Reliability. Repeatability. Simplicity. Monetisation. Insightful. And more.

The challenge we have is that so much of the benefit that our OSS and BSS deliver is intangible. We might talk about orchestration delivering speed, simplicity, reliability, etc. But how do we establish a more tangible link?

How do we achieve the equivalent of what the “Intel Inside” marketing ploy delivered, which made people associate an otherwise obscure integrated circuit with a premium feature to consider when they bought their next computing device. How do we ensure that people know that our OSS / BSS is the master of puppets that make our networks dance? It’s our OSS / BSS that are pulling all the strings of operationalisation, connecting customers with networks.