平台 or伪平台? ——平台型OA选型误区

良莠不齐、参差错落的OA、协同市场本就缺乏统一的行业规范,而不少纷纷号称“平台型OA”、“平台型协同”的软件厂商更是让众多客户企业在选型时倍感无措,极易陷入误区;针对这个问题,笔者采访了国内平台型OA软件主导厂商——飞企软件产品负责人,从专业技术角度对“平台型”、“伪平台型”协同进行深度类比和详细阐述。

近年来,基于平台型OA技术架构衍生出的平台型协同迅速发展,其功能在传统OA应用的基础上更增加了业务运营及协同应用,涵盖功能更为强大,因此也备受越来越多大型企业所青睐。然而市场上相关产品名目繁多,应接不暇,使不少企业客户在选择的时候,就容易被众多概念所迷惑。如何正确认识平台型协同,不要走入误区,本文和读者做一番探讨!

平台型OA系统最大的特点是整个系统构建在通用的业务支撑平台上,使整个管理系统拥有强大的定制开发优势,易扩展、易集成,提高软件实用性。本文就平台型协同管理系统的特征进行分析,解释概念,供大家参考。

误区一、技术平台与业务平台都是一样的?

当平台型协同出现在市场的时候,获得广大企业的认可,其他的传统OA厂商也纷纷宣称自己具有平台,其实是混淆概念,所谓的平台,其实是一个技术平台,在技术上处于一个低层次水平。市场上很多软件厂商所使用的现有java平台或者.Net平台,构建其整个系统,其实并不具备核心的技术,其基本特征就是不具备插件模式,难以给第三方软件开发商进行业务开发。这类平台构建OA系统常用的功能,并产品化,借用技术架构使整个系统拥有一定的定制、扩展能力,通常是预留很多API接口。

业务平台,架构在技术平台之上,使用模型驱动开发,实现业务与技术分离,有统一的元数据建模平台。具备积木式的可插拔业务插件,可以交付给第三方进行业务开发,具备统一开发规范。业务平台是平台中高层次技术,拥有自己核心技术。业务平台厂商往往具备一个完整的产业链,自己业务插件商城或者第三方合作开发商。真正的平台型协同,所有的模块都是一个个业务插件,具备可插拔,可移植,可配置,可监控的特征。并且插件与插件之间可以相互调用和整合;在业务开发上不受接口所制约,能开发出各种各样的业务系统。

我们通常认为平台型协同是指使用业务平台技术建构,这两者天差地别。

误区二、表单技术就是业务开发?

协同管理平台,可轻松维护表单或随时扩展业务需求应用,都少不了这个表单工具,表单建模不仅是所有系统的数据核心,也更是整个协同管理平台的核心所在。但是就可以说:拥有表单技术就能号称平台吗?答案是否定的,这是一个对平台型协同的最大误区,使用表单技术来开发业务系统,也许简单数据少、业务逻辑简单的系统,还是可以胜任,但是往往在项目验收之后,才发现系统运行越来越慢,操作越来也难用!表单技术越来越傻瓜,基本客户通过培训后就能使用,使用表单不需要了解表结构、索引、排序等等开发术语,更不需要了解数据流,业务流之间关系。当数据还少的时候,感觉挺好,但是随着业务深入应用、运行时间和数据越来越多,系统性能就受到挑战,并且业务发生点改变时候,用户的工作效率也变低而且感觉系统很笨。

真正的平台型协同,必须具备数据建模、功能建模、表单建模、工作流建模、报表建模、性能监控等工具,能随着运行时间和数据的增加,可以建立索引,优化系统;通过各种工具的配置,维护数据关系;通过功能建模,改变输入方式,调整业务模型;通过报表建模,分析业务数据,甚至使用BI工具进行数据挖掘,建立分析模型。

业务功能,并不只是收集数据,展现数据。还必须可以流程再造,除了工作流外,还必须有业务流的支撑,必须做到更快捷、更自动、更智能。表单只是解决人与人的交流,但是只有平台的支撑,才能真正做好业务。

误区三、数据融合就是导数据?

近年来,随着信息化的逐渐推进,一些企业内部往往上了很多的系统,只是根据当时各部门情况进行部署系统,使得各系统“各自为政”,没有形成统一的平台,从而让信息成为“孤岛”。一些号称平台型协同的厂商纷纷出招,宣称已经解决“信息孤岛“;但是,项目上马之后,给用户就是一个导数据的功能,将其他系统数据导入到协同,可以供用户查询。这就是所谓的打破信息孤岛吗?不是,数据融合,不是导数据。

这种导数据建设方案只是解决数据展现问题,是融合的第一层。只要往系统中集成一个报表工具就已经达到这个目标了;数据展现,也往往和门户技术进行配合,可以将其他系统的数据通过分析后,展现在门户的小窗口上,用户可以通过链接,单点登录到其他系统进行业务操作;融和的第二层次是数据互通,系统的数据可以和其他系统数据进行共享共用,提升工作效率;比如在ERP系统上发起表单,然后流转到协同系统中进行审批,再将审批结果返回到ERP中。在这个层次上,操作是一体化的,在整体效率上提高数据的使用率和及时性,能更好的给企业领导提供决策依据;企业与上下游供应链的数据整合,是第三步的融合,这里包括了业务模式共享,关系合作,数据安全等等问题,比如:如何与下游共享产品信息、共享客户信息、如何一起项目协作等等;这个层次的数据更加集中,业务效率更高,能加智能化。这层次融合需要行业龙头、或者政府牵头, 搭建数据交换平台,并建立公有云或者私有云服务。

能够实现上述这三个层次的协同才是真正的平台型协同,平台之上,业务融合,平台之下,数据融合,并不只是简单的导数据!

误区四、平台型协同等于项目型OA?

平台型协同的柔性,具备功能开发和变更配置化的操作方案,对技术人员要求低,对需求变更的响应速度更快,极大的提升了业务系统的敏捷性,灵活响应系统运行过程中的各种业务需求和变更。但是,很多人都笼统认为购买平台型协同等于定制开发,属于项目型OA范畴。只有伪平台协同才具备这种特点,用户要什么,我就开发什么,号称DIY协同,以满足用户需求为主要目标。最严重的后果,实施前系统和实施后的系统变了样,变了味,系统改来改去,运行也就不稳定了。

平台型协同就不是产品吗?平台型协同就没有管理思想吗?不是的,平台本身就是一个产品,也是可以容易安装,容易实施的。为什么需要平台型协同呢,著名战略问题权威威迈克尔.波特指出:对公司下属各业务单元相互关系的管理,是公司战略的本质内容;协同是一种战略高度的安排,以管理思想为核心,业务深度融合为基础的整体运营管理平台。所以,平台型协同是含蕴这中国文化的“中庸之道,兼容并蓄,和而不同”智慧:在实施时候,具备丰富的组件、组织模型、工作模式等协同思想,并能结合企业本身文化进行融合,达到改进组织效率、推动企业生态的进化。

真正的平台型协同,强调平台,不是像某些协同厂商强加给用户的管理思想,而是融合企业文化打造具有特色的管理思想,才真正彰显企业的核心竞争力!

误区五、中小企业不需要平台型协同?

这种观点认为,中心企业使用固定的功能模块就可以了,需要平台干什么呢?尽管产品型OA曾经在协同领域内风光无限,但并不适用中小企业实际运营却是不争的事实。产品型OA被引进中小企业后,带来的通病是策略不清晰,落实不彻底;用来用去,就那么几个模块,其他的业务系统,也变成售前的忽悠,就是个摆设,不符合企业实际情况。此外,产品型OA还会因为僵化的业务应用、隔绝的数据信息、离散的业务过程,给中小企业造成数据孤岛、流程孤岛,在其发展的道路上套上沉重的枷锁。

中小企业的首要特征:“小”、“灵”、“快”,不管业务还是组织,在高速发展的道路上,变化总比计划快,并且在关键变革上,更需要协同思想支撑。真正的平台型协同全面抽象管理业务要素,以“人”为中心,业务流为纽带,组合、关联各关键要素和经营资源;“与时迁移,应物变化,立俗施事,无所不宜”,这时候,平台型协同以其管理思想,结合企业实际情况,引导企业方向,帮助企业走出困境,通过组织变更、流程重组等手段,达到企业高速发展的目标。

如上所述,平台型协同是以管理思想为核心,业务深度融合为基础的整体运营管理平台,规范组织中的制度、事务和人文,激发员工创新精神和集体智慧,让各级管理者及时掌握各纬度决策信息,支持企事业单位在快速发展过程中实现顺利变革。作为协同信息化整体解决方案提供商,飞企FE业务协作平台属于第四代OA,即“平台性协同”,它打破了传统OA的概念和模式,具有可视化、可自定义的表单与工作流配置功能,能快速构建和落实组织制度,实现高效协作、资源共享、移动办公等综合事项,并具备强大的二次开发及信息整合、扩展功能;同时,真正能与PM、CRM、ERP、财务、HR等各类业务系统进行深度整合。其强大的“平台性”、“融合性”功能已在业内件数千家政企事业单位客户中得以成功实践运用。

相信随着市场需求的不断深入和扩张,真假“平台型”协同的面目都将更为清晰可辨,其以“人”为中心、“业务流”为纽带的理念将会进一步得到延伸,真正发挥其作为企业实施战略信息化最佳平台的强大功能,为客户创造更大、更长远价值。

创新升级——FE业务协作平台与传统OA的差异

比较项目

FE业务协作平台

传统OA

系统架构

三层平台架构;B/S结构;提供可配置的开发组件,支持不同应用组合;具有标准化的整合机制,全面支撑跨平台、跨数据库的应用。

二层技术架构;B/S结构,少数的使用C/S结构,功能模块通过代码开发而成;只有少部分厂商的支持跨平台、跨数据库。

系统特点

产品化和基于平台的定制开发,以用户需求为中心,能快速响应客户个性化需求。

产品化为主,定制开发难度大、成本高;或项目模式的定制开发,但周期长、风险大、成本高。

系统功能

涵盖传统OA标准功能,内置的平台围绕用户需求进行不同程度的个性化,周期短、质量高,大大提高实用性。具备良好集成性,可以作为基础的框架平台。

OA标准功能,功能看起来全面却不深入,业务功能比不上专业的ERP,个性应用不足,二次开发困难,集成性差。

二次开发

基于平台的二次开发,大大降低技术难度,降低实施成本和风险,无需开放源码,最终用户可以使用平台进行定制开发。

需要开发源码,二次开发周期过长,二次开发一般需要厂商进行,对厂商依赖比较大。

生命周期

提供软件运行和开发的基础框架平台,扩展性好、整合性强、保值性高,能伴随企业发展,因需而变,软件使用年限较长。

一般使用年限不长,往往因为无法满足企业成长需求而停用。

原文发布于微信公众号 - 人称T客(Java_simon)

原文发表时间:2014-10-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ThoughtWorks

TW洞见 | 徐昊谈结对:要更快的编码,还是要更快的交付

1. 我今天有几个问题想咨询你一下,首先第一个问题就说,你在,以敏捷教练来帮助团队实施敏捷的过程中,最经常遇到的一个团队发现的问题是什么?就说因为我这边也待过一...

32170
来自专栏云计算D1net

云计算集成七大关键问题

根据一些独立分析师的评论,我们发现将云应用同数据连接在一起时,担心集成问题是现在市场上主要的错误之一。 曾有分析师指出,如果一个云计算策划者或者架构师首先关注的...

423120
来自专栏WeTest质量开放平台团队的专栏

解决虚幻引擎4手游开发难题,腾讯WeTest携GAutomator、APM亮相UOD大会

18530
来自专栏云计算D1net

2015年预测:海量数据、隐私和混合云

存储资源日益减少 对于大多数人来说,预测未来是非常困难得。但是人们总是喜欢关注未来会发生什么事情。在IT领域,人们同样喜欢关注趋势发展。到了2014年底了。又该...

367100
来自专栏云计算D1net

基于云计算的软件是否适合企业不同需求?

23240
来自专栏SDNLAB

企业网络战略之边缘计算:细数它的5大优势

对于希望超越传统基于云的计算架构的限制的公司而言,边缘计算已迅速成为热门。虽然企业级数据中心依旧在现代网络中发挥重要作用,但物联网设备提供的能够在更接近源的地方...

11820
来自专栏SDNLAB

边缘计算的未来:不仅仅是物联网

什么是边缘计算,为什么我们有这样的结论?为此,我们首先需要了解云和SaaS的发展方向。

13530
来自专栏Web项目聚集地

Java程序员转型大数据可靠吗?附资源

如今大数据发展的越来越成熟。各大企业纷纷成立大数据部门。尤其BAT等一线互联网公司每天处理的数据量都是TB级别。大数据部门已成为这些企业的核心部门,数据已成为企...

13920
来自专栏DevOps时代的专栏

浅谈海量平台的质量管理

49430
来自专栏CSDN技术头条

推荐系统正成为所有领域的一种标配

近段时间团队在扩建算法小组,首当其冲的岗位就是推荐算法工程师,然而历经一、两个月的招聘后,却发现一个事实,推荐算法工程师太难招了。

11230

扫码关注云+社区

领取腾讯云代金券