فصل ۲۰ — جمعه، ۲۶ سپتامبر

سه روز بعد، پشت میزم نشسته‌ام و سعی می‌کنم گزارش پیشرفت Phoenix از Kirsten را روی لپ‌تاپم بخوانم. در حالی که غرغر می‌کند و نفس نفس می‌زند، فکر می‌کنم چند هفته از وقتی patch امنیتی John لپ‌تاپم را خراب کرد گذشته.

گرفتن لپ‌تاپ جایگزین مثل بخت‌آزمایی است. وسوسه‌انگیز است به یکی از افراد service desk رشوه بدهم، همان‌طور که یکی از مدیران Marketing پیشنهاد کرد، اما از صف جلو زدن خودداری می‌کنم. باید طبق قوانین بازی کنم چون خودم مسئول وضع و اجرای آن‌ها هستم. یادداشت می‌کنم با Patty دربارهٔ نیاز فوری‌مان به کاهش lead time این جایگزینی‌های لپ‌تاپ حرف بزنم.

بالاخره ایمیل بالا می‌آید:

From: Kirsten Fingle
To: Steve Masters
Cc: Bill Palmer, Chris Allers, Sarah Moulton
Date: September 26, 10:33 AM
Subject: Great news on project front!

Steve،
بالاخره داریم پیش می‌رویم. توقف پروژه و تمرکز IT روی Phoenix گلوگاه را شکسته. در هفت روز گذشته بیشتر از آنچه معمولاً در یک ماه کامل انجام می‌دهیم انجام داده‌ایم.

آفرین به همهٔ تیم!

در حاشیه: بسیاری از حامیان پروژه خیلی ناراضی‌اند که پروژه‌هایشان متوقف شده. به‌خصوص Sarah Moulton معتقد است پروژه‌هایش از توقف معاف‌اند. او را به تو ارجاع دادم.

گزارش رسمی وضعیت پیوست است. اگر سؤالی داری بگو.

Kirsten

اگرچه یادداشت دربارهٔ Sarah که دوباره دردسر می‌سازد فک‌هایم را به هم می‌فشارد، این خبر واقعاً فوق‌العاده است.

انتظارش را داشتیم، اما خبر خوب همچنان خوشایند است، به‌خصوص بعد از اوایل هفته. یک شکست بزرگ داشتیم به‌خاطر incident Sev 1 که همهٔ سامانه‌های تلفن و voicemail داخلی را از کار انداخت و Sales و Manufacturing را در آخرین روز فصل به زانو درآورد.

دو ساعت بعد از outage فهمیدیم یکی از vendorهای شبکه‌مان به‌اشتباه تغییری در سامانهٔ تلفن production ما داده به‌جای hot spare.

outage روی درآمد فصلی‌مان اثر می‌گذارد، اما هنوز نمی‌دانیم چقدر. برای جلوگیری از تکرار، داریم پروژه‌ای برای پایش سامانه‌های بحرانی‌مان در برابر تغییرات غیرمجاز می‌چینیم.

Wes، Patty و John دور میز کنفرانس Patty دربارهٔ همین پروژهٔ پایش حرف می‌زنند.

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

Wes به عقب تکیه می‌دهد و می‌گوید: «خب، رسمی شد. توقف پروژه‌ات واقعاً کار می‌کند.»

Patty با تعجب به او نگاه می‌کند. «واقعاً شک داشتی؟ بیا، هر دو مدام دربارهٔ این حرف زده‌ایم که هرگز مردم این‌قدر متمرکز ندیده‌ایم. شگفت‌انگیز است توقف پروژه چطور تعارض‌های اولویت و multitasking بد را کم کرده. می‌دانیم تفاوت عظیمی در بهره‌وری ساخته.»

Wes شانه بالا می‌اندازد و لبخند می‌زند. «تا Kirsten به ما credit ندهد، همه‌اش فقط در ذهن ماست.»

حق با اوست. واقعاً عالی است Kirsten پیشرفتمان را تأیید کند.

