需求调研之后，接下来就要出具针对性的解决方案。解决方案的写法有很多，但都需要包括几个方面：第一，对自己公司的介绍；第二，对客户行业的认知；第三，对客户痛点的分析；第四，针对性解决方案的陈述；第五，对方案价值的总结；第六，对我方优势的说明。有了这些内容才是一份完整的解决方案。
一、 怎样做公司介绍。公司介绍要讲清楚三点：
第一，我们公司是做什么的，比如我们服务于哪些行业，聚焦于哪些领域，有哪些产品等；
第二，我们公司的实力怎样，比如公司成立多久，有多少人，人才结构是怎样的，获得过哪里奖项等；
第三，我们公司是有成功案例的，比如我们实施过哪些项目（要讲跟客户类似的项目），在这些项目中做了哪些事情，达到了什么样的效果，客户如何评价等。
二、 怎样论述对行业的认识。客户所在行业的论述要包括三个方面：
第一，客户所在行业的现状，比如行业的经济规模，增长速度，有哪些龙头企业，这些龙头企业的经营状况等；
第二，行业未来的发展趋势，比如市场的拓展空间，行业的集中度，管理模式的转型等；
第三，行业存在哪些潜在风险，比如消费习惯改变、消费意识提升带来的风险，国家内外部政策带来的风险，技术革新带来的风险等。
三、 怎样分析客户的痛点。客户痛点的分析要从宏观和微观两个方面着手：
宏观层面：行业发展趋势给企业带来的机会和风险，怎样把握机会，怎样规避风险，企业的战略目标是什么，IT系统需要给与怎样的支撑。
微观层面：各业务部门存在哪些问题，这些问题是怎样产生的？一般来说，业务部门的问题主要集中在几个方面：
第一，数据采集不上来导致管理、考核无依据；
第二，数据口径不一致导致报表数据不准确；
第三，企业内部各部门或企业上下游供应链沟通协调不通畅导致管理成本高，协调效率低下；
第四，存在手工工作或重复工作，效率低下；
第五，报表数据出不来或严重滞后，不能给决策以支撑。
不同行业，不同企业的痛点是千差万别的，有些是信息化建设不到位引起的，但更多的是管理问题，如组织架构不合理，数据标准不一致，流程设计不合理等等，都会引发诸多问题。
四、 怎样写针对性的解决方案。首先解决方案应该分为三个部分，分别是业务方案、技术方案和实施方案。
首先来看业务方案。与痛点分析相匹配，业务方案也要从宏观和微观两个层面写：
宏观层面：把企业总体的战略目标分解成不同阶段的战术目标。围绕着这些战术目标，人、财、物（包括物料和产品）、客户（包括供应商和渠道、终端等）等生产经营要素应该怎样匹配？每种要素怎样管理？一般来说，对生产经营要素的管理有四大维度。以客户为例，分别是资料管理（包括资料编辑、合规性审核、状态变更等），交易管理（包括订单、发货单、收付款单、折扣返利等），服务管理（包括促销政策、市场政策、培训及考核等），报表管理（汇总表、明细表、日报、月报、对比分析、趋势分析等），有了这四个维度就可以形成完整的管理视图。
微观层面：要阐述关键业务流程，对于时间跨度较长，涉及部门较多的复杂流程可以分成若干阶段，采用主流程+子流程的方式来描述。主流程是关键业务的整体描述，子流程是对关键业务的分阶段描述。流程的描述要有角色、事务、输出（单据、报表等）、控制节点、流向等关键要素。最后就是系统界面的展示，单据和报表是什么样子，怎样实现控制节点等等，对于客户重点关注的点要详细描述。
其次是技术方案。技术方案要讲清楚系统的架构、系统的性能、系统的安全、系统的维护等几个方面。
系统架构：企业的IT系统不是一步到位的，在不同阶段会上不同的系统，因此在做系统架构设计时要考虑和已有系统的集成，要给到客户一个整体的规划。这就要讲清楚几个问题，一是主数据在哪个系统管理，二是不同系统间的数据流向，三是数据接口。数据接口有单向的和双向的，有些双向接口还需要回写数据，用什么技术来实现这些接口，要在方案中讲清楚。
系统性能：系统可以支撑多少用户？可以处理多少数据？软硬件需要怎样配置？在实际运行环境下，数据量往往是不均衡的，在数据高峰期怎样做负载均衡？还有，大数据量的查询对系统性能损耗较大，怎样解决？再有，不同系统处理数据的效率会有差异，数据量大时接口就会形成数据阻塞，怎样解决这些问题，都要讲清楚。
系统安全：不同组织、不同部门、不同用户间的数据怎样隔离？操作权限怎样设置？数据传输过程中是否有泄露风险？通过什么技术或什么方式来规避这些风险？
系统维护：系统的维护由谁来做？甲方还是乙方。系统的运营状态怎样监控？有没有工具软件？截图来说明。系统出现异常或数据出现错误怎样定位？怎样解决问题？要说明解决问题的思路，方式和方法。
最后是实施方案。实施方案要讲清楚工作量预估、实施的周期、投入的资源、工作输出、实施方法论等几个方面。
工作量预估：一般来说，对于大项目，尤其是定制化系统，项目管理+需求+测试的人天总和与系统设计+代码编写的人天总和应该是1：1的。
实施周期：一般实施会分为需求调研、系统设计、代码编写、测试、上线、验收等几个阶段。不同阶段会有关键里程碑，即评审节点，比如需求评审、设计评审、上线评审和验收评审等。有些阶段的工作是可以并行的，比如需求调研和系统设计，可分不同模块，由不同领域的顾问分别调研，分别出具调研报告和设计文档。有些阶段的工作是交叉的，比如代码编写和测试，测试分为单元测试、集成测试、原型测试和压力测试、容灾测试等，压力测试和容灾测试要至少给出两周时间。测试工作和代码编写应该是相辅相成的。对于有系统集成的项目，会存在数据割接，数据割接的准备工作比较繁琐，要留出足够的时间。
投入资源：该项目实施投入的人员，一个完整的项目需要甲乙双方共同投入，乙方有项目经理、实施顾问、架构师、UI设计、开发顾问、测试等角色；甲方一般会有项目经理和关键用户，在甲方项目经理的配置上建议最好两个人，一个熟悉业务，能对业务需求负责；一个熟悉技术和现有系统，能协助项目团队解决IT资源和系统对接等问题。
工作输出：包括需求分析、系统设计、源代码、测试用例、测试报告、变更记录、验收报告、项目周报等一系列工作文档。
实施方法论：包括项目团队怎样搭建，项目风险怎样规避，项目怎样验收等。项目团队搭建主要是对甲乙双方项目角色及职责的约定；项目风险主要是在出现需求变更而导致工作量增加时怎样处理；项目验收主要是项目验收的方式、方法以及验收的标准等，上线及验收标准在售前阶段就要跟客户讲清楚，要得到客户的认同，避免实施交付时引起不必要的麻烦。
五、 怎样总结方案价值。
对方案价值的总结其实就是对整个方案的回顾，要站在宏观层面围绕着客户痛点简明扼要来讲，不要拖沓。
六、 怎样说明我方优势。
作为售前解决方案，你的目的是为了赢单，要知道竞争对手的情况，了解他们的优势和劣势，在方案中或明或暗的去设置门槛，打击竞争对手的同时建立自己的优势。
在方案的最后，要对自己的优势再做一次总结，不需要多，三条即可，多了客户也记不住，同时要表达与客户未来合作的信心和期待。
以上是解决方案的写作方法，欢迎对这方面有兴趣的同仁与我沟通交流，谢谢大家的关注！
