سیستم خراب را با چیزهای بیشتر درست نکن
یک الگوی تکراری هست که من در خیلی از سازمانها میبینم.
یک جایی از سیستم گیر میکند. فرآیند درست جلو نمیرود. کارها عقب میافتد. اطلاعات ناقص است. مسئولیتها گم میشود.
و اولین واکنش معمولاً یک چیز است: اضافهکردن.
فرآیند خرید کند است؟ یک فرم دیگر اضافه کنیم. گزارشها ناقص است؟ یک گزارش جدید بخواهیم. مدیران پاسخگو نیستند؟ یک جلسهی کنترل دیگر بگذاریم. اطلاعات پراکنده است؟ یک داشبورد دیگر بسازیم. کارکنان فرآیند را دور میزنند؟ یک لایه کنترل دیگر روی فرآیند بگذاریم.
هر بار همین اتفاق. و جالب اینجاست که بعد از مدتی، سیستم نهتنها درستتر نمیشود، بلکه پیچیدهتر میشود. فرم بیشتر، گزارش بیشتر، جلسه بیشتر، کنترل بیشتر، امضا بیشتر ولی خروجی؟ گاهی حتی بدتر از قبل.
اینجاست که به نظرم باید یک لحظه بایستیم و یک سؤال ساده بپرسیم: واقعاً چیزی کم داریم یا چیزی زیادی داریم؟
چرا همیشه فکر میکنیم باید چیزی اضافه کنیم؟
به نظرم یکی از دلایلش این است که اضافهکردن دیده میشود.
وقتی یک فرم جدید طراحی میکنی، همه میبینند که یک کاری انجام شده. وقتی یک نرمافزار جدید میخری، میتوانی بگویی سیستم را ارتقا دادیم. وقتی جلسهی جدید میگذاری، همه میبینند که برای کنترل موضوع برنامه گذاشتهای.
اما حذفکردن معمولاً دیده نمیشود. کسی نمیگوید «چه کار مدیریتی فوقالعادهای! امروز یک امضای اضافی را از فرآیند حذف کرد.» ولی همین حذفهای کوچک، گاهی اثرشان از دهها اقدام جدید بیشتر است.
ما معمولاً دوست داریم کاری انجام بدهیم. کمتر دوست داریم تشخیص بدهیم که شاید بهترین کار، انجامندادن یک کار باشد.
شاید مشکل سیستم، کمبود نباشد
این قسمت برای من خیلی مهم است. خیلی وقتها یک سیستم خراب نیست چون چیزی در آن کم است خراب است چون چیزهای زیادی در آن وجود دارد.
فرآیند خرید ممکن است کند باشد، نه چون یک تأیید کم دارد؛ بلکه چون پنج تأیید غیرضروری دارد. ممکن است هر پنج تأیید زمانی برای یک دلیل منطقی ایجاد شده باشد: یکی برای کنترل مالی، یکی برای کنترل فنی، یکی برای کنترل مدیریتی، یکی بعد از یک اشتباه قدیمی، و یکی هم فقط چون «همیشه همینطوری بوده».
نتیجه؟ کسی دقیقاً مسئول تصمیم نیست، ولی همه باید امضا کنند. یعنی کنترل زیاد شده، اما پاسخگویی الزاماً بیشتر نشده است.
گزارش بیشتر، همیشه یعنی اطلاعات بهتر؟
گاهی مشکل سازمان این نیست که گزارش نداریم. مشکل این است که گزارش زیاد داریم.
هر واحد یک گزارش دارد. مدیر یک گزارش دیگر میخواهد. مدیریت ارشد یک فرمت دیگر میخواهد. جلسهی هفتگی یک گزارش میخواهد، جلسهی ماهانه یک گزارش دیگر. بعد همان اطلاعات در چند فایل و چند داشبورد تکرار میشود.
آخرش چه اتفاقی میافتد؟ اطلاعات آنقدر زیاد میشود که اطلاعات مهم در میان اطلاعات غیرمهم گم میشود. ما فکر میکنیم با گزارش بیشتر، کنترل بیشتر میشود، در حالی که ممکن است فقط نویز بیشتری به سیستم اضافه کرده باشیم. گاهی یک گزارش خوب که واقعاً خوانده و استفاده شود، از ده گزارش اضافی ارزشمندتر است.
این دقیقاً همان چیزی است که در مکانیزم غرق شدن سیستم هم دیدیم: سیستمی که زیر حجم اطلاعات خودش دفن میشود، نه چون اطلاعات کم دارد، بلکه چون نمیتواند مهم را از غیرمهم جدا کند.
جلسه بیشتر، الزاماً مدیریت بهتر نیست
این یکی را احتمالاً همه تجربه کردهایم. یک مشکل داریم، پس جلسه میگذاریم. مشکل حل نمیشود، جلسهی دیگری میگذاریم. جلسهی کنترل پروژه، جلسهی پیگیری، جلسهی هماهنگی، جلسهی بررسی جلسهی قبلی.
بعد مدیران بخش زیادی از وقتشان را صرف آمادهشدن برای جلسات میکنند. گزارش آماده میکنند، اسلاید آماده میکنند، داده جمع میکنند. جلسه برگزار میشود، همه صحبت میکنند، و آخر جلسه: «پس این موضوع را پیگیری میکنیم.» تمام.
به نظرم اینجا باید سؤال دیگری بپرسیم: مشکل ما کمبود جلسه است یا کمبود تصمیم؟ چون جلسهای که تصمیم تولید نمیکند، ممکن است فقط یک هزینهی سازمانی باشد.
سیستمها چطور چاق میشوند؟
سیستمهای سازمانی معمولاً یکشبه پیچیده نمیشوند. داستانشان خیلی ساده است: یک روز یک اشتباه اتفاق میافتد، برای جلوگیری از تکرارش یک کنترل اضافه میکنیم. یک تخلف اتفاق میافتد، یک فرم دیگر اضافه میکنیم. یک پروژه شکست میخورد، یک تأیید دیگر اضافه میکنیم. یک مدیر نگران میشود، یک گزارش جدید میخواهد. بعد مدیر بعدی میآید و یک کنترل دیگر اضافه میکند.
هیچکدام از این تصمیمها شاید بهتنهایی اشتباه نباشند. مشکل وقتی ایجاد میشود که هیچکس بعداً برنمیگردد ببیند این چیزهایی که اضافه کردهایم هنوز لازم هستند یا نه. سیستم همینطور رشد میکند مثل خانهای که هر سال یک اتاق به آن اضافه کردهایم، ولی هیچوقت اتاقهای قدیمی را بررسی نکردهایم. بعد یک روز میبینیم: خانه بزرگتر شده، ولی زندگیکردن در آن سختتر شده است.
قانون حذف قبل از اضافه چیست؟
اینجا من به یک قاعدهی ساده رسیدهام: قبل از اینکه چیزی به سیستم اضافه کنی، یک چیز را از آن کم کن.
این به این معنی نیست که هر اضافهکردنی اشتباه است. گاهی واقعاً یک چیز کم داریم، یک کنترل ضروری وجود ندارد، یا نرمافزار جدید لازم است. اما قبل از اینکه چیزی اضافه کنیم، یک بار سیستم موجود را نگاه کنیم: چه چیزی واقعاً ارزش ایجاد میکند، چه چیزی زائد است، چه چیزی تکراری است، چه چیزی فقط به خاطر عادت باقی مانده، و چه چیزی حتی دارد جلوی کارکردن سیستم را میگیرد. بعد تصمیم بگیریم.
قبل از اضافهکردن یک فرم، یکی را حذف کن
فرض کن فرآیند خرید کند شده. راه ساده این است که بگوییم «یک فرم کنترل جدید طراحی کنیم.» اما راه بهتر این است که اول کل فرآیند را نگاه کنیم: چند فرم داریم؟ چند بار اطلاعات مشابه وارد میشود؟ چند امضا داریم؟ کدام امضا واقعاً ریسک را کاهش میدهد؟ کدام مرحله هنوز به دلیل یک اتفاق مربوط به پنج سال پیش وجود دارد؟
ممکن است در نهایت بفهمیم مشکل فرآیند خرید، کمبود کنترل نیست؛ زیادی کنترل است.
قبل از جلسهی جدید، جلسههای قبلی را بررسی کن
قبل از اینکه یک جلسهی جدید برای کنترل پروژه بگذاریم، بهتر است ببینیم جلسههای فعلی چه خروجیای دارند. آیا تصمیمی در آنها گرفته میشود؟ آیا مسئول مشخصی برای اقدام تعیین میشود؟ یا فقط همان اطلاعاتی که قبلاً در گزارش نوشته شده، دوباره برای چند نفر خوانده میشود؟
اگر جلسه فقط تکرار گزارش است، شاید مشکل ما جلسهی کم نیست؛ مشکل این است که تصمیم نمیگیریم. در این شرایط، حذف یک جلسه میتواند بیشتر از اضافهکردن یک جلسه ارزش ایجاد کند.
این قانون فقط دربارهی فرآیندها نیست
به نظرم این موضوع دربارهی خود مدیر هم صدق میکند. وقتی خروجی یک مدیر پایین است، واکنش معمولاً این است: بیشتر کار کند، جلسهی بیشتری بگذارد، گزارش بیشتری بخواهد، بیشتر کنترل کند.
اما شاید سؤال درست این نباشد: «چه کار بیشتری باید انجام بدهد؟» شاید باید پرسید: «کدام کارها را دیگر نباید انجام بدهد؟»
گاهی مشکل مدیر کمکاری نیست؛ پرکاریِ بیاثر است. مدیری که تمام روز درگیر جلسه، گزارش، امضا و پیگیری است، الزاماً مدیر بهرهوری نیست. ممکن است خودش درگیر همان سیستمی شده باشد که باید اصلاحش کند.
حذفکردن به معنی بینظمی نیست
البته یک خطر هم وجود دارد: اینکه از «قانون حذف قبل از اضافه» برداشت کنیم هر چیزی اضافه است، حذفش کنیم. نه، این هم اشتباه است. هر کنترل قدیمی الزاماً بیفایده نیست. هر فرم قدیمی الزاماً زائد نیست.
پس قبل از حذف باید یک سؤال مهم دیگر بپرسیم: این بخش چرا اصلاً به وجود آمده است؟ این همان ایدهای است که در تفکر سیستمی با مفهوم حصار چسترتون (Chesterton's Fence) شناخته میشود؛ یعنی قبل از حذف یک قاعده یا ساختار، اول باید بفهمیم چرا اصلاً ایجاد شده است.
پس قانون من این نیست که «هر چیزی را حذف کن.» قانون این است: اول دلیل وجودش را بفهم، بعد تصمیم بگیر هنوز لازم است یا نه.
اگر امروز از صفر شروع میکردیم، باز هم همین سیستم را میساختیم؟
این یکی از سؤالهایی است که به نظرم باید بیشتر از خودمان بپرسیم. اگر امروز سازمان را از صفر طراحی میکردیم: آیا همین تعداد فرم را میگذاشتیم؟ همین تعداد امضا؟ همین تعداد جلسه؟ همین تعداد لایهی مدیریتی؟
اگر جواب خیلی از این سؤالها «نه» است، پس یک جای کار میلنگد. چون اینکه چیزی سالهاست وجود دارد، دلیل خوبی برای ادامهی وجودش نیست. قدیمیبودن، دلیل درستبودن نیست.
این نگاه، دقیقاً به همان نقاط اهرمی و حلقههای بازخورد سازمانی وصل میشود که قبلاً بررسی کردیم: بیشتر تلاشهای اصلاحی روی نقاط اهرمی ضعیف متمرکز میشود اضافهکردن یک کنترل جدید آسان است، اما پرسیدن «چرا اصلاً این ساختار اینطور شکل گرفته؟» نقطهی اهرمی قویتری است.
یک تست سادهی مدیریتی
از این به بعد، قبل از اینکه چیزی به سیستم اضافه کنیم، میتوانیم پنج سؤال ساده بپرسیم:
۱. دقیقاً چه مشکلی را حل میکند؟
۲. چرا سیستم فعلی نتوانسته این مشکل را حل کند؟
۳. آیا میتوانیم بهجای اضافهکردن، چیزی را حذف کنیم؟
۴. این چیز جدید چه پیچیدگی تازهای به سیستم اضافه میکند؟
۵. اگر امروز سازمان را از صفر طراحی میکردیم، باز هم این را اضافه میکردیم؟
اگر برای سؤال اول جواب روشنی نداریم، شاید هنوز نباید چیزی اضافه کنیم.
جمعبندی: سیستم را با اضافهکردن نجات نده
یکی از خطرناکترین عادتهای مدیریتی این است که هر مشکلی را با یک اقدام جدید جواب بدهیم. مشکل ایجاد شد؟ یک قانون. تکرار شد؟ یک کنترل. باز هم؟ یک فرم. باز هم؟ یک جلسه. و بعد از چند سال، یک سیستم داریم که برای حل مشکلات گذشته ساخته شده، اما خودش تبدیل به یکی از مشکلات امروز شده است.
برای همین، قبل از هر تصمیم جدید، یک سؤال ساده را امتحان کنیم: اگر قرار باشد فقط یک چیز به این سیستم اضافه کنم، اول چه چیزی را باید حذف کنم؟
شاید پاسخ یک فرم باشد. شاید یک جلسه. شاید یک تأیید، یا حتی یک فرآیند کامل. چون همیشه چیزی که سیستم کم دارد، چیزی نیست که باید به آن اضافه شود. گاهی چیزی که سیستم لازم دارد، شجاعت حذفکردن است.
قبل از اینکه سیستم را بزرگتر کنیم، ببینیم میتوانیم آن را سادهتر کنیم.
چند سؤال پرتکرار
۱. قانون حذف قبل از اضافه چیست؟
یعنی قبل از اینکه برای حل یک مشکل، فرآیند، فرم، جلسه، کنترل یا ابزار جدیدی به سیستم اضافه کنیم، ابتدا بررسی کنیم آیا چیزی در سیستم فعلی وجود دارد که بتوان آن را حذف یا ساده کرد.
۲. آیا حذف همیشه بهتر از اضافهکردن است؟
نه. هدف حذف کورکورانه نیست. ابتدا باید دلیل وجود هر بخش را فهمید و بعد بررسی کرد که آیا هنوز ارزش ایجاد میکند یا نه.
۳. قانون حذف قبل از اضافه چه ارتباطی با تفکر سیستمی دارد؟
تفکر سیستمی بهجای نگاهکردن به یک مشکل بهصورت جداگانه، روابط و ساختار کل سیستم را بررسی میکند. قبل از اضافهکردن یک راهحل، باید دید آیا مشکل از ساختار موجود یا پیچیدگی سیستم ناشی میشود.
۴. مهمترین سؤال قبل از اضافهکردن یک فرآیند جدید چیست؟
یک سؤال ساده: اگر امروز این سیستم را از صفر طراحی میکردیم، باز هم این فرآیند را به آن اضافه میکردیم؟ اگر جواب «نه» باشد، احتمالاً زمان آن رسیده که دربارهی حذف یا بازطراحی آن جدیتر فکر کنیم.