it售前工作计划.docx

上传人:b****8 文档编号:9603460 上传时间:2023-02-05 格式:DOCX 页数:15 大小:25.66KB
下载 相关 举报
it售前工作计划.docx_第1页
第1页 / 共15页
it售前工作计划.docx_第2页
第2页 / 共15页
it售前工作计划.docx_第3页
第3页 / 共15页
it售前工作计划.docx_第4页
第4页 / 共15页
it售前工作计划.docx_第5页
第5页 / 共15页
点击查看更多>>
下载资源
资源描述

it售前工作计划.docx

《it售前工作计划.docx》由会员分享,可在线阅读,更多相关《it售前工作计划.docx(15页珍藏版)》请在冰豆网上搜索。

it售前工作计划.docx

it售前工作计划

it售前工作计划

一、职业成长回顾

总觉得还没有来得及揣摩自己在这一年中的所有得失,2011年已经在龙年的爆竹声中成为过去,细细回首这一年走过的路,虽然没有轰轰烈烈的成绩和战果,但是也经历了一些不平凡的考验和磨砺。

我想,2011年是我工作旅程中的转折一年,在这一年中,我在自己的岗位上迎来了更多的历练和思考。

我想,这是喜悦和汗水并存的一年,也是充满了机遇和挑战的一年。

来到xxxx已经一年光景,作为一名项目工程售前的技术工程师,承蒙公司领导与部门同事的批评指导,在履行自己职责的同时,也逐渐看到了自己距离优秀员工所具备的全面素质要求还有一段需要努力弥补和完善的差距。

空闲的时候我也时常扪心自问,是否拥有足够的资格去享受”售前工程师”这样责任重大的称谓?

自从担任公司项目工程售前技术工程师以来,我的主要工作是为行业部门以及其他业务部门的同事编写项目设计方案、项目施工组织方案,以及就公司现有资源产品整合起来编写解决方案。

记得过去一年最开始独立接受项目派单时,我几乎不太能够理解项目售前的含义,更不了解应该如何去把项目售前的工作开展实施,而是过多的依赖于系统集成项目理论型的方案模板,在一些项目关键点部分处理得不够理想,过于理论化,导致与实际脱节。

通过几次不太成功的案例锻炼之后,慢慢的我也开始形成一套适用于自己成长的思维模式,并摸索出一些相似领域、固定产品的处理办法。

但是回过头来看,那段时期的方案编写也存在许多的不足,体现在对于项目建设的需求经常只顾眼前的形势直奔主题,阐述完功能产品的适用性,能够如何满足客户需求即可,但是却忽略了未来客户发展所带来的变化与扩展,对项目的把握不够全面,毕竟系统集成涉及的领域众多,涵盖的技术面较广,这种着眼现在直奔主题的处理方式也折射出了自己知识面狭小的事实。

好在技术中心的韦总及时发现了我所存在的这些问题,通过单独技术指导以及对整个部门进行的项目经验分享指导,也让我逐渐明白在进行系统集成项目时宏观了解,全局设计的重要,对用户的需求必须要深入的分析,了解客户的企业规模、事务处理流程以及发展规划之后,从全局的角度来进行方案设

计,再突出眼前的局部建设构想,这样才能真正把系统集成方案写好,才能真正让客户满意,而我也必须在具备这样全局把控的思维能力,再加上知识的不断积累,才能成长为一名优秀的售前工程师。

二、工作开展回顾

在过去的一年,我对涉足不同行业的系统集成需求也进行了一些回顾总结,其中视频监控项目与网络安全项目占到了所处理案件的70%,在这些项目中,我所要承担的任务主要包括:

项目需求了解、项目设计方案编写、项目跟踪、项目施工组织方案编写等四项。

而相对来说,项目方案设计又占到了很高的精力付出比例,但是如何提供解决方案完成工作,亦经历了两个时期的成长。

第一阶段:

从产品到方案。

将公司的产品资料修改成针对用户的解决方案,这一类售前支持不在少数,处于对公司内部代理的产品比较熟悉,再加上有一定的技术功底,所以这个时期在编写方案的时候从完成速度上来说比较快速,但不能站在客户价值角度来理解产品。

第二阶段:

从需求到方案。