«راستش،» Patty می‌گوید، «او دربارهٔ مدیران کسب‌وکار که دیوانه شده‌اند شوخی نمی‌کند. VPهای بیشتری به من زنگ می‌زنند و waiver برای پروژه‌های محبوبشان می‌خواهند یا می‌خواهند کار off the books انجام شود. فقط Sarah نیست — او فقط واضح‌ترین و پرصدا‌ترین است.»

اخم می‌کنم. «باشد، بخشی از کار ماست و انتظارش را داشتیم. اما نمی‌خواهم این فشار روی هیچ‌کدام از افرادمان اعمال شود. Wes؟»

«به همهٔ تیمم گفته‌ام هر شکایتی را به من ارجاع دهند. و باور کن، به هر کدام از آن آقایان زنگ می‌زنم و یک گوشه‌اشان را می‌گیرم،» می‌گوید.

Patty می‌گوید: «از همین حالا نگرانم بعد از برداشتن توقف پروژه چه می‌کنیم. مثل باز کردن سد نمی‌شود؟»

باز هم انگشتش را روی چیز مهمی گذاشته. می‌گویم: «به Erik زنگ می‌زنم، اما قبلش، الان چطور کارمان را اولویت‌بندی می‌کنیم؟ وقتی به کار روی یک پروژه، یک change، یک service request یا هر چیز دیگری commit می‌کنیم، هر کسی چطور تصمیم می‌گیرد در هر لحظه روی چه چیزی کار کند؟ اگر اولویت‌های رقیب باشند چه می‌شود؟»

«این هر روز لعنتی اتفاق می‌افتد!» Wes می‌گوید، با چهرهٔ باورنکردنی. «به همین خاطر توقف همهٔ پروژه‌ها به‌جز یکی عالی است. کسی لازم نیست تصمیم بگیرد روی چه چیزی کار می‌کند. multitasking ممنوع.»

«سؤال من این نیست،» می‌گویم. «وقتی چند جریان کار همزمان داریم، هر کسی چطور تصمیم می‌گیرد در هر لحظه چه چیزی باید کار شود؟»

«خب،» Wes می‌گوید، «به آن‌ها اعتماد می‌کنیم بر اساس داده‌ای که دارند تصمیم درست بگیرند. به همین خاطر آدم‌های باهوش استخدام می‌کنیم.»

این خوب نیست.

بیست دقیقه‌ای که قبل از توقف پروژه Brent را نگاه کرده بودم را به یاد می‌آورم و می‌پرسم: «و بر چه داده‌ای همهٔ آدم‌های باهوشمان تصمیم‌های اولویت‌بندی‌شان را می‌گیرند؟»

Wes دفاعی می‌گوید: «همه سعی می‌کنیم اولویت‌های رقیب را تا جایی که می‌توانیم جuggle کنیم. زندگی همین است، درست؟ اولویت‌ها عوض می‌شوند.»

«صادق باشیم،» Patty می‌گوید. «اولویت ۱ کسی است که بلندتر فریاد می‌زند، و در صورت تساوی کسی که می‌تواند به ارشدترین executive escalate کند. مگر وقتی subtleتر باشند. دیده‌ام بخشی از staff من همیشه درخواست‌های یک مدیر خاص را اولویت می‌دهند، چون ماهی یک بار آن‌ها را ناهار می‌برد.»

عالی. علاوه بر اینکه بعضی مهندس‌ها bully می‌شوند، مهندس‌های دیگری دارم مثل Corporal Max Klinger از MAS*H که بازار سیاه کار IT خودشان را اداره می‌کنند.

«اگر این درست است، راهی نداریم توقف پروژه را برداریم. نمی‌بینی هیچ راهی نداریم کار را به IT release کنیم و اعتماد کنیم انجام می‌شود؟»

سعی می‌کنم تسلیم بودن را از صدام بیرون نگه دارم و می‌گویم: «Patty حق دارد. قبل از پایان توقف پروژه خیلی چیز باید حل کنیم. که دقیقاً یک هفته دیگر است.»

---

تصمیم می‌گیرم کمی بیرون قدم بزنم. سی دقیقه تا جلسهٔ بعدی وقت دارم و باید فکر کنم.

