弄巧成拙的DevWare Corp.

许多公司的管理层会花费很多精力在「快速解决」问题。举例来说：

如果销售状况不如预期，那么我们就想办法刺激消费者购买；
如果产量过低，那么我们就让负责部门想方设法改善生产表现；
如果获利表现不佳，我们就试着压低成本。

我们也许对于自己当机立断、快速改善现状而感到沾沾自喜，然而，在许多案例中，问题很快会再次出现，甚至变得更糟，这让我们不禁有种「被自己的解方从背后捅了一刀」的错觉，问题的原因为何？是哪边出错了呢？

让我们先来看看DevWare Corp.，一个硬体开发公司的案例。

DevWare面临一个再常见不过的情况：管理层出于好意的行动，竟然产生了和预期完全相反的结果。

有天，产品开发专案经理 Toby 发现落后进度的产品数量异常的高，他清楚若此情况继续下去，那么团队将无法准时推出新的产品。Toby 认为之所以会有这样的情况产生，是因为工程师缺乏严格的监督，同时必须在各阶段进行评估来获取资讯，以便了解哪部分的生产进度落后。

想当然尔，当 Toby 特别关注该问题时，落后的部分就会迅速补上进度，然而过了一阵子，问题又会再次发生，当 Toby 再次处理这个问题时，问题也同样会被解决，不过不会像第一次的效果一样快速，随着 Toby 越关注此问题，问题反而变得越来越糟，是哪个环节出错了呢？

Toby 透过「要求更多的评估会议」来确认产品现况以期解决问题（详见图(1).(2)「评估会议的问题」），然而这些会议都剥夺了工程师真正能拿来开发产品的时间，因此，与其在问题一发生时就向上呈报问题，不如内部先自行想出解方，这代表其他工程师会比原先还要晚才能知道何改变影响了他们负责的产品阶段（详见图(1)「R回圈」），而当越来越多的工程师延后资讯揭露的时间，就会有越来越多的产品落后进度 - 此情况强化了Toby认为他需要「帮助」工程师的假设，Toby和工程师都无意间造成了他们都不乐见的结果 - 进度落后的情况持续的恶化。

在因果关系图中，划出所有行动可能有意造成或无意引发的结果，能帮助我们在问题发生前先预测或处理该问题。

在此情况中，对Toby来说的高槓杆解和他原先实行的「评估会议」非常不同。举例来说，若Toby鼓励工程师们即时回报问题，并答应不会用更多的会议来「惩罚」他们，工程师们想必十分乐意更即时的回报问题。如此，落后进度的数量将大幅减少。（不过，此结果的前提是恶化的问题已经发生。这种「先恶化才改善」的情况，是一个复杂系统的经典例子，再次强调，「延迟」是其中的元凶。）

如同你在此案例所见，所有事情都环环相扣、紧密连结。不论我们将一个系统范围定义的多小，该系统彷彿忽略我们的假设般，和所有相关的变量都有所连结。因此，除了我们有意造成的结果外，我们的行动也会引发很多原本无意的结果。诚然，此问题和我们的行为是否会带来无意的结果无关，重点在于它会带来什么样的结果、对系统的影响程度有多大，在因果关系图中，划出所有行动可能有意造成或无意引发的结果，将能帮助我们在问题发生前先预测或处理该问题。

Source: Introduction to Systems Thinking - The Systems Thinker

想多了解系统思考？

Omplexity顾问团队因应远距挑战，设计出Live 线上视讯班的课程，透过视讯平台Zoom、系统图软体Kumu 与协同数位教学工具Miro，采取永续无纸化的方式，大幅提升训练课程、脑力激盪乃至策略讨论的效率！你将透过分组专案式学习，实际体验这些方法、学习背后的理论、以团体操作练习同时获得个别的意见回馈。