文/周亮 明道云实施顾问
本人实施传统企业软件 8 年之久，加入明道云，实施 APaaS 产品不到一年。对于两种产品的交付形态差异颇有感悟。接下来我就来分享一下 APaas 产品在交付上与传统企业软件的几处不同。
一、POC 模式
APaaS 产品在售前打样过程中，可以通过搭建应用模型来快速确定 80% 以上的需求范围，高效益地将一个个的需求落地成可视化的产品，让客户快速的体验到 APaas 的产品能力。另外 20% 是需要与客户打磨挖掘出更深意的需求，这也是为什么 APaaS 产品能够快速被客户认可采纳的主要原因。同时 APaaS 在 POC 阶段还可以完成数据的交互形态和数据对接模式，跑通实际业务流程，配置真实的角色和权限。很多项目的 POC 验证过程可缩短至一周内，毫不夸张的说 APaaS 产品在 POC 验证阶段甚至是可以完成交付级别的应用。
相比传统企业软件领域，以我过去实施 ERP 产品的经验来看，POC 阶段大多数限于需求梳理。为了确保原生代码开发的可行性，需要大篇幅整理需求文档，以及需要多部门协同（如项目部，产品部，研发部和销售部同时对接），这就造成了客户需求需要不断的确认、甄别和反馈，前期投入的时间和人工成本是非常高的。
可以说 APaaS 在 POC 环节完全打破了传统软件的需求验证型态，更加准确的定位客户需求。
二、SOW 需求梳理
POC 验证完成后接下来就是为了签订合同梳理 SOW（工作范畴清单）。对于 SOW 的规范，APaaS 对工作范畴定义表达更结构化和清晰化，从而减少歧义，增加客户信任度，降低契约成本。如下是 APaaS（明道云）的 SOW 大致结构：
1.目标
企业通过本应用要解决的业务问题，满足哪些业务角色的何种需求。
2.应用范围
根据客户提供的需求，归纳应用分组，可以是单组，也可以是多组。每个应用分组确定数据对象（工作表），需要分发不同的视图，每个工作表涉及的统计分析项和配套的工作流。
3.原型示范
选取 1-2 个核心数据对象，展示搭建出来的原型截图，主要选用含 demo 数据的列表视图，打开包含关联记录的主记录详情两个画面。
4.交付内容
- 直接可用的 Web 应用
- 通过移动 App 访问（包括 iOS 和 Android）
- 通过桌面客户端访问（包括 Windows 和 macOS）
- 使用说明书
- 应用在明道云中的部署分发，直至客户管理员接受应用管理权限（应用成员的分发由客户自助完成）
5.配套服务
- 按需搭建应用
- 在应用交付后的两周内根据客户需求进行局部修订
- 提供应用使用说明和手册
- 提供管理员培训
三、实施团队
APaas 实施团队成员组成特别简洁，无需多部门协同，从某种意义上来说可以实现一人一团队。在明道云，大多数实施专家都来自传统企业软件行业的实施岗位。
传统企业软件的实施团队结构就相对较多，如：前端，后端，产品，CCB，实施等，除了存在多部门协作，还会存在跨专业的沟通，多方传达需求都很容易遇到各种瓶颈。进度受阻是家常便饭，甚至面临交付失败，服务商违约的风险。
四、可复用性
1.应用分发
APaas 在复用的过程中可以快速分发应用，甚至几分钟即可完成复刻。复刻出来的应用既可以实现独立的载体，也可以实现多应用的交互。除了应用本身以外还可以 Copy 对应的数据库。APaaS 真正意义上实现了一键分发。
传统企业软件的分发过程就相对复杂一点，首选需要部署环境，其次挂上数据库，然后发布 Tomcat，整个分发过程耗时比相对较长，而且操作复杂程度高，非技术人员很难完成。
2.应用导入导出
PaaS 应用可导入导出，简单来说需要分发到不同网络中的应用非技术人员也可以通过导入导出的方式实现操作，简洁方便。
传统行业软件导入导出数据则是需要先将数据库和程序一起打包，重新通过分发的方式再发布一遍，并且有多应用数据交互上分发难度大的问题。
3.二次/多次修订
APaaS 复刻出来的应用可以二次改造，将专业应用重新修饰，快速调整为符合其他场景的应用。调整方式简单易学，可塑造性非常强。
传统行业软件的二次改造离不开源代码开发，小到修改脚本都需要研发团队的支持，没有很强的 IT 专业知识很难去调整，必须多部门协同完成：熟悉业务场景的实施团队和熟悉产品的 IT 团队。
五、交付周期
APaaS 产品因具备低代码或零代码特征，交付周期都不会太长。一般来说，单一业务环节的应用交付在 1-2 周之内，稍微复杂一些的应用也能够在一个月之内交付。这甚至包含了需求确认，文档撰写和交付培训等环节。
当然复杂的应用交付离不开经验丰富的实施专家主导。这也是为什么 APaaS 一直在寻找不同行业实施/有业务能力者作为交付合作伙伴的原因。
六、迭代方式
业务发展到一定程度后，自然就会持续地迭代更新自身的业务流程体系，APaaS 迭代方式是通过编辑表单，建立更多对象，加入互相关联，通过工作流优化数据流程形态来完成客户本身的迭代。可以说是做到了边用边改，随需应变。
传统企业软件的迭代在大多数的时候是不现实的。一旦交付后，只能做一些非常局部的变更。不可能再在产品体验等基础环节继续做工作。APaaS 产品的迭代结合交付后应用本身的修订，可以确保企业用户始终得到可用性很强的方案。
七、API 对接
APaaS 有一套开放式的 API 对接平台，一般情况下技术人员可以看懂文档，无需二次开发即可直接将数据写入和写出。
传统企业软件的对接方式有的是通过存储过程或者编写 Web Service 的方式实现，都需要技术人员的参与。为每一个应用软件开发接口都是要额外投入精力的，很多企业在委托开发的时候往往遗漏了这个需求。这也是为什么很多企业应用在交付的时候都不包含开发接口的原因。
我通过以上七个方面的对比，说明了过去一年我的工作和之前的八年有何本质不同。同样都叫实施，效率和客户满意度和过去不可同日而语。作为一名过来人，我给依然在传统软件交付模式下的实施同行们一个诚恳建议，用 APaaS 产品来交付客户需求试试，您的交付产值可能增长五倍不止。