สามวันต่อมา ผมอยู่ที่โต๊ะทำงาน พยายามอ่านรายงานความคืบหน้าของ Phoenix จาก Kirsten บน laptop ของผม ในขณะที่มันส่งเสียงครางฮือและทำงานอย่างอืดอาด ผมก็สงสัยว่ามันผ่านไปกี่สัปดาห์แล้วนะตั้งแต่ security patch ของ John ทำเครื่องผมพังจนกลายเป็นที่ทับกระดาษ (bricked)
การจะได้ laptop เครื่องใหม่มาทดแทนนี่เหมือนการถูกลอตเตอรี่เลย มันน่าดึงดูดใจที่จะติดสินบนพนักงาน service desk สักคน เหมือนที่ผู้จัดการฝ่าย Marketing คนหนึ่งแนะนำ แต่ผมปฏิเสธที่จะแซงคิว ผมต้องเล่นตามกฎในเมื่อผมเป็นคนสร้างและบังคับใช้กฎเหล่านั้น ผมจดโน้ตไว้ว่าจะคุยกับ Patty เกี่ยวกับความจำเป็นเร่งด่วนในการลดระยะเวลารอคอย (lead time) สำหรับการเปลี่ยน laptop เหล่านี้
ในที่สุด e-mail ก็เด้งขึ้นมา:
จาก: Kirsten Fingle
ถึง: Steve Masters
สำเนา: Bill Palmer, Chris Allers, Sarah Moulton
วันที่: 26 กันยายน, 10:33 น.
หัวข้อ: Great news on project front!
Steve
ในที่สุดพวกเราก็มีความคืบหน้าแล้ว การสั่งระงับโครงการ (project freeze) และการที่ IT หันมาโฟกัสที่ Phoenix ส่งผลให้ปัญหาที่เคยติดขัด (logjam) คลี่คลายลง เราทำผลงานได้ในเจ็ดวันที่ผ่านมามากกว่าที่เรามักจะทำได้ในทั้งเดือนเสียอีก
ขอยกความดีความชอบให้ทุกคนในทีมครับ!
หมายเหตุเพิ่มเติม: เจ้าของโครงการ (project sponsor) หลายคนรู้สึกหงุดหงิดมากที่โครงการของพวกเขาถูกระงับ โดยเฉพาะอย่างยิ่ง Sarah Moulton ที่เชื่อว่าโครงการของเธอได้รับยกเว้นจากการระงับครั้งนี้ ฉันเลยแนะนำให้เธอไปคุยกับคุณเอง
สิ่งที่แนบมาด้วยคือรายงานสถานะอย่างเป็นทางการ หากคุณมีคำถามใดๆ โปรดแจ้งให้ทราบ
Kirsten
แม้ว่าข้อความที่ว่า Sarah กำลังก่อเรื่องอีกครั้งจะทำให้ผมขบเขี้ยวเคี้ยวฟัน แต่นี่ถือเป็นข่าวที่ยอดเยี่ยมที่สุดจริงๆ
พวกเราคาดหวังผลลัพธ์แบบนี้อยู่แล้ว แต่ข่าวดีก็ยังเป็นสิ่งที่น่ายินดีเสมอ โดยเฉพาะอย่างยิ่งหลังจากสิ่งที่เกิดขึ้นเมื่อช่วงต้นสัปดาห์ เราเจอกับอุปสรรคครั้งใหญ่จากเหตุการณ์ Sev 1 ที่ทำให้ระบบโทรศัพท์ภายในและระบบ voicemail ทั้งหมดล่ม ซึ่งทำให้ฝ่ายขาย (Sales) และฝ่ายผลิต (Manufacturing) ต้องหยุดชะงักในวันสุดท้ายของไตรมาส
หลังจากระบบล่มไปได้สองชั่วโมง เราก็พบว่ามันเกิดจากหนึ่งใน vendor ด้าน networking ของเราที่เผลอไปทำการเปลี่ยนค่า (change) ในระบบโทรศัพท์ที่เป็น production แทนที่จะเป็นเครื่องสำรอง (hot spare)
เหตุการณ์ระบบล่มครั้งนี้จะกระทบต่อรายได้ประจำไตรมาสของเรา แต่เรายังไม่รู้ว่ามากน้อยแค่ไหน เพื่อป้องกันไม่ให้เรื่องนี้เกิดขึ้นอีก เรากำลังจัดทำโครงการเพื่อมอนิเตอร์ระบบที่สำคัญของเราสำหรับการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต (unauthorized changes)
โครงการมอนิเตอร์นี้เองคือสิ่งที่ Wes, Patty และ John กำลังคุยกันอยู่ โดยล้อมวงกันที่โต๊ะประชุมของ Patty
ผมพูดว่า “ขอโทษที่ขัดจังหวะนะ แต่ผมอยากจะบอกข่าวดีหน่อย” ผมแสดง e-mail ของ Kirsten ให้พวกเขาดู
Wes เอนหลังพิงเก้าอี้แล้วพูดว่า “เอาละ นี่เป็นการยืนยันอย่างเป็นทางการแล้วนะ ว่าการสั่งระงับโครงการของคุณมันได้ผลจริงๆ”
Patty มองไปที่เขาพลางทำท่าประหลาดใจ “คุณเคยสงสัยด้วยเหรอ? ไม่เอาน่ะ เราทั้งคู่ต่างก็คุยกันอยู่ว่าไม่เคยเห็นผู้คนมีสมาธิจดจ่อขนาดนี้มาก่อนเลย มันน่าทึ่งมากที่การระงับโครงการช่วยลดความขัดแย้งเรื่องลำดับความสำคัญและการทำ multitasking แย่ๆ ลงได้ เราต่างรู้ดีว่ามันทำให้ผลิตภาพ (productivity) เพิ่มขึ้นมหาศาล”
Wes ยักไหล่แล้วยิ้ม “จนกว่า Kirsten จะให้เครดิตเราล่ะนะ ไม่งั้นมันก็แค่สิ่งที่เราคิดไปเอง”
เขาก็มีประเด็นนะ มันรู้สึกดีจริงๆ ที่ Kirsten ยอมรับในความกืบหน้าที่เรากำลังทำอยู่
“จะว่าไป” Patty พูดเสริม “เธอไม่ได้ล้อเล่นนะเรื่องที่พวกผู้จัดการฝั่งธุรกิจกำลังสติแตก มี VP โทรหาฉันมากขึ้นเรื่อยๆ เพื่อขอยกเว้น (waiver) ให้โครงการโปรดของพวกเขา หรือไม่ก็ขอให้ช่วยทำงานให้แบบลับๆ (off the books) ไม่ใช่แค่ Sarah หรอก—เธอแค่เป็นคนที่แสดงออกและส่งเสียงดังที่สุดเท่านั้นเอง”
ผมขมวดคิ้ว “โอ้ นั่นเป็นส่วนหนึ่งของงานเราและเราก็คาดไว้อยู่แล้ว แต่ผมไม่อยากให้ความกดดันแบบนี้ส่งไปถึงคนของเรา Wes?”
“ผมบอกทุกคนในทีมแล้วว่าถ้ามีใครบ่นอะไรให้ส่งเรื่องมาที่ผม และเชื่อเถอะ ผมโทรกลับไปหาพวกเขาทุกคนและด่ากลับไปชุดใหญ่เลยล่ะ” เขาตอบ
Patty พูดว่า “ฉันเริ่มกังวลแล้วว่าเราจะทำยังไงหลังจากยกเลิกการระงับโครงการ มันจะไม่เหมือนกับการเปิดเขื่อนให้น้ำทะลักออกมาเหรอ?”
อีกครั้งที่เธอชี้ให้เห็นถึงประเด็นสำคัญ ผมพูดว่า “เดี๋ยวผมจะโทรหา Erik แต่ก่อนจะโทร ปัจจุบันเราจัดลำดับความสำคัญของงานกันอย่างไร? เมื่อเรารับปากจะทำงานโครงการ งาน change งาน service request หรืออย่างอื่น เราตัดสินใจอย่างไรว่าจะทำอันไหนในเวลาใดเวลาหนึ่ง? จะเกิดอะไรขึ้นถ้ามีลำดับความสำคัญที่ขัดแย้งกัน?”
“เรื่องนั้นมันเกิดขึ้นทุกวี่ทุกวันอยู่แล้ว!” Wes พูดพลางทำท่าไม่เชื่อหู “นั่นแหละคือความเจ๋งของการระงับทุกโครงการยกเว้นโครงการเดียว ไม่มีใครต้องมานั่งตัดสินใจว่าจะทำงานอะไร และไม่อนุญาตให้ทำ multitasking ด้วย”
“นั่นไม่ใช่คำถามของผม” ผมพูด “เมื่อเรามีงานหลายสายที่ดำเนินไปพร้อมๆ กัน ใครตัดสินใจว่างานไหนต้องทำในเวลาใดเวลาหนึ่ง?”
“ก็...” Wes ตอบ “เราไว้ใจให้พวกเขาตัดสินใจเลือกสิ่งที่ถูกต้องตามข้อมูลที่มีอยู่ นั่นคือเหตุผลที่เราจ้างคนฉลาดๆ มาทำงานไง”
นี่เริ่มไม่ดีละ
ผมระลึกถึงตอนที่ใช้เวลา 20 นาทีเฝ้าสังเกต Brent ก่อนที่จะมีการระงับโครงการ แล้วถามว่า “แล้วคนฉลาดๆ ของเราใช้ข้อมูลอะไรในการตัดสินใจจัดลำดับความสำคัญล่ะ?”
Wes พูดอย่างปกป้องตัวเอง “เราทุกคนก็พยายามสับหลีก (juggle) ลำดับความสำคัญที่ขัดแย้งกันให้ดีที่สุดเท่าที่จะทำได้ นั่นแหละคือชีวิตจริงใช่ไหมล่ะ? ลำดับความสำคัญมันเปลี่ยนกันได้”
“พูดกันตรงๆ เถอะ” Patty แทรกขึ้น “ลำดับความสำคัญที่ 1 ก็คือใครก็ตามที่ตะโกนดังที่สุด โดยมีกติกาตัดสินตอนเสมอกันคือใครที่สามารถดึงผู้บริหารระดับสูงมาช่วยกดดันได้มากที่สุด ยกเว้นพวกที่ใช้วิธีแนบเนียนกว่านั้น ฉันเคยเห็นพนักงานของฉันหลายคนให้ความสำคัญกับคำขอของผู้จัดการคนหนึ่งเสมอ เพราะเขามักจะพาพวกเขาไปเลี้ยงข้าวกลางวันเดือนละครั้ง”
โอ้ เยี่ยมเลย นอกจากจะมีวิศวกรบางคนที่ถูกข่มขู่แล้ว ผมยังมีวิศวกรคนอื่นๆ ที่ทำตัวเหมือนสิบโท Max Klinger จากเรื่อง M*A*S*H ที่แอบรันตลาดมืดสำหรับงาน IT ของตัวเองอีกด้วย
“ถ้าเรื่องนี้เป็นจริง เราก็ไม่มีทางยกเลิกการระงับโครงการได้เลย พวกคุณไม่เห็นเหรอว่าเราไม่มีวิธีปล่อยงาน (releasing work) เข้าสู่ IT โดยที่จะมั่นใจได้ว่ามันจะถูกทำจริงๆ?”
ผมพยายามสะกดน้ำเสียงไม่ให้ดูสิ้นหวัง แล้วพูดว่า “Patty พูดถูก เรามีเรื่องต้องคิดอีกมากก่อนที่การระงับโครงการจะสิ้นสุดลง ซึ่งก็คือในอีกหนึ่งสัปดาห์พอดี”
ผมตัดสินใจออกไปเดินเล่นข้างนอกครู่หนึ่ง ผมมีเวลา 30 นาทีก่อนการประชุมครั้งต่อไป และผมต้องการเวลาใช้ความคิด
ผมรู้สึกกระสับกระส่ายมากกว่าที่เคย เมื่อเรามีโครงการมากกว่าหนึ่งโครงการในระบบในเวลาเดียวกัน เราจะปกป้องงานไม่ให้ถูกขัดจังหวะหรือถูกแย่งลำดับความสำคัญโดยใครบางคนในฝั่งธุรกิจหรือคนอื่นใน IT ได้อย่างไร?
แสงแดดสาดส่องลงมาที่ผม ตอนนี้เป็นเวลา 11.00 น. และอากาศมีกลิ่นอายของฤดูใบไม้ร่วง ใบไม้บนต้นไม้เริ่มเปลี่ยนเป็นสีส้มและสีน้ำตาล และเริ่มมีกองใบไม้ทับถมกันในที่จอดรถ
แม้จะมีความกังวล แต่ผมก็ตระหนักได้ว่ามันรู้สึกสดชื่นแค่ไหนที่ได้มีโอกาสคิดว่าเราควรทำงานอะไร และจะจัดลำดับความสำคัญและปล่อยงานออกมาอย่างไร ชั่วขณะหนึ่ง ผมรู้สึกทึ่งที่ตัวเองไม่ต้องคอยดับไฟตลอดเวลาเหมือนที่เคยเป็นมาเกือบตลอดอาชีพการงานในสาย IT
ประเภทของปัญหาที่เราต้องแก้ไขในช่วงนี้มันดู... ต้องใช้ความคิด (cerebral) มาก
นี่คือสิ่งที่ผมเคยคิดว่าการบริหารจัดการควรจะเป็นตอนที่ผมเรียน MBA
ผมมั่นใจว่าถ้าเราใช้ความคิดให้ดี เราจะสามารถสร้างความเปลี่ยนแปลงที่แท้จริงได้ ในตอนนั้นเอง ผมตัดสินใจโทรหา Erik
“ฮัลโหล?” ผมได้ยินเสียงเขา
“สวัสดีครับ ผม Bill นะ คุณมีเวลาคุยสักสองสามนาทีไหม? ผมมีคำถามเกี่ยวกับการระงับโครงการน่ะครับ” ผมหยุดเว้นวรรคแล้วเสริมว่า “หรือจะพูดให้ถูกคือ อะไรจะเกิดขึ้นหลังจากเรายกเลิกการระงับโครงการน่ะครับ”
“แหม ในที่สุดนะ ผมก็สงสัยอยู่ว่าเมื่อไหร่คุณจะรู้ตัวว่าคุณมีปัญหาใหญ่ครั้งใหม่รออยู่”
ผมรีบเล่าข่าวดีจาก Kirsten ให้เขาฟัง ผมสรุปปัญหาที่เราเจอในขณะที่กำลังพิจารณาโครงการมอนิเตอร์ และวิธีที่เราจะปกป้องงานในระบบ
“ไม่เลวนี่เจ้าหนู!” Erik พูด “คุณได้นำการสนทนาเรื่องจุดข้อจำกัด (constraint) ของเราไปปฏิบัติจริงอย่างเห็นได้ชัด และกำลังทำทุกอย่างที่ทำได้เพื่อปกป้องจุดข้อจำกัดนั้นจากการถูกงานที่ไม่ได้วางแผนไว้มากระทบ คุณกำลังถามคำถามที่สำคัญมากเกี่ยวกับแนวทางที่หนึ่ง (the First Way) และวิธีที่คุณจัดการกับการไหลของงานที่วางแผนไว้ จนกว่าคุณจะทำแบบนั้นได้ คุณก็บริหารจัดการอะไรไม่ได้จริงๆ หรอก ใช่ไหมล่ะ?
“คุณกำลังสับสนเพราะคุณเพิ่งตระหนักว่าคุณไม่รู้ว่าจริงๆ แล้วงานมันถูกขับเคลื่อนไปอย่างไร” เขาพูดต่อ
ผมพยายามสะกดอารมณ์ไม่ให้ถอนหายใจอย่างหงุดหงิดออกมา
“ผมว่าถึงเวลาต้องไปโรงงาน MRP-8 อีกรอบแล้วล่ะ คุณจะไปถึงที่นั่นได้เร็วแค่ไหน?” เขาถาม
ผมถามด้วยความประหลาดใจ “คุณอยู่ในเมืองเหรอครับ?”
“ใช่” เขาตอบ “บ่ายนี้มีการประชุมกับพวก auditor และพวกฝ่ายการเงินที่ผมจะไม่ยอมพลาดเด็ดขาด เตรียมตัวดูให้ดีเถอะ เรากำลังจะทำให้ John สติหลุดไปเลยล่ะ”
ผมบอกเขาว่าผมสามารถไปถึง MRP-8 ได้ภายในสิบห้านาที
Erik ยืนรอผมอยู่ที่กลางล็อบบี้
ผมถึงกับต้องมองซ้ำ (double take) เขาสวมเสื้อยืดสีซีดๆ และเสื้อแจ็คเก็ตมีฮู้ดแบบซิปที่มีโลโก้สหภาพแรงงานสีซีดๆ เขาติดป้ายผู้มาติดต่อเรียบร้อยแล้วและกำลังเคาะเท้าอย่างกระวนกระวาย
“ผมมาเร็วที่สุดเท่าที่จะทำได้แล้วครับ” ผมพูด
Erik แค่ส่งเสียงฮึดฮัดและทำท่าบอกให้ผมเดินตามเขาไป อีกครั้งที่เราเดินขึ้นบันไดและยืนอยู่บนทางเดินเหนือระดับพื้นโรงงาน (catwalk) พลางมองลงไปที่พื้นโรงงาน
“คราวนี้บอกผมสิว่าคุณเห็นอะไร” เขาพูดพลางผายมือไปที่พื้นโรงงาน
ผมมองลงไปอย่างงงๆ ไม่รู้ว่าเขาอยากได้ยินอะไร ผมจึงเริ่มพูดจากสิ่งที่เห็นชัดที่สุด “ก็เหมือนครั้งที่แล้วครับ ผมเห็นวัตถุดิบ (raw materials) เข้ามาจากท่าโหลดสินค้าด้านซ้าย และด้านขวาผมเห็นสินค้าสำเร็จรูป (finished goods) ออกไปจากท่าโหลดอีกฝั่ง”
Erik พยักหน้าอย่างเห็นด้วยแบบที่ผมประหลาดใจ “ดี แล้วระหว่างนั้นล่ะ?”
ผมมองลงไปที่ภาพตรงหน้า ส่วนหนึ่งในใจผมรู้สึกโง่เง่า กลัวว่าจะดูเหมือนเด็กฝึกคาราเต้ (Karate Kid) ที่ถูกคุณมิยากิ (Mr. Miyagi) ตั้งคำถาม แต่ในเมื่อผมเป็นคนขอคุยเอง ผมเลยเริ่มพูดต่อไป “ผมเห็นวัสดุและงานระหว่างทำ (WIP) ไหลจากซ้ายไปขวา—แต่เห็นได้ชัดว่ามันเคลื่อนที่ช้ามาก”
Erik มองลงมาจากทางเดินแล้วพูดว่า “อ้อ เหรอ? เหมือนสายน้ำอะไรแบบนั้นน่ะเหรอ?”
เขาหันมาหาผม ส่ายหัวด้วยความขยะแขยง “คุณคิดว่านี่คืออะไร ชั้นเรียนอ่านบทกวีหรือไง? จู่ๆ งานระหว่างทำ (WIP) ก็กลายเป็นเหมือนสายน้ำที่ไหลผ่านโขดหินเรียบๆ งั้นเหรอ? จริงจังหน่อยสิ ผู้จัดการโรงงานจะตอบคำถามนี้ว่ายังไง? งานเคลื่อนที่จากไหนไปไหน และทำไม?”
ผมพยายามอีกครั้ง “โอเคๆ งานระหว่างทำ (WIP) เคลื่อนที่จากศูนย์งาน (work center) หนึ่งไปยังอีกศูนย์งานหนึ่ง ตามที่กำหนดไว้ในรายการวัสดุ (bill of materials) และเส้นทางการผลิต (routings) และทั้งหมดนั่นอยู่ในใบสั่งงาน (job order) ซึ่งถูกปล่อยออกมาจากโต๊ะตรงนั้นครับ”
“ค่อยยังชั่วหน่อย” Erik พูด “แล้วคุณหาศูนย์งานที่เป็นจุดข้อจำกัด (constraint) ของโรงงานเจอไหม?”
ผมจำได้ว่า Erik เคยบอกผมตอนที่มาโรงงานนี้ครั้งแรกที่ดูแปลกๆ นั่น
“เตาอบชุบแข็ง (heat treat ovens) และตู้อบพ่นสี (paint curing booths) ครับ” ผมโพล่งออกมา
“นั่นไงครับ” ผมพูดหลังจากกวาดสายตาไปรอบๆ พื้นโรงงานและในที่สุดก็เห็นกลุ่มเครื่องจักรขนาดใหญ่ที่ผนังด้านไกล “และตรงนั้นด้วยครับ” ผมชี้ไปที่ห้องขนาดใหญ่ที่มีป้ายเขียนว่า “ตู้อบพ่นสี #30-a” และ “ตู้อบพ่นสี #30-b”
“ดีมาก การเข้าใจการไหลของงานคือกุญแจสำคัญในการบรรลุแนวทางที่หนึ่ง” Erik พูดพลางพยักหน้า จากนั้นเขาก็ถามด้วยเสียงที่เข้มขึ้น “ทีนี้ บอกผมอีกทีสิว่าในองค์กรของคุณ คุณกำหนดให้ศูนย์งานไหนเป็นจุดข้อจำกัด?”
ผมยิ้มและตอบอย่างมั่นใจ “Brent ไงครับ เราคุยเรื่องนี้กันไปแล้ว”
เขาพ่นจมูกใส่พลางหันกลับไปมองที่พื้นโรงงาน
“อะไรนะครับ?” ผมแทบจะตะโกน “จะไม่ใช่ Brent ได้ยังไง? คุณยังแสดงความยินดีกับผมอยู่เลยตอนที่ผมบอกคุณว่าเป็น Brent เมื่อสองสัปดาห์ก่อน!”
“จู่ๆ Brent ก็กลายเป็นเตาอบชุบแข็งหุ่นยนต์ไปแล้วงั้นเหรอ? คุณกำลังจะบอกผมว่าตู้อบพ่นสีนั่นน่ะเทียบเท่ากับ Brent งั้นสิ?” เขาพูดด้วยท่าทางประหลาดใจแบบล้อเลียน “รู้ไหม นั่นอาจจะเป็นสิ่งที่โง่ที่สุดเท่าที่ผมเคยได้ยินมาเลย”
เขาพูดต่อ “งั้นผู้จัดการของคุณสองคน Chester กับ Penelope จะไปอยู่ที่ไหนล่ะ? ให้ผมเดานะ บางทีพวกเขาอาจจะเทียบเท่ากับแท่นเจาะนั่น หรือไม่ก็เครื่องปั๊มนั่น? หรือบางทีอาจจะเป็นเครื่องเจียรโละนั่นก็ได้มั้ง?”
Erik มองผมอย่างจริงจัง “จริงจังหน่อยสิ ผมถามว่า ‘ศูนย์งาน’ (work center) ไหนคือจุดข้อจำกัดของคุณ ลองคิดดู”
ด้วยความสับสนอย่างสิ้นเชิง ผมมองกลับลงไปที่พื้นโรงงาน
ผมรู้ว่าส่วนหนึ่งของคำตอบคือ Brent แต่พอผมโพล่งออกมาอย่างมั่นใจ Erik ก็แทบจะตบหัวผมอีกรอบ
Erik ดูเหมือนจะหงุดหงิดที่ผมระบุชื่อคนจริงๆ แทนที่จะเป็นเครื่องจักร
ผมมองไปที่เตาอบชุบแข็งอีกครั้ง แล้วผมก็เห็นพวกเขา มีคนสองคนสวมชุดหมี หมวกนิรภัย และแว่นตานิรภัย คนหนึ่งอยู่หน้าจอคอมพิวเตอร์ กำลังป้อนข้อมูลบางอย่าง ในขณะที่อีกคนกำลังตรวจสอบกองชิ้นส่วนบนพาเลทขนส่ง และสแกนบางอย่างด้วยคอมพิวเตอร์พกพา
“อ้อ” ผมพูดพลางคิดดังๆ “เตาอบชุบแข็งคือศูนย์งาน (work center) ซึ่งมีพนักงานที่เกี่ยวข้องกับมัน คุณถามว่าศูนย์งานไหนคือจุดข้อจำกัดของเรา และผมบอกคุณว่าเป็น Brent ซึ่งมันไม่น่าจะถูก เพราะ Brent ไม่ใช่ศูนย์งาน
“Brent คือพนักงาน ไม่ใช่ศูนย์งาน” ผมพูดอีกครั้ง “และผมพนันได้เลยว่า Brent น่าจะเป็นพนักงานที่คอยซัพพอร์ตศูนย์งานมากเกินไป นั่นคือเหตุผลที่เขาเป็นจุดข้อจำกัด (constraint)”
“ในที่สุดก็เริ่มเข้าที่เข้าทางซะที!” Erik พูดพลางยิ้ม เขาผายมือไปกว้างๆ ที่พื้นโรงงานด้านล่างแล้วพูดว่า “ลองจินตนาการดูว่า ถ้าศูนย์งานยี่สิบห้าเปอร์เซ็นต์ข้างล่างนั่นสามารถดำเนินการได้โดยคนเพียงคนเดียวที่ชื่อ Brent จะเกิดอะไรขึ้นกับการไหลของงาน?”
ผมหลับตาใช้ความคิด
“งานก็จะเสร็จไม่ตรงเวลา เพราะ Brent สามารถอยู่ที่ศูนย์งานได้เพียงแห่งเดียวในเวลาเดียวกัน” ผมพูดต่อไปอย่างตื่นเต้น “นั่นแหละคือสิ่งที่เกิดขึ้นกับเราจริงๆ ผมรู้ว่าสำหรับงาน change ที่วางแผนไว้หลายๆ งาน งานจะไม่สามารถเริ่มได้เลยถ้า Brent ไม่อยู่ตรงนั้น เมื่อเป็นแบบนั้น เราก็จะส่งงานต่อให้ Brent บอกให้เขาทิ้งทุกอย่างที่กำลังทำอยู่ เพื่อให้ศูนย์งานอื่นสามารถเริ่มงานได้ เราจะโชคดีมากถ้าเขาสามารถอยู่ที่นั่นได้นานพอจนกว่างาน change จะเสร็จสมบูรณ์ก่อนที่จะถูกใครบางคนขัดจังหวะอีก”
“ถูกต้องเป๊ะ!” เขาพูด
ผมรู้สึกประหม่านิดหน่อยที่ได้รับคำชมของเขา
“เห็นได้ชัดว่า” เขาพูดต่อ “ทุกศูนย์งานประกอบด้วยสี่ส่วน คือ เครื่องจักร (machine), คน (man), วิธีการ (method) และการวัดผล (measures) สมมติว่าในส่วนของเครื่องจักร เราเลือกเตาอบชุบแข็ง ส่วนคนก็คือสองคนนั้นที่ต้องทำตามขั้นตอนที่กำหนดไว้ล่วงหน้า และแน่นอนว่าเราต้องการการวัดผลตามผลลัพธ์ของการทำตามขั้นตอนในวิธีการนั้น”
ผมขมวดคิ้ว คำศัพท์โรงงานเหล่านี้ดูคุ้นๆ หูอยู่บ้างตั้งแต่สมัยเรียน MBA แต่ผมไม่เคยคิดเลยว่ามันจะเกี่ยวข้องกับงานด้าน IT ได้
ด้วยความพยายามหาที่จด ผมนึกได้ว่าทิ้งคลิปบอร์ดไว้ในรถ ผมตบกระเป๋าตัวเองแล้วเจอกระดาษการ์ดดัชนียับๆ ในกระเป๋าหลัง
ผมรีบจดลงไปว่า “ศูนย์งาน (Work center): เครื่องจักร, คน, วิธีการ, การวัดผล”
Erik พูดต่อ “แน่นอนว่าในโรงงานนี้ คุณไม่มีทางให้หนึ่งในสี่ของศูนย์งานต้องขึ้นอยู่กับคนเพียงคนเดียวหรอก มันน่าตลกสิ้นดี แต่โชคร้ายสำหรับคุณที่คุณเป็นแบบนั้น นั่นคือเหตุผลที่เวลา Brent ลาพักร้อน งานทุกประเภทจะหยุดชะงักลง เพราะมีแต่ Brent เท่านั้นที่รู้ว่าต้องทำขั้นตอนบางอย่างอย่างไร—ขั้นตอนที่บางทีอาจจะมีแค่ Brent เท่านั้นที่รู้ว่ามันมีอยู่จริง ใช่ไหมล่ะ?”
ผมพยักหน้าพลางถอนหายใจ “คุณพูดถูก ผมเคยได้ยินผู้จัดการบ่นว่าถ้า Brent ถูกรถเมล์ทับ (hit by the bus) พวกเราคงจะแย่แน่ๆ ไม่มีใครรู้ว่าในหัวของ Brent มีอะไรอยู่ นั่นคือหนึ่งในเหตุผลที่ผมสร้างกลุ่มแก้ปัญหาลำดับที่ 3 (level 3 escalation pool) ขึ้นมา”
ผมรีบอธิบายสิ่งที่ผมทำเพื่อป้องกันไม่ให้มีการส่งงาน (escalate) ไปหา Brent ในช่วงที่ระบบล่ม เพื่อไม่ให้เขาถูกรบกวนด้วยงานที่ไม่ได้วางแผนไว้ และผมได้พยายามทำแบบเดียวกันนี้กับงาน change ที่วางแผนไว้ด้วย
“ดี” เขาพูด “คุณกำลังทำให้งานของ Brent กลายเป็นมาตรฐาน เพื่อให้คนอื่นสามารถทำแทนได้ และเนื่องจากในที่สุดคุณก็ได้จัดทำขั้นตอนเหล่านั้นเป็นเอกสาร (documentation) คุณจึงสามารถบังคับใช้ความสม่ำเสมอและคุณภาพได้ด้วย คุณไม่เพียงแต่ลดจำนวนศูนย์งานที่ต้องใช้ Brent เท่านั้น แต่คุณยังกำลังสร้างเอกสารที่จะช่วยให้คุณสามารถเปลี่ยนงานบางอย่างให้เป็นระบบอัตโนมัติ (automate) ได้อีกด้วย”
เขาพูดต่อ “จะว่าไป จนกว่าคุณจะทำแบบนี้ได้ ไม่ว่าคุณจะจ้างคนมาเพิ่มอีกกี่คนมาช่วยงาน Brent แต่ Brent ก็ยังจะเป็นจุดข้อจำกัดของคุณอยู่ดี ใครก็ตามที่คุณจ้างมาสุดท้ายก็จะแค่มายืนว่างงานอยู่เฉยๆ”
ผมพยักหน้าอย่างเข้าใจ นี่คือสิ่งที่ Wes เคยอธิบายไว้เป๊ะเลย แม้ว่าเขาจะได้รับอนุมัติให้จ้างคนเพิ่มเพื่อมาช่วยงาน Brent แต่เราก็ไม่เคยเพิ่มปริมาณงานที่ไหลผ่านระบบ (throughput) ได้จริงๆ เลย
ผมรู้สึกตื่นเต้นขึ้นมาทันทีเมื่อชิ้นส่วนต่างๆ เริ่มเข้าที่เข้าทางในหัวของผม เขาช่วยยืนยันสัญชาตญาณบางอย่างที่ผมเชื่อมาตลอด และให้ทฤษฎีมารองรับว่าทำไมผมถึงเชื่อแบบนั้น
ความตื่นเต้นของผมหายไปอย่างรวดเร็ว เขามองผมด้วยสายตาไม่พอใจ “คุณถามว่าจะยกเลิกการระงับโครงการได้อย่างไร ปัญหาของคุณคือคุณยังคงสับสนระหว่างสองสิ่ง จนกว่าคุณจะแยกมันออกจากกันได้ในหัว คุณก็จะแค่เดินวนเป็นวงกลมอยู่นั่นแหละ”
เขาเริ่มเดินและผมรีบเดินตามไป ในไม่ช้าเราก็มายืนอยู่กลางพื้นโรงงาน
“คุณเห็นศูนย์งานตรงนั้นไหม ที่มีไฟกระพริบสีเหลืองน่ะ?” เขาถามพลางชี้ไป
เมื่อผมพยักหน้า เขาพูดว่า “บอกผมสิว่าคุณเห็นอะไร”
ผมสงสัยว่าต้องทำยังไงถึงจะได้คุยกับเขาแบบคนปกติได้ ผมเลยกลับไปสวมบทบาทเด็กฝึกงานจอมบื้อเหมือนเดิม “ดูเหมือนเครื่องจักรบางชิ้นจะเสียครับ—ผมเดาว่านั่นคือสิ่งที่ไฟกระพริบบอก มีคนห้าคนรวมกลุ่มกันอยู่ข้างๆ รวมถึงคนที่ดูเหมือนจะเป็นผู้จัดการสองคนด้วย พวกเขาดูเป็นกังวลกันมาก มีอีกสามคนกำลังก้มๆ เงยๆ ดูสิ่งที่ผมเดาว่าน่าจะเป็นแผงตรวจสอบเครื่องจักร พวกเขามีไฟฉายและ—ใช่—พวกเขากำลังถือไขควงด้วย—แน่นอนว่าเครื่องจักรเสียแน่ๆ...”
“เดาเก่งนี่” เขาพูด “นั่นน่าจะเป็นเครื่องเจียรแบบคอมพิวเตอร์ที่ใช้งานไม่ได้ และทีมซ่อมบำรุงกำลังพยายามกู้คืนให้มันกลับมาใช้งานได้ จะเกิดอะไรขึ้นถ้าเครื่องจักรทุกชิ้นที่นั่นต้องรอให้ Brent มาซ่อมล่ะ?”
ผมหัวเราะ “ทุกเหตุการณ์ระบบล่มก็จะถูกส่งไปหา Brent ทันที”
“ใช่” เขาพูดต่อ “เรามาเริ่มที่คำถามแรกของคุณกัน โครงการไหนที่ปลอดภัยพอจะปล่อยออกมาได้เมื่อยกเลิกการระงับโครงการ? เมื่อรู้ว่างานไหลผ่านศูนย์งานบางแห่งอย่างไร และรู้ว่าบางศูนย์งานต้องใช้ Brent และบางศูนย์งานไม่ต้องใช้ คุณคิดว่าคำตอบคืออะไร?”
ผมทวนคำพูดที่ Erik เพิ่งร่ายยาวมาช้าๆ พยายามประติดประต่อคำตอบ
“นึกออกแล้วครับ” ผมยิ้มตอบ “โครงการที่เป็นตัวเลือกและปลอดภัยที่จะปล่อยออกมา คือโครงการที่ ‘ไม่ต้องใช้ Brent’ ครับ”
ผมยิ้มกว้างขึ้นเมื่อเขาพูดว่า “ถูกต้องเป๊ะ (Bingo) ง่ายๆ เลยใช่ไหมล่ะ?”
รอยยิ้มของผมหายไปเมื่อคิดถึงผลที่ตามมา “เดี๋ยวสิครับ แล้วผมจะรู้ได้ยังไงว่าโครงการไหนไม่ต้องใช้ Brent? พวกเรามักจะไม่รู้หรอกว่าต้องใช้ Brent จนกว่าจะทำงานไปครึ่งทางแล้วน่ะ!”
ผมรู้สึกเสียใจทันทีที่ถามคำถามนั้นออกไป เมื่อ Erik จ้องผมเขม็ง “ผมมีหน้าที่ต้องตอบทุกคำถามที่คุณไม่เป็นระเบียบพอที่จะหาคำตอบด้วยตัวเองงั้นเหรอ?”
“ขอโทษครับ เดี๋ยวผมจะหาคำตอบเอง” ผมรีบพูด “คุณรู้ไหม ผมคงจะโล่งใจมากถ้าเราได้รู้แน่ชัดสักทีว่างานไหนที่ต้องใช้ Brent จริงๆ”
“ถูกเผงเลย” เขาพูด “สิ่งที่คุณกำลังสร้างคือ รายการวัสดุ (bill of materials) สำหรับงานทั้งหมดที่คุณทำในฝ่าย IT Operations แต่แทนที่จะเป็นรายการชิ้นส่วนและชุดประกอบย่อย อย่างแม่พิมพ์ สกรู และลูกล้อ คุณกำลังทำรายการสิ่งที่ต้องเตรียมพร้อม (prerequisites) ทั้งหมดที่คุณต้องการก่อนจะทำงานเสร็จได้—อย่างเช่น รุ่นของ laptop, ข้อกำหนดข้อมูลผู้ใช้งาน, ซอฟต์แวร์และ license ที่ต้องใช้, การกำหนดค่า (configuration), ข้อมูลเวอร์ชัน, ข้อกำหนดด้านความปลอดภัย ขีดความสามารถ และความต่อเนื่อง และอะไรต่อมิอะไรอีกมากมาย...”
เขาพูดขัดจังหวะตัวเอง พลางเสริมว่า “จะพูดให้ถูกต้องกว่านี้ก็คือ คุณกำลังสร้าง รายการทรัพยากร (bill of resources) นั่นคือรายการวัสดุบวกกับรายการศูนย์งานที่ต้องใช้และเส้นทางงาน (routing) เมื่อคุณมีข้อมูลนั้น พร้อมกับใบสั่งงาน (work order) และทรัพยากรของคุณ ในที่สุดคุณก็จะสามารถควบคุมได้ว่าขีดความสามารถ (capacity) และความต้องการ (demand) ของคุณคืออะไร นั่นคือสิ่งที่จะช่วยให้คุณรู้แน่ชัดว่าคุณจะรับงานใหม่ได้ไหม และจะสามารถวางตารางงาน (schedule) ได้จริงๆ เสียที”
น่าทึ่งมาก ผมคิดว่าผมเริ่มจะเข้าใจมันแล้ว
ผมกำลังจะถามคำถามต่อ แต่ Erik พูดขึ้นว่า “คำถามที่สองของคุณคือการปล่อยโครงการมอนิเตอร์ออกมาปลอดภัยไหม คุณได้ข้อสรุปแล้วว่ามันไม่ต้องใช้ Brent ยิ่งไปกว่านั้น คุณบอกว่าเป้าหมายของโครงการนี้คือการป้องกันไม่ให้ระบบล่ม ซึ่งจะช่วยลดการส่งงานต่อให้ Brent มากไปกว่านั้น เมื่อเกิดระบบล่มขึ้นจริง คุณก็จะใช้เวลาของ Brent น้อยลงในการ troubleshoot และแก้ไขปัญหา คุณได้ระบุจุดข้อจำกัดแล้ว ใช้ประโยชน์จากมันอย่างเต็มที่ (exploit) แล้วคุณก็ได้จัดลำดับความสำคัญของงานอื่นๆ ให้ขึ้นอยู่กับจุดข้อจำกัด (subordinate) นั้นแล้ว ดังนั้นโครงการมอนิเตอร์นี้สำคัญขนาดไหนล่ะ?”
ผมใช้เวลาคิดครู่หนึ่ง แล้วก็ครางออกมาเมื่อนึกถึงคำตอบที่ชัดเจนนั้นได้
ผมใช้นิ้วเสยผม “คุณบอกว่าเราต้องหาทางยกระดับ (elevate) จุดข้อจำกัดอยู่เสมอ ซึ่งหมายความว่าผมต้องทำทุกอย่างเพื่อให้ Brent มีเวลาเหลือมากขึ้น นั่นคือสิ่งที่โครงการมอนิเตอร์ทำพอดีเลย!”
ผมพูดด้วยความรู้สึกกึ่งประหลาดใจที่มองข้ามเรื่องนี้ไปได้ “โครงการมอนิเตอร์น่าจะเป็นโครงการปรับปรุงที่สำคัญที่สุดที่เรามีเลย—เราต้องเริ่มโครงการนี้ทันทีครับ”
“ถูกต้องที่สุด” Erik พูด “การยกระดับงานเชิงป้องกัน (preventive work) อย่างเหมาะสมคือหัวใจสำคัญของโปรแกรมอย่างการบำรุงรักษาทวีผลที่ทุกคนมีส่วนร่วม (Total Productive Maintenance - TPM) ซึ่งชาว Lean ยอมรับกันอย่างกว้างขวาง TPM ยืนยันว่าเราต้องทำทุกอย่างเพื่อให้มั่นใจว่าเครื่องจักรจะพร้อมใช้งานโดยการยกระดับการซ่อมบำรุง อย่างที่หนึ่งในอาจารย์ (sensei) ของผมเคยพูดไว้ว่า ‘การปรับปรุงงานประจำวันนั้นสำคัญยิ่งกว่าการทำงานประจำวันเสียอีก’ แนวทางที่สาม (The Third Way) คือเรื่องของการสร้างความตึงเครียดให้กับระบบอย่างต่อเนื่อง เพื่อให้เราเสริมสร้างนิสัยและปรับปรุงบางอย่างอยู่เสมอ วิศวกรรมความยืดหยุ่น (resilience engineering) บอกเราว่าเราควรใส่ข้อผิดพลาดเข้าไปในระบบเป็นประจำ และทำบ่อยๆ เพื่อให้มันเจ็บปวดน้อยลง
“Mike Rother บอกว่ามันไม่สำคัญหรอกว่าคุณจะปรับปรุงอะไร ตราบใดที่คุณยังมีการปรับปรุงบางอย่างอยู่ เพราะอะไรน่ะเหรอ? เพราะถ้าคุณไม่ปรับปรุง กฎของเอนโทรปี (entropy) จะรับประกันว่าคุณกำลังแย่ลงเรื่อยๆ ซึ่งจะทำให้คุณไม่มีทางเข้าใกล้เป้าหมายของความผิดพลาดเป็นศูนย์ (zero errors), อุบัติเหตุจากการทำงานเป็นศูนย์ และความสูญเสียเป็นศูนย์ได้เลย”
จู่ๆ ทุกอย่างก็ดูชัดเจนและประจักษ์แจ้งขึ้นมาทันที ผมรู้สึกว่าต้องโทรหา Patty ทันทีเพื่อบอกให้เธอเริ่มโครงการมอนิเตอร์เดี๋ยวนี้เลย
Erik พูดต่อ “Rother เรียกสิ่งนี้ว่า การปรับปรุงกะตะ (Improvement Kata) เขาใช้คำว่า kata (ท่ารำ) เพราะเขาเข้าใจว่าการทำซ้ำสร้างนิสัย และนิสัยคือสิ่งที่นำไปสู่ความเชี่ยวชาญ ไม่ว่าคุณจะพูดถึงการฝึกกีฬา การหัดเล่นเครื่องดนตรี หรือการฝึกหน่วยรบพิเศษ ไม่มีอะไรนำไปสู่ความเชี่ยวชาญได้ดีกว่าการฝึกซ้อมและทำซ้ำ การศึกษาแสดงให้เห็นว่าการฝึกวันละห้านาทีทุกวันดีกว่าการฝึกสัปดาห์ละครั้งครั้งละสามชั่วโมง และถ้าคุณต้องการสร้างวัฒนธรรมแห่งการปรับปรุงที่แท้จริง คุณต้องสร้างนิสัยเหล่านั้นขึ้นมา”
เขากลับไปมองที่พื้นโรงงานแล้วพูดต่อ “ก่อนที่เราจะจากกัน ลองหันเหความสนใจจากศูนย์งานไปยังพื้นที่ที่อยู่ ‘ระหว่าง’ ศูนย์งานดูสิ การจัดการการส่งต่องาน (handoffs) นั้นสำคัญพอๆ กับการควบคุมจังหวะการปล่อยงาน ระยะเวลารอคอย (wait time) สำหรับทรัพยากรใดก็ตาม คือเปอร์เซ็นต์ที่ทรัพยากรนั้นไม่ว่าง หารด้วยเปอร์เซ็นต์ที่ทรัพยากรนั้นว่างงาน ดังนั้น ถ้าทรัพยากรนั้นถูกใช้งานห้าสิบเปอร์เซ็นต์ ระยะเวลารอคอยคือ 50/50 หรือเท่ากับ 1 หน่วย แต่ถ้าทรัพยากรนั้นถูกใช้งานเก้าสิบเปอร์เซ็นต์ ระยะเวลารอคอยจะเป็น 90/10 หรือยาวนานขึ้นเก้าเท่า และถ้าทรัพยากรนั้นถูกใช้งานเก้าสิบเก้าเปอร์เซ็นต์ล่ะ?”
แม้ผมจะยังไม่ค่อยเข้าใจความเกี่ยวข้องของมันนัก แต่ผมก็คำวณในหัว: 99/1 ผมตอบว่า “เก้าสิบเก้าครับ”
“ถูกต้อง” เขาพูด “เมื่อทรัพยากรถูกใช้งานเก้าสิบเก้าเปอร์เซ็นต์ คุณต้องรอนานกว่าตอนที่มันถูกใช้งานห้าสิบเปอร์เซ็นต์ถึงเก้าสิบเก้าเท่าเลยทีเดียว”
เขาผายมือออกกว้างๆ “ส่วนสำคัญของแนวทางที่สอง (The Second Way) คือการทำให้ระยะเวลารอคอยมองเห็นได้ชัดเจน เพื่อให้คุณรู้ว่างานของคุณไปตกค้างอยู่ในคิวของใครหลายวัน—หรือแย่กว่านั้น คืองานต้องตีกลับเพราะมีชิ้นส่วนไม่ครบหรือต้องเอาไปทำใหม่ (rework)
“จำไว้ว่าเป้าหมายของเราคือการทำให้งานไหล (flow) ได้เร็วที่สุด ที่โรงงาน MRP-8 แห่งนี้ เราเคยเจอกับสถานการณ์เมื่อหลายปีก่อนที่ส่วนประกอบบางอย่างไม่เคยมาถึงขั้นตอนประกอบสุดท้ายได้ทันเวลาเลย มันเป็นเพราะเรามีทรัพยากรไม่พอหรือเป็นเพราะขั้นตอนบางอย่างใช้เวลานานเกินไปหรือเปล่านะ?
“เปล่าเลย! เมื่อเราลองติดตามชิ้นส่วนเหล่านั้นไปรอบโรงงานจริงๆ เราพบว่าเวลาส่วนใหญ่ของมันคือการจอดแช่อยู่ในคิว (queues) พูดง่ายๆ ก็คือ ‘เวลาที่ใช้ทำงานจริงๆ’ (touch time) เป็นเพียงเสี้ยวเล็กๆ ของ ‘เวลาทั้งหมดของกระบวนการ’ (total process time) พนักงานเร่งงานของเราต้องไปค้นหาท่ามกลางกองงานมหาศาลเพื่อหาชิ้นส่วนเหล่านั้นแล้วดันมันให้ผ่านศูนย์งานไปได้” เขาพูดด้วยน้ำเสียงเหลือเชื่อ
“เรื่องแบบนั้นกำลังเกิดขึ้นที่โรงงานของคุณเหมือนกัน ลองสังเกตดูสิ” เขากล่าว
ผมพยักหน้าและพูดว่า “Erik ผมยังติดเรื่องการปล่อยโครงการมอนิเตอร์อยู่ ผู้คนมักจะยืนกรานว่าโครงการพิเศษของตัวเองน่ะเร่งด่วน และต้องได้รับการทำก่อนงานอื่นๆ แล้วโครงการตรวจสอบ (audit) และงานด้านความปลอดภัย (security remediation) ที่ John กำลังตะโกนขอนั้น มันอยู่ตรงไหนของภาพรวมนี้ล่ะครับ?”
Erik มองหน้าผมอย่างจดจ่อแล้วในที่สุดก็พูดว่า “ในช่วงสองสัปดาห์ที่ผ่านมานี่คุณได้ยินสิ่งที่ผมพูดไปบ้างสักคำไหมเนี่ย?”
เขามองนาฬิกาแล้วพูดว่า “ต้องไปแล้ว”
ผมตกใจและมองตามเขาขณะที่เขาเดินเร็วๆ ไปที่ทางออก catwalk ผมต้องรีบวิ่งตามเขาไป เขาเป็นผู้ชายตัวใหญ่ อายุประมาณห้าสิบกว่าปีแล้ว แม้จะมีน้ำหนักตัวค่อนข้างมากแต่เขาก็เดินเร็วมาก
เมื่อผมตามเขาทัน ผมพูดว่า “เดี๋ยวครับ คุณกำลังจะบอกว่าปัญหาจากการตรวจสอบมันไม่สำคัญพอที่จะแก้ไขงั้นเหรอ?”
“ผม ไม่เคย พูดแบบนั้นนะ” เขาพูดพลางหยุดเดินและหันมาเผชิญหน้ากับผม “ถ้าคุณทำอะไรผิดพลาดจนทำให้ความสามารถในการปฏิบัติตามกฎหมายและข้อบังคับ (compliance) ของบริษัทตกอยู่ในอันตราย? คุณต้องแก้สิ—ไม่งั้นคุณก็ควรจะถูกไล่ออก”
เขาหันหลังกลับและก้าวเดินต่อ พลางพูดข้ามไหล่ว่า “บอกผมหน่อย โครงการ ‘ความปลอดภัย’ ทั้งหมดที่ Jimmy เพื่อน CISO ของคุณกำลังพยายามผลักดันน่ะ มันช่วยเพิ่มปริมาณงาน (flow) ของโครงการ IT ให้ไหลผ่านองค์กรได้ไหม?”
“ไม่ครับ” ผมรีบตอบ พลางเร่งฝีเท้าตามให้ทันอีกรอบ
“มันช่วยเพิ่มความเสถียรในการดำเนินงาน หรือช่วยลดเวลาที่ต้องใช้ในการตรวจจับและกู้คืนระบบจากระบบล่มหรือการถูกเจาะระบบ (security breach) ได้ไหม?”
ผมใช้เวลาคิดนานขึ้นนิดหนึ่ง “ก็น่าจะไม่นะครับ งานส่วนใหญ่เป็นแค่งานจุกจิก และในกรณีส่วนใหญ่ งานที่พวกเขาขอน่ะมันมีความเสี่ยงและจริงๆ แล้วอาจทำให้ระบบล่มได้ด้วยซ้ำ”
“โครงการเหล่านี้ช่วยเพิ่มขีดความสามารถ (capacity) ของ Brent ได้ไหม?”
ผมหัวเราะอย่างขื่นๆ “ไม่เลย ตรงกันข้ามครับ แค่ปัญหาจากการตรวจสอบเรื่องเดียวก็อาจจะดึงตัว Brent ไปได้ทั้งปีแล้ว”
“แล้วการทำโครงการทั้งหมดของ Jimmy จะส่งผลยังไงกับระดับงานระหว่างทำ (WIP) ล่ะ?” เขาถามพลางเปิดประตูนำทางเรากลับเข้าไปในบันไดหนีไฟ
ผมพูดอย่างเหนื่อยหน่ายขณะที่เราเดินลงบันไดมาสองชั้น “มันจะพุ่งกระฉูดทะลุเพดานเลยล่ะครับ เหมือนเดิมเป๊ะ”
เมื่อเราถึงชั้นล่าง จู่ๆ Erik ก็หยุดและถามว่า “โอเค โครงการ ‘ความปลอดภัย’ เหล่านี้ลดปริมาณงานที่ไหลผ่านระบบ (throughput) ของคุณลง ซึ่งมันคือจุดข้อจำกัดของทั้งบริษัท และมันยังไปถมงานใส่ทรัพยากรที่มีข้อจำกัดที่สุดในองค์กรของคุณอีก แถมพวกมันยังไม่ได้ช่วยเรื่อง scalability, availability, survivability, sustainability, security, supportability หรือการที่องค์กรจะสามารถป้องกันตัวเองได้ (defensibility) เลยสักนิด”
เขาถามด้วยหน้านิ่งๆ “งั้นเจ้าอัจฉริยะ: โครงการของ Jimmy ฟังดูเป็นการใช้เวลาที่คุ้มค่าสำหรับคุณไหมล่ะ?”
ในขณะที่ผมเริ่มจะตอบ เขาก็แค่เปิดประตูทางออกแล้วเดินออกไป เห็นได้ชัดว่ามันเป็นคำถามเชิงประชดประชันที่เขาไม่ต้องการคำตอบ