通过总结问题以及对项目的不断理解,有了自己的知识体系和工作方法,能站在管理咨询的角度采用各种方法去了解客户业务、分析用户需求,并提供解决方案,成果也更符合客户的最终构想--应用集成。

举例来说,早期在处理xxxx码头监控项目时,因为与客户沟通不及时、对客户的应用需求估计不足,在项目设计时过多只考虑采用设备的性能、价格等因素,没有考虑需求变更和客户业务调整带来的风险,导致后期建设时由于客户机房搬迁系统不得不改变架构,将原来本地存储的方式变更为异地远程管理保存;而在摄像机定点上,也由于客户管理方式的变化带来的防区布控点变化。

好在项目报价预留有一定的弹性调整空间,最后勉强把项目实施完成,有惊无险。

而在后来xxxx应急中心网络安全项目建设时,协同厂家合作,我们在充分考虑了用户业务流程、涉及的部门与业务系统操作、到终端用户操作习惯等方面,在设计架构过程中,对网络边界采用高性能防火墙阻隔、对用户终端有一套安全管理平台、对数据在内网中的传输采用了信息交换隔离系统来区分安全业务服务器区和非安全的用户访问区域、对与内网安全检测采用了先进的入侵检测防御系统,从管理的角度出发,

我们又添加了统一管理平台,对各网络设备及终端电脑都能够及时了解状态信息,可以说从外到内都充分考虑到了用户可能存在的安全风险,不仅达到用户预期的建设目的,也为用户提供了一个灵活安全的网络工作环境,因此顺利中得项目。

盘点2011年所达成的项目,统计如下:

三、2013个人职业展望

通过这一年时间的摸索与观察,对于现在各大行业客户,越来越不满足于单一产品的建设需要,他们往往希望单位或企业内部的各个应用子系统能够兼容整合,并且所有的管理能够在统一的平台下进行。

也就是说,对于未来客户系统集成需求我们可以理解或者影响客户往应用系统集成方向发展,而不是单一的提供产品集成,在激烈的行业竞争中,我们需要提供客户耳目一新的亮点方案。

在学习交流中我发现,数据集中与云计算将是未来发展的技术方向,所谓数据集中,就是把企业所有日常办公产生的数据集中在机房管理端,确保数据的安全有效管理,杜绝一些潜在或已知的泄密危险;而云计算通俗来说既是虚拟化服务,包括应用虚拟化、桌面虚拟化和服务器虚拟化,这样的技术发展将越来越降低对客户终端的硬件要求,转而提升系统应用的灵活性和高可用性。

除了对技术方面的发展追求,在职业规划中我也有一些为自己客观定位的要求。

在过去的工作开展中,接受客户案件的时候,我想自己可能过多的是处在一种被动的状态下,按照客户提出的需求进行分析,了解客户一时期内的发展状况,然后提出可行的办法。

但是我想这样远不能够树立自己在客户心目中理想方案解决者的形象地位,我更倾向于为客户树立一种可靠可信的咨询师的身份角色。

不单单对客户的需求进行分析,还要对客户所在行业进行一些必要的了解,清楚行业发展趋势以及新兴技术的应用案例,从硬件和软件结合的角度出发来进行整体解决方案设计,提供给客户综合应用解决方案。

明确了个人的发展方向与职业角色定位,这就要求自己仍然需要不断的知识积累,尤其在数据集中所涉及的存储、备份、数据恢复以及云服务涉及的虚拟化技术上投入一些精力,结合项目实施者成功经验的分享,总结出适合自己在新的一年工作中处理项目的办法。

四、2012具体目标规划

新时期个人自我提高的要求不能只是口头决心的表露,必须要有一个能够不断鞭策自己的目标计划表,按照自己制定的每一条发展表纲而努力,力求实现每一项既定目标。

应用系统集成不可能脱离软件实现,所以在2012年的目标计划表中必须添加对软件系统的学习,包括OA系统、业务应用系统的了解,从架构上、操作应用上进行系统的了解,然后才能结合硬件资源,整合出一套完善的系统应用方案。

售前主要的工作内容1.售前人员需要具备的素质

售前人员应该是项目开发人员与业务销售人员的桥梁,在业务销售人员眼中,售前人员扮演的是技术人员或技术专家的角色,而在项目实施中的开发人员眼中,售前人员是专注技术的销售人员,在用户眼中,售前人员,是代表公司技术水平的技术专家。

