2
The First Way: หลักการของ Flow
ในสายธารแห่งคุณค่า (value stream) ด้านเทคโนโลยี งานโดยทั่วไปจะไหลจากฝ่าย Development ไปยัง Operations ซึ่งเป็นพื้นที่ทำงานระหว่างธุรกิจของเรากับลูกค้า วิธีแรก (The First Way) ต้องการให้งานไหลจาก Development ไปยัง Operations อย่างรวดเร็วและราบรื่น เพื่อส่งมอบคุณค่าให้กับลูกค้าอย่างรวดเร็ว เราปรับให้เหมาะสมกับเป้าหมายโดยรวม (global goal) แทนที่จะเป็นเป้าหมายเฉพาะจุด (local goals) เช่น อัตราการทำฟีเจอร์เสร็จของ Development, อัตราส่วน test find/fix หรือมาตรวัดความพร้อมใช้งานของ Operations
เราเพิ่ม flow ด้วยการทำให้งานมองเห็นได้ (make work visible), การลดขนาด batch, และการสร้างคุณภาพไว้ในกระบวนการ (build quality in) เพื่อป้องกันไม่ให้ข้อบกพร่องถูกส่งต่อไปยัง work center ปลายน้ำ การเร่ง flow ผ่านสายธารแห่งคุณค่าด้านเทคโนโลยีช่วยลด lead time ที่ต้องใช้ในการตอบสนองคำขอของลูกค้าทั้งภายในและภายนอก เพิ่มคุณภาพของงานไปพร้อมกับทำให้เราตอบสนองต่อความต้องการของลูกค้าและตลาดได้ดีขึ้น และสามารถนำการแข่งขันด้วยการทดลองได้มากกว่า
เป้าหมายของเราคือการลดเวลาที่ต้องใช้ในการ deploy การเปลี่ยนแปลงขึ้นสู่ production และเพิ่มความน่าเชื่อถือและคุณภาพของบริการเหล่านั้น เบาะแสเกี่ยวกับวิธีการทำสิ่งนี้ในสายธารแห่งคุณค่าด้านเทคโนโลยีสามารถเรียนรู้ได้จากวิธีการนำหลักการ Lean ไปประยุกต์ใช้ในสายธารแห่งคุณค่าของการผลิต
ทำให้งานของเรามองเห็นได้
ความแตกต่างที่สำคัญระหว่างสายธารแห่งคุณค่าด้านเทคโนโลยีกับการผลิตก็คือ งานของเรานั้นมองไม่เห็น (invisible) ซึ่งแตกต่างจากกระบวนการทางกายภาพ ในสายธารแห่งคุณค่าด้านเทคโนโลยี เราไม่สามารถมองเห็นได้ง่ายว่างานไหลสะดุดตรงไหน หรือเมื่องานกำลังกองอยู่หน้า work center ที่มีข้อจำกัด การส่งต่องานระหว่าง work center ในการผลิตมักจะมองเห็นได้ชัดเจนและช้า เพราะต้องเคลื่อนย้ายสินค้าคงคลังทางกายภาพ
อย่างไรก็ตาม ในงานด้านเทคโนโลยี การส่งต่องานสามารถทำได้เพียงคลิกปุ่มเดียว เช่น การ reassign work ticket ให้ทีมอื่น เพราะมันง่ายมากที่จะส่งต่องาน งานจึงสามารถกระดอนระหว่างทีมได้ไม่มีที่สิ้นสุดเนื่องจากข้อมูลไม่สมบูรณ์ หรืองานสามารถถูกส่งต่อไปยัง work center ปลายน้ำพร้อมกับปัญหาที่มองไม่เห็นเลย จนกว่าเราจะส่งมอบงานให้ลูกค้าล่าช้าหรือแอปพลิเคชันของเราเกิดล้มเหลวใน production
เพื่อช่วยให้เราเห็นว่างานไหลได้ดีตรงไหน และงานกำลังคิวหรือติดขัดตรงไหน เราจำเป็นต้องทำให้งานของเรามองเห็นได้มากที่สุด หนึ่งในวิธีที่ดีที่สุดคือการใช้ visual work boards เช่น kanban boards หรือ sprint planning boards ซึ่งงานจะถูกแสดงบนการ์ดจริงหรือการ์ดอิเล็กทรอนิกส์ งานเริ่มต้นจากทางซ้าย (มักจะถูกดึงมาจาก backlog) ถูกดึงจาก work center หนึ่งไปยังอีก work center หนึ่ง (แสดงเป็นคอลัมน์) และเสร็จสิ้นเมื่อถึงด้านขวาของบอร์ด โดยปกติในคอลัมน์ที่ชื่อว่า "done" หรือ "in production"
ไม่เพียงแต่งานของเราจะมองเห็นได้เท่านั้น แต่เรายังสามารถจัดการงานให้ไหลจากซ้ายไปขวาได้เร็วที่สุดเท่าที่จะเป็นไปได้อีกด้วย วิธีนี้ยังช่วยเผยให้เห็น handoff ที่ไม่จำเป็นในงานของเรา ซึ่งอาจทำให้เกิดข้อผิดพลาดและความล่าช้าเพิ่มเติม ยิ่งไปกว่านั้น เรายังสามารถวัด lead time ตั้งแต่ตอนที่วางการ์ดบนบอร์ดจนถึงตอนที่ย้ายไปยังคอลัมน์ "done" ได้อีกด้วย
ตามอุดมคติแล้ว kanban board ของเราควรครอบคลุมทั้ง value stream โดยกำหนดว่างานจะเสร็จสมบูรณ์ก็ต่อเมื่อถึงด้านขวาของบอร์ด (Figure 2.1) งานยังไม่เสร็จเมื่อ Development ทำการ implement ฟีเจอร์เสร็จ แต่งานจะเสร็จก็ต่อเมื่อแอปพลิเคชันของเราทำงานได้สำเร็จใน production และส่งมอบคุณค่าให้กับลูกค้า
Figure 2.1: ตัวอย่าง Kanban Board ที่ครอบคลุม Requirements, Dev, Test, Staging และ In Production
ที่มา: David J. Andersen และ Dominica DeGrandis, Kanban for IT Ops , สื่อฝึกอบรมสำหรับเวิร์กช็อป, 2012.
การนำงานทั้งหมดของแต่ละ work center ใส่ในคิวและทำให้มองเห็นได้ ทำให้ผู้มีส่วนได้ส่วนเสีย (stakeholders) ทั้งหมดสามารถจัดลำดับความสำคัญของงานในบริบทของเป้าหมายโดยรวม (global goals) ได้ง่ายขึ้น การทำเช่นนี้ช่วยให้แต่ละ work center สามารถโฟกัสทำงานทีละงาน (single-task) ที่สำคัญที่สุดจนเสร็จ ซึ่งช่วยเพิ่ม throughput
จำกัดงานระหว่างทำ (Limit Work in Process: WIP)
ในการผลิต งานประจำวันมักจะถูกกำหนดโดยตารางการผลิตที่ถูกสร้างขึ้นเป็นประจำ (เช่น รายวัน รายสัปดาห์) ซึ่งกำหนดว่างานใดที่ต้องทำตามคำสั่งซื้อของลูกค้า วันที่ครบกำหนดของคำสั่งซื้อ ชิ้นส่วนที่มีอยู่ และอื่นๆ
ในด้านเทคโนโลยี งานของเรามักจะมีความ dynamic มากกว่ามาก โดยเฉพาะอย่างยิ่งใน shared services ที่ทีมต้องตอบสนองความต้องการของผู้มีส่วนได้ส่วนเสียที่หลากหลาย ส่งผลให้งานประจำวันถูกครอบงำด้วย priority du jour (ลำดับความสำคัญประจำวัน) โดยมักจะมีคำขอด่วนเข้ามาทุกช่องทางการสื่อสารเท่าที่เป็นไปได้ รวมถึง ticketing systems, สายแจ้งเหตุขัดข้อง, อีเมล, โทรศัพท์, แชท และ management escalations
การขัดจังหวะในการผลิตก็มองเห็นได้ชัดเจนและมีต้นทุนสูงเช่นกัน มักจะต้องยกเลิกงานปัจจุบันและทิ้งงานระหว่างทำที่ยังไม่เสร็จเพื่อเริ่มงานใหม่ ระดับความพยายามที่สูงนี้ช่วยลดการขัดจังหวะบ่อยครั้ง
อย่างไรก็ตาม การขัดจังหวะคนทำงานด้านเทคโนโลยีนั้นทำได้ง่าย เพราะผลที่ตามมานั้นมองไม่เห็นกับเกือบทุกคน แม้ว่าผลกระทบด้านลบต่อประสิทธิภาพการทำงานอาจจะรุนแรงกว่าการผลิตมาก ตัวอย่างเช่น วิศวกรที่ถูกมอบหมายให้ทำงานหลายโปรเจกต์ต้องสลับไปมาระหว่างงาน ซึ่งมีต้นทุนในการสร้างบริบท (context) ขึ้นมาใหม่ รวมถึงกฎและเป้าหมายด้านความคิด (cognitive rules and goals)
งานวิจัยพบว่าเวลาที่ใช้ในการทำงานแม้แต่ง่ายๆ อย่างการเรียงรูปทรงเรขาคณิตก็แย่ลงอย่างมีนัยสำคัญเมื่อทำหลายอย่างพร้อมกัน (multitasking) แน่นอนว่าเพราะงานของเราในสายธารแห่งคุณค่าด้านเทคโนโลยีมีความซับซ้อนทางความคิดมากกว่าการเรียงรูปทรงเรขาคณิตมาก ผลกระทบของ multitasking ต่อระยะเวลาการทำงานจึงแย่ยิ่งกว่า 1
เราสามารถจำกัด multitasking ได้เมื่อใช้ kanban board ในการจัดการงาน เช่น การกำหนดและบังคับใช้ WIP limits (ขีดจำกัดของงานระหว่างทำ) สำหรับแต่ละคอลัมน์หรือ work center ซึ่งกำหนดจำนวนสูงสุดของการ์ดที่สามารถอยู่ในคอลัมน์นั้นๆ
ตัวอย่างเช่น เราอาจตั้ง WIP limit ไว้ที่สามการ์ดสำหรับ testing เมื่อมีการ์ดสามใบอยู่ในเลน test แล้ว จะไม่สามารถเพิ่มการ์ดใหม่เข้าไปในเลนได้จนกว่าการ์ดจะเสร็จสมบูรณ์หรือถูกนำออกจากคอลัมน์ "in work" และใส่กลับเข้าไปในคิว (คือเอาการ์ดกลับไปไว้ที่คอลัมน์ทางซ้าย) จะไม่มีอะไรที่ทำงานได้จนกว่ามันจะถูกแสดงในการ์ดงานก่อน ซึ่งเป็นการตอกย้ำว่าทุกงานต้องทำให้มองเห็นได้
Dominica DeGrandis หนึ่งในผู้เชี่ยวชาญชั้นนำด้านการใช้ kanban ใน value stream ของ DevOps และผู้เขียนหนังสือ Making Work Visible กล่าวว่า "การควบคุมขนาดคิว [WIP] เป็นเครื่องมือการจัดการที่ทรงพลังอย่างยิ่ง เพราะมันเป็นหนึ่งใน leading indicators ไม่กี่อย่างของ lead time — สำหรับงานส่วนใหญ่ เราจะไม่รู้ว่ามันจะใช้เวลานานแค่ไหนจนกว่ามันจะเสร็จจริงๆ" 2
การจำกัด WIP ยังช่วยให้เห็นปัญหาที่ขัดขวางความสำเร็จของงานได้ง่ายขึ้น * ตัวอย่างเช่น เมื่อเราจำกัด WIP เราอาจพบว่าเราไม่มีอะไรต้องทำเพราะกำลังรอคนอื่นอยู่ แม้ว่ามันอาจจะน่าดึงดูดที่จะเริ่มงานใหม่ (เช่น "ทำอะไรสักอย่างดีกว่าไม่ทำอะไรเลย") แต่การกระทำที่ดีกว่ามากคือการหาสาเหตุที่ทำให้เกิดความล่าช้าและช่วยแก้ไขปัญหานั้น การทำหลายอย่างพร้อมกันที่ไม่ดี (bad multitasking) มักเกิดขึ้นเมื่อคนถูกมอบหมายให้ทำงานหลายโปรเจกต์ ซึ่งนำไปสู่ปัญหาเรื่องการจัดลำดับความสำคัญ กล่าวอีกนัยหนึ่ง ดังที่ David J. Anderson ผู้เขียนหนังสือ Kanban: Successful Evolutionary Change for Your Technology Business กล่าวว่า "หยุดเริ่ม เริ่มทำให้เสร็จ" (Stop starting. Start finishing.) 4
ลดขนาด Batch (Reduce Batch Sizes)
องค์ประกอบสำคัญอีกอย่างหนึ่งในการสร้าง flow ที่ราบรื่นและรวดเร็วคือการทำงานในขนาด batch ที่เล็ก ก่อนการปฏิวัติการผลิตแบบ Lean การผลิตในขนาด batch ใหญ่ (หรือ lot sizes) เป็นเรื่องปกติ โดยเฉพาะอย่างยิ่งสำหรับการทำงานที่การตั้งค่า (setup) หรือการสลับระหว่างงาน (switching) ใช้เวลาหรือมีต้นทุนสูง ตัวอย่างเช่น การผลิตแผงตัวถังรถยนต์ขนาดใหญ่ต้องติดตั้งแม่พิมพ์ขนาดใหญ่และหนักบนเครื่องปั๊มโลหะ ซึ่งเป็นกระบวนการที่อาจใช้เวลาหลายวัน เมื่อต้นทุนการเปลี่ยนงาน (changeover) สูงมาก เรามักจะปั๊มแผงให้ได้มากที่สุดเท่าที่จะทำได้ในครั้งเดียว เพื่อลดจำนวนครั้งในการ changeover
อย่างไรก็ตาม batch sizes ที่ใหญ่ส่งผลให้ระดับ WIP พุ่งสูงขึ้นและความผันผวนของ flow ที่สูงซึ่งส่งผลกระทบเป็นลูกโซ่ไปทั่วทั้งโรงงานผลิต ผลลัพธ์คือ lead time ที่ยาวนานและคุณภาพที่แย่ — หากพบปัญหาที่แผงตัวถังหนึ่งแผง ก็ต้องทิ้งทั้ง batch
หนึ่งในบทเรียนสำคัญของ Lean คือการลด lead time และเพิ่มคุณภาพ เราต้องพยายามลดขนาด batch ลงอย่างต่อเนื่อง ขีดจำกัดทางทฤษฎีของ batch size คือ single-piece flow ซึ่งแต่ละการดำเนินการจะทำทีละหนึ่งหน่วย †
ความแตกต่างอย่างมากระหว่าง batch size ใหญ่และเล็กสามารถเห็นได้จากจำลองการส่งจดหมายข่าวอย่างง่ายที่อธิบายไว้ในหนังสือ Lean Thinking: Banish Waste and Create Wealth in Your Corporation โดย James P. Womack และ Daniel T. Jones 5
สมมติในตัวอย่างของเรา เรามีโบรชัวร์สิบฉบับที่จะส่ง และการส่งโบรชัวร์แต่ละฉบับต้องใช้สี่ขั้นตอน: (1) พับกระดาษ, (2) ใส่กระดาษลงในซอง, (3) ปิดผนึกซอง, และ (4) ติดแสตมป์
กลยุทธ์แบบ batch ใหญ่ (หรือ "mass production") คือการทำทีละขั้นตอนกับโบรชัวร์ทั้งสิบฉบับ กล่าวอีกนัยหนึ่ง เราจะพับกระดาษทั้งสิบแผ่นก่อน จากนั้นใส่แต่ละแผ่นลงในซอง จากนั้นปิดผนึกทั้งสิบซอง แล้วจึงติดแสตมป์
ในทางกลับกัน กลยุทธ์แบบ batch เล็ก (หรือ "single-piece flow") จะทำทุกขั้นตอนที่ต้องใช้ในการทำโบรชัวร์แต่ละฉบับให้เสร็จก่อนที่จะเริ่มฉบับถัดไป กล่าวอีกนัยหนึ่ง เราพับกระดาษหนึ่งแผ่น ใส่ลงในซอง ปิดผนึก และติดแสตมป์ — จากนั้นจึงเริ่มกระบวนการใหม่กับกระดาษแผ่นถัดไป
ความแตกต่างระหว่างการใช้ batch size ใหญ่และเล็กนั้นชัดเจนมาก (ดู Figure 2.2 ในหน้าที่ 24) สมมติว่าแต่ละขั้นตอนในสี่ขั้นตอนใช้เวลาสิบต่อซองสำหรับซองทั้งสิบซอง ด้วยกลยุทธ์ batch size ใหญ่ ซองแรกที่เสร็จสมบูรณ์และติดแสตมป์จะถูกผลิตหลังจาก 310 วินาที
Figure 2.2: การจำลอง "Envelope Game"
(พับ ใส่ ปิดผนึก และติดแสตมป์ซอง)
ที่มา: Stefan Luyten, "Single Piece Flow," Medium.com , 8 สิงหาคม 2014, https://medium.com/@stefanluyten/single-piece-flow-5d2c2bec845b .
ที่แย่กว่านั้น สมมติว่าเราค้นพบระหว่างการปิดผนึกซองว่าเราทำผิดพลาดในขั้นตอนแรกของการพับ — ในกรณีนี้ เราจะพบข้อผิดพลาดเร็วที่สุดที่ 200 วินาที และเราต้องพับใหม่และใส่ใหม่ทั้งสิบโบรชัวร์ใน batch ของเราอีกครั้ง
ในทางตรงกันข้าม ในกลยุทธ์ batch เล็ก ซองแรกที่เสร็จสมบูรณ์และติดแสตมป์จะถูกผลิตในเวลาเพียง 40 วินาที ซึ่งเร็วกว่ากลยุทธ์ batch ใหญ่ถึงแปดเท่า และถ้าเราทำผิดพลาดในขั้นตอนแรก เราก็แค่ต้องทำโบรชัวร์เดียวใน batch เราใหม่เท่านั้น batch sizes ที่เล็กส่งผลให้มี WIP น้อยลง, lead time เร็วขึ้น, การตรวจจับข้อผิดพลาดเร็วขึ้น และการทำงานซ้ำน้อยลง
ผลลัพธ์เชิงลบที่เกี่ยวข้องกับ batch sizes ที่ใหญ่ก็มีความเกี่ยวข้องกับสายธารแห่งคุณค่าด้านเทคโนโลยีไม่ต่างจากการผลิต ลองพิจารณากรณีที่มีตารางการปล่อยซอฟต์แวร์ประจำปี ซึ่งโค้ดทั้งปีที่ Development ทำงานทั้งหมดถูกปล่อยสู่ production deployment
เช่นเดียวกับการผลิต การปล่อยแบบ batch ใหญ่เช่นนี้สร้าง WIP ในระดับที่สูงอย่างฉับพลันและการรบกวนครั้งใหญ่ต่อ work center ปลายน้ำทั้งหมด ส่งผลให้ flow แย่และผลลัพธ์ด้านคุณภาพไม่ดี สิ่งนี้ยืนยันประสบการณ์ทั่วไปของเราที่ว่ายิ่งการเปลี่ยนแปลงที่เข้าสู่ production มีขนาดใหญ่เท่าไหร่ ข้อผิดพลาดใน production ก็ยิ่งวินิจฉัยและแก้ไขได้ยากขึ้น และใช้เวลาในการแก้ไขนานขึ้นเท่านั้น
ในโพสต์บน Startup Lessons Learned นั้น Eric Ries กล่าวว่า
batch size คือหน่วยที่ผลงาน (work-products) เคลื่อนที่ระหว่างขั้นตอนในกระบวนการ development [หรือ DevOps] สำหรับซอฟต์แวร์ batch ที่เห็นได้ง่ายที่สุดคือโค้ด ทุกครั้งที่วิศวกร check in โค้ด พวกเขากำลังรวมงานจำนวนหนึ่งเป็น batch มีเทคนิคมากมายในการควบคุม batch เหล่านี้ ตั้งแต่ batch เล็กๆ ที่จำเป็นสำหรับ continuous deployment ไปจนถึงการพัฒนาแบบ branch-based แบบดั้งเดิม ที่โค้ดทั้งหมดจากนักพัฒนาหลายคนที่ทำงานเป็นเวลาหลายสัปดาห์หรือหลายเดือนถูกรวมเป็น batch และรวมเข้าด้วยกัน 6
สิ่งที่เทียบเท่ากับ single piece flow ในสายธารแห่งคุณค่าด้านเทคโนโลยีคือ continuous deployment ซึ่งการเปลี่ยนแปลงทุกครั้งที่ commit สู่ version control จะถูก integration, testing และ deploy สู่ production แนวปฏิบัติที่ทำให้สิ่งนี้เป็นไปได้ถูกอธิบายไว้ใน Part IV ของหนังสือเล่มนี้
ลดจำนวน Handoff (Reduce the Number of Handoffs)
ในสายธารแห่งคุณค่าด้านเทคโนโลยี เมื่อใดก็ตามที่เรามี deployment lead time ที่ยาวนานเป็นเดือน มักจะเป็นเพราะมีการดำเนินงานหลายร้อย (หรือหลายพัน) ขั้นตอนที่ต้องใช้ในการย้ายโค้ดของเราจาก version control ไปยัง production environment การส่งโค้ดผ่าน value stream ต้องใช้หลายฝ่ายในการทำงานที่หลากหลาย รวมถึง functional testing, integration testing, environment creation, server administration, storage administration, networking, load balancing และ information security
ทุกครั้งที่งานส่งผ่านจากทีมหนึ่งไปยังอีกทีมหนึ่ง เราต้องการการสื่อสารทุกรูปแบบ เช่น การร้องขอ การระบุรายละเอียด การส่งสัญญาณ การประสานงาน และบ่อยครั้งที่ต้องจัดลำดับความสำคัญ การจัดตาราง การแก้ไขข้อขัดแย้ง การทดสอบ และการตรวจสอบ ซึ่งอาจต้องใช้ระบบ ticketing หรือ project management ที่แตกต่างกัน การเขียนเอกสารข้อกำหนดทางเทคนิค การสื่อสารผ่านการประชุม อีเมล หรือโทรศัพท์ และการใช้ file system shares, FTP servers และ Wiki pages
แต่ละขั้นตอนเหล่านี้คือคิวที่อาจเกิดขึ้นซึ่งงานจะรอเมื่อเราพึ่งพาทรัพยากรที่ใช้ร่วมกันระหว่าง value streams ที่แตกต่างกัน (เช่น centralized operations) lead time สำหรับคำขอเหล่านี้มักจะนานมากจนมีการ escalation อย่างต่อเนื่องเพื่อให้งานเสร็จภายในระยะเวลาที่ต้องการ
แม้ภายใต้สถานการณ์ที่ดีที่สุด ความรู้บางส่วนก็สูญเสียไปอย่างหลีกเลี่ยงไม่ได้กับแต่ละ handoff เมื่อมี handoff มากพอ งานอาจสูญเสียบริบทของปัญหาที่กำลังแก้ไขหรือเป้าหมายขององค์กรที่กำลังสนับสนุนไปอย่างสิ้นเชิง ตัวอย่างเช่น ผู้ดูแลเซิร์ฟเวอร์อาจเห็น ticket ที่ถูกสร้างขึ้นใหม่ขอให้สร้างบัญชีผู้ใช้ โดยไม่รู้ว่าบัญชีนั้นมีไว้สำหรับแอปพลิเคชันหรือบริการใด เหตุใดจึงต้องสร้าง การพึ่งพาทั้งหมดคืออะไร หรือว่าการสร้างบัญชีผู้ใช้นั้นเป็นงานที่เกิดขึ้นเป็นประจำหรือไม่
เพื่อบรรเทาปัญหาเหล่านี้ เรามุ่งมั่นที่จะลดจำนวน handoff ไม่ว่าจะเป็นการทำงานอัตโนมัติในส่วนสำคัญของงาน หรือการสร้าง platforms และการจัดทีมใหม่เพื่อให้พวกเขาสามารถทำ builds, testing และ deployments ด้วยตนเองเพื่อส่งมอบคุณค่าให้กับลูกค้าโดยไม่ต้องพึ่งพาผู้อื่นตลอดเวลา ผลลัพธ์คือเราสามารถเพิ่ม flow โดยลดเวลาที่งานใช้รอในคิว รวมถึงเวลาที่ไม่เพิ่มคุณค่า (non-value-added time) (ดู Appendix 4)
ระบุและยกระดับข้อจำกัดของเราอย่างต่อเนื่อง (Continually Identify and Elevate Our Constraints)
เพื่อลด lead time และเพิ่ม throughput เราจำเป็นต้องระบุข้อจำกัด (constraints) ของระบบของเราอย่างต่อเนื่องและปรับปรุงขีดความสามารถในการทำงาน ในหนังสือ Beyond the Goal ดร. Goldratt กล่าวว่า "ใน value stream ใดๆ ก็ตาม จะมีทิศทางของ flow เสมอ และจะมีข้อจำกัดเพียงหนึ่งเดียวเสมอ การปรับปรุงใดๆ ที่ไม่ได้ทำที่ข้อจำกัดนั้นคือภาพลวงตา" 7 ถ้าเราปรับปรุง work center ที่อยู่ก่อนหน้าข้อจำกัด งานก็จะมากองที่ bottleneck เร็วขึ้นเท่านั้น รอให้ work center ที่เป็น bottleneck ดำเนินการ
ในทางกลับกัน ถ้าเราไปปรับปรุง work center ที่อยู่ หลัง bottleneck มันก็จะอดอยาก รอให้งานผ่าน bottleneck มา ดร. Goldratt จึงได้กำหนด "ห้าขั้นตอนการโฟกัส" (five focusing steps) ไว้ดังนี้: 8
• ระบุข้อจำกัดของระบบ (Identify the system's constraint)
• ตัดสินใจว่าจะใช้ประโยชน์จากข้อจำกัดของระบบอย่างไร (Decide how to exploit the system's constraint)
• ทำให้ทุกอย่างอื่นอยู่ภายใต้การตัดสินใจข้างต้น (Subordinate everything else to the above decisions)
• ยกระดับข้อจำกัดของระบบ (Elevate the system's constraint)
• หากข้อจำกัดถูกแก้ไขในขั้นตอนก่อนหน้านี้ ให้กลับไปที่ขั้นตอนแรก แต่อย่าปล่อยให้ความเฉื่อย (inertia) ทำให้เกิดข้อจำกัดของระบบใหม่
ในการเปลี่ยนแปลง DevOps โดยทั่วไป เมื่อเราก้าวจาก deployment lead time ที่วัดเป็นเดือนหรือไตรมาสไปเป็น lead time ที่วัดเป็นนาที ข้อจำกัดมักจะเป็นไปตามลำดับนี้:
• Environment creation: เราไม่สามารถทำ deployments ได้ตามต้องการ ถ้าเราต้องรอเป็นสัปดาห์หรือเป็นเดือนสำหรับ production หรือ test environments มาตรการแก้ไขคือการสร้าง environments ที่พร้อมใช้งานตามต้องการและสามารถจัดการได้ด้วยตนเอง (self-serviced) เพื่อให้พร้อมใช้งานเสมอเมื่อเราต้องการ
• Code deployment: เราไม่สามารถทำ deployments ได้ตามต้องการ ถ้าแต่ละ production code deployment ใช้เวลาหลายสัปดาห์หรือหลายเดือน (เช่น แต่ละ deployment ต้องใช้ 1,300 ขั้นตอนที่ทำด้วยตนเองและเสี่ยงต่อข้อผิดพลาด โดยเกี่ยวข้องกับวิศวกรมากถึงสามร้อยคน) มาตรการแก้ไขคือการทำให้ deployments เป็นอัตโนมัติมากที่สุดเท่าที่จะเป็นไปได้ โดยมีเป้าหมายให้เป็นอัตโนมัติอย่างสมบูรณ์ เพื่อให้นักพัฒนาทุกคนสามารถทำ deployments ได้ด้วยตนเอง
• Test setup and run: เราไม่สามารถทำ deployments ได้ตามต้องการ ถ้าทุก code deployment ต้องใช้เวลาสองสัปดาห์ในการตั้งค่า test environments และชุดข้อมูล และอีกสี่สัปดาห์ในการ execute การทดสอบ regression ทั้งหมดด้วยตนเอง มาตรการแก้ไขคือการทำให้การทดสอบเป็นอัตโนมัติเพื่อให้เราสามารถ deploy ได้อย่างปลอดภัย และทำการทดสอบแบบขนาน (parallelize) เพื่อให้อัตราการทดสอบสามารถตามทันอัตราการพัฒนาโค้ดของเรา
• Overly tight architecture: เราไม่สามารถทำ deployments ได้ตามต้องการ ถ้าสถาปัตยกรรมที่แน่นเกินไป (overly tight architecture) หมายความว่าทุกครั้งที่เราต้องการเปลี่ยนแปลงโค้ด เราต้องส่งวิศวกรของเราไปประชุมคณะกรรมการหลายครั้งเพื่อขออนุญาต มาตรการแก้ไขคือการสร้างสถาปัตยกรรมที่ loosely coupled มากขึ้น เพื่อให้การเปลี่ยนแปลงสามารถทำได้อย่างปลอดภัยและมีอิสระมากขึ้น เพิ่มประสิทธิภาพการทำงานของนักพัฒนา
หลังจากที่ข้อจำกัดทั้งหมดเหล่านี้ถูกแก้ไขแล้ว ข้อจำกัดของเรามักจะเป็นฝ่าย Development หรือ product owners เนื่องจากเป้าหมายของเราคือการทำให้ทีมนักพัฒนาขนาดเล็กสามารถพัฒนา ทดสอบ และ deploy คุณค่าให้กับลูกค้าได้อย่างรวดเร็วและเชื่อถือได้ด้วยตนเอง นี่คือจุดที่เราต้องการให้ข้อจำกัดของเราอยู่ ผู้ที่มีประสิทธิภาพสูง ไม่ว่าวิศวกรจะอยู่ในฝ่าย Development, QA, Operations หรือ Infosec กล่าวว่าเป้าหมายของพวกเขาคือการช่วยเพิ่มประสิทธิภาพการทำงานของนักพัฒนาให้สูงสุด
เมื่อข้อจำกัดมาอยู่ตรงนี้ เราจะถูกจำกัดเพียงแค่จำนวนสมมติฐานทางธุรกิจที่ดีที่เราสร้างขึ้นและความสามารถของเราในการพัฒนาโค้ดที่จำเป็นเพื่อทดสอบสมมติฐานเหล่านี้กับลูกค้าจริง
ลำดับความก้าวหน้าของข้อจำกัดที่กล่าวมาข้างต้นเป็นภาพรวมทั่วไปของการเปลี่ยนแปลงทั่วไป — เทคนิคในการระบุข้อจำกัดใน value streams จริง เช่น การทำ value stream mapping และการวัดผล จะถูกอธิบายในภายหลังในหนังสือเล่มนี้
กำจัดความยากลำบากและของเสียใน Value Stream (Eliminate Hardships and Waste in the Value Stream)
Shigeo Shingo หนึ่งในผู้บุกเบิกของ Toyota Production System เชื่อว่าของเสีย (waste) เป็นภัยคุกคามที่ใหญ่ที่สุดต่อความอยู่รอดของธุรกิจ — คำจำกัดความที่ใช้กันทั่วไปใน Lean คือ "การใช้ทรัพยากรใดๆ เกินกว่าที่ลูกค้าต้องการและยินดีจ่าย" 9 เขากำหนดของเสียในการผลิตหลักเจ็ดประเภท: สินค้าคงคลัง (inventory), การผลิตมากเกินไป (overproduction), การประมวลผลเกินจำเป็น (extra processing), การขนส่ง (transportation), การรอคอย (waiting), การเคลื่อนไหวที่ไม่จำเป็น (motion), และข้อบกพร่อง (defects)
การตีความ Lean ในยุคปัจจุบันได้ชี้ให้เห็นว่า "การกำจัดของเสีย" (eliminating waste) อาจมีบริบทที่ดูถูกและลดทอนความเป็นมนุษย์ เป้าหมายจึงถูกปรับกรอบใหม่เป็นการลดความยากลำบากและความจำเจ (hardship and drudgery) ในงานประจำวันของเราผ่านการเรียนรู้อย่างต่อเนื่อง เพื่อบรรลุเป้าหมายขององค์กร สำหรับส่วนที่เหลือของหนังสือเล่มนี้ คำว่า waste จะใช้ในความหมายสมัยใหม่นี้ เพราะสอดคล้องกับอุดมคติและผลลัพธ์ที่ต้องการของ DevOps มากกว่า
ในหนังสือ Implementing Lean Software Development: From Concept to Cash นั้น Mary และ Tom Poppendieck อธิบายของเสียและความยากลำบากในสายธารการพัฒนาซอฟต์แวร์ว่าเป็นอะไรก็ตามที่ทำให้เกิดความล่าช้าต่อลูกค้า เช่น กิจกรรมที่สามารถข้ามไปได้โดยไม่ส่งผลกระทบต่อผลลัพธ์ 10 Mary และ Tom Poppendieck ได้ระบุของเสียและความยากลำบากเจ็ดประเภทดังนี้: 11
• Partially done work (งานที่ทำไม่เสร็จ): รวมถึงงานใดๆ ใน value stream ที่ยังไม่เสร็จสมบูรณ์ (เช่น เอกสารข้อกำหนดหรือ change orders ที่ยังไม่ได้รับการตรวจสอบ) และงานที่รออยู่ในคิว (เช่น รอการตรวจสอบจาก QA หรือรอ server admin ticket) งานที่ทำไม่เสร็จจะล้าสมัยและสูญเสียมูลค่าเมื่อเวลาผ่านไป
• Extra processes (กระบวนการเกินจำเป็น): งานเพิ่มเติมใดๆ ที่ดำเนินการในกระบวนการที่ไม่เพิ่มคุณค่าให้กับลูกค้า ซึ่งอาจรวมถึงเอกสารที่ไม่ได้ใช้ใน work center ปลายน้ำ หรือการตรวจสอบหรืออนุมัติที่ไม่เพิ่มคุณค่าให้กับผลลัพธ์ กระบวนการเกินจำเป็นเพิ่มความพยายามและเพิ่ม lead time
• Extra features (ฟีเจอร์เกินจำเป็น): ฟีเจอร์ที่สร้างขึ้นในบริการที่ไม่จำเป็นต่อองค์กรหรือลูกค้า (เช่น "gold plating") ฟีเจอร์เกินจำเป็นเพิ่มความซับซ้อนและความพยายามในการทดสอบและการจัดการฟังก์ชันการทำงาน
• Task switching (การสลับงาน): เมื่อคนถูกมอบหมายให้ทำงานหลายโปรเจกต์และ value streams ทำให้พวกเขาต้องสลับบริบท (context switch) และจัดการการพึ่งพาระหว่างงาน ซึ่งเพิ่มความพยายามและเวลาใน value stream
• Waiting (การรอคอย): ความล่าช้าใดๆ ที่ทำให้งานต้องรอจนกว่าทรัพยากรจะพร้อมทำงานปัจจุบันให้เสร็จ ความล่าช้าเพิ่ม cycle time และป้องกันไม่ให้ลูกค้าได้รับคุณค่า
• Motion (การเคลื่อนย้าย): ปริมาณความพยายามในการย้ายข้อมูลหรือวัสดุจาก work center หนึ่งไปยังอีก work center หนึ่ง ของเสียจากการเคลื่อนย้ายสามารถเกิดขึ้นได้เมื่อคนที่ต้องสื่อสารกันบ่อยๆ ไม่อยู่ในสถานที่เดียวกัน Handoffs ก็สร้างของเสียจากการเคลื่อนย้ายเช่นกัน และมักต้องใช้การสื่อสารเพิ่มเติมเพื่อแก้ไขความคลุมเครือ
• Defects (ข้อบกพร่อง): ข้อมูล วัสดุ หรือผลิตภัณฑ์ที่ไม่ถูกต้อง ขาดหาย หรือไม่ชัดเจนก่อให้เกิดของเสีย เนื่องจากต้องใช้ความพยายามในการแก้ไขปัญหาเหล่านี้ ยิ่งเวลาระหว่างการสร้างข้อบกพร่องและการตรวจจับข้อบกพร่องนานเท่าไหร่ การแก้ไขข้อบกพร่องก็ยิ่งยากขึ้นเท่านั้น
นอกจากนี้เรายังเพิ่มของเสียอีกสองประเภทจาก Damon Edwards: 12
• Nonstandard or manual work (งานที่ไม่ได้มาตรฐานหรือทำด้วยมือ): การพึ่งพางานที่ไม่ได้มาตรฐานหรือทำด้วยมือจากผู้อื่น เช่น การใช้เซิร์ฟเวอร์ สภาพแวดล้อมการทดสอบ และการกำหนดค่าที่ไม่สามารถสร้างใหม่ได้ (non-rebuilding) ตามอุดมคติแล้ว งานที่ทำด้วยมือใดๆ ที่สามารถทำให้เป็นอัตโนมัติควรถูกทำให้เป็นอัตโนมัติ ให้บริการด้วยตนเอง และพร้อมใช้งานตามต้องการ อย่างไรก็ตาม งานที่ทำด้วยมือบางประเภทอาจยังจำเป็นอยู่เสมอ
• Heroics (การทำ heroic): เพื่อให้องค์กรบรรลุเป้าหมาย บุคคลและทีมงานถูกวางไว้ในตำแหน่งที่ต้องทำสิ่งที่เกินสมควร ซึ่งอาจกลายเป็นส่วนหนึ่งของงานประจำวันของพวกเขา (เช่น ปัญหาใน production เวลา 2:00 AM ทุกคืน การสร้าง work tickets หลายร้อยใบในทุก software release)
เป้าหมายของเราคือการทำให้ของเสียและความยากลำบากเหล่านี้ — ทุกที่ที่จำเป็นต้องมี heroic — มองเห็นได้ และดำเนินการอย่างเป็นระบบเพื่อบรรเทาหรือกำจัดภาระและความยากลำบากเหล่านี้ เพื่อบรรลุเป้าหมายของ flow ที่รวดเร็ว
CASE STUDY: NEW TO SECOND EDITION
Flow และการจัดการข้อจำกัดใน Healthcare (2021)
ทฤษฎี DevOps และการจัดการข้อจำกัดไม่ได้มีไว้สำหรับการพัฒนาซอฟต์แวร์หรือการผลิตทางกายภาพเท่านั้น แต่สามารถนำไปประยุกต์ใช้ได้กับเกือบทุกสถานการณ์ ลองดูกรณีศึกษาจากอุตสาหกรรมการดูแลสุขภาพนี้ ที่ DevOps Enterprise Summit 2021 ดร. Chris Strear แพทย์ฉุกเฉินที่มีประสบการณ์มากกว่า 19 ปี ได้เล่าประสบการณ์ของเขาในการปรับปรุงผลลัพธ์ของผู้ป่วยโดยการทำงานกับ flow 13
ประมาณปี 2007 โรงพยาบาลของเรามีปัญหาใหญ่ เรามีปัญหาเรื่อง flow ที่เหลือเชื่อ เราต้องรับผู้ป่วยค้างคืนในแผนกฉุกเฉินเป็นเวลาหลายชั่วโมง บางครั้งหลายวัน ขณะที่พวกเขารอเตียงผู้ป่วยใน (inpatient bed)
โรงพยาบาลของเราแน่นมากและ flow ตันมากจนแผนกฉุกเฉินของเราต้องปฏิเสธผู้ป่วยจากรถพยาบาล (ambulance diversion) เฉลี่ยหกสิบชั่วโมงต่อเดือน นั่นหมายความว่าเป็นเวลาหกสิบชั่วโมงต่อเดือนที่แผนกฉุกเฉินของเราปิดให้บริการผู้ป่วยที่ป่วยหนักที่สุดในชุมชนของเรา เดือนหนึ่งเรามี diversion ถึงสองร้อยชั่วโมง
มันแย่มาก เราไม่สามารถรักษาพยาบาลให้อยู่ได้ มันเป็นสถานที่ทำงานที่ยากลำบากจนพยาบาลลาออก และเราต้องพึ่งพาพยาบาลชั่วคราว เอเจนซี่จัดหาพยาบาล หรือพยาบาลรับจ้างเดินทาง (traveler nurses) เพื่อเติมเต็มช่องว่างของอัตรากำลัง โดยส่วนใหญ่แล้ว พยาบาลเหล่านี้มีประสบการณ์ไม่เพียงพอที่จะทำงานในสภาพแวดล้อมฉุกเฉินแบบที่เราปฏิบัติ มันรู้สึกอันตรายที่จะมาทำงานทุกวัน มันรู้สึกอันตรายที่จะดูแลผู้ป่วย เรากำลังรอให้สิ่งเลวร้ายเกิดขึ้น
ประธานของโรงพยาบาลตระหนักว่าสถานการณ์แย่แค่ไหน และเธอได้จัดตั้งคณะกรรมการเพื่อปรับปรุง flow และฉันโชคดีที่ได้อยู่ในคณะกรรมการนั้น...
[การเปลี่ยนแปลง] เป็นการปฏิวัติ ภายในหนึ่งปี เราสามารถยกเลิกการปฏิเสธผู้ป่วยจากรถพยาบาลได้เกือบหมด จากหกสิบชั่วโมงต่อเดือน [ของการปฏิเสธรถพยาบาล] เหลือเพียงสี่สิบห้านาทีต่อเดือน เราปรับปรุงระยะเวลาการพักรักษาตัว (length of stay) ของผู้ป่วยที่เข้ารับการรักษาในโรงพยาบาลทั้งหมด เราทำให้ระยะเวลาที่ผู้ป่วยใช้ในแผนกฉุกเฉินสั้นลง เราแทบจะกำจัดผู้ป่วยที่ออกจากแผนกโดยไม่ได้รับการรักษาเพราะรอนานเกินไป และเราทำทั้งหมดนี้ในช่วงเวลาที่มีปริมาณผู้ป่วย ปริมาณรถพยาบาล และปริมาณการรับเข้ารักษาเป็นประวัติการณ์
[การเปลี่ยนแปลง] นั้นน่าทึ่งมาก เราดูแลผู้ป่วยได้ดีขึ้น มันปลอดภัยขึ้น และมันรู้สึกง่ายขึ้นมากในการดูแลผู้ป่วย มันเป็นการพลิกกลับที่ยอดเยี่ยมมาก จนเราสามารถหยุดจ้างพยาบาลชั่วคราวได้ เราสามารถเติมเต็มพนักงานของเราด้วยพยาบาลฉุกเฉินประจำที่มีคุณสมบัติเหมาะสม และที่จริงแล้ว แผนกของเรากลายเป็นอันดับหนึ่งที่พยาบาลฉุกเฉินอยากมาทำงานในพื้นที่ Portland/Vancouver
จริงๆ แล้ว ฉันไม่เคยเป็นส่วนหนึ่งของอะไรที่ยอดเยี่ยมขนาดนั้นมาก่อน และก็ไม่ได้เป็นอีกเลยหลังจากนั้น เราทำให้การดูแลผู้ป่วยดีขึ้นสำหรับผู้ป่วยหลายหมื่นคน และทำให้ชีวิตดีขึ้นสำหรับบุคลากรทางการแพทย์หลายร้อยคนในโรงพยาบาลของเรา 14
แล้วพวกเขาจัดการพลิกกลับนี้ได้อย่างไร? ก่อนหน้านี้ Chris ได้รู้จักกับหนังสือ The Goal การจัดการข้อจำกัด (constraint management) มีอิทธิพลอย่างลึกซึ้งต่อเขาและวิธีที่เขาจัดการกับปัญหา flow ที่โรงพยาบาลของเขา
ฉันถูกถามหลายครั้งว่าอะไรคือความแตกต่าง? ฉันไม่ได้มีคำตอบทั้งหมด แต่ฉันเห็นแนวโน้มบางอย่าง ฉันเห็นธีมซ้ำๆ บางอย่าง Flow ต้องมีความสำคัญต่อผู้นำ ไม่ใช่แค่ในคำพูด แต่ในการกระทำ พวกเขาต้องเดินตามรอย (walk the walk) ไม่ใช่แค่พูด (talk the talk) และผู้นำหลายคนก็ไม่ได้ทำแบบนั้น
ส่วนหนึ่งคือพวกเขาต้องสร้างแบนด์วิดท์ ผู้นำโรงพยาบาลจะไม่ใช่คนที่ลงมือเปลี่ยนแปลงในแต่ละวันจริงๆ สิ่งที่พวกเขาต้องทำคือ พวกเขาต้องปล่อยให้คนที่กำลังจะทำการเปลี่ยนแปลงเหล่านั้นมีพื้นที่ว่างเพียงพอในจานของพวกเขาที่จะลงมือทำงาน ตัวอย่างเช่น ถ้าหัวหน้าพยาบาลมีสิบห้าโปรเจกต์ มีการประชุมคณะกรรมการสิบห้าครั้งที่ต้องเข้า วันแล้ววันเล่า และผู้นำเดินมาบอกว่า "Flow สำคัญนะ" แต่ตอนนี้ flow กลายเป็นงานที่สิบหกและการประชุมที่สิบหกที่พวกเขาต้องไป มันก็ไม่ได้บอกว่ามันสำคัญเลย มันแค่บอกว่ามันสำคัญเป็นอันดับที่สิบหกเท่านั้น
แล้วก็มีผู้จัดการที่จะไม่มีเวลาสำหรับโปรเจกต์ที่สิบหก ผู้นำต้องคิดให้ออกว่าอะไรสำคัญจริงๆ และอะไรที่รอได้ อะไรที่สามารถลดความสำคัญลงได้ จากนั้นจึงมีบทบาทอย่างแข็งขันในการเคลียร์งานบางส่วนออกจากจานของคน เพื่อที่พวกเขาจะได้ทำงาน มันไม่เพียงแค่ทำให้คนที่ต้องทำงานมีประสิทธิภาพมากขึ้นเท่านั้น แต่มันยังสื่อให้พวกเขารู้ในความรู้สึกที่จริง จับต้องได้ และชัดเจนว่าโปรเจกต์ใหม่นี้ flow คืองานที่สำคัญที่สุด
คุณต้องทำลายไซโล (silos) คุณกำลังมอง flow ผ่านระบบ คุณไม่ได้มอง flow แค่ในหน่วยผู้ป่วยใน หรือ flow แค่ในแผนกฉุกเฉิน เพราะแต่ละแผนกเมื่อมองแบบแยกส่วนแล้วมีความสนใจที่ขัดแย้งกัน เมื่อคุณย้ายผู้ป่วยออกจากแผนกฉุกเฉินไปยังหน่วยผู้ป่วยใน คุณกำลังสร้างงานให้กับหน่วยผู้ป่วยใน คุณให้แรงจูงใจกับคนต่างกันทั่วทั้งโรงพยาบาล
เมื่อคุณกำลังพูดถึงวิธีทำให้ flow ดีขึ้น และมีคนบอกว่าไม่ได้ มันไม่ควรหยุดแค่นั้น "ไม่ได้" ไม่ควรเป็นคำสุดท้าย ฉันได้ยินครั้งแล้วครั้งเล่าว่า "เราทำแบบนั้นไม่ได้เพราะเราไม่เคยทำแบบนั้นมาก่อน" และมันไร้สาระ "ไม่ได้" นั้นโอเค ตราบใดที่มีไอเดียอื่นให้ลองตามมา เพราะถ้าฉันมีไอเดียห่วยๆ แต่มันเป็นไอเดียเดียวที่มีอยู่ แล้วคุณรู้ไหม? ไอเดียห่วยๆ ของฉันคือไอเดียที่ดีที่สุดที่เรามี และนั่นคือสิ่งที่เราจะลอง
ผู้นำต้องแน่ใจว่าพวกเขากำลังวัดผลสิ่งที่ถูกต้อง และให้รางวัลอย่างรอบคอบ แล้วฉันหมายถึงอะไร? ส่วนหนึ่งของไซโลในโรงพยาบาลคือผู้จัดการของแผนกใดแผนกหนึ่งมักจะถูกวัดจากผลลัพธ์ในแผนกของตนเท่านั้น และพวกเขาได้รับรางวัลตามนั้น ผู้คนจะปฏิบัติตามวิธีที่พวกเขาถูกวัดและได้รับรางวัล ดังนั้น ถ้าการปรับปรุง flow ในแผนกฉุกเฉินเป็นสิ่งที่ถูกต้องสำหรับผู้ป่วยและถูกต้องสำหรับระบบโรงพยาบาล แต่มันอาจโยกย้ายภาระไปยังหน่วยอื่น และหน่วยนั้นก็มี metric ตกต่ำลง นั่นก็ควรจะโอเค เพราะ flow โดยรวมของโรงพยาบาลดีขึ้น ใครจะสนใจ flow ในหน่วยเดียว?
ตรวจสอบให้แน่ใจว่าสิ่งที่คุณวัดนั้นสอดคล้องกับเป้าหมายโดยรวมของคุณ ตรวจสอบให้แน่ใจว่าคนได้รับรางวัลอย่างเหมาะสม และพวกเขาไม่ถูกลงโทษอย่างไม่เป็นธรรมจากการปรับปรุง flow ผ่านระบบ คุณต้องคิดถึงระบบ ไม่ใช่แค่แผนก
และสุดท้าย วิธีที่เราจัดตั้งสิ่งต่างๆ ขึ้นมา ทั้งหมดนั้นเป็นสิ่งประดิษฐ์ (artificial) มันเป็นข้อจำกัด ไม่ใช่กฎธรรมชาติของฟิสิกส์ จงจำสิ่งนี้ไว้ เพราะการต่อต้านส่วนใหญ่มาจากความไม่แน่นอนของการทำสิ่งที่แตกต่างออกไป
บ่อยครั้งมีความคิดที่ว่าเพราะเราไม่เคยทำอะไรในรูปแบบใดรูปแบบหนึ่งมาก่อน มันจึงทำไม่ได้ แต่เราเป็นคนสร้างสิ่งเหล่านี้ขึ้นมาทั้งหมด ร่างกายตอบสนองต่อการรักษาอย่างไร นั่นไม่ใช่สิ่งประดิษฐ์ นั่นคือกฎธรรมชาติ แต่คุณจะวางผู้ป่วยไว้ที่ไหน ใครเป็นผู้รับผิดชอบพวกเขา คุณจะย้ายผู้ป่วยจากหน่วยหนึ่งไปยังอีกหน่วยหนึ่งอย่างไร เราแค่คิดค้นสิ่งเหล่านี้ขึ้นมาแล้วสืบสานต่อกันมา ทั้งหมดนี้ต่อรองได้ 15
กรณีศึกษานี้แสดงให้เห็นอย่างเป็นรูปธรรมถึงการใช้ทฤษฎีข้อจำกัด (Theory of Constraints) ของ Goldratt และห้าขั้นตอนการโฟกัสของเขาในการระบุและทำให้ข้อจำกัดนั้นชัดเจน และปรับปรุง flow ในตัวอย่างนี้ flow ของคนผ่านระบบโรงพยาบาลแสดงให้เห็นว่าทฤษฎีนี้สามารถนำไปประยุกต์ใช้กับทุกสภาพแวดล้อม ไม่ใช่แค่การผลิตหรือการพัฒนาซอฟต์แวร์เท่านั้น
บทสรุป (Conclusion)
การปรับปรุง flow ผ่านสายธารแห่งคุณค่าด้านเทคโนโลยีเป็นสิ่งจำเป็นต่อการบรรลุผลลัพธ์ของ DevOps เราทำสิ่งนี้โดยทำให้งานมองเห็นได้ การจำกัด WIP การลดขนาด batch และจำนวน handoff การระบุและประเมินข้อจำกัดของเราอย่างต่อเนื่อง และการกำจัดความยากลำบากในงานประจำวันของเรา
แนวปฏิบัติเฉพาะที่ช่วยให้เกิด fast flow ในสายธารแห่งคุณค่าของ DevOps ถูกนำเสนอใน Part IV ของหนังสือเล่มนี้ ในบทถัดไป เราจะนำเสนอวิธีที่สอง (The Second Way): หลักการของ Feedback
Taiichi Ohno เปรียบเทียบการบังคับใช้ WIP limits กับการระบายน้ำออกจากแม่น้ำของสินค้าคงคลัง เพื่อเผยให้เห็นปัญหาทั้งหมดที่ขัดขวาง flow ที่รวดเร็ว 3 | |
หรือที่รู้จักในชื่อ "batch size of one" หรือ "1x1 flow" ซึ่งเป็นคำที่หมายถึง batch size และ WIP limit ที่เท่ากับหนึ่ง |