軟體系統也要各司其職

在保險公司中，經常要看的乙個指標叫做13個月保費繼續率，這個指標的計算相當複雜，因為需要調取15個月之前承保的保單資料，然後再看當前的繳費狀況。不僅如此，對於保單來說，會有不下二十種保全操作，這些操作有多種會影響到這個指標，還有這些操作的組合，導致情況會更加複雜。

在公司中，最早的時候，這個指標是在核心系統中計算的，因為那時候公司還沒有資料倉儲系統。後來有了資料倉儲系統之後，就利用資料倉儲的能力來計算這個指標了。因為在資料倉儲中，會儲存歷史資料，而且會對那些資料進行加工處理，從而在計算繼續率的時候，可以直接取得相關的計算資料結果，而不知什麼都從頭計算。

而且這樣做帶來的好處就是，業務部門以此為準即可，不需要從各處取得資料，然後再比較。

對於公司的繼續率指標也是一樣，之前有好幾個計算繼續率的地方，每個地方的演算法都不盡相同，誰也搞不清楚哪個才是真正正確的結果，只有在資料倉儲中能夠計算之後，才有了真正統一的標準。儘管在那之後，拋棄已有的計算方式也經過了很多波折，但是隨著不斷地溝通，大家還是最終認可了資料倉儲中的演算法。

然而，最近有傳言說要在核心系統中重新計算繼續率，這絕對是一種倒退，也是核心系統開發人員的一場災難。

畢竟核心系統使用的是資料庫而非資料倉儲，計算這種統計資料並非是它的專長，就好像是拿著一把匕首去砍柴一樣，效果怎麼會好呢？而且還有可能會損害大家的積極性，就像匕首很快就會崩潰一樣。

而且，這樣做出來之後，又會有多個標準，到底哪個才是準確的呢？

另外就是嚴重違反了dry原則，既然已經有了很準確的繼續率值，那麼為什麼還需要再重新開發呢？而且這樣會帶來很大的開發成本和維護成本，誰來負責掏錢呢？

而且，現在系統的效能已經比較難堪重負了，而這種統計資料的演算法又會非常消耗資源，一旦影響到正常的業務操作，誰來承受這個責任呢？

在工作中，人要各司其職，在軟體系統中，各種各樣的系統也是一樣。