小公司开发mrp

1、.小公司开发mrp/mrpii/erp系统策略 =时间：2001-11-14作者: 蒋建校 作者：jjx 转载请指明出处=1、开发mrp,mrpii还是erp？从技术角度和理论来说，个人完全有能力做出一个很好的mrp或是mrpii系统，但是个人是否能开发出一个好的erp系统，就比较难说，相对来说，开发一个erp系统风险和成本过高。因此，小公司还是应立足于开发mrpii系统，然后逐步扩展其功能。 2、开发工具和平台服务器平台和数据库小公司的产品，其优势在源代码级的定制和高度的灵活性和充分的本地化支持，价格是小公司的优势所在，由于小公司的资金和人力有限，所以unix和

2、oracle这些高价格的请不要考虑。但是可以考虑在服务器端使用linux和oracle for linux之类的来节省成本。但是由于小公司面向的企业的计算机管理人员的水平都不是很高。这个选项的优势不是很明显。 因此，推荐在windows平台上使用msde（针对10个用户端左右的客户，完全免费)或是Microsoft sql server 标准版 开发工具和客户端操作系统平台首选的是powerbuilder，开发效率最高，就是该工具的前景不是很客观其次是vb，缺点是不支持继承。但后续的版本还是非常强大的工具当然，还可以选择delphi,c+builder等，但不建议小公司的产

3、品有可能会对部分客户提供源码，过于复杂的开发工具不利于客户的定制化，也不利于二级中间商的定制，同样，你也很难招到此类的高水平的开发人员。 请不要选择java，你是小公司，你玩不起这个，你公司面向的企业也不需要这个。 系统架构用浏览器还是win32?二层还是三层？选择什么中间层服务器？以怎样的方式向客户提供客户化工具。这个问题比较棘手。 browser vs win32？作为一个web/传统应用都有所涉及的程序员，个人觉得web开发的手段还是不足，尽管有这类的好工具，web界面还是无法和win32界面竞争。因此，在当前开发一个顺应internet的win32 程序是

4、理智的决定. 二层还是多层？如果你的系统在开发过程中，请保持原有的思路不变，当然，我向你推荐使用2.5层的结构，即把商业逻辑通过触发器和存储过程来完成。以便以后的升级。 如果你的系统已经开发完毕，但还未成熟，请抛弃这些异想天开的想法，一切等原系统稳定后再说 如果你的系统已经成熟，但不是三层的或是多层的，请逐步升级成多层结构吧 第一步：建立商业逻辑层，这一层将运行在com+中，这些都是无状态的对象 第二步：建立可编程对象，这一层类似于word,excel的对象模型，是有状态的，运行在客户端，这一层也是属于表示层的。第三步：改造前端，使用可编程对象

5、构造前台。为什么这样做，是自身检查可编程对象的可用性。这同可编程对象作用有关。 中间层？对于中间层服务器而言，由于java的中间层服务器把开发工具锁定在java,因此，不予考虑，可选的有com+和ibm easy cics,当然，我是推荐使用com+的了，赫赫 客户化？客户化可能是源码级的，但这种方式无论是产品提供者或是做具体客户化的都不会很喜欢。 有些系统使用取数公式功能，这客户化的一小部分（客户化报表，而且多是账务而非业务报表，对于mrpii/erp系统而言，财务只是服务的一个部门而不是全部) 理想的方式就是提供一个visual basic for

6、application 环境，并且给用户提供可编程对象，用户可以使用vba环境做二次开发。 如果没有可编程对象，用户也可以直接使用商业逻辑层做客户化，但是这往往不推荐，应为商业层往往没有经过好的修饰，通常只是给程序员使用，而不是面向具体客户，具体客户需要更容易的接口来使用商业对象。 如果将自身软件的界面改造为使用可编程的对象的，则可对可编程对象的易用性和效率做充分的测试和调整。并留下良好的文档。 大家可以看到在这个方案中，使用vb可能会有些优势，但使用pb可能会有不同的客户化策略。 用户界面客户化同visual basic 相比，pb以数据窗口为主要界面

7、表现形式，而数据窗口客户化非常简单，你可以你简单的开发出调整控件位置，设置控件属性，保存设置等一些操作。 一些客户化的第三方工具saxbasic enterprise visual basic for application sdk visual studio for application sdk (vba的进一步发展)summit basicscript 四、要点要点只有一个，尽量使用现成的而不是从头开始比方说报表系统你可以使用excel的已有功能来进行，增加取数功能即可或是借助于cystal report和activereport 2.0这些工具 应用程序的web化也可以通过借助于w