公司明确了企业发展的目标是流程化组织建设。如何理解呢?我认为流程化 组织建设的目标可以分解为:价值创造流程简洁高效、组织与流程匹配运作高效、管理体系集成高效、运营管理卓越、持续改进的质量文化与契约交付的项目文化 已经形成。公司从十多年前的IPD、ISC变革开始就在向这个目标在努力,当前 在开展的IFS、CRM变革则是实现这个目标的重要手段。为了实现流程化组织建 设这个目标,公司在各级组织中建设了质量与运营组织,这是为实现流程化组织 建设的一个非常重要的举措。除此外,还需要公司上下对业务、流程、IT、质量、 运营等一些基本概念以及它们之间的关系有一个正确的认识,以指导我们正确的 行动。为此,特把我在业务管理纲要研讨班上对业务、流程、IT、质量、运营等 概念的讲话整理出来,供各位参考。

 

1 业务流是客观存在的,所有和客户相关的业务流,天然是从客户到客户 的

    首先,引入业务流的概念,企业为实现价值创造,从输入客户要求开始到交 付产品及服务给客户获得客户满意并实现企业自身价值的E2E业务过程就是业 务流。业务流是客观存在的,每家公司在设计自身业务流程时都是想办法要找到真实合理的业务流,去适配这个业务流。

只要企业设定了战略,选择了业务模式,就确定了其业务流,不论是否用业务流程来描述和定义,业务流天然存在,所有业务部门都工作在业务流或者支撑业务流的支撑活动中。条条大路通罗马,但总有一条路是最近的。业界的研发流 程经过这么多年的实践后,经过优化和实践,大家现在的研发流程都是差不多的, 没有什么区别。我们跟摩托罗拉打交道,跟诺西打交道,跟IBM打交道,发现大 家经过这么多年的实践,研发流程都基本是一样的,没什么区别,大家都是通过实践,不断优化和改进,找到真实客观的业务流,然后围绕业务流客观地建设流程。

所有和客户相关的业务流,天然是从客户到客户的,我们围绕业务流开展工 作的时候必须瞄准客户,以客户为中心。因为我们本来是围绕客户创造业务价值, 不能脱离客户。

识别业务流非常关键,在流程、IT、质量与运营工作中,业务流是一切工作的原点和基础,紧紧的抓住业务流,就不会偏离工作的方向。流程描述的是业务流, IT承载和使能的是业务流,数据是业务流中流动的信息,质量要求依附于 业务流,质量管理基于业务流,运营也是基于业务流开展。

 

