我的組織正處於收購CRM 4.0以作爲通用軟件開發平臺的最後階段。向我們出售產品的公司已經讓高層管理人員相信，CRM將解決我們所有的生產力問題，並使軟件開發變得像點擊一樣簡單。 （他們不讀Brooks）Microsoft Dynamics CRM作爲軟件開發平臺？
由於我無法阻止CRM被我們開發者強加給我，所以我一直在研究如何管理大型CRM開發的複雜性。
我迄今確定了需要解決以下的複雜性：
在構建大型CRM應用程序時，我還需要考慮哪些其他複雜因素？
CRM作爲開發平臺有哪些限制？
編輯：這topic提供了更多的見解。
我已經與MS CRM 3.0工作所需的全部配置，現在4.0這裏是我的看法：
只要有可能，請重點關注標準最佳做法。不要過分地被CRM正在做什麼或想要你做什麼所困惑。
不要害怕破壞MS的「支持」。有兩個主要因素需要注意 - 貴公司是否可以讓您從盒子外面思考解決問題並進行未正式支持的定製/集成？ - 你是否習慣使用.Net，SQL，JavaScript等編程來實現你的代碼並實現你需要的東西？
我有時拍着我的頭100次試圖做一些事情的「支持」的方式，當一個小的調整，在這裏一個js文件或小分貝的修改有給我我需要的東西。
如果不斷與其他LOB應用程序進行數據集成很關鍵，那麼應該考慮像Scribe這樣的第三方工具（http://www.scribesoft.com/）。這並不便宜，但當涉及到與其他LOB應用程序集成時，基本上可以讓您獲得90％的優勢。
作爲一般規則，MS CRM在聯繫人管理方面非常出色 - 諸如跟蹤約會，進行郵件合併等。您可以將它用作您的核心HR系統 - 可能。財務系統 - 可能有點困難。進一步從其執行聯繫人管理的核心能力出發，您需要做更多的定製工作。如果MS CRM是解決該問題的正確解決方案，則您需要做的越多定製工作就越應該考慮。
事務支持
如果你的應用需要從底層平臺的事務支持，Dynamics CRM中是不正確的選擇。原因是因爲目前Dynamics CRM SDK Web服務不支持事務。
基準線是在這裏：Does MSCRM web-service support database transactions?
既然你想利用動態CRM作爲一個平臺，這意味着所有的業務邏輯應該利用動態CRM SDK Web服務作爲數據訪問層。但想象一下，如果沒有事務支持，並且您將一系列Web服務調用作爲一個工作單元調用，並且其中一個Web服務調用失敗。這意味着您可能會遇到數據完整性問題。
配置
平時我創建一個自定義實體，稱爲配置，將存儲所有當前的CRM應用程序所需的相關配置。已創建完成後，就可以使用動態CRM SDK Web服務來讀取配置自定義實體
我知道你很可能會順利進行到您的Dynamics CRM中的部署，只是幾個小祕訣：
我會避免不受支持的變化純粹是因爲它變得太硬跟蹤最終的變化。由於Dynamics CRM允許開發人員製作C＃插件並訪問Web服務，因此通常不必爲任何不重要的操作進行不受支持的更改。另外，如果你不得不打電話給他們的支持人員，你還需要運行必須隱藏MS變化的輪盤。我知道很多人會包括外部JavaScript文件（jQuery等）和其他有些良性的變化，但是當不支持的編輯涉及任何非可視化的東西時，請嘗試在心裏停下腳步。
查找到這句話的Microsoft Dynamics XRM，有上是優秀的標的幾本書，http://www.thecrmbook.com/是特別好，因爲它提供了一些好的自定義代碼與您的CRM使用。
來源控制您的自定義xml，不要讓人們觸摸數據庫，也可以使用Google Halan CRM工具，並將其用於腳本化CRM定製和JavaScript文件。比編寫自定義PowerShell腳本來做同樣的工作更容易。
請別再叫它 「CRM」。這是一個通用的軟件類，不是產品名稱。 – Javier 2009-07-07 19:43:27
Microsoft在其自己的文獻中將其產品稱爲「Microsoft Dynamics CRM」，與Dynamics AX，GP，NAV或SL（其他產品）相反。 http://www.microsoft.com/dynamics/product/productoverviews.mspx – 2009-07-07 19:53:39