业务流程IT质量运营的关系.docx

业务流程IT质量运营的关系.docx

《业务流程IT质量运营的关系.docx》由会员分享，可在线阅读，更多相关《业务流程IT质量运营的关系.docx（9页珍藏版）》请在冰豆网上搜索。

业务流程IT质量运营的关系

业务、流程、IT、质量、运营的关系

业务、流程、IT、质量、运营的关系

本文为华为轮值CEO徐直军在华为业务管理纲要研讨班上的讲话全文理如下：

公司明确了企业发展的目标是流程化组织建设。

如何理解呢？

我认为流程化组织建设的目标可以分解为：

价值创造流程简洁高效、组织与流程匹配运作高效、管理体系集成高效、运营管理卓越、持续改进的质量文化与契约交付的项目文化已经形成。

公司从十多年前的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自己整个网络部署的端到端流程。

我一看，发现这个流程和我们要的不是差不多吗？

那我们为何不

既然不是核心资产就通通共享，是核心资产就在核心资产保护的环境下也共享起来。

通过考核共享率，这样就没有特别极端了，合理多了。

要把信息安全构筑在流程中，流程走到哪里，核心信息资产就定义到哪里，保护到那里。

核心资产怎么定义？

由业务部门来定义，基于流程来定义。

网络安全也是一样的。

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

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定义Howtodo，Discipline的建设可以授权给各职能部门进行建设。

因此，流程的授权可以分两个维度，一个是基于经营组织的划分进行主业务流的授权，另外一个是基于Discipline的划分对各职能组织进行授权。

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

以前代表处给老板汇报，反映流程太长，流程有问题，他首先骂的是流程IT部，因此流程IT部老是挨批。

最近我们已经讨论清楚了流程的责任人是业务主管，于是我给老板建议，他若再看到哪个流程有问题，就给业务部门主管直接打个电话，骂这个业务部门的主管。

既然我们定义了流程的责任人是业务主管，那以后出了问题首先应该找业务主管。

流程IT部不可能单独开发一个流程出来让大家用，只有业务部门与流程IT部一起开发出来的流程才有可能用，业务部门才有可能执行。

我们已经明确了业务流程的责任人是业务主管，那以后流程有问题就要找业务主管解决。

不是实满际业务的执行者,就不要对业务部门的流程指手画脚,反而会招致更多的反对与不。

我们强调流程要业务部门来主导设计，为什么还要有流程IT部门和顾问公司呢？

是因为我们对业务的理解还存在片面性。

我们怎么理解自己的业务？

就是我们自己做了啥，我们的职责就是啥。

我们在梳理政府事务的流程的时候，就发现政府事务部门仅把自己原来怎么做的变成了自己的流程。

后来我们请IBM做顾问后，发现整个政府事务部在要负责的事情中少了百分之七八十。

我们在顾问的帮助下把业务框架搭起来后，我们发现好多工作都没做。

原来法务也是这样的，我们法务只管诉讼，不管预防。

由于各级业务主管的视角还只聚焦在做了啥，理解到了啥，想到了啥，很难全面，因此我们需要顾问公司。

顾问公司在其它公司做了类似的事情，他们知道别的公司有哪些环节，可以给我们一个Benchmark,建议我们是否需要考虑这些环节，并给些建议方案。

流程IT部门干啥呢？

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

我们做变革也好，做流程优化也好，应该是业务部门、流程IT部门、顾问这三者的结合，这三者的结合是很有价值的。

但是我们强调主导的是业务部门，只有业务部门自己内心愿意做，做好了才愿意推行，推行了有问题才愿意去面对。

否则强加一个流程给业务部门，业务部门不可能推行，也许只可能反对，只要有一点点困难，就会指责流程。

最后，核心的核心还是要问我们自己：

我们到底是流程的奴隶还是流程的主人。

如果我们是流程的主人，那么流程就不是身外之物，不是被动要求的，我们就会主动建设、优化和推行流程。

同时，也只有正确理解业务流、流程、IT、质量、运营之间的关系，才能更有效地建设流程、遵从流程，在流程中构筑质量，并通过IT固化流程，有效落实企业管理的目的是流程化组织建设。