از همیشه بیشتر unsettled هستم. وقتی بیش از یک پروژه همزمان در سامانه داریم، چطور کار را از interrupt شدن یا trump شدن اولویتش توسط تقریباً هر کسی در کسب‌وکار یا جای دیگر IT محافظت می‌کنیم؟

خورشید رویم می‌تابد. ساعت ۱۱ صبح است و هوا بوی پاییز می‌دهد. برگ‌های درختان دارند نارنجی و قهوه‌ای می‌شوند و توده‌هایی از آن‌ها در پارکینگ جمع شده.

با وجود نگرانی، می‌فهمم چقدر تازه‌کننده است بتوانی دربارهٔ کاری که باید انجام دهیم و چطور اولویت‌بندی و release کنیم فکر کنی. لحظه‌ای از نبود firefighting مداومی که بخش بزرگی از کار IT من را dominate کرده شگفت‌زده می‌شوم.

نوع مسائلی که lately باید حل کنیم آن‌قدر… فکری‌اند.

همان چیزی بود که وقتی MBA گرفتم فکر می‌کردم مدیریت همه‌اش همین است.

متقاعدم اگر خوب فکر کنیم، می‌توانیم تفاوت واقعی بسازیم. در همان لحظه تصمیم می‌گیرم به Erik زنگ بزنم.

«سلام؟» صدایش را می‌شنوم.

«سلام، Bill است. چند دقیقه وقت داری؟ چند سؤال دربارهٔ توقف پروژه دارم.» مکث می‌کنم و اضافه می‌کنم: «یا بهتر بگویم، بعد از برداشتن توقف پروژه چه می‌شود.»

«خب، وقتش بود. می‌گفتم کی می‌فهمی یک مشکل بزرگ و جدید داری.»

سریع او را از خبر Kirsten باخبر می‌کنم. مشکلاتی را که هنگام بررسی پروژهٔ پایش و نحوهٔ محافظت از کار در سامانه به آن برخورده‌ایم outline می‌کنم.

«بد نیست، junior!» Erik می‌گوید. «واضح است بحثمان دربارهٔ constraints را به عمل آورده‌ای و همهٔ کاری که می‌توانی می‌کنی constraint را از unplanned work محافظت کنی. سؤالات خیلی مهمی دربارهٔ First Way و مدیریت جریان planned work می‌پرسی. تا وقتی نتوانی آن را انجام دهی، واقعاً نمی‌توانی خیلی چیز را مدیریت کنی، درست است؟

«گیج شدی چون می‌فهمی نمی‌دانی کار واقعاً چطور انجام می‌شود،» ادامه می‌دهد.

آه ناراحت را فرو می‌برم.

«فکر می‌کنم وقت سفر دیگری به MRP-8 است. چقدر زود می‌توانی برسی؟» می‌پرسد.

غافلگیر می‌شوم: «تو اینجایی؟»

«آره،» می‌گوید. «امروز بعدازظهر جلسه‌ای با auditors و finance guys هست که به هیچ قیمتی از دست نمی‌دهم. حتماً باش. قرار است سر John بیفتد.»

می‌گویم پانزده دقیقه دیگر در MRP-8 می‌توانم باشم.

---

Erik وسط لابی منتظر من است.

دو بار نگاه می‌کنم. یک T-shirt رنگ‌رفته و یک hooded sweatshirt زیپ‌دار با لوگوی union رنگ‌رفته پوشیده. badge مهمان را دارد و بی‌قرار با پایش ضربه می‌زند.

«تا توانستم سریع آمدم،» می‌گویم.

Erik فقط غر می‌زند و اشاره می‌کند دنبالش بروم. باز از پله‌ها بالا می‌رویم و روی catwalk بالای plant floor می‌ایستیم.

«پس بگو چه می‌بینی،» می‌گوید و به plant floor اشاره می‌کند.

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

Erik با تأیید سر تکان می‌دهد. «خوب. و وسطش؟»

به صحنه نگاه می‌کنم. بخشی از من احمق احساس می‌کند، می‌ترسم مثل Karate Kid که Mr. Miyagi از او سؤال می‌پرسد. اما خودم این جلسه را خواسته‌ام، پس شروع می‌کنم حرف زدن. «مواد و work in process می‌بینم که از چپ به راست جریان دارد — اما البته خیلی آهسته حرکت می‌کند.»

