公司明确了企业发展的指标是流程化组织建设。若何理解呢？我以为流程化组织建设的指标能够分化为：价值创造流程简洁高效、组织与流程匹配运作高效、治理系统集成高效、运营治理卓越、持续改进的质量文化与左券交付的项目文化已经形成。公司从十多年前的IPD、ISC刷新起头就在向这个指标在致力，当前在发展的IFS、CRM刷新则是实现这个指标的沉要伎俩。为了实现流程化组织建设这个指标，公司在各级组织中建设了质量与运营组织，这是为实现流程化组织建设的一个极度沉要的行动。除此表，还必要公司高低对业务、流程、IT、质量、运营等一些根基概想以及它们之间的关系有一个正确的意识，以领导我们正确的行动。为此，特把我在业务治理纲领钻研班上对业务、流程、IT、质量、运营等概想的讲话整顿出来，供各位参考。

一、业务流是客观存在的，所有和客户有关的业务流，天然是从客户到客户的

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

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

所有和客户有关的业务流，天然是从客户到客户的，我们萦绕业务流发展工作的时辰必须对准客户，以客户为中心。由于我们正本是萦绕客户创造业务价值，不能脱离客户。

鉴别业务流极度关键，在流程、IT、质量与运营工作中，业务流是所有工作的原点和基础，紧紧的抓住业务流，就不会偏离工作的方向。流程描述的是业务流， IT承载和使能的是业务流，数据是业务流中流动的信息，质量要求凭借于业务流，质量治理基于业务流，运营也是基于业务流发展。

二、流程是对业务流的一种阐发方式，是优良作业实际的总结和固化，主张是为了分歧团队执行流程时得到成功的可复造性。越切合业务流的流程就越顺畅。

我讲过两个案例，其一是TG反波胆·(中国区)官方网站ITR流程（网上问题处置流程），以前底子不关注客户，所有的问题定级都是基于分歧产品分歧问题来进行技术等级定级，而表态互吵架，吵得一蹋糊涂，其实问题是从客户那里触发的，客户是最急的。我们不去关注问题对客户的影响，以对客户的影响来评价级别，而在内部吵。以前所有做过研发的都和GTS吵过（由于研发有这个查核指标）。

后来网上问题处置流程和IT系统最大的扭转是：以客户对故障的定级来定级？突Ш苊飨云溆屑付嘤没П挥跋炝。通过数量、功夫、沉要性三个身分来定级，凭据这三个身分分几档，自动就定级了。而后所有的IT，所有的流程都萦绕急剧去知路网上产生的问题、急剧解决网上问题，所有内部查核的事件先放在一壁。流程和IT系统先解决这个问题，而后能查核就查核一下，查核不了就算了。流程IT系统支持公司急剧响应客户需要，知路网上产生的问题，升级上来，急剧去解决，其它所有都要让位于这个主张。

其二是交付流程。原来进行LTC刷新的时辰，问交付流程要不要纳入LTC，我们以为自己的交付流程已经很好，只有在原来的基础上批改一下就OK了。其时交付流程立的是一个优化项目，安身于把原有的流程优化一下就能够了。后来项目组看TG反波胆·(中国区)官方网站交付流程，越看越不合劲。第一次项主张CHARTER和后来在3T汇报的CHARTER面目全非，齐全变了。其中发现TG反波胆·(中国区)官方网站交付流程根基上没有，只有一个项目治理流程和一个站点流程，没有交付流程的，就相当于研发没有研发流程，只有一个研发项目治理流程。

后来终于搞领略了，交付流程要沉新整顿。刚起头搞的时辰没找到方向，不知路交付流程到底该怎么搞？后来我有次看到T-MOBILE自己整个网络部署的端到端流程。我一看，发现这个流程和我们要的不是差不多吗？那我们为何不以T-MOBILE的流程为参考呢？正本网络的部署是客户的事件，我们只是被他们挪用的。一个客户从他明确需要起头一向到网络交付运营，正本就是他们自己的事件，我们只是在他们整个流程中实现其中一两个或者多个环节而已。所以我提出TG反波胆·(中国区)官方网站交付流程要从运营商视角，从运营商自己的流程来看TG反波胆·(中国区)官方网站流程。后来他们再把德电的照拂请过来，再真正从运营商视角来看他从明确需要起头一向到运行守护保险的整个流程，基于运营商视角来设计交付流程。对于欧洲运营商，TG反波胆·(中国区)官方网站交付只是运营商整个网络部署流程里的一个环节。而对于马来这些处所的运营商，他们不足端到端的整个流程，那我们就需多做几个环节。

