谈一谈《BANCS系统“十日谈”》

前一阵在论坛看到《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系统，让局外人也能一窥管径，再说“十日谈”这个名字确实取得有点意思。