对IT项目售前解决方案的一些思考(200825)

今天准备对于IT项目售前解决方案的制作，对于一个软件企业来说，往往会针对自己的产品线和产品形成一整套的售前解决方案类材料，其中包括了售前方案PPT，技术方案建议书，产品功能介绍手册等。但是实际我们看到对于不同的项目应标，往往仍然需要客户实际的需求对标准的售前方案材料进行修改和匹配。

售前项目支撑概述

对于售前项目支撑和解决方案编写，特别是基于甲方客户标书发出的技术规范书内容，如何结合公司已有的产品解决方案快速的整理售前技术方案建议书，这个是每一个售前解决方案顾问必须要掌握的关键技能。

今天继续整理最近几年的售前项目支撑文档材料，在整理构成中有些关键思考记录如下：

售前交流准备

进行正式的解决方案交流时候，前期的初步沟通很重要，主要包括了对客户企业信息化建设基本情况，系统建设和集成情况，当前业务和IT管理的关键需求和痛点，是否已经立项和计划建设时间，是否考察对其它的厂商等，这些信息的了解可以让我们售前方案更加有针对性并扬长避短。

一开始就直接进行售前交流，讲标准的PPT材料往往交流效果都不会太好，你觉得亮点的内容客户往往并不关心。这也是我原来经常会说到的实际上很难有一个售前方案PPT文档能够支撑所有售前项目的情况，基本都需要基于标准模板文档+客户需求进行修正。

同样，对于一开始就将自己摆在强势甲方位置上的企业，往往这种售前项目我们支撑下来基本没有中标的，这也印证一个道理，只有企业对技术尊重，对乙方尊重，认识到是合作伙伴关系往往项目才能够成功。

多个售前项目支撑下来我们发现一个规律就是，企业信息基础越是薄弱的企业往往越是不懂装懂，而真正大的企业信息化建设部门往往才是一种谦逊合作的态度。

售前方案的讲解，一般不能是纯理论和产品解决方案介绍，更是要结合实际在以往项目里面的成功应用案例来辅助说明，如果有和甲方企业相同的同行业企业实施案例往往讲解效果会更加好。

即所有的理论和产品特性，最好的证明方式就是已经在多个以往项目里面成功的得到了应用，而且取得了很好的效果。这个往往也是客户比较看重的一个方面，从我们售前项目支撑和丢标来看，往往都是不同行业项目实施案例会导致甲方评估时候减分。

售前方案材料

售前讲解方案的发送最好是以pdf方式进行发送，如果做的再好一点应该是每一个发送的pdf文件都应该标准清楚是发给哪个客户的。因为我们仍然会发现一些情况，就是我们的产品解决方案类材料会被放到互联网上面，由于一个pdf没有标记给到多个甲方导致也很难清楚究竟是哪个甲方导致材料泄露。

其次，对于材料发送个人建议是在正式应标前只发送ppt类材料，而对于详细的技术方案建议书并不适合在应标就发送给客户，特别是类似详细的word文档材料。因为我们也发现很多企业往往仅仅是为了要你的材料找你沟通，这种情况并不在少数，一个很简单的判断方式就是甲方给你电话沟通，也不问你们公司的规模案例，产品情况，就直接的找你要材料，很多时候都属于上面这种情况。

售前支撑阶段

对于售前项目当前状态可以分为几个阶段，具体理解为

• 阶段一：前前期，客户仅仅是想了解下相关的产品和技术，有潜在的需求但是不明确
• 阶段二：前期，客户已经有项目立项计划，在进行立项申报和产品选型，准备立项
• 阶段三：中期，客户项目已经立项，在进行供应商选型和产品交流，产品POC测试等
• 阶段四：晚期，项目可以发标，可以在互联网上搜索到客户的发标公告

而对于这四个阶段可以看到，最佳的是阶段二和阶段三，对于阶段一实际离项目立项还有很长的周期，对于阶段四本身由于你没有前期介入已经被其它的供应商技术控制基本也没有机会。

