中央银行使用ERP5运行其64个监管工作流程: 货币发行, 货币流通及银行业务交易。广泛的可扩展性测试及基于本地规则的安全管理是成功的关键技术因素。在实施过程中使用以文档为导向的方式降低了项目管理的带宽及预算。从系统到应用贯穿整个数据库地使用开源技术为关键任务应用提供了活跃的支持。

背景介绍: 从大型主机到桌面

一个负责八个国家货币联盟的中央银行在九十年代末决定从基于大型中央主机上的财务软件以及大量的文书工作而运行的传统信息系统向基于通用现成软件Common Off-The Shelf Software （COTS）的零纸张方式及现代IP网络转移。通过使用Intelsat及思科技术，卫星连接及IP路由被部署在超过20家的中央银行分行中。由IBM提供的台式计算机取代了终端设备。Oracle应用由第三方和中央银行的工程师们共同部署并进行了配置，从而实施财务及工资支付的功能。在短短的几年内，中央银行就实现了其信息系统的现代化。

其后，中央银行发现开源软件可以提供更多的灵活性并节省费用。原始的邮件平台是基于Lotus Notes技术，而生产性软件则都在使用Microsoft Office。而今，两者都被开源软件取代了。 邮件平台转移至Thunderbird和Postfix。Microsoft Office则由Open Office取代。打印管理及文档共享转移至SAMBA。通过使用开源产品，IT部门不再需要提前一年计划投资预算，大量的事实证明，这帮助了中央银行的用户在短时间内就可以得到解决方案，并无需打破其在采购方面的管理规定。使用开源产品同样大量的减少了花费，甚至超过2000欧元/用户。

但是, 通用现成软件Common Off-The Shelf Software （COTS） 在一种情况下失效了：银行核心业务中和货币发行，货币流通及银行交易相关的流程的实施。在配置并部署了一个标准的专有ERP之后，还要进行大量的定制开发工作以满足银行对监管任务实施的需求。这个标准的专有ERP的安全模板无法与中央银行的基于本地规则的访问控制政策相匹配。并且，随着用户数量的增加，暴露出的扩展性问题也阻碍了标准专有ERP的使用。另外，在那个时候，标准的专有ERP只支持因特网浏览器, 这样也阻碍了中央银行向开源桌面应用转变的步伐。

于是中央银行开始寻找可以支持其监管需求的，具有良好可扩展性的并与任何网络浏览器（包含高延迟VSAT网络）兼容的替代产品。

挑战: 60个监管工作流 , 10000 个安全小组

中央银行的运作源于国际条约及监管指南，即需要得到财政部长或中央银行总裁的批准。他们直接影响银行业务流程实施的方式。改变这种监管需求通常需要比实施一个ERP更久的时间。所以给中央银行安装的ERP需要可以适应其监管需求的工作流程。

这个中央银行有64个核心业务流程。 我们可以在这里列举一部分：货币发行及销毁，支票支付，转账，旅行支票销售及采购。它包含了25个分支机构，每个分支都有至少290个站点例如主要金库，柜台，现金分拣桶。银行的员工被根据职能及隶属指挥部门分组。银行里一共有35个职能小组例如：会计，分析师，出纳员。一共有8个指挥部门，每个部门都有分部及办公处。指挥部，分部及办公处的总数为4943个。

只有具有特定职能，在特定分支或站点工作，隶属特定指挥部或分支的特定员工才被准许执行64个工作流程中的特定任务。因此ERP中工作流程的配置就需要支持 64 x 4943 x 35 = 11072320 种可能的安全小组。

这个中央银行也需要与其他银行进行接口，例如使用SWIFT网络的银行。每个监管工作流程都需要以某种方式配置，从而使每项交易的结果能够接入相应的应用：财务，工资支付，结算，国际转账等。

经过一轮国际竞标后，ERP5开源ERP被选作这个中央银行实施其监管需求的核心平台。

实施：以文档为基础的实施过程，配合已有程序

