11
22
33
1
首页>协同观察>致远要闻
致远要闻 媒体聚焦 市场活动

从产品工具蜕变进化中的CAP大规模业务定制体系

发布时间:2020-06-01 来源: 45 次浏览

信息化的世界依然是纷纷扰扰,ERP究竟是数字化的底盘,还是会被平台会大规模替代的产品,是云计算、物联网和大数据打败一切,还是SaaS已经没有未来?

不管环境如何变化,未来的信息技术如何发展,以客户为中心,集中人力、物力和财力诸要素为客户创造价值并获取收益,是企业经营的本质。从这个意义上来看,企业本身就是平台,在企业的供给方面是劳动力、厂房土地和资本,而在另一侧这是产品输出给客户,那么企业本身能否信息化呢?

我们一般称做企业信息化的企业为管理软件公司,比如各类ERP厂商,一些领域专业化的软件比如HR、CRM、MES,也有一些行业领域的专业应用比如医院HIS、电力调度等,互联网也催生了很多平台型的厂商,比如最近有点闹腾的滴滴。

回到平台软件本身的定义来看,来源于商学院的平台商业模式可能是最接近的定义------连接供销两边甚至多边的平台,也就是生产者与消费者的连接。作为协同管理软件厂商,我们提供的协同管理软件本质上还不能真正意义上称之为平台,因为我们不仅仅提供工具,还提供实施服务和运维,客户获得的应用价值是由厂商本身完成的,或者最多有销售端伙伴进行产业链合作,从而实现价值链的组合共同服务与客户而已,这里生产者和消费者之间的关系不是双边关系,更说不上是多边关系,而是产品销售的模式。

这带来一个很大的好处,那就是客户用什么、如何用,怎样用,其实是被厂商预先确定好的,我们提供产品,包括解决方案的能力(常常就是解决方案本身),客户选购买单,支付一定的费用后,由厂家或者厂家的代理合作机构给客户提供实施交付服务和运维服务,获取产品+服务的价值。客户的应用、需求其实是提前封闭的,这带来了极大的确定性-----业务是已知的。虽然流程、表单千变万化,但内容其实是非常一致的,如果一定要说有些技术和模式含量的话,这其实是一种分形的应用模式,看似千变万化,实则就是“流程+表单”,而其基础的底盘是组织模型架构,其展现是门户,不管是pc还是移动端,都是连接人与信息系统的门户。

当然,这是CAP之前的状况,而CAP之后一切都会发生变化,特别是在致远2018年推出CAP V4.0之后,这一切的变化将改变未来一个时期客户的应用方式,产品选购方式,实施交付方式,甚至包括销售是谁都会发生改变!

实际上,V5 7.0以后的CAP4推荐客户适应的“产品”并不是平台工具本身,而是基于CAP4的运行态下的“业务包”,这个业务包可能是致远原厂生产的标准包,可能是致远的实施、售前制作的业务包,也可能是致远的合作伙伴制作的“业务包”,而这些业务包本身就是客户使用的产品。

客户要在致远的商城去购买这些软件包,也可以基于致远的标准包进行改造,从而满足购买企业的个性化需求,这样基于“包+服务=定制业务”中的定制业务可能就很多,因为有了标准的基础包作为基础,因而定制的速度可以成倍于之前的业务包从头制作的模式,而这需要CAP4在运行态能够“自组织“、“自增长”成为可运行的一款“软件”。与传统的软件选购模式不同的是,先在致远的商城选购,再在致远的云联中心去认证,这听起来有点繁琐,而实际上这代表了一种未来的业务信息化定制的模式,也即大规模定制。如此繁琐的原因在于,这里上传到商城的业务包不仅是由致远原创,可能来自于定制合作伙伴,客户的IT部门,甚至来自于我们的客户的业务部门(当然是经过客户组织的授权,所以有严格的控制与管理),这就模糊了生产者与消费者的概念。成功企业的更佳实践本身就可以成为信息化的产品,通过业务包的导出、在商城的注册,从而参与交易,很可能一些行业的组织级客户能够将自己的信息化模型输出,既能够引领行业的发展,提高劳动效率和管理效率,也能够为组织创造价值:直接创造收益,这时候企业的IT部门不完全是一个购买IT产品和内部服务的部门,还可能是企业信息化模型的输出部门,成为销售部门。

这就是CAP4设计的初衷,也是致远从协同软件产品服务商走向平台服务商的重要的一步,V5作为基础的信息化的底盘,而CAP4生成的业务包成为在V5上运行的各类软件。

这会带来许多的变化,对于组织级客户来说,购买V5不仅仅购买了一套基础运行的办公系统(我们更愿意称之为协同工作系统),还购买了一套可以做业务协作平台的信息化运行容器,其上可以运行CAP4的业务包,无论是A6+还是A8+,都可以成为运行的容器。

这看似很小的一种变化,其后台是一个巨大的变化,也是致远历经多年业务定制的经验不断积累与发展的成果,可能会引起“0代码规模定制”的一种新的软件定制方式的潮流。

当然,这对于平台提供的软件开发商是一个巨大的挑战,因为这里所有的业务包其实是一种开放系统下的制造成果,这里的“业务包”几乎没有范围约束,与传统的“流程+表单”不同,这里的定义应该先从业务主题的开始,明确未来定义出来的“业务包”是做什么的,而后确认需要哪些基础数据做支撑,需要哪些静态表单去支撑业务协作,需要哪些流程表单解决业务活动,并且按照制度有序进行展开,而这里的业务成果也需要设置一些指标、进程的数字化展现,以实现“数字驱动业务”的过程的实现。

进一步,多个业务之间是需要连接的,每一个定制业务包不能再成为一个个信息孤岛(虽然几十年以来一直都是信息孤岛横行),并且这些业务包与信息化的基础设施比如组织的架构、人员是互动的,与组织的目标是融合的。在信息技术层面来看,这里的定制业务是能够在移动、PC多端可用的,并且业务场景也是多端互动的,进一步,可以通过多端构造复杂的复合应用场景。

而组织级的业务本身就是复杂的,这不同于B2C的业务过程比如销售过程、付款流程具有固定的模式,我们所需要做的就是让使用者体验更好一点,让企业的业务规范更标准化一点,学习的代价更低一点,数据资产能够长期保护,当然更好能够体现组织的文化,我们通常称之为个性的东西其实是企业文化展现的欲望的彰显(有时也是欲望的彰显)。

如果需要解决组织之间的协作问题,是否应该考虑组织之间的连接与协作呢?如果一定要说业务的话,是否可以连接合同,是否可以支撑跨组织的业务团队的协作模型呢?

实现这一切的集成架构、平台,CAP4已经准备好了,虽然依然还不完美,但我们已经正式推出的CAP4已经具备了以上的几乎所有特征。

我们需要改变的,其实是从产品到平台的不同的商业模式的观念的转变,我们需要学会从管理目标任务到设计目标任务实现的机制,从自己做到购买再扩展的转变,而制作基础的业务包,应该是有版权申明的,这符合信息规则的商业原则。

新的平台对我们的实施交付,生态体系是巨大的利好,其实也是一种挑战,因为我们需要转变,需要更换观念,而不仅仅是制作业务包的方法。

 


上一篇: A6+承载新的商业模式解析

下一篇: 业务定制平台的应用特征探索