IBM新一代银行核心业务系统.docx

《IBM新一代银行核心业务系统.docx》由会员分享，可在线阅读，更多相关《IBM新一代银行核心业务系统.docx（20页珍藏版）》请在三一办公上搜索。

1、新一代银行核心业务系统何京汉 ( IBM金融事业部 银行资深方案经理 )背景本文介绍新一代核心银行所处的金融环境；结合目前国内银行所处的金融环境和银行客户的需求的新趋势，按照模型化银行（Modeling bank）的思想，介绍国内银行在设计新一代银行核心系统是要考虑的主要问题。突出新一代核心银行要解决的模型化银行的问题，国内系统与新一代系统在观念上的差距，银行转型与信息规划设计的关系。国内从业人员普遍关心的金融产品概念（模型要点），核心银行的企业级客户文件（Enterprise CIF）的原理。国内外核心银行系统发展所处的环境 国外银行更换核心系统的努力国外核心应用系统大多是70年代建成的，经

2、过多年的运行后现状是：维护成本高，系统架构封闭，不易于加入新的功能且容易引起宕机。80年代至90年代国外银行，曾经试图更换这些系统，但大多归于失败，如花旗银行10亿美金的工程最终没有取得成功。 虽然，更换新的核心银行系统，难度极大，但银行还在思考，为什么还要将大量新的应用放在不灵活的且过时的系统上面？所以更换新的核心系统的努力还在继续，只是吸取了80年代90年代的教训：银行必须采取新的策略去更新核心应用系统，以保证成功！ 这些策略和市场趋势概括起来有： 用核心银行提供商的解决方案替换自我开发的核心银行系统。100强的银行70%的银行将去寻找 核心银行提供商的解决方案（Vendor built

3、solutions），即购买软件包。 主机方案的规模性得到验证。主机的核心银行方案，将继续流行。是因为它的规模性得到证实。尽管主机的技术没有新技术灵活，它的维护成本需要进一步下降。 浏览器方式的解决方案（browser-based solutions）。市场上将会有更多的以浏览器方式出现的核心银行解决方案。 目前国外大多数银行并没有将核心银行更换置于业务发展的最高级别，因为它的风险性。但个别将老系统迁移到新一代核心银行系统的成功经验，和更换后带来的好处，刺激了其它银行更换系统的决心。他们认识到了好处大于风险： 极高的效率 信息容易访问 加入新的应用不会引起系统宕机的能力设计原理国内外银行目前所

4、处的金融环境，对核心银行系统的影响 银行经营环境，客户，产品、服务体系发生较大变化 银行业的经营绩效取决于三个主要的价值策略市场 对上市的银行或即将上市的银行，股东（即使是国有控股）的价值决定了银行改革的方向。为适应WTO形势，以下三种趋势决定了新一代核心银行业务系统必须支持银行选择不同的业务战略方向。银行发展3大趋势 国有银行改革已经纳入国家改革战略，银行上市意味着商业银行面临金融监管体系的变化（将面临不同国家的不同金融监管），股东价值体现开始变化。国有银行对国家经济的地位，会逐步将证券市场与银行资本的互动市场化。 过去几年银行经营的前景已经改变，还将继续改变 目前银行利差是30年来最低的，

5、这迫使银行发展非利差性业务，提供多种服务，对客户提供收费业务等，将是银行经营改变的主要方向。 客户已经从以前的单纯储蓄，变为了具有金融意识的、渠道中性没有忠诚度的客户，要求银行提供一站式理财服务。事实上，具有实力的客户已经在利用银行的建设资金与房屋贷款进行了新一轮的投资。但银行不能说了解这些客户，而是随波逐流。这里的银行风险基本由国家承担。 而新的竞争者又在作什么业务？以上海为基地的外资银行，江浙一带的民营银行可能是改变中的银行经营前景的收益者。过去几年银行经营的前景已经改变，还将继续改变银行新的竞争形势 银行要了解客户，识别客户收入与客户分布银行非利息收入在银行的收入比例逐步扩大，有些银行4

