(一)活动说明
1.模板
表6-21 活动说明模板
活动 名称 | 操作岗位 | 输入 | 活动描述 | 输出 | 模板/工具 | |
主导 | 参与 | |||||
2.定义说明
活动:活动是由单个责任角色主导完成,有明确的输入和输出;活动之下是任务,任务是由单个责任角色完成,活动进一步拆解规范后形成的内容。
主导岗位:表明对活动执行结果承担唯一责任的岗位/角色,在活动执行中占主导地位。
参与岗位:表明参与活动执行的岗位/角色,在活动执行中占配合地位。
输入:活动执行需要的材料、资源及信息。
活动描述:定义活动的执行方法与规定,用于指导与约束活动执行岗位操作。
输出:作为活动的结果生成的结果物,通常是实物或信息,也可能是它们状态的改变。
模板:模板是可复制、可参考的东西,包括实物与信息。模板的目的是帮助活动执行人员节约时间,避免重复劳动;模板让活动执行人员跳过思考过程,直接套用成熟的框架,直入主题,提高工作效率。
3.操作指引
活动名称取自流程图,要求严格保持一致。
对每一个活动要指定唯一的责任人,即主导岗位/角色。如果活动执行涉及多个岗位/角色时,一定要从中找到主导人,其余的都是参与人,否则就会出现共同负责,等于无人负责,就容易出现扯皮。主导岗位/角色也要与流程图严格保持一致。活动主责人有权定义参与角色在活动执行的工作要求,以保证活动执行的结果。
识别活动所需要的输入,重点关注输入的传递是否顺畅,要求能够实现由输入提供者在输入产生时,第一时间触发输入信息及时传递到活动的接收者。如果输入质量影响到活动输出结果要求时,该活动的主导岗位要向输入提供者提出明确的要求,最终要体现在输入产生活动的定义中。
活动描述:根据企业流程管理阶段(初级、中级、高级)选择不同的描述要求。要求太高了就会引起大家的抗拒,也不切合实际。就算是分了不同阶段,在同一个阶段也需要循序渐进,持续迭代,才能输出一个高质量的流程设计。高质量的流程设计的威力是巨大的,会释放出巨大的生产力,不仅为公司带来效率提升,还可能会成为竞争力的来源。
如果在初级阶段,即企业刚导入流程管理时,重点解决责任落地的问题,确保责任落实即可。这不是一个低的要求,如果能够做到,企业跨部门流程就能够保证运作顺畅,扯皮的事件很少发生,组织的内耗会大幅降低,各部门就能够围绕端到端业务流程打胜仗而集体奋斗,都会主动思考:如何获取全流程成果最优,而不是某个环节、某个部门成果最优。
很多时候,企业抱怨协同效率低,问题的根源就是没有基于流程定义清晰职责,个体的责任没有界定并履行到位。团队协同是针对责任/职责界定之外的例外事件才需要的。
描述的要求为:
①定义活动输入与输出及接口关系(明确输入输出如何从产生者传递到接受者),重要的输出要定义模板,如果没有定义输出模板,则要从质量管控的角度提出输出所包括的关键要素。
比如某公司对会议纪要输出的定义,要求包括会议召开的时间、地点、主持人、出席人员、缺席人员、列席单位及人员、特邀专家、记录人等基本情况;主要议题及决策事项;审议过程及会议组成人员本人的意见和表态;其他参会人员的意见;主要分歧意见;会议最终形成的决议及行动计划。再如,某公司对于审批意见输出定义,要求为:同意、不同意、有条件同意。
②描述重点:What,要执行哪些任务?如该活动由多个岗位/角色共同完成,一定要把各岗位/角色之间的职责分工说清楚。日常工作中,经常听到员工抱怨部门/岗位之间扯皮,将职责界面梳理清楚唯一的方式就是在活动说明中,因为每个活动有唯一的责任人,即主导岗位/角色,他会来定义涉及参与人员的工作职责。我的观点是,在活动层面职责一定要定义清晰,做到黑白分明,不可有灰度。
笔者曾看到一家公司的物料调拨流程,他们的是多个跨省基地,同时存在成品、半成品、物料等,由于计划不准确,产生大量跨基地的调货行为,一个月的调拨运费40万~50万元。同时,由于配送计划由计划管理部下达,没有充分考虑实际装车需求,存在大量零担发运,给公司额外增加了100多万元的发运费。
把流程文件打开一看,这两项费用找不到责任主体,所以没有人关注,也不会有人推动改善。笔者采取的做法是先让责任归位,将调拨运费的责任交给计划管理部,本质是由于他的计划不准确导致的,与他的责任制考核挂钩。而将零担发运带来了运费增加责任交给物流的调度承担。同时,要求计划部门只安排周发运计划,具体到每一天的发货计划由物流调度来负责。
如果企业到了中级阶段,即导入流程管理有2~3年,企业已经建立了流程管理的基本认知,能够基于流程解决跨部门/岗位协作的问题,表现为流程运作很顺畅,扯皮的事情很少发生。跨部门协同问题解决了,企业的协同效率高了,但不能保证流程执行的效果与效率,因为流程中的每个活动未必能够执行到位,未必能够保证质量。对于中级阶段,活动说明描述要求如下:
在初级阶段的全部要求基础上,迭代到规则清晰。
达到第一个阶段:责任落实,就实现了组织与岗位围绕流程成功而运作,这会释放出生产力,将组织内耗大幅地降低。但本质上流程运作的模式没有发生改变,改变的是组织运作方式,让组织更协同,让组织更瞄准流程的价值方向去奋斗。但这不足够,就好比创业型公司,业务简单、组织简单,流程就是端到端拉通的,但没有竞争力,因为流程本身的运作方式不先进。到了中级阶段就需要朝两个方向迭代:规则清晰。
我们经常说要用流程来解放管理者,让管理者从例行的工作中解放出来,把例行的工作交给流程。但为什么流程梳理出来了还是交不出去?原因很简单,流程太空了,没有将其中的规则梳理出来,并进行标准化,将最佳的规则固化下来。推荐大家看一篇文章《流程之眼——业务规则》,来自李忠华的公众号“供应链道场”。李老师认为,流程的很多要素都不会被忽视,但业务规则是最容易被忽视的;其他的要素都可以借鉴甚至抄标杆的作业,但业务规则是最个性化的,最依赖公司业务特性的,最体现管理意图的,业务规则是流程之眼!
在百库文库《指南——业务规则》一文中对业务规则的定义为:业务规则是必须遵守的策略的声明或必须满足的条件。业务规则是对如何操作业务(包括业务工具)的各种要求。它们可以是业务需要遵守的法律或规范,也可以表示选定的业务构架和风格。
该文章将业务规则分为约束规则和推导规则两类,具体如下:
①约束规则规定了限制对象结构和行为的策略和条件。
激励和响应规则对某一行为进行约束,方法是通过指定何时触发该行为,以及是否必须满足某些条件才能触发该行为。
操作约束规则规定了在操作前后必须符合的条件,确保操作正确执行。
结构约束规则规定了有关类、对象和它们之间关系不可违背的策略和条件。
②推导规则规定了从一些事实经过推理和计算得到其他事实的策略和条件。
推论规则规定如果某些事实为真,则可以推出一个结论。
计算规则通过处理运算法则(一种更精确完善的推论规则)得出结果。
以上描述更多的是IT视角。从业务及管理视角来看,常见的业务规则有:
相关定义、明确的范围。
流程触发规则。
分层分级规则、定量计算方法公式、判别原则逻辑方法等。
分授权规则(业务权限、财务权限、人事权限)。
输入物技术/管理标准、要求、方法等。
过程操作相关规则:技术/操作/管理标准、要求、方法等。
输出与技术/管理标准、要求、方法等。
能力技术/管理标准、要求、方法等。
如果缺失业务规则,就必然依赖人,就必然要事事请示、层层上报,必然领先管理者与专家的指导,必然效率低下,将管理者耗在例行的工作中。如果缺失业务规则,就必然给操作者留出了空间,就必然由于操作者能力或意愿的问题,带来种种风险,导致流程业务结果不可控;也必然导致公司高度依赖于牛人,伴随着人员流动,业务会有剧烈的波动,政策导向会左右摇摆。相反,如果有了规则就好办了,流程运作就变成了照章办事,不需要请示,不需要审批,快速地就通过了;有了规则就可以加大向下授权的力度,让决策重心前移至一线,大幅提升流程面向市场的反应速度;有了规则,就可以大幅提升IT的生产力,最大化地发挥自动化的价值,实现少人化,大幅提升人效。
我曾在一家企业通过将自动化做到极致大幅提升了公司的人效,自动化项目包括自动开票、自动对账、自动核销、自动生成出仓单、自动审批销售订单、自动销售(线上销售)等。其中,成功最重要的因素就是提炼业务规则。比如自动开票项目有三个规则非常重要:
规范商品的描述规则,使内部描述与外部税务部门的规则拉通,以保证生成开票商品信息之后不需要手工修改。
开票触发规则,到账期触发开票,还是完成出仓完成触发开票,或者客户签收完成后触发开票,你得有一个明确的触发指令。也许不同业务单元的需求一样,仍然需要将其规则化。
ERP系统出仓信息向开票系统传递规则,明确何时,传递什么信息到开票系统。这些规则完成之后,IT自动化实现就相对简单了。
如果企业到了高级阶段,不仅做到了跨部门协同顺畅,还实现了流程结果可控,那么进一步的需求是经验复制。操作要求如下:
对有一定专业复杂度/或对操作者能力有一定依赖度的活动,建立作业文档,重点写:how to do,包括操作指南、评审/检查checklist、模板、FAQ、案例。目的是将活动操作知识化,将最佳实践经验固化并复制给每一位活动操作者,快速地将活动执行水平提升较高的程度。这往往是通过内外部标杆研究来实现的,通过内部标杆研究将企业内最佳实践提取出来,形成知识文档;通过外部标杆研究将外部最佳实践借鉴导入,快速提升作业能力。具体的方法,可以参照内外部标杆分析章节。
我曾有幸被领导信任,在没有财务工作背景的情况下,担任了公司的预算小组执行组组长。经过三年多预算管理流程迭代,公司年度预算目标达成率从原来的不到50%提升到85%以上。对于公司而言,这是一个很重要的能力提升,保证了业绩的可控,提升了资源投放的准确率。
回顾三年多的预算管理历程,我觉得最大的成功因素就是对于预算管理过程中的成功与不足及时地进行复盘总结。预算管理通常是从当年10月份启动,到第二年农历新年开工后正式定稿发布。然后,就会进行月度的经营业绩核算分析与经营分析会议。通常每完成一个小的里程碑点,我们会组织预算小组成员(财务、资金、人力、战略)进行及时的复盘总结,比如预算评审会议(通常有4~6次),在评审会议中,评审专家会从不同的视角提出他们的观点与建议,可能会暴露一些问题,或提出一些需要数据支撑的场景,我就会很快地思考如果缺乏数据支撑(如高管想要看到销售费用之下的销售项目专属费用分配,但由于对费用未进行细分,而无法提供),说明我的预算指标模型出了问题,需要进行相应的完善。如果高管有好的评审视角,比如关注业务结构,尤其是战略业务(战略新品、战略新区域、战略大客户等)的占比或增速,我们就会补充到预算编制的原则或指引中。通过持续的迭代,最终会体现在预算管理流程、预算编制模板、关键指标数据模型、预算评审checklist、预算管理操作指引上。
通过持续迭代,不知不觉中,我的预算管理专业水平快速提升。后续我们与华为财务专家进行沟通后发现,我们的预算管理思路与做法,与华为公司的做法接近,只是在精细度上稍有差距。这既给了我很大的信心,也给了我很大的启发。学习能力+转化能力+推行能力+复盘迭代能力,足以让你快速地成长为业务领域的专家,好的能力是迭代出来的。
某次预算编制后,我们的复盘结果如表6-22所示。
表6-22 复盘结果
序号 | 复盘问题 | 改进对策 |
1 | 对新签合同收入确认进度假设,没有与上一年项目交付进度实际水平进行比对,导致预算与实际偏差太大 | 可以先考虑基于项目计划交付周期来做收入确认节奏的依据,如果事业部要实际周期比历史周期有压缩,需在经营计划中提出对应的改进策略,预算小组对策略逻辑进行验证 |
2 | 对分产品线新签合同净利率水平,没有与历史水平进行核对,导致事业部凑数没有被发现 | 如果产品线净利率预算水平高于历史水平,事业部需在经营计划中提出对应的改进策略,预算小组对策略逻辑进行验证 |
3 | 预算总体做得偏粗,无法满足CEO及业务实际管理需求 | 建议要按产品线、区域、项目等多维度进行展开分析 |
4 | 对于季度的节奏关注不够,会出现Q1预算低于上一年度Q1实际数 | 建议在预算原则要提出,Q1预算要好于去年同期预算、实际数 |
5 | 对于服务与产品集成事业部,业务相对稳定,其预算数要与上年实际数进行比较做得不到位 | 对于服务与产品集成事业部,业务相对稳定,其预算数要与上年实际数进行比较,防止提出的预算数过高,防止出事业部资源过度投入,出现利润大幅下滑的风险 |
6 | 预算小组对各事业部预算审核不足,只做了大层面的指标对比分析,没有对内在的逻辑正确性把关 | 增加内在逻辑的评审 |
7 | 预算评审过程,主要以CEO讲为主,相对发散,有效性不足 | 预算小组要提出自己观点并进行引导,CEO做总结发言 |
8 | 对新参与预算的财务经理培训与指导不足,过程中出现很多操作问题 | 对新参与预算的财务经理,必须先做预算管理培训,过程中由预算小组财务代表提供专业过程跟进与指导服务 |
9 | 新签合同明细的逻辑不合理,新签合同金额与商机明细预测数不一致 | 列出概率较大的商机,给出不同的成交概率与所处阶段,同时允许无项目明细 |
10 | 未开展内部对比,形成竞争氛围,以及内部学标杆的做法 | 对不同事业部之间进行横向比较,尤其是同一行业的不同BU,将优秀BU的水平作为其他相似BU的目标 |
11 | 现金流预测的假设与实际不匹配,不合理 | 对现金流关键影响因素:回款、付款的逻辑进行展开分析与审核 |
12 | 人员增加的节奏不合理,没有与业务实际紧密结合,事业部容易采取简单地按季/月平均的方式 | 审核人员增加与业务节奏的关系,需事业部提供编制支撑材料 |
13 | 不清楚与对手相比较的情况,是否能够支撑公司市场占有率的目标 | 收集行业数据及同行友商数据作对比参考,作为事业部预算评审的依据 |
14 | 经营计划与预算的关联度不足,没有将预算的压力传递到经营计划中 | 增加诸如概预算准确率提升、物料成本下降、大项目营销能力提升、自主产品/解决方案能力提升等相关的指标改善 |
15 | 经营计划的关键举措没有落实到责任人考核中 | 在部门负责人PBC中建议增加这部分的考核 |
16 | 公司对事业部预算设定的目标值过高,使得后续的责任制考核失去意义 | 预算小组基于历史数据提供一稿测算数,为CEO设定科学目标提供参考,并作为内部资源控制的依据 |
17 | 事业部概算与预算、预算与实际均有较大偏差 | 做收入预算时,根据偏差值的历史数据进行修正,可以适度改进,但必须有举措做保证 |
18 | 工程项目结束后,无收入成本存在不确定性 | 预算时做一次测算,在第二年的预算中要进行预提,以更符合权责发生制原则 |
19 | 明年业务的环境与结构发生了改变,但未在预算中体现 | 每一年业务都会出现新的情况,要不断地把新情况纳入预算假设,而不是简单地做历史数据分析 |
2(二)KCP管控设计表操作说明
1.模板
表6-23 KCP管控设计表
流程 | 名称 | 控制目标 | 风险描述 | 控制措施 | 测试程序 |
2.填表说明
流程:通常是末端流程,L3/4。
名称:与流程图保持一致,即KCP对应的活动名称。
控制目标:要求内部控制完成的任务或达到的标准。
风险描述:对风险状态进行描述,包括风险因素、风险事件及风险带来的损失等。
控制措施:为控制风险所采取的相关措施。
测试程序:为测试验证KCP的风险是否处于受控状态的测试方法与规则。
3.操作指引
这是针对KCP进行设计的,如果完成了这张表设计,KCP活动的说明就可以直接引用,不用重复描述。企业想要把管理做简单,就是抓关键,抓住管理的主要矛盾,抓住主要矛盾的主要方面。对于末端流程设计而言,关键点就在于KCP。质量管控要求,从内控、质量、信息安全、EHS、数据治理、法规遵从等方面识别KCP(关键控制点),针对每一个KCP建立对应的管控措施,保证结果可控。具体将在KCP管控设计表中详细说明。目的是保证每一个活动执行结果都符合要求。比如华为公司在推行LTC(从线索到回款)流程变革时,其中一个很重要的诉求就是向爱立信学习,将质量管理要求融入到LTC流程中,提升销售流程的质量,包括线索质量、商机质量、合同质量、交付质量等。
KCP的数量按照业务复杂程度及风险控制现状进行识别,KCP的识别应在L1流程下属流程拉通来进行,建议⼀个Level 1 流程的KCP数量不超过20个。
①分析流程风险并确定CP,常见的风险有:
识别存在风险(影响流程目标达成的风险)的流程活动。
舞弊。
绕过行动。
操作错误。
信息不准确而导致的不恰当决策,如数据不准确,如出现断点、不一致等。
未经过评审或不恰当评审。
法律或政策不遵从。
产品与服务质量问题影响客户满意度。
常见的CP有:
评审和审批,比如账户开立、物料需求、合同条款、费用报销等。
数据/信息的核对,如与客户/供应对账、薪酬数据核对等。
核对checklist,如发布认证合格的供应商信息之前按照《新供应商上网审核表》进行复核。
工作报告,如差错提示报告、账龄分析报告等。
数据创建/修改/删除活动,如创建合同信息等。
②评估风险并识别KCP,通过以下分析,评估风险等级:
高风险通常以影响及发生的可能性来衡量。
重大影响是指影响公司资金资产安全、法律遵从、财务报告及数据质量、产品与服务质量、客户满意度等不确定因素。
发生的可能性可参考审计发现、遵从性测试结果来进行判断。
通常影响大且发生可能性高的风险就是高风险,应当纳入KCP来管控;对于影响大但发生可能性低,要结合具体情况进行确定;对于影响小的风险,通常不纳入KCP进行管理。
③确定KCP:
评估流程活动描述的KCP控制要素是否覆盖高风险、是否清晰并容易理解。
拟制KCP遵从性测试计划。
在流程图中标识KCP。
防止出现不必要/过多的KCP,每一个KCP的设置要符合投资回报原则,即规避的风险损失大于付出的管控成本。从经营的视角来看待风险,经营的目标就是要获利,有效的风险防控,意味着更多利润、更多收入。
④确定KCP的管控措施:
组织控制措施
职责分离:各职位设置和职责划分必须符合相互监督、互相牵制的原则。一般而言,授权、批准、处理、记录、保管和监控等职责应予以划分。敏感性岗位必须定期实施轮换,以降低利益冲突、差错和违规等问题发生的可能性。
权责明确:根据组织目标的分解,明确各职位的责任与权力,并定期审视其合理性和执行效果。各级管理者实施授权必须获得上一级主管的批准,明确授权对象、范围和时效,并监督其实施情况。
流程控制措施
设置规定的标准动作或作业方法。
明确关键控制点设定相应的规则或标准,确保活动执行到位。
针对容易出错或重要的风险环节增加审核控制点。
对操作者资质(确保其具备能够满足岗位的才能与培训要求)或相关设备/设施或环境制定管理要求。
对操作者行为的控制,包括遵守法律法规、制定并遵守商业行为准则、遵守诚信与道德观等。
对记录进行控制:所有经营活动和重要事项必须进行记录,确保其真实、及时、完整和可追溯。重要记录必须按规定及时整理、归档、保存及销毁。任何人不得直接或间接伪造、破坏公司的任何文档和记录。
5⑤确定测试程序:
确定测试对象,包括质量记录、受访人员、观察现场或实物等。
明确证据要求。
确定测试范围,明确测试样本范围以及抽样方法。
确定测试方法,通常有观察、访谈、记录查阅等。
3(三)职责描述模板
1.模板
表6-23 职责描述模板
序号 | 角色 | 职责 | 对应岗位 |
2.填表说明
角色:引用“流程方程式“公众号中《097.Ro流程角色建构的4D模型》文章观点,角色是人被期待符合特定场景的一系列行为的总和,角色是基于业务来定义的。同一个人在不同的流程,会被赋予不同的角色。
职责:是特定角色在流程中所负责的范围和承担的一系列工作任务,以及完成这些工作任务所需承担的相应责任。有两个关键词:工作任务、责任。
对应岗位:承接角色的岗位,岗位是组织中一个特定的职位。同一个人在组织中通常只有一个岗位(兼任多个岗位除外)。
3.操作指引
最好能够基于L1流程对角色进行端到端拉通,否则角色命名会很乱,且不利于拉通来做角色与岗位的匹配;角色来自流程图;职责描述表与流程图要严格保持一致。
职责只写要承担的工作任务及对应的责任,不用写具体如何做。一个好的职责描述标准如下:
责任唯一:每项任务责任人唯一,多角色参与,必须明确主责人。
明确清晰:各岗位均明确其职责,职责描述不空泛,均指向具体的工作任务。
不重不漏:岗位之后职责边界清晰,不交叉,不冲突,不空白。
不仅要描述角色要做的任务,还要明确需承担的责任,尤其是审批类的活动。
每个角色要匹配到组织中的具体岗位来承接。如果涉及一对多的时候,要清晰地描述匹配规则,以便用户快速准确地找到承接岗位。
解决过往因职责不清而导致的扯皮问题。经常在咨询访谈阶段,会遇到企业方大量抱怨职责不清、扯皮不断的问题。但真正到了流程设计/梳理环节,好像找不到扯皮的点,找不到从职责上解决扯皮问题的需求。为何?因为缺乏对于扯皮事件的管理。
我在企业任职时,提出了一个指导原则:“过程中不允许扯皮,当务之急是治病救人,而不是追究责任;结束后必须扯皮,扯清楚,理顺职责边界,今后类似问题不要再扯。”现实中,企业的操作往往是反的,过程中扯皮不断,问题得不到及时解决;事后没有人愿意去扯,下次问题重复发生时,又继续陷入扯皮的内耗中。
我也给出了针对岗位职责梳理及解决扯皮问题的操作原则:“遇见扯皮,要记录;流程过程,不要扯;流程结束,要分析;分析之后,要优化。”