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

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

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

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

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

تعریف

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

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

ریشه و ضرورتش

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

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

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

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

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

تفکر سیستمی سومین اصل طراحی انسانیت‌محور است و چهار گام دارد. یک نمونهٔ ممتد — آبیاری یک روستا — هر چهار گام را نشان می‌دهد:

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

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

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

در دینامیک سیستم‌ها — همان سنتی که فارستر بنا گذاشت — این دو اصطلاح معنای دقیقی دارند:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

چهار نکته اینجا مهم است:

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

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

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

و با همان آزمون سه‌قسمتی بالا، درستش این است:

• - کمیت = تعداد تماس‌های مکرر دربارهٔ موضوع X
• - مسیر بازگشت = تغییری که در محصول انجام می‌شود
• - تأخیر = هفته‌ها.

و ساختن همین مسیر بازگشت، پرنفوذترین مداخلهٔ سیستمی در دسترس یک تیم است — و سازمانی است، نه فنی

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

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

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

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

جمع‌بندی

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