对于阶段二往往是介入的一个关键点，而且可以做到很好的引导客户，体现我们产品的优势和实施能力，同时协助客户完成技术规范书编写增加我们的技术亮点并体现差异化，回避我们产品的弱势能力等。由于阶段二到最终发标之间还有一个很长的周期，务必要做好的就是市场人员对客户和项目的持续跟踪，对中间过程引入的变化因素的判断和决策，类似中间过程有其它的供应商必选进入等。

对于阶段三也是一个很好的介入点，但是更加重要的就是很好的市场和客户关系，如果没有很强的客户关系在阶段三介入往往机会也不太大，除非是客户在阶段二本身就没有相关的竞争伙伴参与过交流和引导。如果甲方强势的推荐你，在阶段三接入往往没有任何问题。个人理解如果客户或甲方没有明确的表示过强势的挺你做这个项目，基本都代表客户有其它意向人选，你可能是去陪标。

那么最终客户发标后是否投标也就简单了，你可以从最终的技术规范书来分析和判断，你提交过的技术材料和优势能力是否在规范书有体现，还是说规范书全部体现的竞争对手的技术指标。如果是第二种情况那么基本没有机会中标，也没有必要再进行应标和售前投入。

售前方案PPT材料的制作

对于一个标准的售前方案PPT制作，可以参考我们前面的一篇文章：

主数据管理平台解决方案和建设重点

在这篇文章里面可以看到一个标准的售前方案PPT材料完全是符合完整的金字塔原理结构的，从最开始的现状和问题分析出发，到业务和技术解决方案，再到最终的实施方案。

对于软件类项目售前方案交流和讲解相对重要，一个是宣讲的材料，一个是宣讲过程两者都不能少。针对售前交流我原来一直的观点就是对于初次交流不要讲解PPT材料，先做非正式的沟通，沟通的目的是了解对方业务需求，存在的问题，项目建设的背景等信息，只有了解了这些才能够有针对性的准备售前方案材料。

对于售前方案的准备，主要应该包括如下关键步骤：

1. 标准售前材料PPT材料准备

首先还是要先准备标准版本的PPT宣讲材料，首先是统一标准的模板和呈现风格，其次是按照不同的产品，平台或系统分别准备不同的PPT宣讲材料。对于这类标准材料里面主要包括了公司简介，项目概述，业务解决方案，系统解决方案，实施方案，项目案例几个章节。

每个PPT宣讲材料应该做到可以拿出去独立讲解用，比如对方只关心MDM主数据产品，那么MDM的宣讲材料就能够独立讲解。即使前期没有了解客户的详细情况，也可以对标准版本的PPT材料进行讲解而不需要做任何额外的补充。

2. 需求+受众

不仅仅是针对售前方案PPT材料，对于所有的PPT宣讲材料的准备都必须要清楚的理解需求和你的目标听众。否则你讲解的内容很可能不是客户最终希望听到的或者想要的内容，而导致售前交流效果很差。对于需求部分，前面讲了可以先进行一次非正式拜访和交流，了解清楚客户真正关心的内容，希望解决的问题，然后再有针对性的进行材料准备；当然如果不方面，也可以先准备一个简单的调研问卷或问题收集，或者电话沟通等了解对方真正关心的内容。

其次是受众，究竟是谁听这个材料？

对于业务部门人员，信息化部门的CIO还有信息化技术人员，不同的受众关心的内容差异很大。业务部门会更多关心方案解决的业务问题，达成的业务目标；CIO关心的是方案体现出的IT部门价值，关键功能特性，包括后续的管控和接维，而下面的技术人员关心的则是是否采用了先进技术，技术架构和技术优势等。

所以我们在准备材料的时候一定要注意最核心的受众是谁，要让谁满意或认可方案。

3. 关键匹配：客户需求-》解决方案

这一步我始终认为是准备一个PPT方案最为关键的内容，即如何从客户需求映射到解决方案上面，因为到解决方案中的模块组件本身就是我们已有标准模块化素材的组装，没有太多要调整改动的地方。但是从客户需求到解决方案则是不同的客户，不同的项目都需要重新准备。

即基于项目背景，阐述我们对客户问题或需求的理解，然后基于该理解给出一个解决方案。同时也可以详细说明如何从需求转到该解决方案的，或者解决方案如何能够解决最终的业务需求和目标的。首先要让客户理解这个大框架，这个理解清楚了再将解决方案里面的模块逐一展开进行描述。

