[原创]白话TOC之灵活的精灵

kimi

应用TOC，是一个创造性的过程。而任何应用都需要看其成效。

 

如果能够确定系统是什么，系统的OWNER是谁，系统的OWNER已经清楚瓶颈是什么，就可以用TOC来做改善。不必计较是整体改善还是局部改善。

 

另外，TOC的思考是非常深入的。这就给如何把握应用过程带来了很大的风险。事实上，为什么国内，甚至国际上也少有企业级的应用，很大一部分原因就在这里；并不是说TOC本身有多难理解。

 

从应用的角度来说，TOC最精彩的现实树、未来树、消雾法等等的应用是作为TOC案例的判断依据之一。另一个依据就是这个应用的过程如何把握；倒不见得一定要说TP如何实现——尽管这也是很精彩的部分。前者体现了TOC的科学性，后者体现的则是TOC的艺术性、人性。

 

TOC，是在矛盾中前行，不存在完美的答案——只要冲突方能够取得共识，并针对共识开展相应工作就可以了。这一点很受学院派的“科学”攻击和实战派的“文化”攻击。

 

这给TOC应用增加了阻力。尽管TOC方面的专家也正用TOC本身来解决这个问题；但所获甚少。

 

对于TOC科学性和艺术性的区分是我个人的一点总结。在交流过程中，也有人同意这样区分。因为灵活并不意味着混乱。

 

与其从理论上要讲究怎么个章法，不如通过实践的例子来说明这一切。因此，理论部分到此结束。

 

在没有得到大家的反馈之前，我想就碰到的具体实例先作一番演绎。也算是让灵活的精灵拉出来溜溜。在这里我可以告诉您的是：在本书的前面，已经完成了处女秀——您不妨翻回去找找。

 

该贴来自群组：TOC约束理论

Yorky

“如果能够确定系统是什么，系统的OWNER是谁，系统的OWNER已经清楚瓶颈是什么，就可以用TOC来做改善。不必计较是整体改善还是局部改善。”

kimi兄，理解你的这个观点是要有深度的才行。我个人也来尝试一下，看看是否占点皮毛？

我的理解是：通过自上而下的系统思考，来确定要分析的对象是什么样的系统，或什么样的流程。其实就是将要改善的对象进行点、线、面、块的分解，进而有针对性的各个突破。正是沿着系统的目标自上而下的顺序,此时制订的局部流程的改善行动就能满足整体流程的目标需要。所以不需要再强调整体改善还是局部改善了，也没有实际的指导意义。

还望kimi兄指正。

kimi

在实践工作中，总是有人拿这个“全局、整体”等借口阻碍瓶颈的发现、干扰注入的涌现、阻挠行动计划的制定。为此，需要一个统一的标准能够判断清楚所谓的“全局、整体”是否确实存在。

Yorky 兄，你提到的分解和顺序，表面上是为了降低复杂程度，其实是很危险的。事实上，我们都有很强的抽象能力，可以在更高一个层次上将系统进行抽象。

TOC，是在提出问题的时候就在解决问题了；而提出问题的时候必须是针对问题的。在现实中，很容易坠入问题的泥潭；而这是在应用TOC中首先就应该避免的。

ckk17hxy

就个人的实践来讲kimi兄提到的“分解和顺序是危险的”这个观点我非常赞同，目前常有的困惑和疑虑也都来自分解，甚至于对目标管理层层分解这个方式我也很多时候想打个叉。不过说实在的系统抽象问题对于大部分人来说还是有困难的，因为缺乏有效的方法或者说不善于去运用方法，每个人都有自己的思维方式，这与系统抽象强调的逻辑和严谨有时是对立的。

路还很长，要学得还很多，学了之后还要用，然后在用中再去学习！

Yorky

首先感谢kimi兄的解答。