在一个具体的售前技术支持活动中,售前人员协调销售人员、用户、后期开发人员间的关系,将公司的技术实力向用户展现,听取用户的初步需求,与用户讨论项目系统的初步框架,协助销售人员将公司的产品和技术优势推荐给用户,为后期开发人员屏蔽用户不合理的、给项目实施带来技术风险的需求,是项目的技术框架的最初设计者。

售前人员要求具备一个技术人员和销售人员两方面的素质,具体如下:

●熟悉自己的产品。

●具有比较全面技术专业知识。

熟悉当前IT的技术发展方向。

●对本公司的开发能力、技术优势、劣势有比较清楚的认识。

●作为行业软件的销售,必须熟悉本行业的业务,对本行业的信息化的现状和发展方向有一定的认识,了解行业中的其它专业软件的基本情况。

●熟悉本行业的技术和产品动向,了解同类产品及其竞争对手的情况和特点。

●能熟练使用文本和图形编辑器进行方案、标书的编写。

●熟悉项目招投标的一般程序。

●善于交流,有良好的沟通能力和技巧。

2.1.招投标前与用户的接触

2.2.投标及投标文件的准备

2.2.1成立投标小组

2.2.2.编写投标书

2.3.参加投标

2.3.1.讲标

2.3.2.答疑

2.4.商务和技术谈判

3.投标文件的编写

4.编写业务需求说明书

5.业务需求交付给研发团队

售前工作刚好在销售和技术部门中间,售前工作要求的是串联工作.

在工作当中,各个软件公司对售前岗位考核各不相同,归纳一般是以下几个方面.

1、公司内业务产品理解程度,具体考核手段以培训和ppt交付成果。

2、配合销售打单,对销售支撑能力评价,考核手段以销售反馈为主。

3、能力考核以销售签单比例为依据。

综合跟踪项目情况。

4、对交流过程中需求把握能力。

对公司产品线提升的贡献能力。

5、需求梳理交付程度,研发和用户两侧对需求认同是一致的,并且可实现的。

由于我也刚刚从事售前工作,很多都在摸索,提出的内容也比较空。

落地还需要磨合和实验过程。

IT售前方案的撰写

准备阶段

只有弄懂了客户的需求,才能写出有针对性的方案

很多人对写方案非常没有信心,一涉及到方案的事情,就束手无策,到处求人。

写方案不难,知道怎么写才难。

关于写方案我只总结一点,结构化地去组织你的思想。

有结构就有思路,有思路就有方案。

另外真正写方案的人,对自己写过的方案是永远不会满意的,只有这样,每次都会进步一点点,解决方案水平质量就会随公司能力不断增长。

撰写方案的几个要点

一、要有体系

一旦用户要求提供关于PDM的方案,很多人大脑是一片空白,完全不知道从哪里下手。

很多人说起自己的产品来,好象知道不少卖点,不过真要写出来,又觉得无从下笔。

这种情况一般是写方案者不熟悉自己产品体系造成的,知道一两个甚至更多的产品卖点不难,但难就难在成体系,知识就是成体系的点构成的,而不是一句一句离散的说法构成的。

因为我们这个行业从业人员说句不客气的话,大部分对所销售实施的管理系统并没有很深入的研究,都是半路出家,从头开始,在学习过程中熟悉,在熟悉过程中领悟。

所以一下子去驾驭一个整体方案是很痛苦的。

只有当一个人对一个产品思路有体系以后,才能够写出完整的方案,否则就是一个单元也要费尽脑汁。

所以一个人要想写好一个方案,首先要把自己产品的来龙去脉,功能模块,适应领域,典型客户实施情况有一个全面的了解,这样才能建立一个完整的知识体系,然后逐步补充竞争对手知识和一些技术性知识,不断深化自己的知识体系。

二、要有思路

有很多用户看多了模板化的方案以后,想看一些针对他们自己的业务的个性化内容,这个时候有的人按照标准方案模板修改还勉强能对付,但对于个性化内容针对性方案就速手无策了。

这种情况从根本上讲还是写方案者不熟悉企业业务造成的,写方案,特别是针对性方案不仅仅要求了解企业的需求,而且要知道这些需求是在何种业务需

求下产生的,用户提出这样的要求到底想解决什么问题,把这个问题找出来,一般针对性解决思路就有了,有了思路,自然可以很好的写方案。

