The Structured/Unstructured SCRM Data Puzzle – ‘in-the-trenches’ Techie weighs in

Don’t lose the cornerstone pieces of the CRM Puzzle in the quest to go Social, or the picture will never be complete.

Data Puzzles

I’ve spent a lot of time lately exploring some of the newer Social CRM solutions being developed and frankly, I’m concerned about some of what I’ve seen in the attempt to swing the innovations for Social too far from the Management part of SCRM.  You’re probably wondering why you should care  that I have an opinion at all, but if you’re planning now for product enhancements & integrations later, then voices like mine are important.

I’m your other customer.  I’m the one who will implement your solutions.  Which means I am the one that will also help make or break the success of your SCRM offering. Make me your advocate by developing your products so it is easy for us to make you rich & respected for providing quality solutions.

We’re the front line knowledge workers who are going to have to make all the pieces of the puzzle fit together to give your customers the complete picture.

(And we’ll take the direct body hits from your customers if those pieces don’t fit. So be kind, pay some mind…)

I’m not a renowned E2.0 Thought Leader or Analyst, but I have been a  ‘Techie in the trenches’ for the past decade as Professional Services Implementation ‘expert’ for Enterprise collaboration software, which means I’ve architected solutions, implemented, configured, integrated, migrated-to-and-from, most of the top traditional CRM packages that come to mind, not to mention  a handful of mid-market ERP packages, gaining a level of process knowledge & data intimacy that many strategists haven’t.  And I’ve implemented sales processes that would make your head spin.

All in the pursuit of providing adequate analytics as the outcome  so your customers can Manage their Customer Relationships and make more Sales.

What I’ve observed is that some vendors are so overly-focused on socializing the process with unstructured data/process innovation dreams, that they’re too cautious about laying the right ground work for future scalability based on a true understanding of the smallest data sets required for optimal analytics, and further feature growth. I won’t presume to offer up a lesson here on 3 layer ‘constraint, schemata, and object’ architecture when there are much brighter Knowledge Management development experts out there, but I will share some basic thoughts on structured minimum data sets and why they are still important.

Unstructured vs. Structured Data – A precarious balance

Let’s illustrate the need for non-structured/structured balance with a recent experience I had while testing new SCRM software. I put it through many different scenarios in an attempt to build a use case that would demo the product end-to-end, but the one function I found most interesting was when I imported a test batch of contacts with a csv file. While I was mapping address fields I noticed in the user interface it looked like I was plunking them all into one address field.  My prof services brain went into over drive at that point, asking questions like:

  • Well this is interesting… I wonder how this works when I search on multiple states to either flag accounts in my territory or run a report on my territory… you know, so I can keep an eye on my pipeline & and commissions?
  • I wondered if the data was being truly parsed into any sort of coded structure with constraints so that we didn’t have multiple dirty data entries for California: Cali, CA, CAL, …
  • What happens in the business logic layer if the user is doing manual account creation and skips the state field altogether? Boy! That will be a lot of fun for the Order Processing department when I push the sale back to them to invoice & ship! WHEE!
  • Users won’t care much if they’re using Googlefied-style searches on most screens, and while I have a deep respect for the need for more natural human language in developing business intelligence, the potential impact on the product’s future ability to integrate in the future with ERP/Accounting packages that rely upon the data in basic address fields like City, State and Country for segmentation that drive things like commission territories is worthy of forethought and a concession to the need for some standards.
  • I checked in with a respected company that develops web-based VOIP billing solutions and learned that they absolutely do hard-code those fields and only Googlefy the results on screens.
  • In short, the ‘C’ in CRM stands for customer, or in the world of data, it still stands for the Customer Record.
  • There must be respect for and knowledge of the Taxonomy of the way the customer handles the sales process once the external social lead becomes a real customer, while still enabling people to enter their own Folksonomy in less critical entry fields.
  • You don’t want a hard-coded relational monster with 236 possible fields for a single record, not counting related tables/fields (been there, done that, haven’t we?) but there is a bare minimum of account detail & segmentation that can’t be optional if the end goal is full CRM functionality including actionable reports & metrics.
  • If done right, this is accomplished with as few as 20 well thought-out fields.

It’s the ‘little things’ you don’t plan for now that will trip you up later when the analysts start vetting your solution.

In another example, I was testing Opportunities created via Twitter leads. I noted that the ‘Stage’ & ‘Likelihood of Close %age’ fields were not related in any way.

  • Simpler for the user, certainly, but that makes it much more difficult to deliver a true ‘weighted’ sales forecast to fulfill the Management part of CRM.
  • That also makes it more complicated to develop templates for simple B2C, Mfg B2C, Wholesale B2B, or other sales cycle processes that you can drop in for plug-n-play verticals.

These are only a few selected examples that seemed obvious and easily identified to this PS geek who has one foot firmly stuck in traditional data/process la-la-land, but it did cause me concern that the innovators might be trying so hard to innovate social into the mix that they have tunnelled their vision too tightly on the Social/Relation part of CRM. With too little strategic focus on the Customer (record) and Management (processing sales & acting on measurable outcomes) part of the acronym.

Aside from the points above, I’ve also concluded that truly visionary SCRM companies will have Professional Services Veterans on their teams. ;>

You will be asked to develop order processing features, or integrate to existing systems that handle those transactions. And if you’ve created a great product, you’ll need to migrate data from existing systems.

Are you building your solutions with those growth challenges in mind? Are you laying the foundation up front?

(Next post… the importance of ‘roles and rights’ in channeling leads through to sales/customer service efficiently. If you stretch your brain, you’ll note that this has intriguing impact on licensing models, too.)