青原新媒体 网站首页 资讯列表 资讯内容

OPENERP在中国的现状个问题

2021-03-05| 发布者: 青原新媒体| 查看: 144| 评论: 3|来源:互联网

摘要: 前段时间,@HilpoolHao先生发布了一个关于OpenERP的话题,从评论看,圈内熟悉它的人不多。这里首先做个简介,OpenER...

前段时间,@Hilpool Hao 先生发布了一个关于OpenERP的话题,从评论看,圈内熟悉它的人不多。这里首先做个简介,OpenERP是一款跨平台的模块化设计的开源ERP软件,目标用户定位在中小规模企业,诞生于比利时,从2005年开始开发,根据官方最近发来的邮件数据,OpenERP在全球有200万用户,550+合作伙伴,支持32种语言,应用于110个国家,共3000+个模块(官方模块有200左右,其余为社区版)。应用领域包含教育、公共事业、政府、电信、零售、生产、医疗卫生、服务等行业。知名用户包括AT&T(使用地点:美国,使用人数:500+),Avcom(美国,50-500),BroadConnect(加拿大,5-50),AFLEX(巴西,50-500),APEM(中国,5-50),Anevia(法国,50-500),Solucom(法国,50-500),Agrinos(墨西哥,500+),DANONE(巴西,500+)等等。
最新发布的OpenERP正式版是7.0版本,不需要安装客户端,只需要Server端,用户通过浏览器访问,没有用户数和并发数限制,一个server可以运行多个帐套,支持多公司,对用户的操作系统没有要求。对企业而言,由于源代码开放,这款ERP具有很强的灵活性和可定制性,可以根据企业实际业务情况进行二次开发和实施。OpenERP官方把自己的目标客户定位在中小规模企业。下面主要讨论大家关心的几个问题,希望能抛砖引玉。

稳定性和性能的问题

1、稳定性和性能的问题,这应该是大家关心的主要问题,也是我所遇到的客户在前期咨询阶段提的最多的问题。
从开发者的角度来讲,“不稳定”都是能找到原因的。像毫无征兆突然出现系统崩溃的情况,肯定是不存在的,OpenERP官方模块开发到现在,已经找不到这样的问题了。但也有一些在实际应用中才能发现的非常微小的bug,可能比较隐蔽,在某些业务流中才能体现出来,这种bug由技术人员提交到launchpad,会很快被修复。中文社区有一个由上海-Jeff发起的OpenERP-osbzr版本,每天跟进官方的修复,合并中文社区提交的模块及bug修复。OpenERP的数据库备份和恢复十分便捷,中文社区也开发了自动备份模块,基本上除了人为因素和环境因素,一个正式上线、正在运行的OpenERP系统是非常稳定的。
性能方面,本人没有实际测试过OpenERP所能承受的最大负载,据说是1000用户,国内使用OpenERP的公司以几十人的系统用户数居多,根据官方提供的客户数据,500+的用户数还是可以使用的(不知是否做了负载均衡)。中文社区的广州-步科提供了负载均衡的解决方案,给OpenERP的用户提供了极大的用户数扩充空间。另外,基于这款软件在时区方面存在的问题和性能方面的考虑,服务端的安装应该选择Linux/Unix系统平台,以避免一些不必要的问题。客户端使用任何操作系统都可以,只需要安装浏览器即可(低版本的IE?不在讨论范围内)。

功能性问题

2、功能性问题。
OpenERP官方模块的功能包括销售管理、客户关系管理、采购管理、仓库管理、生产管理、财务管理、人力资源管理、项目管理、POS零售、车辆管理、午餐管理、知识管理、会员管理等等,这些模块下面又有一些功能扩展模块。支持多公司、多仓库、多库位。OpenERP最新的稳定版本是V7.0,借助于社区模块,可以良好的实现用户邮件代收、代发、客户邮件群发、内部消息通讯,8.0的版本还增加了企业内部即时通讯的功能。但是OpenERP的官方模块并不能直接满足大多数企业的所有业务管理,特别是个性化的需求,所以才会出现社区版的3000个左右的模块作为补充,比如酒店管理、质量管理、租赁管理、Magento连接器、短信收发等等,更多的是根据实际业务需求对现有模块功能的补充和扩展。由于这些模块来自于不同的国家、不同的行业应用、不同的开发者,其中还有一部分是旧版本的模块,开发者没有持续更新,所以这3000左右的模块当中,只有少量模块适用于某一特定的企业。官方把这些模块集中在一起提供免费下载。
有了这么多可选模块,好用了吗?未必,Out-of-the-box的可能性很小,国内的中小企业即使是同一行业,不同企业之间的业务流程也不是完全一样的,社区模块刚好满足需求是最好不过,不能满足的就需要企业自己开发或者找服务公司实施。国内的中小企业在上ERP之前,管理上多多少少存在些问题,有些只能用混乱来形容,一谈到定制,不同的业务部门都会提出自己的需求,甚至会碰到有些需求是越级的、冲突的,这种问题必须跟企业上下级部门沟通好才能化解。沟通交流是ERP实施过程中非常重要的一个环节,沟通分析的质量直接决定了项目的实施质量,问题小则发生需求变更、项目延期,大则决定项目生死。前期的这个过程需要双方都有耐心,把各种情况用流程描述出来。一般情况下,只要是人在决策的时候有所依据,计算机程序都能把它的逻辑实现出来。况且OpenERP的代码完全开放,就是照葫芦画瓢,也能实现常规的行业应用,否则就是技术水平问题了。因此,一次合格的OpenERP项目实施,是必须要深入企业、互相沟通、根据实际业务提炼需求并开发功能的,最终目的是要提高效率、降低成本。
另外,社区版的模块很多是没有中文版的,不过翻译起来还算方便。如果把这些模块组合在一起,再加上功能的完善,很多国内小软件就没有活路。但是由于信息不对称,以及国内开源软件社区开发者合作发展的意识薄弱等原因,目前这些小软件还占据着比OpenERP高得多的市场份额。

