中国银行IT蓝图

bystanderboc

目前中行的IT蓝图项目已经推广了20多家行，今年将推广到所有分行，中行以及各位支持中行的朋友都准备弹冠相庆IT蓝图项目成功，对此，我却认为即使到了年底，IT蓝图项目不一定真正完成了。对于这个结论，估计大部分一直关注蓝图项目的人都不会同意。
可是大家都知道，IT蓝图的背景是，2004年中行请波士顿咨询公司（BCG）制订了IT蓝图，其目标是促进业务发展，防范金融风险。为了实现IT蓝图设定的目标，中行引进了Bancs系统，全行全力以赴推广Bancs系统，到今年年底系统将推广到所有分行。可Bancs系统不等于IT蓝图，所以Bancs系统 推广完成并不意味着IT蓝图项目在中国银行成功完成了。
那么怎样才算成功呢？中行的IT蓝图项目实施应该分为两大目标，首要目标是Bancs实现了IT蓝图所设定的目标，终极目标是IT蓝图项目实施促进了业务发展，降低了金融风险。评估标准设定后，应该由谁来评估呢？在此，我想先假设一下，如果蓝图项目已经实现了既定目标，谁来评估问题都不大。如果目标没有完全实现，谁来评估就很有讲究了。按理说，业务部门是最终使用者，由业务部门主导评估是顺理成章的，但从Bancs系统的引进来看，该项目肯定是业务部门来主导实施的，因为关键核心业务系统由外部来引进，对于IT部门来讲，潜台词相当于承认自己拿不下来这样的项目，这样几乎相当于端掉自己的饭碗，IT部门在行内的作用和地位也会大大降低，所以不到万不得已，IT部门绝对不会出此下策。既然是业务部门主导引进的系统，现在由业务部门来说原定目标没有实现，岂不是相当于自己打自己耳光，最大的可能是打落牙往肚子里咽。假设由IT部门来主导评估本来也顺理成章，技术上IT部门肯定是权威，系统设计实现怎么样，与行业IT水平相比是否先进，IT部门肯定是最清楚的，但是由IT部门说出目标没有完全实现，IT部门可能被认为有拆台之嫌，其他人不一定心服口服。总之蓝图项目已经与各方有太多的千丝万缕的联系，再说带来坏消息的人永远都是不受欢迎的人，谁来评估都不合适。看来唯一的办法是再请外部咨询公司，由他们来收集业务部门和IT部门的意见，通过他们来说出自己想说的话，虽然这是最稳妥的办法，但中行为此又要花一大笔钱，实在有点冤枉，可除此以外还有何良策呢？对于先设定假设条件，估计有人会说我因果倒置，其实，即使没有请权威部门进行评估，推广了这么多行，蓝图项目参与人员应该能知道目标实现得怎么样，所以谁来评估才是关键。
如此说来，大家是不是觉得我说得有些道理。

[ 本帖最后由 bystanderboc 于 2011-2-28 07:43 编辑 ]

boctigerdragon

楼上的仁兄确实提醒得对，我发现我们做事确实经常会走入这样的误区，为了业务发展，提出一个目标;为了实现该目标，需要开发或引进一套新的系统；为了推广新的系统，有的时候提出暂时牺牲业务的发展。当该系统推广完成后，大家就认为大功告成了，可最初的真实目标大家往往已经忘记了。新系统的推出到底是促进了业务的发展，还是没有促进业务的发展，甚至阻碍了业务的发展就没有人去关心了。这样的故事几乎天天都在发生，我们还很难跳出这样的怪圈。
当初推广新一代会计系统提出以客户为中心，将客户信息从账务信息中分离出来，即客户信息文件（CIF）和账户信息文件（AIF），整个系统使用唯一的客户号，为此还专门推出了一个企业数据模型系统。新一代会计系统推广完成以后，没有人告诉我们该目标是否实现。
今天推IT蓝图，“最大的变化就是以账户为中心的业务流程模型转变为以客户为中心。…过去以账户为中心的流程中，客户信息管理都分散在各个产品中，会计系统中还有相当一部分客户信息依靠人工文字管理系统，造成大量重复信息。新系统将建立一个全行共享的客户管理系统，集中管理客户信息，重新确定的十位数的客户号则保证每一个客户在中行的账户号都是唯一的。”(详见《再造流程 中国银行IT蓝图改造三级跳起步》)。新一代会计系统已经实现的功能变成了IT蓝图最大的变化。
看来我们是得需要反思反思。