这些应该是业务主管最明显，流程IT部是搞不明显的。流程是对业务流的一种阐发方式。越切合业务流的流程越顺畅。若是流程刚好切合业务流，就不应该再去简化流程。业务流客观存在是5个环节，你肯定要缩减到3个环节，或者硬要报答地搞成7个环节，那它肯定要回到它的5个环节。所以流程要客观地阐发客观存在的业务流。它跟客观存在的业务流越靠近，流程就越通顺，越精简，越能体现真实。若是流程与客观业务流背路而驰，不搞流程反而好，要搞满是有余的。像我们以前网上问题处置流程就是多的，满是内部吵架，满是为了内部治理。我们要把真实的业务流理解得越来越透。

另表以前我们把流程和部门捆死，使得我们很被动：部门说改就改，部门一改就得改流程。我们此刻流程设计的新思路，是在流程里看不到部门，不与组织直接挂钩，在流程里只界说角色，组织要来承载流程角色。我们强调流程决定组织，就是组织首先要承载流程里面界说的各个角色要推广的职责。同时组织不能跨在两段流程上，不要把组织承载的流程是这边一段，何处一段，要么就一段，要么就两段，不要搞成一壁一段。

三、数据是在流程中跑的信息， 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。

公司明确了企业发展的指标是流程化组织建设。若何理解呢？我以为流程化组织建设的指标能够分化为：价值创造流程简洁高效、组织与流程匹配运作高效、治理系统集成高效、运营治理卓越、持续改进的质量文化与左券交付的项目文化已经形成。公司从十多年前的IPD、ISC刷新起头就在向这个指标在致力，当前在发展的IFS、CRM刷新则是实现这个指标的沉要伎俩。为了实现流程化组织建设这个指标，公司在各级组织中建设了质量与运营组织，这是为实现流程化组织建设的一个极度沉要的行动。除此表，还必要公司高低对业务、流程、IT、质量、运营等一些根基概想以及它们之间的关系有一个正确的意识，以领导我们正确的行动。为此，特把我在业务治理纲领钻研班上对业务、流程、IT、质量、运营等概想的讲话整顿出来，供各位参考。

四、质量的界说就是切合要求，质量要求必须构筑在流程中。内控、信息安全、网络安满是特定大局的质量要求。

质量治理大家Philip Crosby说，质量的界说就是切合要求。任何业务都是要钻营质量的，质量要求必须追随业务流构筑在流程中。为了让每个环节的交付可能刚刚好的满足下游的要求，就必要界说每个作业环节的输入与输出交付件及其质量要求，并基于质量治理的步骤，确保每个作业环节达成质量要求。质量治理蕴含质量策动、质量节造、质量改进，质量策动致力于策动若何达成质量要求，质量节造致力于确保达成质量要求，质量改进致力于若何更好的达成质量要求。为了让每个作业环节知路其作业的质量要求，必要界说质量尺度及Checklist。同时必要建设并堆集支持该作业环节达成交付要求的为工具、步骤、领导书等使能内容，这些属于支持作业环节达成交付要求（交付要求属于What）的How to do部门。

质量分过程质量和了局质量，过程质量若是不构筑在流程中，把业务都跑完了，质量单独由名义存在是不成能的。质量要求也好，质量尺度也好，我们要构筑在流程里面，过程质量也有要求有尺度，可能得到保障。过程质量有保障能力确保了局质量；诠讨柿康闹卫砟艽戳司种柿，由于钻营了局质量迫使我们到源头来管控过程质量。

内控是内部要求，主张是预防凋落，节造风险。我们最早搞内控的时辰，把内控和流程分离。内控在这边搞得如火如荼，流程在何处搞得如火如荼，后来发现存在问题，就把两者归并了。内控就是我们公司内部要求的风险治理和防凋落。性质就两个点：一个叫职责分离，主张是防凋落和财政风险；另一个是关键节造点，在关键节造点要有节造身分和节造法式。内控也必须构筑在流程中。内控若在流程表，不在流程里，是不成行的。我们原来支持流程建设的是流程部，支持内控建设的是内控部，两个部门各行其是。后来发现问题后，我们把流程建设和内控建设部归并。至于SACA、CT干啥？就是跟质量治理一样，看流程执行到关键节造点和需SOD的时辰是否按流程内控要求遵从了。

信息安满是内部治理要求，是萦绕主题资产进行治理和；。主题信息资产产生于哪里？是产生于业务流程中的。所以信息安全也要构筑在流程中。以前信息安全治理是建万里长城，建了好多年，防不胜防，发了100多个文件。后来颁布了EMT决定，把信息安全的治理思路调了180度，要求不要四处防，不要去建万里长城，首先只防主题资产。要防主题资产，首先要把主题资产鉴别出来，只有鉴别出来了才好进行；，要鉴别出来及很好地；せ故堑没诹鞒。信息安全数转变观点，不建万里长城了，把100多个信息安全的文件清得快没了，这也是为什么各人感触好点了。