跳出局部与整体的层面，在更高一个层次上将系统进行抽象？？这个提法与TOC的理论观点看起来是一致的。但是在实际的应用会产生矛盾，公司内部的员工并非都能有时间和精力投入其中，每个人的理解能力与消化能力又存在本质上的差别，有点“一刀切”之嫌和脱离实际的感觉，或者说可操作性不强。要求公司内部的上、中、下层都能在一个更高级别的立场、角度来看同一个问题，不容易做到呀。

“把系统进行抽象，就是为了把复杂的问题简单化”的出发点可以理解。多角度的解读和分工执行是不可避免的，“系统的Owner、Drive、Pusher”就是回归和正视现实的做法。

立场与角度，决定了“全局与整体”，也决定了每个人看待问题的衡量指标的分解和先后顺序。“全局、整体”是否确实存在--------整合和统一此问题，关键看是否有实际的指导意义。

kimi

Yorky 兄，你这么说也没有错。事实情况可能比我们这里说的还要复杂。那么，是否就止步于这么复杂的现实面前么？当然不是，这时候系统的OWNER就应该得以明确，并开展瓶颈的确定。在这里切记不是一上来就是上＼中＼下，整体＼局部，这么来分的－－在我眼里，只存在于这个系统是怎么定义的－－这一点也许是Yorky 兄最不能理解我的意思的地方．其实也没有关系：因为我们不能要求别人完全理解我们每个人的意思．只要我们在解决问题的时候能够针对共同关注的，有冲突的地方进行沟通就可以了，不要回避－－这一点，好过了所谓的＂换位思考＂，更好过了＂达成共识＂．另外，这一个提法也与我们常说的＂办事找对人，事半又功倍＂是吻合的．

这里，我也想告诉应用TOC的人，千万不要让自己成为救世主，而要让系统里面的人成为自己的救世主。至于说到抽象的能力问题，我觉得这个是可以借助外部力量的．当然，平常情况完全不至于如此．

Yorky 兄，至于你说的多角度或者说立场什么的，我觉得这个主要是你看你定义的是一个什么样的系统，有没有找到系统的ＯＷＮＥＲ．当然，这个系统的ＯＷＮＥＲ也许本来就是缺位的，这在现实生活中也是比比皆是．

另外，ＴＯＣ不是想象的那样拘谨；不要让自己的思维成为ＴＯＣ的瓶颈就好了．

ckk17hxy

kimi兄的意思是指一开始就是定义一个系统，而不是在系统都没识别的时候就划分整体、局部，或是分层分解么？关于系统OWNER的问题我一直比较困惑，可能是目前的职能式结构大多会使OWNER缺位吧。

kimi

ckk17hxy 友，我想表达的核心是这个意思。但这也并不能否认在实际工作中会先找人，由其定义其所在系统的这种可能性。但无论如何，理论地图中提到的这三个问题必须得到明确，才可能进行下一步的工作；甚至可以这么说，这是现在大家所谓的TOC理论应用的前提条件。而这个，事实上能够解决很大的问题，甚至是很多的问题。 

Yorky 兄提到的可能还有“全员”的意思在里头。我想这个是一个很高的要求，目前国内很多企事业单位都达不到实际开展“全员”方面的具体工作。最多，只是把这个落实到某个职能部门，由这个职能部门去推动——这个是一个很辛苦的过程，充满未知——这也导致该部门的工作本身也很难管好。这是一个典型的冲突，可惜经典TOC应用里面没有看到这样的例子。

至于OWNER缺位问题，我觉得意识到这个就已经是一个很不错的机遇和契机了。最重要的是怎么解决的。这是一个很值得探讨的问题，也是很值得积累经验的地方。 

ckk17hxy

听了kimi兄的观点，我一直在想一个问题，那就是说大部分人（至少我接触的是这样）的习惯倒着来思考问题，即是先埋头找瓶颈，然后反过来定义系统，至于系统OWNER的问题往往是忽略掉，并没有追寻TOC理论地图的步骤，以前我也常常陷入这个问题，过于急功近利，看来实在是有必要静下心来考虑这个常识。