對 APS系統不熟或者不了解他的一些運行規則也是在實施項目中導致經常不能正常運行不可忽視的因素，對 APS系統的早期了解是整個項目實施運行的成功至關重要的因素。
如果不了解 APS潛在的因素和運行準則的話，這個團隊可能會設計一個他預期所不能達到的一個模型，可能已經上線了，才發現這個解決方案並不能夠達到他的效果，所以對系統功能性的了解，認知也就是等於加重轉化商業目標到建模之間的難度，結果許多項目都會浪費了時間又浪費了資源。
通常情況下 APS系統都會分為兩大類：
第一，經過優化的系統。
第二，基於其他式的系統。
優化式系統就是將這個排程問題當成一個數學問題，就像是線性編程以至於達到最優的方案，而這些系統對數字就相當的敏感。
想要到達一個違反規則的解決方案，要是在建模過程中稍有一點馬虎之類的，基於遺傳啟發式的系統呢，而恰恰相反，他可以將所有排程問題做成一系列的小的問題通過不同商業規則將其突破。
這個遺傳啟發式的用在 APS解決方案中通常被當做買方，這些生成的解決方案呢，並不能保證完全保證是最優的，但至少他是可用的，而且他也是完整的也比較容易理解，總體來說比優化式的系統所生成的解決方案要好，如何提升一個人對 APS系統以及準則了解，最關鍵的要去從賣方，實施顧問得到一個培訓，我們通常會把一個客戶的團隊同 APS的實施顧問，會拉到一塊工作在進行二次開發的時候，這個團隊都會在這個 APS解決方案力所能及的範圍之內，設計出更多的信息選擇。
至於第二中系統類型可能就比較讓人失望。
用戶都不用這個設計出來的解決方案，當這個項目組讓這個解決方案實施上線之後，這個項目經常會遇到。
第二個比較尷尬的境地是， APS已經被設置好了，用戶卻會覺得很難去運用，得到他所期望的那種結果，要經過一段進化之後，計劃人員才能夠去找到比較舒適合理的表格但是他們細一看，會將車間管理放棄一些解決方案的整體而就取了其中的一個表格，沒有整個利用起來。
如果項目組都看到第一個方案沒有辦法實施的時候，用戶也會被同樣的狀況所困惑，從整個計劃的模型到數據的質量來看， APS兩個方案的行為都能夠對他們的工作或多或少產生一些困擾。但是項目組都是很倉促，都沒有時間幫他們去培訓去傳輸信息，所以導致 APS性能被一些交期在追逼而不是客戶能接受客戶的成功來節約。
結果這個項目組在 APS上線之後就離開，然後讓客戶自己去摸索，客戶可以憑借這有限的支持，然後進一步自己去探索，有時候還通過其他渠道去了解新的解決方案的一些相關問題，但是那些無疑是杯水車薪。
轉載於:https://www.cnblogs.com/NB-Juvien/p/10784293.html