路况较好

中国银行总行决定：授予河北省分行石奇华红绫顶戴，黄马褂。。。。

中国银行去年告诉俺要小心黄金回调风险，真tmd傻

boooker

在一片不看好的的目光中，居然上收全国大半分行核心业务了。接下来也应当是问题不大。

hjdbl

原帖由 boooker 于 2011-3-14 22:45 发表
在一片不看好的的目光中，居然上收全国大半分行核心业务了。接下来也应当是问题不大。

项目没有不成功的，上线没有不顺利的，呵呵

rainwghua

今天浙江、福建、宁波开始上线了！

LOVEBOC

闽浙甬投产成功，加班还得继续。。。。

[ 本帖最后由 LOVEBOC 于 2011-4-9 15:10 编辑 ]

路况较好

......................................

isjava

bystanderboc是个老实人，如你自己所说，确实“实在是水平低”:-)

原帖由 bystanderboc 于 2011-2-12 19:19 发表
前一阵在论坛看到《BANCS系统“十日谈”》，感觉对BANCS的赞誉有点过。首先声明，我对BANCS系统没有偏见，对以前的系统譬如NACS也没有任何特殊的偏好，只是觉得应该有一说一，咱不能好就好上天，坏就踏上一只脚。下面将针对“十日谈”的观点谈一谈。
    “十日谈”：首先——天赋异秉！BANCS系统彻底颠覆了我行以往业务系统的观念，引进了全新的核心银行系统理念，是一个完全以客户为中心的生产系统。
    新一代会计系统NACS也是以客户为中心的核心系统，当时提出的企业数据模型使用唯一客户号，就是为了建立以客户为中心的生产系统，从这一点来讲BANCS系统的“天赋异秉”无从谈起。
    “十日谈”：其次——满腹经纶！覆盖了旧线的NACS、RTS、NISS、NICS等等系统的功能，减少了一笔业务要跨多个系统处理的历史。   
    覆盖了这么多系统的功能？“十日谈”自己不是说，“当然BANCS大侠也不是事事亲力亲为。比如他更关注交易的处理”。其实BANCS也仅仅是登记了交易，没有生成银行最基本的借贷账，哪来的“满腹经纶”。
    “十日谈”：再次——武艺高强！500多天来，系统运行稳定，期间只短时宕机一次。（要知道，以往新系统投产，水土不服，宕机状况屡有发生，此大侠居然毫不失手，不能不叫人佩服！）
    新一代各个系统投产也仅仅听说系统不好用，没有听说过宕机状况屡有发生，咱不能无中生有。
    “十日谈”：再再次——性格倔强！嘿嘿，金无足赤，人无完人，大侠也不能无所不能。尤其当操作人员出于对BANCS不了解，就会有不知如何处理的情况发生，导致了大家对大侠一些误解。然而真金不怕火炼，真大侠不怕考验，通过大量的培训、锤炼，我们已逐渐掌握了与之相处之道。
    性格倔强是不是就是要求大家“通过大量的培训、锤炼”去适应它吗？   
    “十日谈”：一日 问下英雄出处…
    就笔者粗浅的知识，知道此位大侠来自南半球的澳大利亚，一路飘洋过海来到我行。在此之前，他曾经在澳洲、西欧、台湾等地区的一些银行成功运行。
    本来确实不应该问英雄出处，但作为IT业内人士，可能从来没有听说过澳大利亚还出产软件，铁矿石但是卖的挺贵，入股合同签了还能毁约赔钱。“曾经在澳洲、西欧、台湾等地区的一些银行成功运行”，没有听说大的银行运行案例。再说何来英雄之说。
    “十日谈”：第二日 BANCS大侠之名号
    此番所说的名号，乃指BANCS系统的交易码。BANCS系统的交易码非常多，但规律明显：…
    又有看官挑战：09760是什么意思？俺只能苦笑，无语。因为俺只知道是修改密码，但套不上上面的逻辑。那就使出绝杀技——不求甚解，死记硬背。
    BANCS系统的交易码是令新用户头大的地方，现代用户界面的设计都讲究人性化，交易码最多只能作为一个快捷人口选项，系统使用的快慢决定于交易画面的输入及后台账务和业务的处理，而不是仅仅是选择交易的快慢，繁多的交易码逼迫用户死记硬背，感觉从Web时代回到使用字符界面的蛮荒时代。
    “十日谈”：第三日 BANCS的地盘BANCS做主
    …BANCS作为一个核心银行系统，也是对个人、公司依据一定条件开立、记录存款业务的账户，但账号是无意义的为17位数字。…
    其实，各位看官有所不知，BANCS 大侠的这招，可谓是深藏不露，无招胜有招。只要是入了本派，无论你是在北方大漠，还是南沙诸岛，只有一个代号。无论你是辖区变换，还是职位升迁，代号只有一个，那称呼你的人多方便啊。所以我们送BANCS一个尊称：以人为本。
    现代会计系统账号的设置一般都采用了序号的方式，这种用法与软件设计原则中“单一职责原则”是一致的，即账号的作用是标识账户，只要满足唯一性条件就可以了，这样如果系统发生大的修改，账号也不用变化，不像以前的系统账号包括了货币核算等诸多信息。只是这种设计与以人为本有什么关系。
    “十日谈”：第五日 BANCS的两大独门暗器：一本账和二次更新
    而所谓二次更新，更显BANCS大侠心思缜密。比如，今儿事务繁忙，大侠即号令手下，凡柜台发生金融交易，先写进交易日志，待闲时，再用二次更新程序(SY1000) 从日志表读取交易记录并将分录写到总账接口文件中(GLIF)。
