协同OA未来5年发展趋势预计

申请免费试用、咨询电话：400-8352-114

从目前企业公司、事业单位、政府机构对管理信息化的角度来看，无非会集中在三大方面，即协同OA类、ERP类、BI类，通过这三大类的信息化推广，可全面部署内部管理信息化的支持体系。
随着信息化的全面推进，三大类的信息化，会你中有我、我中有你的趋势，但对于各阶层的使用者来看，可集中通过协同OA单一入口，灵活处理协同OA中工作内容、也可以及时处理ERP数据、以及对内部数据的数据报表分析。
三者关系可见简图：
 
以及对三者之间的关系，也会相互穿插关联关系：
类型 协同OA类 ERP类 BI类
协同OA类 纯粹、基础的协同OA应用，关注规范过程管理的控制，提升管理效率 在OA应用之上，能获取ERP中的业务数据通过多维审批 在OA应用(含本身部分报表)之上，能获取BI形成的报表数据展现出来
ERP类 在ERP本身数据管理基础之上，能获取OA中审批后数据进行业务处理 重点关注业务数据逻辑处理 在ERP应用(含本身部分报表)之上，能把BI分析后数据获取过来并反向影响业务数据操作
BI类 能获取OA数据来源作为分析渠道之一 能获取ERP底层数据来源作深化分析 强有力的后台多维数据抓取、报表制作、分析

所以，基于整体管理信息化的发展来看，对于协同OA未来的应用价值，会越来越至关重要，这也是目前市面上很多IT厂商会逐步切入来分担这块蛋糕的原因：
1、 协同OA产品服务方式
(1). ASP:
ASP即Application Service Provider（应用服务提供商），ASP模式就是集中为企业搭建信息化所需要的所有网络基础设施及软件、硬件运行平台，负责所有前期的实施、后期的维护等一系列服务，使得企业无需购买软硬件、建设机房、招聘IT人员，只需前期支付一次性的项目实施费和定期的ASP服务费，即可通过互联网享用信息系统。
众所周知，信息化包括硬件和软件两部分，对于硬件部分，大部分的中小企业都进行了IT产品采购并已建立了局域网，但软件部分的应用水平还比较低，像OA这类中高端管理应用，国内的中小企业一般都没有实施，或者实施得不完全。据有关调查结果显示，在中国上千万家企业中，有37%的被调查企业认为所需费用过高，有24%的企业缺乏专业咨询机构的支持协助，有8%的企业认为是内部人员素质偏低、意识薄弱，有5%的企业认为是实施周期长、见效慢，而这些都是阻碍企业有效实施0A的核心要素。据获，近期国内协同软件供应商泛普软件和中国电信面向中小企业客户联合推出基于泛普OA系统产品的商务领航泛普ASP平台。
ASP模式的OA相对于传统项目型0A，它具有进入门槛低、成本低、风险小、易实施、不需维护软硬件等的特点，很好解决了众多中小企业所面临的问题。从现有的600多万个客户中抽样调查发现，中小企业薄弱的地方不是外部资源，也不是市场应变能力，而是管理。泛普认为，无论是ERP、CRM、OA，还是SCM都是用来提升企业管理效率，梳理工作流程，整合信息流的。而对于那些以商贸为主的中小企业来讲，除了必须的财务软件和进销存软件之外，首当其冲的自然是OA，中小企业从OA使用中轻易获得大公司的管理方式，一旦应用，必将大幅提升企业竞争力和效率。
提ASP平台主要考虑了客户使用和实施这一块，在自定义流及个性化设置十分完善,除了满足大多数企事业单位在内部管理过程中的共性需求外，在租赁方式上，采用月租和年租的方式也体现了灵活的特点。另外，电信成熟的托管运营经验也将更大程度的保障客户的数据安全及无间断的在线使用。而泛普庞大的渠道体系也将在实际推广过程中对客户更好的服务。
近来，在线型的应用软件市场在近几年异彩纷呈，ASP模式在OA领域将有大有可为。不管最终是否象预言那样垄断市场，但对中国中小企业信息化的推进而言，无疑是一种强大的推动力。
(2). Saas:
SaaS是Software-as-a-service（软件即服务）的简称，它是一种通过Internet提供软件的模式，用户不用再购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件，对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要，近年来，SaaS的兴起已经给传统套装软件厂商带来真实的压力。
SaaS服务提供模式：
SaaS服务提供商为中小企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人员，只需前期支付一次性的项目实施费和定期的软件租赁服务费，即可通过互联网享用信息系统。服务提供商通过有效的技术措施，可以保证每家企业数据的安全性和保密性。企业采用SaaS服务模式在效果上与企业自建信息系统基本没有区别，但节省了大量用于购买IT产品、技术和维护运行的资金，且像打开自来水龙头就能用水一样，方便地利用信息化系统，从而大幅度降低了中小企业信息化的门槛与风险。
SaaS服务的优势：
对企业来说，SaaS的优点在于：
I. 从技术方面来看：企业无需再配备IT方面的专业技术人员，同时又能得到最新的技术应用，满足企业对信息管理的需求。
II. 从投资方面来看：企业只以相对低廉的“月费”方式投资，不用一次性投资到位，不占用过多的营运资金，从而缓解企业资金不足的压力；不用考虑成本折旧问题，并能及时获得最新硬件平台及最佳解决方案。
III. 从维护和管理方面来看：由于企业采取租用的方式来进行物流业务管理，不需要专门的维护和管理人员，也不需要为维护和管理人员支付额外费用。很大程度上缓解企业在人力、财力上的压力，使其能够集中资金对核心业务进行有效的运营。
(3). Mobile:
SaaS是一个为企业提供开箱即用的行业管理软件托管平台，支持企业个性化需求，应用随身定制、随需而变。
而Mobile将软件应用服务延伸到移动商务领域，通过定制手机应用，实现电脑和手机的双终端使用。用户只需要一部支持WAP2.0或者支持JAVA的手机就可以随时随地的访问OA。
(4). Sms:
Mobile用来扩展用户使用OA的一种途径，可达到类似通过IE访问OA使用的一样效果。
但Sms服务，可以直接把一些相关信息转换为文本信息，利用短信功能发送到用户手机上，并通过短信的简单回复可与OA系统智能的双向沟通，达到人机互动处理的效果。
2、 协同OA产品架构模式
(1). SOA(Service-Oriented Architecture)应用:
面向服务的体系结构（Service-Oriented Architecture，SOA）是一种 IT 体系结构风格，支持将您的业务转换为一组相互链接的服务或可重复业务任务，可在需要时通过网络访问这些服务和任务。这个网络可以是本地网络、Internet，也可以分散于各地且采用不同的技术，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。可以对这些服务进行结合，以完成特定的业务任务，从而让您的业务快速适应不断变化的客观条件和需求。
当在战略业务目标的引导下进行 SOA 实现工作时，可确保对业务进行积极转换，并能够实现 SOA 的好处，具体如下： IT 与业务的一致性 、IT 资产的最大化重用。
这些有助于确保在耗资巨大的 IT 项目中的投资能够给业务带来长远的价值。
那么，该如何步入 SOA 的领地，它又会如何影响您的业务呢？协同管理确定了五个切入点，可确保所进行的每个基于 SOA 的解决方案都能提供真正的业务价值。
协同管理可定义的五个切入点能帮助您和您的业务实现预定义的 SOA 解决方案，从而从中获益。这些切入点同时受到业务需求（人员、流程和信息切入点）和 IT 需求（连接性和重用切入点）的驱动。以下是五个切入点的一般描述信息：
人员：SOA 的这个切入点关注用户体验，以帮助生成调用和实现更好的协作，从而获得一致的人员与流程交互，提高业务效率。例如，通过使用 SOA，可以创建基于服务的 Portlet 来提高此协作。
流程：流程切入点可帮助企业了解其业务中发生的情况，从而支持其对现有业务模型进行改进。通过使用 SOA，可以将业务流程转换为可重用且具有灵活性的服务，从而改进和优化这些新流程。
信息：通过使用 SOA 的这个切入点，能以一致而可见的方式利用公司中的信息。通过在所有业务领域提供这个一致而受信任的信息，可促进企业各个领域的创新工作，从而更为有效地进行竞争。通过使用 SOA，可以更好地控制信息，而且通过信息与业务流程的结合，可以发现很多有意义的新关系。
连接性：利用连接性切入点，可以有效地连接基础设施，从而将企业中的所有人员、流程和信息整合到一起。通过在服务间和整个环境中实现灵活的 SOA 连接，可以获取现有业务流程并在不需要太多工作的情况下通过其他业务通道提供此流程。甚至还能以安全的方式连接防火墙外的外部合作伙伴。
重用：通过 SOA 重用服务，可以充分利用企业中已经存在的服务。通过对现有资源进行构建，可以简化业务流程，在整个企业内确保一致性并缩短开发时间。所有这些将能帮助您节约大量的时间和资金。另外，还能减少服务中的功能重复，并能获得使用企业中为大家所熟悉的经过验证的核心应用程序的好处。

