现状、问题及需求应该怎么写

作为售前咨询顾问，对于客户的现状、问题和需求进行深入了解和剖析是非常重要的，毕竟你需要证明建设内容是基于客户实际的，因为我们无法售卖与客户无关的东西。

一、下面是我经常看到的样子，我试着分析图中可能存在的不足：

图1提供了现状和问题，但作为客户，我的疑惑是这些问题与我有什么关系，也不清楚我需要做什么。

图2比图1提供的信息要多些，除了问题还有需求，但作为客户，我还是不知道我的问题是怎么来的。

二、如何才能系统地将现状、问题及需求讲清楚呢？

首先：要让客户明白问题是怎么出现的。

最简单的方法就是将业务过程展开来，每一环节在处理业务过程当中存在什么问题也就一目了然。

如果是数据治理，可以先将数据治理的过程拉出来，数据治理的处理过程自然很长，但客户显然并不需要特别细致，可以适当地进行抽象，比如采集数据、清洗治理和对外服务就是基本的环节，基于这个处理过程将数据取之于业务、最终服务于业务的理念说明白。

其次：针对每个环节讲清楚主要问题点。

基于处理过程，将每一个环节工作中客户当前所存在的问题进行说明，讲清楚这个问题在该环节存在的来龙去脉，以及所造成的影响。

对于一个未进行过数据治理的企业而言，问题自然是要多少有多少，但需要捡重点地说。

所谓重点，就是客户自身的问题以及环节本身最重要的能力点的交集。比如采集数据环节，客户要做智能工厂，需要采集各种生产设备的数据，而客户的生产线经过好几代换线后，设备厂家繁杂，数据标准不一，尤其有些设备无法直接采集数据，需要经过工业协议转换才能采集。

如此复杂的数据环境，最需要的就是此环节的数据集成能力，能否兼收并蓄，海纳百川。

若实在设备过于小众，是否能够方便地快速对接，毕竟客户IT部门大多处于人少活多的状态，如何帮助他们在数据采集对接上降低难度显然是该环节需要重点考虑的。

最后：将客户的重要问题归纳成需求。

按照业务过程将每个环节客户存在的重要问题逐一分析，并最终将这些问题归纳成若干个需求点，若是能够将问题与需要进行映射就更佳。

比如下图所示，最终将客户在数据治理上面的需求归纳成了数据标准、开发技术、指标体系和物料溯源之后，会引申出一个额外的需求，就是谁来落实这些问题。

技术部门自身是无法驱动业务部门的，如果要想把这些工作最终落地，需要有相应的组织和流程来进行保障才行。但这个不是必需的，有些技术部门的领导人在公司特别有影响力，可以不考虑这部分内容。

相比较而言，按照上图的写法，应该可以把现状、问题及需求讲得让客户更明白些，但前面的胶片也并不是就不能用。

这里指的是交流并不是只有胶片而已，还有人的参与在里面，人可以把胶片中不足的部分通过语言进行补充，达到更理想的状态，但这需要人具有较强的沟通能力。

当然也存在一些人有意留部分内容不落胶片的情况，这纯属个人风格，这里不再展开讨论了。