再谈开源ERP

cs19801023

最初由 醉眼看世界 发布
[B]说来听听 [/B]

呵呵，“可以”的概念是理论上可行。

nseernseer

最初由 w39 发布
[B]对于开源ERP，我的观点很明确：

仅仅是促进中国ERP产品研究技术的层次来说，这是绝对值得提倡的。但仅仅只能作为提高技术水平的层次。

如果一个企业要用开源ERP，除非你有非常强大的内部IT团队，我建议企业慎之又慎。

ERP不仅仅是软件技术。 [/B]

非常高兴超级斑竹能够就开源ERP谈这么多，而且确实很中肯，特别是站在用户的角度所说的、所分析的都是客观存在的。

实际上我们探讨、实践开源ERP很长时间了（2004年就开始准备开源，2006年正式开源）。作为客户有些矛盾：一方面想战略性的参与，但是又不想真正的干活。其实这符合社会分工越来越细的原则，活都被用户自己干了，那么我们的软件公司吃什么？

经过我们一年的实践，证明如果想让开源erp在客户方面取得成功，必须有一支强大的、本地化的、有增值开发能力的实施、培训、开发队伍，这些队伍就是分布在各地的中小软件公司。他们不是简单的代理，也不是渠道，而是使用完全开放的开源erp平台身份独立的本地公司，我们称为加盟合作伙伴。目前我们已有3家。我们为加盟合作伙伴提供培训、技术支持、技术文档、专有工具等服务来帮助客户实施erp,我们不主张用户绝对的自我实施开源erp，因为用户没有精力去做自己核心业务之外的事！

cs19801023

最初由 nseernseer 发布
[B]

经过我们一年的实践，证明如果想让开源erp在客户方面取得成功，必须有一支强大的、本地化的、有增值开发能力的实施、培训、开发队伍，这些队伍就是分布在各地的中小软件公司。 [/B]

山东那边吗？我知道那边2年前提过这个想法。
谁做主导？这很重要。软件公司还是企业，还是另有第三方。这个想法说真的挺好的，但是至少在现在实施的话，时机不对。

nseernseer

楼主所提到的：
“1、对软件的理解
对于程序员来说，如果是自己设计自己开发一套软件产品，我想难度会比“在别人产品的基础上进行修改”要容易的多。思路是自己的，想法也是自己的，只是如何实现罢了。对于开源产品来说也存在同样的问题：程序员要去理解并掌握这套新的系统需要多长时间。和对成品软件的实施不同，要掌握的不仅仅是软件的功能，更要掌握软件的设计思路，开发的技巧。多长时间能掌握这些，后续开发的程序是不是狗尾续貂是每个IT经理需要考虑的。”，


我不是很同意以上观点，一个erp应用软件的开发成熟周期不会很短的，我们这个被许多人称之为垃圾的开源erp是经历近7年的心血，但是目前任何个人或者开发团队在客户规定的项目期间完成这样的软件是不现实的。就像sap是经历了30多年的积累，知识需要积累，软件更需要积累。

其实我知道很多人一直对恩信科技开源erp心存疑虑：恩信科技开源erp是否值得大家作二次开发，早期很多人以为我们是小儿科、找噱头，其实这才是我不能说服大家的原因，况且ITPUB里高手云集，而且都是实施大型企业的高级顾问（我们比喻为开宝马、奔驰的），况且我们的产品（我们现在比喻为小夏利）又是完全b/s结构的大家一开始看不惯，我们都能理解。但是冷眼观察过我们甚至加盟我们的朋友对我们还是很肯定，我们的产品一直在升级，我们自己还有能维持5年没有收入而正常运营所需的现金储备，但是公司为了更快发展所以马上就要接受VC了，所以我们会持续发展，会一步一个脚印得让它成功！


也许大家通过我已经了解恩信科技团队了，我们非常有耐力，非常顽强，我们对开源erp运营模式的思维方式是：坚信它会成功，每天所想的、所作的就是如何促进尽快成功，愿意结交ITPUB高手，这就是为什么不愿放弃itpub,喜欢在此讨论、宣传的原因
希望大家支持！

trigger_lau

大家都摆出自己的观点吧，多沟通总会有好处。

eric0125

分析精辟

相信任何一家成熟的企业都不会冒这个险

guoliang0571

nseernseer
中级会员

注册日期: 2006 Jun
来自:
技术贴数:83
精华贴数:0
论坛积分:457
论坛排名:5835
论坛徽章:0
======================================
上面这个家伙又来了　，我建议封杀他的号码．．．．．
看看你们恩信的代码，　开源，开你个头．．．．你们的代码中所有的ＳＱＬ语句连一个事务处理都没有，我想懂点技术的人都知道事务的重要性，，，
　　　看见一次我扁一次．．．．．火大了，　别侮辱我们的智商，那代码明显有问题．．

wjfonhand

39好文，读过不加评论不快。

Linux在中国境遇可能并不能算很好，至少以我所知，客户端首选是windows系统，服务器端厂商大多附带了更成熟的Unix操作系统，与商业软件比起来，Linux还算不上成功。

