一、从OA到BPM，流程线上化的系统载体我们对流程上线系统的最朴素的认知可能来自于OA系统，在OA上填单子、领导批流程，可能也是我们对流程实现线上化最通常的印象。这是一种工作流（Workflow）管理技术，即按照定预先定义的规则，使得文档、信息或任务能够在不同的参与者之间传递执行，从而实现全部或部分经营过程的自动化执行，达到提高工作效率、降低生产成本的目标。实现工作流管理技术的系统，我们称之为工作流程管理系统(WfMs)，从20世纪70年代中期开始，工作流就已经出现并运用于办公自动化领域，工作流程管理系统配备了大量功能，旨在通过自动化重复任务和提高整体效率来优化工作流程。工作流管理系统一般包含以下功能：流程的图形化展示：流程的流转过程可以用图形化的方式展现，让流程负责人和节点处理人员快速了解流程运作的现状；流程可以通过流程面板分类、分级地形象化展示，方便员工找到对应的流程。流程的可视化配置：利用可视化工具快捷地配置新流程，实现企业的随心应变要求；允许对已经运转的流程中的任务进行添加、删除和调整任务次序等操作，以适应企业动态的变化。需具备“同步看、顺序批”、退回、新增节点、授权、统计等功能。支持一些常用的审批功能：审批代理，全权代理或者仅代理某一类业务或者某个公司下业务；跳过，同一责任人跳过（前跳后审、前审后跳）、空责任人跳过；撤回，审批撤回；授权交办，可设置仅允许交办1次或者允许交办多次；流程传阅，单个传阅、某类型下批量传阅、某责任人下批量传阅等；打回重走，由审批人决定是否重走或者打回后必须重走。流程审批节点提醒：支持利用短消息和邮件的形式向流程审批节点的负责人发出提醒；在信息系统中每个人的工作任务栏里自动添加事件的提醒方式。流程引擎的其他功能：组织架构与流程关联，实现组织架构变动流程自动调整；和文档中心进行关联，能够勾连文档中心的文档或者将流程中产生的文档自动存储到文档中心的相应位置；流程可以和项目、人员等卡片进行勾连，便于从多维度统计和分析；可以设定流程的自动触发条件（时间或者进度等）；记录备案，并能在任何时候对流程历史进行追溯。各种审批记录、重要的操作、关键性的决策都需要长期保存，以备查询。除了OA，大家可能还会听到过BPMS这一概念，即业务流程管理系统。二十一世纪初，BPM正式从外国引入中国。在当时，BPM是非常专业的产品，复杂的状态机、活动、事件等概念充斥其中，许多BPM产品的用户界面不够友好，实施和配置过程往往需要专业技能，这增加了使用门槛并可能降低用户采纳率；灵活性不足也是一个显著问题，系统难以快速适应业务变化和新需求，对非标准流程的支持有限；与现有企业系统的整合困难可能导致数据孤岛问题，影响整体效率。更重要的是高昂的实施和维护成本可能超出中小企业的预算。BPMS和OA的核心都是流程引擎，通过流程引擎实现流程的线上化和传统的将业务流程直接写入程序中的开发方式相比具有明显的优势。因为业务流程是经常发生变化的，而业务流程的改变意味着程序的改变，对于传统的开发方式来说，这是个费时、费力和容易出错的过程。而基于流程引擎，业务流程系统把业务流程管理与应用系统分开，使得业务流程的调整不受应用功能的影响，改动的成本快速下降。根据哈默的理念,一个理想的BPMS应该具有以下特征: 彻底的流程重塑:哈默强调不应该仅仅自动化现有流程,而应该从根本上重新思考和设计业务流程。BPMS应该支持这种彻底的变革。 以客户为中心:流程应该围绕客户需求来设计,BPMS应该能够捕捉和响应客户需求的变化。 打破职能壁垒:BPMS应该支持跨部门的流程管理,打破传统的部门界限。 决策支持:系统应该为流程中的决策者提供及时、准确的信息支持。 持续优化:BPMS应该具备持续监控和改进流程的能力,支持流程的动态优化。 工作重组:支持工作任务的重新组合,让员工能够承担更有价值、更具挑战性的工作。 技术驱动:充分利用现代信息技术,如人工智能、大数据分析等,来支持流程创新。 敏捷性:能够快速响应市场变化,支持企业的战略调整。 文化变革支持:BPMS不仅是技术工具,还应该支持组织文化的转型,促进创新和持续改进的文化。 价值导向:系统的设计和实施应该直接关联到企业的核心价值创造。可以看到，哈默所认为BPMS不仅仅是一个管理工具,而是企业彻底变革的催化剂。在他看来,成功的BPMS实施往往伴随着组织结构、工作方式和企业文化的根本性变革。理论上，BPMS要比WfMS高一个段位，功能上会涵盖设计、建模、执行、监控和优化各阶段，系统性的从业务流程的生命周期考虑，帮助管理一组动态的流程集合，从战略的层次对其优化，使它能够真正表现企业自身的业务操作走向并实现其目标。但是在实践上，往往难以发挥其真正的价值。图表54BPM和OA的异同某企业为加强流程管理，斥巨资上线了一套国外的BPM系统，但实际上只使用了流程引擎的部分，BPMS变成了一个大号的OA，除了能够通过定制化的开发解决一些较为复杂的流程审批逻辑之外，流程的设计、监控这些环节的功能没有用起来，和OA并没有本质上的区别，甚至实现流程的效率还要低一些（因为页面和流程逻辑需要定制化的缘故）。从PDCA的角度来说，我们需要在“流程线上化”这一工作之外，补全计划、监控、调整环节，“流程线上化”主要依靠的是流程引擎的功能，如果将计划、监控、调整这些功能也通过IT技术实现，就形成了BPMS。例如欧洲的某A系统，其一大特点是综合组织、数据、流程、功能、产品和服务视角建立业务流程架构，在功能上除了设计器、执行器外还有流程绩效管理器、审计管理器、业务流程优化器等一系列服务于流程全生命周期的工具，这些功能的组合产生了一加一大于二的效果，实现了BPMS对OA的第一层超越。另外还有BPMS在企业整体IT架构中的位置，我们使用OA的时候，实际上更多的还是实现办公流程的自动化，可以简单的将它认为是某种“办公活动的系统”，与其他业务系统之间是平行的关系，但是BPMS需要成为一个“做系统的系统”、“承载所有流程的平台”，它会位于其他应用系统的下层，也就是所谓的业务中台的概念。这既不是一个新鲜的概念，也不是一个新鲜的技术，实现起来需要解决系统集成的成本效益问题，以及用户体验的统一性问题。有的企业为了追求形式上的一致性，将所有的系统中的流程通过BPMS重做，实现流程在BPMS单一系统上的统一，这倒也大可不必，笔者更加倾向于将一个个的独立的业务系统（尤其是外采的商业化套件）视作一个个相应的流程域，BPMS需要对穿越流程域和其他流程域需要进行连接的流程进行改造，对其他细枝末节的流程只需要统一入口和体验即可。实际上经过上面的讨论，我们不必纠结于OA和BPMS之间的概念上的差异，我们需要明白的是我们在流程管理方面的需求，让流程能够在线跑起来，免去纸质文件的传递是第一层次的需求，这产生了WfMS；能够分析流程的数据，对单个工作流进行管理，这是第二层次的需求；能够从企业架构的角度对流程进行线上建模和管理，这是第三层次的需求；能够发现高层级流程的（Process层级而非Workflow层级）问题，进而促进流程优化再造，这是第四层次的需求。这些需求也许通过某个单一的套件实现，也许通过多种工具的组合实现，这都可以称之为BPMS，实现业务流程管理的系统。二、五阶法流程线上化回到我们本节的目的——流程线上化，不管是使用OA还是使用BPM，将业务流程线上化的方式和路径其实大同小异。根据笔者的实践，将流程线上化的过程分为建立线上化计划、需求梳理确认、系统实现、验收交付和持续跟踪5个阶段。图表55流程线上化的流程示意Step1：建立线上化计划单条流程的线上化可以跳过这一阶段，直接从需求梳理确认开始，但是如果要推动企业层面的流程线上化，那么这一步必不可少。笔者曾经忽视了这一阶段，走了不少的弯路。逐一地推动流程线上化当然没有错，但最大的问题在于难以获得高层级的支持。拿由某主管负责的三级流程，找部门负责人也就是二级流程的责任人要资源，这里面就存在错位，这不是说自下而上的视角是错误的，但必须要和自上而下的视角结合。也就是说，我们向某一客户（内部的或外部的）提出流程线上化或者优化再造的建议的时候，总是跟随着客户的视角，从他/她的全局找问题，打包形成解决方案，而不是今天提出一条具体的、低层级的流程需求，明天又提出另一条。举个例子，某公司，我们经过和人力资源部门长时间的沟通、调研，发现： 入职审批流程未严格执行，部分分公司存在先进人，后补流程的情况； 员工入职后第二天才能拿到电脑，第三天才能开通系统账号； 对新入职员工缺少相应的培训和引导的过程； 离职时未按照规定执行离职面谈的过程； 某职场社交平台上出现一些离职员工的负面言论。这时候，从流程管理的角度，如何提出一个解决方案？我们可以分别从各个流程的角度，指出需要优化的举措，或者，我们可以从这些表象上升一层，看到这里存在新员工难进、难融的问题，显然，从后者的角度提出解决方案能够更容易获得资源，业务部门也更容易配合。我们应基于流程清单，建立我们的流程线上化计划，分块、统一的提出建议，这样才更便于获得预算和支持。图表56某公司流程清单示例Step2：需求梳理确认流程线上化过程中应当同步对流程进行优化，这个课题我们将在下一章进行探讨，这里我们主要讨论在线上化过程中形式上的需求的确认。我们重点需要梳理流程和表单（含数据）两方面的需求，这在前面两章已经分别讲过了，这里我们重点从流程线上化实操出发，提出需求梳理确认过程中的几个要点。流程方面需要明晰以下内容： 符合要求的流程图（使用规范建模语言、六要素清晰）。流程图应当由流程主责部门绘制提供，虽然流程工程师、需求工程师或者产品都能够帮助流程主责部门画流程图，但是这种流程/IT绘制+业务部门确认的模式实际效果远不如业务部门绘制+流程/IT提建议，一些隐含的、特例的流程活动往往只有在业务人员深度参与的时候才能够被识别出来。 流程图中所有角色的角色清单。这是完整的角色清单的一个子集，通过建立角色清单的方式，能够更好的合并相同相似的角色，明确角色信息的来源，以及规范维护的人员和维护方式，从而保障角色信息的准确完整。角色清单的建设方式详见4.3表单方面需要明晰以下内容： 表单的样式。基于现有的线下表单，或者从零开始设计线上表单，要注意对表单进行结构化设计，尽可能避免文本附件、各种备注说明。 表单中的术语和数据。表单中出现的术语需要明确其含义，纳入企业的术语表，并在企业层面拉通认识；所有出现的数据指标也要明确其含义、计算公式、来源等，对历史数据进行分析和清晰，促进数据治理。表单数据的结构化方法详见4.3此外还应注意： 流程和表单的关联关系。流程节点和流程表单上的字段应当有所对应，明确不同流程节点、不同流程活动执行人应当填写或变更哪些字段，避免不必要的信息公开，也更加具象化每个人的责权。 原型很有用。一些流程存在较为复杂的页面上的交互，使用Axure等工具制作交互原型，这比单纯的文字描述效果好多了。 别忘了非功能需求。响应时间、并发用户数这些非功能需求同样重要。在梳理清楚以上信息后，需要和需求提出人、需求提出部门进行正式的确认。你可以采用简易的线下单据作为过度，也可以按照我们本章所讲述的流程线上化的方法进行线上化。做这一步的目的主要是为了获得流程责任人的背书、实现需求的合规和责任的可追溯，并且能够把一大部分临时的、随意的、不经仔细思考的业务需求给排除掉。图表57流程线上化需求登记表Step3：系统实现：从流程图到现实需求确认后，就进入了系统实现阶段。以下几点需要注意： 选择合适的系统很关键。我们通常会选择成熟商业化的OA和BPM系统，然后进行流程定制。不要被花哨的功能迷惑。关键是看系统是否真正契合企业的业务流程，对供应商的实施团队的能力也要进行充分的评估。 系统集成是容易被低估的环节。现代企业通常已有多个信息系统在运行，如ERP、CRM等。确保OA或BPM系统能与这些系统良好集成非常重要。 性能测试和安全性考虑同样重要。特别是对于大型企业，系统的并发处理能力至关重要。我建议进行压力测试，模拟高并发情况下的系统表现。同时，对于敏感数据，如财务信息，要实施严格的权限控制和数据加密。 用户测试与反馈不容忽视。建议邀请关键用户参与测试，因为他们往往能发现开发人员意想不到的问题。流程开发的人天成本根据流程的复杂程度、所采用的系统、开发实施人员本身的能力以及企业内流程数字化成熟度有所不同，一般来说，我们通过OA去实现一些简单的审批流程，现在一些OA系统已经实现了低代码甚至无代码，业务人员可以自己配置流程，最简单的流程可能几个小时就能完成。但是如果涉及到系统间交互、页面和数据的集成，那仍然需要IT人员的介入。BPM产品相对来说更重，一些产品定制化的能力很强大，但也导致了一定的使用门槛，一般来说需要较为专业的IT人员的介入，如果要实现跨系统的交互、集成，同样也需要其他系统相关的研发人员的参与。根据我的经验，可以大致将流程分为简单、中等和复杂三个级别：简单流程（如请假申请）通常需要3-6人天，中等复杂度的流程（如报销审批）大约需要7-11人天，而复杂流程（如多部门协作的项目审批）可能需要11-18人天甚至更多。如果需要大量的定制开发，时间可能会显著增加。在实际项目中，建议增加15-20%的缓冲时间，以应对各种意外情况。Step4：验收交付：以促进真正使用为目的开发完成后，我们通过培训交底、试运行、验收将新的线上化的流程导入到用户的日常工作中去，并通过一段时间的陪伴，引导用户部门改变原有的行为习惯，真正使用起来流程。培训交底是流程数字化项目交付的第一个关键环节,其重要性不容忽视。一个精心设计的培训计划可以大大提高用户对新系统的接受度和使用效率。项目团队需要制定详细的培训计划。这个计划应包括培训内容、时间安排和参与人员等关键信息。培训内容要全面覆盖新系统的各个方面,从基础操作到高级功能都应涉及。时间安排要合理,既要保证培训的充分性,又要考虑到用户的工作安排。参与人员的选择也很重要,要确保各个相关部门和岗位的代表都能参与其中。准备易懂的培训材料至关重要。这些材料可以包括详细的操作手册、直观的视频教程等。材料的编写要站在用户的角度,使用简单明了的语言,避免过多的技术术语。图文并茂的设计可以帮助用户更好地理解和记忆操作步骤。分层培训的策略可以提高培训效果。针对不同角色的用户,如普通员工、管理人员、系统管理员等,提供有针对性的培训内容。这样可以确保每个用户都能获得与其工作相关的必要知识和技能。实操演练是培训中不可或缺的环节。通过让用户亲自操作新系统,可以加深他们对系统的理解,同时也能及时发现和解决潜在的问题。在演练过程中,培训人员应该耐心指导,及时回答用户的疑问。收集培训反馈非常重要。通过问卷调查、面谈等方式,了解用户对培训的满意度,以及他们在使用新系统时可能遇到的困难。这些反馈可以帮助项目团队进一步优化系统和培训方案。试运行阶段是流程数字化项目从理论到实践的关键过渡期。这个阶段的主要目的是在实际业务环境中验证系统的可用性和稳定性,同时让用户逐步适应新的工作方式。试运行计划应该明确试运行的时间范围、涉及的业务范围,以及预期达到的目标。时间安排要合理,既要给用户足够的适应时间,又不能拖得太长影响正常业务。合适的试点部门也很重要。理想的试点应该具有代表性,能够覆盖系统的主要功能,同时又不会对整体业务造成太大影响。试运行期间,注意收集用户的使用反馈,了解他们在实际工作中遇到的困难和建议。一些小的问题可以通过即时调整解决,而对于一些较大的问题,可能需要制定后续的优化计划。尽管前期已经进行了充分的测试,但在实际业务环境中仍可能出现意外情况。完善的应急预案可以帮助团队快速响应和处理各种突发问题,最大限度地减少对业务的影响。验收是流程数字化项目交付的最后一个关键环节。制定明确的验收标准和指标是验收工作的基础。这些标准和指标应该涵盖功能完整性、性能指标、用户满意度等多个方面,并且要与项目的初始目标相对应。准备完整的验收文档，包括详细的功能清单、测试用例、运行报告等,为验收工作提供全面的依据。验收过程中,要组织相关的利益相关者参与，不仅包括直接使用系统的业务部门,还应该包括IT部门、管理层等。多方参与可以确保验收的全面性和公正性。最后,获取用户的正式验收签字确认。Step5：持续跟踪：让系统与时俱进系统上线不是终点，而是新的起点。我一直强调持续优化的重要性，因为只有这样，流程以及承载流程的信息系统才能持续为企业创造价值。要证明流程线上化项目的价值，数据是最好的佐证。定期整理一些关键指标，如平均审批时间的减少、差旅报销周期的缩短等。这些数据不仅能证明项目的价值，也能为后续的优化提供方向。如何从数据发现流程存在的问题进而优化流程详见第四章。有了报表，我们就有由头定期组织用户座谈会，了解他们在使用流程系统过程中的体验和建议。企业的业务流程是不断变化的，及时对BPM系统进行了调整，确保它能支持新的业务模式。流程线上化是一个持续的过程，而不是一蹴而就的项目。通过流程线上化，我们能够大大提升企业的运营效率。但最关键的是，要始终以解决实际业务问题为导向，而不是简单地追求技术上的先进。只有这样，我们才能真正实现流程线上化的价值，推动企业在数字化时代不断前进。
购物车
购物车