Erik از catwalk نگاه می‌کند و می‌گوید: «آه، واقعاً؟ مثل یک رودخانه؟»

به من برمی‌گردد و با نفرت سر تکان می‌دهد: «فکر می‌کنی این کلاس شعرخوانی است؟ ناگهان WIP مثل آب روی سنگ‌های صاف می‌رود؟ جدی باش. یک plant manager چطور جواب می‌دهد؟ کار از کجا به کجا می‌رود و چرا؟»

دوباره امتحان می‌کنم: «باشد، باشد. WIP از work center به work center می‌رود، همان‌طور که bill of materials و routings تعیین می‌کند. و همهٔ آن در job order است که آنجا release شده.»

«بهتر شد،» Erik می‌گوید. «و می‌توانی work centerهایی را پیدا کنی که constraints کارخانه هستند؟»

می‌دانم Erik در آن سفر عجیب اول به این کارخانه گفته بود.

«heat treat ovenها و paint curing boothها،» ناگهان می‌گویم.

«آنجا،» می‌گویم بعد از scan کردن plant floor و بالاخره دیدن مجموعه‌ای ماشین‌های بزرگ کنار دیوار دور. «و آنجا،» می‌گویم و به اتاق‌های بزرگ با تابلوهای «Paint Booth #30-a» و «Paint Booth #30-b» اشاره می‌کنم.

«خوب. فهمیدن جریان کار کلید دستیابی به First Way است،» Erik می‌گوید و سر تکان می‌دهد. جدی‌تر می‌پرسد: «پس حالا دوباره بگو کدام work centerها را constraint سازمانت تشخیص داده‌ای؟»

لبخند می‌زنم و راحت جواب می‌دهم: «Brent. قبلاً درباره‌اش حرف زده بودیم.»

تحقیرآمیز ادا درمی‌آورد و دوباره به plant floor نگاه می‌کند.

«چی؟» تقریباً فریاد می‌زنم. «چطور Brent نباشد؟ حتی وقتی چند هفته پیش گفتم Brent است تبریک گفتی!»

«ناگهان Brent یک heat treat oven رباتیک است؟ داری می‌گویی معادل آن paint curing booth پایین Brent است؟» با تمسخر می‌گوید. «می‌دانی، شاید احمقانه‌ترین چیزی باشد که شنیده‌ام.»

ادامه می‌دهد: «پس دو مدیرت، Chester و Penelope، کجا می‌مانند؟ حدس بزنم. شاید معادل آن drill press station و stamping machine آنجا باشند؟ یا شاید آن metal grinder؟»

Erik جدی به من نگاه می‌کند: «جدی باش. پرسیدم کدام work centerها constraintهای شما هستند. فکر کن.»

کاملاً گیج، دوباره به plant floor نگاه می‌کنم.

می‌دانم بخشی از جواب Brent است. اما وقتی با اطمینان blurt کردم، Erik تقریباً سرم زد. باز.

Erik عصبانی به نظر می‌رسد که یک آدم واقعی نام بردم و Brent را مثل یک تجهیزات جا زدم.

دوباره به heat treat oven نگاه می‌کنم. و بعد می‌بینمشان. دو نفر با overall، hard hat و goggles. یکی جلوی computer screen چیزی وارد می‌کند، دیگری توده‌ای قطعه روی loading pallet را با handheld computer اسکن می‌کند.

«آه،» با صدای بلند فکر می‌کنم. «heat treat oven یک work center است که workerهایی به آن وابسته‌اند. پرسیدی کدام work centerها constraintهای ماست و گفتم Brent، که نمی‌تواند درست باشد، چون Brent work center نیست.

«Brent worker است، نه work center،» دوباره می‌گویم. «و شرط می‌بندم Brent worker است که از work centerهای خیلی زیادی پشتیبانی می‌کند. به همین خاطر constraint است.»

«حالا داریم جایی می‌رویم!» Erik می‌گوید و لبخند می‌زند. با اشارهٔ گسترده به plant floor پایین می‌گوید: «تصور کن بیست و پنج درصد همهٔ work centerهای آنجا فقط توسط یک نفر به نام Brent قابل بهره‌برداری باشد. به جریان کار چه می‌شد؟»

