BPM- Eteams体验报告

协作移动办公平台，从老版OA替换为BPM。OA是国内特有的企业系统，为了满足公司粗放型管理。先富起来的企业，早早搭建信息化平台，第一个企业级系统就是OA。但正因为上的早，沉淀了十几年的管理逻辑，OA变的十分冗余。此外，用户习惯了OA的操作逻辑，特别是老员工，本就难以改变其习惯，对于OA有着坚定地执着感，除了界面他们承认新系统变得简洁外，反认为新系统不如OA好用。经常在讲一句话，用惯了牛犁地，给他开拖拉机反而不适应。因此早用上了OA，反而不是好事，在信息化建设上，可能存在后发先至的情况。

回到我司，幸而sponsor态度坚决，BPM项目进程还算顺利。BPM本身适合迭代式快速上线，先把平台搭起来，功能增量往里搬。不同于业务性管理系统，为了保证切换后业务流畅通，以及双系统并准数据源不唯一情况，无法按照MVP原则上线（或者说业务系统的MVP是在保证架构合理以及业务流跑通前提下） 。平台型及工具性产品，在传统型公司，也适合以敏捷方式开展。

OA与BPM的本质区别是什么，没找到明白的解释。打个比方，也许类似信息化与数字化的差异。OA从行政审批起家，发展到各个部门，不同部门基于内部管理要求，对IT提需求。企业内部不同部门、不同领域，有着不同的流程定义及操作规范。而BPM注重端到端的业务流程，连接上下游，保证与其他应用系统的集成性。功能上，由于技术的更新，同时BPM做流程的专业性，支持复杂的审批场景，如加签、征询意见、超时跳过等，在BPM可通过配置实现；善于兼容端到端的复杂流程，对于同一父级不同流行的业务流程，OA往往要开发不同功能承载，而BPM可以用一个大流程兼容；可方便业务用户查看流程配置，梳理流程，进行优化改进；报表监控，将流程绩效指标要求落实到系统中。

低代码开发，托拉拽方式配置流程，类excel操作创建表单，交由业务部门关键用户完成。理念很美好，实际难落地。一是业务太“笨”，培训的成本还不如技术人员直接完成开发。而且即使教会了这位用户，没有边际效益的，关键用户只会负责部门内部流程，没几个的。但凡涉及跨部门流程，还是要找IT实现。公司弊端在于流程没有owner，或者owner不知道自己是owner，更别说流程manager。因此没法由manager配置流程；二是无法保证功能、样式的统一，例如要求驳回必须填写备注，而同意默认意见为“同意”。表单、头信息在顶部，行信息在中部，审批人信息在尾部；三是容易造成流程的部门墙，业务变成流程管理员，缺乏业务整体运营考虑，局限于本部门或业务的要求。

核心功能点

• 待办事宜：按照类型进行筛选，倒序排列

• 已办事宜

• 我的请求

• 审批

  • 同意/驳回：可设置驳回必须填写审批意见

  • 转发：转给其他用户，仅供查阅。可用于意见征询

  • 转办：将该节点自己的审批权限转给其他用户

  • 传阅：转给其他用户，仅供查阅。目标用户查阅后，会给使用该功能的人通知，对方已查阅

  • 引用：基于审批意见回复

• 相关信息查看

  • 流程图：全流程图及各节点审批人。点击节点，显示该节点未操作者、已查看者、已操作者

  • 流程状态：各节点执行情况，审批耗时

  • 相关资源：相关联的附件、文档及流程

• 提交流程：提交后，集成IM消息推送，可直接点击完成审批

• 流程代理：委托他人代为处理，可根据代理人、代理时间段及流程类型范围设置。

• 流程督办：申请人可发起督办，通知当前节点人处理，同时流程状态中，会记录该条督办。

• 流程监控：按照自定义查询条件，监控流程状态。

• 报表分析：选择表单字段，自定义逻辑创建报表。最喜欢审批效率报表，以各种维度排序审批时长。哪个人处理审批花的时间最长。例如大部分员工在意的报销流程，一直被诟病，if you don't measure, you can't manage.

• OA应用模块。类似商城APP，IM的工作台，大同小异。要与专业系统做好定位，BPM不能太臃肿，重蹈OA的问题。

• 文档管理。对流程中的附件、文档归档，以及模糊搜索查询。