整合項目難做，做過的人都是很容易知道的，這也是為什么整合項目通常要規劃很久、實施很久，而且還要花費很大的財力的原因，在之前的blog中曾經寫過整合項目難做的一些地方，像數據分析、客戶的不夠理解等。
隨著對于整合項目實施的逐步深入，碰到的難點在逐步的增多，目前手頭的一個整合項目接近完成了，對于這種類型而言的整合項目中的難點估計該出現的都已經出現了，總結下來除了數據分析這個大難點之外，還有的難點就是業務理解的不一致、系統設計的不一致和協調這三個，其實業務理解的不一致和系統設計的不一致可以列入數據分析這個范圍，但由于這兩點對于整合項目的影響較大，會很大程度影響整合項目實現的難度，所以還是單獨列出來講講。
業務理解的不一致
當整合兩套業務系統時，對于基于服務(web服務/中間標準XML等)提供兩套系統的業務功能的時候還好說，因為可以根據業務的需求來制定一個統一的中間標準，而對于兩套系統通過數據庫直接連接整合的項目來說，則更為麻煩，直連庫的這種在很多的情況下都會以雙方的數據庫結構說明書為準，這個時候在做整合時會出現一個很容易忽略的地方，就是兩套系統的設計人員對于業務理解不一致的情況，特別是兩套功能基本一致的系統時，這個問題會非常的突出，很明顯的一個例子就是在系統A中某個字段是必填項，而在另外一套系統中這個字段則是非必填項，有些可以通過數據庫約束來避免這種錯誤的產生，而有些則不行，例如在系統A中可能認為當字段B不為空時，字段C也不能為空，而在系統B中可能就不是這樣的了，這種現象呢，通常都只有在進入測試階段時才能發現這樣的錯誤，因為在數據庫結構說明書中通常很少會有寫的這么詳細的，尤其是這種涉及業務規則的地方，更復雜的就是帶業務規則的字段，那就會更麻煩。
這樣的現象就會導致整合項目的周期不斷的變長，而且錯誤直到測試階段才暴露出來，再加上可能錯誤會不斷的一個接一個的逐漸的才能暴露出來，有可能會導致對于用戶的信心以及項目成員的信心造成不小的打擊。
這種情況通常在建設綜合平臺、廢除原系統的時候容易出現，因為原系統的這種數據庫的業務規則可能是很難了解到的，只能隨著項目的不斷進行才能逐步的暴露出來。
系統設計的不一致
這種現象對于整合項目而言是非常大的難點，這樣的難點通常都出現在通過數據庫直連實現整合的項目中，出現這種現象的時候首先是需要盡量協調其中的一家公司看看能否根據另外一家公司的設計來生成符合設計的數據，如果雙方都協調不了的話，整合廠商就只能自己來做了，這個時候就非常的復雜了，需要了解兩方的設計，然后在數據進行交換的時候來根據一方的數據來生成符合另外一方設計的數據。
這種情況對于整合廠商而言，是非常復雜的，完全不夸張的說幾乎是超出了做兩套業務系統的難度。
協調
廠商間的協調是整合項目中最難的地方，在整合項目中客戶是非常重要的角色，客戶能否照顧好各家廠商的利益協調好各家廠商進行配合，很大程度上決定了整合項目能否成功，如果廠商不配合的話整合項目要成功的可能性非常低，一旦協調不好很有可能會導致整合廠商成為客戶、其他系統開發商之間最難受的一方，也會直接導致整合項目的成功性下降，整合廠商在進行整合項目之前應該首先調查好系統需要涉及的開發商是否能提供配合，如有不怎么配合的開發商的話需要慎重的考慮該接口的處理。