对于IT规划需要系统的方法论支撑，现在谈IT规划方法论的也比较多了，在这里做一个学习后的思考和记录。前面在畅想博客还专门看到一篇关于IT规划没有真正发挥作用的文章，规划了的反而不如走一步算一步的，这也再次说明了大量的规划类的文档和资料的一种虚浮的现实。文档很漂亮，规划也很系统，发展愿景也很美好，但是就是没有为企业代理真正的价值。因此核心思想仍然应该是企业战略驱动业务，业务驱动IT，IT规划和建设以真正的创造和实现企业价值为核心驱动力。

方法论是很好的东西，也是我谈的比较多的一个词。但是现在我时刻的提醒自己方法论本身仅仅是过程而不是目标，方法论给我们了高屋建瓴和系统思考，但是更重要的是逐层分解后的行动能否真正落地，行动后的效果能否达到最后的目标。大道无为，但是当你没有达到这个境界的时候你需要借助方法论，但是方法论里面的活动单元如何串联起来才是真正重要的问题，否则方法论仅仅是一群资料的集合而毫无意义。

不可否认的是IT规划或咨询也可能受到权力和政治的影响，完全体现高层管理者的思维意志，咨询或规划过程本身已经变得不再重要，仅仅是一个反推已知目标的奇怪过程；或者更简单的完全照搬业界的标准做法和最佳实践，根本不考虑企业战略和业务目标。正如经常大学所做的软课题一样，对于规划的结果仅仅能够是文档，而对文档的规划内容在短期又无法真正的检验其对错，其真正的有效性和价值也都会是让人感觉到很迷茫的东西。那贡献呢？或许通过结构化的方法把企业的现状，业务，流程，架构和组织等都梳理了一遍还能够提供些价值。

1.企业战略驱动整个规划过程，企业战略驱动IT战略，如何驱动？这个就要基于现状和问题分析，包括业务，IT，管理等各个方面的现状调研，抛出问题，根据问题提出IT战略。企业战略和IT战略一定是匹配的，IT战略也必须为企业战略服务，这个在现状调研完后直接抛出目标，作为后续业务流程分析和IT差异分析的战略指导。充分体现由上至下的结构，而不是目标和战略都不清楚就开始照搬业界。所以在这个阶段我们看到访谈的重点里面必须有高层领导的参加。

2.大的IT战略愿景确认后开始分解和实践，首先要进行了仍然是业务规划和建模，而这个步骤里面最重要的仍然是流程，而流程是动态的对象，在流程背后还有一个静态的流程承载的东西即业务数据。首先要认识到企业流程分析需要有结构化的思路，有从上向下的展开的思路。到了流程中的具体一个活动单元又要注意输入，输出，输入和输出准则，具体的活动内容等多个方面进行阐述。通过这块我们期望的是为企业形成一套标准的流程和规范体系。而这也是流程管理常强调的重点，包括ISO，流程管理，CMMI很多知识都可以在这里使用和借鉴到。

3.流程重组BPR又是一个概念，但是也是很容易落入概念本身而忽视了具体的落地细节。在没有对现有流程进行详细诊断而逐层解剖问题的情况下，盲目的照搬业界的最佳实践是我们常犯的毛病。这也是导致我们的规划华而不实的一个重要原因。因此BPR不是一个独立的阶段，而是在我们做现有流程分析和诊断中逐步发现问题，分析问题和提出解决方案的一个过程。BPR觉得不需要的是完全的革新，而是需要我们各个点逐步的小改进，这个需要的支撑就是业务建模中的两个重要内容。一个是静态的业务对象和数据建模，一个是动态的业务事件和流程建模。