比如一个大的平台建设项目，基于前期调研沟通，我们发现了客户存在基础数据不一致，接口混乱无法关联，端到端流程存在断点无法贯通，接口改造在多方联动的时候经常导致问题而回退，业务人员在处理业务的时候不清楚一个完整的业务流走到哪里了？可能还有很大问题。

我们经过分析后给出了一个完整的平台方案，里面包括了技术平台，MDM主数据平台，SOA集成平台，BPM流程平台，门户和4A管理几个大的组件。那么就需要讲清楚这些子模块是如何衔接起来的？其次要讲清楚客户的需求或问题是如何通过提供的子系统解决掉的。这个整体解决方案客户理解清楚后，客户就有了一个完整的概念和框架，然后再展开详细描述就容易了。

如果这个大框架都没有理解，一下就过渡到你自己的产品讲解，那给客户最大的感觉就是卖产品，而且和客户的需求脱节。对于卖数据库，中间件等产品类售前可以这样，但是对于实施项目售前这样操作就完全达不到预期目标了。

4. 搭建整体架构和框架目录

前面想清楚后可以详细细化整体PPT的框架目标，注意仍然是要根据客户实际情况进行调整，大致仍然应该是包括了项目背景和概述，整体解决方案，产品解决方案，实施方案，项目案例这几个关键内容。对于项目背景概述，整体解决方案是需要重新编写或者做出较大调整的内容。同时通过解决方案将需求和后续的产品解决方案有效的衔接起来。

整体解决方案很重要，后续的内容分解也完整遵循金字塔原理的思路进行分解。

因此整体解决方案中的各个子系统或组件如何集成？关系如何，以及整体解决方案如何解决目标和问题的，都需要在整体解决方案部分阐述清楚。

5. 细化和揉合完整方案PPT内容

到了最后一步，重点就是基于构建完整的框架和目录结构填充内容。这个时候原来我们准备的很多标准材料内容就可以完全拷贝过来了，也正是这个原因最好所有的售前材料都采用标准的PPT模块格式，防止拷贝过程中再去做格式的调整。基于经验实际上需要新写和调整的内容应该是20%左右，而80%的内容都应该可以复用以前的材料。

在以前的材料拷贝过来后，仍然需要根据目标听众的情况来考虑哪些内容要删减，哪些地方可能还需要根据客户实际情况进行1-2页的细化补充。这些都属于内容细化和揉合必须要考虑的问题点。

再简单点来说，最终一个完整的售前PPT需要回答两个关键问题，其一是我们提供的解决方案可以有针对性的解决企业的问题，达成企业目标；其次就是公司本身产品，技术和团队积累优势，同时说明提供的实施团队经验丰富能够完全胜任项目。

售前解决方案框架搭建举例

在这里以自己准备一个完整的ESB服务总线解决方案售前材料举例来说明。这类解决方案既是以产品为核心，但是又不是单纯的一个产品介绍PPT材料，让客户意识到产品本身是解决他们问题的，而不是单纯的卖产品。

因此要准备这个PPT材料，往往首先就需要搭建完整的内容框架，这个内容框架的搭建可以直接在PPT里面进行，也可以通过Word文档或思维导图进行。在整个框架的搭建过程中，我们基本就会将每个大章，每章节里面的每个小节或者细化到每页要谈哪些内容都考虑清楚。

01-概述和导入部分的内容

Page1： 企业集成场景的出现

企业业务本身是连贯的，但是支撑业务的IT系统为了建设方便往往会拆分为多个IT系统，这些系统之间必须集成和协同起来才能满足业务需求。集成一种是横向业务流程的协同集成，一种是纵向的数据能力共享集成。

已有的IT应用架构下，当存在新系统建设和规划时候一定存在集成，从横向业务流来看一种是前端系统，一种是中端系统，一种是后端系统；从纵向来看，一个是数据共享和分发，一个是数据采集和分析。而这些都需要通过集成来解决。

