解决方案制作 第1篇
build模块可以单独作为构建补丁包的模块进行统一管理，这样做的好处是，补丁包的最终出处在这个模块下，里面可以进行各种文件的管理，比如jar包目录，class文件目录，甚至各种启动脚本等
pom依赖
，用于描述补丁包中解决的bug等信息，通常根据自己项目规范即可
制作补丁包时最终补丁包文件的位置信息描述，即可以理解为补丁包中的文件包括哪些？这些文件从哪里来？
一旦当你的描述信息正确无误时候，运行maven命令时候，ant插件就会按照描述信息将补丁包制作好，如下是一个标准的样板文件，可根据自身需要进行修改即可使用
最后，让我们来运行一下maven打包命令，看看效果如何，执行如下命令：
通过运行中的日志，也可以大概看出其打补丁包的执行过程
到这一步，我们完成了补丁包的制作，但这个是比较粗略的，真正项目中，还需要遵循公司的规范，比如补丁包的命名规范
同时，通过此例，可以看到，该补丁包属于增量补丁包，后续的流程是，通过shell命令，解压补丁包，将补丁包内的各个层级的文件，比如配置文件，依次替换生产环境下匹配目录下的文件，最后重启服务即可
本篇到此结束，最后感谢观看！
解决方案制作 第2篇
对于软件类项目售前方案交流和讲解相对重要，一个是宣讲的材料，一个是宣讲过程两者都不能少。针对售前交流我原来一直的观点就是对于初次交流不要讲解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需要回答两个关键问题，其一是我们提供的解决方案可以有针对性的解决企业的问题，达成企业目标；其次就是公司本身产品，技术和团队积累优势，同时说明提供的实施团队经验丰富能够完全胜任项目。
解决方案制作 第3篇
所谓解决方案就是针对客户提出的需求（或你理解出的需求）一一做应答。你的技术能力能否令客户放心，你的配套服务能力能否让双方在合作过程中保持愉悦，这些都客户较为关心的点。需要注意的是，技术框架也好，功能点的设计也好，都要与你提出的“痛点”相互呼应，这才会形成完整的思维逻辑流（Thinking Flow）。每个抛出的问题都可以得到解答，这也会让人觉得这的确是深思熟虑且为客户定制化开发的解决方案。
表现层：
就是将想法落实的过程，这部分涉及到信息框架的填充和落实，美化。这时候你收集的素材，积累的材料就可以派上用场，为你最终的可视化展示服务了。
我们花了大量的篇幅讲述了一个方案背后的思维和逻辑，下期我们通过一个现实的场景，看看一个方案从构思，策划，到制作是一个怎样的流程。
解决方案制作 第4篇
以要做一个智慧校园的解决方案材料来进行说明下，背景是我原来做企业内部信息化开发和需求工作，主要涉及到CRM客户关系管理系统，熟悉软件工程和软件生命周期，对ERP也较为熟悉，有过需求分析和调研经验，做过CRM软件项目的售前解决方案并进行过宣讲。可以看到这不是要给完全跨新领域的工作，而是一个已有IT领域的延展性新工作。
第一步思考：破题-不破不立
首先要考虑的仍然是破题，即智慧校园解决方案 = 智慧和信息化+校园业务+IT解决方案。
即以上三个方面的内容都了解清楚后你才可能做出一个完整的智慧校园IT解决方案，而实际经过初步分析得出的就是我只有IT解决方案经验，而没有智慧校园方面的经验，即我们要做这个事情还是存在技能和经验差距的。那这个时候的匹配就是：
业界做法+我已有的知识经验=》达成目标的完整框架逻辑
对于业界做法很简单，需要的就是网上搜索和浏览大量的资料，这里面本身包括两个方面的资料
大量资料浏览后需要的就是对比，拆分出各个资料里面的关键项目，最终再去考虑如何基于我们自己的目标整合为一个完整的方案。
我已有的经验是基于IT解决方案的，即对于写一个IT解决方案一般会涉及到项目背景和概述，总体解决方案，实施方案几个方面。有时候对于总体解决方案本身又分为业务解决方案，技术解决方案。对于技术解决方案本身又分为技术架构设计，功能架构设计等更加细化的内容。
不论是哪种，我们对于IT解决方案经过总结和归纳后会形成一个关键经验点，核心思路即：
可以看到，这个通用的IT解决方案的思路对于做智慧校园IT解决方案的时候也适用，那么我们需要做的事情实际很简单，即：
将搜索到的业界做法和网上参考材料整合到你前面形成的大框架中。
同时可以看到，这个跟做CRM解决方案时候有两个大的陌生点，其一就是校园本身的业务究竟是如何的我们并不清楚？其次就是一个校园信息化的整体框架我们应该如何搭建？只有这两个问题都想清楚后我们才能够形成初步完整框架。
可以看到只要我们大IT解决方案思路和逻辑清楚，要做智慧校园解决方案并不是难事，我们需要学习和补充知识，同时由于本身又做过需求收集和分析方面的工作，因此要学习和熟悉校园业务也很容易。
第二步思考：搭建大框架和结构
什么叫搭建大框架和结构？
简单点来说就是一个新的陌生领域你需要基于搜集的业界做法加上你已有的知识经验快速的搭建一个概念模型，这个概念模型就是梳理清楚一件事的关键框架和结构，把核心的内在逻辑，演进和推导关系想清楚，确保框架中的每项内容是承上启下，相互衔接为一个整体的。
金字塔原理说清楚很简单，但是实践起来却不容易，你需要的就是先从大框架开始就把结构想清楚，确保逻辑完整。
实际上大部分人在做解决方案的时候没有把这点想清楚和透彻，更多看到的场景是网上搜索到一个或二个智慧校园的IT解决方案，就开始简单的拼凑和组合，最终交付一个解决方案，而里面的内在逻辑是如何的自己也讲不清楚，这种解决方案没有太大的价值，也经受不住拷问，同时更加不利于自我的学习实践和技能提升。
下面我们来看下如何搭建这个框架结构出来。我们先分析网上搜索的一些材料
材料1
材料2
材料3
收集和学习资料的目的就是要综合对比这些资料，并结合我们已有的做IT解决方案的思路，给出一个做智慧校园IT解决方案的整体框架。
由于我们是做一个通用性质的解决方案，因此初步考虑并不会去分析某个学校实际经过调研后的现状和问题，因此基于前面的分析和归纳，应该理出一个大的框架逻辑。
这里面关键还是要把校园业务搞清楚，包括各个业务之间的关系，同时搭建总体架构要考虑分析，可以基于平台+应用的思想来构建一个总体框架框架，如（基础云资源层，平台层（共享数据中心，服务总线平台，流程平台），应用层）等。到了应用层再按理解清楚的校园业务将信息化分解为各个大的业务子系统和功能模块。
以上内容都做到了，你就会发现整个解决方案的各个部分会形成一个相互衔接的整体，每部分内容都不散而且是相互集成在一起并承上启下的，这就是搭建总体框架形成的关键概念模型。
实际上到这个步骤，你对于里面的类似在线学习，教学评估各个子系统并没有详细深入去了解，但是这个不影响你搭建出上面的这个大框架。
第三步思考：逐层求精，层层匹配
在第二步大框架搭建完成后，其实你心里就应该有底了，即整个方案应该如何做出来，包括其内在逻辑是如何的。但是要成为一个完整的方案还有很多工作要做，里面的很多点你都还需要进一步去分解和落地，即通过详细解决方案和实施方案真正解释清楚你规划的总体架构和顶层设计是可以落地的，所以你必须要把how to 如何做，如何落地方面的事情讲清楚才行。
那么如何解决如何做层面的匹配呢？
这个匹配是我们完成一个新领域的第二个关键所在。搜索很多时候解决的都是目标到目标的匹配，而这里我们要解决的是如何通过详细的过程和步骤达到目标的匹配，即：
Process（Step1->Step2->....->Stepn)==>Goal1
要把这个搞清楚就必须进入到事物内部的运行机制和运转逻辑了。
举个简单的例子，客户需要爆米花，你给出了一个爆米花机那么就是最简单的目标匹配，而下一步你需要回答的就是爆米花机如何将玉米+白糖变化为一个个爆米花的。要回答这个问题你就必须知道和清楚爆米花机内部的运转机制。
在第二步搭建总体架构的时候我们更多的是采用了静态分析和架构搭建的思路，而到了这个步骤更多的就需要用动态分析的思路，解释清楚流程，包括如何通过流程达到目标。
即这个步骤的关键是动态分析，而动态分析的关键是流程分析，而流程分析本身又必须要把关键活动，活动的输入和输出搞清楚，即流程的各个阶段和活动节点本身是相互衔接和无缝集成的。
举例来说，当我们开始讲在线学习子系统的时候，我们就需要考虑E-Learning系统本身内部各个模块之间是如何动态协同完成最终的业务目标的，从课件准备，到学员学习和培训，再到后面练习，最终的考试评估如何形成一个完整的闭环体系。
这个理解清楚了那么我们的整体系统内部运转机制就理解清楚了，再通过这个动态分析分解出培训子系统，学习子系统，考试子系统，知识库等各个子模块就有理有据。
如何在第二步我们是以自顶向下的思路完成了总体框架的搭建，那么到了第三步我们可以用自底上的思路将搜集到的各种材料，学习到的内容安装目标要求进行组合和整合，形成一个完整的整体。先组合和整合完各个子件，然后再将各个子件最终集成和装配到完整的总体架构设计框架上面。
即搭建整体框架的时候是从树木到树干的分解和梳理过程，而到了详细解决方案的时候是从各个细枝末节组合到树干上的装配过程，两种最终衔接好就完成了一个高度整体的解决方案。
物流IT圈
泛物流行业IT知识分享传播、从业人士互帮互助，覆盖快递快运/互联网物流平台/城配/即时配送/3PL/仓配/货代/冷链/物流软件公司/物流装备/物流自动化设备/物流机器人等细分行业。
解决方案制作 第5篇
当我们接到一个新的销售机会，看到客户最初提出的表象需求时，就站在了需求层的大门之下。我们先别急于动笔，先把下面的事情考虑清楚：
客户所在的行业当下正在经历什么变化？客户内部当下正在经历什么变化？是否已被移动互联网颠覆，或是因其冲击而对整个产业生态造成了巨大的震动或影响？客户在行业内处在什么水平，他们的战略/想法够不够前端？如果是，那么如此“大胆”的转型是否可以让客户获得在新时代的一席之地；如果不，就要好好想想在机遇和挑战并存的当下，我们能够为客户做点儿什么。
有了前面的分析，你会大概明白让客户“坐不住”的原因是什么，但这还不够。解决方案是为客户创造价值并将销售机会形成订单的过程，这过程中往往会涉及到多个部门的合作并有利益的牵扯，所以不要觉得这与你无关，尽可能的和销售人员搞好关系，明白这个项目有谁在支持，有谁在反对，客户内部对此项目的态度。如果需要其他部门的配合，想想能够为他们带来什么影响，什么好处，在进行适度的“取悦”。
有了明确的方向，接下来我们就要有针对性的进行论证，告诉客户为什么选择我。
解决方案制作 第6篇
在pom依赖中，指定了assembly的文件位置
assembly文件，可以理解为定义项目资源文件目录的描述元信息，比如说，你即将要打的补丁包里面的一些class文件，一些配置文件，甚至数据库脚本等
比如我这里，在web模块下，指定的assembly文件就在web的根目录下
在实际项目中，可能其他的除了web之外的模块也需要进行资源文件的补丁包打包，也可以像上面这样同样的操作即可