背景：从纸质文件和电子邮件到电子公文流转

客户需要能够追溯所有与第三方承包商签订的合同的信息系统。他们已经有一套由双方合同和第三方承包商的法律规定定义的离线审批手续，但是，所有流程通过电子邮件和简单的纸质文件交流的离线操作，这两种方式既没有效率，也没有追溯谁何时批准何种合同内容的可能。

Nexedi建议采用基于决策模拟的文档管理系统（DMS）和电子公文流转系统（EDC）的结合，这将能够管理整个合同审批流程,包含所有涉及的全部合同文件。该项目的挑战是在一个非常复杂并持续变化的商业环境中对两种类型系统的结合。

为了满足客户对EDC系统的要求，我们开发了“决定”的一个新的抽象方法，其中“决定”是系统中的一个对象，代表一项指定的人执行的活动。这一简单但强效，通用的概念提供了可追溯性，历史记录以及简洁性：任何被指定做出合同决策的人必须批准或拒绝一项由系统为其生成的决定。只有系统知道通过商业程序规定的商业规则应该对谁生成何种决定。因此，用户只需对一项决定进行批准或拒绝两种选择。

该系统的另一有趣的特征是它提供了共同制作文件的协作工具，从而描述文本形式合法文档。为此，我们使用一个现有ERP5 DMS应用程序，它允许用户在系统上有效地协作操作任何文件，而系统负责处理类似文件修订，版本和历史记录等所有细节。所%X-Balancer-Current-Server: nexedi-4 89这些操作都和EDC部分紧密结合：例如，给一个合同添加一个新的版本可以被认为是拒绝“决定”，但在其他情况下，如果新版本改动是轻微的，那么它就被认为是批准了“决定”。

项目一开始是1.5个月的建模，以展示ERP5将如何满足客户的需求。成功建模后，Nexedi开始真正进行项目。项目进入生产阶段后，任何新的附加功能都会被一一建模，这样，在花费任何时间进行功能完善之前，客户就能够看到新的功能雏形。生产过程结束后，客户的工程师再将大部分系统翻译成俄语。

“业务流程”为公司内部任何流程建模

“业务流程”的概念被用来描述合同审批程序，从而批准合同或第三方承包合同。这是一个目标通用概念，它允许开发人员对一家公司的内部流程建模，无论公司是一个服务型，贸易型或制造型企业。Nexedi起初为制造业务开发了该模型，但它在本项目中仍然适用于贸易和销售型公司。这表明，任何ERP系统都可能也需要具备允许企业管理者自己通过很好的ERP用户界面来描述任何业务流程的工具。这也证明，建模业务流程能够在深入了解自身企业的商务人士和了解系统技术但对客户业务一知半解的真正的系统集成商（例如Nexedi）之间提供一个很好的抽象层面。正如本项目中发现的，两方面是可以天衣无缝地合作的。

在当前的项目背景下，我们使用的业务流程是一个抽象的工具，基于现有业务规则来描述任何可能的合同审批程序。 这个工具为我们提供了可配置层，这样，甚至客户的工程师也可以自己设置新的新的审批程序来扩展系统。

为什么通过业务流程进行抽象是非常重要的

在目前的系统背景下，我们以一套让所有决策参与者对决策进行并联审批的业务流程为开端。最初，人们认为并行工作比按顺序工作更加有效率，这在理论上是正确的，但现实确实不同的。

在现实中，在审批流程中对合同属性或合同本身的改版是经常性的，因为文档流转本身还涉及到文档的协同创作，但审批过程总是需要所有相关成员的一致批准。这就是为什么并行决策模型——系统中最有用的部分，最初并不被接受，因为它可能导致正进行修改的文档版本被复原。
然而，后来推出的顺序决策模型也会合同起草者之间大量的挫折，因为它会导致多个迭代决定和拒绝请求群组。而更糟的是，由于系统的良好的历史记录，低效率的工作变得透明化。幸运的是，这种缺乏效率的现象可以通过重新安排公司内部的合同审批业务规则很快被修复，从而在将来把它们变成纯粹的ERP5“业务流程”使用到系统中。

上面这个例子说明客户的业务需求变化可以如此之快（从并行到顺序的审批流程）。幸运的是，由于使用的是“业务流程”的抽象工具，这种客户方面的需求变化并不需要重建系统——我们只需要对所使用的一套业务流程进行重新建模。

实施这样一个系统的挑战

该项目有许多挑战，可分为两类：技术和人。

