This would be one of the integral links in any enterprise level BSS Project chunk in a larger BSS/OSS implementation .Actually if you look at this topic from different angles you might see the picture differently depending upon the role you are playing in this integration. The roles can be the enterprise business analysts ,disparate vendors providing the CRM and Billing solutions in the form of off the shelve packages, IT backoffice team defining the IT backbone for the enterprise operations flow, Financial and Auditing teams, Executive management teams and several other teams who if not involved in giving shape to the integration output ,build their expectations of better business turnover in their silos based on the success of this integration.
So obviously these integrations are done because the end goal of “Customer Relationship Betterment” 🙂 if I might put it in that way is just not possible simple by a standalone CRM product in the ever evolving market but obviously needs the transactional value-add capabilities as well Business Process & Performance management enhancements provided by a back end billing system to really make the difference.
Well at this point I might be barked at 🙂 by being said that CRM and Billing are absolutely 2 different pieces and if CRM is required for a specific set of stuff then Billing too would be required absolutely essentially for the arena it holds fort. Yes , agreed but wait I do hear noises at different places where people are talking about avoiding the complexities of a billing system altogether.
People might argue but the advancement of billing systems over time is actually what provides you the real power in monetizing more effectively the services provided by an enterprise. So that is the reason why my above para comes in.
But it is true that in the present perspective if you do take at random a CRM product and a Billing product there will be overlapping pieces which actually by strict definitions of the systems should not be a part of that product . But they find place because sales opportunities forced the producers to induct these as so-called value-adds which can help penetrate new markets and get more business.
Funny that when the point comes of integrating these 2 systems at times it is the ambiguity of these overlapping areas which result in Integration conflicts. Since both the systems have it they generally would not think about OOB integration adapters for integrating precisely these pieces. So you start having gaps and then you think of filling them and it is here the next demon comes out -> data model inconsistencies between 2 systems . Yup that’s the killer isn’t it and if you go deeper this inconsistency arises again from the differences in the ontologies of borderline terms in both the systems. Well to take an example a billing system would encompass the concepts of contracts & priceplans different from the way a CRM system is comprehending bundles and products (products which can again be seen as components of priceplans).
So what do we do about this , well to dig this further I endeavoured to get some guiding light on this matter from Integration knights in Armour out there in the professional world out there on linkedin.com.
There have few good answers on that link which you can go through.
I am happy to see readers from different parts of the world paying a visit to this new-born. Inviting folks to leave comments on how they find this blog and how they would want to see this blog shape up in the future.