市场调查一下：想开发一个独立的MRP运算模块

tony_trh_cu

我觉得，ERP/MIS系统模块化是一个大趋势，因为现在的软件公司从头到尾开发一个完整的ERP/MIS系统，其实是非常有问题的。

不论是从技术、还是资金成本、还是行业经验，都存在欠缺。

除了少数几个大软件公司可以这么做，绝大部分中小软件公司或者企业自己去开发一个大而全、小而全的企业管理系统，我认为是不明智的。

模块化，对软件公司和企业用户本身都有好处，软件公司可以减低成本，形成产业链，只做自己擅长的事情，企业用户如果觉得该系统中的某个模块不适合，可以更换其中模块，而不必更换整个系统，减少了投资和风险。

所以，这就是我觉得，有必要开发独立的MRP运算系统的思路。当然也可以开发独立的成本核算系统den等等。这样使这些模块可以做到通用化，而不仅仅只成为某个系统的专用子模块。

tony_trh_cu

MRP运算模块，相当于电脑的“CPU”,
是ERP/MIS系统中的核心部件，很多中小型企业，一般也就1-2个ERP管理或者开发人员，
研发力量有限，如果他们自己去全套开发这些系统，一是工程量大，时间周期长，问题多，
如果有现成的成熟的模块，集成到现存系统，我认为是最好的方案。

w39

tony_trh_cu 发表于 2014-12-27 08:33
我觉得，ERP/MIS系统模块化是一个大趋势，因为现在的软件公司从头到尾开发一个完整的ERP/MIS系统，其实是非 ...

为什么要自己研发？
金碟、用友、天心这样几万，乃至几十万的系统哪个不提供MRP模块？

w39

楼主的市场定位有问题

单纯的进销存软件现在已经极少了吧？包括速达都有MRP模块了

单纯购买进销存产品，价格也极其低廉，基本上几千块都能搞定。

tony_trh_cu

购买的ERP系统，很多方面，不适合实际公司需要，这就是ERP实施失败率非常高的原因。

所以很多公司希望自己能研发，但自己研发，确实时间周期比较长，如果要成熟、稳定，时间更长，

但如果有组件模块，能与自己的系统无缝集成，那么，就可以破解这一大难题，

aknightchen

我也认为,楼主的市场定位有问题.

你开发个通用的MRP,给别人做接口,是没有任何意义的.

如果你熟悉MRP这一块, 我建议你有两条路:

1>.要么自已开发出一个"进销存+生产+BOM+MRP+..."的系统.(很辛苦,需要很漫长的过程,也需要家庭的大力支持,包括经济上的支持)

2>.要么你进一家不错的软件公司中打工. 通过帮助软件公司改进MRP算法, 以便在公司中立足. 然后稳定工作.

tony_trh_cu

看来，没有人看好这个项目，

如果开发大而全、小而全的系统，一是没精力，二是没有这个能力，三是没有这个财力。

能做好某个链条上的一个环节，就是相当不错了。

准备先做一个简单实用的MRP运算系统，并且免费开源，

等有市场和用户了，再考虑商业方案。

takeliou

不看好市场面：

* UniDAC是死路，除非客户愿意花三天三夜跑MRP。「专业」的MRP一定用stored procedure。
* 拼装车无论怎样组装、用甚么高贵的零件，在路上随时会解体。

能人很多，但是都是落单的蚂蚁。如果可能，请考虑合作，一起面对国内外巨鳄。
参考资料

tony_trh_cu

1)MRP运算时候，肯定是在存储过程里跑的，只是数据同步时候，需要用这些数据访问组件，把变化的数据同步到MRP运算模块的专用DB里去。

2)怎么可能要三天三夜呢？写成中间层，跟ERP/进销存数据库在同一台主机上，效率跟存储过程也不会有啥差异的。

takeliou

tony_trh_cu 发表于 2015-1-2 14:25
1)MRP运算时候，肯定是在存储过程里跑的，只是数据同步时候，需要用这些数据访问组件，把变化的数据同步到M ...

技术问题：
能把「具特色的MRP独立模块」套用在3种无MRP的资料处理软件，必须深入了解这3种资料处理软件。谁有这么长的生命去做？SAP R/3也只为Oracle、MS SQL server、DB2...三、四家数据库写stored procedure。千人公司的技术能力仅止於此，1人公司呢？

逻辑问题：
(a)有哪一套值得你去挂上「具特色的MRP独立模块」的资料处理软件，却没有MRP？
(b)成不了气候且无MRP的资料处理软件，值得你去深入研究其架构？

市场问题：
(a)你千辛万苦拜访一个不开心的资料处理软件用户10次，相谈甚欢。在签单的前一日，客户打一通电话给原厂，取得「优惠」升级到有MRP模块的新版，回覆你：「不必再劳烦你了！谢谢！」
(b)你的模块永远寄生在别家不良的产品之上，发展空间狭小到接近零。