求高手解答 BPO 作業。

經在國內最大的金融行業BPO公司供職過壹段時間，並親手組建了那裏的需求分析團隊，使得那裏的需求分析從無到有，從稚嫩到成熟。想想現在那裏的老大是我從壹個應屆生壹點壹點培養起來的，心裏有說不出的滿足感。可是中國壽險行業BPO還面臨這很多問題和困難，還不能說是壹個成熟的行業。關於壹些行業性質的問題之前跟那裏的領導提過，但是因為種種的原因，壹些事情始終沒有能夠的到改善。這裏先來談壹下實施BPO之後給壽險公司帶來的問題和BPO核心處理系統本身的弊端。由於BPO綜合處理系統與壽險公司核心業務系統有著本質的區別，壽險業務流程外包會給壽險公司帶來以下問題： 1、數據層面的問題件數量激增。這個公平的講並不全都是外包公司的問題，也有壽險公司業務填寫不規範的原因。總得來講外包的原因多壹些。那麽是什麽原因造成了問題件數量的激增呢？從我過往的經驗來看主要有以下幾點： A、必然現象，壽險公司選擇了實施BPO也就意味著新契約處理流程的必然性增長，環節的增多；也就意味著處理鏈、溝通鏈、糾錯鏈的增長，從而問題的增加就成為了壹種必然現象。 B、人的因素，無論技術先進到了什麽程度人仍然是最重要的因素——這個亙古不變的真理。壽險公司在實施BPO之前那些錄單的內勤是什麽樣的水平？什麽教育背景？對自己公司的規則理解到了什麽程度？壽險公司絕對不能夠期望BPO公司的錄入人力有那樣的水平——否則BPO公司將不可能會有成本優勢。 C、系統的差距，BPO公司壹般而言會用自己的綜合錄入平臺來處理多加壽險公司的錄單業務，這樣的綜合處理平臺對規則的控制是不可能與壽險公司的生產系統相比的。其實這裏是BPO公司可以通過自己的努力彌補的地方。目前BPO處理系統的現狀是會有壹個以錄入任務為核心的，最小粒度為字段的綜合處理系統實現對數據的錄入，並根據每個客戶的不同要求專門為該客戶開發壹套輸出程序，客戶方要求的規則壹般而言會在輸出程序中實現，對於輸出的邏輯檢查也會在輸出程序中實現並標記問題件。據我所知，目前還沒有壹家BPO公司有能力實施規則引擎，這也就意味著基本上BPO公司實現的規則檢查只能是事後檢查，並標記問題件不能像生產系統控制投保規則壹樣做預防性檢查；這也意味著基本上 BPO公司實現的規則檢查與規則轉換多數是靠寫死代碼去實現，這樣的情況下BPO公司不太可能做出非常完備的規則檢查，這樣也就造成了問題件數量的增加。 2、由於某些BPO公司經常會犯壹些壽險公司員工難以理解的錯誤，可能更多的人願意把這些問題歸因為系統原因。BPO公司所犯的壹些錯誤是壽險公司的內勤員工也經常有可能犯的，所以有的錯誤對於壽險公司的員工來說是可以理解並寬容的；例如投保單地址填寫不清的導致填寫錯誤的問題，至今沒有壹家敢說比較完美的在系統層面解決了這個問題。（這裏多說壹句，在以後我搞銷售支持系統之後發現，如果在銷售支持系統裏面實現投保單預錄入功能應該是可以比較完美的解決這個問題和之前提到過的數據層面的問題件數量過多的問題——但是這樣的構想面臨這代理人或者客戶的接受能力方面的挑戰）但是有壹些問題在壽險公司員工的眼裏是不可能出現的錯誤，這樣的問題的出現給BPO公司帶來了很大的壓力。對於這樣的問題，我覺得主要原因有兩個：A、人的因素——跟前面壹樣，我們不能指望BPO公司的錄入員具備和受過高等教育的壽險公司內勤壹樣的常識和對該家公司規則的理解。B、系統的差距，壽險核心系統與BPO公司的綜合處理平臺存在著巨大的差距，其中最重要的是BPO公司的綜合處理平臺缺少了核心系統的靈魂——產品模塊。這也就意味著 BPO公司的綜合處理平臺不能夠做產品級別以及更精細的責任級別的規則校驗和處理，它所能處理的只是相當於投保規則通則裏面的部分內容，而熟悉投保規的人都知道，通則估計也就是投保規則的20％左右…… 3、高峰期的風險問題，如果從壽險公司SOA框架的角度考慮，我這裏討論的是壽險系統錄單組件的性能問題。每個保險行業的人都知道每月的25號左右會有壹個交單的高峰，BPO公司為多家壽險公司服務，那麽在他們那裏會形成壹個由多家壽險公司波峰疊加形成的更大的波峰。這裏無疑會對BPO公司的運營交付能力和系統承載能力提出很大的挑戰。壽險公司的高峰是非常講究時效的，但是這個時候也是BPO公司最容易出現問題的時候。這個時候最容易出現兩類問題：A、運管資源爭搶問題，某個壽險公司很然出現了很大的投保單錄入作業量將必然影響BPO公司對著該家公司本身和這個BPO公司服務的其它壽險公司的運營交付。B、由於系統承載能力問題出現的系統宕機，由於成本原因，多數BPO公司沒有應用高性能的數據庫軟件如Oracle、DB2等，也沒有應用高性能的硬件如小型機；現實中較好的情況是使用MS SQL 跑在若幹臺沒有做過負載均衡的PC Server上面，PC Server是按照客戶劃分的，所以某壹個客戶的業務量在沒有先兆的情況下突然增大就可能宕機。說了這麽多關於BPO公司問題的東西，其實我們不可否認的是行業分工的細化，讓低端的人力去發揮她們的比較優勢是潮流的趨勢，BPO也是壽險行業運營發展的重要趨勢之壹。這裏我還是結合自己的經驗談談BPO系統的未來吧。 1、系統方法論層面的改進——棄CMMI投身敏捷開發。BPO公司相對與壽險公司自己錄單的最大優勢是成本，壹般的BPO公司給壽險公司開發輸出程序都是免費的，這樣開發到底需要多少時間就變得非常重要，另外壽險公司的規則恐怕也是天底下最易變的規則了，如何能對客戶的需求做出迅捷、正確的反應也變得至關重要。從這個角度來看BPO公司的質量管控方面的人選應該從ThoughtWorks裏面找壹個高手。 2、固件化、裝配化：如前所說，BPO公司會為它的每壹個客戶單獨寫壹個輸出程序（因為每個客戶的需求不壹樣）。但是項目間輸出程序有大概60％－70％的代碼是重復的，這裏完全有必要、有可能把其中的公***的業務邏輯處理抽象出來形成輸出邏輯組件。需要的時候將組件進行裝配就可以進行測試環節。 3、產品化：BPO公司有很多壽險的業務邏輯是實現不了的，其深層原因是缺少的壽險業務邏輯的靈魂——產品的概念。如果BPO需要在新契約業務上面更進壹步則必須實現這個組件或者模塊。另外現在很多BPO公司都把理賠BPO作為其業務的新的增長點，這裏對產品化的需求更為強烈——產品是理賠的基礎，如果要實現“無歷史賠付額的簡單理算”則必須以實現產品概念為前提。 4、期待行業數據交換規範的出現：目前BPO公司與壽險公司之間的數據交互基本上是依靠XML完成的，而XML的格式與數據傳輸的模式都是壽險公司的核心系統供應上提供給BPO公司用的，BPO公司沒有任何的話語權，這也無形中增加了很多二次開發的工作量。有的比較好的壽險公司會用銀保通的行業規範給BPO公司，作為外包的數據交換規範。這個規範的結構是非常科學的，而且做到了與核心平臺無關，但是也還是存在壹定的局限性：A、關於保全操作交易的數據格式定義過於簡單，也許可以滿足銀保通的保全需求，但是無法滿足普通壽險的復雜保全需求。B、沒有關於理賠操作交易的數據定義，目前所有的理賠BPO還都是用Excel進行數據傳輸，還屬於數據傳輸的“刀耕火種”時代。C、查詢交易過於簡單，不能滿足理賠關於“以案件為核心”的歷史賠付額的查詢，這也造成了理賠BPO不能進行復雜理算，無法再向壽險公司運營流程上價值鏈的更高端邁進。