6、0%的收入要来源于非利差收入。 这决定了银行提供金融服务和金融产品的重要性。 了解客户对不同客户的需求，提供不同的金融产品 65%的收入是30%的优质客户提供。银行需要这样的客户。为保留他们要提供不同的金融产品。在国有大银行，几千家优质客户提供绝大多数收入来源，在目前金融环境下，也不足为奇。快速地开发先进的金融产品成为了竞争的要器。 15%的收入由80%的客户提供。这反映银行并没有开发出满足这部分客户需求的金融产品。仔细分析，这可为银行改革提供了方向。同样，核心银行系统要提供适合这类客户群?quot;金融产品。可参阅介绍产品工厂的概念。 20%的客户使银行收入负增长。这需要银行进行引导，减少这

7、部分客户使用昂贵产品和服务的机会，以降低成本。这种方便银行业务人员操作，又不至于影响银行形象的解决方案，同样需要核心银行系统定制金融产品和服务。 各种了解客户，识别客户的功能是新一代核心系统的核心。这需要核心系统内的企业级客户信息系统（Enterprise CIF）的支持。银行普遍采用新的金融模式：提高效率，差异化经营，提高经营的弹性这三个关键需求决定了金融机构的解决方案的基本需求国有银行、股份制和城市商行控制国内经济的主体，优势是明显的。但提高效率，增加弹性尤其是风险防范意识，进行差异化经营，是未来与外资银行、灵活的民营银行进行市场竞争取胜的不变的真理。 风险监管和控制，跨渠道集成，客户关怀

8、，分行再造，前后台流程再造是国内银行目前可以开始起步的工作。核心银行系统受银行经营环境变化的影响银行的经营环境在发生变化，对目前正在进行的新一代核心银行系统提出了要求 能够支持银行选择的业务创新方向 金融产品建制的能力 以客户为中心，完整的客户关系视图 先进数据结构和业务流程处理架构 高效报表管理 实时数据更新, 24x7, 较少批量处理 基于可重用的组件 多行、多货币和多语言 所有渠道一致的服务 清楚地接口定义 可增长，规模性 低操作成本，低维护成本 核心系统，业务驱动？还是IT驱动？这里没有唯一的答案，但是，必须第一步要定义业务策略和远景；策略描述业务蓝图或银行业务结构；蓝图必须设计为支持

9、业务结构；应用架构必须与数据架构紧密结合；长期的集成需要开发式的平台 新一代核心系统是否能以业务策略驱动，在国内尚是未知数。上一代的银行核心系统是由IT部门为主，技术架构驱动的。欧美大银行90年代新一代的核心系统集成，基本是由业务因素驱动，由业务部门主导。这种差异是否会导致核心系统本质区别尚待观察，但差异是明显的。 业务策略：以客户为中心的组织服务体系，金融产品制造，风险管理，业务流程再造，混业经营，资本证券化，利率市场化迟早要发生的。这是银行战略决策部门要考虑的因素。 如上图所示银行经营的6个能力1。产品制造，2。内部处理，3。洞察力，4。服务提供，5。基础设施，6。风险和金融计划。是银行管

10、理层要考虑的业务策略。 应用结构，数据结构是核心系统的功夫所在。考虑未来的业务发展趋势，在新一代核心系统或核心应用模型中打下坚实的基础。是这一代系统区别于上一代系统的本质。这是银行IT部门要计划实施的。 业务架构：是业务部门（Line Of Business）关心和决策的（图所示）。但就国内银行的现状来看，这是一块软肋。在进行核心系统建设时引进银行业务咨询公司不失为一项明智的举措。 模型化银行主要思想和功能模块及IBM的方法论 银行核心发展系统发展的4个阶段主要功能银行核心业务功能 银行的核心业务功能可以用上图表达。银行界经过几代核心系统的开发，发现可以用简单的概念模型化数据，流程和业务功能。

11、 IBM公司经过10多年的努力，提出并成功实践的IFW提出了9个最基本概念。 Involved Parties（参与者） 与业务有关的人和组织 Locations（地点） 地方、地址、地区 Product/Services（产品） 能带来收益的金融产品和服务 Conditions（条件） 因金融产品、合约等不同的变化的因素 Arrangements（合约） 参与者之间达成的 合约、合同、协议等 Resource Items （资源项） 银行提供的金融设施，存折、卡、抵押品ATM等 Events（事件） 事情的发生，银行业务活动，银行交易等 Business Directions（业务方向） 决