چشم‌ها را می‌بندم تا فکر کنم.

«کار به‌موقع تمام نمی‌شد، چون Brent فقط می‌تواند در یک work center باشد،» می‌گويم. با اشتیاق ادامه می‌دهم: «دقیقاً همان چیزی است که با ما می‌شود. می‌دانم برای bunchی از planned changeهایمان، کار حتی نمی‌تواند شروع شود اگر Brent آنجا نباشد. وقتی این اتفاق می‌افتد، به Brent escalate می‌کنیم و می‌گوییم هر کاری می‌کند رها کند تا work center دیگری راه بیفتد. خوش‌شانس می‌شویم اگر آن‌قدر بماند تا change کاملاً implement شود قبل از اینکه کس دیگری interrupt کند.»

«دقیقاً!» می‌گوید.

کمی ناراحت از احساس گرم تأییدی که در پاسخ حس می‌کنم.

«البته،» ادامه می‌دهد، «هر work center از چهار چیز ساخته شده: machine، man، method و measures. فرض کن برای machine، heat treat oven را انتخاب کنیم. men همان دو نفری‌اند که steps از پیش تعریف‌شده را اجرا می‌کنند، و obviously به measures بر اساس نتایج اجرای steps در method نیاز داریم.»

اخم می‌کنم. این اصطلاحات کارخانه‌ای از سال‌های MBA کمی آشنا هستند. اما هرگز فکر نمی‌کردم در domain IT مرتبط باشند.

به دنبال جایی برای یادداشت، می‌فهمم clipboard را در ماشین گذاشته‌ام. جیب‌ها را می‌گردم و یک index card کوچک چروک در جیب عقب پیدا می‌کنم.

عجولانه می‌نویسم: «Work center: machine, man, method, measure.»

Erik ادامه می‌دهد: «البته، در این plant floor یک‌چهارم work centerها وابسته به یک نفر نیست. این absurd است. متأسفانه برای شما هست. به همین خاطر وقتی Brent مرخصی می‌رود، all sorts of work فقط متوقف می‌شود، چون فقط Brent می‌داند چطور certain steps را تمام کند — steps که احتمالاً فقط Brent می‌دانست وجود دارند، درست است؟»

سر تکان می‌دهم و نمی‌توانم groan را مهار کنم. «حق با توست. شنیده‌ام مدیرانم شکایت می‌کنند اگر Brent proverbial bus بخورد، کاملاً up the creek می‌رویم. کسی نمی‌داند چه چیزی در سر Brent است. که یکی از دلایلی است که level 3 escalation pool ساختم.»

سریع توضیح می‌دهم چه کردم تا escalation به Brent در outageها جلوگیری شود و interrupt نشود با unplanned work و چطور سعی کردم همین را برای planned changeها انجام دهم.

«خوب،» می‌گوید. «داری کار Brent را standardize می‌کنی تا دیگران بتوانند اجرا کنند. و چون بالاخره آن steps را document می‌کنی، می‌توانی سطحی از consistency و quality هم enforce کنی. نه‌تنها تعداد work centerهایی که Brent لازم است کم می‌کنی، documentation می‌سازی که بعضی را automate کنی.»

ادامه می‌دهد: «اتفاقاً، تا این کار را نکنی، هر چند Brent دیگر هم استخدام کنی، Brent همیشه constraint می‌ماند. هر کسی استخدام کنی فقط دور می‌ایستد.»

با فهم سر تکان می‌دهم. دقیقاً همان‌طور Wes توصیف کرد. با وجود headcount اضافه برای استخدام Brentهای بیشتر، هرگز واقعاً throughput را افزایش ندادیم.

ناگهان حس exhilaration می‌گیرم وقتی قطعات در سرم جا می‌افتند. بعضی intuitions عمیقم را تأیید می‌کند و underpinning theory برای باورم می‌دهد.

شادی‌ام کوتاه است. با نارضایتی مرا از بالا به پایین نگاه می‌کند: «داری دربارهٔ برداشتن توقف پروژه می‌پرسی. مشکلت این است که دو چیز را قاطی می‌کنی. تا در ذهنت جدا نکنی، فقط دور خودت می‌چرخی.»