2 流程是对业务流的一种表现方式,是优秀作业实践的总结和固化,目的 是为了不同团队执行流程时获得成功的可复制性。越符合业务流的流程就越顺畅。

    我讲过两个案例,其一是我们的ITR流程(网上问题处理流程),以前根本 不关注客户,所有的问题定级都是基于不同产品不同问题来进行技术等级定级, 然后相互吵架,吵得一蹋糊涂,其实问题是从客户那里触发的,客户是最急的。 我们不去关注问题对客户的影响,以对客户的影响来评价级别,而在内部吵。以 前所有做过研发的都和GTS吵过(因为研发有这个考核指标)。

    后来网上问题处理流程和IT系统最大的改变是:以客户对故障的定级来定级。 客户很清楚其有多少用户被影响了。通过数量、时间、重要性三个要素来定级, 根据这三个要素分几档,自动就定级了。然后所有的IT,所有的流程都围绕快速 去知道网上发生的问题、快速解决网上问题,所有内部考核的事情先放在一边。流程和IT系统先解决这个问题,然后能考核就考核一下,考核不了就算了。流程 IT系统支持公司快速响应客户需求,知道网上发生的问题,升级上来,快速去解决,其它一切都要让位于这个目的。

    其二是交付流程。原来进行LTC变革的时候,问交付流程要不要纳入LTC,我们认为自己的交付流程已经很好,只要在原来的基础上修改一下就OK了。当时交付流程立的是一个优化项目,立足于把原有的流程优化一下就可以了。后来项目 组看我们的交付流程,越看越不对劲。第一次项目的CHARTER和后来在3T汇报的 CHARTER面目全非,完全变了。其中发现我们的交付流程基本上没有,只有一个项目管理流程和一个站点流程,没有交付流程的,就相当于研发没有研发流程, 只有一个研发项目管理流程。 后来终于搞明白了,交付流程要重新整理。刚开始搞的时候没找到方向,不知道交付流程到底该怎么搞?后来我有次看到T-MOBILE自己整个网络部署的端 到端流程。我一看,发现这个流程和我们要的不是差不多吗?那我们为何不以 T-MOBILE的流程为参考呢?本来网络的部署是客户的事情,我们只是被他们调用 的。一个客户从他明确需求开始一直到网络交付运营,本来就是他们自己的事情, 我们只是在他们整个流程中完成其中一两个或者多个环节而已。所以我提出我们 的交付流程要从运营商视角,从运营商自己的流程来看我们的流程。后来他们再 把德电的顾问请过来,再真正从运营商视角来看他从明确需求开始一直到运行维护保障的整个流程,基于运营商视角来设计交付流程。对于欧洲运营商,我们的交付只是运营商整个网络部署流程里的一个环节。而对于马来这些地方的运营商, 他们缺乏端到端的整个流程,那我们就需多做几个环节。

    这些应该是业务主管最清楚,流程IT部是搞不清楚的。流程是对业务流的一 种表现方式。越符合业务流的流程越顺畅。如果流程恰好符合业务流,就不应该 再去简化流程。业务流客观存在是5个环节,你一定要缩减到3个环节,或者硬要人为地搞成7个环节,那它一定要回到它的5个环节。所以流程要客观地表现客观 存在的业务流。它跟客观存在的业务流越接近,流程就越畅通,越精简,越能体 现真实。如果流程与客观业务流背道而驰,不搞流程反而好,要搞全是多余的。 像我们以前网上问题处理流程就是多的,全是内部吵架,全是为了内部管理。我 们要把真实的业务流理解得越来越透。

    另外以前我们把流程和部门捆死,使得我们很被动:部门说改就改,部门一改就得改流程。我们现在流程设计的新思路,是在流程里看不到部门,不与组织直接挂钩,在流程里只定义角色,组织要来承载流程角色。我们强调流程决定组织,就是组织首先要承载流程里面定义的各个角色要履行的职责。同时组织不能 跨在两段流程上,不要把组织承载的流程是这边一段,那边一段,要么就一段, 要么就两段,不要搞成一边一段。

 

3 数据是在流程中跑的信息, IT是用技术手段来固化流程

     理解了业务流和流程,再谈谈数据。在流程、IT、质量与运营工作中,数据是非常关键的,但是公司当前并没有给以足够的重视。在业务流中流动的是信息, 信息的载体即数据,数据包括结构化数据和非结构化数据(文档),数据即业务 流各作业活动的输出。对于每个作业环节来说,其作业的输出需要满足下游的需 要,如果一个作业活动没有输出下游所需要的数据,则这个活动就相当于白做了, 因为没有达到该环节的质量要求,下游为了补救则需要花费更大的代价。理想的 境界就是每个作业环节匹配其独特价值输出下游需要的刚刚好的信息,不冗余, 不缺失,满足该作业环节的质量要求。IPD变革虽然进行了十多年,也有力地支 撑了公司的发展壮大,但是在早期对数据的关注不够,因此没有系统的梳理产品 的信息架构和数据的标准,也没有对业务流中的数据流进行系统的梳理。从而没 有基于梳理的数据来定义IPD流程各环节的交付件和数据,也没有基于数据流的 梳理来定义IPD领域的IT应用架构和接口,导致前期IPD领域的IT和工具建设非 常的凌乱,不集成。IPD的经验与教训告诉我们,对业务流中信息的梳理是流程 定义的前提,是IT应用架构定义的基础,也是IT系统开发的前提,主流程集成贯 通,本质上是数据的集成贯通。数据管理在流程与IT中处于最核心的位置,因需 要对数据给以足够的重视。

    数据是在流程中跑的信息。工作中常见的现象是信息的入口没管理起来,使 得进到流程中的是堆没用的东西,流程是通的,但因为里面的东西没有价值,从 而流程也是没用的。信息很关键,一定要把住入口。

    除了流程贯通需要关注数据外,数据还是公司经营管理的基础,基础数据不 准确,则各种经营管理所需要的报告数据也不准确,不能准确的反映业务实质, 无法有效的指导经营管理。

    IT是什么,IT就是承载业务作业流程并实现业务数据自动传递和集成的使能器。IT承载的是业务流以及数据,IT支撑每一个作业以及作业输出的数据,通过 IT实现数据之间的集成,流程的自动化,而不要依靠人来输入、转换数据,因为 人是会犯错误的,而IT系统不会,而且效率比人高。因此,流程化的组织建设的 最高境界就是端到端、整个业务流全由IT支撑,使所有的作业、所有的数据都被 IT承载,而且从前到后都是集成和自动化的。

    IT是用技术手段把流程承载起来,是用技术手段来固化流程,提升流程的运作效率。在IT中跑的是固化的流程,本质上跑的是业务。没有IT支撑的流程容易成为一堆纸,难以执行。 当然不是所有流程都要借助IT,只有用的人多,有效率问题才用IT。如果只是一个部门二三十个人在用,也不一定要借助IT。

 