12、定银行业务变化的规定：目的，规则、政策 Classification（分类） 分类,以上8类都没有的概念，如市场区隔、风险等 在九个概念中，参与者(Involved Parties)包含了核心银行中经常使用的概念，客户，机构，银行职员职位，第三方机构；事件（Event）包含了，交易，促销活动等概念。合约（Arrangements），提供了记账（Accounting）、与客户合约（如贷款合约，外汇买卖，贸易结算合约）；条件（Conditions）包含利率/费率/期限等；产品（Product）,金融产品是国内系统中缺少的概念，下节将专门讲述。 读者是否发现，任何一句在银行发生的金融活动，都可以用以

13、上9个概念描述呢？如 我（Involved Party ）现在（Condition）开(Work flow)一个存折（Resource Item）; 他（Involved Party）在昨天(Condition)在储蓄所(Locations)的ATM(Resource Items)上取了(Work flow)100元(Conditions);这里还隐含着使用借记卡（Product，金融产品 其中，提到的Work Flow就是IFW提到的CBP模型，取钱就是工作流里的动词。不难发现既然银行活动能用自然语言表达，那么用计算机模型语言表达也是可以实现的，这不就是人类发明计算机语言的初衷吗？这就是，金

14、融界普遍进行模型化的去实现核心银行系统追求的目标。 简而言之，将业务需求，业务范围用数据模型（计算机语言中的名词）、工作流程模型（计算机语言中的动词）和功能模型（规则参数）表达出来，就能整体把握核心银行业务的整体，建造出核心银行的部件；再选择较好地核心银行架构，建造出核心银行业务应用。这就是90年代开始的模型化银行热潮，西方的大银行一般都有独立于核心银行系统之外的银行核心业务模型，这样可以保证，即使核心银行系统结构落后，但银行业务应用保持相当的先进性。从这个理念出发，也产生了多种银行经营IT部门的模式，如美国的几大银行，只在改进银行核心业务模型上完全由银行内部人员完成，核心银行系统的构造完全交

15、给IT公司完成，节省成本提高效率！保证银行业务的先进性才是银行的核心竞争力，保持核心银行系统软件包的先进不是银行的核心竞争力。 银行业务功能上图所示，站在银行经营的角度要求，核心银行支持银行经营的6个能力：1。产品制造，2。内部处理，3。洞察力，4。服务提供，5。基础设施，6。风险和金融计划核心银行系统架构将银行的业务功能，转换到新一代核心银行系统架构是现代核心银行应用系统建造的过程。 结合上文的分析，银行经营环境变化，对核心银行系统的建设提出的要求。西方银行是如何运用模型化银行的思想进行新一代系统开发的呢？以下几节将举例介绍，核心银行模型。这里概括核心银行应用模型的主要方面： 它是在IFW

16、9个概念基础上，建造的数据模型，工作流程模型和功能模型。 核心模型 Party and Party role 模型机构/法律实体 模型客户模型金融产品模型金融记账（Financial Record Keeping）/金融资产(Financial)模型分类（Classification）/通讯（Communication） 模型地点（Location）模型事件（交易）计划和日程安排 市场和销售模型 金融产品提供模型 风险管理功能模型 财会管理功能模型 客户服务功能模型 银行监管功能模型 细心的读者可以发现，银行业务功能图5所提倡的银行6种能力1。产品制造，2。内部处理，3。洞察力，4。服务提供，

17、5。基础设施，6。风险和金融计划。在以上核心银行应用模型都有所涉及。这说明，无论从哪种角度构造银行应用系统，其出发点都是要求核心银行系统能站在银行的经营理念上，来满足2.2提到的核心银行功能。 银行的应用模型 银行应用模型 的建立和维护绝非一时之举，在欧美一般在大型银行设有专门的应用模型组织，而且与业务部门（Line Of Business）处于同一老板（CIO）管理之下才可长期坚持。一般认为银行应用模型是银行核心竞争力，而不是核心应用系统本身（可能外包或购买产品包，在银行应用模型指导下加以集成）。 限于篇幅，以下只对上面提到核心银行应用模型中的核心模型之数据模型，国内银行普遍感兴趣的部分，作