شروع به راه رفتن می‌کند و من عجله می‌کنم دنبالش بروم. زود وسط plant floor ایستاده‌ایم.

«آن work center را می‌بینی، با چراغ زرد چشمک‌زن؟» می‌پرسد و اشاره می‌کند.

وقتی سر تکان می‌دهم می‌گوید: «بگو چه می‌بینی.»

فکر می‌کنم چه لازم است تا با او مکالمهٔ عادی داشته باشم و دوباره نقش trainee احمق را بازی می‌کنم. «به نظر می‌رسد یک piece of machinery down است — حدس می‌زنم چراغ چشمک‌زن همین را نشان می‌دهد. پنج نفر کنار جمع شده‌اند، از جمله دو نفر که شبیه manager به نظر می‌رسند. همه نگران‌اند. سه نفر دیگر خم شده‌اند و به چیزی که حدس می‌زنم machine inspection panel است نگاه می‌کنند. flashlight دارند و — آره — screwdriver هم — قطعاً machine down…»

«حدس خوب،» می‌گوید. «احتمالاً یک computerized grinder out of commission است و maintenance team دارد آن را online برمی‌گرداند. اگر هر piece of equipment آنجا برای repair به Brent نیاز داشت چه می‌شد؟»

می‌خندم. «هر outage فوراً به Brent escalate می‌شد.»

«بله.» ادامه می‌دهد: «با اولین سؤالت شروع کنیم. کدام پروژه‌ها برای release وقتی توقف پروژه برداشته شود امن‌اند؟ با دانستن اینکه کار چطور از certain work centerها جریان می‌یابد و بعضی work centerها Brent می‌خواهند و بعضی نه، فکر می‌کنی جواب چیست؟»

آهسته آنچه Erik گفت را تکرار می‌کنم و سعی می‌کنم جواب را بچسبانم.

«فهمیدم،» می‌گويم و لبخند می‌زنم. «پروژه‌های candidate که release امن‌اند آن‌هایی‌اند که Brent لازم ندارند.»

وقتی می‌گوید «Bingo. خیلی ساده، بله؟» لبخندم پهن‌تر می‌شود.

لبخندم وقتی implications را فکر می‌کنم ناپدید می‌شود. «صبر کن، چطور بدانم کدام پروژه‌ها Brent لازم ندارند؟ تا نیمهٔ کار هرگز فکر نمی‌کنیم واقعاً Brent لازم داریم!»

بلافاصله از پرسیدن پشیمان می‌شوم چون Erik به من glare می‌کند. «قرار است به همهٔ چیزهایی که خیلی disorganized هستی خودت بفهمی جواب بدهم؟»

«ببخشید. خودم figure out می‌کنم،» سریع می‌گويم. «می‌دانی، وقتی بالاخره همهٔ کاری که واقعاً Brent می‌خواهد را بدانیم خیلی relieved می‌شوم.»

«حتماً،» می‌گوید. «آنچه می‌سازی bill of materials همهٔ کاری است که در IT Operations انجام می‌دهید. اما به‌جای لیست parts و subassemblies مثل moldings، screws و casters، همهٔ prerequisites را catalog می‌کنی که قبل از complete کردن کار لازم است — مثل model number لپ‌تاپ، specifications اطلاعات کاربر، software و licenseهای لازم، configurations، version information، security و capacity و continuity requirements، yada yada…»

خودش را interrupt می‌کند و می‌گوید: «خب، دقیق‌تر بگویم، در واقع bill of resources می‌سازی. bill of materials به‌علاوهٔ لیست work centerهای لازم و routing. وقتی آن را داشته باشی، به‌علاوهٔ work orderها و resources، بالاخره می‌توانی capacity و demand را handle کنی. این چیزی است که بالاخره می‌فهمی آیا می‌توانی work جدید بپذیری و بعد واقعاً work را schedule کنی.»

شگفت‌انگیز. فکر می‌کنم تقریباً فهمیدم.

