深圳oa软件系统

想要理解OA，就要先了解OA与BPM系统的恩恩怨怨。

我们现在看到的OA是中国人的发明，源于上世纪90年代，是一个“基于文档的流程管理加文档管理”的复合体（注意：是基于文档而不是表单），当然还加了一些无法成为独立系统的模块级应用，例如会议、计划等等。这个时代的主流是企业局域网和C/S架构，用户还未意识到他们存在管理需求，他们的要求仅限于“红头文件”的批、阅，于是第一代OA应运而生。它几乎是为政府/国企办文量身定做的，因此它们与BPM、KM（知识管理）系统在概念上有些相似之处，但应用领域几乎没有交集。

21世纪初，互联网和浏览器/服务器架构的普及带来了一个新概念━━企业门户，OA迅速将其收编，同时，OA厂商发现企业用户存在的管理需求，它们强化了流程管理的功能，将门户、自定义表单、流程引擎、文档管理作为核心，附加了极多基本无用的辅助功能模块，并极力包装成“BPM+KM+Portal”的合体，这就是第二代OA。虽然拿出任何一块，OA都难以满足用户的关键业务需求，但凭借价格（便宜到几万元）及部署（看似装上就能用）方面的极大优势，OA迅速进入企业市场，以“强化企业管理”之名，行“填补企业在行政办公软件方面的空缺”之实（上文中我曾谈到OA被很多企业视为“打杂”软件，其实与这个阶段OA厂商的自身定位有关）。对于荷包有限和IT实力不足的客户，OA可以轻易将BPM拒于门外；但孱弱的流程引擎和自定义表单，令OA在真正的BPM需求之前无还手之力。所以这个时代，OA与BPM的PK只存在于OA厂商的想象与宣传中，它们泾渭分明的用途在它们一踏上拳击场时就分出胜负。

如果说，21世纪初的OA其实是个七拼八凑的四不像，但经过十年的结晶，OA找到并实现了自己的核心价值：协同。协同的理念比实现来的要早很多，笔者在2008年曾经为金蝶的OEM厂商规划过产品设计理念，而在此之前，协同的理念就已经满天飞了。其实这些都是经过协同理念包装的第二代OA，产品内核没什么变化，只是更新了宣传册和PPT而已，应该算是2.5代OA，它们的价值在于引导客户将OA应用到业务领域。协同做为第三代OA的典型特征，是在不知不觉中完成的，到了2013年前后，主要的OA厂商都完成了对其产品的重构，将协同理念落实到产品技术架构的核心位置，与此同时，还在用户UI、沟通、移动终端等多个方面拓展协同的实际体验。自此，OA与BPM进入了全面角逐的时代━━在OA人眼中，协同是个涵盖并超越过程管理的概念；在BPM人眼里，OA是个功能繁多的山寨机。

到了第三代OA，确实值得比较一下OA与BPM系统了。

业务流程管理（BPM）可以归纳成一个类似PDCA的四步循环：“流程设计→流程执行→流程监控→流程优化……”，在这里面，OA几乎完全胜任的是流程执行、流程监控；部分胜任的是流程设计（缺失流程体系规划）；几乎完全缺失的是流程优化。流程体系规划、流程优化这方面最好的BPM系统当属ARIS，OA与之的差距之大，令OA厂商无心追赶。除此之外，市面上的主要OA系统都有一大欠缺，就是缺乏一个原生设计的集成开发环境，这导致OA的二次开发有一定的技术难度且无法平滑升级。

OA相对BPM的优势则多出很多，笔者列出感触最多的五项：

一是多出两大核心模块，门户、文档管理；其中门户可以跨系统聚合信息；

二是多了很有用的辅助模块，任务、日程、微博、会议等等；

三是模块的强关联，因此无需二次开发就能实现各模块之间数据的相互引用，例如流程引用文档；任务引用流程；

四是模块的引擎化，例如流程自动启动任务；任务自动触发流程；

五是搜索工具很强大，搜索范围可以囊括OA各模块中沉淀的信息（尤其是流程及附件）；

