Reading the recent news on talkRA of the merger of EcTel and cVidya, and financial results for Subex got me thinking. Add to that when I was on an internal call last week, I was asked why we need to use the RA tool to perform a reconciliation, and not just use SAS.
Is it the case that the RA tool, as a specialised piece of software, that can command a premium price, is going the way of the dinosaur? On the phone call, I was able to argue that the configuration work had already been done so it was pointless to repeat it, but would I have an easy as response as this, if the work had not yet been started?
I have recently been thinking again about the TMF’s RA maturity model. What I am sure on is that the benefits from an RA investment (be that time, people or tool), will not be more than the lowest individual dimension of maturity. So if 4 of the 5 dimensions of the TMF maturity are high, but the “people” dimension (for example) is low; then only low benefits will be realised (don’t ask me to define low vs. high benefit).
And so the RA manager’s role must be to align each dimension to deliver and sustain the next level of maturity. Delivering this though requires thought, based on an honest appreciation of where capability is currently at, and strategic leadership to see how to move in the next level.
To bring this back to why I was thinking about this originally, there seems a disconnect between the seemingly unflattering business performance of RA vendors, and the apparent growing need for RA work. It raises the question that, in general, are RA tools and software more mature than the people and processes, or is it the other way around? And depending on that answer, is this recognised by the RA software vendors, and if so what could, or must, they do to lift their own profit?
Hi Eric,
I completely agree with your comment.
About your questions, I may propose some answers based on my own experience.
The efficiency of the tool depends, in my opinion, not on the maturity of the RA team, but on the maturity of the company. Expanding the capabilities of the RA team with leakages detection is a great deal that we achieve with the tools, but it will not help if the company doesn’t act or react to recover the leakages and then prevent them.
Concerning why does they tools success even in non-mature companies : well, in a non mature company, there is so much to be done that any tool gets a quick ROI no matter what, a long long time before efficiency and maturity.
May be the vendors should sell packages including "maturity consultancy" to be sure that not only the RA team evolves but the whole company.
Morisso
Hi Morisso,
Mike here (as opposed to Eric).
I agree with your comments. By “process”, you can broadly include the dimensions of organisation and influence per the TMF model. The RA team can be the best at finding leakage with the best tool but if the organisation does not want to fix the specific instances or the processes, then the benefits (take this as revenue uplift from preventing leakage or loss), will be stuck at zero. This goes to my point that, all dimensions of maturity must be aligned to achieve results.
Should tool vendors sell packages to develop “maturity”? Possibly but that asusmes that tools are more mature than other dimensions so that once the tool is in place, then the next task is to bring the other dimensions up to that level. Is this the case though?
This also raises other questions – do the RA tools on the market today allow operators to obtain the highest form of maturity?, do tool vendors have capability right now to offer “maturity consultancy”?, do operators have the desire and cash to invest in both a tool and “maturity consultancy”?
The last question is perhaps the most relevant to consider. The old world model where the more you invest in technology, the greater the ROI, seems to be increasingly redundant. This applies as much to RA as any investment but getting the balance right is critical to success.
Mike
Hi – it’s the real Eric this time ;)
On Mike’s question of whether maturity of tools is ahead of the maturity of other dimensions, let me make the following observation. In any self-appraisal people may exhibit bias. The TMF RA maturity questionnaire was designed to limit the possibility of bias, but like any questionnaire a clever person can work backwards from the results they want to the answers that generate those results. In my honest opinion, we saw that happen in the last TMF benchmark, with some businesses under-marking tools maturity in order to bolster their internal business case for increased expenditure on tools.
I am reluctant to make a sweeping generalization about the sophistication of RA tools versus the maturity of other dimensions, but let me say something about a few of my experiences relating to tools and other dimensions of performance. I have seen telcos where an RA system was implemented, but where no provision was made to train the people using it, so they do not know how to use it. I have seen telcos where RA systems were implemented to detect errors, but where there was no process in place to do anything about them. FMS systems are essentially rules-based, and the rules should be optimized to get the best results in real life, which of course means what was optimal at one time will not be optimal later because things change. However, I have seen telcos with sophisticated FMS where the rules were set up when the system installed but never tweaked again. Perhaps the telco staff felt it is hard to change the rules; you could also argue that you should not select a system if it is too hard to use it, and that includes optimizing it. I have also seen telcos where only some of the system’s capability is utilized, because nobody has the job to use the other modules. There are also telcos with good people who lack tools, but this imbalance is more visible than the imbalance of telcos with good tools that are underexploited.
Vendors are often willing to throw-in some consultancy around maturity when making a tools sale or in the run-up to a sale. This being the real world, bias is common, even when the vendor uses the TMF questionnaire. You cannot be too critical: they have their own company’s short-term financial targets in mind, not the explicitly long-term objectives that drive the TMF maturity model. For these reasons, I do not believe any business that primarily positions themselves as a software vendor can be relied upon to offer maturity consultancy. This is not a criticism, just a recognition that the investors in the vendor expect it to deliver a return in a certain timescale and expect to earn that return from software. Offering consulting services on top will always be a opportunistic quick win for the software vendor, not a fundamental part of its proposition, and hence they cannot afford to give good advice that runs counter to their efforts to sell more tools.
When working for telcos I find the best approach to buying consultancy, especially long-term consultancy, is to look for a long-term partner. If you change consultants often, they have no incentive to give good, long-term, advice. They may write a report and you never see them again. Better to intend to build a long-term partnership so the consultant knows they are first choice for future work, and will stop being first choice if they fail to align their own goals to those of the customer. This also means focusing on the individual consultants who give best results, not the firm that employs them. If the consultant moves, you buy the services of that same consultant from their new firm, not stick with the old firm and take a chance that a new person is as good as the consultant you were used to working with and who is aligned to your long-term objectives. Procurement processes can be an obstacle because they focus on approved suppliers, not the individuals you buy through the supplier, but it is worth the trouble if you find a really good business advisor. Getting good, impartial advice aligned to your long-term objectives is very hard to do, not least because it is hard to measure the benefit of good advice over bad advice. However, the value of good advice is great, and the value of bad advice is nil (or less than nil, if you follow it). When looking for maturity consulting my best advice is to find consultants with integrity and experience who make their money through long-term partnerships… and to stick with them.
Hi everyone,
In my opinon, I see 3 reasons for the disconnect between “unflattering business performance of RA vendors” and the growth of RA in general as an area.
– First, the success of a RA department is rarely tied to the capabilities of a tool. So much can be done in RA with just human intelligence and simply interest and motivation. RA departments rely on tools, sure, but just to some extend. What you really need is good reporting and investigation capabilites. Once you’ve got that, you’re pretty much set. You don’t need to feed software vendors with constant new requirements.
– RA is personal… Each company is often looking at it from a very personal angle, driven by the personality of the RA manager and the specifics of the operator’s architecture. It makes it this much more difficult for RA vendors to come-up with modules and solutions that are generic enough that they can satisfy large groups of customers. That is, of course, when you go beyond the obvious modules like switch-to-bill and data integrity and beyond solutions imposed by groups (ie Vodafone, Telefonica)…
– RA vendors often lack hands-on experience. They sell great tools but often don’t understand the business value of the results that they produce. They are packaging together modules that they are trying to sell when companies really need consulting around the tool just as much as they need the tool. There is no successfull RA implementation projet without a heavy dose of consulting around it and business-models of RA vendors too often leave a very small place to consulting and don’t push it as a real revenue-making department.
Lionel: you make some great points, and I wouldn’t dispute any of them. The thing is, your observations lead to some pretty unpalatable conclusions for vendors (and I’d love to hear somebody from a vendor offering a counter-argument). The main issue for me is that you’re saying RA vendors don’t bring a lot of subject matter expertise to delivering their solutions. You’re also saying that there is not much of a standard market for RA vendor’s tools, but rather a mixed bag of different needs that can be vaguely grouped under a common heading of ‘revenue assurance’. If that’s true what does that say about the vendor’s ability to package up bog-standard BI capabilities and sell them at a premium to a specialist market? What does it say about how vulnerable they would be if new entrants wanted to come into the RA market? What does it say about the wisdom of the average customer for dedicated COTS RA tools? And what does it say about the wisdom of the investors who have put their money into these companies on the basis that they sell something special?
I notice that I’m asking lots of questions. That’s because I don’t want to be the person who offers answers… ;)
Let’s admit it…you knew I’d respond to this one. Before I proceed with the reply, I have to say – Lionel, I understand your point of view and I do give it due respect. Having said that, I do work for a RA vendor. Working for a RA vendor is a little like trying to kill a hydra. As soon as one item is addressed, the next technology/leakage/framework pops up. Due to the wonder of modern technology, every operator decides,” Hey!!! I want to be safe from this as well!!!”. I can’t tell you the number of telco’s who want to be “leak-proofed” from a situation which will never arise for them.
Now as a vendor, you will obviously attempt to provide the best value to your customer. It’s not philanthropy, it’s just good business. Being a direct customer-facing member of my organization, it makes me feel good if I can understand what the customer is looking for and I provide the best fit, rather than selling a pre-packaged product. I genuinely want the product to be used because we have seen customers derive great benefit out of it.
I am a stoic believer that a tool alone will never help you “do RA”. It is merely a facilitator, but an excellent one if the surrounding processes are setup right. If you notice, most of my blogs deal with workflows and processes.
The one point you’ve raised which I do not agree with is that the RA vendors do not have hands-on experience. I am of the belief that working for a RA vendor opens your perspective on how different customers do RA. When you work in a single operator within a single country, then your views on how to do RA are molded by the actions of your peers. The environment creates a process which is followed without significant scope for broadening. There is a resistance to change which I have seen first hand. Working for a RA vendor means you are exposed to so many different operators that you are forced to understand and assimilate the best practices, so that we can deliver value to the next customer.
Furthermore, as a practice, most RA vendors (okay, maybe I’m generalizing – but I can say this for my organization) would hire people with hands-on experience. Preferably people who have worked in telcos. No RA vendor worth his salt can claim to have a product if the source of the product isn’t a direct line from telcos. To further elucidate on this statement, I have learnt a lot more from the issues people raise rather than standardized documentation. I believe that the strongest reason for interacting with a RA vendor is the knowledge bank that they would have acquired over the years.
I do believe that we bring a certain amount of subject matter expertise to the table, not because we are the smartest cats on the planet, but merely because we see a wide spectrum of practices in a relatively short period of time. As Eric alluded to earlier – If we do not have any subject matter expertise and if we do not provide good value, why would anyone entertain the vendor? I know I wouldn’t.
At the end of the day, most of us really enjoy what we do. That’s why my presence on this site is not as a promoter of my product, but rather a fellow RA practitioner. I derive great benefit from the wisdom of others via their blogs, and I hope some of my blogs help people too. If not help, then at least get people questioning the way things are being done today.
Hi Ashwin, Let me re-phrase, maybe. There is, no doubt, incredible value in visiting customers in a pre-sales context, listening to their requirements, answering RFP, etc… I’ve done that for 2 years in different parts of the globe for a RA vendor and that is indeed maybe the best way to get to know the area. There is also incredible value in working on-site with the customer as a product is being deployed. That experience as a RA vendor brings great value to customers, when you interact with them, no doubt. You grow by learning from others, they all know that, so do RA vendors. Maybe what I was just trying to say was: the business model of RA vendors rely heavily on their software division, more than their consulting division. Probably because it is really hard for RA vendors to find enough people that can bring something to the table that would justify the heavy consulting fee. Maybe also because customers feel like they, internally, have more experience than some of the consultants they’ve met from RA vendors (that surely happens too!). And when you are in the software business, you will for sure struggle, just like most of the billing software vendors, etc.
Hi all,
I think everyone is in broad agreement that for RA to be a success, there are a broad range of activities required. These are such that no one single factor or dimension will ensure success and it is up to the RA manager to determine, within their time and budget restraints, who is best to offer what solution (be that system or process) to deliver the benefits that RA can.
When I re-read the TMF maturity model (albeit quickly), this sets the “what” of maturity at each level but the “how” is the greatest challenge. And the “how” has a large dependence, on the individual organisation. This is where lessons from the experienced consultant (be they independent or from a tool supplier) can be leveraged so that an operator can climb the maturity curve more quickly. A key then to engaging someone, or before taking their advice, must be to ask “where have you done this before?”, “how have you done this?” and “what typical road blocks to success, will you specifically, help me avoid?”
Mike