ERP5是一个建立在统一业务模型Unified Business Model (UBM)上以文档为导向的ERP软件。基于UBM， ERP5只需不超过10个表格来存储核心ERP属性。大多数的传统ERP都需要上千个表格来达到同样的结果。并且，ERP5的文档导向方式能够适应一个组织机构的现存文档及已有流程。ERP5的文档导向方式无需改变工作习惯或内部流程。在这个中央银行的案例中，由于其核心流程的监管特性，这一点是非常重要的。

在中央银行中实施的方案叫做: "ERP5 实施流程". 这个方案是相对容易的：通过测试案例描述目前的业务流程, 收集银行所有的纸质文档并将数据同步到ERP5。但是，在实施这三步工作之前，需要做一些抽象的分析以确定“统一业务模型“是可以被应用到中央银行中的。尽管近十年里我们还未发现一起不能应用“统一业务模型“的商务流程案例， 在投资几个人进行全年的项目工作前花费几周做一些理论评估是更加保险的。

这个对中央银行核心流程抽象分析的过程引出了一个与此领域相关的业务模板叫做 "ERP5 银行业务", 它包含了几百行的Python编码。"ERP5 银行业务" 囊括了类属业务规则并最终简化了银行和支付业务的任何应用的实施。它现在被用于移动支付系统，公路收费系统及虚拟货币结算等业务。"ERP5 银行业务" 于是被设计成为这样一个应用：具备足够类属性的统一业务模型，适用于包含中央银行业务的任何银行业务流程。

这个项目包含了三个阶段：建模，实施和终结。

在建模阶段，这个项目被分成3组。第一组收集所有的文档类日常管理样品：表格，收据，报告等。这一组主要成员是中央银行的工程师们。第二组负责实施一个单一流程的模型。这一组的成员包含了Nexedi和中央银行的工程师。第三组负责为银行账户用户们实施一个同步系统。这一组的成员是Nexedi的工程师。

收集日常管理文档样品的过程帮助定义了此项目的规模：所有的交易表格，收据，报告，及工作流程界面都被考虑到了。通过模型的实施，创建一个覆盖单元测试，含有加速输入表格，报告以及连接外部系统和文档的界面的模板。这个模型证明 "ERP5银行业务" 抽象化"的实际适配性. 账户资料通过SyncML协议的同步证明了将基于Oracle的应用与ERP5建立接口的可能性，无论是迁移遗留数据，或者在遗留应用中更新数据。

接下来，实施工作就可以开始进行了。根据现存的中央银行日常管理工作使用的纸质文档，60个工作流程被逐一建模。每一份纸质文档 —— 例如转账表格 —— 通常显示了由手写签名实现的不同验证状态以用作之后追踪决策的责任权。每一个验证状态都将作为工作流程状态被配置到ERP5基于Web的工作流程编辑器。每一份纸质文档也展示了不同的属性，例如日期，帐号，金额，货币等。每一属性都被绘制到ERP5统一业务模型中已存属性及基本类别中。一旦配置好一个工作流，我们立刻定义其安全性及权限以保证只有特定资质的员工可以执行工作流程状态的特定修改，也被称作工作流程转换。最后一步流程转换通常引发数据录入到中央银行“事件巴士“（event bus） —— 一个将所有应用和财务应用的界面连接的“中央车辆“（central vehicle）。我们为每一个流程都开发并设置了一组单元及功能测试，以避免之后使用过程中出现任何的功能性衰退问题。

整个实施过程进行了一年左右。在管理日常文档之上，我们也添加了标准监管报告功能以便可以完美生成现有纸质报告类型。确保新的ERP5应用可以和目前基于纸张的工作流程完全一直，这是一个非常清晰的目标 —— 正如接下来要介绍的 —— 是项目成功的关键因素。第一次验收测试，是被组织在所谓的 "实验室"中进行，并基于由银行员工编写的一个详尽的测试案例，结果显示功能符合度达到了94%。剩下的6%是由于一些功能并未被包含到日常业务程序中，于是在项目实施过程中产生了变化，或是使用到非监管文件。

