来源：信息化协同创新专委会

今天准备谈下IT规划咨询的核心方法论和思考逻辑。在这篇文章我不会详细的去谈当前主流的企业架构方法论理论框架和内容。而是根据多年IT咨询实践，将一些关键逻辑点和你分析。

为什么要谈核心IT规划和咨询逻辑？

可以毫不客气的讲，大部分的做IT规划咨询的人是不具备进行全局架构规划咨询能力的，这个一方面是需要你有大量业务和技术双领域的实践经验积累，一方面是需要你真正做过大型的咨询规划项目并在这个过程中将实践内容，各个架构之间输出关系想清楚。

系统学习下类似TOGAF课程当然有用，但是这不代表你具备了咨询规划能力。

理论可以指导实践，但是没有通过自我实践证悟的理论没有价值。

很多IT顾问完全叫PPT顾问都不为过，完全拿着已有的咨询规划模板到处套内容。如果你本身做同一垂直行业，比如拿着某家电制造行业的规划输出去给另外一家做咨询。这种场景下基本还能够像模像样的的输出一个规划报告。

但是生搬硬套最大问题就在于，你即使有了输出结果，你也无法自己详细论证清楚这个结果如何分析得来的，即无法实现自我论证。

类似的场景，我们可以看下讲课和培训，很多人能力强但是怕讲课，即虽然这类人可以快速的输出结果，但是具体是如何分析和解决问题的过程，这个确出来没有考虑过系统化。因此这类人本身能力也很难做到很好的知识分享和转移。

比如我们常说的架构规划里面这个业务架构图如何一步步形成的？这些接口你是通过什么方法一步步的分析识别出来的。这些问题大部分人无法清晰回答。即使对于TOGAF，我们也很少从官方材料里面看到类似业务架构，数据架构，应用架构和技术架构之间的内在逻辑关联在哪里。

整体规划方法论

IT规划涉及到咨询方法论、流程管理和分析、信息架构、应用系统分析和设计、技术架构、项目管理和实施等众多方面的内容。从企业战略到业务目标，从业务目标到IT目标，从IT目标到应用蓝图，从应用蓝图到分阶段实施落地，任何一个步骤的脱节将导致规划内容无法落地。

再完美的规划和架构，如果脱离企业业务目标，都不能带来企业业务价值的提升。此外，IT规划之难，不在于IT本身，而在于流程；不在于技术本身，而在于业务。

业务驱动IT是核心

对于IT规划，遵循的思路主要是：从业务到技术，从流程到IT，围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键步骤。

现状分析包括业务现状和IT现状，根据企业战略提出业务目标和发展规划，分析现状和目标之间的差距提出和整理问题集（定义IT建设目标），根据差距和问题给出规划蓝图，根据目标和问题分解到的子目标和子问题以及蓝图规划内容，多维度评估和确定后续的实施规划，定义IT系统建设实施的优先级。

IT规划始终围绕业务和IT两条线展开和协同

从以上的描述可以看出，整个IT规划始终围绕业务和IT两条主线，业务包括了业务流程，业务数据，岗位组织和角色，业务管控体系；而IT包括了数据架构，应用架构体，技术架构和平台，基础设施建设。业务驱动IT，端到端业务流程最终落地到应用系统的功能上，业务数据最终映射到数据模型并沉淀到数据库中。

各类架构标准规范体系和最佳实践是关键输入

随着各种思路的不断融合，IT规划核心指导思想应该转化为企业架构层面。

企业架构的提出，主要是为了解决业务和IT“两层皮”的问题，企业架构整个方法应该融入到整个IT规划思想中。此外，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。

针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom业务模型等。

与此同时，在前面基础上再融入云计算和SOA的核心思想，它将很好的解决我们多年前IT规划经验里的多个竖井式IT系统的集中化和协同化的问题。若现在规划仍走以前老路是不妥当的。那么，今天规划重点在开始之初就应该考虑集中化和协同的问题，将SOA思想融入到IT规划当中。当今的信息化规划，要务必避免出现IT重复建设和信息孤岛，流程断点和业务无法协同的局面。

中台和微服务发展趋势下，原有规划方法是否调整？

可以很明确的讲在新的中台和微服务发展下，原来的企业架构相关方法和内容必然做出调整。比如在我最近中台规划思考里面提出了业务架构和应用架构合并，基于SOA思想增加中台+服务+前台的分层逻辑规划，单独增加服务架构规划，在数据架构规划中增加数据库拆分规划等。

以上内容后续我会专门写文章来进一步详细说明。

调研和现状分析

现状分析的核心思路是把战略目标、业务目标调研清楚，如果客户不清楚我们可以给出参考目标；其次是把实际的现状了解清楚，如客户现状流程、IT支撑现状；最后是将潜在问题识别清楚：一是在当前目标和当前现状被识别后客户意识到的问题，二是在我们提出参考目标和业界实践下，客户意识到潜在存在的问题。

