分销产品能够被用户使用的前提
一直在做分销供应链系统,就是我们称为DCM,别人称为DRP的东西.分销供应链由于在全国各地有很多分销店,如果做成C/S模式的集中管理,是很不方便的.做成B/S模式可以直接把数据传到总部的服务器,便于统一控管.老总不需要收集各地的数据,无论身在何处只要打开电脑上网就可以看到各地和整个公司的运营情况,这样听上去很美,看上去很炫,可是这个系统要想让客户真正准确无误地用起来,我认为至少要达到以下几点:
1.强大的期初数据收集功能.
所有的公司不可能是在分销产品诞生后才成立,他们采用的第一个e化产品也不大可能是我们的DCM,从MIS到MRP再到MRPII，ERP，很多公司都在一步步地实现企业的e化，必然有大量的期初数据需要导入DCM系统中。如果不能简便地将这些企业原来系统的数据导入到我们DCM系统中，DCM也就失去了存在的意义，因为期初数据就是错的，有赠能指望DCM能够正确地运行那？
客户一般很乐意整理Excel，因为很多系统可以将数据导出到Excel中，再导入到我们DCM中。既然客户热衷于整理Excel，那我们就要提供标准的Excel格式，供客户去整理数据。当然我们现在是要顾问去慢慢地整理期初资料到我们系统中，可是要想做成产品还想依靠顾问是不可能的。真正的产品应该就是一个Setup.exe，然后顾问去培训客户使用。路漫漫其修远兮......
2.即时的数据更新能力.
支持客户的时候发现，他们原来用的系统很多脏数据，比如某个人已经不在了，或者已经转岗了，可是系统中存的数据还是原来的老数据，从而造成了大量的脏数据。如果系统中存在脏数据，牵一发而动全身，整个系统的运行都会受到很大的影响。
特别是促销员管理系统，由于人员流动太大，有可能今天还属于这个网点，明天就属于其他网点了。如何结算其薪资？成本核算时如何，考虑其成本归属？薪资一般是一个月结算一次的，对于一些临时促销员，真正的业务流程又是怎样的那？是雇佣几天，就给几天的钱，还是其他方式？有可能为了短时间的促销活动，召集很大一批的人原来搞促销，但是等活动结束后，就解散，对于这样的一批人，有必要录入系统备案吗？如果不录入系统，那么将来的薪资怎么计算？可是对于一些只出现一次的人，有必要录入吗？很多东西没有很好的灵活处理方式，系统做到现在这个地步很不容易，客户真正用的又是怎样那？
对于一些系统的用户，一般是各个办事处的内勤或者业务员，对于这些人的异动情况一定要能准确无误地即时反应。当然在现实的业务中，客户也会对这样的情况备案。系统应该能对这样的人事异动，发送通知到总部ITS管理员处让其统一更改系统用户，或者采用其他的方式，但要保证能够即时更新。
3.完备的数据统计功能
我们的系统界面录入的数据都是没有统计功能的，虽然可以按照某个查询条件得出该条件下的数据，但没有采取任何的统计汇总动作。这样的数据对客户来说意义是不大的。也就是说我们通过界面只是得到了一些日常工作录入的流水帐，这个功能是必需的，这些数据是将来统计的数据来源，巧妇难为无米之炊。将需求细化到每个具体的操作员，他每天工作后到底想看到什么数据，那些数据的统计对他来说是有意义的。
比如，仓库出货的业务员，每天都会录入很多张的单据，通过操作界面可以看到他今天出货的一张张的单据。一天工作后，他有可能就想知道，他今天出货的数量和金额是一共多少？一个月后，他要知道他这个月出了多少货，赚了多少钱。这些都是非常正常的需求。我们现在很重视操作界面的功能，却把最重要的报表功能当成了镢头。我觉得有必要提升报表的地位，不应该只当成开发后期的扫尾工作，另外，报表这东西，需求一定要跟操作员和看报表的人沟通，他们到底想要看到什么东西。我感觉RD很可怜，盯着需求文档像看天书一样一个个字段从数据库里找，把表连接起来，做完了都不知道是什么意思。这样的状态是不行的。另外目前的报表开发模式效率太低，客户要求的报表数量应该是巨大的，应该跟操作界面的数量差不多，当然我们可以要求客户压缩需求，但真正从产品的角度出发来考虑的话，报表不但不能压缩，好要自己加上很多。
目前的报表实现方式急需更改，开发效率低下，呈献给客户的东西也不直观。
1.强大的期初数据收集功能.
所有的公司不可能是在分销产品诞生后才成立,他们采用的第一个e化产品也不大可能是我们的DCM,从MIS到MRP再到MRPII，ERP，很多公司都在一步步地实现企业的e化，必然有大量的期初数据需要导入DCM系统中。如果不能简便地将这些企业原来系统的数据导入到我们DCM系统中，DCM也就失去了存在的意义，因为期初数据就是错的，有赠能指望DCM能够正确地运行那？
客户一般很乐意整理Excel，因为很多系统可以将数据导出到Excel中，再导入到我们DCM中。既然客户热衷于整理Excel，那我们就要提供标准的Excel格式，供客户去整理数据。当然我们现在是要顾问去慢慢地整理期初资料到我们系统中，可是要想做成产品还想依靠顾问是不可能的。真正的产品应该就是一个Setup.exe，然后顾问去培训客户使用。路漫漫其修远兮......
2.即时的数据更新能力.
支持客户的时候发现，他们原来用的系统很多脏数据，比如某个人已经不在了，或者已经转岗了，可是系统中存的数据还是原来的老数据，从而造成了大量的脏数据。如果系统中存在脏数据，牵一发而动全身，整个系统的运行都会受到很大的影响。
特别是促销员管理系统，由于人员流动太大，有可能今天还属于这个网点，明天就属于其他网点了。如何结算其薪资？成本核算时如何，考虑其成本归属？薪资一般是一个月结算一次的，对于一些临时促销员，真正的业务流程又是怎样的那？是雇佣几天，就给几天的钱，还是其他方式？有可能为了短时间的促销活动，召集很大一批的人原来搞促销，但是等活动结束后，就解散，对于这样的一批人，有必要录入系统备案吗？如果不录入系统，那么将来的薪资怎么计算？可是对于一些只出现一次的人，有必要录入吗？很多东西没有很好的灵活处理方式，系统做到现在这个地步很不容易，客户真正用的又是怎样那？
对于一些系统的用户，一般是各个办事处的内勤或者业务员，对于这些人的异动情况一定要能准确无误地即时反应。当然在现实的业务中，客户也会对这样的情况备案。系统应该能对这样的人事异动，发送通知到总部ITS管理员处让其统一更改系统用户，或者采用其他的方式，但要保证能够即时更新。
3.完备的数据统计功能
我们的系统界面录入的数据都是没有统计功能的，虽然可以按照某个查询条件得出该条件下的数据，但没有采取任何的统计汇总动作。这样的数据对客户来说意义是不大的。也就是说我们通过界面只是得到了一些日常工作录入的流水帐，这个功能是必需的，这些数据是将来统计的数据来源，巧妇难为无米之炊。将需求细化到每个具体的操作员，他每天工作后到底想看到什么数据，那些数据的统计对他来说是有意义的。
比如，仓库出货的业务员，每天都会录入很多张的单据，通过操作界面可以看到他今天出货的一张张的单据。一天工作后，他有可能就想知道，他今天出货的数量和金额是一共多少？一个月后，他要知道他这个月出了多少货，赚了多少钱。这些都是非常正常的需求。我们现在很重视操作界面的功能，却把最重要的报表功能当成了镢头。我觉得有必要提升报表的地位，不应该只当成开发后期的扫尾工作，另外，报表这东西，需求一定要跟操作员和看报表的人沟通，他们到底想要看到什么东西。我感觉RD很可怜，盯着需求文档像看天书一样一个个字段从数据库里找，把表连接起来，做完了都不知道是什么意思。这样的状态是不行的。另外目前的报表开发模式效率太低，客户要求的报表数量应该是巨大的，应该跟操作界面的数量差不多，当然我们可以要求客户压缩需求，但真正从产品的角度出发来考虑的话，报表不但不能压缩，好要自己加上很多。
目前的报表实现方式急需更改，开发效率低下，呈献给客户的东西也不直观。