正因为这个原因，企业内集成主要是业务集成和数据集成，存在实时和非实时，存在大并发，大数据，大文件等不同的集成场景。这些都是在集成时候需要考虑的问题。

Page2：企业当前集成的做法和问题

企业当前一般采用点对点网状集成的模式，在这种集成模式下存在接口不规范，无法复用，开发工作量大，接口管控运维困难等诸多问题。因此首先要对问题进行分类：

• 接口需求问题：接口需求的分析，复用的判断，服务目录规划和梳理等。
• 接口开发问题：接口设计和开发，接口测试等层面的问题。
• 接口管控问题：涉及到接口安全，日志监控分析，变更影响分析困难，运维困难等。
• 标准规范问题：接口实施标准的方法论，规范标准模板定义（需求规范，开发规范，接入规范，消费规范）

Page3：企业内集成场景分析

还是要单独说下企业内的集成场景，包括了业务集成和数据集成，包括了实时和非实时，大并发和大数据等不同的集成场景。这个我们在前面专门做过企业内集成场景分析的一页PPT。

正是由于存在不同的集成场景，因此就存在类似ESB(WS服务+JMS）, ETL或ELT，MFT文件传输等不同的集成工具和集成技术和实现方法。在这里要把这个说透彻，即针对不同的集成场景需要采用不同的集成技术，而不是一种技术或工具来解决所有问题。

由于需要有不同的集成技术，我们就需要一个提供一个完整集成技术和工具的产品，而不仅仅是需要一个单独的ESB服务总线即能够解决问题。

Page4：完整的SOA集成平台解决方案

完整的SOA集成平台应该解决和覆盖所有的集成场景，因此应该是提供一个完整集成解决方案（包括ESB能力，ETL能力，文件集成能力），同时包括服务目录提供和最终能力的开放，包括SOA治理和管控。同时能够满足企业大数据，大并发的集成需求。

注意在这个解决方案里面，ESB不是全部，而仅仅是SOA集成平台的一部分。所以我们当前的SOA整体产品方案是完全能够满足企业多方位集成需求的。

Page5：建设和实施SOA集成平台为企业带来的价值

价值的阐述应该从业务和技术两个方面来进行阐述和说明。

• 从业务层面：业务协同更加连贯，业务系统响应业务变化更加敏捷，原有业务断点减少，数据不一致减少。
• 从技术层面：实现IT集成架构标准化，IT服务资产显性化，IT管控治理可视化，业务和IT匹配可跟踪化。

原有的IT掌握在业务系统建设厂商手里面，实施SOA后新的IT架构掌控在IT部门手里面，IT部门要打开原有厂商黑盒，实现关键服务能力的暴露和管理，正在衔接好业务和IT协同的中间层次。比如一个端到端的流程优化项目，IT部门完全有能力在中间起到这种协同作用，业务驱动IT，IT只有明白了整体架构才知道如何更好的和企业端到端业务协同和服务。

02-SOA产品解决方案

Page1 产品整体架构介绍

前面第一部分讲解完成后直接进入到产品介绍，那么这里首先就要有一个关键过渡，即前面讲到的接口需求类，接口开发类，接口管控类，接口运维类四类关键需求如何对应到SOA整体产品架构上面。

给出SOA产品架构，里面分子系统和模块，然后将关键需求和这些子系统和模块对应上。接口开发类的更多对应到ESB引擎和设计器能力，接口管控对应到服务全生命周期管理和自服务流程，接口运维类对应到SOA整体监控运维解决方案，而接口需求对应到我们整体前期服务规划，咨询中的服务识别和定义。

Page2 产品的关键特性说明

产品如何讲？

应该从三个方面来讲比较合适，一个是产品关键的技术能力有哪些？一个是产品对服务全生命周期管理和实施过程的支撑，一个是产品对后期SOA管控和治理方面的支撑。

Page3 产品的关键技术能力（可以有多页）

在这里只拿ESB产品来说明如何对关键技术能力进行描述，这里需要描述的关键技术能力仍然是基于标准的ESB产品功能架构展开，对里面的核心技术功能进行描述。

• 适配器（支持DB，JMS，SOAP，Rest各类适配）
• 协议转换和内容转换能力（协议的转换能力，消息格式的转换能力）
• 大数据集成能力（包括大数据集成，大文件集成能力）
• 消息集成能力（单独提，包括消息1对多，消息发布订阅场景等）
• 安全能力（户名/密码，Token，IP控制，传输安全，数字证书）
• 服务代理（即传统说明的服务透明）
• 服务路由（对服务静态路由的支撑，动态路由的支持能力）
• 日志能力（记录服务详细运行日志）
• 大数据集成（类似基于大数据平台技术的大数据实时采集和集成能力，需要新增，特别是对MES集成）

Page4 产品的服务实施过程支撑能力（可以多页）

服务开发和实施整个过程是如何的？原来的服务实施方法论流程图可以进一步简化，先把服务实施整个流程说清楚，接着再说明服务实施整个过程，当前的的集成平台是如何支撑的自动化和自服务化。如何支撑服务定义，服务设计，服务开发，服务测试，服务部署上线的完整过程管理。

• 服务定义过程（服务元数据管理，服务目录，服务查询，服务视图浏览等）
• 服务接入过程（服务如何自服务的接入，服务接入申请，服务自动化测试，服务部署和开通）
• 服务订购过程（服务订购，订购后服务开通）
• 服务变更过程（服务版本管理，服务变更，服务变更后的测试和上线等）

Page5 产品提供的管控和治理能力（可以多页）

管控和治理能力包括后期的服务监控和运维能力，实际上很多大的SOA产品套件这块都是独立的子产品。因此对于这部分内容需要单独进行描述。

• 服务日志查询（详细的服务日志查询能力）
• 服务运行分析和统计（服务运行次数，运行时间，并发数，服务运行异常情况）
• 流量控制能力（提供完整的流量控制能力）
• 服务监控预警（监控策略设置，监控告警，告警通知等）
• 服务报表能力（各种服务可视化的展示图，包括设计器图表和服务运行图表）

03-SOA实施方案和流程说明

对于原来我们偏重的SOA实施方案需要做调整，即给出一个适合客户自己进行的快速实施解决方案和实施方法。第一步的重点仍然是先将接口统一管理起来，其次再次考虑接口本身的粒度和复用性。要讲清楚，当前产品支持两类方式实施和接入，一种是契约先行模式下的，一种是历史接口直接接入和发布。

Page1 产品实施工作流程

产品实施究竟包括哪些工作，其中包括了SOA平台的安装和部署，环境安装后的验证，产品的培训，各种典型服务开发的示例和说明。SOA实施流程和规范，标准化流程的指导，整个SOA管控治理体系的建立等。

Page2 产品部署架构

产品的安装和基础环境搭建，讲清楚部署架构，需要的软硬件资源准备。建议的硬件服务器和资源准备，部署架构需要进一步描述产品的高可用性架构，产品本身的可扩展性。

Page3 产品交付文档清单

产品最终的交付文档清单，包括了产品开发手册，产品运维手册，服务技术标准规范体系等。同时也包括SOA技术标准规范，SOA服务实施方法论一系列文档（服务规范，服务开发和接入指南，服务消费指南，服务设计规范，服务测试规范等）。

Page4 产品培训

产品培训说明，讲清楚会做哪些培训？同时说明针对不同场景都会做一个Case案例方便客户快速掌握。其中包括了SOA基础培训，服务开发和封装接入培训，SOA管控和运维培训等。

产品成功案例介绍

实际上应该是一个代表性的案例详细介绍，其余只给出客户名称和粗略的表格式介绍即可。

售前方案Word材料框架和匹配案例分析

以要做一个智慧校园的解决方案材料来进行说明下，背景是我原来做企业内部信息化开发和需求工作，主要涉及到CRM客户关系管理系统，熟悉软件工程和软件生命周期，对ERP也较为熟悉，有过需求分析和调研经验，做过CRM软件项目的售前解决方案并进行过宣讲。可以看到这不是要给完全跨新领域的工作，而是一个已有IT领域的延展性新工作。

第一步思考：破题-不破不立

首先要考虑的仍然是破题，即智慧校园解决方案 = 智慧和信息化+校园业务+IT解决方案。

即以上三个方面的内容都了解清楚后你才可能做出一个完整的智慧校园IT解决方案，而实际经过初步分析得出的就是我只有IT解决方案经验，而没有智慧校园方面的经验，即我们要做这个事情还是存在技能和经验差距的。那这个时候的匹配就是：

业界做法+我已有的知识经验=》达成目标的完整框架逻辑

对于业界做法很简单，需要的就是网上搜索和浏览大量的资料，这里面本身包括两个方面的资料

• 智慧校园的解决方案材料
• 校园信息化和主要业务的资料

大量资料浏览后需要的就是对比，拆分出各个资料里面的关键项目，最终再去考虑如何基于我们自己的目标整合为一个完整的方案。

我已有的经验是基于IT解决方案的，即对于写一个IT解决方案一般会涉及到项目背景和概述，总体解决方案，实施方案几个方面。有时候对于总体解决方案本身又分为业务解决方案，技术解决方案。对于技术解决方案本身又分为技术架构设计，功能架构设计等更加细化的内容。

不论是哪种，我们对于IT解决方案经过总结和归纳后会形成一个关键经验点，核心思路即：

1. 提出问题（背景，问题和现状分析）
2. 总体设计（建设的目标是什么？这个目标达成的总体架构设计是如何的？）
3. 详细实现（我们的解决方案是如何解决和达成目标的，详细过程和思路是如何的？）

可以看到，这个通用的IT解决方案的思路对于做智慧校园IT解决方案的时候也适用，那么我们需要做的事情实际很简单，即：

将搜索到的业界做法和网上参考材料整合到你前面形成的大框架中。

同时可以看到，这个跟做CRM解决方案时候有两个大的陌生点，其一就是校园本身的业务究竟是如何的我们并不清楚？其次就是一个校园信息化的整体框架我们应该如何搭建？只有这两个问题都想清楚后我们才能够形成初步完整框架。

可以看到只要我们大IT解决方案思路和逻辑清楚，要做智慧校园解决方案并不是难事，我们需要学习和补充知识，同时由于本身又做过需求收集和分析方面的工作，因此要学习和熟悉校园业务也很容易。

第二步思考：搭建大框架和结构

什么叫搭建大框架和结构？

简单点来说就是一个新的陌生领域你需要基于搜集的业界做法加上你已有的知识经验快速的搭建一个概念模型，这个概念模型就是梳理清楚一件事的关键框架和结构，把核心的内在逻辑，演进和推导关系想清楚，确保框架中的每项内容是承上启下，相互衔接为一个整体的。

金字塔原理说清楚很简单，但是实践起来却不容易，你需要的就是先从大框架开始就把结构想清楚，确保逻辑完整。

实际上大部分人在做解决方案的时候没有把这点想清楚和透彻，更多看到的场景是网上搜索到一个或二个智慧校园的IT解决方案，就开始简单的拼凑和组合，最终交付一个解决方案，而里面的内在逻辑是如何的自己也讲不清楚，这种解决方案没有太大的价值，也经受不住拷问，同时更加不利于自我的学习实践和技能提升。

下面我们来看下如何搭建这个框架结构出来。我们先分析网上搜索的一些材料

材料1

• 总体建设思路（现状和问题分析，智慧校园和传统校园信息化区别，建设目标，演进路线）
• 技术方案（重点是总体架构设计，包括了业务层面和技术层面总体架构）
• 应用方案（主要是基于技术方案架构模块展开的各个子系统详细介绍和说明）

材料2

• 概述（现状和问题，建设目标）
• 总体建设方案（建设思路，建设原则，顶层设计（业务，技术，数据等方面））
• 子系统介绍（各个子系统的详细介绍）
• 实施方法论（项目实施方法，进度，资源投入，风险管理）

材料3

• 建设思路（政策背景，核心理念，建设目标，建设内容）
• 建设内容（应用系统建设，共享数据中心建设，云平台建设，保障和运营机制建设）
• 建设成效（应用展示，建设收益分析）

收集和学习资料的目的就是要综合对比这些资料，并结合我们已有的做IT解决方案的思路，给出一个做智慧校园IT解决方案的整体框架。

由于我们是做一个通用性质的解决方案，因此初步考虑并不会去分析某个学校实际经过调研后的现状和问题，因此基于前面的分析和归纳，应该理出一个大的框架逻辑。

1. 提出问题
2. 总体设计（建设原则，业务总体架构，技术总体架构，集成架构，管控架构）
3. 详细解决方案（分解后的各个子系统介绍，最后再增加子系统间协同介绍）
4. 实施方案（重点介绍标准的实施方法论，各个实施阶段的关键工作和内容）

这里面关键还是要把校园业务搞清楚，包括各个业务之间的关系，同时搭建总体架构要考虑分析，可以基于平台+应用的思想来构建一个总体框架框架，如（基础云资源层，平台层（共享数据中心，服务总线平台，流程平台），应用层）等。到了应用层再按理解清楚的校园业务将信息化分解为各个大的业务子系统和功能模块。

1. 现状和问题要通过建设思路映射到目标上，实现问题和目标的匹配
2. 目标的达成要分解到具体的架构设计中的各个模块上，实现目标到实现的匹配
3. 各个子模块实现要详细描述清楚，回答交互逻辑和可实现性

以上内容都做到了，你就会发现 整个解决方案的各个部分会形成一个相互衔接的整体，每部分内容都不散而且是相互集成在一起并承上启下的，这就是搭建总体框架形成的关键概念模型 。

实际上到这个步骤，你对于里面的类似在线学习，教学评估各个子系统并没有详细深入去了解，但是这个不影响你搭建出上面的这个大框架。

第三步思考：逐层求精，层层匹配

在第二步大框架搭建完成后，其实你心里就应该有底了，即整个方案应该如何做出来，包括其内在逻辑是如何的。但是要成为一个完整的方案还有很多工作要做，里面的很多点你都还需要进一步去分解和落地，即通过详细解决方案和实施方案真正解释清楚你规划的总体架构和顶层设计是可以落地的，所以你必须要把how to 如何做，如何落地方面的事情讲清楚才行。

那么如何解决如何做层面的匹配呢？

这个匹配是我们完成一个新领域的第二个关键所在。搜索很多时候解决的都是目标到目标的匹配，而这里我们要解决的是如何通过详细的过程和步骤达到目标的匹配，即：

Process（Step1->Step2->....->Stepn)==>Goal1

