CIO从四方面做好销售部门需求调研

　　众所周知，需求调研对于信息化管理项目的成败与效果有决定性的作用。这也是CIO必须要掌握的一项技能。笔者现在就结合自己的需求调研历程，来跟各位CIO分享一下对企业各个部门进行需求调研时的侧重点以及注意事项。希望这些内容能够帮助各位提高需求调研的成果。今天笔者要谈的是对需求部门的调研。笔者这里总结了四点。

　　一、价格管理方面的需求。

　　笔者认为，销售部门最敏感的数据就是销售价格了。不同的企业可能对这个价格有不同的管理要求。所以笔者认为CIO在给销售部门做需求调研时要从这个销售价格开始。如笔者企业对销售价格就有如下几个控制要求。

　　首先销售价格只有销售部门等少数几个部门的员工可以看到。对于生产部门、仓库部门等等不能够看到销售订单的价格。这主要是出于对价格的保护。既然员工提出了这方面的需求，那么CIO在软件选型时就需要特别注意。笔者也遇到过不少的管理软件，有的有现成的解决方案。只需要在单据类别中进行简单的设置，就可以屏蔽这个销售订单的价格。可见若事先能够向员工确认这个需求，则CIO在软件选型时就可以有针对性的去选择管理软件。可以最大限度降低后续二次开发的几率。

　　其次需要确认销售价格的更改权限。如笔者企业在外地还有自己的销售办事处。那么业务员可以更改销售订单的价格吗?笔者企业现在的管理规则是，业务员可以更改基本销售价格，但是具有一定的限制。普通销售员可以在1.5%的幅度内变更销售价格;而销售经理则可以在2.5%的幅度内调整销售价格。所以他们希望在系统中，也能够进行这个控制。防止销售人员任意更改价格的情况。

　　第三，希望能够实现数量折扣的管理。我们企业为了扩大销售规模，有数量折扣的优惠政策。即如果客户一次性购买数量达到某个程度时，其价格就可以享受一定的优惠。数量折扣又叫商业折扣，其处理方式跟价格折扣不同。数量折扣直接反映在销售帐款中;而价格折扣则是通过财务费用来进行核算。在有些国外的系统中，没有体系这方面的差异。所以CIO在选型时，要搞清楚这两者的差异。不要让对方售前咨询顾问给蒙过去了。对于这方面比较专业的内容，笔者有时候也搞不清楚。笔者的作法是，要么让相关业务员写一份详细的书面说明，最好用举例来说明。或者说在选型的时候，请他们自己跟对方说。如此的话，就可以在最大程度内保证需求调研的质量。如果CIO需求调研后对员工的需求还是一知半解。在这种情况下去为员工选择合适的信息化管理软件时，这个选型的质量就很难有所保证。

　　第四，是否有价格表版本的需求。有些管理软件是通过价格表版本来管理销售价格的。笔者认为这种管理机制非常的有用。如笔者企业的某些产品会有季节性的调价。那么就可以设置多个价格表版本并设置合理的有效期限来应对这种季节性的调价需求。另外，价格表版本机制也可以用来解决一些整体价格的波动问题。如需要把原来的价格都上涨10%，则只需要新建一个价格表版本，然后通过复制价格表版本的方式对每个产品都进行涨价即可。所以笔者比较希望通过价格表本本来管理销售订单的价格。价格表版本的灵活性比较高。不过不是每个系统都是通过价格表版本机制来管理销售订单价格的。在笔者的印象中，好像神州数码的易飞ERP系统没有采用价格表版本的管理方法。而在OracleERP系统中则引入了价格表版本管理。同时最大的开源ERP系统Compiere中也采用了价格表版本的理念。不过话说回来，没有那种方法是最好的，只有最合理的。CIO还是要根据自己企业在销售价格方面的管理需求来确定那种价格管理模式更加合理。

