摘要：在ERP服务领域，用户界面工作普遍耗时费钱。而对客户端和Web 1.0产品的设计着实需要再研发的投入。尽管Infor公司占领了先机，但赛捷、SAP和SunTotal却紧随其后。
设想一下你为一家大型软件公司管理其研发部门。在过去几十年间，该部门的雇员在竞争收购和扩充产品线等方面为公司的成长做出了突出的贡献。现在你要做的是支持数十条产品线和改进产品结构等工作。然而不幸的是，专注于该种产品的竞争对手正以迅雷不及掩耳之势在所有云端平台引进各种新型的应用。同时他们还引入了新型社交、分析和移动设备等现代化应用。

一些新涌现的竞争者只拥有一条产品线、一种技术栈（如云端多租户堆栈）和单一版本的产品。显而易见，他们的动作迅捷。相比之下拥有众多产品线的老派供应商较之迟缓，其客户和渠道合作伙伴对此感到不满。那么他们能做些什么改进现状呢？

赛捷拥有数量惊人的客户和渠道合作伙伴。他们热切的渴望在新的云端，移动服务和其他方面的改进。

近期我目睹了四家软件公司对此类问题进行攻克。SumTotal公司的举动大胆前卫，它将几乎所有产品在一个单一的新平台上进行重新构建。目前，构架的灵活性赋予了该公司迅捷增添新功能的能力。另外公司还可以很快的重构平台并整合所需产品。其回报是丰厚的，他们能够以市场发展的速度运动，保持竞争力，并以客户需求为基础稳步创新。

Info软件公司拥有全球最广阔的应用软件产品线。同时他们也和其他公司一样承受着来自市场的压力并努力推新自己的产品线。他们在该方面的特点体现在在各个产品线显著提升用户体验（UX）。为此他们创建了提供和存储Infor交易数据和多重规模数据源的云端分析数据库。迄今为止，Infor已创建了可将新的生命力吸收进长期产品线的解决方案。

赛捷集团旗下的赛捷（北美）是另一家具备维护和增强代码能力的久经考验的大型组合公司。赛捷拥有数量惊人的客户（全球超过六百万客户）和渠道合作伙伴，他们热切的渴望在新的云端，移动服务和其他方面的改进。

赛捷采取了一连串步骤来开启转变的大门。第一个步骤是遴选产品线。近期公司出售了ACT！和SalesLogix业务（给Swiftpage），并卖掉了Accel/KKR解决方案。产品种类的减少使得有限的研发经费集中在有限的产品线之上。第二，公司创建了与大部分公司本地解决方案兼容的独立的、只适用于云端的应用（比如赛捷支付解决方案）。此类附属应用拓展了现有解决方案的功能性，而不是将已有的核心应用程序进行改造。

第三，公司创建了赛捷云端数据空间（名为赛捷数据云）。客户可以访问50gb（按需求也可更大）的云端存储空间。来自赛捷云应用的信息（像上文提到的独立应用）和存储在本地应用服务器的数据都被复制并存储到云端。这样一来，移动应用通过一个云端服务器可就以访问核心应用。

此类云数据空间在某种程度上与Infor公司在意识形态上有一定的共识。Infor将核心ERP数据植入云端，所有用户交互行为都将影响云数据的存储。无论客户是在咨询，还是正结束交易，或者在第三方数据源的基础上处理内部数据等，这些过程都将体现在Infor的云数据存储中。无论是什么形式的计算设备（比如台式电脑、远程手机、还是平板用户等），在该结构的影响下数据和结果都将很快的呈现给用户。据我了解，云数据存储是Infor的主要存储方式。数据也可被写回以本地应用为基础的关系数据库或者持久存储设备。然而，只有云数据存储才是Infor的真实的数据来源。

再谈谈我的理解：赛捷，真实的数据来源是独立于控制交易的应用程序的。如果信息来源于本地应用，并被本地应用处理，那么本地关系数据库就是主存储器并且会将相同的资料复制给云服务。而如果数据产生于较新的唯云附属应用的话，那么云服务器就是主存储器。

赛捷（北美）CTO：Himanshu Palsule
我跟随赛捷（北美）CTO Himanshu Palsule以探寻结论的准确性。他称赛捷数据云将数据归入三种不同的类别：参考数据、交易数据和唯云数据。参考数据是指数据需要将本地产品的范围拓展至基于角色用例的移动设备和浏览器。客户、地址、联系人、库存物品和票据等就是此类数据。我认为这个类别中的大量数据都是相当程度的静态表并且（或者）是主文件信息。它补充说该类数据实际上是在ERP系统下的（本地或云托管，如Azure下的赛捷300）并不论何种ERP产品（赛捷50、赛捷100、赛捷300等）都以通用格式被复制到赛捷数据云。这种数据的同步方式为持续同步。

交易数据包括来源基于移动设备和浏览器的应用程序的交易，随后的过程中还会用到ERP系统的业务规则进行处理。如报价、订货、开具票据和支付等交易环节由赛捷数据云所主导，但却经过处理最终注入本地标准ERP工作流程。在拓展移动设备用户范围期间，赛捷能够有效的向其客户提供在商业流程、培训、定制化等领域的杠杆投资的选项。