要把这个搞清楚就必须进入到事物内部的运行机制和运转逻辑了。

举个简单的例子，客户需要爆米花，你给出了一个爆米花机那么就是最简单的目标匹配，而下一步你需要回答的就是爆米花机如何将玉米+白糖变化为一个个爆米花的。要回答这个问题你就必须知道和清楚爆米花机内部的运转机制。

在第二步搭建总体架构的时候我们更多的是采用了静态分析和架构搭建的思路，而到了这个步骤更多的就需要用动态分析的思路，解释清楚流程，包括如何通过流程达到目标。

即这个步骤的关键是动态分析，而动态分析的关键是流程分析，而流程分析本身又必须要把关键活动，活动的输入和输出搞清楚，即流程的各个阶段和活动节点本身是相互衔接和无缝集成的。

举例来说，当我们开始讲在线学习子系统的时候，我们就需要考虑E-Learning系统本身内部各个模块之间是如何动态协同完成最终的业务目标的，从课件准备，到学员学习和培训，再到后面练习，最终的考试评估如何形成一个完整的闭环体系。

这个理解清楚了那么我们的整体系统内部运转机制就理解清楚了，再通过这个动态分析分解出培训子系统，学习子系统，考试子系统，知识库等各个子模块就有理有据。

如何在第二步我们是以自顶向下的思路完成了总体框架的搭建，那么到了第三步我们可以用自底上的思路将搜集到的各种材料，学习到的内容安装目标要求进行组合和整合，形成一个完整的整体。先组合和整合完各个子件，然后再将各个子件最终集成和装配到完整的总体架构设计框架上面。

即搭建整体框架的时候是从树木到树干的分解和梳理过程，而到了详细解决方案的时候是从各个细枝末节组合到树干上的装配过程，两种最终衔接好就完成了一个高度整体的解决方案。