4.IT我们强调的是固化业务和流程，但是IT应该是我们管理思想和业务流程驱动出来的，管理的好坏直接影响到IT系统。因此在流程分析和重组先行是必须的，僵化或低效的流程下不可能产生高效的IT。对于流程分析后需要其实涉及到很多改进，包括流程本身，业务组织架构，岗位角色，业务分解和整合等多个方面的内容，而我们需要观察的则是流程合理后哪里还存在效率瓶颈。我们需要通过TOC约束理论的思想来找寻我们流程的效率瓶颈，因为IT最拿手的就是提升效率，通过瓶颈分析产生了IT需求才会过渡到具体的IT规划阶段，而这个时候也很明细，IT完全是业务和价值驱动的，不是凭空构想的而无法落地。

5.到了IT规划阶段后，问题应该就简化下来了，因为IT需求和优先级已经基本明确了，需要的就是就是进行具体的各个维度的IT规划。而这个之前我们需要通过IT愿景先拿出一个IT的总体架构和IT规划总图，然后再逐步展开。首先讲IT产品和项目的规划，这里面可以参考IPD里面标准的产品规划方法论，从需求转化到组合分析，进行路标规划，考虑资源后进行具体的项目和版本规划。其次还有我们的具体的平台规划和技术规划，还有我们的IT基础设施规划包括硬件，网络等各个方面的内容。

业务流程分析是IT规划里面不可缺少的内容。分析的目的是理解现状和发现问题，而问题是什么呢？是我们对业务目标的期望和现在流程实际效能之间的差距。因此流程诊断的重点就是基于流程本身要创造业务价值这个目标来解决如何发现问题的问题。

1.流程要体系战略和目标驱动，流程的总体框架设计需要和公司总体的战略相匹配，流程的最终运行和实施需要能够实现战略分解处理的各个目标和子目标。这是我们在做流程诊断时候必须考虑的问题，也是为何要在流程分析前首先明确企业的战略愿景的发展规划的重要原因。

2.流程或流程中的活动是否增值，流程实际的价值在哪里？在波特提出价值链分析法后，讲企业内外的活动分为基本活动和支持活动。基本活动涉及企业生产、销售、进料后勤、发货后勤、售后服务。支持性活动涉及人事、财务、计划、研究与开发、采购等，基本活动和支持性活动构成了企业的价值链。而我们诊断和关注的一定是流程是否真正的增值，首先我们关注点要放到增值的基本活动上。同时要关注基本流程中哪些是不增值的活动，或者增加的活动哪些在流程里面还没有体现。

3.流程是否端到端？A到B不是端到端，A到B再回到A才是端到端。因此关注端到端就真正的会关注的流程的一个重要特性即闭环，而只有闭环通过最终的验证和确认才能够后续更好的去评估和改进流程的绩效。对于企业的高端流程来讲，和波特的价值链流程图是一致的，即起点是客户的需求，最终实现的是客户的价值。从客户发起再到客户结束，形成端到端的闭环流程。只有这样流程才可能更好评估和持续改进。

4.谁对流程负责？这个是我们诊断流程问题的一个重要突破口，差的流程往往就是涉及众多的人和步骤，但是最终却没有一个人为流程负责，下游往往也有足够的理由推卸到上游。当一个跨越了多个部门和单位的流程时候往往更是如此，各个部门都以自我利益为中心，部门壁垒无法优化，这些可以讲都是低效流程的顽疾。所以在流程诊断中不可避免的要再次的审视组织结构，分析现有的岗位角色和职责定义，同时为了避免出现无人负责的流程，需要进一步加强对流程中各个活动的角色，职责，输入和输出准则的定义。

5.流程评估的平衡问题。对于流程不可避免的涉及到多个评价维度，比如成本，速度，质量等各个方面的内容，流程臃肿或低效的一个重要原因也就是各个维度都想做好，都想拿满分，最终的结果就是什么都做不好。因此在做企业战略分析和目标分解的时候，需要关注到流程绩效的各个维度的权重，体现2/8原则，关注关键问题。

