منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۳ دقیقه

تفکر سیستمی (Systems Thinking) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

منبع می‌گوید «حلقه‌های بازخورد را شناسایی کنید» — و بعد در پرسش‌وپاسخ، حلقهٔ بازخورد مثبت را «تشویق‌کردن کاربر» و منفی را «هشدار پیش از حذف» تعریف می‌کند.

هیچ‌کدام از این دو، در معنایی که فارستر (که همین صفحه به او ارجاع می‌دهد) به‌کار می‌برد، حلقه نیست.

تعریف

تفکر سیستمی رویکردی است که طراح با آن مسئله را در بافت درستش تحلیل می‌کند. با نگاه‌کردن به فراسوی مسئلهٔ ظاهری و دیدن سامانه به‌عنوان یک کل، می‌توان علت‌های ریشه‌ای را آشکار کرد و از درمان‌کردن صرفِ نشانه‌ها پرهیز کرد.

و نقل‌قول نورمن که منبع می‌آورد: «باید همه‌چیز را به‌عنوان یک سامانه ببینید، و باید مطمئن شوید که به علت‌های ریشه‌ای زیرین می‌رسید.»

ریشه و ضرورتش

منبع نکتهٔ شناختی درستی می‌گوید: مغز ما سیم‌کشی شده تا از اثری که می‌بیند، علتی ساده و مستقیم بسازد. ما مسئله را جدا می‌کنیم و به فکر مقابله با نشانه‌هایش می‌افتیم، چون با رابطهٔ «اگر X پس Y» راحت‌تریم.

و تاریخش: مفهوم تفکر سیستمی در ۱۹۵۶ سر برآورد، وقتی جِی فارستر در دانشکدهٔ اسلون MIT گروه دینامیک سیستم‌ها را ساخت — با این هدف که رفتار سامانه را به‌شکل ترسیمی پیش‌بینی کند، از جمله با نمودار رفتار در زمان و نمودار حلقهٔ علّی.

و نورمن مسائل بزرگ را سامانه‌های اجتماعی‌–‌فنی پیچیده می‌نامد که مثل مسائل شرور: سخت‌تعریف‌شدنی‌اند، سامانه‌های پیچیده‌اند، معلوم نیست از کجا باید سراغشان رفت، و معلوم نیست راه‌حل کار کرده یا نه.

و خطرِ نداشتن این نگاه: ساده‌سازی افراطی، بیرون‌کشیدن مسئله از بافتش، درمان نشانه، و بدتر‌کردن اوضاع. نمونهٔ خوبی هم می‌آورد: خودروی برقی راه‌حلی به‌ظاهر خوب برای آلودگی است — اما اگر برقش از زغال‌سنگ بیاید، هدف را نقض می‌کند و با احتساب تلفات انتقال، ممکن است آلودگی بیشتری بسازد.

چطور به‌کارش ببریم

منبع آن را سومین اصل طراحی انسانیت‌محور می‌داند و چهار گام می‌دهد، با یک نمونهٔ ممتد از آبیاری یک روستا:

• - مردم‌محور باشید. مدتی طولانی میان مردمی که می‌خواهید کمکشان کنید زندگی کنید تا ماهیت واقعی مسئله و منظر آن‌ها و راه‌حل‌هایی که آزموده‌اند را بفهمید.
• - مسئلهٔ درست را حل کنید. عامل‌های محرک را دقیق بررسی کنید؛ روش پنج چرا کمک می‌کند.
• - همه‌چیز را یک سامانه ببینید. با رهبران جامعه مشورت کنید، حلقه‌های بازخورد را بسنجید، و از مسئله‌های ظاهری به علت ریشه‌ای بروید.
• - با گام‌به‌گام‌گرایی جلو بروید. منتظر فرصت یک آزمون کوچک بمانید، و اگر جواب داد ارزیابی و تطبیق و تکرار کنید.

و در آن نمونه، آب کافی است و خاک هم کوددهی شده — و علت ریشه‌ای در جای غیرمنتظره‌ای پیدا می‌شود: آب کمی بیش‌از‌حد گرم است، به‌دلیل لوله‌های پلاستیکی تیره و ورقهٔ مشکی تونل موقت. و راه‌حل، روشن‌کردن رنگ همان سامانه است.

«حلقهٔ بازخورد» در این متن دو معنای ناسازگار دارد

این بخش افزودهٔ مترجم است. در دینامیک سیستم‌ها — یعنی همان سنتی که منبع با نام فارستر به آن ارجاع می‌دهد — این دو اصطلاح معنای دقیقی دارند:

• - حلقهٔ مثبت (تقویت‌کننده): خروجی برمی‌گردد و همان خروجی را بیشتر می‌کند — نتیجه‌اش رشد یا فروپاشی نمایی است. این «تشویق‌کردن» نیست.
• - حلقهٔ منفی (تعادل‌بخش): خروجی برمی‌گردد و انحراف را کم می‌کند — نتیجه‌اش پایدار‌شدن حول یک هدف است. این «هشدار‌دادن» نیست.

