致远协同进入业务定制领域已经有数年的时间了，，，引领了“0代码”定制新业务的应用，，新业务涵盖了协同HR、
、、协同费用控制、、协同行政管理、、协同CRM，，以及多种协同业务，，，但对于协同应用定制平台
，，似乎还缺乏较为完整的描述
。。。

平台是指具有网络效应
、、
、多边协作的规模越大应用效果越好的一种高弹性的适应方式，，，比如我们看到的电信网络随着手机使用人数的增长而增加了通话价值，，
，
，随着微信的各类团队实时的沟通协作及泛在线的建立，，，微信应用成为我们相互沟通，，传递文字、、、、语音和图片信息的一个渠道，，
，这就具有明显的网络效应
。。。
。

作为面向企业业务的定制平台，，，，我们希望在平台上有更多地人参与制作“业务应用的信息化包”，，而这些制作者既可以是我们自己的实施人员
、、伙伴的实施人员
，，，，也可以是我们的客户
，，大量伙伴涌入制作包就使得业务定制的从业人员大幅度增加
，，，知识转移和学习的成本因为大家都熟悉而大幅度降低，
，，这就可以吸引更多的人愿意从事业务包的定制工作，，从而达成网络效应。
。。。

更进一步，，，，我们希望客户也可以将定制的业务包输出，，并获得信息化经营的收益，，，，这就将客户转变成为了供应商，，从而实现了双边网络效应。。要达成这些应用模式，，
，改变商业的逻辑，，也就是供应链的价值网络与需求端的价值网络的互联、、、、融合，，
，组合成为更大的生态网络
，，就需要系统具有很多简单的功能性产品不具备的一些特征，，，，这些特征应该有以下这些，，，
，但不仅仅限于这些特征：

1、、、应用包的自组织
：也就是业务应用包能够独立成为一个“实体”，，，成为一个类似于独立的“软件”，，，但这个“软件”的构造是由我们的实施人员
、、、、客户方的工作人员制作的
。。这个“软件”需要具备：

(1) 业务包数据自描述：这是业务的数据结构的组合
，，，，能够告知使用者、、其他业务包或者信息系统“我有什么”，，我的权属关系，，是否可以被直接使用，
，以及如何使用；

(2) 业务包功能自描述：业务必须能够自我描述“我能够为组织做什么”，
，
，，我能够提供一些什么样的功能特征
；

(3) 业务包的兼容性自验证：业务包的指标体系，，，业务包的结构
，
，，数据+功能的组合，，，，业务包自身的版本号，，，，以及历史上的一些改进；

(4) 跨业务包的应用验证
：历史的“记忆”复制，，，，业务表、、业务应用之间的关系逻辑描述是基础，，当业务进化时
，，，，这些特征可以象“基因”一样带走
，，成为下一个业务包的概念、、、内涵。。。

最终，，我期望我们的业务包能够具有一定的智慧，，，，而不是机械的结构与植入。。

2、、、运行态的自组织：

(1) 业务包导入导出的逻辑特征：导出了哪些数据定义、
、
、数据和应用，，，并且能够对运行过程进行自动监控
；
(2) 表间关系的自适配、、、、自动识别，，，最好能够对触发、、会写自动组合逻辑，，前期能够与人互动
，，以后可以自动相互适应，，，自动抽象出模型
，，能够自动学习（这个路还有点长）
；

(3) 能够标准化模型，，，形成有机的层次结构和横向的协作结构，，
，这样的业务应用才会有更强的生命力；

3
、、开放性：

业务应用的开放性，
，，能够支持更多的应用接入，，，
，业务应用互动的生态特性；
(1) 支持业务包的导入导出，，，能够驻留于不同的系统中，
，比如A6+、、、A8+，
，，，能够在一个集团化单位，，
，
，一个行业，
，一个领域中应用；
(2) 业务包能够适应组织的变化与成长，，，
，比如人员规模的增长、、组织架构的变化，，行业的转型、、、对组织环境的适应
；