对于业务流程的建模一定是从顶向下逐层分解的，首先通过价值链分析法得出企业重要的高端流程图。然后对高端流程图进行分解，重点关注价值链中的主体增值的业务主线，形成以阶段和子流程为标准的LEVEL2流程图。其次对各个子流程画出详细的业务流程图或活动图。在这个至上而下逐层分解的过程中，我们发现有两个问题产生了，一个是标准化的流程本身确实，表现形式就是在做这件事但是没有规范文件支持；另外一个就是我们需要的内容即流程已经有，但是可能没有实现自动化，信息传递缓慢，而这正式我们需要的IT需求。

关于企业业务流程的的识别，可以从业界的一些标准和同类企业的一些典型出发，比如APQC流程成熟度模型，价值链的高端流程分析等。这些让我们很容易的建立起企业业务模型和流程的总框架。如果我们仅把企业的流程从上到下分解为三个层次展开，则第一个层次可以直接解决价值链分析思路形成高端流程，第三个层面已经到了操作和执行层面从已有的一些岗位职责和工作指导手册里面也很容易找到，而最困难的个人任务则是第二个层次的抽象。不同的行业都可能会有生产，研发和营销等活动，但是具体的活动和业务流程却千差万别。

将企业看做一个大的黑盒子，这个黑盒子会有外部的供应商，客户，已经其它类似物流，财务审计等多个角色存在着交互。不管是外部的客户还是内部的工作人员都可能发起各种事件，这些触发的事件共同形成了一个上下文的关系图。通过这种方式我们就可以来识别企业重要的业务事件，而业务事件恰好是业务流程的触发点，标识出业务事件就能够帮助我们识别出业务流程，而业务流程又是为了响应业务事件而触发的一系列业务活动，它通常是由不同部门，不同岗位的人共同来协作完成的。而业务活动是业务流程的重要组成部分，它一般是由一个人来完成的，一个业务活动本身又包含了多个业务步骤。

识别出一个业务触发事件，就识别出了一个业务流程，比如体检者申请体检是一个业务事件，申请是一个触发点，可以朝后面逐渐展开将重大的业务活动串联起来，包括体检申请，收费，体检，化验，出具体检结论，拿单等一系列的活动。从这我们也可以看到流程本身是端到端的，从用户提出体检申请，到最终拿到体检结果，实现了价值服务。

对于流程的粒度问题是在流程分析和识别中另外一个重要问题。在业务事件和流程识别的时候都可能是头脑风暴的思路，因此头脑风暴完成后必须要按一定的准则进行重新的归纳，整合和拆分。保证流程的粒度尽量一致。而对于流程的粒度可以参考的就是流程本身涉及到的业务活动数，涉及到的跨部门和岗位的数量。涉及到外部客户驱动的端到端的应该是属于一个粒度，涉及到跨越多个部门协调完成的流程应该是一个粒度，如果仅仅是部门内的流程又应该是一个粒度。

在价值链中我们已经识别了核心的高端流程，后续在朝后面分解的过程中有些流程可能需要分解到4层5层，而有些往往分解到1-2层就已经可以到具体的业务活动。但是我们期望的是不管是哪个业务领域，分解到同样层次的流程应该尽量是同样的粒度和复杂度。这里在结构化产品开发中的分解思路是可以借鉴的，即产品开发-》阶段-》流程-》活动-》步骤。而流程这里根据复杂度不同又可能还需要划分到具体的子流程。

特别强调的是，在流程分解的时候要避免把流程的分类作为流程的分解单元。比如在分解销售流程的时候，直接将分销，直销或其它销售方式分解为流程的第二层。正确的方式应该是多去考虑流程的生命周期阶段，流程从触发产生到创造价值实际经历的重点阶段。同时流程分解完成后时刻都要重新审视粒度问题，比如生产流程如果分解为整机生产，半成品生产，工艺，仓储，对外加工。里面就会有很多问题，因为整个分解使用了三个不同的准则，一个是对外还是对内，一个是整机还是半成品，一个是生产，仓储和工艺。这是三个不同的维度。而我们希望的维度则是最后一种分解方式。