所以一个人要写好方案,还需要了解下游客户的业务,了解业务最有效的方法就是亲自做几次详尽的业务调研,有了业务调研做基础,在调研过程中把握用户所关注的重难点问题,自然可以比较好的确定方案的个性化内容思路。

解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。

三、要有素材

一般不经常写方案的人,在写一个方案的时候,即使有想法,有思路,但往往也会很累,就是因为缺少足够的素材。

很多项目现在都是投标,不同用户可能有不同投标的要求,这样很难用一个方案去适应所有的用户,因此在每个方案中都有一些需要准备的内容。

这些内容基本上是通用的,但如果没有足够积累每次编制方案就需要花费大量时间去准备,造成方案完成周期过长。

所以写好方案必须具备这三个条件,第一方案编制者对企业业务要很熟悉,或者有相关业务调研经验,第二方案编制者对产品非常熟悉,至少对自己产品功能模块作用很清楚,第三方案编制者手上有大量可公用的素材库。

四、要有层次

很多人刚和用户接触没有多久,为了表现自己对客户的重视,马上表示要提供方案,当然有的客户刚刚开始选型,也不知道到底要什么搞,也要供应商马上提供一个方案。

结果拍胸脯容易,写方案难,自己写不出来只好求公司,公司没有安排专人了解情况,只好按模板制作一个,用户一看几个供应商方案内容都差不多,觉得不好,又总结出一些个性化要求,于是大家有开始折腾第二轮方案。

其实方案编制在不同阶段有不同策略,不要轻易提供方案。

刚开始接触是可以提供项目合作建议书,类似可行性报告,项目需要考察软件技术,可以提供标准的产品技术白皮书,到了经过售前调研,有所准备,在演示前后阶段和其它竞争对手刺刀见红的时候,才在知己知彼的基础上提供解决方案或者投标书。

过早提供方案只能匆匆了事,时间紧急,质量自然不高,自然也就觉得方案难写。

想急就又能解决问题的事情,本来就是一般人做不来的。

方案想要写得好,一定要用心,用心就一定要耗时间,指望用几个小时写出一个高质量的方案是不可能的。

如果你做了精心调研,你写不出一个好方案唯一缺的是技巧。

写方案是一种技巧性工作,明白了这一点,大家都可以经过练习写出好的方案。

撰写方案常见的错误

错误一、只有论点,没有论证

不好的解决方案粗看起来非常厚重,其实都是功能罗列,象产品手册摘要版,不象方案书。

不好的方案是一大堆内容,淹没在一堆纸里面,也不知道想说什么,给你一个厚度,证明我们的工作质量很高。

我们国内许多的企业客户特别是大型企业都很在乎这点,认为可以从方案厚薄中看出对项目重视程度。

如果你做了精心调研,你写不出一个好方案唯一缺的是技巧。

写方案是一种技巧性工作,有个金字塔式的写做原理,也就是说文章一定是有结构的。

所以真正好的方案,不一定厚,但能看出你用心,你认真。

现在的解决方案一个不好的倾向是"长、厚、全",看起来面面俱到,其实对决策者没有帮助。

所有的方案无差异性,每家供应商都说自己能解决这些问题,而且都有成功案例。

结果所有的方案都无法给决策者简明的判断依据,不得不费更大劲去做产品演示和用户考察。

如果不能找到解决这些问题的原因,简单地去解决这些现象,就象治病不能治根一样。

这样一个模板化,自我膨胀化的方案想打动用户的心是非常困难的。

不好的解决方案最大的问题就象写一篇议论文,能够发现问题,提出答案,但没有论证。

没有论证的东西不管内容陈列得多么繁复,名词多么吓人,但是无法打动用户,特别是那种理性的用户。

看到方案时候,其实很多用户下不了决心,他会感觉每家都差不多。

如果从没看过方案的人,突然看到这几个方案,你为什么会感觉某个方案写得好呢,关键是有的方案图画的好,通过图,通过表,会感觉这个公司还不错,很规范。

但对内容认可程度并不高,实际上没看懂。

错误二、业务解决方案成为功能列表

解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列,或者参照软件用户手册罗列,这种解决方案不是按照用户业务去准备的内容,而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。

大凡按照功能列表组织的解决方案用户会有一个体会,庞大而庸长,但要看到自己想看到的部分非常困难。