4 质量的定义就是符合要求,质量要求必须构筑在流程中。内控、信息安 全、网络安全是特定形式的质量要求。

    质量管理大师Philip Crosby说,质量的定义就是符合要求。任何业务都是 要追求质量的,质量要求必须跟随业务流构筑在流程中。为了让每个环节的交付 能够刚刚好的满足下游的要求,就需要定义每个作业环节的输入与输出交付件及其质量要求,并基于质量管理的方法,确保每个作业环节达成质量要求。质量管理包括质量策划、质量控制、质量改进,质量策划致力于策划如何达成质量要求, 质量控制致力于确保达成质量要求,质量改进致力于如何更好的达成质量要求。 为了让每个作业环节知道其作业的质量要求,需要定义质量标准及Checklist。同 时需要建设并积累支撑该作业环节达成交付要求的为工具、方法、指导书等使能 内容,这些属于支撑作业环节达成交付要求(交付要求属于What)的How to do 部分。

质量分过程质量和结果质量,过程质量如果不构筑在流程中,把业务都跑完 了,质量单独在外面存在是不可能的。质量要求也好,质量标准也好,我们要构 筑在流程里面,过程质量也有要求有标准,能够得到保证。过程质量有保证才能 确保结果质量。基于过程质量的管理能带来结果质量,由于追求结果质量迫使我们到源头来管控过程质量。

    内控是内部要求,目的是防止腐败,控制风险。我们最早搞内控的时候,把 内控和流程分离。内控在这边搞得热火朝天,流程在那边搞得热火朝天,后来发 现存在问题,就把两者合并了。内控就是我们公司内部要求的风险管理和防腐败。本质就两个点:一个叫职责分离,目的是防腐败和财务风险;另一个是关键控制 点,在关键控制点要有控制要素和控制程序。内控也必须构筑在流程中。内控若在流程外,不在流程里,是不可行的。我们原来支撑流程建设的是流程部,支撑 内控建设的是内控部,两个部门各行其是。后来发现问题后,我们把流程建设和内控建设部合并。至于SACA、CT干啥?就是跟质量管理一样,看流程执行到关键控制点和需SOD的时候是否按流程内控要求遵从了。 信息安全是内部管理要求,是围绕核心资产进行管理和保护。核心信息资产产生于哪里?是产生于业务流程中的。所以信息安全也要构筑在流程中。以前信 息安全管理是修万里长城,修了好多年,防不胜防,发了100多个文件。后来发布了EMT决议,把信息安全的管理思路调了180度,要求不要到处防,不要去修万里长城,首先只防核心资产。要防核心资产,首先要把核心资产识别出来,只有 识别出来了才好进行保护,要识别出来及很好地保护还是得基于流程。

    信息安全部转变观念,不修万里长城了,把100多个信息安全的文件清得快没了,这也是为什么大家感觉好点了。

     同时把信息安全和共享两个职责都放到信息安全部,要求既要抓信息安全, 也要抓信息共享,信息安全部的考核指标是既有信息安全,又有共享,这样就好 多了。现在到各个部门去看,很少有人反馈说搞信息安全搞得啥都看不到。既然 不是核心资产就通通共享,是核心资产就在核心资产保护的环境下也共享起来。通过考核共享率,这样就没有特别极端了,合理多了。要把信息安全构筑在流程中,流程走到哪里,核心信息资产就定义到哪里,保护到那里。核心资产怎么定 义?由业务部门来定义,基于流程来定义。

    网络安全也是一样的。网络安全我们强调的是产品在各个流程中要具备网络安全的能力、要有防御能力。

 