对于整个调研仍然要体现业务驱动IT，从业务流程和IT系统两个方面入手，但是最终两个部分内容不能散，在调研阶段还需要完成当前的IT系统是如何支撑现有业务的分析。

一个完整的调研阶段流程逻辑如下：

业务流程和现状分析

业务现状分析重点在于业务流程和业务数据上，建议采取自顶向下逐层分解的方法，找到关键的几个端到端流程为主线进行逐层分解，分解时抛开业务部门的隔离，IT系统的约束，进行跨业务域的流程分析和梳理。

在流程分析和梳理的过程中进一步分析子流程和活动，业务组件和数据，跨业务域的协同和交互等一系列问题。业务分解的方法可以参考价值链分析方法，业务模型可以参考针对各个业务域的一些标准业务参考架构和模型，如供应链的SCOR模型，电信的etom模型，研发领域的IPD和PACE方法，CMMI成熟度模型，项目管理知识体系，营销和客户关系管理模型，财务域标准模型等。

IT现状调研

IT现状包括现有的IT应用系统现状和功能架构，IT基础设施架构现状，IT系统对业务现状的支撑情况分析等。重点的是理清业务和IT的关系，IT对业务的支撑度。现状分析的目的是为提出后续业务目标和IT系统规划建设目标打基础，明确了建设目标才能够真正为业务服务，体现业务价值。

调研完成后的输出内容覆盖四个方面

在调研完成后的输出如上图包括了业务流程，业务数据，系统功能，接口集成和部署四大方面的内容。而这四个方面的内容刚好是我们做后续四大架构规划的基础。

差距和目标匹配分析

有了以上现状分析和调研，才谈得上差距分析。

差距分析包括了当前目标和当前现状间的问题和差距分析；业界参考目标/最佳实践和当前现状下的差距分析；IT现状对当前目标支撑的差距分析；IT现状对参考目标和业绩标准的差距分析。

差距分析清楚后得到双方认可的最终业务战略目标和业务子目标，由业务目标传递到对应的IT规划和建设目标，而后续的IT规划即解决两个问题。

IT建设解决当前业务和IT间的差距（无新业务战略下你如何更好支撑）IT建设解决后续战略目标和IT间的差距的问题（新战略下你如何扩展支撑）对于目标提出而言，有两个途径。

其一直接提出业务目标和IT建设目标；

其二是通过差距进一步细化目标和有针对性的目标，特别是IT建设目标的提出，必须进行差距分析，因为IT建设重点就是支持业务目标，那么所有现存的IT建设和应用架构中无法支撑的部分都是差距，IT规划建设就是要解决这些差距。

改进也同样的道理，有些是不需要业务改进直接进行IT建设和改进，有些则是业务优化和改进先进行，IT配合业务优化改进措施的落地。从这个思路基本也就清楚BPR的考虑和定位，并不是所有场景都一定要让用户进行BPR。

通过差距分析得出的目标是多个子目标，是一个目标群，正如我们面临的问题是一个问题集一样，多个子目标的分阶段，分步骤实现最终才可能完成一个大的业务目标。

目标分解，问题分解，目标和问题映射最终形成一个完整的解决方案。这也是为何我们说，在大的IT规划中一定会涉及到组合管理，项目群管理方面的内容，目标分解到子目标，子目标最终落实到具体的项目，通过项目规划和建设的方式推动实现。

这个本身我和前面文章谈到的咨询类方案成为的思路完全一致。

第一阶段：问题分解和基础素材对应

在这个阶段重点就是将目标分解为子问题，然后将论据映射到对应的子问题上。

在这个过程中你已有知识库积累可能不足够，这个不要紧，那么需要你进一步学习，进一步上网搜索资料，对资料进行分析，同时将没有的素材论据全部要清理掉。

最后留下的就是能够完全支撑目标的有用论据材料。

第二阶段：粗粒度对应，进一步排序和整合

到了第二阶段做什么？简单来说就是要做抽象和归纳的事情了，即进一步对你的材料进行整合和归纳，形成大块的解决模块，然后将解决模块对应到子问题域。

在解决模块形成过程中，我们还需要对素材论据进行优先级排序，确定材料的重要性，哪些在最终呈现的时候应该放在前面，哪些应该放在后面等。

第三阶段：进一步归纳并从归纳到演绎反转

前面三个论据形成了，但是仍然比较散。因此我们需要进一步进行归纳，将其形成一个完整的整体，不论是静态的金字塔结构，还是动态的流程结构都需要看到，你最终的解决方案中各模块必须首先是一个整体，不能散。

从流程分析到业务架构和数据架构

经常看企业架构输出的可能会注意到，对于完整的业务架构输出而言可能并看不到具体的流程图。这是因为实际上业务架构中的每一个小方框都可以是一个完整业务流程。