怎么样，诸位感觉如何？大侠果然是大侠，事无巨细，井井有条。
    采用这种方式，蓝图内部的人士能否介绍一下冲正交易和事后稽核等工作是否比较困难？
    “十日谈”：第六日 BANCS的有所为有所不为
    身为掌门，当然BANCS大侠也不是事事亲力亲为。比如他更关注交易的处理，而对于统计报表、利润分析等等事务，一概安排给总账系统几个“长老”去做。“长老”们分工如下：如MIS系统负责统计类报表，PA负责利润贡献度分析，还有个长老（名字俺忘了），负责集成报表。
    PA（利润贡献度分析系统）将负责全行分机构、分产品、分客户等维度的利润贡献度分析。该系统涉及上存下借、内部资金转移计价、减值准备、中间业务、内部分润等十余个业务功能。
    明白了这一点，我们就不要要求掌门管太多的事情。要知道，如果掌门事必躬亲，即使他是三头六臂，也会影响他的工作效率，岂不是得不偿失。
    从第六日就可以看出来，BANCS确实就是一个记录交易的系统，其它事情都交给其它系统完成，从银行系统整体架构上看，确实算不上是核心系统。
    “十日谈”：第七日 BANCS系统中的核准人员与旧系统复核人员的职责差异
BANCS和以往我们使用的系统还有一个非常巨大的区别。如：旧线系统中，无论什么业务，都要设置一个经办一个复核。复核要对经办所做的每一项工作负责。无论大事小情，上至账号金额，下至漏章错字，吃喝拉撒全负责。如此设置，表面上看起来是覆盖全面，天衣无缝。而实际上，其中的隐患不可谓不深：第一、经办复核之间很容易产生依赖心理，进而产生操作性风险，是谓之“集体负责等于无人负责”；第二、复核关注的点过多过杂，容易削弱复核的注意力，有时会抓芝麻丢西瓜。
    我们再来看看BANCS，想当初俺看到大侠的安排时，就仿佛天际一道闪电，顿时照得俺如醍醐灌顶——世界上咋有这聪明的人哩？千言万语化为两个字：佩服！
    诸位看官，请听俺细表。
    由于BANCS系统是一个交易驱动的系统。所谓交易驱动，就是只要柜员明确自己想做什么，选择正确的交易码，那么后台的会计核算会自动生成，永远不用担心用错核算码。看到这里，有些看官恍然大悟：想当年用NACS时，会计核算可是一个最重要的环节呀。常常出现给客户记账记得对，但是轮到写对方科目时，却给记错了，结果冲账时连客户账也得一块冲。耽误时间不说，跟客户也不好交代呀。“嗯~~（捻须晃脑），BANCS高出一筹。”
