Who Owns CRM Data at Your Company?
In most enterprise IT systems, record ownership is about as controversial as a ham sandwich. Not so in CRM. In fact, it can become quite the political topic. Fortunately, good governance can solve most CRM data ownership problems.
Fri, January 04, 2013
CIO — In most enterprise applications, ownership of an individual record just isn't that important. Yes, you want to make sure that you keep confidential information away from prying eyes, but the information is usually dealt with as an entire class of data such as "all salaries" or "this group's charge numbers." Meanwhile, the handling of access privileges is often just a matter of following user-group-world hierarchies.
Some data in a CRM system follows this pattern. For example, the access privileges for data about your users (such as "name" or "phone") can be handled in a simplistic way. When it comes to the meat of CRM data, though—contacts, relationships, accounts, deals, cases and so on—access privileges for those records have to be handled on a highly individualized basis. And when you get the privileges wrong, you'll know about it in seconds via a high-volume phone conversation. This is definitely not mañana territory.
Commentary: Why CRM Data Trumps CRM Systems
The main reason for this is the sales staff. They have families to feed, and if your company uses a highly leveraged compensation plan, the only way they have a nice vacation is by winning deals. Depending on your industry and your company's sales culture, the salespeople can be almost maniacally territorial. Taking away any increment of visibility or control over their client and prospect relationships is akin to stealing. There's no blaming them, as they're simply playing by the rules management has given them.
CRM Data Ownership Gets Complicated
In most CRM systems, the first control point for visibility is the record owner. This can be set only to a single user, so the "owner" may be supplemented by "sales team" and "support team" abstractions that provide shared access. In addition, your system may have conditional ownership privileges for global accounts; you see this in follow-the-sun customer support models and sometimes for local account managers. Just to keep things interesting, there can be multiple levels of overlay.
These mechanisms can get complicated. Unfortunately, with the really fancy ownership models, there's only two ways to see what's going on: Top-down, by inspecting all the rules and code in the abstract, and bottom-up, by working with specially-crafted test cases. You won't find any pretty graphics here—at best, it's a series of spreadsheets—and troubleshooting often involves white-boards and conference calls. That's right, Star Trek fans, stone knives and bear skins.
There's yet another layer of complexity, too. In most cases, ownership of each object is almost totally independent, unless you have set up a strict master-detail relationship. (Really.) This means that ownership of an Account is more or less independent of the ownership of Contacts or Cases at that Account. The specific rules used to determine the privileges are typically independent, and the record updates are independent unless you've written some of your own code to update child records to "follow the parent." (Really.)