车企中有很多BOM问题是由BOM的技术架构决定的，与BOM架构相关的问题中，有三个较为突出的：
一、数据冗余问题
数据冗余带来的问题非常明显：同一份数据在产品上被重复定义，必然带来产品数据不一致性，不一致性带来的问题是变更管理的问题。当同样的数据被定义在两处甚至多处，发生设计变更时，必然要考虑如何同步的问题。另外，数据冗余也会造成不必要的工作量增加，数据维护困难。
很多企业至少在研发端的BOM都按照超级BOM模式进行组织，这是否解决了数据冗余问题呢？答案是否定的。超级BOM在一定程度上确实缓解了这一问题，但超级BOM本身也存在一个如何搭建的问题。如果超级BOM本身的架构不合理，则这一问题还是显得非常突出。
二、不同形态BOM之间的转换问题
不同形态BOM之间的转换问题，尤以工程BOM到制造BOM的转换为典型，是制造业的一个长期存在的难题。
大部分传统车企，工程BOM的搭建只是从设计的角度出发，导致结构层级与CAD结构比较接近，而对BOM应用部门的要求考虑得比较少。这样做的后果有两种情形：一种是制造BOM干脆另起炉灶，由下游的制造或者生产物流专门组织人员基于研发、采购和工艺等部门提供的文件重新搭建一套制造BOM；另一种情形是直接将工程BOM上的设计虚拟层级带到制造端，使得制造BOM效率极低，应用受到诸多限制。这两种情形的根本原因是，很难实现由基于设计角度出发而定义的工程BOM向面对生产的制造BOM转换，特别是发生工程变更的情况下，二者之间的同步将变得极为困难。
三、配置信息的传递问题
配置信息的传递问题在当前企业中也是比较突出。国内很多车企配置化信息实际上没有被充分利用，基本都停留在配置表作为记录产品信息以供下游参考的表单，研发端的BOM虽然以超级BOM方式组织，但真正利用配置信息进行BOM解析的很少，到制造端就更难了。
从数据组织方式来看，研发端的BOM往往会基于设计的需要定义一些中间层级。配置化信息往往作用在这些层级，而这些层级无论是制造、试制、售后甚至研发端的成本分析、重量管理都可能不需要。这样问题就产生了，当BOM向其他领域传递时，这些配置信息就“丢失”了，需要各个业务领域重新梳理配置关系，这就导致了各个业务领域所需的BOM事实上完全独立，不能贯通。因此，这个问题不解决，将会直接导致上面讲到的第二个问题。
以上三个问题要从根本上解决，必须从BOM如何搭建入手，而不是固守已有的搭建方式不变去找解决方案。