唯云数据是一种用来扩展本地参考数据以提供更加丰富的用户体验的数据。比如，在移动销售中维持相关库存以抓住增销机会的能力。这种数据被维护在基于UI的浏览器中。即使在升级其本地系统的情况下，它都能够创建一种持续的客户体验（例如赛捷50和赛捷300）。观察其行路历程，运用本地SDKs和差异化的客户体验，赛捷更希望将以上功能被附加到每个本地ERP系统。而目前的新功能只有在能够服务于多种产品的条件下才会被补充进去。

当服务商创建两处以上数据存储空间时，客户应当警觉以下问题：迟滞、同步和灾难复原。迟滞问题易出现于以下情形中：应用程序首次升级某一数据存储器（一种本地关系数据库），但通过其他数据存储方式（比如有一种云报表服务器）提供的用户所需的数据会出现数秒乃至若干分钟内无法观测新的/更新的数据的状况。

Himanshu表示“由于本地数据和云数据的差异可以导致差异化的结果，同步数据（参考数据）并不是为云报表服务器服务的，而是为尝试向剔除客户和库存物品（这些可能不会在云端本地系统被同步）创建报价的潜在的移动销售代表设计的。由于我们运用本地ERP业务规则处理被移动应用创建的交易，所以被剔除的客户会被系统监测并反馈为不良数据以避免此类数据被归入ERP系统内部。目前我们不提供云端报表服务器。然而此类数据一般仍会在本地系统的日终处理（销售日报更新）功能执行后被处理。此类更新会以递增方式将数据输入云端。并且我们以技术确保直到上传中的进程结束，数据才可被云端报表服务器所查看。”

当其中一种数据存储方式出现中断或者失败时，灾难复原就成为一个棘手的问题。怎样在几种存储方式中探寻问题的源头，又怎样这些存储方式中全面复原其他两种存储的数据呢？赛捷有两种数据存储方式：本地和云存储。Himanshu补充“我们利用向量时钟周期计量方式保持数据的同步性。云和ERP系统记录这种计量过程。对云和本地数据的备份修复会引导计量数据的刷新和回归。”

那么如果永久存储或本地存储媒介被重置，是什么导致了客户终止云应用呢？Himanshu回应称“赛捷数据云连接器以Windows服务的形式存在于本地服务器。在系统管理（如会计核算期间关闭或备份恢复数据等）行使过程中，这种服务可以由用户在本地中断。完成之时服务便重新启动并恢复同步。当服务停止时，移动和网络用户可以继续自己的工作，任何需要被ERP系统处理的交易都将在赛捷数据云处排队等候，直到连接器重新恢复在线。”

当依赖于其他应用（如成本核算）数据的一种应用程序（如生产计划）正访问一种特定版本的数据（如通过一种当地RDBMS），但却看到了另一种（如冗余云存储）数据集，同步问题就出现了。数据值的微小差别可能引致令人意想不到和难以理解的差异。

赛捷集团版权所有，经授权使用

接下来我们看一下赛捷在以下领域的表现：

使得赛捷数据云更像一种非ERP数据的终结者。50gb并不是很大的数据空间。该空间尽可能的保存赛捷用户的ERP数据和附加数据。但是它不是真正意义上的大数据集。当人们希望对ERP、HR或其他数据与社会舆情、大型零售商的POS交易数据等进行比较时，这时大数据集（通常超过兆字节以上）就十分必要了。

显著提升云服务的分析能力和应用广度。运用赛捷数据云内部的驻存数据提供更多的预建分析模型。赛捷需要开发应用，设计更多连接第三方数据源的连接器，并拓展包括更多第三方数据供应方在内的渠道合作伙伴。Himanshu说“我们存储在云内的数据持续膨胀，此类功能性将被纳入我们未来的蓝图。与微软的合作和对Azure平台的应用将使得我们有能力创建和拆除对大数据分析的运算丛集。”

为赛捷数据云添加内存数据库功能。基于速度和大数据等因素的考虑，赛捷的竞争对手会被迫向云数据存储提供此类服务。赛捷的标准SMB用户会期待解决方案或纯粹云端解决方案的改进，并将内存数据库功能顺其自然的视为未来服务内容之一。我了解到赛捷数据云的构建是基于若干的数据存储的，如关系、核心/价值、文件和内存缓存等。内存数据库将依据所需被合理应用。

让分析应用推动新型客户体验和工作流程。当分析应用监测到异常行为时，它会利用流程引擎追踪线索，并提供可行方案指引相关人员获得可靠的业务产出。赛捷已经通过赛捷库存顾问服务提供了一种类似的早期功能。但愿赛捷继续推动该功能的演进。另外，预警和审批也应是突出实用的功能。

为所有应用创建一个也是唯一一个历史辑录。这方面的改变会要求一些赛捷ERP解决方案发生变化。对此我和Himanshu有着不同的见解。于他而言，不同的用户群适用于不同的产品的组合，而每种产品只针单一的商业问题。而我相信通用的功能（如会计核算和工资结算等）可共享一个通用数据模型，同一个模型可以同时服务于多种产品线。这样一来，能够轻松连接和服务于多种ERP产品的共享对象和移动应用等将得到长足开发。然而，我与Himanshu关于不同纵向应用程序的理解是一致的。