电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本
换一换
首页 金锄头文库 > 资源分类 > DOC文档下载
分享到微信 分享到微博 分享到QQ空间

售前工程师具有的素质

  • 资源ID:134099411       资源大小:33KB        全文页数:14页
  • 资源格式: DOC        下载积分:10金贝
快捷下载 游客一键下载
账号登录下载
微信登录下载
三方登录下载: 微信开放平台登录   支付宝登录   QQ登录  
二维码
微信扫一扫登录
下载资源需要10金贝
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
支付方式: 支付宝    微信支付   
验证码:   换一换

 
账号:
密码:
验证码:   换一换
  忘记密码?
    
1、金锄头文库是“C2C”交易模式,即卖家上传的文档直接由买家下载,本站只是中间服务平台,本站所有文档下载所得的收益全部归上传人(卖家)所有,作为网络服务商,若您的权利被侵害请及时联系右侧客服;
2、如你看到网页展示的文档有jinchutou.com水印,是因预览和防盗链等技术需要对部份页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有jinchutou.com水印标识,下载后原文更清晰;
3、所有的PPT和DOC文档都被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;下载前须认真查看,确认无误后再购买;
4、文档大部份都是可以预览的,金锄头文库作为内容存储提供商,无法对各卖家所售文档的真实性、完整性、准确性以及专业性等问题提供审核和保证,请慎重购买;
5、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据;
6、如果您还有什么不清楚的或需要我们协助,可以点击右侧栏的客服。
下载须知 | 常见问题汇总

售前工程师具有的素质