从技术上讲，我们需要以一种方式来表示基于部门和岗位的相当复杂的内部公司结构，基于其实现强大的安全性，并确保系统能够为基于我们客户所要求的任何现行审批程序的任何部门的任何成员产生决策。为此，我们为ERP5引入了一个新的模块：职位。这是一个通用的工具，它允许使用职位来模拟公司的层次结构。基于这样的层次结构，我们可以建立安全规则来定义用户被允许看到和修改的内容。

由于客户不断变化的业务需求，内部审批程序的变化几乎不断发生，因此需要Nexedi提供极大的灵活性。这在最初创建通用工作流程系统时就被考虑到了，它能够表示任何客户创建的批准程序。该工作流程系统在内部采用ERP5仿真模块，并允许根据需要，由客户方面的工程师通过内置的用户界面自己为新的程序建模。

由于系统依赖于人的决定，很快我们就发现需要添加啊一些额外功能：外部人员的支持或向一个特定的人指派一个特定的决定（无论是由于离开/缺席或是需要一些特定技能进行的决策类型）。所有这些功能都经过小型建模来实现，然后再真正实施。如果没有对该系统的所有部分都进行大量的测试从而防止功能回归，这种部分模块开发将是不可能的。

有趣的是，最具挑战性的部分是如何让人们了解系统的复杂性，并有效地使用它。Nexedi和客户方面的工程师都不得不面对和克服许多挑战，如：从未使用该系统的用户心理障碍，对系统效率的疑虑（在某些情况下，从用户的角度来看，纸张的流通可能会非常快速，高效（但不可管理），等等。培训不仅要理解和使用该系统以及其业务流程，引入该系统对企业内部文化的影响很快就变得明显了。

成功的一部分是使系统尽可能简单，并为用户提供良好的视频培训材料。用户界面的翻译也是有帮助的。

落实完善的安全模式

定义完善强大的安全模式是非常重要的。这需要认真分析客户的公司内部规定，并将其转化为系统规则。

如果没有客户方面工程师的支持，这将是不可能的。然而，这样一个系统还是需要界定何人，何时可以访问何种内容，这就创建了一个非常复杂的安全架构，它完全基于当前使用的审批程序和根据公司层次结构决定的用户部门和岗位的安全规则的组合。

为了实现这样复杂的安全模式，Nexedi采用最好的ERP5安全系统措施—即所谓的“5A”模式，该系统安全模式围绕5种角色创建：Author（作者），Assignee（受指派者），Assigner（指派者），Associate（相关人员）以及Aditor（阅读者），从而任何登录的用户都可以加以区分。每个角色定义为给定对象一生中的任何时刻定义某些权限。采用矩阵或文件权限以及5A模型，这就允许任何ERP5的开发者为任何用户组轻松定义安全权限，这对处理财务材料这样的敏感信息的流程就非常重要了。另一复杂层面来组公司基于部门和岗位组合的层次结构这一事实。考虑到客户非常严格的业务规则，这就使安全矩阵性变得相当复杂。

敏捷开发和远程工作

Nexedi使用敏捷方式开发系统，一方面由于业务所需而快速兴起的变化，另一方面由于在短时间内小步伐开发可以使我们最大限度地减少业务需求和实际执行之间的误解造成的风险。

这个项目不是该规则的一个例外：正常的功能开发时间是在数周之内，而非几个月。如果没有ERP5这个被设计为完全通用的系统，使用通用工具并不进行任何假定，那么这将不可能实现。在这个项目中大量使用的另一种工具和概念是所谓的现场测试，基本上就是能够在一个“活”系统上运行单元测试，可以进行任何测试。这使开发周期变得很短，因为任何时刻，你都可以运行现场测试，以证明你目前的变化并没有在代码中引入任何回归。如果没有大量测试，这样一个复杂的系统是不可能建成的。

考虑到客户在俄罗斯而拥有来自世界各地的工程师的Nexedi总部在法国，整个项目的实施是远程完成的，这本身就相当具有挑战性

SlapOS云，分布式系统，弹性和NoSQL

客户的系统运行于有SlapOS提供的云基础架构。

对系统的访问很大程度上依赖于res6tnet，这是Nexedi开发的另一个基于通天弹性的网络组件。由于任何数据中心的可靠性是不可预测的，并且取决于许多因素，该项目首次引入一个新组件：Resillient Webrunner。这个Webrunner负责向至少2台在不同的数据中心的计算机生成生产系统的副本。如果一个数据中心出现故障，通过动态DNS规则，我们可以轻松地将前端系统调整指到备份系统中。由于流量通过IPv6，我们可以从任何地方访问任何机器。

所有数据都存储在ZODB这个NoSQL数据库。 然而，和许多NoSQL数据库一样，ZODB数据库缺乏高效的查询语言，因此ERP5使用MySQL数据库进行对象索引，并提供原生查询API。