流程梳理2

 运营管理系统是一个输入输出的转化系统，将一些原料、信息输入，转化成产品和服务。而这个转化过程是通过业务流程来实现的，但是，业务流程的各个步骤或活动，是由组织结构中各个部门的某个岗位或作业中心来完成的。各个部门/作业中心协同、合作，组成一条完整的业务流程，而业务流程完成一类业务，也就是生产出一类产品，提供一类服务，这就是运营职能的运作方式。在确定如何建立组织结构和业务流程的建模方法之前，需要弄清楚如何梳理他们的关联部位，即流程活动，更合适。

1、梳理流程活动的难点

    组织结构和业务流程关联的单位是流程活动，或者叫流程步骤。那么，第一个问题就是按照那个角度来梳理流程活动？是按照业务流程还是组织结构？从名称上看，按照业务流程来梳理，会更直接。可是，事实并不总像表面的那么样，这里也不例外。

    判断哪种方法更好，首先得整理清楚难点在什么地方，这个东西整理清楚了，后面就比较容易确定了：哪种方法可以更好的解决这些难点，那么对应的方法就会比较好。

    第一个问题是如何确定割断业务流程的流程活动的粒度。业务流程由一系列活动，以及这些活动的关联，达到业务流程的目标。既然是一系列的活动，那么这些活动该如何区分呢？前面的文章已经提到，流程活动切分的粗细程度不同，会出现不同层次的流程活动。一个主要的业务流程不是一串链珠，而是像一张网络，一张渔网：存在大量的分支，存在大量的判断，以满足不同产品/服务所独有的特征。不管是网络还是链珠，在我们看到这个实物时，我们总是能够找到中间的那些珠子、那些网络节点。可是，如果放到组织的环境下，放到一个没有什么文档的环境下，如果想按照相同的粒度将这些珠子、节点找出来，困难可想而知。即使组成足够大的专项项目团队去干这个事情，也是很难说明白这个粒度，更不用说好好的组织管理了。所以说，表面上看到的、直观的割断业务流程以得到一个个的流程活动，这个方法看起来很直接、很美，可这个唯一的“很难实现”这个缺点就将这个方法排除在外。

    第二个问题是如何确定割断各个流程活动的点。业务流程这个网络，主流程是由多个子流程组成的，就好像是一个网络的子结构还是一个网络一样。但是，并不是任何地方都需要隔开，或者隔开后对运营管理有帮助。如何确定这个割开点呢？仅仅从业务流程的角度，很难做出判断，因为业务流程就是一个个流程活动连接起来的，如果不引入其它的信息，每个流程活动都是一个节点，没有什么区别。所以从这个角度看，业务流程角度整理业务活动，也不是什么好的解决方法，更确切的说是这个角度根本就解决不了这个问题。

    第三个问题是“整体到局部”还是“局部到整理”的梳理流程活动的问题。这里所说的整体是整个的业务流程，局部是单个的流程活动，或由多个流程活动组成的次要业务流程。能够按照业务流程的起始点一步一步的整理，以得到一个完整的流程，不能说不可行，但在实际中几乎没有人采用，而更多的是首先整理各个岗位的 SOP（Standard Operation Procedure，标准作业程序），然后进行汇总以得到一个整体的业务流程。为什么呢？因为让岗位的人整理岗位的SOP是让最熟悉的人去干他们最熟悉的事，后面的汇总才是专项项目的人员干的事情。每个岗位的人才真正对这个岗位的作业程序最了解，一个专项项目组的成员是不可能真正的熟悉岗位的作业程序的，他们知道的只是建立SOP的方法。各自发挥自己的长处，才能做的更好，所以就出现了大量的岗位SOP，最后让一个专项项目汇总得到最后的整个业务流程。从这个角度来说，实践中采用的“局部到整体”的方式，决定了按照业务流程的“整体到局部”的方式是那么的不合适。

    而按照岗位梳理流程是如何能够解决这些问题呢，以及应该采用什么样的步骤来梳理流程活动呢？在文章的后半部分会一一讨论。

