对 APS系统不熟或者不了解他的一些运行规则也是在实施项目中导致经常不能正常运行不可忽视的因素，对 APS系统的早期了解是整个项目实施运行的成功至关重要的因素。
如果不了解 APS潜在的因素和运行准则的话，这个团队可能会设计一个他预期所不能达到的一个模型，可能已经上线了，才发现这个解决方案并不能够达到他的效果，所以对系统功能性的了解，认知也就是等于加重转化商业目标到建模之间的难度，结果许多项目都会浪费了时间又浪费了资源。
通常情况下 APS系统都会分为两大类：
第一，经过优化的系统。
第二，基于其他式的系统。
优化式系统就是将这个排程问题当成一个数学问题，就像是线性编程以至于达到最优的方案，而这些系统对数字就相当的敏感。
想要到达一个违反规则的解决方案，要是在建模过程中稍有一点马虎之类的，基于遗传启发式的系统呢，而恰恰相反，他可以将所有排程问题做成一系列的小的问题通过不同商业规则将其突破。
这个遗传启发式的用在 APS解决方案中通常被当做买方，这些生成的解决方案呢，并不能保证完全保证是最优的，但至少他是可用的，而且他也是完整的也比较容易理解，总体来说比优化式的系统所生成的解决方案要好，如何提升一个人对 APS系统以及准则了解，最关键的要去从卖方，实施顾问得到一个培训，我们通常会把一个客户的团队同 APS的实施顾问，会拉到一块工作在进行二次开发的时候，这个团队都会在这个 APS解决方案力所能及的范围之内，设计出更多的信息选择。
至于第二中系统类型可能就比较让人失望。
用户都不用这个设计出来的解决方案，当这个项目组让这个解决方案实施上线之后，这个项目经常会遇到。
第二个比较尴尬的境地是， APS已经被设置好了，用户却会觉得很难去运用，得到他所期望的那种结果，要经过一段进化之后，计划人员才能够去找到比较舒适合理的表格但是他们细一看，会将车间管理放弃一些解决方案的整体而就取了其中的一个表格，没有整个利用起来。
如果项目组都看到第一个方案没有办法实施的时候，用户也会被同样的状况所困惑，从整个计划的模型到数据的质量来看， APS两个方案的行为都能够对他们的工作或多或少产生一些困扰。但是项目组都是很仓促，都没有时间帮他们去培训去传输信息，所以导致 APS性能被一些交期在追逼而不是客户能接受客户的成功来节约。
结果这个项目组在 APS上线之后就离开，然后让客户自己去摸索，客户可以凭借这有限的支持，然后进一步自己去探索，有时候还通过其他渠道去了解新的解决方案的一些相关问题，但是那些无疑是杯水车薪。