作为终结阶段的一部分，根据第一次验收测试的结果，我们需要附加几周的开发时间进行改进。第二次验收测试，进行于实施阶段完成后的9个月，显示了100%的功能覆盖率。也许大家会好奇，如果所有的功能都已经被覆盖了，那么终结阶段的工作究竟是关于什么的。终结阶段的工作是关于可扩展性。第一次尝试实施专有ERP就是因为可扩展性而失败了。所以Nexedi决定在ERP5的实施过程中证明ERP5可以胜任中央银行在未来5年内所期待达到的数据量和交易量的两倍任务的能力。

可扩展性测试的开发是为了模拟ERP5在真实场景中的使用情况，包括延迟，与顾客讨论的耗时，午餐休息等。原始的测试结果不尽人意。当两个用户同时处理交易时，ERP5交易管理系统就会阻止其中的一位完成他的交易。原因也很简单：银行交易系统是由一系列的按次序逐渐增加的参数给予指令，不支持完全平行的长时间交易的处理。于是交易编码就被改为在日期前缀后包含一个随机部分。渐渐的，通过优化指标和MySQL中的表结构，通过在ERP5活动中使用新的算法，通过加速ERP5目录，我们可以支持300个并行用户同时进行高强度交易。另外，整个ERP5应用在投入生产前可以完全通过300个模拟用户的测试。

在2008年2月4日，中央银行25个分支所有当前程序都被同时从纸质文档和电子数据表转移到ERP5中。

成功因素: 客户及供应商共同参与工程实施及新型安全模块

ERP5实施64个监管工作流程的高灵活性及高生产效率显然是成功的一个关键因素。ERP5基于标准HTML表格和"每笔交易一个HTTP请求"概念的用户界面是使应用程序在高延迟VSAT网络下运行的重要因素。但他们并不能独立解释工程实施的成功。

中央银行的员工在项目中的参与极大的帮助了对监管程序和报告制作的专业知识的掌握。如果没有中央银行员工的参与，Nexedi是没有办法单独达到同样成果的。参与项目的中央银行员工大多是受过优秀大学教育的工程师。另外一个关键员工是一位有着超过20年经验的了解所有工作流程的前分行经理。这个项目在超过两年的时间内都是秘密进行的。只有在投入正式使用的6个月前才被公开。最初许多银行高管都认为此项目会失败所以并没有加以干涉。这有助于减少在项目管理上所需的带宽并促使其在短时间内顺利完成。相反，全球许多ERP项目失败的原因是有太多的高管干涉，不断延伸功能要求并制造了项目的带宽瓶颈。

其他ERP5关键技术也在项目中出演了关键角色。使用Zope对象数据库（ZODB）结合NoSQL方法来储存银行数据表现出了优异的可扩展性，可能比任何关系数据库的可扩展性都要好。利用活动(activities)，ERP5异步并行处理技术有助于并行处理大量交易并实时将其按小批量分组。

另一个重要的成功因素是ERP5管理访问权限的新模块。大多数应用程序框架使用用户，小组和角色的分配方法。用户是小组的成员，一个小组被授予一个在特定环境背景中的角色。只有特定的角色可以执行特定操作，或访问特定数据。这个简单的模块适合简单的应用。一旦工作流量变高，将会发生两种情况：角色爆炸和小组爆炸。应用开发程序员往往会为每个工作流程创建几个角色。64个工作流有近乎300个角色。程序员也为每个职位，指挥部和站点的结合创建小组。中央银行这个案例中，一共需要创建1500000个小组。

为了解决小组爆炸和角色爆炸的问题，ERP5介绍了一个新的方法进行权限管理：基于规则的权限。首先，ERP5认为管理中的大部分工作流不需要超过5个角色,即 "5A" 在ERP5术语中被称作：Author（作者）, Assignee（受托人）, Assignor（转让人）, Associate（合作人） and Auditor（旁听人）。作者的角色定义可以创建一个新交易的权限。受托人的角色定义了负责发起交易的权限。转让人的角色定义负责验证交易的权限。合作人的角色定义可以干预验证过程的权限。旁听人的角色定义仅可以咨询方式访问文档信息的权限。

