I looked through the comments posted to the question about the Fraudulent Engineer and would like to quickly summarize the knowledge, skills and abilities (KSA’s) I picked up there.
- “…requiring some serious levels of expertise and a fair amount of coding”
- “…extracting all switch inventory tables and applying a lot of switch architecture knowledge”
- “…DMS filter compensation”
- Knowledge to know that there are switch level settings to suppress the generation of XDR’s and that there are legitimate business reasons for suppressing them (not all suppressions are fraudulent, so which is fraud and which not?)
- Switch settings at different levels such as line level, global level and group level and which rules override which?
- An understanding of trunks and gateways
- The ability to extract data and make it available in a form to run queries. This implies knowledge of SQL, SAS, advance Excel, etc
- Interconnect knowledge
- Service profile knowledge. This covers the difference between profile components on the network elements vs the profile components on the billing system. These 2 worlds don’t always use the same naming conventions, so that mapping must be understood as well as the fact that billing specific profile components may not be on the network and vice versa
- Root cause analysis
- Deductive and inductive reasoning abilities
Considering that RA mostly reports into Finance and the typical job profile for the RA analyst asks for reconciliation and recovery of leakage (correct the under or overbilling by correcting the reference data and resubmit the event for processing or raising a journal to correct the financial impact), at which point do we teach these analysts of switch level settings and are there courses available, aimed at the average non-technical RA analyst that covers this knowledge?
I have to confess, I learnt from this question. I did not know that it was possible to use the network without leaving a trace in the form of a call record (partial, incomplete or not) that I was there using it. I knew it was possible to delete those records early in the process and not send them through to mediation.
This raises an interesting point for the composition of the RA team and implies that RA is a decentralized function within the organization which requires contribution and support from all departments to resolve a query such as this. It is unlikely that the RA department, reporting to the CFO would employ this range of technical and telco knowledge.
I would like to hear from operators following these discussions who have people with this knowledge employed in their immediate teams and what motivation was given to management to allow such technical skills to be employed in Finance.
Hi Guera,
The people with these skill sets are a very niche sub-set of the available resource within the RA market. Generally speaking, we end up working for the smaller niche consultancies who then develop software solutions to be sold back into the operators.
Where RA is positioned within an organisation has always been a subject of much debate(well for me at least). Organisations take the opinion that the benefits of Revenue Assurance are “increased revenues” therefore we should sit in Finance. However there are many more benfits to revenue assurance, that would bring this simple conclusion into question. Take for instance the reconciliation Matt described in the “Fraudulent Engineer” question. The possible benefits of this reconciliation would be:
1) Reclamation of network equipment
2) Identification of network faults
3) Identification of IT faults(provisioning failures, billing failures etc)
4) Reduced CAPEX(re-utilisation of redundant equipment)
5) Reduced OPEX(less calls to cusomer services, reduced load on the network, removal of interconnect charges relating to non-paying customers etc)
6) Identification of marketing failures(mis-pricing within literature)
7) Regulatory compliance(charging the customer correctly, providing the requested service etc)
The list can go on and on, but ultimately the benefits of RA, impact the entire business. In my opinion, we should be treated as the policeman of the entire operator and given the independance and authority befitting such a team.
My favourite counter-argument to anyone who says “The purpose of RA is to generate money therefore you should sit in finance”, is “what’s the purpose of your role?”, as we are all here to generate money for the company.
Hi Guera,
It is not uncommon for engineers to by-pass the provisioning system when doing “subscriber account maintenance”. This activity takes place on HLR/Switches, SMS platforms, MMS, and Web platforms. Also, this activity is not unique to wireless platforms. It happens on the wired network as well. The only way to identify these types of breaches is to do a 100% subscriber to billing platform recon. There are problems with this like timing issues, duplicate subs, and canceled subs. However, a good algorithm can minimize false positives.
In our case, we had a team of technical folks who had the skills to pull 100% of subscriber data, 100% of call attempts, 100% CDR’s created, billing rules, and GL activity associated with the subs. The team would then recon all variables to find leakage.
Has anyone considered performing a B – table analysis on the switch? This should identify scenarios where CDR generation is supressed.
Hello,
i would appreciate more info on the B number analysis idea put forward by Nitin. I have been trying to achieve this for some months now, and would appreciate his experience