关于开源的涵义，不只源代码开放这么简单。至少我觉得社区驱动和集市式开发是开源的核心，源代码开放只是一个表象罢了。所以其实很多开源项目并非真正的开源，即使它开放了全部的源代码，软件本身的功能和项目控制都在几个人手里，那也不能算是真正的开源。

所以我印象中开源最成功的当推TOMCAT和JUNIT，而非ECLIPSE。TOMCAT不只是一个与商业web服务器的竞争的开源产品，更重要的是它是J2EE WEB服务器的标准实现，是按行业标准开发的。而JUNIT带来的是一种TDD的开发方法，这些都不只是一堆JAVA代码的价值。

那么我们再看开源ERP的优势。ERP作为一种企业管理工具，其中涵盖诸多的管理理论和方法。比如工作流，物料需求计划，信用管理以及ABC成本法等等。这些可以说大部分并不是软件开发人员能够精通的领域，这样一个以管理专家和程序员共同组成的开源社区就能弥补跨行业的认知局限，因为从产业发展的现状看，SAP多年积淀的成功不可复制。也就是说，每个人贡献自己特长的领域，比如国内很多社区做的本地化工作，然后拿走你想要的东西。所贡献不一定是资金，所索取也不一定只是源代码。COMPIERE公司同时也是很多行业标准的会员企业，比如workflow.

我之所以关注开源ERP，是因为我知道现在市场上很多商业的或非商业的ERP开发或实施都是无标准的，市场已经乱到了任何程序员都敢说自己写得MIS就是比SAP更牛的ERP。劣币驱逐良币的经济学规律，很难让从业者再潜心投入，用骗就可以了。开源如果能够给程序员一个清晰的开发思路，何乐不为呢？

单论源代码开放，sap的abap语言让更多人有机会了解商业逻辑的技术实现细节。只要一个/h，结合online help，你就能看到令你惊叹的设计。这也是二次开发人员水平提高的一个捷径。

39的经验和分析我大多赞同，应该说诸多限制使开源erp即使是很优秀的产品也不一定能在现在中国的土地上有所建树。能不能总结一下：

第一、实施的风险。不管是否开源，这个风险都是客观存在的。而商业erp厂商是如何规避这个风险的呢？有软件商亲自派实施顾问的（姑且称其为顾问），有发展合作伙伴通过教育培训培养伙伴实施能力的（sap和oracle这样做的，可是项目上有几个PA顾问或真正理解了asap实施方法论的呢？）。如何衡量实施效果和客户投入产出比，这本来就没有定论。何谈开源就必定风险更大呢？compiere社区正是有很多合作伙伴参与社区引导compiere软件发展的，作为最终用户和软件商的中间环节，咨询公司更多参与产品的设计和发展，以更开放的模式去运作一个产业链，本身就是一个很好的解决方案。一年前我在topoint曾说sap b1要推广首先要建立一个中立的社区，sap、咨询伙伴、用户能够有效互动，并把最终积淀反作用于产品开发和实施过程，这样才能更好地提高客户满意度。这也是itpub上人人为我我为人人精神的一个延伸。

第二、二次开发的风险。同样，商业产品也存在这些问题。无论什么样的项目，如果是外行指导内行（往往残酷的现实都是这样），必失败无疑。用户的需求可能是错的，可是他的出发点一定是有道理的。更大范围的社区知识共享能够让外部专家参与到企业内部项目中来，以较低的成本（比起商业软件）构建真正符合个性化需求的系统。至于影响升级，sap提供的关于命名空间的方案和模块化的系统架构对现在的技术人员都不是太大的难题，只不过规范的保障执行是一个博弈，即使是R3项目，也有改标准程序的case，SAP公司也没法全部拒绝。

所以我觉得现在开源ERP的问题是：是不是有真正的开源社区驱动的ERP项目，什么样的盈利模式能保证开源继续走好。

关于盈利模式，我也曾有过思考。

JBOSS的盈利模式是建立在最终用户把服务视同产品购买的前提下。在中国，除了培训，这种意识还没建立起来。但是既然IBM已经在半世纪前把软件产业从硬件产业中分离出来，又是IBM在上世纪末提出了靠卖IT服务赚钱，有老大带路，春天很快会来的。

无论如何，我仍旧充满信心。虽然很艰难，但COMPIERE已经走出了第一步，但不知adempiere这个事件是用户之福还是用户之祸。

无论如何，如果作为咨询服务提供商，透明运作代码公开的进销存比起所谓自主开发功能齐全的小ERP产品更容易令我信服。真正了解产品，才能做到对客户负责。毕竟，我们卖的是服务。

wjfonhand

IBM的选择告诉我们，随着IT业的发展，利润将从硬件逐步流向软件再流向服务。作为IT咨询服务的补充品，ERP软件本身成本的降低是大势。

SAP为什么有那么壮大的合作伙伴队伍，因为SAP承诺，一个项目，他赚20%，合作伙伴赚80%

ccwlm741212

这东西，怎么说呢？ 难说，那就别说了