让用户直接使用Rule的语言不是一个好的选择,我认为应当给客户一个GUI,通过这个GUI用户来选择Rule,然后程序将用户的选择翻译成Rule语言,这是我目前对最终用户使用DRools的认知。
因为让用户直接在编辑器中编辑Rule Language要求过高,产生错误的几率过高。如果用户直接操作Rule Language,就类似于用户需要学习一门脚本语言,Learning Curve的问题较突出,而且用户也没有这么多时间。另外,维护起来很困难。
如果做成GUI,用户只需下拉菜单,选择预先设好的条件和参数值即可。当然预先的设定是必不可少,但是很多设定用户都可以自己完成的,尤其是业务数据。
真实ERP产品其实也是这样做的。但是局限于ERP产品开发商出于商业目的,战略规划和预算的投入,Rule的工具还有待完善,尤其是对于复杂的行业应用,当Rule很多时,例如几万条,几十万条,软件的Performance会有问题,并且Bug也会随之更多显现出来。这是让ERP厂商马上修改产品以适应客户的需求往往很难达到。
我看到的DRools BRMS虽然给出了GUI,但是过于简单,对于Rule的数量很少时,管理还是可以的,但是一旦数量级爆增,就很难使用。这是就需要开发适应用户使用习惯的,符合行业习惯的客户终端工具。
因为让用户直接在编辑器中编辑Rule Language要求过高,产生错误的几率过高。如果用户直接操作Rule Language,就类似于用户需要学习一门脚本语言,Learning Curve的问题较突出,而且用户也没有这么多时间。另外,维护起来很困难。
如果做成GUI,用户只需下拉菜单,选择预先设好的条件和参数值即可。当然预先的设定是必不可少,但是很多设定用户都可以自己完成的,尤其是业务数据。
真实ERP产品其实也是这样做的。但是局限于ERP产品开发商出于商业目的,战略规划和预算的投入,Rule的工具还有待完善,尤其是对于复杂的行业应用,当Rule很多时,例如几万条,几十万条,软件的Performance会有问题,并且Bug也会随之更多显现出来。这是让ERP厂商马上修改产品以适应客户的需求往往很难达到。
我看到的DRools BRMS虽然给出了GUI,但是过于简单,对于Rule的数量很少时,管理还是可以的,但是一旦数量级爆增,就很难使用。这是就需要开发适应用户使用习惯的,符合行业习惯的客户终端工具。