و اشکال عملی‌اش این است: منبع مفهوم سیستمی را با معنای روزمرهٔ «بازخورد» در رابط (یعنی خبر‌دادن به کاربر از نتیجهٔ کنشش) عوض کرده. اما پیام تأیید در رابط، هیچ حلقه‌ای نیست — چیزی به آن کمیت برنمی‌گردد.

و پیامدش ملموس است: تیمی که به او گفته شده «حلقه‌های بازخورد را شناسایی کن»، فهرستی از پیام‌های تأیید و اسنک‌بارهایش را در می‌آورد و نتیجه می‌گیرد تفکر سیستمی انجام داده.

پس یک آزمون سه‌قسمتی، پیش از آنکه چیزی را «حلقه» بنامید:

• - کمیت را نام ببرید. چه چیزی زیاد و کم می‌شود؟
• - مسیر بازگشت را نام ببرید. این کمیت از چه راهی روی خودش اثر می‌گذارد؟
• - و تأخیر را نام ببرید. چند وقت طول می‌کشد تا اثر برگردد؟

و تأخیر همان قلمی است که همه جا می‌اندازند — و دقیقاً همان چیزی است که باعث می‌شود حلقه‌ها غافلگیرتان کنند.

و جالب اینکه منبع یک نمونهٔ واقعی از حلقه هم دارد، ولی در جای دیگری و بی آنکه به آن اشاره کند: «کاربران آموزش اولیه را رد می‌کنند ← تیکت‌های پشتیبانی جهش می‌کند». و اگر پشتیبانی در پاسخ، راهنمایی بنویسد که بعداً به آموزش اولیه تبدیل شود، آن یک حلقهٔ کامل است — با کمیت، مسیر بازگشت، و تأخیری چند‌هفته‌ای.

اگر این کار آسان‌تر شد، کارش به گردن کی افتاد؟

این بخش هم افزودهٔ مترجم است. نمونهٔ خودروی برقیِ منبع بهترین حرکت آن مقاله است، ولی منبع قاعده‌ای که از آن بیرون می‌آید را نمی‌نویسد. قاعده این است:

وقتی کاری را از دوش کاربر برمی‌دارید، ببینید حالا چه کسی انجامش می‌دهد. تلاش و هزینه به‌ندرت نابود می‌شوند؛ جابه‌جا می‌شوند.

• - تأیید خودکار یک درخواست ← کار بازبینی را به پشتیبانی، چند روز بعد، منتقل می‌کند.
• - حذف یک فیلد الزامی ← حدس‌زدنش را به تیم عملیات منتقل می‌کند.
• - پرداخت یک‌کلیکی ← رسیدگی به خطا را به فرایند بازگشت پول منتقل می‌کند.
• - پنهان‌کردن یک تنظیم ← بار را به میز راهنما منتقل می‌کند.

و پرسش تشخیصی‌اش یک جمله است: «اگر این حالا آسان‌تر شده، کارش به گردن کی افتاد؟»

و اگر هیچ‌کس نتوانست جوابش را بدهد، شما مرز سامانه‌تان را پیدا نکرده‌اید — فقط آن را دور تیم خودتان کشیده‌اید.

و یک صداقت دربارهٔ نمونهٔ خود منبع: آن مسئلهٔ آبیاری با نمودار حل نشد؛ با رفتن و اندازه‌گرفتن دمای آب حل شد. هیچ نمودار حلقهٔ علّی‌ای «لوله‌ها تیره‌اند» را بیرون نمی‌کشد.

پس درس صادقانه‌اش این است: نقشهٔ سامانه در گفتنِ «کجا را نگاه کن» خوب است و در گفتنِ «چه چیزی پیدا می‌کنی» بد. و حالت شکستش، جلسه‌ای است که یک نمودار زیبا تولید می‌کند و هیچ اندازه‌گیری. قاعدهٔ عملی: هر نقشهٔ سامانه باید به فهرستی از «چیزهایی که باید بروم اندازه بگیرم» ختم شود، با یک نام کنار هرکدام. اگر نشد، آن یک تمرین نقاشی بود.

«همه‌چیز یک سامانه است» بی مرز، بی‌فایده است

این بخش هم افزودهٔ مترجم است و کوتاه است. منبع درست می‌گوید که ساده‌سازی افراطی خطرناک است — ولی شکست معکوس هم به همان اندازه رایج است و در آن متن اسمی ندارد: دامنهٔ بی‌مرز، جایی که هر مسئله «کل اکوسیستم» می‌شود و هیچ چیز منتشر نمی‌شود.

و انتظام لازمش این است: مرز را صریح بکشید، بنویسید چه چیزی را عامدانه بیرون گذاشته‌اید، و فرضی را که اجازهٔ این بیرون‌گذاشتن را می‌دهد بنویسید.

این کار یک بازگشت بی‌پایان را به یک تصمیمِ ثبت‌شده تبدیل می‌کند — و اگر بعداً آن چیزِ بیرون‌گذاشته‌شده مهم از آب در آمد، دقیقاً می‌دانید کدام فرض شکست، که خودش سریع‌ترین راه اصلاح است.

در بافت فارسی: نقشهٔ سند، نه نقشهٔ کلیک‌ها

