关于IT售前、解决方案等一些个人理解和经验之谈

写在前面

本人9年IT研发相关从业经验，主要方向在大数据和数据治理相关研发工作，之所以写这边博客是因为最近三四年工作及以咨询顾问角色对外做相关咨询工作中遇到与售前相关的一些事宜，包括与客户洽谈相关商机、需求调研分析、解决方案编写等相关工作。所以写下该编博客记录一些经验总结。本篇博客的主要内容思维导图如下，同时在某些细节点上会举些个人实际经历过的案例加以说明：

当然本人做售前相关的工作的能力的经验与专业做售前工作的售前工作师有一定的差距，希望看到相关博客的售前工程师或大佬能够联系本人指出该编博客的错误、不足并提供相关的能力、经验的指导。万分感谢！

1.什么是IT售前，主要做什么

首先来看下deepseek的解释

IT售前的主要工作内容
1. 需求分析与诊断
客户访谈：与客户技术/业务部门沟通，挖掘显性需求（如“系统卡顿”）和隐性痛点（如“数据孤岛导致决策延迟”）。
业务场景拆解：将客户业务问题转化为技术语言，例如：
客户抱怨“订单处理慢” → 分析是数据库性能瓶颈，还是业务流程设计问题。
需求优先级排序：区分“必须满足”的核心需求与“锦上添花”的附加需求。

2. 技术方案设计
定制化方案：根据客户预算、IT现状、业务目标，设计可行性方案（如云迁移方案、大数据平台架构）。
技术选型：推荐适配的软硬件产品（如选择私有云还是混合云），平衡性能、成本和扩展性。
方案文档输出：编写《技术建议书》《系统架构图》《实施方案》，用可视化工具（如Visio）呈现技术逻辑。
3. 技术交流与演示
产品演示（Demo）：针对客户场景展示解决方案，例如：
为制造业客户演示物联网设备监控平台的实时告警功能。
技术答疑：回应客户技术团队的专业质疑（如安全合规性、系统兼容性）。
对标竞品：通过技术指标对比（如并发处理能力、灾备方案），凸显自身优势。

4. 招投标支持
标书撰写：编写技术方案部分，确保符合招标文件评分标准。
讲标答辩：向评标委员会讲解技术方案，回答专家提问。
风险预判：分析竞争对手可能提出的技术质疑，提前准备应对策略。

5. 项目风险评估
技术可行性验证：评估客户现有环境是否支持方案落地（如老旧设备能否兼容新系统）。
实施风险预判：识别潜在问题（如数据迁移丢包风险），提出备选方案。
成本测算：协助销售核算实施成本（如服务器资源消耗、第三方接口费用）。
6. 客户关系维护
技术培训：为客户IT团队提供方案预培训，降低理解门槛。
持续价值传递：定期分享行业技术趋势（如AIGC应用案例），强化专业信任。

谈谈个人的理解

个人简洁的理解，IT售前主要工作的核心是作为乙方角色从一个商机到与甲方落成合作（一般以中标为准），实施人员开始实施产品或服务之前的整个过程的工作。但在实施产品和服务过程中，个人建议是售前人员也需要运营和客户的关系，对实施过程中的情况有一定的掌握和了解。之所以这样做，主要是为了让客户满意，能够在客户满意的背景下挖掘后续的可能的合作机会。在实际的工作中，个人觉得售前工作主要包括商机洽谈、方案编写、方便讲解答疑、POC等相关工作，如果你的公司将商务、需求分析、产品演示都有对应的人员角色去执行，那么可能这部分工作不需要你去做，但你需要统筹，如果区分得不明确的话，可能依然需要售前去执行。

2.如何收集、获取、把握、运营商机

一般在企业中，有专门的商务人员去挖掘商机，有一套商机挖掘管理运营的一套机制，同时也会因为公司的业务属性有一定的商机客户群。但大多数情况，售前和商务区分度并不大。所以售前也需要具备如何收集、获取、把握、运营商机的能力。一家IT企业，要么是卖产品（设备），要么就是卖服务。一个商机的来源是多样性的，有可能是客户打公司的官方咨询电话，有可能是商务或售前运作出来的，有可能是人脉关系吃一顿饭、一次交谈建立的、有可能是参加一次论坛、会议建立的。总之，作为一个售前或者一个相关从业人员，要有无时不刻，无处不在的去挖掘出商机的思维惯性。

个人案例

