RA as an example of collaborative networking

In August 2000, Peter Drucker made a startling prophesy: “The corporation as we know it is unlikely to survive the next 20 years”. Legally and financially, yes but structurally and economically, no.

We are all familiar with the technology explosion happening around us. Mergers and acquisitions further influence the features of combined capability in platforms and services provided. So what are the structural changes that lead to corporations being different today? It is called collaborative networking rather than a vertical integrated organisation with strict reporting lines. This should not be confused with a matrix structure. Matrix work groups still function within a defined structure with fixed reporting lines whereas collaborative networking doesn’t.

Collaborative networking is a feature of organisational culture today and RA is probably one of the most established forms of collaborative networking in operations practice. The network is dynamic and “fit for purpose” with the agility to change the components and how they relate to each other legally and operationally as purpose and context evolves. It is not unthinkable that this method of working could be suited to more formal interdepartmental processes. However, most operations personnel are more confortable working in silos with clear boundaries.

Now, you know my take on the boundaries of the Revenue Assurance function. Why, I spent a whole masters degree on it….. Collaborative networking works well were there are no formal boundaries or where these boundaries seem to move in any given direction and at a speed ill understood by those involved, or affected by it for that matter. It is also true that the RA industry sees the boundaries between RA, RM and Fraud greying. GRAPA just launched a Revenue Engineering course, effectively establishing RA’s role in pricing strategies. Dan Baker commented on upselling capabilities inherent in billing system, which could provide RA the capability of assuming revenue generating activities.

If RA lacks clear boundaries and collaborative networking is seen as a possible answer to formalising the RA engagement, how do we stack up? There are five factors affecting the successful implementation of collaborative networking. Let’s apply these to RA.

1. The network must have unifying objectives. This is best captured in the departmental objectives. What is it that the RA function must achieve and what are the KPIs against which this achievement will be measured? Do these objectives align with the other departments’ objectives and KPIs? For collaboration to be effective, the objectives of RA MUST align with the objective of the rest of the organisation. How often is this the case?
2. The collaborative network has a value proposition that ranges from shared interest to mutual self-interest. The stated value proposition of a legitimate RA function is shared interest and it maps directly to the formal objectives of all parties involved. I know of various examples where shared interests had been neglected in favour of self-interest, mutually, no doubt.
3. The collaborative network has an economic opportunity, which varies in degrees of certainty. Economic opportunity describes how well the network has established a way of monetising the value proposition, including collective currencies of the network members. I have difficulty picturing the collective currencies of RA. Considering the collective currencies of a LinkedIN or Facebook membership. There is a clear exchange of value. I don’t see that exchange of value in RA. True, we have a benefits realisation calculation, albeit much debated but value exchange in one direction can be established. What is the currency coming back into the RA function? Other than sales and employment opportunities for vendors and consultants.
4. The organising mechanism is a method through which the members to the collaborative effort come together and manage or govern themselves. Here I believe we have made good progress. We have formal functions, budgets, industry guideline bodies, relative standardisation in RA technology and well organised conferences.
5. Collaboration intensity is the degree to which activities are coordinated and shared, and resources leveraged for the benefit of all parties. Again, as an industry I think we can tick this one off. Perhaps more work required in the organisation where resource allocation may be a challenge but we have passed the hurdle of motivating why such collaboration is required in the first place.

There are unresolved concerns with regard to objectives alignment, the true value proposition and the economic measure of the value proposition. Consider the newly established Revenue Engineering course or the billing system that has automatic upselling identification capability. It is a fallacy to reason that just because the training course was passed or the upselling system capability is operational, RA automatically becomes responsible for those activities. Aristotle is giggling in his grave. Any person reading this blog objectively would argue that it does not imply RA to take on that responsibility, neither expects it to do so. It merely means that the capability and capacity to do so, exists. Yet, this is not our reality. The greyness overtakes. Like the old adage of a frog sitting in slowly boiling water. It does not leap out but bubbles to a soup.

We make these invalid inferences unconsciously and thus the boundary stays fluid. And next year we continue the debate on the factors to include in an industry standardised benefits realisation calculation. Why? Because our objectives aren’t aligned and our value propositions are not understood or truly accepted. If I don’t like a LinkedIN group, I leave the group. If I don’t find benefit in chatting on-line with fellow researchers, I remove myself from that discussion forum. If I have a Nah-nah amongst my Facebook friends, I delete him from my list. Can Customer Care remove itself from the RA function involvement because the RA analyst hammered it on inadequate bad debt collection methods but failed miserably in identifying failed service activation processes timeously to prevent the Call Centre queue from falling over? No it can’t. So where is collaboration?