در فصل‌های قبل یاد گرفتیم سیستم چیست، Feedback چگونه کار می‌کند و سیستم‌های خوب چه ویژگی‌هایی دارند. این فصل یک قدم مهم‌تر می‌رود و توضیح می‌دهد چرا با وجود اینکه فکر می‌کنیم یک سیستم را می‌شناسیم، باز هم نتیجه‌ی اقداماتمان اغلب غیرمنتظره می‌شود.
پیام اصلی فصل: ما معمولاً سیستم‌ها را به شکل خطی و ساده می‌بینیم، در حالی که رفتار واقعی آن‌ها از روابط، حلقه‌های بازخورد، تأخیرها و ساختارهای پیچیده به وجود می‌آید.**
ذهن انسان دوست دارد روابط را این‌گونه تصور کند:
A → B → C
مثلاً:
مالیات را کم می‌کنیم → مردم پول بیشتری دارند → اقتصاد بهتر می‌شود.
یا:
قیمت را پایین می‌آوریم → مردم بیشتر خرید می‌کنند → فروش بیشتر می‌شود.
اما سیستم‌ها معمولاً این‌قدر ساده نیستند.
در یک سیستم:
A روی B اثر می‌گذارد، B روی C، C دوباره روی A و...
یعنی:
A → B → C ↑ ↓ └───────┘
همین حلقه‌ها می‌توانند نتایج کاملاً متفاوتی ایجاد کنند.
یکی از اشتباهات بزرگ ما این است که فکر می‌کنیم علت باید نزدیک به معلول باشد.
مثلاً اگر امروز:
قیمت بنزین افزایش پیدا کرد
ممکن است بلافاصله بگوییم:
«پس مردم کمتر رانندگی می‌کنند.»
اما شاید اثر واقعی افزایش قیمت، بعد از ماه‌ها یا سال‌ها ظاهر شود:
افزایش قیمت
→ مردم خودروهای کم‌مصرف‌تر می‌خرند
→ ترکیب خودروها تغییر می‌کند
→ مصرف سوخت تغییر می‌کند
بنابراین:
بین علت و نتیجه ممکن است فاصله‌ی زمانی زیادی وجود داشته باشد.
این همان Delay است که در فصل ۲ دیدیم.
این یکی از مفاهیم اصلی فصل است.
در یک رابطه خطی، مثلاً:
دو برابر ورودی → دو برابر خروجی
اما در سیستم‌های پیچیده، چنین چیزی تضمین‌شده نیست.
ممکن است:
دو برابر فشار → ده برابر نتیجه
یا:
ده برابر تلاش → تقریباً هیچ نتیجه‌ای
باشد.
فرض کن یک دریاچه مقدار محدودی آلودگی را می‌تواند جذب کند.
تا یک نقطه:
آلودگی بیشتر → تغییر کمی در اکوسیستم
اما بعد از عبور از یک آستانه:
آلودگی کمی بیشتر → فروپاشی شدید اکوسیستم
یعنی رابطه خطی نیست.
سیستم‌ها گاهی تا مدت‌ها ظاهراً خوب کار می‌کنند، اما وقتی از یک آستانه عبور کنند، رفتارشان ناگهان تغییر می‌کند.
مثلاً:
وضعیت سیستم خوب ────────────────┐ │ ↓ Threshold │ ↓ بد ────────────────┘
این موضوع در:
محیط زیست
اقتصاد
جمعیت
سلامت اکوسیستم‌ها
بازارها
سازمان‌ها
بسیار مهم است.
ممکن است سیستم مدت زیادی مقاوم به نظر برسد، ولی در واقع به یک نقطه بحرانی نزدیک شده باشد.
ما اغلب روی چیزی تمرکز می‌کنیم که بیشتر در دسترس است.
مثلاً می‌گوییم:
«اگر سرمایه بیشتری داشته باشیم، تولید را افزایش می‌دهیم.»
اما شاید مشکل اصلی سرمایه نباشد.
ممکن است محدودیت واقعی:
نیروی انسانی
مواد اولیه
انرژی
ظرفیت کارخانه
بازار
آب
زمان
باشد.
این یعنی:
رشد معمولاً توسط محدودکننده‌ترین عامل تعیین می‌شود.
مثلاً اگر یک کارخانه ۱۰۰ میلیون دلار سرمایه داشته باشد ولی آب کافی نداشته باشد، اضافه کردن پول الزاماً تولید را افزایش نمی‌دهد.
فرض کن یک سیستم برای رشد به سه چیز نیاز دارد:
سرمایه + نیروی انسانی + مواد اولیه
اگر:
سرمایه = زیاد
نیروی انسانی = زیاد
مواد اولیه = کم
باشد،
مواد اولیه تبدیل به Limiting Factor می‌شود.
پس افزایش سرمایه و نیروی انسانی ممکن است تقریباً هیچ اثری نداشته باشد.
این یکی از دلایلی است که:
بهینه‌سازی یک قسمت از سیستم الزاماً عملکرد کل سیستم را بهتر نمی‌کند.
این ایده در کتاب خیلی مهم است.
فرض کن در یک بیمارستان، هدف بخش اورژانس این باشد:
«هر بیمار را در سریع‌ترین زمان ممکن از اورژانس خارج کنیم.»
اگر این هدف را بیش از حد دنبال کنیم، ممکن است:
بیماران سریع‌تر ترخیص شوند،
اما بخش‌های دیگر بیمارستان تحت فشار قرار بگیرند،
تشخیص ناقص شود،
بیماران دوباره برگردند.
در نتیجه:
عملکرد یک بخش ↑
اما:
عملکرد کل سیستم ↓
مدوز به این نوع نگاه هشدار می‌دهد.
Suboptimization یعنی یک جزء را بهینه کنیم و کل سیستم را بدتر کنیم.
یک سیستم واقعی معمولاً فقط یک هدف ندارد.
مثلاً یک شرکت ممکن است هم‌زمان بخواهد:
سود را افزایش دهد،
کیفیت را حفظ کند،
هزینه را کاهش دهد،
کارکنان را نگه دارد،
مشتری را راضی نگه دارد،
رشد کند.
این اهداف گاهی با هم تعارض دارند.
اگر فقط یکی را بهینه کنیم، ممکن است دیگری آسیب ببیند.
پس:
نباید یک شاخص را با کل عملکرد سیستم اشتباه بگیریم.
یکی از نکات ظریف فصل این است که ما معمولاً چیزی را که قابل اندازه‌گیری است با چیزی که واقعاً مهم است اشتباه می‌گیریم.
مثلاً در آموزش:
نمره امتحان ↑
ممکن است نتیجه بگیریم:
«یادگیری بهتر شده.»
اما شاید دانش‌آموز فقط برای امتحان حفظ کرده باشد.
پس:
Indicator ≠ Reality
شاخص فقط یک نماینده از واقعیت است.
اگر بیش از حد روی شاخص تمرکز کنیم، ممکن است افراد یاد بگیرند شاخص را بهینه کنند، نه خود سیستم را.
یکی از ایده‌های مهم این بخش این است:
وقتی یک شاخص تبدیل به هدف شود، دیگر لزوماً شاخص خوبی باقی نمی‌ماند.
مثلاً اگر به معلمان بگوییم:
«موفقیت مدرسه بر اساس نمره آزمون است.»
ممکن است سیستم به سمت:
آموزش برای امتحان
حرکت کند.
نمره بالا می‌رود، اما لزوماً یادگیری واقعی بالا نرفته است.
این یک نمونه از:
است؛ یعنی انگیزه‌ای که ظاهراً برای بهبود سیستم طراحی شده، اما رفتارهایی ایجاد می‌کند که در نهایت سیستم را خراب می‌کنند.
این جمله را خیلی خوب به خاطر بسپار:
Good intentions do not guarantee good outcomes.
ممکن است سیاست‌گذار واقعاً بخواهد یک مشکل را حل کند.
اما اگر ساختار سیستم را درست نفهمیده باشد، مداخله او می‌تواند نتیجه معکوس بدهد.
مثلاً:
هدف: کاهش ترافیک
راه‌حل: ساختن بزرگراه جدید
ابتدا:
ترافیک ↓
اما بعد:
بزرگراه بهتر
→ رانندگی جذاب‌تر
→ افراد بیشتری خودرو استفاده می‌کنند
→ سفرهای بیشتری شکل می‌گیرد
→ ترافیک دوباره ↑
این همان چیزی است که Systems Thinking می‌خواهد به ما نشان دهد:
سیستم می‌تواند به مداخله‌ی ما پاسخ دهد و خودش را دوباره تنظیم کند.
این مفهوم خیلی مهم است.
گاهی افراد مختلف در یک سیستم، هرکدام سعی می‌کنند سیستم را در جهت مطلوب خودشان تغییر دهند.
اما سیستم از طریق Feedbackها در برابر این تغییر مقاومت می‌کند.
مثلاً:
دولت می‌خواهد قیمت مسکن را پایین بیاورد.
→ سیاستی برای افزایش عرضه ایجاد می‌کند.
اما:
عرضه ↑
→ تقاضا از مناطق دیگر وارد می‌شود
→ قیمت زمین ↑
→ هزینه ساخت ↑
→ اثر سیاست کمتر می‌شود.
یعنی سیستم در برابر مداخله مقاومت می‌کند.
مدوز می‌گوید این مقاومت لزوماً به معنای «بد بودن افراد» نیست؛ اغلب ساختار خود سیستم باعث آن است.
مدوز چند دلیل اصلی را کنار هم قرار می‌دهد:
حلقه‌های بازخورد
تأخیرها
روابط غیرخطی
Limits
Multiple goals
Hierarchy
توانایی سیستم برای سازگار شدن
همه این‌ها باعث می‌شوند:
مداخله ساده → نتیجه پیچیده
مدوز می‌گوید یک اشتباه مهم این است که فقط اتفاقات منفرد را ببینیم.
مثلاً:
«امسال قیمت‌ها افزایش پیدا کرد.»
این یک Event است.
اما Systems Thinking می‌پرسد:
«چرا طی ۱۰ سال گذشته قیمت‌ها مرتباً افزایش یافته‌اند؟»
اینجا به Pattern می‌رسیم.
و سپس سؤال مهم‌تر:
«چه ساختاری باعث ایجاد این الگو شده است؟»
اینجا به System Structure می‌رسیم.
پس سه سطح داریم:
Event ↓ Pattern ↓ System Structure
و هرچه پایین‌تر برویم، به علت‌های بنیادی‌تر نزدیک می‌شویم.
فرض کن فروش یک شرکت کاهش پیدا کرده.
فروش این ماه کم شده.
فروش طی دو سال مرتباً در حال کاهش است.
محصول قدیمی شده،
تحقیق و توسعه کم شده،
مشتریان اطلاعات کافی ندارند،
پاداش مدیران کوتاه‌مدت است،
سرمایه‌گذاری بلندمدت کاهش یافته.
حالا می‌توانیم مشکل واقعی را ببینیم.
اگر فقط Event را ببینیم، ممکن است بگوییم:
«تخفیف بدهیم!»
اما اگر Structure را ببینیم، شاید بفهمیم:
سیستم نوآوری شرکت خراب شده است.
مدوز تأکید می‌کند:
برای فهمیدن رفتار یک سیستم، به ساختارش نگاه کن.
اگر یک سیستم دائماً رفتار خاصی را تکرار می‌کند، احتمال زیادی وجود دارد که مشکل در:
ساختار Feedbackها
باشد، نه در یک اتفاق منفرد یا یک فرد خاص.
به همین دلیل، تغییر افراد بدون تغییر ساختار ممکن است مشکل را حل نکند.
چون ما معمولاً:
مدل ذهنی ساده‌ای از سیستم داریم.
مثلاً:
«اگر X را زیاد کنیم، Y هم زیاد می‌شود.»
اما سیستم واقعی ممکن است:
X ↑ → Y ↑ → Z ↓ → Feedback → X ↓
باشد.
بنابراین پیش‌بینی ما اشتباه می‌شود.
مدوز می‌گوید به جای اینکه بیش از حد به پیش‌بینی دقیق آینده اعتماد کنیم، بهتر است:
سناریوهای مختلف و رفتار احتمالی سیستم را بررسی کنیم.
یعنی به جای:
«سال آینده دقیقاً چه اتفاقی می‌افتد؟»
بپرسیم:
«اگر این روند ادامه پیدا کند، چه رفتارهایی ممکن است ظاهر شوند؟»
این قسمت بسیار مهم است.
سیستم‌ها فقط پیچیده نیستند؛ ذهن ما هم سیستم را ساده‌سازی می‌کند.
ما معمولاً:
چیزهای نزدیک را مهم‌تر می‌بینیم،
تأخیرها را نادیده می‌گیریم،
روابط غیرخطی را خطی فرض می‌کنیم،
دنبال یک علت واحد می‌گردیم،
به رویدادها بیشتر از الگوها توجه می‌کنیم.
بنابراین یکی از موانع اصلی Systems Thinking:
خودِ مدل ذهنی ماست.
WHY SYSTEMS SURPRISE US │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ Feedback Delays Nonlinearity │ │ │ ↓ ↓ ↓ Unexpected Oscillation Thresholds behavior │ ↓ Policy Resistance │ ↓ Suboptimization │ ↓ Wrong intervention │ ↓ Unintended consequences
اگر فقط ۱۲ نکته بخواهی:
سیستم‌ها معمولاً خطی نیستند.
علت و معلول می‌تواند فاصله زمانی زیادی داشته باشد.
Delay می‌تواند باعث نوسان و نتایج غیرمنتظره شود.
سیستم‌ها ممکن است Threshold داشته باشند.
افزایش یک ورودی لزوماً خروجی را به همان نسبت افزایش نمی‌دهد.
رفتار سیستم اغلب توسط محدودکننده‌ترین عامل تعیین می‌شود.
بهینه‌سازی یک جزء می‌تواند کل سیستم را بدتر کند.
شاخص قابل‌اندازه‌گیری همیشه معادل واقعیت نیست.
تبدیل یک شاخص به هدف می‌تواند رفتارهای مخرب ایجاد کند.
سیستم‌ها می‌توانند در برابر سیاست‌ها Policy Resistance نشان دهند.
برای فهم مشکل باید از Event → Pattern → Structure حرکت کنیم.
مهم‌ترین علت غافلگیری ما، نادیده گرفتن Feedback، Delay، Nonlinearity و Structure است.
اگر بخواهیم چهار فصل اول را به هم وصل کنیم:
فصل ۱:
سیستم چیست؟
↓
فصل ۲:
سیستم‌ها چگونه با Feedback رفتار می‌کنند؟
↓
فصل ۳:
چه چیزی باعث می‌شود سیستم‌ها تاب‌آور و سازگار باشند؟
↓
فصل ۴:
پس چرا با وجود همه این‌ها، سیستم‌ها ما را غافلگیر می‌کنند؟
و پاسخ مدوز تقریباً این است:
چون ما معمولاً به رویدادهای قابل مشاهده نگاه می‌کنیم، در حالی که رفتار سیستم توسط ساختارهای عمیق‌تر، حلقه‌های بازخورد، تأخیرها، محدودیت‌ها و روابط غیرخطی ایجاد می‌شود.
Event → Pattern → Structure → Feedback → Behavior