18、简短的分析。且没有用E_R关系模型表述。 金融产品金融产品的概念在西方已普遍使用多年，在银行的柜台摆放得业务简介大多以金融产品和服务为主，银行业早已经转向市场销售为主。在国内银行的发展是从储蓄业务/银行会计发展到今天，国家控股是普遍的现象。金融产品这个市场化银行的产物，在国内如何使用，目前还是引入阶段。笔者暂且下一个定义，金融产品是客户眼里市场化的，银行可销售的金融工具。对金融产品的理解从不同角度，有完全不同的划分：从不同银行交易渠道（Product delivery channel）；从信用风险控制(Credit Risk)；从资金控制(Financial control )；从信息管理角度

19、（MIS）.这恰恰涉及金融产品的多个维度。 设计金融产品时要考虑的业务原则（Business Rule）， 它与Deal(Arrangement,与客户买卖有关)，以客户购买决定因素为出发 金融产品有许多特性（Product Features）,如利率，费率，资源项 可买卖的因素(Interest, Fee)+衡量收益因素（Revenue, Expense） 金融产品分为简单产品Simple Product, 复合产品Compound Product 金融产品具有级别Product Class，可让金融产品在不同业务部门操作以下以图例的方式，介绍一种复合金融产品：代收水费。之所以是复合产品，是

20、由于它涉及不同的访问方式（如渠道）、资源项（Resource Item）不同的付款机制（Payment/settlement）。不同的账户（水公司对公账户，客户对私账户） 相反，若只涉及单一货币，单一访问方式，单一付款方式，单一账户（如只能是定期），不能透支等的产品就称为简单产品。 以下图例， A:为银行业务部门如何看待金融产品的；用于业务部门与IT部门谈定制金融产品的需求。Line: 业务部门（个人银行、公司业务部）；Group(储蓄业务) B:为IT部门如何将A金融产品的业务概念分解为应用的数据模型 C:为应用程序（Object Model）如何使用B的产品、账号等数据模型 假设：上图的

21、Transaction = ID：1000 ,借记客户账户的交易； Product = ID为DEBT，代收水电借记客户帐产品码 Account = 客户账号，8790 1000 1200 1003 若发生了一笔代缴或电费之扣客户帐的交易1000 找到Accounting Unit里，对应的扣客户帐程序：Debt0001 (1) Debt0001按照业务逻辑找到数据模型Account，Product (2) (3) Product根据需要找到对应的利率和收费 (5) (6)Line: 业务部门（个人银行、公司业务部）；Group(储蓄业务) 金融头寸（Financial Position）,金

22、融纪录（Financial Record）,金融交易（Financial Transaction）相互配合。将账户信息记录入Accounting Unit 。(7)(8)(9) 图中Event中的Transaction一般称为Execution Transaction,为前台人员设计的交易；而经过Deal(Arrangement)后的交易称为Financial Transaction 或Product delivery Transaction（例如外汇买卖交易，开信用证交易） 产品工厂概念：金融产品的制造是为了销售，销售是为了金融市场，市场的主体是客户，为防范风险在内部处理中和金融计划中要充分

23、考虑风险和盈利。这就是产品工厂的概念，它与前面提到的银行要具备6种能力是一致的。 如产品工厂概念图所示，金融产品开发流程 产品制造后，金融产品发布 广告 市场推出 产品销售：客户自我服务 产品前台销售 客户自我服务从该图不难看出，要实行产品销售，银行要具备产品发展部门，它要作为银行建立金融产品的市场营销体系的核心。产品发展部门负责：从产品市场定位，市场盈利分析，产品考核管理等工作。这样核心业务应用，MIS，电子渠道系统，才能够在统一的产品体系下工作。 交易，金融产品，合约（客户交易），会计帐（账户）间的关系图产品工厂概念图企业级的客户信息管理 IFW 的Involved Party 中包含了C