顺便简述一下OA与KM系统的恩怨：上个世纪，知识管理属于企业内部的封闭体系。建设KM系统，就是在组织内建构一个知识系统，让组织内的资讯与知识，透过获得、创造、分享、整合、记录、存取、更新、创新等过程，不断的回馈……专业KM系统确实会为大型企业带来强劲的竞争优势。但互联网时代，google和商业化的知识库网站已经彻底重新定义了KM系统，面对这个基于互联网的全球性KM系统，企业想构建一个价值高过它的封闭KM系统，势必需要极大的投入来维持一个专业的知识管理团队，还需要不断推陈出新激励员工参与知识贡献。与其这么复杂，不如换个角度，借助baidu、google等搜索引擎，购买几个专业的知识库网站服务，同时用好OA的文档管理和搜索工具，花少量的钱就可以取得八成的成效。（当然，OA厂商还需要大大强化搜索工具的命中率）

小编在工作的头十五年里，我很热衷于做一件事，不断试图用一张图阐释众多IT系统之间的关系，我们称之为系统蓝图。直到有一天，我开始质疑一件事：凭什么我认定IT系统之间的复杂关联能在一张二维图纸上得以展现。

2009年，我参加ARIS培训，老师跟我们讲过一个故事，他做过一个项目，客户最终把所有的子流程图整合在一张图纸上打印出来，数以万计的图形和连线贴满了会议室的整整一面墙。我当时一边想象，一边感叹，ARIS好强大。但在后面5年的工作实践中，我不断发现，这是扯淡，因为企业的流程体系是多维度的，只有对它进行切片研究时，才能在二维平面中展示流程。一旦你把它们整合起来，你只能在即损失信息又增加冗余信息的前提下，得到一个仅具审美价值的流程总图。

所以，不存在一张各系统平等前提下的系统蓝图，也不存在一张各流程平等前提下的流程总图，当我们试图理解OA与BPM的关系，就要明白，这与理解ERP与其它系统的关系，亦或xxx与其它系统的关系一样，是在假设只有焦点系统与其他系统两大系统这个大前提下试图得出有用的结论。有用的结论，仅此而已。

传统的IT系统蓝图中，二维的展现形式其实影响了OA系统所处的位置，当OA不得不与ERP、CRM、PDM、HR……等处于同一张纸上时，这些系统各自对应一块业务的特点也被赋予OA，于是OA被打发去承担这些高富帅们不干的工作：发新闻、存文档、行政审批、车辆管理、文具领用、图书管理……这一块业务的就是：打杂。于是OA很憋屈，还要被指责，真烂，连打杂都打不好。

事实上，这个杂还真不好打，事尽是些鸡毛蒜皮、婆婆妈妈，缺乏管理思想的光芒；使用对象却是公司的上上下下，众口难调却又要面面俱到。所以，OA一旦吊到这棵树上，基本上是死路一条。从OA与BPM的恩怨瓜葛深度解析OA的蜕变历程

想为OA找到一条生路，就必须脱离ERP一帮兄弟占据的系统蓝图，找到对OA更有价值的角度。在下图中我们可以看到，交通工具可以在不同层级上被展开到不同的程度，越往下区分越细致，越往上抽象程度高。而对于维护、航空管制、售票这三种业务，需要的抽象程度是不同的：我们很难想象售票业务需要根据具体的机型区分；但我们在维护时，肯定不能把波音与空客搞混。这就是我们要找的观察OA与其它系统的角度━━业务抽象的程度，例如：ERP中需要明确区分采购订单、销售订单等等，需要处理好不同的单据逻辑及彼此的关联；OA系统中不需要，它会将其统一为单据；BI就更抽象了，它只关心表头数据、明细数据及其之间的关系。

ERP之类的业务系统通常有三大弱项：

业务系统重结果轻过程。例如对于销售合同，ERP只关心最终的销售订单的数据被正确完整录入并有人审核过，但不关注在这个销售合同形成过程中可能产生的往复过程，不会记录下不同部门对这个合同的质疑或承诺等等。

业务系统缺乏过程管理的思想。例如一个销售订单从录入到审核可能经过不同部门多次退回复议，业务系统不会记录这些过程信息，从而无法有效督办或在日后统计分析并改善过程。

业务系统各管一段，过程无法跨越边界。例如一个销售合同引发的业务活动可能要贯穿CRM、PDM、ERP，并在PDM的多项非标设计、ERP的多种原材料采购过程中逐渐碎片化，导致用户很难通过三个系统的来回切换跟踪合同的执行。

OA的业务抽象度高，意味着它可以跨越业务特性来处理业务，当业务系统专注于对业务结果的精细化控制时，OA则能有效管理业务的过程。因此，我们的主张是：OA完善了业务系统在业务过程管理方面的三个短板，与关注结果的业务系统构成了完美解决方案。