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

业务、流程、IT、质量、运营的关系业务、流程、IT、质量、运营的关系公司明确了企业发展的目标是流程化组织建设。如何理解呢？我认为流程化组织建设的目标可以分解为：价值创造流程简洁高效、组织与流程匹配运作高效、管理体系集成高效、运营管理卓越、持续改进的质量文化与契约交付的项目文化已经形成。公司从十多年前的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、质量的定义就是符合要求，质量要求必须构筑在流程中。内控、信息安全、网络安全是特定形式的质量要求。质量管理大师PhilipCrosby说，质量的定义就是符合要求。任何业务都是要追求质量的，质量要求必须跟随业务流构筑在流程中。为了让每个环节的交付能够刚刚好的满足下游的要求，就需要定义每个作业环节的输入与输出交付件及其质量要求，并基于质量管理的方法，确保每个作业环节达成质量要求。质量管理包括质量策划、质量控制、质量改进，质量策划致力于策划如何达成质量要求，质量控制致力于确保达成质量要求，质量改进致力于如何更好的达成质量要求。为了让每个作业环节知道其作业的质量要求，需要定义质量标准及Checklist。同时需要建设并积累支撑该作业环节达成交付要求的为工具、方法、指导书等使能内容，这些属于支撑作业环节达成交付要求（交付要求属于What）的Howtodo部分。质量分过程质量和结果质量，过程质量如果不构筑在流程中，把业务都跑完了，质量单独在外面存在是不可能的。质量要求也好，质量标准也好，我们要构筑在流程里面，过程质量也有要求有标准，能够得到保证。过程质量有保证才能确保结果质量。基于过程质量的管理能带来结果质量，由于追求结果质量迫使我们到源头来管控过程质量。内控是内部要求，目的是防止腐败，控制风险。我们最早搞内控的时候，把内控和流程分离。内控在这边搞得热火朝天，流程在那边搞得热火朝天，后来发现存在问题，就把两者合并了。内控就是我们公司内部要求的风险管理和防腐败。本质就两个点：一个叫职责分离，目的是防腐败和财务风险；另一个是关键控制点，在关键控制点要有控制要素和控制程序。内控也必须构筑在流程中。内控若在流程外，不在流程里，是不可行的。我们原来支撑流程建设的是流程部，支撑内控建设的是内控部，两个部门各行其是。后来发现问题后，我们把流程建设和内控建设部合并。至于SACA、CT干啥？就是跟质量管理一样，看流程执行到关键控制点和需SOD的时候是否按流程内控要求遵从了。信息安全是内部管理要求，是围绕核心资产进行管理和保护。核心信息资产产生于哪里？是产生于业务流程中的。所以信息安全也要构筑在流程中。以前信息安全管理是修万里长城，修了好多年，防不胜防，发了100多个文件。后来发布了EMT决议，把信息安全的管理思路调了180度，要求不要到处防，不要去修万里长城，首先只防核心资产。要防核心资产，首先要把核心资产识别出来，只有识别出来了才好进行保护，要识别出来及很好地保护还是得基于流程。信息安全部转变观念，不修万里长城了，把100多个信息安全的文件清得快没了，这也是为什么大家感觉好点了。同时把信息安全和共享两个职责都放到信息安全部，要求既要抓信息安全，也要抓信息共享，信息安全部的考核指标是既有信息安全，又有共享，这样就好多了。现在到各个部门去看，很少有人反馈说搞信息安全搞得啥都看不到。既然不是核心资产就通通共享，是核心资产就在核心资产保护的环境下也共享起来。通过考核共享率，这样就没有特别极端了，合理多了。要把信息安全构筑在流程中，流程走到哪里，核心信息资产就定义到哪里，保护到那里。核心资产怎么定义？由业务部门来定义，基于流程来定义。网络安全也是一样的。网络安全我们强调的是产品在各个流程中要具备网络安