确实没想到，绕了一圈，居然又回到了OA，当年从HW从来，就是不想仅仅只做给内部人用的产品，没想到兜兜转转，又回到了给“内部人做产品”的“老路”。
当然，就像先哲赫拉克利特说的——人不能两次走进同一条河流。既然是第二次走OA之路，自然对其认知也不会再停留在原来阶段，不论是公司的期望还是自我的要求，肯定都希望能站在更高点来做OA的全局审视与方案规划。
OA在IT行业是一个相对“古老”的领域，从IT诞生之初便是服务于此，最早的打孔机，就是为了提高工作效率而在在办公自动化这条路上往前迈出的一小步。然后从电子管，到晶体管，再到集成电路，随着软硬信息技术的发展，信息系统的服务能力在实现“给办公人员使用“的基础目标之后，迅速延展开来：有一部分人走的OA产品变现路线，例如微软的Windows系统与其Office办公套件；另一部分人走的信息共享路线，例如1.0时代的Internet，当然还有一部分人始终追求着软硬一体化的终极目标，只是受限于当时的硬件制造水平，单机算力有限，只能停留在PC端一体化的层次，即是已故的乔帮主他们。
随着基础网络设施的完备、单机算力的摩尔式提升，信息时代进入2.0时代，这个时代是真正属于Internet的时代，所谓信息爆炸便是从此时开始。这个时候单机OA虽然演化到了Web OA，但发展路线总体是比较纠结的，始终在效率与安全之间徘徊，虽然OA办公的形式从单机Windows客户端升级成了Web网站，但相比互联网用户类Web产品的蓬勃发展，总体而言还是进步甚微——即便有微软将Office Web化等类似的大胆尝试，但信息对于各个企业而言，依然是孤岛型的，毕竟受限于公司信息安全这个”紧箍咒“。期间微软打造的SharePoint企业内协同共享产品已经算是一种卓越的尝试，只是简单将Office能力照搬到Web上，功能虽然强大了但使用也复杂了，用户操作体验与学习成本大大增加，而且软件稳定性与性能也受限于当时Web1.0时代的Web技术水平——前后端未分离、集中式部署——终究是功亏一篑。
在OA还没来得及跟上互联网发展步伐的时候，互联网时代却已经突然跃进到移动互联网时代，昔日用户手中仅能拨打电话的功能机摇身一变，变成了智能手机，于是个人信息计算中心自然而然地从桌面搬到了手中，于是乎OA也被裹挟着“不情不愿地”进入了移动App时代。即便是到现在移动互联网时代已经进入了下半场，我们依然可以“放肆”地论断——OA依然没有完全准备好进入移动互联网时代，依然只是在Web OA的架构外面套了一层App的壳。
笔者做出此等判断，首先在于当前大部分公司OA的整体产品建设思路依然是基于Web门户的思维在做，并未充分认识到移动办公所能带来的产品质变空间。Web门户时代，受限于PC机人机交互方式的单一性（主要是鼠标操作），OA产品整体布局是二维平面式的，也即所见屏幕可视范围内的区域即是整体产品设计的最大范围，现在大量的OA门户依然是大量采用平铺式布局、长页设计等常见内容堆叠手段。
其次，对于全司IT系统的建设模式，依然停留在烟囱式建设模式，单立系统居多，即便有局部的中台建设思维的突破，整体IT分工模式依然局限于绝对的对内支持与对外服务这种。
以上两点本质原因在于公司IT人员特别是核心岗位人员的宏观产品思维没能跟上时代，业务人员的IT素养也并未随着移动互联网的到来而得到质变性提升。所以即便有了3.0的IT产品理念与技术能力，却也依然是基于2.0的思维层次在运用、在做系统建设。
而真正3.0时代的OA产品架构，首先应该是充分利用智能手机一直在线特性来打造消息驱动型OA产品解决方案，员工工作模式应该由以往的流程驱动模式转变为消息驱动模式，当然这对于信息产品的全局解决方案设计要求非常高，绝不仅仅是引入一个所谓NB的即时通讯产品就够的：真正的消息型OA产品，一方面能提供便捷的即时沟通能力，另一方面也应该能让IM作为最基础通用能力，充分融合到OA所有业务系统的任何需要交流沟通的功能角落，最终使IM消息中心既成为沟通交流的聚合点，也成为工作任务的汇聚广场。
其次，基于用户在线的特性延展，就需要将流水线式的单向串行工作模式，转变为实时并行的协同工作模式。构想一个很有前景的协作场景，过往我司的合同订立流程，合同信息伴随流程审批节点单向流动，途中任一个节点审批不过关，流程就得退回修改，再从零开始重走层层审批老路，即便前置节点已经审批过多次（虽然当前我们做了小幅优化，支持打回修改后直接提交到当前节点，但是又无法解决如果还需要前置部分节点人员来基于新增上下文做二次审核的问题），而基于实时并行协作模式的设计构想，应该是颠覆基于流程来驱动合同订立的串行任务式设计，改为在线共同协作编写模式，即由合同订立所有相关协作人员一同参与到合同的编写与调整、全程修改留痕，同时在协同编写过程中应该可以基于此文档进行工作群级别的信息即时沟通。
第三，应充分利用移动手机的语音输入能力，基于智能语义识别技术叠加企业全局搜索能力与移动端全局路由架构，可轻松打破二维屏幕视域限制，实现1 To N的增维式产品设计。
第四，对于1 To N的能力，还必须要提现在已经运用成熟的基于智能推荐的千人千面。这同样是一种非常值得赞赏的主动服务型产品内容呈现方式。稍显美中不足的是，当前大部分所谓智能推荐基本都是基于对单体数据的模式识别，而对于连续内容的关联识别方面做得相对欠缺。
眼下火热的钉*、*微、飞*等To B端互联网办公产品，勉强算2.8代产品，有优秀的即时通讯体验与部分浅度协同工作体验，但是寸有所长、尺有所短，正是由于其诞生于互联网行业，其对移动端的体验打造非常极致，但是对于OA业务的理解深度都相对欠缺（第一个集中体现便是对PC端工作门户的选择性忽视），纷纷将其丢给下游ISV厂商来做，当然这也可以说是”建生态“。 当然这样最容易把平台做大、最容易挣钱，从企业盈利角度来讲无可厚非。但同时也就没法使产品本身充分深入OA业务，做出全业务整体解决方案级产品。
对于大中型企业、特别是有多年业务系统（大部分是PC端Web系统）建设积累的企业而言，需要的是能覆盖从前到后全职能端的整体解决方案，而不是先天性缺一块的半面琵琶。特别是通用协同办公能力（即时通讯、邮件、日程、流程、待办、文档、会议）必须是能覆盖全端、并能全面支持业务系统集成的，如此才能满足各类用户需求，同时才有可能让这些通用能力与各类业务系统进行深度融合，形成深层次的业务协同。
当然，这很难，业界目前也没能出现这样一款完美的产品，互联网办公类产品偏重基于即时通讯的协同沟通平台的建设，业务深入丢给了下游厂商；传统OA厂商能深刻理解业务，但是整体交互体验比互联网产品确实还有不少差距。如我司这类情况，目前而言，相对现实的选择是综合两类选择，在选购一家能支持Web端的互联网协同办公产品的基础上，再选取一家真正有OA业务积累的大型OA厂商来做全局OA产品与体验升级，后续再谋求通过自定义开发的方式将通用协同办公能力融入各业务模块。如果退而求其次，那就是牺牲部分互联网产品体验，选用一家具备协同办公能力的传统厂商，来实现OA的整体平稳升级，后续再考虑在此基础上进行体验优化。直选互联网产品+各类下游ISV厂商的方式基本可以不考虑，所谓ISV厂商无非都是一些有局部特长的小企业，再多建那么多烟囱，既增加交付风险，又增加了后续服务中断的风险，完全没必要。
聊完3.0的选型，似乎OA已经到头了，但是一切其实才刚刚开始，经过笔者这一年多的生产实践，有一种趋势已经愈发明显，那即是“通用服务能力上云共享”，笔者称其为OA的4.0时代。
通用服务云化分层架构图
现在都流行管理扁平化，其实在笔者看来，管理扁平化并不是简单的穿透式管理（穿透式管理会让中层管理者很难受，容易导致团队分裂，最终导致团队整体执行力下降），而应该是各级管理层对公司业务的深刻理解之后，依托自身专业能力或者信息化智能管理手段（更多的是后者），使其管理半径达到成倍增长，从而实现管理人员规模的缩减、中间流转节点的压缩之目标。乔布斯能在苹果公司实行扁平化管理，并不仅仅在于其专业产品能力，还在于其在苹果公司浸营多年、对各类业务有足够深刻的了解，如此才能收放自如。能达到此等程度者少之又少，不过，通过管理信息化效率提升来实现管理半径的扩展显然是非常现实可行的。
而管理信息化的扩展，显然就是OA信息化建设的进一步扩展，在现代企业中，基于由外至内的内外服务一体化拉通建设，可有效实现过程环节的优化裁剪，进而实现作业自动化、高效化，节约中转环节的人力成本，增大单人作业面与作业量，从而实现管理效能的提升，最终促进展业效率的质变性提高。
这种一体化打通，首先受益方向便是业财一体化，毕竟公司是以盈利为目的的，通过业务与财务的拉通来实现经营分析的快速呈现，有助于公司快速调整经营策略、以更快适应市场的变化。
其次在于服务的边界模糊化、云化，在2.0乃至3.0时代，对内服务与对外服务是泾渭分明、绝不允许破界的，但是到了4.0服务云化时代，内外服务呈现出一体化趋势，举个最常见的例子——各类线上化签约流程，一头是用户签约，一头是公司盖章，基于同一个线上化签署业务流程、共用同一份电子合同、调用同一个电子签署微服务，最终完成双向签约。在这过程中，流程服务、电子合同管理服务、电子签署服务已经没有内外之分了，而如果再加上区块链的过程见证，本身就要求全流程一体化留证。
再以笔者经手的直播平台建设为例，平台建成后，既会对外部客户提供展业服务，同时也会为内部员工提供内训服务，显然不会因为内外服务之分而创建两套平台系统。
因此，内外服务一体化，既是信息技术发展到微服务阶段的技术必然，也是公司扁平化展业的竞争力提升诉求。当然，这类转变最关键也最难的还在于信息技术部门关键角色的管理思维转变、整体产品解决方案能力的提升。
服务云化既是一个中台制霸天下的时代，也将是基于业务领域的服务百家争鸣的时代，而各条业务线的