而且这种方案还有一个特点,一个问题反反复复的提,在业务背景中指出某个问题,讲一通,在价值分析中又重点解释一通,到了功能介绍时又将某个问题来龙去脉概要说明一下,给用户感觉是一堆资料的堆积,哪里体现出了方案的针对性呢?

按功能列表准备方案的做法在很长一段时间内不会消失,这和我们普遍是4P即:

Product、Price、Place和Promotion销售人员,还缺少SPIN销售人员有关,在资源不足的情况下,要保证效率就只能提供功能列表方案了。

附:

术语解析

PDM:

ProductDataManagement,PDM是一门用来管理所有与产品相关信息和所有与产品相关过程的技术。

4P:

Product、Price、Place和Promotion销售人员。

做售前-售前工作职责和流程

在IT界,成功的完成一个项目的需要销售人员、售前人员、项目实施人员、售后服务人员等密切

协作。

本文从售前技术支持人员的角度,对售前技术支持工作的过程进行了描述,根据作者在售前的经验,提

出了各环节的应该注意的要点,希望能对售前人员的工作有一定的帮助。

1.售前人员需要具备的素质

售前人员应该是项目开发人员与业务销售人员的桥梁,在业务销售人员眼中,售前人员扮演的是技术人员或技

术专家的角色,而在项目实施中的开发人员眼中,售前人员是专注技术的销售人员,在用户眼中,售前人员,

是代表公司技术水平的技术专家。

在一个具体的售前技术支持活动中,售前人员协调销售人员、用户、后期开

发人员间的关系,将公司的技术实力向用户展现,听取用户的初步需求,与用户讨论项目系统的初步框架,协

助销售人员将公司的产品和技术优势推荐给用户,为后期开发人员屏蔽用户不合理的、给项目实施带来技术风

险的需求,是项目的技术框架的最初设计者。

售前人员要求具备一个技术人员和销售人员两方面的素质,具体如下:

●熟悉自己的产品。

●具有比较全面技术专业知识。

熟悉当前IT的技术发展方向。

●对本公司的开发能力、技术优势、劣势有比较清楚的认识。

●作为行业软件的销售,必须熟悉本行业的业务,对本行业的信息化的现状和发展方向有一定的认识,了解行

业中的其它专业软件的基本情况。

●熟悉本行业的技术和产品动向,了解同类产品及其竞争对手的情况和特点。

●能熟练使用文本和图形编辑器进行方案、标书的编写。

●熟悉项目招投标的一般程序。

●善于交流,有良好的沟通能力和技巧。

一个人通常不可能具备这么全面的知识和技能,因此,对于大型项目,为了与客户进行全方位的交流,展现公

司实力,对系统进行初步的论证和设计,其售前往往是一个团队,这个团队根据项目的需求,可能有行业业务

专家,数据库专家、操作系统专家、信息安全专家、网络构架师、软件系统分析员、项目管理专家等角色。

2.项目招投标活动的过程描述

项目从前期跟踪,签单,作为售前人员,需要与销售人员密切合作。

通常获得一个项目的前期过程如下:

1.销售人员拜访用户,了解用户的项目基本情况,向用户介绍公司和公司的产品,与用户建立起良好的关系。

2.销售人员在用户招标前,引入售前技术支持人员,与用户进行技术上的交流和沟通,了解用户在项目上的需

求,偏好的技术构架,引导用户到本公司的技术思路上,这个过程可能是需要多次反复。

至少要做到用户对公

司有一定的兴趣,愿意邀请你参加投标。

3.用户发招标书,售前人员根据招标书的要求,结合前期与用户交流的情况,编写投标书。

4.参加招投标会,进行技术、商务上的讲解和答疑。

5.参加商务和技术的谈判,起草项目商务合同和技术协议书。

6.签订合同,项目实施以及维护。

2.1.招投标前与用户的接触

招投标前与用户接触,了解用户的真实需求和想法,通过交流,了解用户对系统框架、平台、新技术的偏好,

使以后在投标中能“投其所好”“命中要害”。

介绍公司的技术和产品,使用户在招标前对本公司技术和产品能有

比较清楚的认识和了解,将用户的需求引导到本公司的技术和产品的思路上,使用户的在技术上对本公司有一

定的偏好。

交流和需要了解的内容通常包括:

1.用户的组织机构,信息化的现状,现有的硬件设备、网络情况、正在使用的软件系统情况;

2.新系统的规划、目标、规模,要求等,包括用户对系统的安全性、可靠性、易用性、扩展性的要求;

3.业务内容、业务流程系统的现状,软件功能需求;

4.平台和数据库的选型;

5.信息安全、存储的需求;

6.对软件开发机制的认识;

7.用户感兴趣的热点技术;

交流应该广泛,不要只限于项目的具体负责人,如果有条件,可以拜访更上级的用户,以及各部门的主要负责

人或技术权威,尽量了解用户的对项目的认识和想法,交流和拜访中要善于识别用户的身份,抓住对项目有决

定权、影响大的用户的想法,同时,可以初步分析哪些用户可能是以后的招标评委,留意他们对项目感兴趣的

地方。

以便在投标和讲标中有所针对性。

引导用户向本公司的擅长的技术路线和产品特点上。

可以将以往做过项目的情况、功能特点讲给用户,最好是

借助演示,这是用户会告诉你哪些是他感兴趣的,哪些是没有意思的,其它对手的产品是什么样的等等。

这样

便于与用户进行深入的交流,找到与用户相互的共鸣点。

跟踪和了解对手情况,了解同类产品的现状,这是一个长期积累的过程,分析对手的产品和解决方案可能的特

点,找到或提出比对手有新意的、能吸引用户的系统亮点。

当然,这些亮点的提出必须先考虑自己的技术实力

和项目的投资规模。

2.2.投标及投标文件的准备

2.2.1成立投标小组

成立项目投标小组,投标小组的核心应该是项目的法人代表授权人。

根据项目的规模、技术难度和招标时间的

要求,制订投标计划,将计划分解到每个人员上,确定每个人工作内容和计划,确定计划的执行的监督人员。

投标的时间一般都是确定的日期,而且比较短,这也是考验一个公司和团队的响应速度,必须在这个有限的时

间内完成投标书的制作,否则,将由于准备不充分而丢标。

这需要平时的技术积累,对行业知识的积累,投标

书的积累,如有类似的的标书或模版,以及良好的团队合作精神和氛围。

作为一个行业应用项目,技术部分可能涉及到的人员有:

网络规划师、硬件产品经理、软件构架师、行业专家

、数据规划专家或数据库专家信息安全专家,以及其它专业领域的专家等。

这个团队建立,需要整合公司内部

和外部的相关资源,来共同完成。

例如,可以临时请专业公司相关的售前支持、相关行业的

专家、相关专业的大学教授等来扮演相关的角色。

甚至可以考虑与相关的其它公司联合投标。

在投标小组中,建立保密制度,特别是对于特大型项目,关于报价、核心技术等内容,最好在小范围讨论和确

定。

必要的情况下可采用封闭开发的方式。

2.2.2.编写投标书

用户的招标书通常包括:

招标邀请函、商务要求部分、技术要求部分、附件和附图等文档,这些文档是编写投

标书的基础。

投标小组成员在编写标书前,应该仔细、反复阅读招标书,特别是对投标商的资质要求等内容,

投标小组对招标书进行讨论,找出招标书中描述不清楚的地方,根据情况向招标方提出要求解释,确定项目资

质情况、投标以及实施的风险、对手情况、投标的优势、劣势等;制订投标策略;确定投标书的内容、投标方

式;初步编写投标书的大纲。

在投标书编写过程中,应该注意一下几点:

1.商务投标书应该按照招标书的要求进行严格的应答,应答的顺序和格式最好严格遵循招标书的要求。

2.对于招标书没有要求的内容,特别是商务标书,最好不要画蛇添足,如果希望增加对项目投标有帮助的资质

,最好经过慎重的考虑,确保没有漏洞。

商务部分主要的目的是展示投标公司的实力,确保参加投标的资格。

首要是确保投标有效。

注意有些东西可以讲出来,但不是所有可以讲出来的东西都适合写出来。

3.差异表的处理:

对于投标文件与招标文件中有差异的部分,通常招标方要求标注在差异表中,在编写投标方

案时,应该尽可能的将差异部分找出来,描述清楚,但是,在最后整理、提交差异表时,就需要特别慎重,并

不是每个差异都适合在这个正式的场所

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 总结汇报 > 学习总结

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1