在2021年被一个朋友拉去和他的一个目前在做汽车金融业务的前同事吃饭，吃饭的过程中聊到了数据仓库、数据治理等相关的技术。后面和那个朋友建立了联系，但联系比较少，但我还是会偶尔和他沟通一下最近做什么等闲谈。在2023年，刚好他们有一个汽车金融数据仓库的项目在与客户沟通，了解到他们的客户说当前最大的问题的问题是数据质量不行，需要做在这个项目中结合业务做数据仓库的同时需要加一部分的数据治理能力，刚好我在2023年获得DAMA数据治理专家（CDGP）的认证。因此我在2023年协助他们做了大大小小的方案讨论很多次，包括和他们一起去上海与客户对接多次。从2021年第一次沟通到方案讨论，与客户交流我都是免费协助。后面约150万的项目中标后，我作为数据治理专家的角色帮他们设计了整个数据治理的解决方案编写和平台设计，自己也获得一定的报酬。

在以上个人案例中的总结：

1.不要短见,即使在一两次帮助别人出谋划策了，解决了他人的某些问题，也不要急于求回报，如果没有什么损失，那么就要持之以恒的把机会运作下去。
2.作为个人，需要有一两个专长，如果有权威认证更好，也许有一天你的专长可以解决别人的问题，那么就会成为商业机会。作为公司的员工，需要了解知晓公司的核心产品和能力，同理你公司的核心能力可能赋能其他公司的业务。
3.要善于沟通和多社交，不要说你不认识某某，就连沟通都不愿意。要在沟通中表达自己或所在公司的能力，让被沟通者能够有你可能能够帮助他们解决他们当前问题的感知

3.如何挖掘、分析客户需求及需求调研

挖掘、分析客户需求及需求调研本质上是弄清楚客户想要什么，客户待解决的问题是什么，从而决定是否能够提供给客户什么样的产品或服务去解决客户的诉求。

3.1.需求挖掘的三个层次与目标

层次	定义	目标	方法工具
表层需求	客户直接提出的要求	确认需求边界	清单核对、需求记录表
深层需求	问题背后的业务目标	理解真实痛点与动机	5Why分析法、场景还原
潜在需求	客户未意识到的可能性	引导创新解决方案	竞品对标、技术趋势预判

3.2.需求调研步骤

4.如何编写解决方案及宣讲解决方案

在实际工作中，要首先将编写解决方案和编写建设方案、概要设计、详细设计、等区分开，个人理解解决方案是从宏观上说明拿到客户需求和诉求后，用最简洁全局的方式说明如何去实现需求和解决问题的。解决方案编写一般是最困难也是最复杂的一步。售前的解决方案设计一般是有一份word文档格式和一份ppt格式的，word格式一般是项目审计的一个重要材料，ppt格式的一般是对客户宣讲的，ppt格式由word文档格式精简提炼得出的。本人在参与的相关解决方案设计都是以ppt为主。在编写ppt格式的解决方案时，建议不要超过100页，如果是一般项目，需求较为清晰，项目合同金额较少的，建议页数不要超过30页，对于中大型项目页数可以相对较多，同时建议word和ppt格式都需要编写。解决方案的编写由于行业不同、业务场景不同、项目的性质等差异其实没有标准的套路。这里只举例本人实际参与编写的解决方案提炼出共通的思路和步骤。

编写完解决方案后就需要跟客户宣讲解决方案，在宣讲解决方案时个人的经验总结如下几点：

个人案例

在之前部门的一个同事在编写一个电力相关项目的数据治理解决方案。当时方案写完了就让该同事发给我看一看参考一下，我拿到方案PPT时发现整体的方案有接近80页，内容涉及到的技术部分把整个大数据技术，开源组件、框架基本上都涉及了。同时整个方案给我的感觉是我们产品能够无所不能，解决所有问题。当时因为我没有参与该项目的前期工作，看到方案时只是提出了这个方案是不是太臃肿了。后面得知在宣讲方案时，客户基本没有提出什么问题和互动，最终该项目经历了大约一年时间运作，耗费了大部分人力，最终没有中标。

2024年在个人参与一个汽车金融数据仓库和数据治理项目中，当时是本人亲自编写的方案和讲解的方案，整个方案共约30页ppt（当然该项目合同额较少）。在讲完方案后，客户A提问麻烦将ppt翻到某一页，针对该点我有些问题。当时三四个客户人员都是以这种方式对方案提出问题和互动。

