相信较深入了解TOC理论的人，特别是体验过TOC生产模拟游戏的人，都会惊讶于采用简单的方法竟然可以获得如此神奇的改善。但是在有些TOC实施项目并不如人意，有些甚至以失败告终。是理论和实际的差距？是理论的适用性？还是实施的方法？笔者参考众多的TOC案例，结合自己参与的几个TOC项目，对TOC的实施提出几点自己的意见。

1．项目的管理。一个企业的TOC的实施是“为完成某一独特产品、服务或任务所作的一次性努力”（项目定义，PMI，2004），涉及项目管理的初时、计划、实施、控制、结束过程，需要对整体、范围、时间、费用、质量、人力资源、沟通、风险等进行全面管理。但是很少的TOC实施能用项目管理的方式，甚至一份像样的计划都没有，更别论如何进行质量控制、风险评估。有些TOC实施的领导者在领导能力、冲突处理能力、团队建设能力、解决问题能力等项目经理能力要求方面存在缺陷，也直接的影响了项目实施的效果。

“20%项目失败的原因来自于技术能力的缺陷，而另外80%来自于对项目运作的管理和控制出了问题”。

2．Buying. TOC方法在很多方面对传统的管理理念是颠覆性的改变。要改变一个人的习惯是困难的，更何况于要改变一个人的思维，而TOC的实施更需要改变一个企业绝大部分成员的思维！！推行这看似简单的方法，需要强大的执行力，强大的执行力，来自管理层对理论完全接受和掌握。有些TOC项目，公司的某个高层参与了培训，认识到TOC的力量，认为这是个简单的改进，试图自己推行组织变革。他们忽略了对中层管理的TOC培训。结果，在推行中困难重重，更重要的是在制定方案时，就由只参加几天培训的管理人员领导一群没有理解TOC的中层领导制定，我们可以想象制定的方案离真正的TOC要求差距。

国内的某个企业在实施TOC时，老板认同TOC，顾问对管理层也进行了较好的buying，刚开始推行尚顺利，也取得一定的成效。但是某个关键职位发生人事变动，新来的主管认为他的原来经验非常有效，对TOC的方法阳奉阴违，而此时顾问没有很好对这位主管和其他新来的人进行有效的buying，这些人的工作破坏了TOC系统的整体性。TOC的成功实施也是奢谈了。

3．TOC系统实施的整体性。很多TOC实施项目，包括顾问协助的项目，为了简化实施，只是采用shipping buffer来控制投料和管理优先顺序。当然，这能收到效果，特别在淡季时，对生产周期和在制品数量的改善相当明显。但是，在旺季时，仅按shipping buffer来控制投料将造成生产负荷过大，从而对生产周期、在制品数量和准时交货率的表现急剧变差。实质上，他们已经背离的TOC，因为这些项目都抛开了TOC强调的“制约资源”来思考问题。

在Eli Schragenheim的《在快速反应项目中使用SDBR》（Using SDBR in Rapid Response Projects）的文中已经很好论述了如何结合shipping buffer和CCR的负荷来管理生产。而在TOC的模拟生产游戏中，我们已经知道结合CCR的符合来控制投料是多么的重要。

4．分销方案中的目标市场。库存周转率（Inventory Turn）是TOC分销方案定义为企业的竞争性优势。的确，几乎所有渠道商对库存周转率是非常敏感的，依此，某些TOC实施企业企图将所有的客户都纳入TOC分销方案中。但是他们忽视了TOC分销方案中非常重要的“追求错误的潜在客户不仅浪费宝贵的资源(金钱、销售部门的人力和时间)，更会导出〝结论〞，认为方向也是错的。【Pursuing wrong prospects is not just a waste of valuable resources (money, sales capacity, time...) it can lead to the “conclusion” that the direction is invalid.】”（VV project，Consumer Goods S&T， 4.21 Target Market Definition）。而最终，不但没有将客户的库存周转率提高，反而降低，造成客户抱怨，停止合作。

5．IT支持。任何理论和方法，都只存在人脑和纸面上的，如果没有软件来固化实施的话，将是难以操作、不可控、不可靠、难以持久和改善的。大部分TOC实施都认识到工具的重要性，但在应用方面存在一些问题：

针对没有ERP或其他生产IT系统的企业，依靠EXCEL来记录生产单的状态。由于Excel文件的独占性、非流程化修改，造成了在传递过程中版本错乱，错误修改数据，非共享方式阻碍团队协作，数据安全控制，操作不便利，统计分析不灵活。

有些有ERP，也有专业的TOC软件，那么TOC软件所需的数据由ERP来。而由于ERP本身实施是失败的，数据的可靠性无从谈起。可以想象，TOC软件的吃进来的是垃圾，吐出来的也只能是垃圾。当顾问认识到这点，企图通过在ERP中只管控TOC关注的几个点的数据收集，也就是说：如果一个流程是A->B->…-> Y->Z，强制他们在ERP中录入A/B/和Z信息，其他不管。那么，Z面对前面C到Y的数据缺失，它有足够的动力和信息来完成Z的填写吗？知道后续工序需要自己另外方式提供信息，自己在ERP录入的信息不被后续工序认同，A/B的数据录入有可能认真吗？ 最后还是导致数据的继续错乱。

以上都导致的提供分析决策的数据混乱。基础数据都错了，决策也就错乱，如是形成恶性循环：数据错->决策错->消极录入数据->数据更错->…

有些企业在实施过程中应用FTFSYS或Symphony来较好的协助解决以上问题。但极个别企业跟上述形成鲜明对比：过分崇拜IT，企图让IT在TOC实施过程中解决一切问题。如是将很多的时间放在IT的改善上，成了本末倒置。

TOC理论在生产运作的改善上是显著的，但具体到某个企业的实施效果，对实施项目小组提出了很高的要求。