So you’ve decided to add Enterprise Search to your firm’s ECM arsenal. You should all be familiar with the many benefits of Enterprise Search: search consolidation, knowledge management, and quick, global search results, resulting in improved productivity and efficiency of the work staff. You should also all be familiar with the drawbacks: cost and complexity.
Let’s leave those drawbacks out of the equation for now, and focus on what should be a benefit: the ease of finding documents across the enterprise. How could this be bad, you ask? The Enterprise Search utilities are designed to respect the security of whatever system the content lives in. That’s good, right? Well, what if the documents aren’t secured in the source repository? Some older systems make it inherently difficult to find documents with the native search interface/engine. Since it may be difficult to find documents, users start to skip the step of securing documents. Their thinking is, “Well, no one can find the document anyway, so why do I need to waste 45 seconds and add security to it?”. These unsecured documents could be financial statements, HR documents, or any other content that should be secured.
Enter Enterprise Search. Once Enterprise Search is introduced, that open level of security would now be apparent to all users of the system. This could cause headaches in the enterprise, and put a black-mark on the Enterprise Search tool — even if it’s not the Enterprise Search tool’s fault. This is just one example of the implications of adding new ECM functionalities to an environment. The security example here can be alleviated by scripting a security update to the source repository prior to the deployment of the Enterprise Search; essentially resolving the issue before it can become a security nightmare.