从以上两个案例中总结如下：
1.不要堆砌技术，不要给客户你好像可以造航空母舰的感觉，而是要给客户感觉你在解决他们的问题，哪怕没有全解决。
2.一定要让客户相关人员依据你的方案针对性提出问题，而不是干脆没有问题或者敷衍式提问，这只能证明你的方案客户没有听懂或者不满意，只是礼貌性互动。

5.如何识别主要干系人和运营主要干系人

这里提到的干系人和项目管理中的干系人管理有所区别，这里的干系人主要指客户的哪些人对你运作项目成功有重要影响的人，一般分为以下几类：

分类	说明	如何识别	如何运营
核心决策干系人	发起项目的人、决定你的方案是否通过，是否决定建立合作的人	一般是客户公司的领导，沟通中讲战略、目标较多的人	要重点关注该干系人的想法，看法，在一定层度上需要揣测该干系人的工作形式风格
核心使用干系人	使用产品(设备)、服务的核心人员，你的方案能不能解决他们的问题，你的产品或服务好不好用他们的意见最重要	沟通对接过程中对某些点提出问题最多的人，提出问题最聚焦的人	要在他们关注的点上尽全力满足，对他们的某些诉求和想法进行引导
可能阻碍干系人	可能不希望合作成功的阻碍者，一般对于客户方相对较少或者没有	沟通对接过程中提出***钻问题的人	先引导在化解、避免产生冲突

个人案例

还是参与一个汽车金融数据仓库和数据治理项目，当时参加宣讲会时，会议室内大约有30位客户方相关人员。会议开始后客户方的一个部长大概介绍了一下他们这个项目的背景和目标及对他们公司业务的一些作用等相关的信息。后面讲解方案的时候客户方的其中一位不断地对一些细节提出了比较专业和实际的问题。当时团队就判断出核心决策干系人可能是那位部长，核心使用干系人可能就是这位提出专业问题的客户。后面这位部长的主要是一起参与项目的总监在跟进，也不断地和他沟通，做了很多的商务工作。而对于这位核心使用干系人我自己在跟进，在跟进过程中发现她也在准备考取CDGP认证，当时我就提供了很多资料包括不断地给了她很多的考试指导。后期整个合作是建立的比较顺畅。

从这个案例中总结如下：
a.要在不断地沟通对接中识别出对应的干系人
b.如果在项目合作之外能够给与某些干系人帮助，要力所能及的给与帮助。

6.遇到竞品，竞争对手怎么应对

关于该点我只总结出一点，不要为了自己能够合作成功踩对手抬高自己，这个大忌

个人案例

在去年的项目中，总监跟我沟通说客户方准备采购某公司的成熟的产品去实施他们的数据治理项目，当时和客户对接的时候客户也提出来沟通一下，当时我和客户沟通的内容大致如下：
a.在我与很多客户特别是政府客户对接过程中，我发现早些年的客户比较倾向采购大厂阿里、华为的数据中台产品，但近几年好像这个趋势在下降。在我和类似这些客户沟通中客户反馈这些大厂产品有他们的好处，但对于现有成型的业务用这些产品会又一些困难和麻烦，甚至会带来实施成本的增加。所以我觉得应该要升入调研，如果盲目采购会形成南橘北枳的效应。
b.对于我们来说，因为我们是一直做贵方相关的业务，虽然我们目前没有像大厂一样成熟的产品，但我们会根据你们的业务诉求定制出适用的产品平台出来，成本和实施相对来说比直接采购更低和编写

从以上的案例可以总结第一要实事求是，第二就是目标始终要是帮助客户解决问题。不要去说采购有多么不好，别人的产品有多么不好。

7.如何做好PoC

概念验证（PoC）是在技术或产品开发的早期阶段，通过实验或小规模测试验证其核心创意、技术可行性、市场需求和商业化潜力的过程。实际在项目运作中就是将产品或服务向客户进行部分演示，表达能够满足客户需求及给客户信心。一般情况下PoC工作在解决方案完成并且客户认可解决方案后进行。有较少的情况在解决方案之前进行。个人对如何做好PoC有如下总结：
a.PoC过程着重在前期需求调研，客户访谈及解决方案编写宣讲过程中的客户关注重点，核心疑问点、核心难点上的
b.不管是产品还是服务，在PoC开始之前，要对产品或服务的功能或能力进行裁剪从而做出针对性，同事在进行中要注意尽量不要突出技术环节，如果实现等信息，在一定情况下还是要防止产品或服务被抄袭。毕竟抄袭发生在PoC阶段最多的