5 运营是瞄准业务目标,周而复始地沿着流程转,通过持续、周期性的业 务运营管理活动,以达成业务目标。

    前面讨论了流程、IT、数据与质量,下面再谈谈运营。所谓运营,就是指业 务的运转过程中的连续性循环活动,运营的目标是为利益关系者创造价值。说的直白一点,运营就是流程和管理体系Run的过程,没有运营,流程和管理体系就 是死的(静止的),企业的价值创造就无法实现,也就无法实现业务目标。因此, 在一个企业中,运营无处不在,大到一个企业的运营,小到一个基层组织的运营。 运营管理就是对运营过程的计划、组织、实施和控制,运营管理的对象包括业务流程(如IPD、LTC)和管理系统,运营管理的实质就是通过对运营过程和运营系统的有效管理,以实现投入产出的最大化,因此其关注的目标包括:质量、成本、费用、效率/效益、周期/速度、柔性、客户满意等,最终支撑企业的商业成功。

     在一个企业中,战略规划流程DSTE是处于最顶层的流程,其将战略规划、业务规划、财经、HR、流程与IT围绕从战略到执行实现有机的集成,以实现组 织的业务目标。围绕DSTE开展运营管理以实现组织的业务目标是运营管理中最重要的部分,也可以称为绩效运营管理。基于DSTE开展运营管理以实现组织的业务目标的基础是基于各业务流程开展的运营管理,如基于IPD、LTC、ITR等 流程的运营管理,如在LTC下开展的项目、项目群、项目组合的运营管理,以实 现每个项目、项目群的业务目标。在谈不同范围的运营时,可以在运营前面加定 语以区分,如项目运营管理、销售运营管理、营销运营管理、知识运营管理、客户满意运营管理等,在很多情况下也可以将运营省略,如销售管理、项目管理、质量管理、客户满意管理、知识管理等,这些管理活动本身就是运营管理的一个 组成部分。

    如果不沿着流程转就不是运营,我们的IPD体系,在运营这块是清晰了,是 理解透了,我们所有的业务都是在流程里转。但我们在区域实际上没达成共识, 区域有商务管理、销售管理、流程质量、流程管理。销售管理不就是围绕销售流 程转的吗,商务管理不是管合同质量的吗?在产品线里这些都是合并的。只要是 围绕流程转的,就需有相应的支撑组织,我们的运营组织要全在运营里面,核心 是要遵从流程才能转得起来。

    遵从流程后发现和业务场景不匹配,作为主管,在自己授权范围内的,就直接优化好;在自己授权范围外,明显看到流程有问题,与业务场景不匹配的,就 要去推动优化。当然要先遵从流程之后再提出流程的问题,如果都没有遵从流程 就说流程有问题是空谈。如果有人对我说流程有问题,我会问他哪个流程有问题。华为公司流程有问题的很多,你要告诉我那个流程有问题。只有遵从过流程,围着流程转过你才知道问题在哪里,如果不遵从就不可能知道流程有问题,不可能推动和优化流程。因为你转都没转过怎么知道问题在哪里?

这就是运营,几个目的,一个是沿着流程周而复始地转,其次是在遵从过程中发现有问题时解决或推动问题解决。如果我们真的不是流程的奴隶,而是流程 的主人的话,我们会去关注流程到底怎样,关注流程是否符合业务场景,关注我们的流程遵从以后还有什么问题,那我们公司流程遵从和流程优化的土壤就改善了。

 

