خلاصه مدیریتی ۶۰ ثانیه‌ای
سازمان‌ها برای خطاها و نیازهای مقطعی کنترل، گزارش و جلسه اضافه می‌کنند، اما معمولاً سازوکاری برای بازبینی و حذف آنها ندارند.
برای کنترل‌ها و فرآیندهای جدید Review Date تعریف کنید و هر فصل یک Stop-Doing Review با سؤال «چه چیزی را می‌توانیم حذف کنیم؟» برگزار کنید.
پیچیدگی انباشته قابل مشاهده می‌شود و حذف، از یک اقدام سلیقه‌ای به بخشی از طراحی و نگهداری سیستم تبدیل می‌شود.
چند روز پیش یادداشت بسیار کوتاهی از Steph Ango با عنوان What can we remove? خواندم.
کل نوشته شاید یک دقیقه زمان بخواهد، اما سؤالش مدتی در ذهنم ماند:
چه چیزی را می‌توانیم حذف کنیم؟
Ango درباره یک تمایل طبیعی در سیستم‌ها می‌نویسد: اینکه مدام چیزی به آنها اضافه می‌کنیم؛ قانون بیشتر، فرآیند بیشتر، قابلیت بیشتر، کد بیشتر و چیزهای بیشتر. اگر مکانیزمی برای هرس کردن وجود نداشته باشد، همین اضافه‌شدن‌ها به‌تدریج سیستم را پیچیده و سنگین می‌کنند. Steph Ango
وقتی نوشته را خواندم، بیشتر از نرم‌افزار یا زندگی شخصی، به شرکت‌ها فکر کردم.
چون در سازمان‌ها تقریباً همیشه برای اضافه کردن دلیل داریم.
اما برای حذف کردن، کمتر.
مشکل حل می‌شود؛ راه‌حل باقی می‌ماند
فرض کنید یک بار در ارسال بار اشتباهی اتفاق می‌افتد.
برای اینکه تکرار نشود، یک مرحله تأیید اضافه می‌کنیم.
یک بار گزارشی لازم می‌شود و از آن به بعد تصمیم می‌گیریم هر هفته تهیه شود.
بحرانی پیش می‌آید و برای کنترلش جلسه‌ای تشکیل می‌دهیم.
اطلاعاتی گم می‌شود و یک فایل Excel جدید می‌سازیم.
مشکلی در پرداخت اتفاق می‌افتد و یک امضای دیگر به فرآیند اضافه می‌کنیم.
احتمالاً در همان لحظه، هرکدام از این تصمیم‌ها منطقی بوده‌اند.
مسئله این نیست که چرا آنها را ایجاد کرده‌ایم.
مسئله این است:
چه کسی قرار است چند ماه یا چند سال بعد بررسی کند که هنوز به آنها نیاز داریم یا نه؟
مشکل ممکن است مدت‌ها قبل حل شده باشد، اما راه‌حل همچنان در سازمان زندگی کند.
و این اتفاق اگر به‌اندازه کافی تکرار شود، نتیجه‌اش سازمانی است که هیچ‌کس دقیقاً نمی‌داند چرا بعضی کارها را انجام می‌دهد.
فقط می‌داند:
«روالش همین است.»
به نظرم این جمله یکی از مواردی است که باید در سازمان نسبت به آن حساس باشیم.
وقتی پاسخ سؤال «چرا این کار را انجام می‌دهیم؟» تبدیل می‌شود به «چون همیشه همین‌طور انجام داده‌ایم»، شاید زمان بازبینی رسیده باشد.
هر اشتباه، مستحق یک قانون جدید نیست
این بخش ماجرا برای من از همه مهم‌تر است.
مدیران معمولاً نسبت به یک اتفاق بد واکنش نشان می‌دهند.
و واکنش قابل مشاهده معمولاً اضافه کردن کنترل است.
یک نفر اشتباه کرده؟
از این به بعد مدیرش هم تأیید کند.
دوباره مشکلی پیش آمده؟
مدیر بالاتر هم تأیید کند.
یک اطلاعات جا افتاده؟
سه فیلد دیگر به فرم اضافه کنیم.
یک مشتری ناراضی شده؟
یک گزارش هفتگی جدید ایجاد کنیم.
این کار احساس خوبی ایجاد می‌کند، چون نشان می‌دهد در برابر مشکل «کاری کرده‌ایم».
اما سؤال سخت‌تر این است:
آیا واقعاً لازم بود کاری به سیستم اضافه کنیم؟
هر کنترل جدید رایگان نیست.
زمان می‌گیرد.
تصمیم را کند می‌کند.
تمرکز آدم‌ها را مصرف می‌کند.
گاهی اختیار را از کسی می‌گیرد که باید یاد بگیرد خودش تصمیم بگیرد.
و در نهایت ممکن است صد نفر را مجبور کنیم هر روز هزینه اشتباهی را بپردازند که یک نفر، یک بار مرتکب شده است.
این به معنی مخالفت با کنترل نیست.
در بعضی فرآیندها، مخصوصاً وقتی پای پول، ایمنی، کیفیت، قرارداد یا ریسک جدی در میان است، کنترل اضافه کاملاً توجیه دارد.
اما قبل از اضافه کردن قانون شاید باید بپرسیم:
با یک اتفاق استثنایی روبه‌رو هستیم یا یک مشکل سیستمی و تکرارشونده؟
این دو، پاسخ یکسانی نمی‌خواهند.
حذف کردن هم می‌تواند اشتباه باشد
اینجا باید مراقب یک دام دیگر هم باشیم.
وقتی از ساده‌سازی خوشمان می‌آید، ممکن است به همان اندازه که قبلاً شیفته اضافه کردن بودیم، شیفته حذف کردن شویم.
هر مرحله‌ای که خروجی مستقیم تولید نمی‌کند، زائد نیست.
کنترل کیفیت ممکن است سرعت تولید را کم کند.
بازبینی قرارداد ممکن است فروش را کندتر کند.
تأیید مالی ممکن است فرآیند خرید را طولانی‌تر کند.
Backup، امنیت اطلاعات، مستندسازی و کنترل داخلی همگی هزینه دارند.
اما هزینه داشتن با بی‌فایده بودن فرق دارد.
بنابراین سؤال خوب این نیست:
«چطور فرآیندمان را کوتاه‌تر کنیم؟»
سؤال بهتر این است:
«اگر امروز این مرحله وجود نداشت، با دانشی که اکنون داریم دوباره آن را ایجاد می‌کردیم؟»
اگر پاسخ «بله» است، نگهش داریم.
اگر «نه» است، سؤال بعدی سخت‌تر می‌شود:
پس چرا هنوز وجود دارد؟
این سؤال مرا یاد یکی از ایده‌هایی می‌اندازد که Jim Collins با ارجاع به Peter Drucker مطرح کرده است: اگر امروز با یک صفحه سفید روبه‌رو بودید، آیا دوباره وارد همین فعالیت، پروژه، سیاست یا تصمیم می‌شدید؟ اگر نه، ادامه دادن آن نیاز به توضیح دارد. Jim Collins
هزینه چیزهای کوچک را دست‌کم می‌گیریم
مشکل اصلی معمولاً یک فرآیند بسیار بد نیست.
انباشت تعداد زیادی چیز نسبتاً بد است.
جلسه‌ای که فقط ۳۰ دقیقه اضافه است.
گزارشی که تهیه‌اش فقط ۲۰ دقیقه طول می‌کشد.
یک تأیید که فقط چند ساعت سفارش را عقب می‌اندازد.
یک گروه کاری که فقط چند Notification بیشتر ایجاد می‌کند.
یک فایل Excel که «فعلاً» باید در کنار سیستم اصلی نگه داشته شود.
یک CC اضافه در ایمیل.
یک فرم که فقط چند فیلد غیرضروری دارد.
هیچ‌کدام به‌تنهایی آن‌قدر دردناک نیستند که کسی برای حذفشان بجنگد.
اما سازمان به‌تدریج هزینه مجموع آنها را می‌پردازد.
و بدتر اینکه بعد از مدتی این پیچیدگی برای ما عادی می‌شود.
شبیه همان استعاره زیبایی که Ango در نوشته‌اش از ساحل استفاده می‌کند: یک تکه زباله را می‌توان برداشت؛ وقتی همه‌جا پر شده باشد، منظره جدید را طبیعی فرض می‌کنیم. Steph Ango
در سازمان هم شاید خطرناک‌ترین مرحله زمانی باشد که دیگر پیچیدگی را نمی‌بینیم.
چرا حذف کردن سخت‌تر از اضافه کردن است؟
فکر می‌کنم بخشی از پاسخ، انسانی است.
اضافه کردن قابل مشاهده است.
یک مدیر سیستم جدید راه‌اندازی می‌کند.
فرآیند جدید طراحی می‌کند.
داشبورد جدید می‌سازد.
جلسه جدید تشکیل می‌دهد.
پروژه جدید تعریف می‌کند.
در پایان چیزی وجود دارد که می‌توان نشان داد.
اما کسی که یک گزارش غیرضروری را حذف کرده چه چیزی برای نشان دادن دارد؟
هیچ.
جلسه‌ای برگزار نشده.
گزارشی تولید نشده.
فرمی تکمیل نشده.
زمانی مصرف نشده.
کار خوب او دقیقاً در چیزی است که دیگر وجود ندارد.
Ango در پایان یادداشتش هم به همین «کار نامرئی حذف کردن» اشاره می‌کند. Steph Ango
به نظرم در مدیریت هم باید برای این نوع کار ارزش بیشتری قائل شویم.
همه پیشرفت‌ها حاصل ساختن چیز جدید نیستند.
گاهی پیشرفت یعنی برداشتن چیزی که دیگر نباید آنجا باشد.
شاید در کنار To-Do List به Stop-Doing List نیاز داریم
سال‌هاست درباره To-Do List صحبت می‌کنیم.
چه کارهایی باید انجام دهیم؟
چه پروژه‌هایی باید شروع کنیم؟
چه قابلیتی باید به محصول اضافه کنیم؟
چه گزارشی لازم داریم؟
چه جلسه‌ای برگزار کنیم؟
Jim Collins پیشنهاد می‌کند در کنار To-Do List، یک Stop-Doing List هم داشته باشیم؛ یعنی آگاهانه مشخص کنیم چه فعالیت‌هایی باید متوقف شوند. او حتی پیشنهاد می‌کند در برنامه‌ریزی، فقط اهداف جدید تعیین نکنیم و اهدافی برای متوقف کردن بعضی فعالیت‌ها هم داشته باشیم. Jim Collins
فکر می‌کنم این ایده در شرکت‌ها می‌تواند بسیار عملی باشد.
مثلاً هر سه ماه یک بار، جلسه‌ای داشته باشیم که دستور جلسه‌اش فقط یک سؤال باشد:
چه چیزی را می‌توانیم حذف کنیم؟
نه اینکه چه پروژه جدیدی شروع کنیم.
نه اینکه چه نرم‌افزار دیگری بخریم.
نه اینکه چه KPI جدیدی تعریف کنیم.
فقط ببینیم:
کدام گزارش دیگر خوانده نمی‌شود؟
کدام جلسه دیگر تصمیمی تولید نمی‌کند؟
کدام تأیید ارزش متناسب با تأخیری که ایجاد می‌کند ندارد؟
کدام فایل موازی را می‌توان بازنشسته کرد؟
کدام KPI دیگر به تصمیمی منجر نمی‌شود؟
کدام Notification را می‌توان خاموش کرد؟
کدام مرحله از فرآیند فقط میراث یک مشکل قدیمی است؟
و شاید مهم‌تر:
چه کاری را انجام می‌دهیم که اگر امروز از صفر شروع می‌کردیم، اصلاً شروعش نمی‌کردیم؟
اما حذف باید صاحب داشته باشد
یک نکته دیگر هم از تجربه سیستم‌سازی برایم مهم است.
صرف اینکه بگوییم «فرآیندها را ساده کنیم» اتفاق خاصی نمی‌افتد.
همان‌طور که برای اضافه کردن Owner تعیین می‌کنیم، برای حذف هم باید مسئولیت وجود داشته باشد.
حتی می‌توان برای بعضی تصمیم‌های جدید از ابتدا Review Date گذاشت.
مثلاً:
این گزارش را سه ماه اجرا می‌کنیم و بعد بررسی می‌کنیم.
این جلسه تا پایان پروژه برقرار است.
این کنترل به‌دلیل مشکل فعلی اضافه شده و شش ماه بعد باید دوباره ارزیابی شود.
این فایل موقت است و بعد از انتقال کامل اطلاعات حذف می‌شود.
یعنی بعضی چیزها را به‌جای اینکه با عمر نامحدود وارد سازمان کنیم، با یک سؤال از قبل وارد کنیم:
«چه زمانی دوباره درباره ادامه وجودش تصمیم می‌گیریم؟»
این شاید همان مکانیزم «هرس کردن» باشد که Ango درباره‌اش صحبت می‌کند: سیستم خوب فقط قابلیت رشد ندارد؛ راهی برای پاک شدن چیزهای اضافی هم در خودش دارد. Steph Ango
این سؤال فقط برای سازمان نیست
بعد از خواندن آن یادداشت، متوجه شدم همین سؤال را می‌شود درباره کار شخصی هم پرسید.
کدام جلسه را دیگر لازم نیست شرکت کنم؟
کدام گزارش را از روی عادت می‌خوانم؟
کدام Notification واقعاً باید روشن باشد؟
کدام تعهد را سال‌ها پیش پذیرفته‌ام و هیچ‌وقت دوباره درباره‌اش تصمیم نگرفته‌ام؟
کدام کار را می‌توانم واگذار کنم؟
کدام پروژه را باید بپذیرم که قرار نیست تمام شود؟
کدام ابزار را فقط به این دلیل استفاده می‌کنم که زمانی برای راه‌اندازی‌اش وقت گذاشته‌ام؟
و شاید سخت‌ترین سؤال:
کدام کار را فقط به این دلیل ادامه می‌دهم که قبلاً زمان زیادی برایش صرف کرده‌ام؟
حذف کردن همیشه به معنی شکست نیست.
گاهی نتیجه یادگیری بیشتر است.
اضافه کردن پیش‌فرض نباشد
من مخالف فرآیند، کنترل، گزارش یا سیستم بیشتر نیستم.
در بسیاری از مواقع دقیقاً به آنها نیاز داریم.
اما شاید بهتر باشد پیش‌فرضمان را کمی تغییر دهیم.
وقتی مشکلی می‌بینیم، اولین سؤال همیشه این نباشد:
«چه چیزی باید اضافه کنیم تا این مشکل حل شود؟»
گاهی ابتدا بپرسیم:
«چه چیزی را می‌توانیم حذف یا ساده کنیم تا این مشکل اصلاً وجود نداشته باشد؟»
و هر چند وقت یک بار، حتی بدون اینکه مشکلی وجود داشته باشد، در شرکت و زندگی شخصی‌مان قدم بزنیم و به چیزهایی که در طول زمان جمع کرده‌ایم نگاه کنیم.
بعضی‌هایشان هنوز لازم‌اند.
بعضی‌ها باید بهتر شوند.
و بعضی‌ها فقط به این دلیل مانده‌اند که هیچ‌کس مسئول حذف کردنشان نبوده است.
ساختن معمولاً بیشتر دیده می‌شود.
اما شاید یکی از نشانه‌های بلوغ یک سیستم این باشد که فقط بلد نباشد چه چیزی به خودش اضافه کند؛
بلکه بداند چه چیزی را، چه زمانی و چرا باید از خودش کم کند.
پانوشت: جرقه این یادداشت از نوشته کوتاه Steph Ango با عنوان What can we remove? آمده است. اگر نوشته‌های کوتاه و فشرده درباره طراحی، ابزارها، عادت‌ها و فناوری را دوست دارید، نوشته‌های او در وب‌سایت Steph Ango ارزش مرور کردن دارند. Steph Ango