同时把信息安全和共享两个职责都放到信息安全数，要求既要抓信息安全，也要抓信息共享，信息安全数的查核指标是寂仔信息安全，又有共享，这样就好多了。此刻到各个部门去看，很少有人反馈说搞信息安全搞得啥都看不到。既然不是主题资产就统统共享，是主题资产就在主题资产；さ幕肪诚乱补蚕砥鹄。通过查核共享率，这样就没有出格极端了，合理多了。要把信息安全构筑在流程中，流程走到哪里，主题信息资产就界说到哪里，；さ侥抢。主题资产怎么界说？由业务部门来界说，基于流程来界说。网络安全也是一样的。网络安全我们强调的是产品在各个流程中要具备网络安全的能力、要有防御能力。

五、运营是对准业务指标，周而复始地沿着流程转，通过持续、周期性的业务运营治理活动，以达成业务指标。

前面会商了流程、IT、数据与质量，下面再谈谈运营。所谓运营，就是指业务的运行过程中的陆续性循环活动，运营的指标是为利益关系者创造价值。说的直白一点，运营就是流程和治理系统Run的过程，没有运营，流程和治理系统就是死的（静止的），企业的价值创造就无法实现，也就无法实现业务指标。因而，在一个企业中，运营无处不在，大到一个企业的运营，幼到一个基层组织的运营。运营治理就是对运营过程的打算、组织、执行和节造，运营治理的对象蕴含业务流程（如IPD、LTC）和治理系统，运营治理的内容就是通过对运营过程和运营系统的有效治理，以实现投入产出的最大化，因而其关注的指标蕴含：质量、成本、用度、效能/效益、周期/速度、柔性、客户中意等，最终支持企业的贸易成功。

在一个企业中，战术规划流程DSTE是处于最顶层的流程，其将战术规划、业务规划、财经、HR、流程与IT萦绕从战术到执行实现有机的集成，以实现组织的业务指标。萦绕DSTE发展运营治理以实现组织的业务指标是运营治理中最沉要的部门，也能够称为绩效运营治理；贒STE发展运营治理以实现组织的业务指标的基础是基于各业务流程发展的运营治理，如基于IPD、LTC、ITR等流程的运营治理，如在LTC下发展的项目、项目群、项目组合的运营治理，以实现每个项目、项目群的业务指标。在谈分歧领域的运营时，能够在运营前面加定语以分辨，如项目运营治理、销售运营治理、营销运营治理、知识运营治理、客户中意运营治理等，在好多情况下也能够将运营省略，如销售治理、项目治理、质量治理、客户中意治理、知识治理等，这些治理活动自身就是运营治理的一个组成部门。

若是不沿着流程转就不是运营，TG反波胆·(中国区)官方网站IPD系统，在运营这块是清澈了，是理解透了，我们所有的业务都是在流程里转。但我们在区域现实上没达成共识，区域有商务治理、销售治理、流程质量、流程治理。销售治理不就是萦绕销售流程转的吗，商务治理不是管合同质量的吗？在产品线里这些都是归并的。只有是萦绕流程转的，就需有相应的支持组织，TG反波胆·(中国区)官方网站运营组织要全在运营里面，主题是要遵从流程能力转得起来。

遵从流程后发现和业务场景不匹配，作为主管，在自己授权领域内的，就直接优化好；在自己授权领域表，显著看到流程有问题，与业务场景不匹配的，就要去推动优化。当然要先遵从流程之后再提出流程的问题，若是都没有遵从流程就说流程有问题是空谈。若是有人对我说流程有问题，我会问他哪个流程有问题；玖鞒逃形侍獾暮枚，你要通知我那个流程有问题。只有遵从过流程，围着流程转过你才知路问题在哪里，若是不遵从就不成能知路流程有问题，不成能推动和优化流程。由于你转都没转过怎么知路问题在哪里？

这就是运营，几个主张，一个是沿着流程周而复始地转，其次是在遵从过程中发现有问题时解决或推动问题解决。若是我们真的不是流程的奴隶，而是流程的主人的话，我们会去关注流程到底怎么，关注流程是否切合业务场景，关注TG反波胆·(中国区)官方网站流程遵从以来还有什么问题，那我们公司流程遵从和流程优化的泥土就改善了。

六、流程确定角色，组织承载角色，流程与组织匹配能力运作高效

