星期天,去了朋友那里玩,朋友在一家大型制造企业搞ERP开发,朋友的企业也购买了金蝶ERP,但有些功能达不到要求,所以有一些方面还需要自己开发.
        首先讲到的就是B/S和C/S架构,现在主要的ERP系统都是B/S架构,那么以后的ERP系统会不会走向C/S架构呢?随着丰富的互联网应用的兴起,比如ajax,flex/flash,sliverlight等等的如日中天,还有网络宽带的数量级提高,这些都也许将改变ERP系统传统的B/S架构.金蝶也推出了了在线的软件服务,虽然只是雏形,还看不到什么盈利,但是我想,通过技术的不断改进,一定会有所突破的.
       当然我们还谈到了金蝶ERP的行业性,比如说,我们在电子,塑胶,五金的制造行业常常做的比较好,但一遇上服装类,印刷类的制造行业时,常常是水土不服,因为服装类和印刷类行业的产品特点多,产品生命周期短.尤其我们就谈到了服务中款式的不同颜色的管理,我们都知道金蝶ERP是可以通过辅助属性来管理颜色的,遗憾的是辅助属性仅仅是一个分类,目前还无法做到真正的辅助属性区别,因为尤其是在做成本核算时,并不会将辅助属性考虑在其中, 所以有一些单位的变通做法就是在编码时,将颜色作为一个区分的代码,这样的方式,无疑大大的增加了代码量和管理难度.其实我们还是应该回到辅助属性的层面来考虑,当然,辅助属性的范围过于狭窄,其实完全可以这样,将产品定义为一个编码,将颜色,款式,(定义成多个项目)用其它的代码来表示,一个正式的产品代码就是原始产品,颜色,款式或者其它属性代码的组合.当成本核算的时候都是以最终组合的代码来进行核算,这样即保证了组合的灵活性,也保证了成本核算的正确性.而且直观,方便.在金蝶BOM里面有一类特征类BOM,就是反应这些方面,但似乎用起来并不方便.
       当然我们还谈到了数据处理的方式,最初的软件架构都是两层的,就是表现层和数据层,当表现层发出一个提取数据的指令时,对于数据的处理方式无疑只有两种,一种就是当我发出这指令时,数据层只将给你包含指令中字段的整个表传输给你，在表现层直接进行处理，这种方式使数据层的处理量比较小，但缺点时传输的数据过大，当网络宽带过低，或者网络中数据负荷过大时，会变的很慢．另外一种，正好与第一种相反，当表现层发出指令时，由数据层来帮你处理指令，得到你所需要的数据后才传回给表现层，这样传输的数据量大大减小．表面上看起来，这种方式会快很多，但是我们忽略了，就是表现层比较少的时候，这种方式会比较快，但是表现层比较多，每个表现层派发的指令都由数据层来处理时，可能数据层就会不堪重负，也同样会变的很慢．这样，三层架构便出现了，中间层的出现，正是为了平衡两者的数据处理，首先，指令丢给数据层后，数据层经过简单的处理，再丢给中间层进行处理，中间层把大部的数据处理完毕，再丢给表现层，表现层或不用再处理，直接提取数据，或少量的处理（数据检查）再表现出现．

　　另外，我们还谈到，当一个软件过于大的时候，要查找某一个模块真的有点麻烦，有的时候，我们专业人士如果有一些时候没接触了，一下找起来都会忘记，所以如果有一个搜索的方式就好了，只要打几个字，比如说物料新增，马上就会跳入到物料新增的界面．当然目前金蝶的是用模块代码来表示．