再谈IT规划的核心逻辑

前面我写文章谈过IT咨询规划的核心逻辑，说到了IT规划本身就是一个问题定义，问题分析和解决的过程。是一个通过现状分析，了解差距，明确目标，达成目标的目标驱动的过程。下周再谈下IT战略规划的核心步骤和关注点。

IT规划的指导思想

对于IT规划，基本遵循的思路还是从业务到技术，从流程到IT，围绕价值链优化和分析的核心驱动模型。今天我们谈IT规划核心指导思想应该转化为企业架构上面，企业架构提出本身就是为了解决业务和IT两张皮的问题。企业架构整个方法应该融入了整个IT规划思想中。其二，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom模型等。

今天我们谈IT规划，在前面两点的基础上融入云计算和SOA的核心思想，这两个思想在解决我们多年前规划的多个竖井式的IT系统的集中化和协同化的问题。如果现在规划还在走以前的老路是有问题的。那么今天规划重点就是一开始就需要考虑集中化的问题，考虑SOA集成和协同的问题，考虑SOA思想融入到IT规划，甚至后续IT应用系统建设的问题。如果我们今天进行的IT规划还不不断的出现重复建设和信息孤岛，流程断点和业务无法协同。那么整个IT规划无疑使很失败的。

IT规划的核心步骤

第一阶段还是现状分析和调研，那我们这一个步骤的核心究竟是什么？应该遵循什么样的方法进行现状分析和调研。在这里我的考虑分为如下几个方面，首先是要把战略目标，业务目标，业务子目标调研清楚，如果客户不清楚我们可以给出参考目标；其次是把实际的现状搞清楚，客户现状流程和业务，客户现状的IT支撑现状究竟是如何的？最后是把问题搞清楚，问题包括了几个方面的内容，其一是在当前目标和当前现状清楚下客户意识到的问题，其二是在我们提出参考目标和业界实践下，客户意识到潜在存在的问题。

有了以上现状分析和调研，才谈得上差距分析。那么差距分析就包括了当前目标和当前现状间的问题和差距分析；业界参考目标和最佳实践和当前现状下的差距分析；IT现状对当前目标支撑的差距分析；IT现状对参考目标和业绩标准的差距分析。这些都分析清楚后得到双方认可的最终业务战略目标和业务子目标，由业务目标传递到对应的IT规划和建设目标，而后续的IT规划即解决两个问题，IT建设解决当前业务和IT间的差距，IT建设解决后续战略目标和IT间的差距。改进也一样，有些是不需要业务改进直接进行IT建设和改进，有些则是业务优化和改进先进行，IT配合业务优化改进措施的落地。从这个思路基本也就清楚BPR的考虑和定位，并不是所有场景都一定要让用户进行BPR。

第二阶段为业务流程优化和设计，对应到企业架构中为流程建模和业务架构，这个时候我们不需要考虑太多IT层面的事情，重点就是考虑我们的业务流程如何进行优化，业务架构如何进行重新整合，以满足我们已经明确的业务目标。在这个步骤中可以看到业务流程和活动，业务职能单元，组织岗位角色，业务核心单据和数据，业务协同都是我们需要考虑的问题。在这里希望融入部分SOA核心思想，即企业是一个完整的有输入有输出的产生核心业务价值的价值单元，而这个价值的实现是通过企业内部一个个相互协同的业务功能职能单元提供出来的，这些业务单元相互协同和组合完成核心价值的提供。这也是为何在端到端流程分析，流程分解和EPC分析后，重新对业务功能单元进行组合形成业务架构和业务组件，然后通过端到端业务流程对业务组件间的协同进行验证的原因。

第三阶段为IT规划和架构设计，很可惜的是看到太多的IT规划咨询报告，到了这一个步骤后出现严重脱节，即和第一，第二两个阶段出现断层，没有一种通过科学分析方法平滑的映射到第三个层面。在我前面的一篇文章IT应用机构分析思路上有谈到过这个内容。在这里再次说明几个核心内容。首先进行总体应用架构的规划，应用架构和业务架构对应，但是不一样的地方时流程优化分析和业务架构不会考虑太多平台层面的内容，而这个应用架构必须考虑，两大核心就是集中化和协同，两大技术就是云计算和SOA，这些内容需要引入到IT总体应用架构规划中。

我们经常谈传统IT建设竖井式，相互之间很难协同。而引入SOA核心并不是没有竖井了，一个个核心的业务组件和能力提供单元还是独立的，但是完全下沉到最底部了。上面是领域层，是SOA服务层，完全实现了集中化和整合，也实现了解耦。通过服务灵活的进行更高层的应用的组装和协同。

业务架构解决了业务能力提供单元的问题，但是企业真正关心的端到端业务流程的顺畅，即业务单元要能够很好的协同起来。那么就需要对业务组件进行跨组件的端到端流程交互和协同分析，一通过协同分析核心交互点就出来了，对核心交互点进行分析和整理，在应用架构中的另外一个核心内容集成架构也就基本出来了。

任何流程都包括两个方面的内容，一个是业务的问题，一个是数据的问题，业务功能和协同在前面已经解决，而数据的问题是另外一个维度，数据的识别是通过业务流程分析，而数据的建模有专门的数据架构方法来支持。业务协同最终将体现到底层数据的关联关系和相互映射，底层数据模型出现问题直接影响高层业务协同。对于数据架构分析方法不多说，除了要关心主数据外，还必须关系跨业务模块的核心业务单据数据，这些都是企业核心数据。数据的问题最终都将对应到应用架构和数据架构，SOA解决的是业务集成和协同，而数据集成是其它解决方法，包括传统的BI，数据中心，MDM主数据系统建设等。

前面问题都清楚后，应用架构仍然体现逐层展开的核心思路，总体应用架构清楚后细化到第二个层次单个应该的功能架构和集成架构。这个时候细化相当重要，真正解决业务目标和业务希望功能的落地问题。功能架构包括功能模块和具体核心功能点，这些梳理出来后我们需要明确当初提到的业务架构和业务需求最终落地到哪里？其次，以某个应用为主体核心，来观察该应用和外部应用间的集成关系，已经集成后如何协同的问题。前者为功能性需求，后者为接口需求。

这个做完后再反过来看，应用中规划的功能点是为了映射和满足业务架构中的哪个业务功能或需求，业务架构中的功能是为了满足哪个业务目标。这两个问题都回答了，那么就基本回答了规划的功能点无用，不清楚功能点和目标之间关系的问题了。

IT规划和架构设计最后还有一个内容即技术架构，传统企业架构中说的技术架构偏基础设施和部署架构，那么整个企业大IT基础设施，部署架构都在这里考虑。前面应用架构规划明确完成后作为基础设施规划的基础，而技术架构规划又是涉及到云计算，特别是IaaS层规划。

第四阶段我不谈，前面所有分析和规划都到位后，简单的讲就是所有要做的事情全部梳理出来了，包括业务方面，IT方面各种需要做的事情，业务和IT需要协同的事情。这些事情我们应该根据企业目标和演进路线如何评估优先级，如何形成一个个独立的子项目，如何考虑子项目的协同，如何在考虑企业预算和成本情况下分阶段建设和实施。这些都是实施阶段要解决的，前面三阶段做到位，第四阶段就简单，只是需要一个核心知识能力，即项目组合管理和项目群管理能力。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密