下面再谈一下我对组织设计与流程的匹配的一些理解。在流程与组织刷新中，必要遵循如下的过程：第一个蹊径是从战术启程，基于战术设计所选择的业务模式，确定主业务流，并鉴别业务流的关键能力，基于关键能力的差距和优先级确定刷新的规划，基于刷新，进行流程设计，并基于组织设计准则进行组织设计和流程的匹配。从一个企业的组织与流程架构设计来看，梦想的设计应该实现：从水平来看，每个流程在各Business组织间若何实现全球的一致性，从垂直看，每个Business组织若何实现各业务流程的有机集成。主业务流程是直接为客户创造价值的流程，所有组织要么必须工作在主流程中，要么就必须支持好主业务流以为客户创造价值，不然，这样的组织就是有余的组织。各职能组织若何参加和支持呢？项目化运作是最有效的方式，事实上，任何Business组织都是通过一个个项目/群来实显熹经营指标的，项目就是最基础的治理单元，执行主业务流程的是项目/群，而各类组合治理的主张蕴含组合设计、弃取、以及优先级排序，以使得满足客户需要并实现资源投入产出最大化。因而，各职能组织都必要参加到执行主业务流的跨职能部门项目中，为客户创造价值。

对于各职能组织的设计，必要基于如下主题理想：每个职能组织都要对E2E了局掌管，而不是段到段，各组织之间不是接力赛，而是类似足球赛，共同参加项目，通过项目组的跨职能组织的运作，一路执行主业务流，以实现业务指标。职能组织的设计基于业务流的必要的能力的一个或者几个专业领域（凭据治理的必要），为了让各职能领域可能有一个其执行的E2E的齐全的流程视图，能够引入Discipline（专业领域）的概想，对于每个专业领域，其对应于HR的一个职类（如软件、硬件），也可对应一个职能部门。流程界说What，Discipline界说How to do， Discipline的建设能够授权给各职能部门进行建设。因而，流程的授权能够分两个维度，一个是基于经营组织的划分进行主业务流的授权，另表一个是基于Discipline的划分对各职能组织进行授权。

七、业务主管是流程的责任人，照拂公司和流程IT部提供流程专家，以照拂大局提供专业服务输入标题

以前代表处给老板汇报，反映流程太长，流程有问题，他首先骂的是流程IT部，因而流程IT部总是挨批。最近我们已经会商分了然流程的责任人是业务主管，因而我给老板建议，他若再看到哪个流程有问题，就给业务部门主管直接打个电话，骂这个业务部门的主管。既然我们界说了流程的责任人是业务主管，那以来出了问题首吓爪该找业务主管。流程IT部不成能单独开发一个流程出来让各人用，只有业务部门与流程IT部一路开发出来的流程才有可能用，业务部门才有可能执行。我们已经明确了业务流程的责任人是业务主管，那以来流程有问题就要找业务主管解决。不是现实业务的执行者,就不要对业务部门的流程指手画脚,反而会招致更多的否决与不满.

我们强调流程要业务部门来主导设计，为什么还要有流程IT部门和照拂公司呢？是由于我们对业务的理解还存在单方面性。我们怎么理解自己的业务？就是我们自己做了啥，TG反波胆·(中国区)官方网站职责就是啥。

我们在梳理敌灾事务的流程的时辰，就发现敌灾事务部门仅把自己原来怎么做的造成了自己的流程。后来我们请IBM做照拂后，发现整个敌灾事务部在要掌管的事件中少了百分之七八十。我们在照拂的援手下把业务框架搭起来后，我们发现好多工作都没做。原来法务也是这样的，我们法务只管诉讼，不论预防。由于各级业务主管的视角还只聚焦在做了啥，理解到了啥，想到了啥，很难全面，因而我们必要照拂公司。照拂公司在其它公司做了类似的事件，他们知路此外公司有哪些环节，能够给我们一个Benchmark, 建议我们是否必要思考这些环节，并给些建议规划。

流程IT部门干啥呢？流程IT部门有些专家可领导业务部门在流程上该怎么设计，怎么阐发，及流程建设上必要把稳的一些事项。

我们做刷新也好，做流程优化也好，应该是业务部门、流程IT部门、照拂这三者的结合，这三者的结合是很有价值的。但是我们强调主导的是业务部门，只有业务部门自己内心愿意做，做好了才愿意奉行，奉行了有问题才愿意去面对。不然强加一个流程给业务部门，业务部门不成能奉行，也许只能能否决，只有有一点点难题，就会责怪流程。

最后，主题的主题还是要问我们自己：我们到底是流程的奴隶还是流程的主人。若是我们是流程的主人，那么流程就不是身表之物，不是被动要求的，我们就会自动建设、优化和奉行流程。同时，也只有正确理解业务流、流程、IT、质量、运营之间的关系，能力更有效地建设流程、遵从流程，在流程中构筑质量，并通过IT固化流程，有效落实企业治理的主张是流程化组织建设。

文章起源于网络