24、ustomer(客户这个概念)。Party 是典型的美国银行术语，它是为了抽象参与银行运作的实体，客户、机构、银行雇员（Employee, Banker）,第三方（代理行，政府，央行，监管者）都在Involved Party中。两个重要的概念，Party(客户，机构) 和 Party In a Role(或叫Party Role，信贷员，会计主管，交易员，CFO)。 客户概念，描述分为Party(客户标识)信息，RolePlayer(客户角色，与银行服务有关的角色)，Context(客户与银行信息)，Content(客户本身)。 如，张三（Party）男，30岁(Content)在银行贷款(贷

25、款户RolePlayer1，有贷款账户（Context）。如，张三（Party）男，30岁(Content)在银行存款(存款户RolePlayer2)，有定期账户（Context）。 由图中可以看出，这种客户信息模型是如何实现与不同的应用系统相联接的，我们称之为CIF由于它是核心应用系统的一部分，也称为运营型的客户信息系统（CIS） CRM有客户管理系统（Operation CRM客户服务营销系统）和客户分析系统（Analytic CRM 数据仓库）。将 Operation CRM + CIS + Analytic CRM 所拥有的信息结合起来，我们称之为ECIF(Enterprise CIF

26、，企业级的客户信息系统)。 企业级客户信息系统的建立作用是全方位。客户服务的作用了解客户，识别客户，服务客户，在银行业务层面是为了： 评估总的盈利率创建和管理单一视角，为银行多产品建立销售管道（Pipeline）评估风险敞口跨区域信贷价值值得注意的是企业客户的类型，它会影响到客户的分级Customer Class，以及银行处理部门和流程有相应的调整。 如全资企业，部分控股，主要控股；总公司，地区分公司，跨国分公司客户与银行的关系，如买卖产品性质，记账性质，债务人，涉及到银行产品等级Product Class ，银行对不同的产品、客户状态，处理部门不同，产品不同，风险防范也不同。 以上已经勾画出

27、了CIS数据模型最本质的地方。总之，ECIF是核心银行应用中最复杂的部分之一，它涉及银行的各个方面，它核心系统的核心。实施难度较大，银行一般采取购买和咨询服务的方式实施ECIF。单纯从某项业务（如储蓄）某个方面（如渠道系统）考虑是较难取得效果的。银行机构与业务功能这是国内银行较为熟悉的概念，这里主要强调为何机构在国内系统中没有很强的功能，主要是没有Party role的概念和成本核算的考虑。如没有划分：省行（Party）信贷部(Party Role)。不能有效处理业务职能（某省行信贷部）和行政区隔（总行，某省行）。若要作到这一点，要将业务职能专门建立模型，一般称之为银?quot;法律实体模型（

28、参见4节银行核心应用模型）。 以下各点是国内银行设计机构时没有涉及到的： 1。雇员是存在于机构里，雇员的角色（Banker：信贷员，主管，会计师，CFO）也是模型的重要组成部分。 2成本中心与机构、人是密切相关的； 3。团队（Team）在机构中是一个重要的概念，它是矩阵管理，任务管理基本单位。银行帐务处理帐务处理是国内银行系统中最强大的部分，但与国际化的总帐会计系统比较，少了客户（帐）与产品（帐）的概念，金融纪录（非头寸）和金融头寸的区别。显得国内的会计系统只是国际化产品包的一部分。区别是较大的，这与国内金融监管体系尚处发展之中有密切关系。 银行的市场功能/管理功能/服务功能随着银行发展的趋势

29、，核心银行除了客户信息管理，产品生产，交易处理，帐务处理，机构管理等核心能力外，其外延逐步扩大。其市场功能，管理功能，服务功能成为区别银行区别于另外一家银行的重要标志。 在介绍 银行核心应用模型时已经提到，需要建立市场功能，风险管理功能，财会管理功能，银行监管功能，客户服务功能，产品管理功能等模型。限于篇幅只介绍了后两种，不可能一一介绍。这是国外核心银行应用相对强大和成体系之处，值得国内同行借鉴 总结国内系统与国际新一代核心产品 国外新一代核心系统花费6年以上的时间才成型，国内银行基于目前的环境走自我研发的老路是不可取的。在国内环境如何能达到更换新一代核心系统，使银行核心应用能逐步赶超国际先进

30、水平呢？ 首先，银行应该决定核心应用系统是以客户服务为核心的系统。这是银行今后生存的法宝。这是我们建议的国内银行（大部分业务是面向零售负债业务的）业务转型方向。它决定了核心银行的选型。 其次，银行应该在应用模型上下功夫。核心银行软件包，不是银行的核心价值，应该交给专业的公司发展。这里可选择购买产品包加以改造，外包开发维护等业务，小的银行可以租赁。IBM On Demand 灵活的资金处理方式讲述了同样的道理。核心应用软件包会老化，但银行的应用模型可以不断发展。不应再重复上一代系统的错误：应用模型与核心系统一同老化，或随人而改变。将有限的资金投入在模型化银行的工作中，将是一条出路，这一点被欧美大

31、银行证明过。 第三，面向业务的核心银行发展管理体制。银行数据中心是IT部门的专长，而应用开发这是银行业务部门更有发言权。IT部门只保留维护人员，应用设计人员隶属业务部门是西方银行的模式。IBM On Demand 方法论 附件-IFW模型化银行的思想 将银行业务在功能上进行模型化（Function Model）国内银行从事核心应用的专家大多相熟银行机构对核心应用的作用，Function model最终物理实现的就是银行机构。但从几十年的实践证明，银行的物理机构设置与银行的业务功能不是一一对应的，而银行的业务部门的逻辑功能是随银行的业务性质决定的，是基本不变的。另外各业务性质相同的银行的业务功能

32、本质是一样的，但机构是经常调整变化的。 故进行银行模型化的专家，将银行业务功能抽象出来模型化。如图5零售银行核心业务模型所示，零售银行业务功能，在全球银行的实践中已经形成了业界的标准。IFW就是将它们进行模型化。 银行业务功能最后落实到我们熟知的银行机构的概念（见4.3节），使银行业务功能不随银行机构的变更而变化，从而保持核心银行系统结构的稳定。 数据模型FSDM如银行卡，发卡的品种是不一样的（可能是借记卡，贷记卡，生肖卡），用来表达银行卡内容的术语却是一样的，如卡名，有效期，金额，客户名称，发卡机构。不一样的是卡片种类，用途，费用，可使用额度的性质等。这些可以用名词表达的部分是，就是数据模型

33、，在IFW中称为FSDM(Financial Service Data Model)。国内有些银行建立了自己的数据模型，对它较为熟悉，但一般用于数据分析型应用（MIS）。但为整个银行建立数据模型，或用于核心业务开发，是目前面临的挑战性。在全球银行的实践中，一般借助于IFW（提供零售银行最佳实践模型）研发适合于自己的模型。 将银行业务的流程进行模型化是CBP（Critical Business Process）的基本思想银行业务处理中，有许多业务事件（如开户，发卡，促销，记账，申请，审核等），每个业务事件有它的共性和特性。如开户无论是定期，活期都叫开户，即开户这个活动（Activity）一样，但

34、它们内容（数?quot;）不一样。其实银行不同的业务的其某个环节的活动是大致一样的，不同的是办理它们的业务部门（银行职员的角色）不一样，前提条件（Trigger）不一样。将业务事件区别开的活动（Activity） + 前提条件（Trigger） + 角色（Role） 用时序图用箭头关联起来就构成了银行的业务流程图（FSWF Financial Service Work Flow）。 将同一类的FSWF归类，用一个通用（generic）的名称表达的业务流程就称为CBP。如国外汇入汇款FSWF1，同城汇入汇款FSWF2，跨省汇入汇款（FSWF3）等多种汇入汇款业务流程，统称为汇入汇款流程（CBP1

35、）。这样银行?quot;通用业务流程就有规律可循了。一般银行的业务流程（CBP）不过几百个。这种对流程的模型化，帮助了银行业务部门控制风险，优化业务流程或为银行进行业务流程再造提供帮助。同时，对构建核心业务系统提供了支持。 以上介绍了银行的业务功能，业务内容（数据），业务流程，对它们用模型化的语言进行表达，可以转换为核心业务的应用架构、数据结构，技术架构。 IBM的IFW方法论,是使用业务功能模型（Function Model），工作流程(CBP)和数据模型(FSDM)，进行业务分析，以业务部门为主导，用模型化的语言写出业务需求。再用工具生成系统设计（System Design）,这还涉及到I

36、T人员使用的模型（BOM业务目标模型，IDM接口设计模型）这里就不详述了。 附录2一、 我眼中的IBM核心业务系统的成长历程。在银行核心业务系统上，我们和IBM有二次接触。通过这二次接触，我们可以发现IBM在核心业务系统的成长历程。第一次：2000年，我们启动一个研究小组，探讨下一代银行系统的设计。当时惊动了国内外各大厂商，纷纷上门来推销产品。其中包括IBM（当时好像何京汉也在场），IBM调用了海外的八国联军，请来了很多银行业务顾问，给我们灌输了很多国外的业务理念。但是，其实那时候IBM的思路是主推“产品销售”，他们拿出了一套国外的CBS（CorebankSystem）系统，打算卖给我们。备注

37、：其实和IBM打交道，不能太迷信他们所谓的国外理念。你提的任何国内需求，他们都会说：国外理念不这么做，这是落后的！他们的阴谋其实不外呼就是让你全盘使用他们的系统，不要改造。第二次2004年，我行全面启动核心业务系统，这次IBM带来了IFW（IBM信息框架）的概念。这次他们卖的是方法论，而再不是实实在在的系统（越虚的东西越值钱）。我感觉这次IBM在和fidelity的合作中确实发生了质变。上一次他们的很多业务理念其实是各资深银行专家的零散拼凑。而现在IBM吸收了FILSVR的东西，开始比较系统地提出“核心业务系统”的理论框架。备注其实所谓的IBM核心业务系统方案，应该是Fidelity Core

38、banking 解决方案与IBM结盟的产物。Fidelity在国内无实施经验，所以借助IBM给他打市场。 二、 IFW（IBM信息框架）的概念IBM的核心业务系统方案的最大核心其实是IFW.2003年底，IBM带来了几个老头子，说是爱尔兰的核心银行解决方案研究中心的。主推IFW概念。模型解决方案IFW。其核心是数据模型、功能模型、以及流程模型三种。不过，我个人认为IFW在业务模型上有所欠缺。我更加推荐用UML业务建模中，以“业务愿景”、“业务过程”，“业务结构”，“业务行为”四个通用视图来刻画业务。2005年 01月13日 12 : 11 业务分类模型理解之一 阅读IFW，对九大概念细致地理解

39、，终于对其中的事件（EV）和业务策略（BD）有了进一步的认识，这里将Business Direction Item翻译成业务策略可以表示这种理解。原来，我将BD看作是营销策略或营销活动，概念有些模糊，但和事件区别，如果将BD称作是营销活动，那就是一种发生的事件，而且BD并不仅仅是指营销，所有为企业发展所制定的政策，包括营销方案，资费政策都属于BD概念。对于产品（Product, PD）和资源（Resouce Item，RI），认识原先也有些模糊，比如在blog概念就是抽象中，提到的电视是一种产品，而电视机也是一种资源，很让人迷惑。通过对比两者，可以认为产品是一种虚的，指企业提供的可获得的商品和

40、服务，比如电视是商店的一个产品，但是电视的尺寸、颜色（这些都是条件（Condition, CD）都需要在进行顾客购买时确定下来（通过合约（Arrangement，AR），最后销售给顾客的是实实在在的电视机，按照指定的颜色、尺寸，从商店的库房里调出来的东东。这种资源可以看作是产品的实例，当然并非所有资源都是产品实例，例如商场和顾客签订的买卖合同那张纸，也是资源。从这点看，资源似乎是那些看得见摸的着的东西，但也不尽然，资源包括有形和无形的，一个企业的无形资产，例如品牌、商标、专利都可以算作资源。那么人算不算资源？现在一般的企业都有人力资源部，就是把人作为一种资源。但在IFW中似乎企业的雇员是参与方

41、（Involved Party，IP），通过劳动合同这个Arrangement，和企业这个IP建立关系。那为什么雇员不是资源呢？IFW的标准是，那些被动的、不能作出独立判断的价值物品。happyscry 2005年 01月17日 12 : 03 业务分类模型理解之二 目前让我感到困惑的是IFW的Classification概念，按自己的理解，它是一种比其他八种更加抽象的概念，似乎有些类似于元数据相对数据的地位。即使结合例子，也是不太明确它究竟是什么，IFW提出对每种概念可以有不同的角度去看，也就可以形成不同的分类体系，每个概念称作分类值，任何概念都可以通过不同scheme，或称分类角度，细分成

42、子概念，这些scheme似乎就是Classification啊？在一个业务领域中，从这9个概念逐步具体化，将会有成百上千的分类值和分类角度。而Classification作为单独的一个概念，也同样有子概念，那不得有成百上千个吗？在例子中，提到帐户Account，电话用户的帐户、visa卡用户的帐户都是Classification，这更让我迷惑。总想CL是一个抽象的非实体的概念，但帐户却明明是个实体。其他几个可以看作CL的是语言，度量单位，这理解起来似乎是将CL描述为其他八个概念的属性，确实属性可以用来为一个概念进行分类，例如按性别区分客户，按通话时长区分通话事件等。但是地理位置是不是实体的属性

43、呢？例如客户的住址，帐单邮寄地址等，但这在IFW中却有单独的Location概念。同样，条件，Condition也可以作为属性来进行分类，这些概念和CL有什么区别呢？ happyscry | 已被浏览34次 3 评论 | 引用(8) | 加入博采中心 Classification的含义 回复 安以为Classification可以理解成代表代码表、维表、字典表之类实体的概念ding | 2005年 01月20日 10 : 26 回复 你们现在的项目是不是用的这样的抽象的逻辑模型?SummerRain | 2005年 01月18日 00 : 05 个人主页: 不是 回复 这个模型在这个项目中没有

44、用到，最终的ODS模型几乎还是按照源系统的数据模型设计的。而且这还不是逻辑模型，是概念模型。happy | 2005年 01月18日 09 : 24 2005年 01月19日 12 : 04 业务分类模型理解之三 提出九大概念，不是说它一个业务系统就是从这九大中具体化而来的。古今中外的哲学家都喜欢追求物质的本源，阴阳说、五行说、原子说，都是如此，其实这些理论也都试图提出一种可以描述世界万物的基本概念，万物都从这些概念衍生而出，不论是两个概念、五个还是一个。计算机系统据说是受了阴阳论的影响，通过0和1组成了目前具有如此丰富功能的软件，而未来0和1是否能够进化成更智能的，甚至是matrix那种虚拟

45、世界，也是不可预知的。这些古老的哲学理论教人们如何看世界，而对于构建一个业务系统，似乎比世界要具体化的多，如果将什么原子论作为业务分类模型的基础，就像用0和1来编写一个应用程序一样费劲。因此，这九大概念并不是最抽象的，却试图作为业务系统最抽象的，不一定非得是九个，比如NCR的模型就提出8个概念，这就是仁者见仁，智者见智。当然，我们可以用实体、关系这两个概念来抽象整个业务系统，或者为业务系统建立一个Object基类作为最抽象的概念，只是确定这两个或一个基本概念之后，离完整的系统还远的很。 2005年 01月20日 13 : 15 业务分类模型理解之四 对于IFW九大概念，还是无法理解深入。为什么

46、将Location孤独出一支来？类似于客户新增，属于Involved Party还是Event？每种概念都可以分成三个方面，基本面、关系面和描述面，这如何理解？这和Scheme有什么区别？依据这九大概念似乎方便于理解业务，但是对于最后形成的逻辑、物理模型，他们似乎很难匹配，例如原来联通业务模型中的三户关系，客户、帐户和用户，这似乎形成一种比较整体的概念，但在IFW中，客户属于IP概念，而用户属于AR概念，而帐户按照例子中所说，属于CL，这更让人难以理解。而计费详单、月帐单、缴费、营业受理、营业收费似乎都是Event，是这样吗？而平时经常提到的代码表或字典表，是不是属于CL范畴呢？搜索IFW和Modelware，在IBM Systems Journal, VOL35, NO 1, 1996的一篇文章中，找到IFW的来由。1987年，John Zachman发表了一篇论文，A Framework for Information Systems Architecture，介绍了一个信息系统框架模型，IBM的银行解决方案中心（Banking Solution Centre）在Zachman提出的框架基础上建立了IFW，虽然开始应用于金融领域，但是他们在设计这个框架时并没有叫做金融信息系统框架，就是想将它作为可以适用于多个垂直行业的框架模型。在后来的IBM电信