(3) 公众性：所谓的开放
，，是容易学习，，，容易使用，，不需要学习或者很小量学习的系统，，具有大规模人员的所谓“粉丝”特征的系统；
、、

4、、连接和互联：

所谓连接的开放系统
，，，，业务定制不仅仅是内部的自循环
，，
，，封闭的系统，，，业务定制支撑接入生产设备信息，
，，并结合组织的分工安排，，，形成团队的工作贡献的执行控制
，
，，，并积淀行为大数据信息供组织决策使用；
(1) 业务定制系统还应该连接人、、、、连接团队、、、连接行为（时间、、、地点和活动），，，
，从而形成纷繁复杂的在“应用现场”的符合活动信息，，，，提供可跟踪、、
、、可管理的业务执行与活动控制，，并将结果呈现给领导
、、组织的公众，，，，从而大幅度改善信息不对称，
，，增加组织的信任网络的信息化建设；

(2) 业务定制的应用包之间，，
，本身就应该成为协作系统，
，甚至是跨系统部署的业务之间的互联，
，这使得我们的系统能够通过“蜂群效应”获得更大的信息网络效应

5、、、应用约束：

(1) 任何平台具有范围约束与规制，，对于协同应用业务来说
，
，，，我们聚焦于协作行为
，
，，包括人与组织的协作，，
，人与人的协作，，，部门与组织与人的协作
，，，聚焦于行为信息化而不是复杂的计算逻辑；

(2) 聚焦与组织内部、、、
、组织之间的协作，，，支持层级结构、、
、、网络结构和矩阵结构，，而不是各类无结构的应用模型的无边界设计，，，实际上前期我们依然聚焦与组织内的应用，，，扩展到组织间的应用
；

(3) 我们不做复杂的数理逻辑的演绎，，而是基于多种单元结构的协作模式的建设，，以人为本，
，以组织角色或者组织间的角色结构的协作为主要方向
。。。

6、、
、、环境适应性：

(1) 平台正因为具有开放性
，，
，，因而具有更强的环境适应能力，，，
，实际上我们定义的业务应用就是基于互联网的一个工作节点，，，是融合数据
、、、应用的模型化的业务模型，，，，更多的时候是部门业务与组织公众的连接，
，，对于网络、、、、浏览器、、设备都需要广泛的适应性；
(2) 应用业务包的迭代模式，，成长方式，，这些需要设计态
、、、运行态和监控机制的建设，
，确保客户的应用系统是可以“自动成长”的；

(3) 复制机制：组织级客户本身就是复杂的对象，，，对于同一个应用领域，，会因为人员规模、、、收入规模、
、、管理风格、
、、行业特性具有很大的不同，，，，并不是一个简单的复制即用的系统，，，，如何能够自适应、、如何能够自动纠错，，，，是一个复杂的机制
。。。

7
、、、、生态特性：

(1) 治理机制
：生态伙伴如何协作，，这不仅仅是一个技术问题，，也是一个商业问题，，，比如经销商的职责分工，
，权力与利益分配也许存在诸多漏洞需要弥补，，如何吸引并管理好合作伙伴，，，，创造多家企业共赢的生态链机制，，，这是从平台产品的应用架构、、分工协作模型，，
，，交付模型
、、、运维模型和成长模型中都要去思考并设计的
；
(2) 协同机制：柔性连接，，，，系统应用，，多边整合，，智能适配，
，这些特性都能够大幅度提升业务应用的价值，
，使得多个小业务应用组合成为更大范围、、更大规模和更深层级的应用，，从而解决组织的复杂的应用问题，，为提升组织的管理效率服务。。。。

这一篇文章，
，，我希望是对未来的一些畅想，
，，，我们一起努力打造更加适应未来的系统，，，，并立足与现在。
。
。。