6 流程确定角色,组织承载角色,流程与组织匹配才能运作高效

    下面再谈一下我对组织设计与流程的匹配的一些理解。在流程与组织变革中, 需要遵循如下的过程:第一个路径是从战略出发,基于战略设计所选择的业务模 式,确定主业务流,并识别业务流的关键能力,基于关键能力的差距和优先级确 定变革的规划,基于变革,进行流程设计,并基于组织设计原则进行组织设计和流程的匹配。从一个企业的组织与流程架构设计来看,理想的设计应该实现:从水平来看,每个流程在各Business组织间如何实现全球的一致性,从垂直看,每 个Business组织如何实现各业务流程的有机集成。主业务流程是直接为客户创造价值的流程,所有组织要么必须工作在主流程中,要么就必须支撑好主业务流以为客户创造价值,否则,这样的组织就是多余的组织。各职能组织如何参与和支撑呢?项目化运作是最有效的方式,事实上,任何Business组织都是通过一个个 项目/群来实现其经营目标的,项目就是最基础的管理单元,执行主业务流程的 是项目/群,而各种组合管理的目的包括组合设计、取舍、以及优先级排序,以 使得满足客户需求并实现资源投入产出最大化。因此,各职能组织都需要参与到执行主业务流的跨功能部门项目中,为客户创造价值。

    对于各职能组织的设计,需要基于如下核心理念:每个职能组织都要对E2E 结果负责,而不是段到段,各组织之间不是接力赛,而是类似足球赛,共同参与 项目,通过项目组的跨职能组织的运作,一起执行主业务流,以实现业务目标。 职能组织的设计基于业务流的需要的能力的一个或者几个专业领域(根据管理的 需要),为了让各职能领域能够有一个其执行的E2E的完整的流程视图,可以引 入Discipline(专业领域)的概念,对于每个专业领域,其对应于HR的一个职类 (如软件、硬件),也可对应一个职能部门。流程定义What,Discipline定义How to do, Discipline的建设可以授权给各职能部门进行建设。因此,流程的授权可 以分两个维度,一个是基于经营组织的划分进行主业务流的授权,另外一个是基于Discipline的划分对各职能组织进行授权。

 

7 业务主管是流程的责任人,顾问公司和流程IT部提供流程专家,以顾问形式提供专业服务

    以前代表处给老板汇报,反映流程太长,流程有问题,他首先骂的是流程IT 部,因此流程IT部老是挨批。最近我们已经讨论清楚了流程的责任人是业务主管, 于是我给老板建议,他若再看到哪个流程有问题,就给业务部门主管直接打个电 话,骂这个业务部门的主管。既然我们定义了流程的责任人是业务主管,那以后 出了问题首先应该找业务主管。流程IT部不可能单独开发一个流程出来让大家用, 只有业务部门与流程IT部一起开发出来的流程才有可能用,业务部门才有可能执 行。我们已经明确了业务流程的责任人是业务主管,那以后流程有问题就要找业务主管解决。

    我们强调流程要业务部门来主导设计,为什么还要有流程IT部门和顾问公司 呢?是因为我们对业务的理解还存在片面性。我们怎么理解自己的业务?就是我 们自己做了啥,我们的职责就是啥。

    我们在梳理政府事务的流程的时候,就发现政府事务部门仅把自己原来怎么 做的变成了自己的流程。后来我们请IBM做顾问后,发现整个政府事务部在要负 责的事情中少了百分之七八十。我们在顾问的帮助下把业务框架搭起来后,我们 发现好多工作都没做。原来法务也是这样的,我们法务只管诉讼,不管预防。由 于各级业务主管的视角还只聚焦在做了啥,理解到了啥,想到了啥,很难全面, 因此我们需要顾问公司。顾问公司在其它公司做了类似的事情,他们知道别的公 司有哪些环节,可以给我们一个Benchmark, 建议我们是否需要考虑这些环节, 并给些建议方案。

    流程IT部门干啥呢?流程IT部门有些专家可指导业务部门在流程上该怎么 设计,怎么表现及流程建设上需要注意的一些事项。

我们做变革也好,做流程优化也好,应该是业务部门、流程IT部门、顾问这三者的结合,这三者的结合是很有价值的。但是我们强调主导的是业务部门,只有业务部门自己内心愿意做,做好了才愿意推行,推行了有问题才愿意去面对。否则强加一个流程给业务部门,业务部门不可能推行,也许只可能反对,只要有 一点点困难,就会指责流程。