项目收支两条线管理（建权责自运转之四）

扶着试行版手册这个“婴幼儿”走了一段时间，大家会深刻体会到自己的腰酸背痛和“婴幼儿”的跌跌撞撞，会对这个眼前的这个产品重新思考：它在我们现有的各类制度、文件、管理程序标准中处于什么位置？应该具备怎样的基本结构？对它的第一次修订该如何进行？

一、定位

目前对于权责手册并没有一个标准的定义。笔者结合自己的工作经验和大家的讨论，试着做了一个初步的定义：

权责手册是指组织从自身生产经营特点出发，为确保关键业务的审批流程规范化，与作业流程、组织架构、岗位相结合，对业务事项审批流转过程中各岗位角色的权限、责任进行规范化指引的文件。

作为内部授权的依据和以职能为模块的权限管控工具，它的定位应该是：指导公司制度体系文件的纲领性文件，效力高于公司任何制度体系文件。

具体而言，它在我们的业务事项流转中主要起到三个作用（如图）：

在实施中应该注意几点：

1.凡是公司制度体系文件中相关条款与权责手册相冲突的，统一按照权责手册执行。

2.组织管理手册是根据组织结构的岗位设置来进行直线或交叉管理的规定，而权责手册是界定在具体的业务流转中，处于不同角色的责任人具体的工作权限、责任、义务的指引。

3.作为一种“管理程度”的说明，它对流转中每一步对应角色发挥什么作用必须有所表述，不然就会成为形式主义，产生低效和冲突（详细情况后文表述）。

二、编写结构

通常一个典型的权责手册主体部分的表达方式是这样的：

它主要包括以下两个部分：

1、说明部分。文件版本，生效日期，本文件的编修主责人和签批生效的审批人，明确文件的定位，名词解释，符号说明（如用▲代表发起，数字代表顺序、★代表审批、○代表知会），签批时效要求，各类角色的定义，冲突的处理，签批意见的强制性选择要求，审批人再向下授权的要求。

2、对“关键事项”的理解

(1)关键事项可作分类划分，以便使用者查阅。

(2)关键事项这个名称本身，就要求必须要具备相当的重要性，不能鸡毛蒜皮都列入手册，比如笔者在实践中就经常看到有小型集团公司对某个层级人员的请假按不同种类、不同天数作了详细的区分，光是请假一项就有几十条内容，让人看起来就晕。这种细致的标准完全可以在各类制度、规范类文件中用表格方式来表达，如有条件时，完全可以通过OA系统的初步表格开发实现。但是，关键事项应覆盖到我们所有业务中相对重要的部分，不能出现明显的“空白”。

(3)主责单位是指对本页职能涉及事项在公司的主管中心或部门，他们应该在第一版手册诞生时就重要的事项进行梳理，在未来进行增删时通过主动与协作部门、审批领导沟通，达成一致后提供初稿。

(4)手册的编修主责人也兼解释人，一般会是总经办、行政或企管部门，它应该对每一版的修改进行统筹，重点解决“错、漏、重、冲”的问题，发现和协调组织结构设置、职能分属和业务实施中不匹配的现象。

3、流程审批中各类角色的权责说明。

(1)提案：负责完成对应事项的请示报告、规划、计划方案、制度等初步意见，并按流程顺序发起审核、审批要求。

(2)参与：参与提案部门的工作，提供信息、指导、建议，辅助完成部分初稿。

(3)审核：重点在“核”，必须是对此事项有必要、有责任的人员才能履行这一角色，职责在于检查正确、妥当与否，有问题必须指出和纠正；同理，如果后续发现文件本身有问题或没有尽到“核”的职责，应承担相应责任。

(4)审批/审议：审定后给明确意见，是决策权的体现，一般只能给出“是”或“否”的结论。

(5)备案或知会：知情者。知情的原因，有可能是保留未来的问责权，也可能是为了实现信息对称，比如总部信息部门的系统升级方案，有必要让下属各子公司知道总体设想和安排。

(6)执行：具体制度、方案、计划的实际执行者，比如总部计划部门对全年工程节点的安排，就必须交由各项目去具体落地，同时也要按此考核。通常作为提案部门的主责单位会在编写过程中让执行者配合或充分参与，防止不接地气或与一线信息不对称。

三、编写步骤

完整的编写步骤如下图。通常而言有一定业务规模和团队规模的企业，应该按照该图的“三上三下”过程完成手册的编写：

当然，正如前文所述，我们的试行版本是“简单粗暴”的，上述步骤应该是在试行之后总结经验的基础上，让最熟悉实际的各职能骨干来丰富手册的骨肉。通过扩大参与范围，让手册的应用可以最接地气、最得人心，让它从以爬为主的“婴儿”变成学会走路的“幼儿”，从而为我们提升管理效率、规范管理行为打下基础。