می‌خواهم چند سؤال بپرسم، اما Erik می‌گوید: «سؤال دومت این بود آیا شروع پروژهٔ پایش امن است. قبلاً establish کردی Brent لازم ندارد. علاوه بر آن می‌گویی هدف این پروژه جلوگیری از outage است، که escalation به Brent را جلوگیری می‌کند. بیش از آن، وقتی outage رخ می‌دهد، کمتر از وقت Brent برای troubleshoot و fix لازم است. قبلاً constraint را identify کرده‌ای، exploit کرده‌ای تا بیشترین را از آن بگیری، و بعد flow of work را به constraint subordinate کرده‌ای. پس این پروژهٔ پایش چقدر مهم است؟»

لحظه‌ای فکر می‌کنم. و بعد از جواب obvious groan می‌کنم.

انگشتانم را در موهایم می‌کشم. «گفتی همیشه باید دنبال راه‌های elevate کردن constraint باشیم، یعنی باید هر کاری لازم است برای cycles بیشتر از Brent انجام دهم. دقیقاً همان کاری است که پروژهٔ پایش می‌کند!»

با کمی disbelief که قبلاً ندیدم می‌گویم: «پروژهٔ پایش احتمالاً مهم‌ترین improvement project ماست — باید فوراً شروعش کنیم.»

«دقیقاً،» Erik می‌گوید. «Properly elevating preventive work در قلب برنامه‌هایی مثل Total Productive Maintenance است که Lean Community پذیرفته. TPM اصرار می‌کند هر کاری لازم است برای اطمینان از machine availability با elevate کردن maintenance انجام دهیم. یکی از senseiهایم می‌گفت: «Improving daily work is even more important than doing daily work.» Third Way همهٔ آن است که مطمئن شویم continually tension در سامانه می‌گذاریم تا continually habits را reinforce کنیم و چیزی را improve کنیم. Resilience engineering می‌گوید باید routinely fault در سامانه inject کنیم، frequently، تا کمتر painful شوند.

«Mike Rother می‌گوید تقریباً مهم نیست چه چیزی improve می‌کنی، تا وقتی چیزی improve می‌کنی. چرا؟ چون اگر improve نکنی، entropy تضمین می‌کند واقعاً بدتر می‌شوی، که تضمین می‌کند مسیری به zero errors، zero work-related accidents و zero loss نیست.»

ناگهان آن‌قدر obvious و evident است. احساس می‌کنم باید فوراً به Patty زنگ بزنم بگویم پروژهٔ پایش را فوراً شروع کند.

Erik ادامه می‌دهد: «Rother به این Improvement Kata می‌گوید،» ادامه می‌دهد. «کلمهٔ kata را به کار برد چون فهمید repetition habit می‌سازد و habitها mastery را enable می‌کنند. چه دربارهٔ sports training، یادگیری ساز موسیقی یا training در Special Forces حرف بزنی، چیزی بیش از practice و drills به mastery نیست. studies نشان داده five minutes daily practice بهتر از یک بار در هفته three hours است. و اگر می‌خواهی genuine culture of improvement بسازی، باید آن habitها را بسازی.»

دوباره به plant floor برمی‌گردد و ادامه می‌دهد: «قبل از رفتن، توجهت را از work centerها به همهٔ فضای بین work centerها ببر. به‌اندازهٔ throttle کردن release of work، مدیریت handoffها مهم است. wait time برای یک resource given، درصد busy بودن آن resource تقسیم بر درصد idle بودنش است. پس اگر resource پنجاه درصد utilized باشد، wait time 50/50 یا 1 unit است. اگر resource نود درصد utilized باشد، wait time 90/10 یا نه برابر طولانی‌تر. و اگر resource نود و نه درصد utilized باشد؟»

اگرچه relevance را کاملاً نمی‌فهمم، در ذهن حساب می‌کنم: 99/1. می‌گویم: «نود و نه.»

«درست،» می‌گوید. «وقتی resource نود و نه درصد utilized است، باید نود و نه برابر بیشتر از وقتی که پنجاه درصد utilized است صبر کنی.»

