There is a well established understanding that telecommunications is undergoing a process of fundamental transformation. What makes these changes fundamental are not just upgrades in technologies and services, but in how values are generated and delivered. Traditional CSPs evolve into partnership ecosystems to provide complex multilayered products. For example, cloud services can be represented as infrastructure, platform or customer front-end services, or any combination of these. Smart cities represent another example where the product is a combination of services provided by different parties including telcos, public service offices, equipment suppliers, analytics providers and the like. In other words, the traditional consecutive value chain is being replaced by a value network with different points to initiate and to collect value. This kind of business is able to deliver services in a flexible and agile manner to satisfy customer needs.
All of the above means that assurance should also transform to face new challenges as the traditional RAFM approach shows growing uncertainty regarding new digital products and revenue models. The TM Forum 2017-18 RA Survey illustrates this point; despite an increase in overall maturity scores…
…decreases were noted for “Business knowledge”, “Staffing levels”, “Communications”, “Change management involvement and sign-off” as well as “Use of RA technology”.
There are currently wide discussions within the professional community about the role of assurance for present and future telecoms. There was a nice brainstorm at the RAG Bahrain conference early this year, concluding that revenue assurance is just a part of complex business performance bottom-line assurance. The question is how to make assurance teams capable of supporting business in this new rapidly changing environment. It seems obvious that to do that assurance should be flexible enough to implement and develop its practices and controls on demand during a short period of time and with a high quality of service.
One way to achieve this is to become agile. Usually we think about agile in the context of IT, meaning there is a need to hire dev-ops teams, and split complex tasks into small pieces to implement them one by one. This raises a question: what if my company is not already working this way? Does it mean that there is no room to build agile assurance? This declaration of agility is not quite accurate. To be agile with IT means being flexible throughout the processes involved in development, but processes are not the only important ingredients. Two other important ingredients are technologies and knowledge (or subject matter expertise) which means flexible capabilities to execute processes and controls to ask the right questions whilst understanding how to get the right answers. So to become an agile assurance provider means to find a combination of agile processes, technologies and knowledge.
OK, stop there. Do current assurance teams not exhibit this combination of agile processes, technologies and knowledge? The answer is yes and maybe. Yes, if we speak about separate teams dedicated to specific assurance domains. But when we take them together then things are becoming more complicated. How well are they all combined? What about infrastructure utilization? Do we avoid double spending in technologies to ingest, store and analyze data? Do teams understand each other? Are cross-domain tasks executed without any friction? Can we treat teams as organs of the body or just as a set of different species? Another question is about their abilities to evolve without major changes and investments to stay relevant to risk assurance. What are the incremental costs to do that? As the scope of risks becomes less predictable then the cost of changes in assurance becomes very important.
A certain kind of magic would enable the assurance team to become agile in an agile way, starting with their next investment and incorporating every improvement to build a robust assurance ecosystem. That does not mean this would be easy. To master agility means mastering complex changes that require different methods to those which are usually applied. Every assurance team will have unique first steps depending upon their current situation. But the common goal is that every next step should have cumulative effects with previous ones, leading to the creation of new opportunities and combinations. This is like creating new Lego pieces whose use can vary depending upon the way they are recombined on demand and assurance scenarios where they are employed. This is how agility will help construct an efficient assurance partner for the telecoms business.
Assurance teams cannot make this happen on their own. Suppliers to the market, and the wider community should evolve to be accommodating of agile assurance as well. New kinds of solutions are needed. The assurance community needs platforms for the frictionless sharing of best practices, knowledge and methodology. And, of course, we have a long way to go before we can develop the business recognition of risk culture. When this is done, we can build a world with digital trust and mutual prosperity. Let’s go!
