廢話不多說，直奔主題。

從實施效果來看，建議先拆分承保模組。

1、保全模組和理賠模組功能涉及範圍廣，拆分表時需要其他模組提供查詢介面和資料同步介面，如果採用另一種方案：使用同一個資料庫，則做出來的系統是個半成品，做不到真正意義上系統的拆分。

2、實驗效果不明顯，保險公司最為關注的是兩點：出單效率和理賠效率，所以從這兩個模組入手效果比較可觀，帶來的直接效益也比較明顯，另外，保全模組是最浪費人力和資源的，而且還不會給公司帶來直接經濟效益的，所以保險公司一般希望通過直接通過優化系統減少這部分工作量，但是由於保全模組的特殊性和複雜性，最後做出來的東西往往都是個半成品。

3、測試起來不容易，對於測試人員來說，無論是保全、理賠、收付，都是建立在已出單的基礎上，加之保險產品的多樣性，在測試過程中製造滿足條件的保單也會話費大量的人力，既然這樣為什麼不從錄單開始做，一步一步下去。

結合上面三點來看，在建設網際網路保險核心初期探索階段，如果模組選擇不清楚，思路不清晰，成本預估過於樂觀都會導致拆分效果不明顯，而且拆出來個半成品甚至廢品，這就平臺無辜的增加了系統維護成本。

目前多數保險公司從原始承保模組已拆分出來的系統大致有：規則引擎、核保核賠系統、錄單系統、財務收付系統等。

下一篇將介紹：承保模組具體建設思路，可拆分出來的子系統，分庫分表建議等。