با اشارهٔ گسترده می‌گوید: «بخش بحرانی Second Way visible کردن wait timeهاست تا بدانی وقتی کار روزها در queue کسی می‌نشیند — یا بدتر، وقتی کار باید backward برود چون همهٔ parts را ندارد یا rework می‌خواهد.

«به یاد داشته باش هدف ما maximize کردن flow است. اینجا در MRP-8 سال‌ها پیش وضعیتی داشتیم که certain components هرگز به موقع در final assembly نمی‌رسید. چون resource کافی نداشتیم یا چون certain tasks خیلی طول می‌کشید؟

«نه! وقتی واقعاً parts را در plant floor دنبال کردیم، فهمیدیم برای اکثر وقت، parts فقط در queueها می‌نشست. یعنی touch time کسری کوچکی از total process time بود. expediterها باید در کوه کار جستجو می‌کردند parts را پیدا کنند و از work center عبور دهند،» با تعجب می‌گوید.

«این در plant شما هم می‌شود، پس مراقب باش،» می‌گوید.

سر تکان می‌دهم و می‌گويم: «Erik، هنوز روی release کردن پروژهٔ پایش گیر کرده‌ام. مردم همیشه اصرار می‌کنند پروژهٔ خاصشان urgent است و باید به قیمت همهٔ چیز دیگر کار شود. همهٔ urgent audit و security remediation projectهایی که John برایشان فریاد می‌زند کجا جا می‌گیرند؟»

Erik با دقت به صورتم نگاه می‌کند و بالاخره می‌گوید: «یک کلمه از آنچه دو هفتهٔ گذشته گفته‌ام شنیدی؟»

به ساعتش نگاه می‌کند و می‌گوید: «باید بروم.»

غافلگیر، تماشایش می‌کنم که سریع به خروجی catwalk می‌رود. باید بدوم تا برسم. آدم درشت است، احتمالاً کمی بیش از پنجاه سال. با وجود چند kilo اضافه، سریع حرکت می‌کند.

وقتی می‌رسم می‌گویم: «صبر کن. داری می‌گویی audit issueها آن‌قدر مهم نیستند که fix شوند؟»

«هرگز این را نگفتم،» می‌گوید، در جایش می‌ایستد و برمی‌گردد رو به من. «چیزی را screw up کنی که ability کسب‌وکار برای maintain کردن compliance با قوانین و regulations مرتبط را به خطر بیندازد؟ بهتر fix کنی — یا باید fired شوی.»

برمی‌گردد و دوباره قدم برمی‌دارد و از روی شانه می‌گوید: «بگو. همهٔ projectهایی که Jimmy، CISOت، push می‌کند. flow of project work از IT organization را increase می‌کنند؟»

«نه،» سریع جواب می‌دهم و دوباره می‌دوم.

«operational stability را increase می‌کنند یا time لازم برای detect و recover از outage یا security breach را decrease؟»

کمی بیشتر فکر می‌کنم. «احتمالاً نه. much of it فقط busywork بیشتر است، و در most cases کاری که می‌خواهند risky است و واقعاً می‌تواند outage ایجاد کند.»

«این projectها capacity Brent را increase می‌کنند؟»

بی‌مزه می‌خندم. «نه، برعکس. فقط audit issueها می‌توانند Brent را برای سال آینده tie up کنند.»

«و انجام همهٔ projectهای Jimmy به WIP levels چه می‌کند؟» می‌پرسد و در را باز می‌کند که به stairwell برمی‌گردد.

با exasperation می‌گویم وقتی دو پله را پایین می‌رویم: «از سقف بالا می‌رود. باز.»

وقتی به پایین می‌رسیم، Erik ناگهان می‌ایستد و می‌پرسد: «باشد. این projectهای security throughput پروژه‌ات را decrease می‌کنند، که constraint کل کسب‌وکار است. و most constrained resource سازمانت را swamp می‌کنند. و squat برای scalability، availability، survivability، sustainability، security، supportability یا defensibility سازمان نمی‌کنند.»

با صورت poker می‌پرسد: «پس، genius: projectهای Jimmy به نظرت use of time خوبی می‌آیند؟»

وقتی شروع به جواب می‌کنم، فقط در exit را باز می‌کند و از آن رد می‌شود.

ظاهراً rhetorical بود.