(2). Web services/套件化:
实际上，Web Service的主要目标是跨平台的可互操作性。为了达到这一目标，Web Service完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。
长项一：跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。
举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。
如果中间层组件换成Web Service的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web Service，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web Service这种结构，可以节省花在用户界面编程上20%的开发时间。另外，这样一个由Web Service组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过Web Service把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。
长项二：应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。
例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web Service，订单执行程序可以把“AddOrder”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
长项三：B2B的集成
用Web Service集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。
Web Service是B2B集成成功的关键。通过Web Service，公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念，EDI(电子文档交换)早就是这样了。但是，Web Service的实现要比EDI简单得多，而且Web Service运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。不过，Web Service并不像EDI那样，是文档交换或B2B集成的完整解决方案。Web Service只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。
用Web Service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来，成为Web Service，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。
长项四：软件和数据重用
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。
当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
Web Service在允许重用代码的同时，可以重用代码背后的数据。使用Web Service，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的Web Service就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的We bService，这个Web Service就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。Web Service的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过Web Service“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用Web Service，把当前基于组件的应用程序结构扩展为组件/Web Service的混合结构，可以在应用程序中使用第三方的Web Service提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。
从以上论述可以看出，Web Service在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，Web Service根本不能带来任何好处。
短处一：单机应用程序
目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用Web Service，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然Web Service也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。
短处二：局域网的同构应用程序
在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。有趣的是，在.NETremoting中，也可以指定使用SOAP/HTTP来进行Web Service调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。
总之，只要从应用程序结构的角度看，有别的方法比Web Service更有效、更可行，那就不要用Web Service。