　　第五，多币种的转换问题。笔者企业部门产品是出口的，为此在销售订单价格管理上希望能够实现多币种管理。不过在汇率的管理上，则没有多大的要求。只需要根据月初月末大汇率进行调整即可。其难点在于统计上面。销售人员希望可以根据需要选择不同的汇率进行统计。而且当月的销售价格要跟当月的汇率对应。也就是说，销售人员在4月5日统计3月份的销售数据时，采用的应该是3月份的汇率，而不是当前4月份的汇率。一开始笔者还不知道这方面有什么差异，还是销售员在无意中提到了这个例子。言者无意，听者有心，笔者就把这个当作后续项目选型的指标。还确实起到了不小的作用。

　　有些企业的销售价格管理要求可能还要复杂一些。不过笔者企业主要是以上这几方面的要求。笔者认为在销售价格的需求调研上，没有多少难度。难就难在细心上。CIO要耐心性子，一一的去收集需求。对于自己一些不熟悉的地方，最好能够让对方以例子的形式加以说明，以加强对这方面的理解。

　　二、销售流程方面的调研。

　　在销售流程方面的调研可比较有讲究。笔者认为，在流程调研上一定要强调一个细线条。笔者以前参与过企业的ISO项目。在这个项目中，也需要涉及到销售流程方面的调研。但是，那个流程整理的是非常粗线条的。如在一个订单下单流程上，就只建立了一个粗流程，而没有进行细化，如没有分为样品订单、反单产品、仓库订单等等来分别建立流程。如此的话，这个流程的可执行就很差。

　　笔者认为，在对销售流程进行调研时，一定要细化深入。如对于销售订单下单流程一定要针对不同的订单类型去进行需求调研。因为不同的下单方式其操作流程与控制要点是不同的。如果不细化这些流程的话，则就不能够选择合适的销售管理模块。

　　如就以销售订单下单为例。笔者企业有预收帐款的管理需求。也就是说，客户下单时必须先付款，然后企业才能够安排订单。而光光这个预收帐款，又分为两种情况。一是只有客户付款后企业才会下订单安排生产与采购，这个规则就比较严。二是一个相对宽松一点的，即只要客户在企业出货之前把款打到企业帐户即可。这两中方法现实中操作不同，那么在系统中控制也会有所不同。一个要求在销售订单审核时控制，一个则是在出货之前进行控制。如果CIO不搞清楚这两方面的差异，那么在后续项目实施中，就很难判断合理的控制点。而且在选型的时候，也没有标准来判断某款管理软件是否能够满足企业的需求。故在销售流程的需求调研上，一定要细化、深入。这不仅是系统选型的需要，也是后续项目实施的需要。

　　当然，并不是说要对所有的销售流程都进行如此细致深入的分析，而是要求CIO能够抓住销售部门的主要管理流程。如对于笔者企业来说，销售部门的主要管理流程有以几个。

　　一是销售报价流程。销售报价流程中关系到客户付款条件、客户优惠情况、产品是否属于特价产品、活动期间中的促销情况等等。而且销售报价又直接关系到订单价格的准确性，所以对于销售部门来说这个流程往往是比较关键的。另外，笔者企业还要求能够直接从报价单转换为实际的销售订单，从而减少价格的出错率。笔者在刚开始的软件选型中，就根据这个需求淘汰了好多厂商。

　　二是下单流程。由于订单类型比较多，其又对应了不同的操作方式，故需要进行比较深入细致的需求调研。如笔者企业在订单分类上，就分为样品订单、预付帐款订单、仓库订单、POS订单等等。不同的订单类型其操作方式都是不同的。CIO需要了解各种订单操作方式的差异。只有如此，才能够在软件选型的时候，判断这些操作方式能否一一在系统中实现。根据笔者的经验，报价流程不能够实现的话还可以通过其它方式来补救，但是这个销售订单下单流程必须要在系统中能够一五一十的实现。否则的话，销售员工可能就不会买你的面子。

　　三是订单变更流程。如销售订单原先的数量为2000套。现在客户又增加了1000套变为了3000套。此时该如何处理?如果物料需求计划或者采购计划还没有进行的话，那么直接通过订单变更单变更数量即可。但是如果采购计划已下但是采购订单还没有下时，又该如何处理?如果已经下了采购订单但是供应商还没发货此时采购订单又该如何变更呢?这些都涉及到操作的安全性与便捷性。而且有时候安全与便捷往往是相互矛盾的。所以这个销售订单变更流程CIO也需要一一确认清楚。