语言问题

3、语言问题。OpenERP支持32种语言。支持给业务伙伴定义他的语言,这样可以直接打印出对方语言的报价单、询价单、合同等单据。
但是官方中文语言的操作界面基本不能满足国内应用,一是术语翻译不符合国内习惯,二是存在一些未翻译英文。幸好国内有个活跃的OpenERP社区,由保定-粉刷匠把大家组织起来对OpenERP进行本地化翻译。只要参与翻译或者直接购买,就能拿到语言包,覆盖原有语言文件就可以了。不过这些翻译主要针对的是常用模块,没有翻译到的地方,使用者可以在OpenERP界面上直接翻译(OpenERP有着方便的在线翻译和在线开发功能,但是本人并不推荐这种方式)。当然如果找服务公司,语言上的问题是可以一并解决的。语言,不是一个会让用户困扰的问题。

扩展性问题

4、扩展性问题。
这个可以算作功能性问题的深入。OpenERP的功能扩展极其方便,提供了界面开发和程序开发两种方案,界面开发允许具有相应权限的用户在ERP操作界面上添加字段、模型、视图、动作、菜单等等,程序开发是使用IDE写程序代码来完成模块开发。作为一个开发者,不推荐前者,不仅因为界面开发做出来的功能不方便移植,可控性和灵活性也不如程序开发。
OpenERP任何一个模块都可以通过继承的方式修改和添加功能,继承的方式比较好管理,未来如果选择升级系统,要解决的问题也会少很多。当然,直接修改原生模块也是可以的,只不过需要在方案成熟的前提下,并且企业不打算在未来升级到更高版本,否则可能造成升级的成本极高。如果用户使用过一段时间之后,公司业务发生调整,再去修改继承或继承修改OpenERP都是可以的。

技术团队

5、技术团队。
根据官方资料,中国共有官方认证的合作伙伴12家(含香港、台湾),另有更多数量的未注册服务公司。前面已经提到,中国还有一个非常活跃的中文社区,有组织者、开发者、应用者,也有围观者,在几个OpenERP大牛的带领下,共同参与OpenERP的中文翻译、技术学习、应用探讨、Bug修复等等,上面提到的模块和其它几个未提及、非常有用的模块也是由中文社区成员开发和共享出来的。
官方给出了不同预算对应的实施标准。但是由于项目和团队的差异,国内环境下没有公开、统一的实施标准,也没法统一,服务内容和质量也就不一。再加上源代码完全开放,服务成本相对较低,社区内有此发展意向的新成员很多。
odoo openerp.hk odoo 国内也有一些公司自己培养OpenERP开发人员,优势是清楚内部实际运营流程,沟通交流比较便捷,后期持续服务也比较稳定,对外没有什么依赖;这种团队的不足是缺乏ERP项目实施经验,很多ERP的概念和流程需要学习、上手,有个学习周期,在整个项目周期上,一般比请服务公司做时间要长。社区内也有自己摸索了大半年还没上线的案例。所以,如果预算充足,又想缩短项目周期、尽快上线,选择专业的技术团队(服务公司)还是有必要的。



分享至:
| 收藏
收藏 分享 邀请

最新评论(0)

Archiver|手机版|小黑屋|青原新媒体  

GMT+8, 2019-1-6 20:25 , Processed in 0.100947 second(s), 11 queries .

Powered by 青原新媒体 X1.0

© 2015-2020 青原新媒体 版权所有

微信扫一扫