比如你在一个完整的业务架构图里面会看到有合同签订，采购需求的小方框。而这些本来就是独立的业务流程，你完全还可以自己画Level3到Level4级的流程图进行描述。

类似上面的业务架构图如何构图出来？

大部分人实际上缺的正是如何形成上面的业务架构完整构图。在整个业务架构和数据架构规划里面我们看到，核心仍然是从最顶层核心价值链开始驱动，逐层分解的端到端流程分析，跨业务域流程分析。

价值链模型为何具备普适性？

可以看到，虽然不同类型的企业核心业务流程都存在差异，比如类似电信运营商，电网公司和实际的传统制造型企业，那么核心业务上肯定有差异。但是核心价值链思想无差异。

核心价值链思想一句话描述就是：

接收市场和用户的需求，将最终的需求转变产品或服务并交付给客户的过程。

你可以是重资产企业也可以是轻资产企业，可以是服务类也可以是制造类企业，可以是传统企业也可以是当前的互联网运营企业，但是最终价值核心思想不变。

那么我们可以看一个我多年前画的一个电网类企业的价值链模型图：

这种价值链模型就可以理解为企业的核心顶层流程视图。通过该视图你再去分析企业核心的端到端业务流程，去分析跨业务域的一些流程。比如：

工程项目建设的端到端流程（最长的一个流程）供应链跨域流程财务的概预核决流程客户全生命周期服务流程为什么要去梳理这些端到端和跨域流程？

我前面已经谈到一个重要观点，即对于你熟知的行业领域你可以直接拿出结果，类似上面的业务架构图，但是对于你未知领域，你必须通过详细流程分析得出结果。

流程分析后，你会发现里面有流程图里面有业务活动，而这些业务活动就是最终会体现到业务架构图里面的业务功能单元。流程分析中可以识别出关键的业务对象和数据对象，而这些就是体现到你后续数据架构里面的关键内容。

这也是我经常强调的一个点。

从顶向下的流程分析是找到关键业务单元和数据单元的过程，而业务架构规划和数据架构规划是对单元进行归类，汇总，朝上进行聚合和抽象的过程。

只有这样才才能够真正解释清楚你的业务架构是如何得来的。

比如我们基于价值链已经看到供应链跨越流程，那么我们可以对供应链流程进行梳理。

梳理完后你会发现，输出的职能带流程图中的大阶段刚好就是你业务架构里面的业务域或业务单元。或者流程图中的业务活动刚好就是你业务架构分解到最底层的业务功能模块。

即当我们流程分析到最底层后，我们就可以抽象输出一个最底层的业务架构图。比如对应供应链和采购管理，我们可以输出到最底层的业务架构图或业务组件图。

流程梳理和分析究竟应该到多细的粒度？

流程梳理从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。

第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来，如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。

因此高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

从业务架构到数据架构

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。即我们谈到的业务流程分析和梳理还会识别和产出另外一个关键内容，即业务实体和数据单元。

流程中的业务活动可以是产生数据单元，也可以是对数据单元属性状态进行变更。

比如采购订单制作和提交业务活动，自然这个业务功能就会产生采购订单这个关键数据单元。而对应采购订单审批这个业务活动，则仅仅是对订单审批流状态进行变更。

数据架构贯穿业务和IT两个层面的规划

对于企业架构里面的数据架构规划，大家可能会有一个疑问，即数据架构究竟是偏业务层面的内容还是偏IT规划层面的内容，今天在此进一步说下我的看法。

即数据架构规划是一个贯穿业务和IT两部分规划的内容。即在业务阶段你可能只做到数据域划分，核心的数据概念模型和主数据识别。而到了应用架构规划阶段，你就需要进一步对数据进行逻辑模型和物理模型的设计。

在业务层面数据架构规划做到识别关键的业务对象即可。而到了技术层面数据架构规划必须细化到具体的数据库表和表里面的核心字段定义。

数据域-》数据概念模型-》数据逻辑和物理模型

数据域和数据分类是数据规划的顶层，这个时候如何确定数据域？

简单来讲如果你所在的行业有标准的数据模型标准，那么参考业界标准来做，比如电信行业的SID数据模型分类。如果没有标准，那么业务架构规划里面核心价值链模型的业务域即是数据域。

从这个图我们可以看到大的数据域实际和我业务域是完全对应的。

数据域出来后，我们可以对单个数据域再进行细化分析，这个时候就到了单个数据域里面所有和业务相关的业务对象和数据对象的识别，数据的概念模型定义。

比如对于供应链数据域，我们在完整梳理了供应链业务后即可识别出所有的业务对象，然后对这些业务对象单独拿出来进行数据建模，并分析数据对象之间的关联和依赖关系。

因此数据架构规划需要

转载请注明:http://www.aideyishus.com/lkyy/1337.html