从流程洞穿岗位职责和部门职责.docxVIP

从流程洞穿岗位职责和部门职责老包我们一直强调：流程管理不是单纯管理流程，流程管理是一种企业运营的模式，是基于流程构建和整合企业运营管理体系。这不是重构，因为在流程管理之前我们没有真正实现多管理体系的有效整合。其中的道理之前已经反复讨论过，这里不再赘述，现在要探讨的是基于流程来看部门职责和岗位职责。??? 在职能为核心的管理模式之下，我们总是强调部门职责，因为部门之间总是企业剪不断理还乱的老话题，部门内部什么都能搞定，跨越部门就必然涉及到职责边界的问题。企业通常会重复这样的活动：隔一段时间梳理一下职责，岗位写自己的岗位职责，部门写自己的部门职责，报送上去，谁来判断呢？就凭那几行字就能把所有的事情划清楚了吗？虽然我们总是试图划清这样的界限，然而现实情况是很难，说的时候清楚，做的时候不清楚。??? WHY？??? 因为我们的出发点错了，部门和部门之间就不要划清楚，也没有办法划定很清楚，如果真的划清楚了反而成为问题，因为部门之间的工作总是存在很多配合的，本来就应该是你中有我我中有你的。如果仅仅靠职责说明书那点文字就能够搞清楚的话，企业运营就太简单了。这个问题不放在具体的活动层面是没有办法解决的，只有到具体的活动才能够说清楚到底谁来负责。??? 正是基于这样的思想，我们需要从流程的角度来看待岗位职责和部门职责。我始终坚持这样的观点：部门之间的职责是模糊的而岗位的职责应该是高度清晰的。不是说部门之间没有办法梳理清楚，而是不需要去强调，只需要把岗位之间的职责搞清楚，那么部门仅仅是一个工作组而已，岗位职责的集合也就自然明了。??? 如何去清晰岗位职责呢？答案是流程。??? 首先要保证你的流程是成体系的，从价值链逐层分解下去，是跨职能部门的贯通的一个整体，所有的活动就像你真实运行的路径一样完整呈现出来，而每一个活动都被定义了一个Owner，这个Owner就是为这个活动负责的人（很多企业喜欢对一个流程活动定义很多个角色，我一直强调不管多少个角色一定要有一个Owner为此负责）。这样不管是大的业务模块还是细小的操作动作都有了一个Owner。??? 接下去的事情就简单了，只需要按照角色把他负责的所有活动都列出来，他应该对什么负责也就一目了然了。现在的流程管理工具几乎都支持这样的非常easy的功能，如果你的流程管理软件不支持的话那真是太不幸了。这样看起来我们根本不用再去梳理岗位职责了，因为在流程层面我的岗位职责能够精确到具体的活动。??? 关于部门职责的问题前面已经说过了，部门不过是岗位的group，一个部门包含的岗位集合起来就自然是部门职责了，那么部门职责我也当然不需要再表述出来，如果你愿意的话那也很简单了。??? 很不幸的是，我们现在依然有很多企业在用VISIO绘制流程，绘制的结果依然是被部门分割的流程片段，每一页都是从一个开始到一个结束，根本没有办法实现所谓流程端到端的贯通和部门之间的跨越。这是基于关注局部流程时代的工作方式的缩影，现在的流程早已经体系化了，整个企业的流程应该彼此链接成为一个不间断的整体。杜豪博士形容这样的方式是在“用职能的方式做流程的事”还是相当贴切的。??? 用VISIO还是用能够呈现流程体系的工具这看起来似乎只是表现方式的差异，而其实背后的原理远远不只这么简单。工具只是表象的，理论基础和方法论的差异才是根本——那是片段流程和流程管理体系的本质差异。能够理解这一点，剩下的事情也就没那么难了。 下面是一个实例，我们按照业务实际的逻辑，以业务模块为单位来绘制流程而不是部门，这里就没有太多部门的概念，强调的是岗位，这样能够保证不管是大的业务模块还是小的具体活动，所有的事情都可以负责到岗位。流程和流程之间是相互贯通的，软件可以支持这样的链接，每一个活动如果内部还有更细的子活动的话只需要点击就可以到下一层，用这样的方式流程就形成了一个整体而不再是我们时常说的多少条的概念了，而是一整套。??? 还有一个延伸的问题，部门职责变了、岗位职责变了流程会不会改变？如果我们是用片段的方式在部门内部来做流程的话那就有点摸不着头脑了，以为对于一个部门或者一个工作岗位来说，他的工作内容变了，流程自然要变化，甚至有的流程已经不属于他了，这就会成为一个大麻烦。我之前也遇到过被这样的事情困扰的企业。然而当我们用这样的方式帮他们建立了一个整体的流程体系之后，答案就不言自明了：不管组织机构如何变化，岗位如何变化，流程就在那里，不增不减（流程的变化是优化的问题而不是机构和岗位变动的问题），变化的仅仅是那个Owner由一个岗位的名称变成了另外一个岗位的名称而已。一个企业的人力资源经理在看到我们帮助构建的流程体系之后异常兴奋，从来没有搞清楚的部门和岗位职责问题其实可以这样简单。??? 思想基础不同，结果就会大相径庭。——找到撬动杠杆的那个支点。