May 13, 2011, 10:31 AM — If Value Engineering is the identification of different implementation strategies to achieve the business goal, the ultimate in value engineering is to identify requirements that don't need to be done in the first place. Although security and access control would seem to be a poor candidate for this kind of requirements elimination, in many situations the technical solutions are so clumsy and expensive that there's almost no ROI.
This can be politically touchy, as nobody wants to be the one to say "no" to risk reduction and compliance. This can be a particularly pointed issue with CRM systems, which tend to be the most politically charged of any Enterprise application. So... don't say no -- instead say "that wont be effective."
Keeping the users to their own knitting
Let's start with an example: sales' ability to see and change opportunity records in the CRM. The starting point is typically "a sales person should see only the deals that they own and the deals of those that report to them." This is easy to understand, and clean to implement in CRM systems. Sometimes there will be a plot complication -- "the reps should be able to see that another rep's deal exists, but not be able to see any of the details." CRM systems can handle that kind of exception without too much trouble.
But in large, multi-channel organizations, there are territory overlays and named accounts. Consequently, it gets harder to automatically determine what a sales rep is supposed to "own." Their territories may have "holes" in them, and even if they don't, multi-national customers present a challenge to the "rep ownership" rules. For example, if GM Canada is making a purchase but the decision is being made in conjunction with GM USA, which rep owns it? This becomes much more complicated when selling to government contractors, where different projects within the same customer business unit may be "owned" by different sales reps.
Enforcing what started as a simple rule now would now take a complex series of lookups and exceptions. And of course, no CRM system has this processing built in: you must custom code it. But the bigger challenge is maintaining the lookup table(s) that have to be changed every time there's a new rep, new partner, or customer merger or divesture. Sure, you could create a nice UI to maintain and test all the moving parts, but in large organizations the code and lookup tables wont be maintainable. Consequently, the security infrastructure will eventually give somebody the wrong level of access, and it's likely to irritate a fair percentage of your users.