Let me try and put a few things straight first:
– (Reactive) Assurance: Assuring after the fact and preventing recurrence in future
– Active Assurance: Assuring ‘as and when’ things are falling apart, fixing and hoping to stop things from falling apart in future.
– Proactive Assurance: Playing ‘Minority Report’ (the Tom Cruise starer movie). Just joking. The concept I hope is to ‘assure’ before things fall apart.
Using the word ‘Assuring’ so as to avoid having to define the “scope of revenue assurance” et al.
Nice thoughts and for all practical purposes all are flawed– whatsoever the Gurus of Marketing of pro-typical software vendors may say. Ask the real guy who works his ass off in assuring revenue and You would get the real picture of the actual facts of what works and what not.
Essentially what is typically necessary is means to ‘automate’ reporting and controls that are put in place. Imagine having to use a 100 person strong team for regular reporting and control purposes. The effective tool is one that helps to free up the human resources by automating the manual activities, so that the same set of people can be effectively used for finding and ‘assuring’ other areas of the business, else the capacity is under-utilized.
Note however, a effective output (efficiency) of any process in any place/industry/region is guided by the throughput of the slowest working unit of the process. If you increase capacity in one or more working unit only without considering how to improve the overall efficiency, all that is done is maximizing ‘inventory’ thus building up operational costs with no output. End of day You hurt Your own business. So howsoever You try and fix everything about reporting and controls, if the bottleneck is in getting the data itself in the first place, all other processes is guided by how well You get the data and process the same.
Success of a effective processes around revenue management and business assurance (say call it ‘Optimized Revenue Assurance’) therefore is guided by the capability to optimize the throughput of the slowest process. The key steps therefore are:
1) to identify the slowest process
2) identify how to optimize the same
3) ensure the rest of the processes are aligned to the output capability if the slowest one.
Note, it is not necessary to have the rest of the processes running at full capacity over and above the capacity of the ‘sub-optimal’ process– for that would just increase the operational costs for the organization.
This is a very engrossing topic…. hope to write more on the same in future posts.
All Comments of All Forms are Welcome.