این بخش هم افزودهٔ مترجم است و چهار نکته دارد.

یک: سامانه در بازار ما تقریباً همیشه از محصول بیرون می‌زند و به یک گام آفلاین می‌رسد — امضای فیزیکی، مراجعه به شعبه، پیک، بازرسی، رسید کاغذی، احراز هویت حضوری. و همان گام است که هیچ‌وقت نقشه نمی‌شود.

پس نقشه‌ای که اینجا کار می‌کند، معماری نرم‌افزار نیست و جریان کلیک‌های کاربر هم نیست: مسیر سند یا شیء است. بنویسید در هر لحظه، آن کاغذ یا کارت یا بسته کجاست و دست کیست — چون تأخیرها و گم‌شدن‌ها همان‌جا زندگی می‌کنند، نه در کد.

دو: قوی‌ترین حلقهٔ واقعی در محصولات محلی، حلقهٔ پشتیبانی‌–‌محصول است، و معمولاً شکسته است. پشتیبانی هر روز حقیقت را می‌فهمد و مسیر بازگشتی به طراحی ندارد.

و با همان آزمون سه‌قسمتی بالا، درستش این است: کمیت = تعداد تماس‌های مکرر دربارهٔ موضوع X · مسیر بازگشت = تغییری که در محصول انجام می‌شود · تأخیر = هفته‌ها. و ساختن همین مسیر بازگشت، پرنفوذترین مداخلهٔ سیستمی در دسترس یک تیم است — و سازمانی است، نه فنی.

سه: تأخیرها اینجا بلندتر و پرنوسان‌ترند (تأمین، مجوز، وابستگی بیرونی، خوشهٔ تعطیلات) — و تأخیر بلند دقیقاً همان چیزی است که رفتار حلقه را ضد‌شهودی می‌کند: فشار می‌دهید، چیزی نمی‌شود، بیشتر فشار می‌دهید، و بعد همه‌اش یک‌جا می‌رسد.

پس یک عادت ارزان: کنار هر مداخله، تأخیر مورد‌انتظارش را بنویسید — و پیش از سپری‌شدن آن تأخیر، مداخلهٔ دوم نکنید. بیشتر نوسان‌هایی که به «بی‌ثباتی بازار» نسبت داده می‌شوند، پاسخ‌های زودهنگام خود ما به تأخیرهای خودمان‌اند.

چهار و آخر، یک قید صادقانه: در تیم کوچک، بیشتر مسائل سیستمی نیستند؛ فقط حل‌نشدهاند. تفکر سیستمی توجهِ گران است، و به‌کار‌بردنش روی مسئله‌ای که یک اصلاح دو‌خطی حلش می‌کند، راهی برای پرهیز از آن اصلاح است.

آزمونش هم ساده است: آیا این مسئله از دو تلاش صادقانه برای حل مستقیمش جان سالم به‌در برده؟ اگر نه، مستقیم حلش کنید و نقشه را برای بار سوم نگه دارید.

جمع‌بندی

• - تفکر سیستمی تحلیل مسئله در بافت کل سامانه است تا علت ریشه‌ای به‌جای نشانه درمان شود؛ از فارستر و گروه دینامیک سیستم‌ها (۱۹۵۶) می‌آید و نورمن آن را به سامانه‌های اجتماعی‌–‌فنی پیچیده وصل می‌کند.
• - اما منبع «حلقهٔ بازخورد» را با معنای روزمرهٔ «بازخورد در رابط» عوض می‌کند: پیام تأیید هیچ حلقه‌ای نیست. حلقهٔ مثبت خروجی را بیشتر می‌کند و حلقهٔ منفی انحراف را کم می‌کند.
• - آزمون سه‌قسمتی: کمیت · مسیر بازگشت · تأخیر — و تأخیر همان قلمی است که جا می‌افتد و باعث غافلگیری می‌شود.
• - از نمونهٔ خودروی برقی یک قاعده در می‌آید که منبع نمی‌نویسد: «اگر این حالا آسان‌تر شده، کارش به گردن کی افتاد؟» تلاش نابود نمی‌شود، جابه‌جا می‌شود — و اگر جوابی نیست، مرز سامانه را دور تیم خودتان کشیده‌اید.
• - و نمونهٔ آبیاریِ خود منبع با نمودار حل نشد، با اندازه‌گیری حل شد: نقشهٔ سامانه می‌گوید کجا را نگاه کن، نه چه چیزی پیدا می‌کنی. هر نقشه باید به فهرستی از اندازه‌گیری‌ها با نام مسئول ختم شود.
• - «همه‌چیز یک سامانه است» بی مرز بی‌فایده است: مرز را صریح بکشید و فرضِ بیرون‌گذاشتن را بنویسید.
• - و در بافت ما: مسیر سند یا شیء را نقشه کنید، نه کلیک‌ها · حلقهٔ پشتیبانی‌–‌محصول را وصل کنید (پرنفوذترین مداخلهٔ در دسترس) · تأخیر هر مداخله را بنویسید و پیش از سپری‌شدنش مداخلهٔ دوم نکنید · و بپرسید آیا این مسئله سیستمی است یا فقط حل‌نشده.