Having reviewed the pros and cons of both the
Account-centric and
Individual Path approach we can now attempt to start drawing some conclusions.
In short, I'd venture to say that the
Individual Path approach is considered to be the overall better approach as it’s less prone to “disorganization”. Which to me is the most important factor when it comes to organizing content in SharePoint. There might be exceptions to this on a case by case basis, as it will depend – as has been hopefully illustrated – on the nature of the entity for which the documentation is being stored.
Now that we've chosen the Individual Path, the question then becomes - at which entity levels should documentation be stored? That is,
as has been illustrated, you can specify to have the "Documents" tab show up on virtually any CRM entity. So you could check off accounts, contacts, opportunities, orders, quotes etc. such that any documentation pertaining to the account will be stored at that level, and any documentation pertaining to the contact will be stored at that level, and any documentation pertaining to opportunities will be stored at that level, and so on and so forth.
The issue that now becomes apparent is that of "user discretion". Let's use a "Statement of Work" (SOW) document as example. User A might consider this to be opportunity related and therefore may decide to go into the opportunity to store this document. On ther other hand User B might consider this to be more of a company document and therefore may decide to store this against the parent account. User C might be just too lazy to navigate all the way down to the opportunity and may also store it against the account for no particular considered reasoning.
Then there is the reverse scenario where User D wants to go and review the document that was stored. And discovers after searching around a bit that it is stored in a different location than a previous SOW.
An SOW is obviously just one example of this issue - but hopefully illustrates that the issue with selecting too many entities for associating documentation is that it can lead to additional disorganization and lack of consistency/standards as far as content management is concerned. The more levels selected the more of an issue this is likely to be.
Both the storage and retrieval of documentation must be as intuitive and easy as possible. In short, users should know - without having too think about it too much - where to go and store a document or conversely where to go to find a particular document.
Therefore one of the conclusions to draw here is as follows:
Do not choose "select all" for the Select Entities settings. Give it careful consideration and make sure that the entities selected are distinct enough such that it keeps it simple and logical in terms of document storage and retrieval. If you do not do so, you are less likely to benefit from the CRM/SharePoint integration due to the fact that your documentation will become less organized and harder to find. The end result being that it will decrease the chances of having this feature successfully adopted within your organization.
SharePoint itself of course has a ton of features and functions designed to better organize content. Until now, we really have focused on the CRM side of the CRM/SharePoint integration equation. However I think that the most successful implementation of this integration incorporates taking advantage of some of the key SharePoint capabilities. We'll review this
next.
Next:
CRM 2011 Document Management Settings: SharePoint Best Practice