在中国IT业界,有这么一群技术人员,往往辛苦地工作在第一线,任劳任怨,没有多少时间来交流,但他们确是最具备交流能力的一群人,他们没有象那些开发者一样在公司中那么显眼,但他们确是本应该在公司中最露脸的人物,这就是售前工程师,或者说技术顾问,更加可叹的是,我们的专家在绞尽脑汁地分析和争议为什么会出现一万元的ERP?为什么这个项目本该100万中标的却只有20万?这些为什么,做为一个售前人员是最清楚的了。正当他们谈论恶意竞争的时候和感叹法规不完善的时候,一个真正的售前人员可以很轻易的分析究竟是什么导致了这些情况的发生!如果大家还对售前这个职务没有概念的话,请看江月先生发表的文章:售前工程师的来世今生今天,只是一个普通的售前人员,没有必要讨论那些宏观的事情,只是抱着为了售前这个职务有一个更好的发展这个良好的想法,同时真正为我们的客户着想,拨开那些层层的迷雾,让我们的项目做的更加顺利,为IT业尽一份力,同时也响应IT应用服务网那句话:“这里不需要豪言壮语,不需要喧哗的概念,我们只要切实行动,从小做起,一切为客户着想”, 笔者思考良久,还是采用随笔的方式,简简单单,从一个售前必须具备的能力和素质的角度,进而也顺带讲解一些IT业界在竞标中出现的一些情况和分析。笔者希望本文的读者:那些可敬的工作在第一线的售前工程师、想从事售前的工程师,那些公司的经理CEO、CTO,还有我们的用户,以及对这个职务好奇或关心这个职务的人。前言在现在的项目运做中,随着客户个性化需求的提出,以及各类技术的涌现,一个良好的售前工程师要具备什么样的能力和素质呢,那些素质最重要呢,要回答这些问题,我们就要抓住几点,售前的目的是做什么,售前的核心目的:是把公司的产品或解决方案让用户充分肯定并更进一步,使用户在众多可选项目中选种你的产品和方案。我们不防想象一下,在竟标的现场,是最激动人心的场面了,你可能是公司老总,你可能是CTO,你可能是公司售前技术顾问,那么在用户的面前你其实就是一个普通的售前工程师,用户和专家把他们各自关心的细节准备好了,为的是向你提问,另外对你每一句陈词,甚至某个字眼都有可能成为攻击你的目标,解释的好,可能成为你标书的亮点,解释不好,成为你标书的“暗点”。一旦成为你的“暗点”,这些日子,你们公司售前组花了几个通宵的精力打造的一本漂亮的标书就成了几页废纸,抱憾终生。如果有人说招标是走过场的形式,可以不必在意,关于这个问题,我会在以后的文章里专门探讨,所谓无论是走什么过场,都逃离不了“囚徒困境”的博弈,终究要回到“你的这些问题终究要决定的结果,什么样的花结什么样的果”这一伟大立场上来。为了避免这些问题,我就非常有必要回到我们的正题:究竟一个售前要具备什么样的能力和素质呢?下面是一个非常容易接受的命题逻辑,在这个逻辑上我们再细细探讨:(1) 用户不可能比你了解你公司和你公司产品技术(2) 用户不一定了解用户的所有需求,你不一定了解用户的所有需求(3) 用户不能够自己解决自己的问题第1个命题很简单,如果他要是比你还了解你公司的话,他自己就能提出你公司的解决方案了,要不要你,不在于你,完全在于他了。第2个命题也不难,用户要是知道他所有的需求的话,那就太好了,你的开发经理就不必搞什么需求调研了,开发好的项目直接就可以上线了,万事大吉,实际上往往不是这样,用户并不一定了解,他不了解的话,你就更不一定了解了。第3个命题也很简单,用户通常是没有能力去解决自己的问题,或者是不必要自己去解决自己的问题,所以你才有去拿这些项目的机会,前提是你要有这个实力。所以针对第1个命题,一个售前必须具备呈现(presentation capability)方面的能力,有了这个能力才可以充分展现你公司的实力,和你公司的解决方案,以及对他所有问题的响应程度。所以针对第2、3个命题,一个售前必须清楚用户要解决什么问题,和知道如何去解决这些问题,这样你就必须具备发现问题和解决问题的能力,这个能力最终是落实到技术层面上来的,一个售前必须具备另一种能力:过硬的技术(Technical Skills)这就是为什么说:“售前嘛,能说会做,能写会练”所以说做售前不容易就在于此。其实以上这两个能力是用户非常关心的,但是要把售前工作做好,把项目作好,从售前本身出发还要自身的个人品质方面的素质,想象一下,一个技术非常厉害的售前,如果在标书里面经常放一些非常低级的错误,如:项目名称都弄错,报价少了一个零等等。恐怕对用户也不好交代哦。根据自身多年的投标和售前工作经验,针对售前提出如下3个层面的素质或能力要求。呈现方面(1)沟通能力(2)卓越的演讲能力,(3)睿智的答辩能力,(4)精湛的写作能力,技术方面(1)业务专家,(2)需求分析专家;(3)产品专家;(4)技术专家;个人品质方面(1)细心;(2)耐心;(3)信心;(4)虚心;(5)勤奋;一个售前的能力和素质如下图所示:为了把这么多内容解释清楚,委实不易,但我们可以用验证法,其中有一个很有效的方法是关键验证法,俗话说:“管他白猫黑猫,抓到老鼠就是好猫”,“到了关键的时候才能正确的评价一个人”,那么投标的时候也能评价一个售前;有一次评标结束,我们正要上台演讲,前面出来上一家公司的两个人在小声埋怨,“你是怎么搞的,页眉页角怎么弄错了呢?”你看,专家可以通过你的呈现发现人性非常底层的属性-不太细心,如果那位专家往下一想:这家公司,做事马虎,不够严谨,恐怕难以胜任这种项目啊,这就不好了。呈现能力大家回到这张图上来,你要是出了纰漏,用户和专家是很容易发现的,为什么,下面详细介绍:其实这个时候决定你的成败就在于你的呈现,这里的呈现包括:标书技术方案的好坏,商务报价的高低,服务与实施等等,但这些东西是从你嘴巴讲出来,和标书里写出来的。有时候,专家是不能够面面俱到去看你的标书,因为这里有一个原则:一个好的标书,你很容易讲好,你不太容易讲坏;一个不好的标书,你不容易讲好,你很容易讲坏;不妨再想象一下,一个口才一般的售前,讲标的售前你肯定要熟悉你的标书,你标书要是写的很好,你照着约定的PPT讲,效果不好也不坏,但至少没有什么漏洞和把柄让用户抓住,至少达到让用户认可你了(这是售前的最初目的:肯定你),如果你标书本身就没有吃透用户的需求,设计也很马虎,你口才一般,按照约定的PPT讲,没有什么发挥,效果也就恰恰反映了你标书的情况-糟糕,用户和专家就必然对你提出很多疑点,甚至刁难。所以呈现要好的话,标书必定要写好,这也就是专家可以泰然听你演讲而并不看你标书的原因了。如果你标书写的好,呈现能力强的情况会怎么样了?答案是太妙了,锦上添花啊,如何才能锦上添花呢,这才是一个关键,所谓艺高人胆大,过犹而不及,一个人往往讲的兴奋了,就可能天花乱坠,本来不应该把有些技术讲的太深的,而他偏偏一时高兴,越来越深,如脱缰野马,拉不回来了,会出现两难境地,1)容易跑题,用户专家不满,耽误时间;2)言多必失,若此时出现技术纠缠,就坏事了。第一位:沟通能力没有了解,就没有发言权,相信大家在投标过程中,对用户都有一定的了解,而了解不是去参观用户,而是与用户去沟通,而沟通无处不在,投标前要沟通,投标中要沟通(在讲标过程中察言观色,调整自己的思路),投标后也要沟通,大家很少看见一个事先与用户没有任何接触,却突然中标的事情吧。在这里,笔者妄自把沟通能力放在首位,所谓不打无准备的战,沟通是一种语言和行为的交流,在作战之前讲标人一定要了解前因后果,一定是要参与标书的人,通过这种沟通,在真正的战场上,你面对你的受众(用户,专家),你就知道哪些应该是你强调的,哪些是你应该规避的,你的发言框架就大致确定了,发挥起来就有的放矢。在这里笔者要指出的是,很多公司,派出去的讲标人并不是参与标书的人去讲标,比如销售经理,技术经理,甚至总经理,他们无外呼基于如下考虑:这些职务形象比较专注,或技术比较好,领导重视,但是如果他们没有清楚整个标书的细节,会出现前面所说的:天花乱坠,跑题;讲的和标书承诺的不一致;技术实现与用户需求脱节等细节错误;等这些技术要售前工程师来答疑澄清的时候,已经失去先机,这些情况发生的不在少数。所以专业的公司宁愿培养一名优秀的售前工程师来担此重任,比如:有些公司通过录象和培养演讲水平等方式来提高售前呈现能力就是一个很好的例子。第二位:卓越的演讲能力我们售前工程师面对客户的时候,客户第一印象就是,哦,这是某某公司的技术顾问来了,这个时候售前工程师无形中就代表了公司的形象,所以在这个售前的能力图中,在一个讲标的过程中,如果一个售前面对多名专家,气定神闲,风度翩翩而温和谦虚会是一种什么样的感觉?如果我是专家,我一定会非常欣赏,人往往会认同一个人,既而认同他的思想,所谓爱屋及乌,这是人性的弱点,正是这个可爱的弱点,许多不可思议的情况发生了。这里笔者同样要贸然指出:在进行你精彩演讲之前,千万要参与了整个售前项目,把细节处理到位,做到名副其实。然而现实情况中,还是有许多标书做的很好,讲解的时候结结巴巴,吞吞吐吐,让用户听不清楚,甚至曲解你的意思,导致效果大打折扣。在这里提醒,所谓卓越的演讲,千万不要弄成大话空话,这样让人生厌。第三位:睿智的答辩能力在一般的标书呈现过程中,答辩是比不可少的,一般的需要答辩的问题是你标书现有的情况,用户或专家一时并不理解,要你阐述一下,还有的情况是,提出某些具体的功能,考核你是如何实现的,对于前一种情况,大部分售前都能处理好,后一种情况,往往很有争议,为什么呢?因为用户或专家心理也有一种实现方法,所以在阐述你的观点的同时,千万不要太过于肯定,我经常听到用户在这个时候说:“呵呵,你说的这个方法,还没有讲到点子上”其实呢,用户也不一定有好的方法,可能是各自的理解不同而已,如果你一时激动,与用户争持,往往得不到好的结果,所以对于这些问题的处理,就要小心了,一般可以在回答之前,一定要说方法有很多种,时间关系先说其中的一种,说完以后呢,一定要补充一句:“其实,这位专家您这个问题问得非常好,您肯定还有其他方法,我们可以继续探讨”,专家也有思维定势,他有可能就透露他的想法,这个时候,你要是业务熟悉,技术熟悉的话,就可以接过来,继续发挥:“哦,对了,你这个想法与我们第2种方式比较类似”这样至少不会出现让你冷场的话。关于如何处理这些答辩,笔者准备了很多案例,将在未来的文章中发表,这里不做深入讨论。第四位:精湛的写作能力大家不要忘记,呈现分两种,一是语言的呈现,二是标书和演讲稿的呈现,一个好的标书,行文要流畅,用语要规范,意思要明了,现实中很多标书都是相互引用(COPY)的,引用太多会导致标书整体质量下降,比如:出现一些低级错误:文字啊,名称啊,最可怕的是出现其他业务背景的东西,我不反对引用,但是一定要有针对性的,对一些功能和实现手段一定要量身定做,对需求一定要分析透彻,由于标书不一定是由一个人写的,每个人的文笔不同,术语也不同,容易造成标书行文不流畅,当然这里也有长时间配合的问题。在这里写关于写作,话题实在太广泛,我在这里强调的是精湛文笔会对标书起到非常好的作用,在日益频繁的投标竞争中,从比较优势来讲,你会超越竞争对手的。售前技术能力在用户面前,售前就是一个专家,特别是投标过程中,用户最想看到的是作为一个公司技术人员的代表,是什么水平,而刚才说了,所有的技术能力,都在呈现中去发挥,问题是,你一定要有技术,你才能去发挥啊,这里就开始讲,一个售前需要具备那些技术相关的背景。第一位:业务专家在IT项目中,行业越来越细分了,如果你对ERP熟悉,你是做不了移动BOSS项目的,隔行如隔山,很难想象一个对用户业务一点背景都没有的人,通过技术能打动用户的心,所以作为一个技术售前,业务要放在第一位,近年来,很多曾经是甲方的用户,或多或

注意事项

本文(售前工程师具有的素质)为本站会员(moji****019)主动上传,金锄头文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即阅读金锄头文库的“版权提示”【网址:https://www.jinchutou.com/h-59.html】,按提示上传提交保证函及证明材料,经审查核实后我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.