ERP5随后提供了一个基于规则的系统，用于明确哪些职能，指挥部及分支机构被分配到"5A" 中的哪些角色。规则看起来像 "同一指挥部下的所有用户都是文档的“作者“，并具有金库经理的职能" 或 "总部的所有用户具有会计职能"。每个规则都含有2到3行的謂语定义。ERP5用一种有效的方式解释了謂语，并给每个交易附加了一组所谓的安全密码，和交易一起被储存在数据库中。于是交易访问权限被紧密连接到Zope对象数据库持久化机制。这减少了安全和访问权限被外化到另一个系统时经常发生的信息泄露风险。安全密码也被有效地索引到MySQL关系数据库中。查询系统中给定用户可见的交易清单从此得益于快速索引功能。这是ERP5架构相比基于外部权限管理系统或过滤的方法的另一个强大的优势。

解决难题: 开源产品给予客户活跃的支持

当项目在二月一日开始时，一切都进行的还算顺利。所有的用户都可以使用ERP5。系统如我们预期一样具有可扩展性。但是，一小部分的交易没有被正确索引到ERP5目录中。Zope对象数据库和MySQL表现出一些交易行为，这些行为之前并未被发现并且可能导致工作流程被阻断。这些行为在1年里都从未被发现，尽管模拟银行流程的安全比例已达到了2。

很明显，现实情况与模拟还是有细微差别的。一些交易之间的延迟并不能被模拟出来。经过调查，Nexedi客户支持团队发现误差交易行为的源头存在于Zope核心数据库，ERP5活动系统（ERP5 activity system）和MySQL的复杂组合中。在24小时内，通过修改Zope和ERP5中的一行源代码，问题很快得到了解决。

试想现在同样的情况发生在专有数据库，专有应用服务器和专有ERP中，每一项都有自身的支持合同。如果无法同时访问三个组件的源代码，并且没有能对所有核心组件的代码有直接访问权限的客户支持团队，这种问题将会非常难以被分析出来。在专有软件的世界这种客户支持团队是几乎不可能存在的。

只有开源软件支持建立这样的客户支持团队。Nexedi已经在ERP5可扩展性测试中学到如何重新编译MySQL - 目前是MariaDB - 并优化其性能。Nexedi团队已经通过在大型数据集合上进行一年的可扩展性测试了解Zope内部。使用专有数据库及应用服务器，这是无法办到的。

未来的革新: 用于全球银行业的SlapOS云，分布式NoSQL

在4年的安全运行后，ERP5开展了该中央银行更多的工作流程部署工作。与自动实时结算系统和国际转账对接的接口已完整地集成到ERP5中。这为中央银行节省了大量的预算。

中央银行的员工可以自行扩展ERP5，创建报告，将ERP5与外部系统例如自动提款机或新的支付系统对接。ERP5同时与JEDOX PALO商业智能软件对接，从而提供用户配置的在线报告功能。

最近，ERP5被对接到Zope2.12。银行最近更新的版本已经使用SlapOS云操作系统。ERP5“银行业务“的整个建立，部署和运行都由SlapOS自动化运行。

将来，ERP5将采用一个基于Javascript和JSON的新用户界面，同时保留 "每个交易一个HTTP请求"。一个叫做NEO的基于分布式储存的Zope对象数据库的新版本，已被计划用来支持大数据量和自动化灾难后恢复。 通过五年的研究，NEO现在能够提供比ZEO更可靠更优质的性能。使用NEO， ERP5“银行业务“能够支持20年的数据量。由于其缺少相关的贸易支持（Sun Microsystems被Oracle收购），MySQL也将被MariaDB取代。 另一方面，MariaDB正处于一个非常快速的发展时期并能够支持关键的应用程序 。

MariaDB背后的故事同样证明开源软件在长期发展下的力量。尽管有恶意收购的存在，开源产品的开发人员还是能够幸免并继续为用户提供开源项目的支持。对于大型机构例如中央银行，ERP5开源系统是对在接下来的20年内维系其核心系统的保证。