APS(高级排程)可视化开发过程遇到的苦恼

CSDNFucker 2014-07-01 10:18:00

不知道有没有人在做这方面的开发，想找人沟通下。因为这项目就我一个人在进行，状态不佳时，项目停滞不前。
上一个项目模块划分

现在已经有一个UI视图，是显示各工组每天的派工的。现在还要添加一个视图显示车间的甘特图。苦恼，发下牢骚。
更希望有这方面经验的人交流下。

...全文

1942 18 打赏收藏转发到动态举报

写回复

用AI写文章

18 条回复

切换为时间正序

请发表友善的回复…

发表回复

CSDNFucker 2015-12-03

打赏
举报

还坚持在这方面做研究的加Q群：99091465交流

ytq2080 2015-02-13

打赏
举报

我也在隻身一人搞APS: 基於工序執行順序、優先產能約束的生產排程！普通算法都很複雜，基因算法很複雜，搞半天沒搞懂！有懂行的分享下！

duanzhi1984 2015-01-22

打赏
举报

APS这东西只适合那种变化小，定额固定，等受因素少的计划排班。

CSDNFucker 2014-12-25

打赏
举报

引用 11 楼 ahu9870 的回复:

总的感觉吧，数据部分看起来工作做得挺多的，但不知道排程部分研究得怎么样

现在工程做得挺宠大的，我试着归纳一下几个主要的逻辑吧 1.加工顺序限制：根据物料清单的层级关系控制半成品指令单、采购物料、外协物料的需求前后关系。根据半成品的工艺路线控制工组、设备、模具的前后关系。 2.产能限制：通过定义生产日历，及定义工艺的单位工时，可以控制产能分配合理

ajaxfeifei 2014-12-25

打赏
举报

引用 14 楼 CSDNFucker 的回复:

[quote=引用 13 楼 lc2737 的回复:] 排产这玩意，只能说呵呵，噱头，实际能执行的没几家。

下班前上来看看，呵呵确定算法上是要考虑很多实际情况的，现在就有一个正在用我们ERP的客户极力想上，资料也比较完善的，物料清单、工价表、工时表都很完整。希望这能成吧。[/quote] 这种项目我做过比较多了，很多公司都很理想化，想要管得细不是一套软件能搞定的，还是要看业务流程规范及企业执行力。以前做过一个项目，那公司还请了日本人、德国人帮他们规范，做了两年没什么效果。

CSDNFucker 2014-12-25

打赏
举报

引用 13 楼 lc2737 的回复:

排产这玩意，只能说呵呵，噱头，实际能执行的没几家。

下班前上来看看，呵呵确定算法上是要考虑很多实际情况的，现在就有一个正在用我们ERP的客户极力想上，资料也比较完善的，物料清单、工价表、工时表都很完整。希望这能成吧。

ajaxfeifei 2014-12-25

打赏
举报

排产这玩意，只能说呵呵，噱头，实际能执行的没几家。

ahu9870 2014-12-24

打赏
举报

总的感觉吧，数据部分看起来工作做得挺多的，但不知道排程部分研究得怎么样

CSDNFucker 2014-12-23

打赏
举报

好久没上来了，谢谢各位的回复，上几幅图，让大家了解一下我在做什么

以专业开发人员为伍 2014-11-03

打赏
举报

在技术论坛，我想最有意义的事情（和目的）就是跟实际负责任的工程师交流开发设计经验，而主要目的并不是为了贴“知识点”给做作业的学生。

以专业开发人员为伍 2014-11-03

打赏
举报

因为这种问题不是一个学生在上课时的所谓的“知识点”、抄点msdn语句的问题。这不是一个“抄字典”的问题，是一个工程问题。

於黾 2014-11-03

打赏
举报

3个月了,估计楼主都把这个帖子给忘了

S314324153 2014-11-03

打赏
举报

卧槽，7月的贴，10底月才有回复...

以专业开发人员为伍 2014-11-01

打赏
举报

引用楼主 CSDNFucker 的回复:

现在已经有一个UI视图，是显示各工组每天的派工的。现在还要添加一个视图显示车间的甘特图。苦恼，发下牢骚。更希望有这方面经验的人交流下。

你看这个描述，就是设计分析中的大忌。你不过是刚刚知道ige“每天派工”的操作界面，甚至可能你连“到底有多少种工种分别需要派工”都还没有搞清楚，你就把它叫做“UI视图”。如果这个叫做“UI视图”，那么其它的几十个排产工作的主界面是不是UI视图呢？而所有的辅助录入窗口、领导查询监视窗口等等算不算UI视图呢？先弄一个高大上的名词儿，你就不能再认证进行系统分析了。所以在初步分析时，就要把这种名词做为“含混、必须拆分”的名词儿而抛弃。没有经验的人往往需要被“骂”6、7遍才能真正从实际出发去进行设计。

以专业开发人员为伍 2014-11-01

打赏
举报

如果你觉得不能入手，那么就把你这些先扔掉，从两方面入手： 1. 找美工设计配合所有的界面（草稿即可，但是绘图方面一定要有基础的人来绘制）。然后跟用户确认这些基本设计是否是基本准确的、是否是比较完善的，是否是没有含混和刻意逃避的。 2. 把上述内容的描述文档、其中的什么“名词儿、动词儿”进行一边梳理和分析，写一个“词典”。排除那些重复、含混、是属性（而非对象）、需要拆分的部分，以及暂时排除那些“属于扩展子类”的部分，然后初步画出一个对象（类）图来。完成以上内容，比如说需要2个月。之后你再花2个月进行其它的初步设计，就可以开始动手写程序了。

以专业开发人员为伍 2014-11-01

打赏
举报

你把不同层次的东西放在一张模块图上，那就没法进行真正的业务设计了。肯定是整天沉迷于“底层技术”好像很有道理，而一旦遇到高层的业务就怂了。 UI 就是 UI、DB就是DB、BLL就是BLL，其它许多（例如什么Method、什么PB、什么UI冒号）都是重叠和干扰。结果是，我没有在这里看到你在真正研究业务领域，堆砌一些技术名词儿而已。这样搞设计，你当然永远不能落地啦。