最近一直在忙於風險系統。
系統取數，涉及到行內多個部門。大致有信貸、授信、統計、運營、清算。
在感受到幾家銀行的各種信貸系統之後，心中有想掐死做信貸系統分析人的衝動。
整體而言，大部分系統設計基本符合要求。
屬於能看，也能用的範圍。
但是在對需求分析和數據庫表建設的做的不足的可以說佔絕大多數。
當然，我也不能否認我們的系統也存在設計問題。
要做到一個好系統，不是說所有功能強大就可以，也不是說前臺頁面好看能用就算perfect.
一個相對優秀的系統，首先要滿足的是需求！ 其次考慮應該是設計，最後考慮的應該是功能。
一、需求，包括業務平時的一系列流程。以前學習總是記得“業務流程重組”這一概念。不過不是說所有的業務流程都需要重組，也可能是簡化或者是優化。舉個簡單的實例：授信與貸款。
業務的流程是，先授信後用信（使用授信，暫稱之爲用信）。
問題1：對貸款做授信，還是對客戶做授信？
問題2：貸款和授信的對應關係是什麼？
問題3：貸款前後是否對授信有影響？
問題4：貸款結清覈銷，和授信結束怎麼處理？
以上問題，是一個系統分析師應該考慮的最基本問題。
第一個問題，應該是對客戶授信。授信在貸款之前，事前你不可能做到對貸款授信。
第二個問題，一筆貸款對應一筆授信，一筆授信對應多筆貸款。
第三個問題，貸款前授信是確定的，若果授信不足可以做臨時授信或者特殊授信。授信在貸款後會減少，即可用授信減少。
第四個問題，貸款結清不意味着所有的授信都結束。舉個示例：授信50W，貸款20W。剛爲此客戶放貸結清貸款，授信尚在，還未失效，此客戶仍舊可以用此授信繼續貸款。授信結束如何處理？在系統上確實應該有個失效標識，而不是單靠日期去判斷（靠日期判斷的在後期每次都需要處理）。
而我遇到的，實際情況卻是。貸款和授信是分開的，也是對客戶授信的。但是一個客戶有多筆授信，讓人根本不知道這筆貸款對應哪筆授信！這對於業務來講，也許直接能看出，貸款對哪筆授信（額度上能判斷一二），但對於一個系統而言，這是不允許的。至少應該有個標誌，能夠唯一確定，一筆貸款對應一筆授信。在這裏我比較欣賞，在貸款表中加入授信號的做法。
二、設計。設計一旦出錯絕對很致命！ [感覺要寫的太多了，單就我知道的開始]
分類：整體設計，詳細設計。整體設計：結構設計、模塊設計，功能設計；詳細設計：程序設計、數據庫設計
行內的結構設計、模塊設計，大致還算令人滿意。不足之處有：在頁面關閉，切換做的不好；擔保菜單位置不妥。
功能設計，缺點相當明顯。一個客戶，多個支行都有各自的一個客戶基本信息。簡單需求描述：客戶可以在一個支行登記，在其他支行貸款。但是我所看到的信貸系統卻是，每個支行都有自己的客戶基本信息（即便是同一個客戶，也有不同的信息）。關注事件，這一字段，設計爲下拉框可多選爲最佳（他們設計爲三個文本框）。
程序設計和數據庫設計，就以我們現在所做的系統爲例。
程序設計：層次結構不清，共用類太多（耦合性太高），程序可重構性太強
數據庫設計：字段不統一，需求分析缺失字段，未細考慮空間問題。
--------------------------------------------------------------------------------------------------------------
從最初接觸，稍微的開發，到後期的各種修正，完善。不說是掉了一層皮，也是因痛苦死了不計其數的腦細胞。
回想起，數據庫的sql優化從跑不動到幾分，功能的讀表寫文件到視圖寫文件，程序的共用到拆分，頁面拙劣到美觀。已經不能用“完善”這兩個字來形容了...
真心迫切的希望，能有專門的分析設計師，事先分析設計好，而不是抓到需求就開始做，然後再去逐步修改。
考慮到系統的可移植性和健壯性，個人覺得還是應該能低耦合點、精煉些更好。
另外需要注意的是，程序和數據庫，壓力比重要適當。
謹以此文能爲諸位同行共勉。
2014年3月27日11:06:32