Friday, April 02, 2010
Enterprise Architecture and Social CRM
Another industry analyst whom I follow, sent me a direct message via Twitter inquiring whether I could help him resolve a challenge he had with acquiring a business owners insurance policy. He knew that I was well connected within my organization that enterprise architects tend to understand who to contact since it is very much a social role and more importantly that since I have an affinity to the security community, I might have a clue as to how things truly work.
Anyway, upon receiving his DM, I first ascertained something I never really thought about in terms of connecting with customers. He described his business as security consulting to an underwriter which was accurate, but this has a totally different meaning within the insurance ecosystem than it does to customers. The insurance vertical uses standard classification codes and security consulting would feel more like what retired FBI agents do in the private sector than advising enterprise clients on best practices for software security. So, the first lesson is to think about how to use social networking to educate consumers on terminology. This simple interpretation could cause a business or consumer to pay more for insurance than they should.
Upon receiving the information, I of course had to figure out what particular interactions he had with our organization. The business community at large always talks about the notion of a 360-degree view of the customer and social media makes this particularly challenging. Most architecture in this regard has the built-in assumption that you know something that feels like a primary key. Since this was twitter, I dare not ask for publicly identifiable information over a non-secure channel and therefore had to resort to other tactics.
Many enterprise systems will allow for one to search for a person based on identifiers such as phone numbers, addresses, social security numbers and so on, but to date I have yet to find one where you can search based on a twitter handle. So this begs the question of what other types of attributes above and beyond simplistic inetOrgPerson should an enterprise store based on its consumer-base. This has turned into homework for me to not only capture attributes but made me think about user-oriented registration and other factors.
Of course, I am not in the customer service business and needed to route this request to someone more qualified. Do I use more traditional email? Since I am security-focused, do I inject something into the current workflow from a CRM perspective so it will follow the defined path even though this would be a violation of controls?
Well, of course I found an answer that was timely and compliant. The actual approach doesn’t matter much as it was company-specific but this does beg the question of how does an employee, any employee become an ambassador of customer service in a world of traditional controls.
With a few exceptions, the vast majority of enterprise architects I know spend an awful lot of time focused on internal issues whether it is rationalization, the cloud, storage governance, data center consolidation, creation of reference architectures, portfolio management and other considerations that aren’t even visible to customers. One should ask whether IT can be truly successful if we are busy listening to the business but otherwise are blissfully ignorant towards the customers they serve.
Maybe a discussion in the blogosphere on how enterprise architects should think about social CRM is in order. We need to move this away from a constrained discussion related to public relations towards a conversation that all can participate in…
Links to this post: