BOM的基礎是一個靜態的物料構成表，目的是把產成品分解成為多個原材料。但是這種‘分解’是一種靜態的分解，不考慮動態的生產過程。因此，只有在生產工藝中的物料構成發生變化的情況下，BOM才能作出相應的改變。其他的變化，比如工序時間、工序順序的變化都無法反應到BOM中。因此BOM不能完全響應企業的生產過程和生產方式的變化，無法根據生產過程的變化而進行一對一的相應調整。實際上很多生產過程的改變都是直接在生產地點手工完成的，與ERP無關。

如果企業的生產方式的改變涉及到物料結構的變化，那么BOM是不是就一定能作出相應的反應呢？答案是否定的。因為BOM不僅是一種靜態數據，而且其算法和針對的生產模式都是固定的。一般一種BOM只能解決一種固定類型的生產模式——物料結構的變化不能超越這種模式，否則還是無法對變化作出反應。根本原因也是由于它的靜態數據的本質引起，因為BOM方法的理論基礎就是把不同種類的動態的生產過程固化為不同的靜態的狀況，分別予以解決。

典型案例：

上海某制藥企業，90％的生產過程都是一個工藝流程產生一個產成品，但是10％的工藝是產生多個產品。主要集中在中藥的提取和加工上。其中一種中藥材在加工過程中，產生的部分原漿經過提純和裝瓶，直接做成液體藥劑出售；剩下的原漿經過濃縮和添加其他藥物，制成藥丸出售。這兩種藥物的最終比例可能會隨著計劃的不同而隨時發生變化。這樣的生產流程首先要求BOM能滿足一個工藝流程有多個產成品，其次要求BOM的物料構成數量按照要求隨時發生變化。

在項目的實際實施過程中，這個要求是在生產實施進行了一半才提出來的，軟件廠商事先并不了解用戶有這種要求，因此沒有做準備，也沒有簽協議，出了事情以后，先是答應開發完成，后來反復拖延，直到最后，軟件廠商明確表示放棄開發，沒有回款的部分也不了了之。

這個例子還可以換一種說法：假如用戶原來只有一個產品的工藝流程要求進行改進，變成有多個副產品和協產品，軟件同樣無法滿足變化。這個案例的本質在于，用戶總是傾向于要求自己來設定自己的生產模式，希望軟件隨時按照這種設定的模式執行。但是對軟件廠商來說，BOM是一種靜態模型，算法已經固定在其中，數據可以改變，已經固定了的算法很難再進行調整變化。滿足用戶的要求意味著徹底的改變算法和重新開發生產模塊，而用處十分有限，這對單獨的項目來說是不合算的。

實際上，幾乎所有的BOM都是把生產過程固化成一些標準模式，比如合成型、分解型、流程型、離散型，或者干脆單獨某種行業的生產模式。ERP廠商也按照這些模式來確定自己所屬的市場范圍，其產品只能針對某幾種生產類型的企業滿足它的生產要求。用戶的生產過程也就被限制在BOM已經固定的模式上。對現在大多數ERP軟件來說，都不能以單獨產品單獨滿足所有要求。而重新開發滿足新的BOM模式是一件很復雜的工作。在這個例子中，實際上軟件商提供的是一種‘合成－流程型’的生產模型，可以滿足用戶90％的生產要求，但是10％的流程中出了多個產成品，就變成了‘分解－流程’型的模型。相當于要開發一種全新版本的生產模塊，供應商當然無法滿足這個要求。

隨著管理的進一步發展以及SCM的出現，越來越多的企業要求把生產過程與很多其他工作流程比如采購、銷售、運輸、質檢，甚至是其他企業的生產流程相連接。因此企業生產管理出現了向多種模式發展的趨勢，要求軟件能同時解決多種生產模式，打破BOM對單一生產模式的限制。用戶自己設定生產模式，軟件自動滿足這種變化的要求已經成為下一步ERP升級的必然方向。但是沒有基礎理論突破性的進展，現有的BOM方法根本不可能完成這個任務。