2、为什么按照岗位来梳理流程活动是合适的？

    上面已经提到确定流程活动的粒度、分割点以及项目协作方面的难点，认为按照业务流程来梳理流程活动是不合适的，那么为什么按照岗位来梳理就是合适的呢？因为岗位为上面的三个问题都提供了一个载体。

    首先是粒度问题。岗位是组织结构的最少粒度，以岗位为粒度来确定流程活动，就让粒度问题变成了不是一个问题，因为岗位就是流程活动的粒度。只要将岗位对应的工作理顺了，这个岗位需要干的活整理完整了，该岗位完成的流程活动就确定了。能把岗位的工作说清楚的粒度，就是一个合适的粒度。而是否把岗位的工作说清楚了，就不是一个很难的问题了。

    说到这里，又有人会问：为什么岗位这个粒度就是合适的呢？有三个原因。一是岗位是组织结构的最小粒度、最小单元，从组织结构的角度来看，已经不怎么合适分到更细了。二是建立这个模型，更多的是为了确定运营资源的消耗，运营资源包括人、设备、原材料等，这些东西都是根据岗位和工作量配置的，也就是说岗位是框架，工作量是驱动因子，确定了岗位就确定了框架，也就确定了结构。三是如果粒度是岗位的更上一层，那么显然粒度是不够的，因为设置不同岗位的原因就是不同岗位干不同的活，能把岗位都混淆在一块，要么是分解的不够详细，要么是岗位设置的有些问题。不管是一个什么情况，都表明岗位的更上一层不是合适的。

    第二个问题是分割点的问题。同样，岗位的出现让这个问题也变得不是一个问题：岗位就是天然的分割点。不同岗位干的活，通过岗位就分开了，一个岗位下相似的活动就成了一个节点。当然，由于一个岗位会干多项活，所以岗位下可能包括多个节点，但是已经到岗位这个层次，后面的处理就变得比较容易了，毕竟涉及的范围比较窄。当涉及的范围比较小的时候，在理论上要把问题解决清楚可能会有一点的难度，但在实际中解决这个问题肯定不会难，大不了多花点时间嘛。而当范围比较宽的时候，理论的指导才显得更有意义，因为仅仅花更多的时间来蛮干这种方法在范围比较宽的时候，就显得不合适了。只有企业的规模大到一定程度，才体现管理的作用，可能也是相同的机理。

    最后一个问题是项目协作的方式问题。上面已经说到了，为了发挥各自的优势，从“局部到整体”可能是更好的方法。一个员工常常只对应一个岗位（当然在实际的环境下，一个员工可能会对应多个岗位，也就是兼岗，但不会对下面的说明有影响），他常常会对自己要干什么事情很清楚，而对其它岗位要干什么事情不清楚。他清楚自己岗位要干的活，每个活的上游岗位是什么，下游岗位是什么，跟谁交接等等。这就决定了他可以很清楚的描述出自己岗位的SOP，而不能描述出别的岗位的SOP。此外，由于说明是按照岗位的SOP来分配资源、绩效考核，岗位的员工就很有动力把岗位的工作描述的很完整，这就解决了“局部到整体”而容易出现遗漏的情况。从而，只有对应岗位的员工才能更完整、清晰的描述出岗位的SOP，别的岗位的员工都不能胜任这项工作，即使专项项目的成员也是这样的。各个岗位描述自己岗位的SOP，然后由专项项目的成员进行汇总，就可以保证最后的汇总结果不会遗漏、不会多余，也不会冲突了，保证了质量；同时也减少了专项项目组的负担，保证了成本；不需要专项项目组花费大量时间摸索业务，只需要理顺岗位的SOP就可以了，保证了时间；岗位的员工自己描述的岗位SOP，他们肯定更会认可，保证了项目成果的有效。总之，是项目推动的有效方法。

3、梳理流程活动的操作步骤

    上面已经讨论过，按照岗位梳理流程活动，然后由专项项目组汇总是一个好的方法，下面将给出操作的步骤。

    第一步，各岗位描述自己岗位的SOP。需要包括的内容有：岗位的名称；科室、部门的名称；需要完成的工作列表；每项工作对应的上游岗位的活动、下游岗位的活动；需要的数据、信息；每项工作的大概描述；完成后的结果；衡量该项工作的工作量指标；单位工作量消耗的人力、设备、材料等资源数量。

    第二步，专项项目组与岗位人员沟通，保证SOP符合规范，是合格的“产品”。因为专项项目组对SOP的操作方法、注意事项、常见错误都很了解，是SOP的“专家”，而岗位的人员在这方面会比较不专业，两者沟通可以保证SOP是合格的。

    第三步，专项项目组成员汇总各个岗位的SOP，形成一个个的完整流程。在汇总的过程中，毫无疑问会出现遗漏、重复、冲突的流程活动、功能描述，这就要专业的专项项目成员来梳理、发掘，并于岗位SOP的编写人员沟通、完善，当然这个沟通过程常常是需要多方沟通。

    第四步，将汇总的结果发给各个岗位的人员，由他们确认是否有不符合实际的情况。由岗位人员确认可以保证项目成果的得到更好的认可，也可以避免一些错误，应该在做项目时常常采纳。

    第五步，形成这些文件的管理规范。这些文件描述的常常是某个时间点的静态的情形，实际会常常改变，所以必须要有一套规范来指导如果改变，或者改变之后需要做些什么事情，以避免这些文件在完成不久就失效了，这就是这些SOP的管理SOP。

关键点汇总：

    1、流程活动是业务流程和组织结构的关联点，在梳理时候需要好的角度来指导。

    2、按业务流程来梳理流程活动，会出现粒度难以确定、分割点确定不了，以及项目执行的难度。

    3、按照岗位来梳理，然后汇总可以解决这些难点，是一个合适的方法。

    4、按照岗位来梳理，也需要好的规划，一步一步来才能保证效果。