会写代码的产品经理

信息化项目售前阶段需要向客户了解的问题,以及需要向客户说明的问题(一)

我将从项目发起者、项目干系人、项目范围初步概述我们售前团队要做的工作,并概述了我们所销售的是什么的问题。
分类:
标签:
2021/2/8 11:40:21

本文讨论技术层面的问题,背景、预算等不在讨论范围。
本文讨论的是定制化项目开发实施的售前问题,而不是标准化产品的售前。
本文面向我们的销售和售前团队,有些需要的信息,需要客户配合调研才能完成。

项目真正发起者

了解谁是真正发起者,有助于我们初步判断项目的目的。有可能的情况下,尽可能与项目的直接发起者沟通,了解项目的高层次目的或根本目的。
了解项目的根本目的,有助于我们判断项目难度和成本,而不被表面的工作量所迷惑,做出远超客户预算的报价错失项目。
什么是根本目的,什么又是表面工作量,我以一个用于生产企业的生产管理软件为例,简单粗暴的归纳:

  • 表面工作量
    生产工艺、流程的电子化,生产过程管理事无巨细的电子化,车间零零总总的设备对接。力求完美与准确。减轻车间生产者与管理者的工作量。

  • 根本目的
    企业一把手希望深化对生产部门的管理。

如果以表面工作量来估价,甚至恨不得马上把最先进的技术与理念销售给客户,成本与价格必然高昂,错失项目,项目的发起者根本没考虑这么多。在这种情况下,你所有的科普都不会有太好的效果,会给客户造成一个“你就是想赚我钱”的认识。销售先进的技术产品需要过程,不可以一蹴而就。

如果我们把所有的工作都只围绕根本目的去做,就会发现,没那么难。那些琐碎的细节都是可以不做的,所谓减轻基层员工的工作量也不重要。我们只要通过技术手段采集好订单信息、产量信息,质量信息,大老板就点头了,才有可能获得信任继续合作。这样我们就可以在初期大幅度降低报价促成项目落地,项目的实施过程也会有的放矢,避免成本超支。

只有知道了项目的真正发起者,根本目的,才能正确的评估与报价。

项目干系人

若要实施项目,可能会涉及哪些部门。在项目管理学科上有一种技术叫做“干系人分析”,我们把项目干系人分为四种类别:

  • 权力大、关注度高
    重点管理、争取支持。

  • 权力大、关注度低
    令其满意、争取支持。

  • 权力小、关注度高
    随时告知、获取支持。

  • 权力小、关注度低
    保持关注,防止关注度变化。

常规来讲项目干系人分析在项目启动之后由项目经理负责。但是我认为在售前阶段,就必须开展一定的前期识别工作,这对项目成本的评估和报价有非常重要的影响。权力大关注度高的干系人多,势必造成项目成本攀升甚至飙升。

所以在售前阶段,就要做好初步的干系人分析,整理好干系人清单,一方面与客户不断沟通,完善修正这个清单,另一方面与技术开发实施团队保持沟通,正确传达。在整理干系人清单的时候,要与各个干系人直接沟通,正确的理解他们的期望和关注的原因,关注的点在哪里。特别是要分析好不同干系人的期望之间可能会存在的冲突。在项目开发实施阶段,要解决这些冲突的成本也是高昂的。

管理软件本质上是管理手段的化身,任何企业管理没有矛盾和冲突是不可能的,售前阶段评估的越准确,项目成本预算就越准确,给客户报价时,也能有理有据,取得信任。

项目范围

说白了就是要干的活。理论上来说这是售前阶段必须要明确的,要列为合同附件的。这里最容易产生的问题是项目范围宽泛,抽象,而解释权掌握在甲方手中。虽然任何项目要求售前团队完全明确项目范围,是不可能的,但依然应该尽可能的,尽最大努力的去做好范围识别。

举例来说,客户要求项目能够把现有的管理流程,在系统中实现。那么就要问清楚:

  • 有哪些流程?
    不是宽泛的“财务审批”,而是具体的就财务审批来说,又到底有哪些流程。我们未必能在售前阶段彻底搞明白流程的细节,但至少要有一个清单,知道有这么一回事的存在。

  • 涉及哪些部门?
    有许多流程是跨部门的,这就容易导致部门之前有一些矛盾冲突存在,也许在长年的工作中,大家达成了某些默契或是潜规则,来处理工作中的一些问题。一旦上了管理系统化,如何调和这些管理流程上矛盾或不合理的地方?这可能需要开发实施团队付出大量的精力和成本。说起来这是甲方自己的问题,需要自己去解决制定好管理流程,但作为乙方我们去陪跑,也是需要付出成本的,这是不可忽略的项目成本。如果搞到最后甲方说无解,那我项目就不验收了?不给钱了?

这样的例子还会有很多,各个模块都会存在这类问题。所以项目的范围说明,不仅仅也不能只是一个“功能清单”,它必须是一个“项目范围说明书”。这项工作不仅仅是对我们自己负责,也是对甲方负责。

我们销售的到底是什么

这是我们售前团队自己首先要理解的一件事。并要把这个理念,传达给客户,获得客户的认可。

我们销售的不是软件,我们销售的是服务。

我们做的是定制化软件系统开发,不是标准化产品,我们的成本是由这个服务的过程产生的。客户要付的费用,是这个服务过程的费用,而不是交付物的费用。

我们先理解一个概念:什么是产品范围,什么是项目范围。

  • 产品范围
    我们的交付物,比如交付 MES 软件、OA 软件。前文讲的“项目范围说明书”,关注的是这一部分的内容。

  • 项目范围
    为了完成所要交付的产品,所要做的所有工作,这里我不讨论技术层面的工作,只讨论客户能够理解的项目层面的工作。

    • 需求调研:与所有相关部门、干系人讨论交流、开会讨论、写文档、画流程图、再循环继续开会讨论、修改文档。
    • 原型设计:根据需求文档,设计原型界面,与所有相关部门和干系人沟通确认、调整修改、讨论听取意见,循环反复。
    • 修改返工:客户的想法变了也好,领导的个人喜好也好,需求调研没有做到位也好,干系人理解错误也好,对错不重要,重要的是这也是我们项目工作可以预见的一部分成本。
    • 部署实施:涉及到人员的差旅、软件的安装调试、试用期间人员的在场支持。
    • 后续支持:使用期间的技术咨询、技术支持等等。这不等同于运维服务,运维服务可能是有合同有费用的,后续支持则是一个宽泛的概念,电话或是微信上咨询一些使用问题,三不五时来一波,都会消耗我们的人力,遇到项目紧张的时候,就会影响我们下一个项目的工作。

这其中需求调研和原型设计的成本巨大,在复杂项目中,占比超过开发实施都是可能的。有些大型项目会把这部分工作单独做为咨询项目立项,可见其复杂度。

我们做定制化信息化项目开发实施,销售的是这一体化的服务过程,必须使客户理解这个概念,才有可能使客户认可我们的报价,理解我们的报价。

联系:

E-mail: C5118@outlook.com

QQ: 279060597

Github: https://github.com/iccb1013

联系:

E-mail: C5118@outlook.com

QQ: 279060597

Github: https://github.com/iccb1013

@南京

关于我 我的免费产品> 我的开源项目>

ICP证:皖ICP备14020687号-1

公安备案:34110202000256