如何写售前解决方案2
来源：神州数码erp 关键词：电子商务, PDM, OA
?口语书面语混杂，遣词造句不严谨有的人写方案时顺着思路走，口语化成分很多。
利用范本复制的方案如果不经过仔细的核对，往往容易出现如下几种错误：第一，替换不
完整，在方案中出现了其他客户的名称。
?业务解决方案成为功能列表
解决方案图快、图省事的另一种常见编写方法，就是将产品功能描述作为技术方案内容进行罗列，或者参照软件功能手册进行罗列，这种解决方案不是按照客户业务去准备的，对客户而言没有实质的意义。
如果解决方案中业务思路部分写得清晰简明，倒是可以把功能列表作为解决方案附件，或者在解决方案中提供一份软件全功能列表给用户参考。
?口语书面语混杂，遣词造句不严谨
有的人写方案时顺着思路走，口语化成分很多。方案是代表公司正式对外的文档，行文一定不要出现口语和书面语混杂的情况。
有的人写方案比较喜欢表现自己对客户问题认识的深度，喜欢指出客户的不足，而且采
用激烈的语言。例如出现“企业缺少管理” 、“业务失控”、“后果很严重”之类词语，这些内容很容易让用户反感。
方案用语不要追求“语不惊人誓不休”，而要注重理性分析，认真推导，句句讲逻辑。确实需要用一些事实说明客户的问题，不要用刺激性强的语言。例如说客户业务存在问题，可以说业务有可改进的地方；说企业管理失控，可以说管理上存在难以受控的环节。这样的表达客户比较容易接受，不容易出问题。
有些客户内部关系比较复杂，一些提法，特别是一些有新意的提法可能对某些人比较敏感，在方案中可以中性化表达，是否合适要仔细斟酌，并询问电子商务人员的意见。
?没有认真检查，存在大量硬伤
很多解决方案的制作过程往往是找一个同类方案，然后通过“Ctrl+C”+ “ Ctrl+V ”制作
成一个新的方案。利用范本复制的方案如果不经过仔细的核对，往往容易出现如下几种错误：第一，替换不完整，在方案中出现了其他客户的名称。
第二，替换过度，把一些典型案例中典型客户名称也替换成为本方案客户名称，闹出笑话。
第三，只注意正文的文字替换，不注意插人图片文字中客户名称或其他内容的替换。第四，只注意正文替换，忽视页眉页脚的替换，特别是在首页或目录和正文不同的情况下。
第五，目录不对，忘记刷新，出现页码或者标题名称错误。第六，案例不对，没有查找本行业案例，案例全部都是其他行业的。第七，联系方式不对，给不同地区的方案要注意更正服务机构联系方式。第八，文件电子属性没有更改，导致在资源管理器中浏览时显示其他客户的方案名称。第九，存在大量技术硬伤，堆砌非本行业的专用词汇和概念，和正文内容无关。
?过于突出自我
很多人写方案大量出现“ ** 软件公司”字样，甚至每个产品都恨不得加上自家标识，行文造句都是“我能……”、“我行”、“我有……”等语气。
这种方案很容易给客户过度营销的感觉。给客户写售前方案时，建议尽量用客户作前缀，例如说某企业PDM 项目，给客户一种相对的针对性，感觉这个方案的确是为客户准备的。
在售后实施方案中软件公司的名字只需要出现一次，后面就尽量不要反复出现，我们更
应该让客户把注意力集中到产品支撑业务的能力上。
?没有体现公司产品最新进展 很多时候解决方案的编制者都是一抄再抄几年前的模板，没有反映产品功能最新进步， 自然缺少竞争力和说服力。
提交解决方案往往离正式实施需要半年甚至更长的周期， 不充分利用公司最新产品进展， 就好比有大马力的法拉利赛车， 但偏要拿奥迪去比速度。 因此写解决方案一定要根据公司最 新产品功能， 认真组合实现企业业务流， 甚至可以考虑利用未来半年内会发布的产品功能认 真组合客户业务解决思路。
所以咨询顾问还要随时收集、 学习软件规划， 以推动解决方案的技术水准不断完善和提高。 ?文字太多，图表很少
凑解决方案的字数不难， 难在让客户把这些文字都看完。 文字陈列太多， 方案可读性就 会降低。 软件解决方案中文字的概念比较多， 理解难度比较大， 因此要想办法设计一些简明 清晰的图表，把写 Word 方案当作PPT —样来书写，减少文字的比例，把大段的解释变成图 表式直观表达。
从没看过软件方案的人，判断某个方案写得好坏关键是看方案图表质量。 售前解决方案中应该多用一些描述理念和逻辑的框图，少用 有的方案图表不少， 但一看就是不同文章
风格的拼凑之作， 一种。
?没有评审 方案提交给客户之前，一定要经过内部评审。 没有个性
化定制内容的方案， 一般经过自评和互评即可。
的结构、问题描述、 遣词造句等方面， 特别要注意关注替换修改的企
业名称和产品名称等方 面的内容， 尽量减少低级错误。 自己评审过的
方案一定要给其他人评审， 帮助发现一些自己 行文习惯下难以发现的问题。
对于有个性化定制内容的方案， 要经过公司的评审。 提交给公司评审的方案， 一定是已
经过自评和互评的方案， 而且要注明主要看哪些部分， 以及编写这些部分的业务知识， 便于
加快评审速度。OA 软件界面图。 应该把所有图表风格统一成
自评时， 要重新审视整个方案
2.如何写售前方案
ERP 项目中，我们经常会遇到咨询顾问写“解决方案” 的情况，有些公司售前阶段需要售前顾问来写，有些公司甚至有方案经理这类的角色，笔者不才，写过一些，所以，简单介绍一下方案的写法，都是经验之谈，就不去引经据典吊书袋了。另外，需要提醒读者注意，本文写的是”售前方案“，不是项目开始后的实施方案。
售前阶段，一般最终做过简单调查后，需要制作某某企业ERP实施方案，或者规划方案，解决方案等东西。
这个方案通常情况下，是由咨询公司对企业进行初步调研之后，会同企业ERP选型项目
组共同制定的，主要功能用来游说企业项目决策人，同时企业领导人选型决策的参考。
我通常的写法如下，笔者一家之言，大家见谅。方案框架（以下是简单写法，复杂写法的框架比这复杂很多）：
一。引言
主要讲信息化趋势，企业所属行业，特别是竞争对手的信息化动向。
二。企业现状分析主要是问题分析，问题是指信息化可以解决的问题，无关的问题不要谈。这些问题有共性，比如：信息孤岛无法集成和共享，企业流程效率低下，成本无法有效
控制等等，同时，也要分析本企业及所属行业的一些特殊性问题，比如：快速消费品行业对高效供应链管理的迫切需求。
这些问题的写法可以借鉴一些咨询公司的方案，尤其是问题的表达，很多咨询公司的方案堪称典范。
三。信息化如何解决这些问题。本部分是重中之重，一般说来，要分成以下小章节。
1。关键业务流程，信息化功能实现（重点，用流程图，数字，模型说明信息化功能实现，特别是如何解决企业现在面临的问题）
2。流程优化与重组。
3。企业最佳业务实践复制。
四。实现的价值和收益要区分可以计量的，和不可以计量的，可以计量的，甚至可以细化到资产负债表事项。
五。项目实施初步规划可以用甘特图作简单描述，说明时间，阶段，成果，参与人员等。
六。项目资金概算。
软硬件投资，咨询费用，新增的项目组人员薪资等。这个概算，也是作为一个初步报价的过程，具体价格要慎重，不可多写，也不要少写，摸清对方心理底线。
七。一些建议。如，尽快启动项目，要注重项目组成员的福利待遇等等。
我的感觉是，文字尽量控制在100 页以内比较好，同时，一定要出一个简化版本，将方案浓缩在3页，5页A4纸上，这样便于领导查看主要数据。
如何写好售前解决方案 动笔前先打一个电话。 一般情况下，方案撰写人只是按照别人的要求提供方案，并非直接利用方案的人。所以在写方案之前，问问需要方案的同事，甚至是客户，听听他们对方案的想法和建议，这样对写方案会有很大帮助。 闭门造车往往导致接受者对方案不满意，要求返工修改。所以动笔前先打几个电话，问清楚客户需求，这样不但可以提高方案的针对性，也可以获得大量的解决思路线索，对写方案大有好处。 一. 努力按客户业务逻辑写 一般写方案最简单的方式就是按照协同软件设计思路和功能模块来写，因为有大量素材可用。但这样撰写方案并非是一种最佳选择，因为对客户而言，他必须转换角色进行思维，要站在供货商的思维模式上才能看懂方案字句之间的含义。 如果从以客户为中心的角度出发，方案应尽量让客户容易看懂，好理解，自然也就取得了较好的印象分。 方案应先仔细探讨客户业务，而不是将调研结论一一罗列，应从业务分析中推导出业务需求，最后描述技术实现手段。从这个意义上讲，解决方案要按照简明的业务手册来准备。 二.按标准套路写方案 不同类型的方案都有自己的套路，例如可行性报告、解决方案、建议书等都各有套路。一个公司可以经常讨论完善和丰富方案的写作套路。我们应尽量按照标准套路准备方案，不要自成体系。在既定套路下发挥，套路就体现了一种结构化、体系化的思维模式，很多客户本身也是习惯阅读有套路的文档。 套路和为客户定制并不矛盾，好的套路反映了专业文档定制的经验。 三.先构思提纲，经过讨论，最后动笔 很多时候方案的准备时间并不充分，很多人接到任务之后立即找个范本修改，这是不好的工作习惯。 有时候利用模板的确可以较快地完成任务，但时间长了就形成了惰性，形成用替换方式抄改方案的习惯。真在实际工作中遇到个性化较强的项目，而标准供应链管理方案模板没有涵盖时就无从应对。这是因为平时写方案过程中思维始终缺少结构化思考练习的结果。 写方案时一定不要急着动笔，而是先想提纲。提纲中的逻辑联系和业务衔接在脑海中推导得比较有力和充分了，才开始动笔；有了提纲，思路就不会断，写起来才快。 如果有条件的话，这个思路还应该和大家讨论，特别是一些重要方案，一定要先反复讨论提纲。各种意见和思路在提纲中统一了，再动手写。这样就不至于遇到方案写完评审时又被否定，不得不推倒重来的痛苦。 四.找一个安静的地方和完整的时间段开始 写方案最怕中间不停地被打断，这样思路无法保持连贯性。所以无论接到多么紧急的方案编制任务，也不要急着去写，而是先把手头该处理的小事情处理干净，确保编写的时间段相对安静和完整，这样才能保证方案的质量。
售前技术发展部 绩效考核方案 1概述 售前工程师是公司非常重要的岗位。一方面，支持具体销售活动（例如产品验收、客户沟通、需求获取等），并提供各类销售技术支持（例如参与建议书编写、技术方案编写、标书制作及演示文档、典型案例归纳等工作）。另一方面，售前工程师是公司产品理念的开创者、公司产品设计的领军者，肩负着产品发展方向、产品设计等重要工作。所以需采用综合评价方法进行绩效考核。 2绩效考核方案拟定原则 以职位等级为基础，采用基于销售额的考核及综合指标考核相结合的综合考评方法。具体构成为： 年收入=等级职位薪金+销售奖金之和+年底综合评定奖金 3具体考核办法 3.1以职位等级划定基本薪酬体系结构 在建立售前工程师基本薪酬体系结构过程中，要充分考虑售前工程师在本行业从业年限及行业经验积累、技术能力、个人综合能力，主要按能力付酬，而不能仅按照销售业绩付酬，不能过分强调薪酬的
变动性，而应当建立一套以职位等级标准为基础的薪酬体系结构，从而实现公司售前工程师向售前顾问的角色转换，将售前工程师以售前工作重点的模式，向产品战略、产品设计方向等工作重点转变。 进一步说，对于售前工程师的激励重点不是考核，而是能力提升，只有售前工程师具备充分的能力，才可能使售前工程师成为企业实现技术营销、顾问式营销的关键点。 职位等级划定基本薪酬体系结构标准为： 职位等级晋升考核办法（略）。 3.2基于销售额的考核 售前支持作为售前工程师的工作重点之一，通过实际销售额的定量考核，提高售前工程师对售前工作支持的积极性。 由于目前项目类型（具体见附件）较多，同时考虑公司的项目实际情况，以及售前工程师的实际工作情况，特制定以下考核办法：1）售前工程师的销售额奖金直接与销售人员的奖金挂钩，即单个项目，售前工程师的销售额奖金与销售人员所拿奖金（扣除商务等各种费用之前）成固定比例（25%左右，具体看公司的项目性质以及公司的策略等）； 2）售前工程师在实际工作工程中可能存在工作交叉的情况，即同一个项目有多个售前工程师参与，分别负责不同的工作内容，所以需
IT售前如何写解决方案分析 1??IT售前如何写解决方案( N' T, s$ E! K# c; u/ m- s5 n+ S 1.1??解决方案难写在哪里* @: I??X: ?# `7 M2 Q 很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样，我觉得我在这方面确实是有绝活。# g8 J0 k1 `8 P$ F0 h! R- m" N ? ?我基本上都是在方案提交前一两天接到写方案的任务，而我自己的事情一般又比别人多一点，也不能不做，只好心里大骂一句，骂完后就打电话搞清楚别人的要求，边问就边构思整个方案的推导思路和结构提纲。 因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在2~4个小时以内)，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。所以我其实也特别紧张，注意力也特别集中，大脑也高速反应，基本上几分钟电话或面谈完思路基本就有了，然后该干嘛干嘛，找一些零散的小时间把思路不断推导一下，然后到了一个比较安静和完整的时间段前才开始写，这个时候基本上要写的话都想清楚了，只需要不断敲字，敲字的时候也是注意力也特别集中，大脑也高速反应，越写思路越开，很快也就完工了。% r/ M, f# Z3 f! N 写方案不难，知道怎么写才难。关于写方案我只总结一点，结构化地去组织你的思想。 有结构就有思路，有思路就有方案。0 a8 B4 S( ~: f 另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。) x$ u8 A% f& ]4 v4 A 当然我曾经问过很多人，你到底为什么写不出好的方案呢？ 基本上原因可以归为四类：( ^5 T. m, x1 n( X 1.1.1 第一种是没有体系 一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。 这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。 6 B. F0 m4 n% W% W 因为我们这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。: H8 a" w+ m6 ~/ |
1IT售前——编写解决方案 解决方案的路径是说明问题——分析问题——解决问题的过程。 编制解决方案的过程是从业务理解到技术方案编制的过程，即通过业务架构分析，了解组织的战略、相关业务的组织结构和职能、关键流程，从而构建企业的应用系统架构，并根据应用系统需求提供技术解决方案。 根据此理解，解决方案的编写路线如下： 整个技术解决方案包括五部分： 1.1业务理解 此部分内容旨在阐述公司对客户业务的理解，通过项目背景、业务架构、问题与变革三部分分析，说明客户的业务现状、遇到问题和未来可能的变革，以实现在业务层面与客户的共鸣。 1.1.1项目背景分析 项目背景分析包括竞争环境分析、业务标杆分析和信息化标杆分析三部分内容：
竞争环境分析。竞争环境包括宏观环境和任务环境，其中宏观环境包括政治、经济、社会和技术环境等，任务环境是指与企业直接有关的产业环境，通常可采用波特的竞争力模型进行分析。波特认为影响行业竞争结构及竞争强度的主要因素包括行业内现有企业、潜在的进入者、替代品制造商、供应商和顾客（产品购买者）。 业务标杆分析。基准化分析法（benchmarking）就是将本企业各项活动与从事该项活动最佳者进行比较，从而提出行动方法，以弥补自身的不足，是一种评价自身企业和研究其他组织的手段。 信息化标杆分析。针对相关信息化领域，提供信息化标杆分析。 1.1.2企业现状和业务架构分析 业务架构分析包括企业基本情况、业务战略、组织架构、业务模式及关键流程和信息化现状分析等五部分内容： 企业基本情况分析。企业生产经营概况，包括公司简介、主要业务和效益情况、在同行业内所处的地位等。 企业业务战略分析。企业的使命、目标、价值观和企业的竞争战略（量化的竞争目标和竞争实施计划）。 企业组织架构分析。企业的组织架构设置情况、组织各单元的主要职能、关键岗位设置和岗位职责情况。 业务模式及关键流程分析。本部分内容是关键，采用价值链理论进行业务模式分析，并采用编目的方法进行流程描述和说明。 信息化现状分析。描述企业相关的应用系统、软/硬件设备投入情况，以及企业信息化管控模式。 1.1.3问题定义与变革分析 问题定义与变革分析包括三部分内容： 宏观问题。根据环境和标杆分析，指出企业业务模式各环节存在的问题及改进建议。
售前支持部标准工作流程 版本号：V 1.0 密级：公开 20XX年X月
1、工作流程图
1.1 标准工作流程说明 [1]. 市场客户调研：客户发掘、客户前期走访调研、初步项目需求；市场部人员按照调研表输出【项目情况基本表】。 [2].项目分析：业务部门组织相关人员（业务主管、市场总监、总经办或售前人员）对项目进行案情分析，形成【项目立项评估表】。 [3].方案报价阶段：根据【项目立项评估表】确定是否调用售前人员。 业务人员编写方案报价：根据公司售前【标准资料】编写项目初步方案及报价。 售前人员编写方案报价：需要市场人员提交【售前支持申请单】，并附上【项目情况基本表】和【项目立项评估表】，经相关领导审批；售前部门出具【资源调配单】。审批流程详见“调用售前人员审批流程”； 调研：根据【资源调配单】情况，确定调研人员；售前人员支持公司标准产品介绍、项目初步需求调研、项目选型、项目个性化产品方案报价及个别第三方产品；技术部人员支持个性化产品，需要制作DEMOの项目及公司没有の产品；公司支持特殊项目（如国家课题、特殊项目等）。 调研后：由调研人员出具【调研报告】、【项目推进建议书】；如果调研后出具解决方案及报价，由售前部门确定该方案为标准、简单の方案，由市场人员进行编写；如果为个性化或国家课题方案，有售前部门编写。 [4].投标阶段：由市场部确定该项目是否投标；确定成本及利润。发送邮件于各个部门，开展投标启动会。 标底：根据提交给客户方案、需求及市场の评估，出具【标底】。 投标质疑：由售前部门制作质疑函及回复函。 投标：业务部门提交标书，由售前人员进行投标任务分配，出具【投标任务分配表】；具体内容详解“投标任务表分解”。 [5].合同阶段：由业务人员根据公司标准合同模板出具合同，输出【项目合同】。 [5].项目交接：由业务部门人员组织内部实施启动会，售前在项目中产生の所有有用の资料需求文档都进行移交。
IT 售前方案编制xx 一、方案的概念 （一）传统行业 产品：沙发服务：沙发的配送、安装。 方案：为家庭提供从布局设计到采购推荐、再到配送、安装等全流程就是 解决方案。 （二）IT行业 产品：App、系统、平台、闸机、PDA终端设备等。服务：安装、部署、运行维护等。 方案：为客户提供定制化的产品，解决客户的某些实际问题，并首先以文 字的方式展现出来。 二、方案编制目的 为没有购买欲望的客户导入需要购买思想。为已经有购买欲望的客户传达选择我们的理由。 三、方案编撰原则首先，我们需要确定我们的客户是谁？然后需要搞清楚我们 要通过方案向 客户传递什么内容？ 1．客户为什么要购买我们的产品和服务？ 2．我们的产品和服务能为客户解决什么问题？ 3．为了给客户解决问题我们要做些什么？ 4．客户为此要花费多少钱，钱都花在哪里？ 四、方案编撰内容
（一）方案通常包含哪些章节？ 建设背景、建设目标、建设原则、客户需求、建设内容（方案设计）、实施方案、技术方案、建设内容清单及预算、硬件产品配置参数、软件功能、资质优势、成功案例等。 （二）建设背景 通常对应客户为什么要购买我们的产品和服务？ 1．上级部门有建设要求 公安部要求各省在2020 年完成治安防控体系建设； 交通运输部要求于2017年 3 月 1 日起，对省级、市级客运班线全面实施客票实名售票和实名查验。 2．实际业务过程中有建设需要 检查站要进行人员身份核查，民警需要借助软件系统核实人员身份信息； 旅客忘记携带身份证件，无法实名入住旅馆，需要软件来核实人员身份信息。 3．注意事项 上级部门的要求有很多，我们一定要选择和我们的产品或服务相匹配的内容，是通过我们的产品和服务能够解决的问题。 业务中存在的问题也很多，我们一定要选择客户管辖范围内的问题。 （三）建设目标 通常对应我们的产品和服务能为客户解决什么问题？ 1．编制内容 1）需要对客户购买产品或服务后能够解决的问题进行概述，以向公安销售电子临证产品为例，建设目标可以有： 2）可实现申请人员与全国七类重点人员及临控人员的比对预警，增加了公安
如何写售前解决方案 一般要为客户撰写的售前方案分为：项目建议书、项目解决方案、项目投标书。 项目建议书用于动员客户启动项目，为客户启动项目提供何行性建议分析，或者用于客户初步选型阶段，获得调研机会后再编制解决方案。 解决方案用于恰谈技术协议和合同之前持软件技术交底，或者用于议标阶段，重在介绍软件供货商的技术能力和实施服务能力等方面的优势。 投标书用于客户的招标文档，按照客户要求的格式进行发挥，要充分说明公司各个方面的综合实力，以战胜对手。 项目建议书的参考结构： 1 引言 2 企业业务现状分析与诊断 3 项目目标规划 3.1 项目规划原则 3.2 项目总体目标和分阶段目标 3.3 项目预期周期和成本规划 4 项目必要性分析 5 项目可行性分析 5.1 相关技术的发展现状介绍 5.2 软件公司相关产品的能力分析 5.3 企业具备的管理、硬件、组织和技术基础 6 项目的经济效益分析 7 结束语
建议书的要求是简短紧凑，内空翔实，目标规划清楚，便于高层决策，可以在一份建议书中列出几个可选技术方案，推动客户高层决策。 解决方案的参考结构： 1 引言 2 业务现状分析与诊断 3 系统架构规划 3.1 总体目标 3.2 指导思想 3.3 总体功能框架 3.4 硬件部署体系 …… 4 系统业务技术解决方案 4.1 关键业务问题解决方案（可多个） 4.2 关注重点技术问题介绍 4.3 其他标准功能介绍 …… 5 系统实施方案 5.1 实施管理方法 5.2 实施团队构成 5.3 实施里程碑计划（可分解子系统实施计划） 5.4 各阶段双方工作配合说明 5.5 风险分析及对策
售前如何写解决方案分析4 我基本上都是在方案提交前一两天接到写方案的任务,而我自己的事情一般又比别人多一点,也不能不做,只好心里大骂一句,骂完后就打电话搞清楚别人的要求,边问就边构思整个方案的推导思路和结构提纲。,以下便是第1页的正文： 售前如何写解决方案分析 售前如何写解决方案 1解决方案难写在哪里 很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样，我觉得我在这方面确实是有绝活。 我基本上都是在方案提交前一两天接到写方案的任务，而我自己的事情一般又比别人多一点，也不能不做，只好心里大骂一句，骂完后就打电话搞清楚别人的要求，边问就边构思整个方案的推导思路和结构提纲。 因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在个小时以内，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。所以我其实也特别紧张，注意力也特别集中，大脑也高速反应，基本上几分钟电话或面谈完思路基本就有了，然后该干嘛干嘛，找一些零散的小时间把思路不断推导一下，然后到了一个比较安静和完整的时间段前才开始写，这个时候基本上要写的话都
想清楚了，只需要不断敲字，敲字的时候也是注意力也特别集中，大脑也高速反应，越写思路越开，很快也就完工了。 写方案不难，知道怎么写才难。关于写方案我只总结一点，结构化地去组织你的思想。 有结构就有思路，有思路就有方案。 另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。 当然我曾经问过很多人，你到底为什么写不出好的方案呢？ 基本上原因可以归为四类： 1.1第一种是没有体系 一旦用户要求提供关于的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。 这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产 品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散 的说法构成的。 因为我们这个行业从业人员说句不客气的话，大部分对所销
写好售前解决方案的心得 一般情况下，方案撰写人只是按照别人的要求提供方案，并非直接利用方案的人。所以在写方案之前，问问需要方案的同事，甚至是客户，听听他们对方案的想法和建议，这样对写方案会有很大帮助。 闭门造车往往导致接受者对方案不满意，要求返工修改。所以动笔前先打几个电话，问清楚客户需求，这样不但可以提高方案的针对性，也可以获得大量的解决思路线索，对写方案大有好处。 ◆努力按客户业务逻辑写 一般写方案最简单的方式就是按照协同软件设计思路和功能模块来写，因为有大量素材可用。但这样撰写方案并非是一种最佳选择，因为对客户而言，他必须转换角色进行思维，要站在供货商的思维模式上才能看懂方案字句之间的含义。 如果从以客户为中心的角度出发，方案应尽量让客户容易看懂，好理解，自然也就取得了较好的印象分。 方案应先仔细探讨客户业务，而不是将调研结论一一罗列，应从业务分析中推导出业务需求，最后描述技术实现手段。从这个意义上讲，解决方案要按照简明的业务手册来准备。 ◆按标准套路写方案 不同类型的方案都有自己的套路，例如可行性报告、解决方案、建议书等都各有套路。一个公司可以经常讨论完善和丰富方案的写作套路。我们应尽量按照标准套路准备方案，不要自成体系。在既定套路下发挥，套路就体现了一种结构化、体系化的思维模式，很多客户本身也是习惯阅读有套路的文档。 套路和为客户定制并不矛盾，好的套路反映了专业文档定制的经验。 ◆先构思提纲，经过讨论，最后动笔 很多时候方案的准备时间并不充分，很多人接到任务之后立即找个范本修改，这是不好的工作习惯。 有时候利用模板的确可以较快地完成任务，但时间长了就形成了惰性，形成用替换方式抄改方案的习惯。真在实际工作中遇到个性化较强的项目，而标准供应链管理方案模板没有涵盖时就无从应对。这是因为平时写方案过程中思维始终缺少结构化思考练习的结果。 写方案时一定不要急着动笔，而是先想提纲。提纲中的逻辑联系和业务衔接在脑海中推导得比较有力和充分了，才开始动笔；有了提纲，思路就不会断，写起来才快。 如果有条件的话，这个思路还应该和大家讨论，特别是一些重要方案，一定要先反复讨论提纲。各种意见和思路在提纲中统一了，再动手写。这样就不至于遇到方案写完评审时又被否定，不得不推倒重来的痛苦。 ◆找一个安静的地方和完整的时间段开始 写方案最怕中间不停地被打断，这样思路无法保持连贯性。所以无论接到多么紧急的方案编制任务，也不要急着去写，而是先把手头该处理的小事情处理干净，确保编写的时间段相对安静和完整，这样才能保证方案的质量。 一定要保证在一个时间段内初步拿出完整的推导思路和结构提纲，然后就可以逐步补充和丰富内容，不至于在写的过程中还为结构苦恼，不清楚从哪里下笔，每次要花费大量时间从头构思。 ◆认真准备方案的阅读提示和摘要 客户决策领导往往公务繁忙，时间有限，很难保证将厚厚一本方案的内容全部认真研读，所以方案可以单独附一份摘要以供客户领导浏览。摘要重点介绍整个方案中的精华部分，当然也可以附带实施方法和典型用户介绍。通过摘要让方案的解决问题的思路在短短几页纸中得到清晰、准确的描述，这种用精炼文字描述业务思路的能力往往更能给人留下深刻印象。 对于较复杂、内容较多的方案一定要提供一份阅读提示，告诉不同的人其关心的内容可以通过阅读哪些章节直接获得。实际上很多论文和书籍序言都会有一段来说明文章的结构，读者可以直接进入感兴趣的话题，这对我们编制方案也是一个有益的启发。 ◆注意积累素材 写方案时，无论按照何种客户业务组织材料，必然有80％的内容是相似的，毕竟软件设计理念不会在短期内发生巨大改变，方案涉及功能边界在短期内也不会发生大的改变，所以不同时期不同用户解决方案中
售前技术支持工作浅谈 售前技术支持工作是介于销售与技术之间的职位，经常接触到各式各样的客户，对提高自身的沟通能力有很好的磨练。就算在IT业内售前的职位也很特殊，既要有与客户沟通的技巧，也要有技术人员的细致与执着，实际上是技术型的销售角色。售前工程师的最终目的就是让客户接受公司的解决方案，在招投标的过程中，技术部分能够打出最高分。 同样，客户在采购IT产品时，无论硬件、软件、服务都是为客户业务提供支持服务的，往往需要的不是产品本身，而是解决方案。说得明白些，就是怎样解决客户面临的问题。客户一般来说不是IT的专家，有些甚至连具体的需求也说不清楚，需要你的提炼与讲解。如何合理地选择产品组成方案，既要提供高性价比，又要具有前瞻性保护客户的投资，多数是靠售前对技术方案的理解与讲解。 售前技术支持的工作既辛苦，又难做，但恰恰是最锻炼一个人的意志与能力。从技术上来说，一名优秀的售前工程师有比研发人员的技术更为“广博”，因为他接触各种各样的对手产品；从市场的角度讲，售前工程师有比销售更敏锐的产品嗅觉，因为他了解客户的需求。若你知道什么样的技术流行、实用，什么样的产品会畅销，客户最需要什么。 结合日常售前支持工作的经历和感受，就以下几点与大家共同探讨一下。 1.切忌过多炫耀你的技术。 技术人员都喜欢“表现”自己，尤其为了让客户尽快地信任自己，就往往会把自己的“长项”一股脑地道出来，有时会适得其反。如果在炫耀技术的同时，没有经过事前的准备，现场难免有很多意想不到的情况发生，结果反而给客户留下不好的印象，客户不是“技术型”的人，否则认真起来就更加得不偿失了。 2.不要与客户争执技术观点，即使你是对的。 客户中每人的技术水平相差是很多的，有专家也有非技术的管理人员，所以在对客户不是很了解的时候，不要与客户争执技术上的观点，即使你是正确的，尤其不要反驳已经成为事实的东西，不合理但它存在，存在就是对的。对售前技术人员来说，此时应该是主要关心客户的问题点是什么。因为问题解决了，客户自然会欣赏你。客户的技术有很多“特色”，争执其合理性，忽视了主要的工作，是售前技术人员的忌讳。 3.提炼产品的亮点，展示出你技术上的优势，是售前技术人员的基本功。 把复杂的问题简单化，是大师的水平，是对技术的真正理解，所谓简单是能切中要害，
IT售前如何写解决方案分析 1 IT售前如何写解决方案( N' T, s$ E! K# c; u/ m- s5 n+ S 1.1 解决方案难写在哪里* @: I X: ?# `7 M2 Q 很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样，我觉得我在这方面确实是有绝活。# g8 J0 k1 `8 P$ F0 h! R- m" N 我基本上都是在方案提交前一两天接到写方案的任务，而我自己的事情一般又比别人多一点，也不能不做，只好心里大骂一句，骂完后就打电话搞清楚别人的要求，边问就边构思整个方案的推导思路和结构提纲。 因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在2~4个小时以内)，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。所以我其实也特别紧张，注意力也特别集中，大脑也高速反应，基本上几分钟电话或面谈完思路基本就有了，然后该干嘛干嘛，找一些零散的小时间把思路不断推导一下，然后到了一个比较安静和完整的时间段前才开始写，这个时候基本上要写的话都想清楚了，只需要不断敲字，敲字的时候也是注意力也特别集中，大脑也高速反应，越写思路越开，很快也就完工了。% r/ M, f# Z3 f! N 写方案不难，知道怎么写才难。关于写方案我只总结一点，结构化地去组织你的思想。 有结构就有思路，有思路就有方案。0 a8 B4 S( ~: f 另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。) x$ u8 A% f& ]4 v4 A 当然我曾经问过很多人，你到底为什么写不出好的方案呢？ 基本上原因可以归为四类：( ^5 T. m, x1 n( X 1.1.1 第一种是没有体系 一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。 这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。 6 B. F0 m4 n% W% W 因为我们这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。: H8 a" w+ m6 ~/ | 所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对
IT售前方案的撰写 准备阶段（摸清客户需求） 只有弄懂了客户的需求，才能写出有针对性的方案 很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。 写方案不难，知道怎么写才难。关于写方案我只总结一点，结构化地去组织你的思想。有结构就有思路，有思路就有方案。 另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。 撰写方案的几个要点 一、要有体系（熟悉产品及产品卖点） 一旦用户要求提供关于PDM（Product Data Management）的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点(自己产品的优势)，不过真要写出来，又觉得无从下笔。 这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。 因为我们这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。 所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知
识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。 二、要有思路（要有针对性） 有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。 这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。 所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户所关注的重难点问题，自然可以比较好的确定方案的个性化内容思路。 解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。 三、要有素材（平时多积累） 一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。 这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。 所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。 四、要有层次（在必要时提供） 很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。
售前工程师岗位职责 主要工作内容: 1、指导并协助销售部人员，以对公司销售业务发展方向提供咨询。 2、完成相关产品/方案宣传资料的撰写、产品/系统演示等工作。 3、配合公司营销人员完成相关项目的打单。负责所有的售前支持工作，包括与用户的技 术交流、技术方案编写、技术方案宣讲等。 4、配合公司营销部门完成相应项目的投标。标书的技术应答、系统软硬件配置、公开报 价、讲标答标等工作。 5、配合销售团队提案及客户竞标。 6、配合公司渠道人员做好与合作伙伴、原厂商等的技术交流工作。 详细工作内容: 1.从技术层面了解公司主营产品的特点，根据客户需求，与销售共同面见客户， 从技术角度阐述产品的特点（针对渠道客户）。 2.能独自完成简单方案的编写，根据销售的货单和客户的需求，能给出简单的解决方案， 满足客户的需求。 3.能根据公司的业务快速认知新产品，对新产品抱有信心，学习其技术原理，了解产品 本质特点和优势，并能将新产品融入到原有解决方案中。 4.熟悉解决问题的流程方法，遇到技术难题能与厂商做有效沟通，能快速找到解决问题 的方法。 5.能够熟练讲演ppt，宣传公司的产品，吸引客户。具体的工作过程可按以下内容进行， 以服务器存储售前工程师为例： 作为服务器、存储相关的硬件售前工程师，想要从对服务器，存储初步的了解到 成为这方面专业的售前工程师需要一段长期的学习和积累的过程。 作为售前工程师，工作职责主要是根据本公司销售人员以及最终用户的项 目需求编写项目方案，应对项目需求，有的项目需要讲解方案。对于大型
项目需要提前编写竞标标书。同时，对于硬件产品本身的参数特点要尽可能的熟记，熟练掌握公司经营的服务器，存储的相关知识，要做到对应项 目需求给出需要采用哪个品牌的哪种类型的硬件产品 学习的过程从整体方案入手，先对方案的编写有个整体的概念，例如编写方案需要先分析项目背景，然后项目需求分析，项目方案设计（根据项目预算，尽可能给出两套项目方案，即简单成本低廉的方案和安全性高，易扩展的方案）。 对方案有了整体的了解后，开始学习目前主流的方案有哪些及涉及到的关 键技术，例如，部署个企业私有云，我们需要采用服务器虚拟化技术，为 了数据安全我们会采用容灾技术（同城容灾和异地容灾），链路负载均衡和 广域网加速等技术都会融合到部署企业私有云的网络中。 应对以上方案技术，我们的具体学习过程要有条理性的进行，例如服务器 虚拟化技术是应对什么问题的，采用服务器虚拟化有哪些好处，做服务器虚拟化有哪些厂家，他们各自的优缺点是什么。然后举一反三的去学习其他技术，例如灾备，桌面虚拟化，应用虚拟化等。 学习了方案技术之后，我们需要养成一种学习习惯，即记录这些方案的主 要内容，同时把方案中设计的技术名词进行深入了解，例如HANA是一个 软硬件结合体，提供高性能的数据查询功能，用户可以直接对大量实时业 务数据进行查询和分析，而不需要对业务数据进行建模、聚合等，Hadoop 即HDFS是分布式文件系统，有高容错性和高吞吐量，为海量数据提供存储和计算。 了解了方案和技术后，我们开始具体学习产品，即服务器和存储，服务器 方面要知道服务器有哪些品牌，主流的型号及和其他厂商对应的型号是什 么，例如IBM的主流服务器是3650M4，用的是E5-2600V2系列的CPU,内 存最大可达到768G等参数，对应的华为品牌服务器为RH2288，DELL为 R720和R720Xd、及HP的DL388P等，在存储方面我们同样按这样的方式 去学习存储，例如，存储分为高端，中端和企业入门级的低端存储，做存 储的主要厂商为EMC, HP, Netapp、IBM和华为，这些厂商有哪些型号的存储，对应友商的是什么型号的存储，各自的优缺点是什么。