其实，BANCS是交易驱动，意味着复核人员不仅不用关注会计核算，同时也意味着不用关注汇率折算、回单缮制、统计报表等等事务。甚至一部分交易还控制了对诸如汇率类型、跨客户号入账等等错误的控制。可以说，现在想犯点错误都难。在这种情况下，如果每笔业务，尤其是小额频繁发生的业务，仍然按以前的模式设置一个经办一个复核，实在是极大地浪费。
    二十一世纪什么最贵？人才！我们必须把我们的人才用在刀刃上。因此，BANCS系统摈弃了以往的复核，而引进了“核准”这个概念，核准人员只对核准点负责任。比如，在汇款交易中，如果不改变原汇款报文的账号，则一个经办即可入账。如改变了账号，则跳出核准点“入账账号被变更，请核准”。核准员只需对此核准点进行核准，就无需关注其他。套句时髦的话，因为专心，所以专注；因为专注，所以专业。
    本人实在是水平低，说了半天，我也没看出BANCS系统高明之处，旧线系统不是也可以单人临柜吗？“十日谈”所举冲账的例子，只能说旧线系统有效性检查不够。再说中行内部有没有评估过BANCS上线前后节省了柜员多少工作量。
    “十日谈”：第八日 大侠也有“脚踝”
    BANCS虽然贵为掌门，但也有自己的软肋。具体的说，就是涉及到一借多贷、多借一贷乃至多借多贷等等旧线常见业务时，由于此种情况与BANCS的设计理念完全背道而驰，会将这位掌门愁死。好在BACNS中还有BGL账户，并有若干BGL交易（如BGL与客户账之间的对转、BGL与BGL之间对转），通过它搭桥，完全可以避开这些困难。
    如果BANCS实现连一借多贷、多借一贷乃至多借多贷都比较困难的话，确实对不起“大侠”的称号，要知道这都是会计的基本账务要求，通过其他方式避开困难，会计人员会不会感到困惑。
    第九日 玩转BANCS
    操作窍门涉及两个原则：一、尽量多使用键盘而少使用鼠标；二、充分使用系统提供的一些热键。
    …
    3、很多交易都没有历史查询的功能。如果非要查，可以使用“日志查询”功能进行查询。
    “充分使用热键”，这种理论在使用Unix系统的时候就耳熟能详了， Unix系统用户界面设计理念让骇客们体验还行，动员中行全辖老少柜员都这样用确实有点难为他们了。
    第十日 如何与BANCS 相处
    既然使用BANCS，那么就要尊重他的设计理念。如果系统流程与现有的业务操作规程不相适应，那么做何取舍，就是非常重要的。如果非要用陈茶冲水，又如何能够得到新鲜的茶香？！举个例子来说，BANCS中的汇款类业务，完全通过接口从电讯系统接收报文，柜员在BANCS系统处理后，会计账户自动生成，根本无需打印报文、缮制会计传票，即完全实现了无纸化处理。但是一些部门根据以往的会计传票规定，硬性要求传票中包含报文和传票，就要求柜员使用专门的交易去打印，既浪费了时间精力，又导致了人员的浪费。
    这种情况已经得到充分关注，并设立了流程整合专门部门，相信以后会越来越顺。
    这些部门SWIFT的使用理念确实落后，如果为此专门成立流程整合专门部门，确实有点小题大做了。
    总的说来，难得有人这么详细介绍了BANCS系统，让局外人也能一窥管径，再说“十日谈”这个名字确实取得有点意思。

zhouky4665

为了100页，啥都不说了。