【文章內(nèi)容簡介】 Urbis 核心業(yè)務系統(tǒng) B2B 系統(tǒng) RA 客戶端系統(tǒng) 柜面終端系統(tǒng) 系統(tǒng) 我們使用下表中所設計的內(nèi)容，來收集這些應用系統(tǒng)的狀況：表 21：中國建設銀行應用信息系統(tǒng)狀況表系統(tǒng)名稱：19 / 64調(diào)查內(nèi)容 說明系統(tǒng)名稱所支持業(yè)務內(nèi)容系統(tǒng)描述供應商名稱購入/開發(fā)時間系統(tǒng)類型 P、C、V P= 內(nèi)部開發(fā)或供應商專門為建設銀行開發(fā)、C= 外部采購產(chǎn)品客戶化并由內(nèi)部支持、V= 供應商提供產(chǎn)品及支持應用中間件的使用系統(tǒng)接口的情況（報文、格式等）與其有連接的其它系統(tǒng)名稱被該系統(tǒng)調(diào)用數(shù)據(jù)的系統(tǒng)調(diào)用該系統(tǒng)輸出數(shù)據(jù)的系統(tǒng)使用該系統(tǒng)的部門/用戶（請指明系統(tǒng)的應用范圍，如在總行或哪級分行使用）系統(tǒng)使用狀態(tài) U、P、D、R U = 在線使用、P = 已采購、D = 在開發(fā)、R = 待淘汰業(yè)務增長率（可由系統(tǒng)用戶填寫） ％未來三年的預計業(yè)務量增長率。如果該系統(tǒng)不是基于交易的，則使用基本生產(chǎn)單位，例如，發(fā)出帳單數(shù)量等。系統(tǒng)版本狀態(tài) 0、 0= 當年投產(chǎn)、1= 上年投產(chǎn)、2= 前年投產(chǎn)、操作系統(tǒng)操作系統(tǒng)版本操作系統(tǒng)使用時間數(shù)據(jù)庫類型與版本硬件平臺版本硬件平臺使用時間（年）數(shù)據(jù)處理模式 B、P、O B = 批量、 P = 部分在線、O = 100% 在線 基于 Web A、P、N A = 已經(jīng)、P = 可能、N = 不會開發(fā)語言 應用開發(fā)所使用的編程語言支撐工具 應用系統(tǒng)支持所需要的主要工具軟件架構（B/S,C/S 等）系統(tǒng)優(yōu)點現(xiàn)存問題對本系統(tǒng)的升級具體要求對本系統(tǒng)的升級具體計劃注：在說明中可以闡述系統(tǒng)的各個應用模塊在總、分行的的功能分布情況 系統(tǒng)調(diào)查及訪談結果 建設銀行 IT 系統(tǒng)調(diào)研結果我們對于建設銀行主要應用系統(tǒng)應用信息系統(tǒng)進行了資料層面的調(diào)查，并對調(diào)查結果進行匯總。具體結果參見本文第五章。 對建設銀行 對分行系統(tǒng)的訪談結果建設銀行為本項目選擇了陜西（Unisys 主機）河北（RS/6000 主機）、福建（AS/400 主機）、上海（ES/9000 主機）四家分行的科技處長或開發(fā)中心主管，和畢博管理咨詢的項目工作人員進行了訪談。根據(jù)對建設銀行這四個有代表性的分行的科技處處長的訪談，我們得到了以下主要信息。訪談的詳細記錄，見先前提交給建設銀行的訪談紀要。1. 分行外圍系統(tǒng)的構思大體相仿，目標都是用大前置整合渠道、管理交易、落實本地特色業(yè)務；中間業(yè)務平臺完成新中間業(yè)務的定義和外部系統(tǒng)的連接。但在落實參差不齊，有的分行還沒有完整的大前置，中間業(yè)務平臺的功能也各不相同。2. 分行核心業(yè)務系統(tǒng)平臺各不相同，省級集中的方式不同，版本不同3. 在安排各自的 IT 工作上，分行的策略各不相同4. 各分行都或多或少的開發(fā)了管理信息類的系統(tǒng)5. DCC 項目獲得高級主管的足夠支持，系統(tǒng)規(guī)劃較完整6. DCC 項目存在諸多一定的風險，如人員保證、符合項目計劃和預算、系統(tǒng)測試的條件、系統(tǒng)切換、異構的歷史數(shù)據(jù)的集中過程等方面。）7. DCC 項目規(guī)劃支持目前通行的產(chǎn)品類型，對今后一段時間內(nèi)金融產(chǎn)品多樣性的支持沒有明確答案8. 都認為版本統(tǒng)一比數(shù)據(jù)集中更重要21 / 649. 都認為管理信息系統(tǒng)的開發(fā)重點在于數(shù)據(jù)的獲取和全行的數(shù)據(jù)標準10. 分行目前新的業(yè)務需求不多,處于優(yōu)化的過程11. 缺少項目實施后對項目效益的評估 使用參照體系結構模型考察建設銀行現(xiàn)行的應用系統(tǒng) 參照體系結構模型介紹我們進行 IT 規(guī)劃的一個重要參考，就是參照體系結構模型。該參照體系結構模型已經(jīng)在其他國家的銀行行業(yè)的客戶中得到實施、驗證并進行了改進。我們用參照體系結構模型作為對現(xiàn)狀分析階段所收集的信息進行分類和分析的工具，同時也將用來輔助設計建設銀行的目標應用體系結構。圖 31 參照應用體系結構圖23 / 64每層次的定義、含義和每層系統(tǒng)實例如下： 渠道層 渠道是銀行和它的客戶進行交互的界面。為方便起見，我們將銀行渠道分為以下四種：? 電子渠道——電子渠道是通過數(shù)字設備訪問銀行系統(tǒng)的總稱，包括 Money 或 Quicken 這樣的 PC 軟件、Web 的訪問、移動電子設備（手機、PDA 等）、交互式電視等。他們應該通過統(tǒng)一的交換平臺向主機發(fā)送交易請求。Email 也是一條渠道，雖然它可能要通過專用的軟件（如 BridgeWare）才能產(chǎn)生交易請求。 ? 呼叫中心——呼叫中心在結構上分為 ACD（自動呼叫分配） 、IVR/AVR（交互/自動的語音應答）、CTI（計算機/電話集成）。當網(wǎng)絡帶寬足夠?qū)捛医?jīng)濟時，完整的圖象交換也可以實現(xiàn)。當前的呼叫中心的體系結構都假設：在對外服務時只有一個邏輯上的呼叫中心，而實際上建設多個物理的呼叫中心?？梢栽诙鄠€呼叫中心進行負載均衡、實現(xiàn) CTI 交換。? 支持渠道—現(xiàn)在包括所有的自動化機具。傳真和郵遞渠道也可以包含在其中。最終跨渠道的電子現(xiàn)金的表單的處理也會包含在其中。目前尚沒有支持性渠道的統(tǒng)一的概念定義。? 傳統(tǒng)的營業(yè)網(wǎng)點——柜臺、綜合柜員制。 渠道接口管理層 渠道管理層負責渠道設備的物理管理和集成（幾個渠道共用）管理，它可以允許在渠道的界面做個性化定制。渠道管理有以下幾個關鍵問題：? 渠道管理—管理特殊的渠道比如管理 Email 的 Brightware。也包括交換平臺管理的各個渠道。為了利用單渠道管理的界面表達優(yōu)勢，應該在該層中建立界面表達子層。? 界面表達——界面表達將銀行服務傳遞到界面終端。在 Web 界面方面，界面元素應該能夠得以管理、維護和版本變更；對于呼叫中心，則包括腳本代碼和代理服務管理。? 發(fā)布——利用技術將信息發(fā)布給銀行客戶。包括廣播、多頻道的能力和發(fā)布管理軟件，以及允許聲音、數(shù)據(jù)、圖象通過 IP 一起傳輸?shù)臋C制。例如 Pointcast 和 MBONE。? 個性化——將需要傳輸?shù)男畔?，根?jù)客戶個人的定制，以獨特的方式發(fā)布的技術。個性化技術有多個層面，例如： Broadvision公司著眼于全部表達的個性化；Vigte 公司則著眼于基于會話活動的表達的個性化。 客戶交互層客戶交互層保存的是，每個客戶和某銀行及其每一個合作銀行的每一次接觸的歷史的全局視圖。該層包括以下功能：25 / 64? 客戶交互軟件——提供給用戶一個和銀行接觸史的單點視圖。這可以通過數(shù)據(jù)映射實現(xiàn)，也可以通過數(shù)據(jù)復制實現(xiàn)。? 工作流——既可以通過客戶管理管理系統(tǒng)中的工作流機制實現(xiàn)，也可以通過象 Eastman 或 AWD 這樣的企業(yè)工作流產(chǎn)品的界面實現(xiàn)。如果連接到象 Blaze 這樣的業(yè)務規(guī)則引擎中處理流程邏輯，效果更好。銀行的業(yè)務邏輯將逐漸地從核心業(yè)務系統(tǒng)這樣地系統(tǒng)中抽取出來，這是趨勢，代之以 CORBA 組件或者業(yè)務規(guī)則引擎這樣的體系結構。? 客戶交互的完成——現(xiàn)實中，有類似于客戶手冊之類的文件支持客戶交易的完成。在系統(tǒng)中，可以執(zhí)行自動化的、體現(xiàn)法律關系的、個性化的交流手段。為了使客戶交互完成的成本最低，要盡量減少手工介入。? 銷售和服務的前端系統(tǒng)——該層應該開發(fā)為組件形式，駐留在應用服務器上，其物理位置可以是任何地方。之所以將該層置于客戶交互層而非產(chǎn)品引擎層，是強調(diào)它的重要性和邏輯上的位置。這個以對象為基礎的應用，會和客戶的信用數(shù)據(jù)、信用評分、以及后臺系統(tǒng)交互。信用評分引擎可以部署在這一層，如果它太復雜，也可以部署在后臺系統(tǒng)。 操作型客戶管理層操作型客戶管理層，控制銀行和客戶的商業(yè)操作面的關系。真正的商業(yè)處理是按照市場規(guī)則進行的個性化的運作。該層包括以下幾個方面的系統(tǒng)功能：? 客戶和客戶家庭的商業(yè)價值? 組合的風險狀況? 市場營銷活動在邏輯上，操作型的客戶數(shù)據(jù)庫和分析用的數(shù)據(jù)庫是分離的，因為二者是對不同數(shù)據(jù)類型的數(shù)據(jù)的訪問。在物理上，兩套數(shù)據(jù)庫也是通常分別建立在不同的平臺上，以支持不同類型的服務。 分析型客戶關系管理層客戶關系管理的基本理論認為，每個客戶都應該被視為單獨對待，特別是給銀行帶來良好利潤的客戶。分析型客戶關系管理層整個建立在一對一市場營銷的理論基礎上，功能包括：? 客戶價值分析? 個性化和產(chǎn)品開發(fā)27 / 64? 客戶行為分析? 家庭的價值分析? 市場營銷活動的管理? 客戶屬性定義 業(yè)務集成層 .該層提供端到端處理的“粘合劑”，可以在該層進行大量的增值服務。該層的基礎是基本連接，由通訊中間件提供，如消息中間件、COM/DCOM、CORBA 通訊機制，也包括交易中間件（如 CICS）。建立于該層之上的增值服務包括：數(shù)據(jù)的集合（例如兩個交易請求合并為一個后再發(fā)出）；數(shù)據(jù)的分割（例如一個交易請求被分解為多個交易請求再發(fā)出）；按照業(yè)務規(guī)則進行的數(shù)據(jù)的轉(zhuǎn)換（例如，某些算法操作、數(shù)據(jù)表的查詢和數(shù)據(jù)格式的轉(zhuǎn)換）還有許多高級金融產(chǎn)品的提供基于規(guī)則的工作流類型的系統(tǒng)功能。這種功能會按照交易內(nèi)容的優(yōu)先級，控制數(shù)據(jù)在虛擬組織中的流動。另外，目錄服務可以跨網(wǎng)絡地進行資源定位、跟蹤設備使用、提供消息修復功能之類的管理工具。目錄服務也是需要的。該層的諸多可能的功能，要根據(jù)銀行的具體情況，有選擇地實施。然而，越來越多的金融產(chǎn)品在系統(tǒng)中的實現(xiàn)，需要共性的、基礎性的服務，從簡單的網(wǎng)絡連接工具到高端的 EAI（企業(yè)應用集成）產(chǎn)品。這些服務，都應該盡量安排在商業(yè)整和層實現(xiàn)，作為各種金融產(chǎn)品、金融渠道的共享服務。 產(chǎn)品引擎層產(chǎn)品引擎提供金融服務的核心能力，并保存細節(jié)的帳戶記錄。該層所提供的，是傳統(tǒng)的后臺服務，越來越多的業(yè)務規(guī)則的處理前移到整個體系結構的客戶交互層中。中間件和其他系統(tǒng)軟件的使用，將原先的大塊邏輯處理，分解為原子級交易，并保持和最終交易系統(tǒng)及企業(yè)工作流的接口。產(chǎn)品引擎要支持金融產(chǎn)品在整個生命周期內(nèi)所要提供的服務。和交易相關的每個產(chǎn)品的信息都記錄在產(chǎn)品引擎中。同時交易路徑的支持、專家性的支持也可以由產(chǎn)品引擎在客戶需要的領域內(nèi)提供，如：欠款催繳、捐款處理、抵押等。產(chǎn)品引擎以以下的幾種方式存在：29 / 64? 核心銀行產(chǎn)品——提供包括現(xiàn)金帳戶、存款、借貸在內(nèi)的業(yè)務。在理想狀況下，借記卡、支票業(yè)務等金融產(chǎn)品的處理，和前面的業(yè)務是一體的，靠參數(shù)化配置就能實現(xiàn)新業(yè)務? 信用卡? 抵押業(yè)務? 其他金融產(chǎn)品，包括保險產(chǎn)品、租賃和中介業(yè)務。? 和一些非金融機構的系統(tǒng)進行集成，例如，和電子商務網(wǎng)站在支付上的集成。所有的業(yè)務的處理都是基于帳戶交易的。銀行的品牌可以體現(xiàn)在客戶服務點上。該層需要和整個系統(tǒng)結構中的其他層緊密結合，才能實現(xiàn)端到端的自動化的交易流程的實現(xiàn)，并且能做到低成本、低風險、少人工干預。 合作伙伴管理層合作伙伴管理層應該管理銀行和所有業(yè)務伙伴的關系，主要包括：? 行政管理——維護每個合作伙伴的基本信息，為每日的關系管理提供支持。例如，合作伙伴中的哪位用戶被授權可以改變產(chǎn)品信息。? 財務管理——維護和處理合作伙伴的帳單和財務回報。本功能的特點是完全依賴于和合作伙伴的關系的定義。例如從帳戶和交易的處理費用，到互聯(lián)網(wǎng)上的廣告費用，他們的處理過程，根據(jù)合作伙伴的關系的不同，可能完全不同。? 關系管理——是管理基于服務水平協(xié)議的合作伙伴關系和它們的對應責任的商務過程。這包括為每個業(yè)務合作伙伴定義產(chǎn)品和服務的能力和管理這些“進出”的能力。? 品牌信息管理——管理和每一個品牌相關的信息。需求的程度取決于業(yè)務合作伙伴在需求上和銀行一致性。? 業(yè)務風險——該功能的特點是：提供接近實時的、關鍵性的操作信息，以便于風險管理。這里的一個關鍵問題是業(yè)務合作伙伴的商業(yè)操作所帶來的風險的管理。另外，如果是業(yè)務合作伙伴提供服務給銀行，和上述管理相反向的管理也要進行。如果超過一個合作伙伴提供了某種服務，那么就應該建立智能產(chǎn)品選擇功能，以告訴產(chǎn)品引擎哪個服務在何種條件下應該被推薦。31 / 64 銀行內(nèi)部管理系統(tǒng)層銀行內(nèi)部管理系統(tǒng)是用來管理銀行內(nèi)部業(yè)務操作的。它們由內(nèi)部的支持性應用系統(tǒng)組成，在大多數(shù)情況下，銀行會應用這些系統(tǒng)。它們包括：? 行政管理系統(tǒng)—包括運營管理報告（如任務清單、異常情況）和所有的法定管理報告（如人民銀行、外匯管理局要求的報告）? 財務管理系統(tǒng)——包括總帳、資金、支持性的帳務、固定資產(chǎn)、供應商管理傭金管理。? 人力資源管理系統(tǒng)——通常為人事和工資管理系統(tǒng)。該系統(tǒng)提供其他所有系統(tǒng)關于角色、責任和授權的信息。? 業(yè)務績效管理信息系統(tǒng)——提供包括和渠道、客戶、產(chǎn)品盈利性、銷售和服務業(yè)績的報告? 業(yè)務風險管理系統(tǒng)——該系統(tǒng)的特點是：提供近乎實時的、關鍵性的操作信息，以便于風險管理。該系統(tǒng)關注的是銀行的風險頭寸，而非合作伙伴的風險頭寸。? 交易核對機制保證所有的產(chǎn)品帳務和支付數(shù)據(jù)無誤。? 傭金管理系統(tǒng)——用于監(jiān)控期望的和實際的由合作伙伴或第三方提供服務所引起的傭金收入（反方向也要考慮作為銷售成本的傭金付出）。? 員工自服務——許多系統(tǒng)的輸出都建立在員工自服務的概念上，特別是費用、人力資源、工資、日常購買等。 支付網(wǎng)關層支付網(wǎng)關——是產(chǎn)生支付動作的系統(tǒng)，例如：? SWIFT? 卡支付—— 國內(nèi)的信用卡通過 VISA 網(wǎng)絡的交易界面產(chǎn)生國際交易。重要的是，支付功能從銀行內(nèi)部的體系結構中分離出來，由外部的