Lean vs Kanban

Lean (ลีน) คือการประยุกต์ใช้หลักการผลิตแบบลีน (Lean Manufacturing) ในการพัฒนาและจัดการผลิตภัณฑ์และบริการ Lean มีรากฐานมาจากระบบการผลิตของโตโยต้า (Toyota Production System) และมุ่งเน้นการเพิ่มคุณค่าให้ลูกค้าให้สูงสุดพร้อมกับลดของเสียให้น้อยที่สุด

Lean เป็นหนึ่งในปรัชญาที่มีอิทธิพลมากที่สุดในโลกธุรกิจ งานวิจัยของ MIT (2023) พบว่าองค์กรที่นำหลักการ Lean ไปใช้มีประสิทธิภาพการดำเนินงานดีขึ้น 25-35% และลดต้นทุน 20%

เป้าหมายคือเพิ่มมูลค่าที่มอบให้แก่ลูกค้าและผู้ใช้ให้สูงสุด ขณะเดียวกันก็ลดต้นทุนและของเสีย Lean นิยาม "คุณค่า" ว่าเป็นสิ่งที่ลูกค้ายินดีจ่ายเงินเพื่อมัน — ทุกอย่างอื่นคือของเสีย

หลักการ Lean 5 ประการ

1. กำหนดคุณค่า (Value) — ลูกค้าต้องการอะไรจริงๆ?
2. แมปสายธารคุณค่า (Value Stream) — ขั้นตอนในการสร้างคุณค่าคืออะไร?
3. สร้างการไหล (Flow) — ขจัดอุปสรรคเพื่อสร้างการไหลที่ราบรื่น
4. สร้างการดึง (Pull) — ผลิตตามความต้องการ ไม่ใช่ตามการคาดการณ์
5. แสวงหาความสมบูรณ์แบบ (Perfection) — มุ่งมั่นสู่ความเป็นเลิศอย่างต่อเนื่อง

Lean เติบโตมาจากระบบการผลิตของโตโยต้า (TPS — Toyota Production System) ที่พัฒนาหลังสงครามโลกครั้งที่สองโดยไทอิจิ โอโนะ (Taiichi Ohno) และเอจิ โตโยดะ (Eiji Toyoda)

เหตุการณ์สำคัญ:

• 1940s-1970s — พัฒนา TPS ที่โตโยต้า
• 1988 — John Krafcik บัญญัติคำว่า "Lean"
• 1990 — "The Machine That Changed the World" โดย Womack และ Jones
• 2003 — "Lean Software Development" โดย Mary & Tom Poppendieck
• 2011 — "The Lean Startup" โดย Eric Ries

Lean ระบุของเสีย 7 ประเภทที่ต้องลด:

1. การขนส่ง (Transport) — การเคลื่อนย้ายวัสดุหรือข้อมูลที่ไม่จำเป็น
2. สินค้าคงคลัง (Inventory) — งานระหว่างทำที่รอและไม่เคลื่อนไหว
3. การเคลื่อนไหว (Motion) — การเคลื่อนไหวที่ไม่จำเป็นของคน
4. การรอ (Waiting) — เวลาที่คนหรือกระบวนการรอ
5. การผลิตเกิน (Overproduction) — ผลิตมากกว่าที่ต้องการ
6. การแปรรูปเกิน (Over-processing) — ทำงานเกินความจำเป็น
7. ข้อบกพร่อง (Defects) — แก้ไขข้อผิดพลาดและข้อบกพร่อง

ของเสียในการพัฒนาซอฟต์แวร์

Lean ใช้ระบบดึง (Pull System) ที่ให้บริการตามคำขอของลูกค้าเพื่อลดการผลิตเกินความจำเป็นและของเสีย ระบบดึงเป็นพื้นฐานของ Kanban

หลักการดึง:

• ตามความต้องการ — ผลิตเฉพาะสิ่งที่ต้องการ
• Just-in-Time — ส่งมอบในเวลาที่เหมาะสม
• WIP Limits — จำกัดงานระหว่างทำ
• "หยุดเริ่ม เริ่มเสร็จ" — ให้ความสำคัญกับการเสร็จมากกว่าการเริ่ม

Mary และ Tom Poppendieck ปรับหลักการ Lean สำหรับการพัฒนาซอฟต์แวร์ในหนังสือ "Lean Software Development" (2003):

หลักการ Lean 7 ข้อในซอฟต์แวร์

1. ขจัดของเสีย — ระบุและกำจัดกิจกรรมที่ไม่เพิ่มคุณค่า
2. สร้างคุณภาพจากภายใน — TDD, BDD, Code Review
3. สร้างความรู้ — เรียนรู้อย่างต่อเนื่องและทดลอง
4. ชะลอการตัดสินใจ — ตัดสินใจในช่วงเวลาสุดท้ายที่รับผิดชอบได้
5. ส่งมอบเร็ว — วงจรการส่งมอบสั้น
6. เคารพผู้คน — ความไว้วางใจ ความเป็นอิสระ และแรงจูงใจ
7. เพิ่มประสิทธิภาพทั้งหมด — มุมมองเชิงระบบ ไม่ใช่การเพิ่มประสิทธิภาพเฉพาะจุด

Eric Ries นำหลักการ Lean ไปใช้ในโลกสตาร์ทอัพ:

วงจร Build-Measure-Learn

1. Build (สร้าง) — สร้างเวอร์ชันขั้นต่ำ (MVP)
2. Measure (วัดผล) — วัดผลลัพธ์
3. Learn (เรียนรู้) — เรียนรู้จากข้อมูลและตัดสินใจ — ดำเนินต่อ (Persevere) หรือเปลี่ยนทิศ (Pivot)

แนวคิดสำคัญ

• MVP (Minimum Viable Product) — เวอร์ชันที่เรียบง่ายที่สุดเพื่อยืนยันสมมติฐาน
• Pivot — การเปลี่ยนทิศทางจากการเรียนรู้
• Validated Learning — การเรียนรู้ที่ยืนยันด้วยข้อมูล

Lean กับ Agile ต่างกันอย่างไร?

Lean มุ่งเน้นที่การขจัดของเสียและเพิ่มประสิทธิภาพการไหล มาจากโลกการผลิต Agile มุ่งเน้นที่การส่งมอบคุณค่าและความยืดหยุ่น มาจากโลกซอฟต์แวร์ ในทางปฏิบัติ ทั้งสองเสริมซึ่งกันและกัน

Lean เหมาะกับการผลิตเท่านั้นหรือ?

ไม่ Lean ถูกนำไปใช้อย่างประสบความสำเร็จในซอฟต์แวร์ (DevOps) บริการ สาธารณสุข การศึกษา และเกือบทุกสาขา หลักการขจัดของเสียและเพิ่มคุณค่าเป็นสากล

Lean กับ Kanban เกี่ยวข้องกันอย่างไร?

Kanban เป็นวิธีการที่เติบโตมาจาก Lean โดยนำหลักการ Lean เรื่องการไหล Pull และ WIP Limits มาใช้ในการจัดการงาน

เริ่มต้นใช้ Lean อย่างไร?

1. แมปสายธารคุณค่า (Value Stream Mapping)
2. ระบุของเสียในกระบวนการ
3. นำการปรับปรุงเล็กๆ ไปใช้ (Kaizen)
4. วัดผลลัพธ์
5. ทำซ้ำกระบวนการ

• Kanban — วิธีการที่เกิดจาก Lean
• Kaizen — การปรับปรุงอย่างต่อเนื่อง
• Agile — ปรัชญาที่เสริมกัน
• Scrum — กรอบงาน Agile
• Cycle Time — ตัวชี้วัดหลักของ Lean
• Lead Time — เวลาทั้งหมดจากคำขอถึงการส่งมอบ
• DevOps — การประยุกต์ Lean ในการดำเนินงาน IT

Kanban คือวิธีการ (Method) แบบ Lean สำหรับการจัดการและปรับปรุงการไหลของงานในกระบวนการการผลิต การพัฒนา และการบริการ โดยมุ่งเน้นที่การส่งมอบคุณค่าอย่างต่อเนื่องโดยไม่ทำให้ทีมงานมีภาระงานมากเกินไป และใช้ระบบภาพในการติดตามความคืบหน้าของงาน คำว่า "Kanban" (看板) มาจากภาษาญี่ปุ่น แปลว่า "สัญญาณภาพ" หรือ "บัตร"

Kanban เป็นหนึ่งในสองวิธีการ Agile ที่ได้รับความนิยมมากที่สุดในโลก ควบคู่กับ Scrum จากรายงาน State of Agile ปี 2024 พบว่าประมาณ 13% ของทีมใช้ Kanban เป็นวิธีการหลัก และอีกหลายทีมผสมผสานกับ Scrum ("Scrumban")

Kanban ถูกพัฒนาครั้งแรกในช่วงทศวรรษ 1940 โดยไทอิจิ โอโนะ (Taiichi Ohno) ที่บริษัทโตโยต้า (Toyota) เป็นส่วนหนึ่งของระบบการผลิตแบบโตโยต้า (Toyota Production System) จุดมุ่งหมายเพื่อเพิ่มประสิทธิภาพของกระบวนการผลิตโดยการมองเห็นงาน ลดของเสีย (Muda) และปรับการผลิตให้สอดคล้องกับความต้องการจริง

ระบบดั้งเดิมใช้บัตรจริงที่ไหลระหว่างสถานีงาน บัตรแต่ละใบแทนรายการงานหนึ่งรายการ เมื่อสถานีหนึ่งทำงานเสร็จ บัตรจะถูกส่งกลับไปเป็นสัญญาณให้สถานีก่อนหน้าผลิตรายการถัดไป — นี่คือพื้นฐานของระบบดึง (Pull System)

Kanban ขยายจากการผลิตไปสู่การพัฒนาซอฟต์แวร์ในช่วงทศวรรษ 2000 ส่วนใหญ่เป็นผลจากผลงานของ David J. Anderson หนังสือของเขา "Kanban: Successful Evolutionary Change for Your Technology Business" (2010) กลายเป็นหมุดหมายสำคัญในสาขานี้

Anderson กำหนดแนวปฏิบัติหลัก 6 ประการของ Kanban:

1. ทำให้งานมองเห็นได้ (Visualize) — ทำให้งานเป็นที่มองเห็น
2. จำกัดงานระหว่างทำ (Limit WIP) — ป้องกันการโอเวอร์โหลด
3. จัดการการไหล (Manage Flow) — ติดตามและเพิ่มประสิทธิภาพการไหล
4. ทำให้นโยบายชัดเจน (Make Policies Explicit) — กฎที่ชัดเจนสำหรับทุกคน
5. ใช้วงจรข้อเสนอแนะ (Implement Feedback Loops) — การตรวจสอบและทบทวนเป็นประจำ
6. ปรับปรุงร่วมกัน พัฒนาแบบทดลอง (Improve Collaboratively) — การพัฒนาทีละขั้น

ทีมงานใช้บอร์ด Kanban (Kanban Board) ในการมองเห็นการทำงานและติดตามความคืบหน้า บอร์ด Kanban ทั่วไปประกอบด้วยคอลัมน์ต่างๆ เช่น:

• To Do — งานที่รอเริ่ม
• In Progress — งานที่กำลังดำเนินการ
• Review — งานที่รอการตรวจสอบ
• Done — งานที่เสร็จสมบูรณ์

แต่ละรายการงานแทนด้วยการ์ด (Card) ที่เคลื่อนจากซ้ายไปขวาผ่านคอลัมน์ต่างๆ บอร์ดให้ภาพรวมทันทีของสถานะงานทั้งหมดในทีม

งานวิจัยแสดงให้เห็นว่าบอร์ด Kanban แบบภาพสามารถลดเวลาการสื่อสารในทีมได้ 30% และปรับปรุงการมองเห็นคอขวดได้ 50%

Kanban ส่งเสริมการปรับปรุงอย่างต่อเนื่อง (Kaizen) — การค้นหาและแก้ไขปัญหาในกระบวนการทำงานอย่างสม่ำเสมอ ต่างจากวิธีการที่ต้องการการเปลี่ยนแปลงแบบปฏิวัติ Kanban ส่งเสริมการเปลี่ยนแปลงแบบวิวัฒนาการ — การปรับปรุงเล็กๆ น้อยๆ ที่สะสมเป็นการเปลี่ยนแปลงที่สำคัญในระยะยาว

แนวทางของ Kanban คือ "เริ่มจากจุดที่คุณอยู่" — ไม่จำเป็นต้องเปลี่ยนบทบาท กระบวนการ หรือตำแหน่งที่มีอยู่ แต่ให้ค่อยๆ ปรับปรุงขณะทำงานไป

หนึ่งในแนวปฏิบัติหลักของ Kanban คือการจำกัด WIP (Work In Progress) — การกำหนดจำนวนสูงสุดของงานที่สามารถอยู่ในแต่ละขั้นตอนพร้อมกัน

ทำไม WIP Limits จึงสำคัญ?

• เพิ่มสมาธิ — งานคู่ขนานน้อยลง = ความเข้มข้นมากขึ้นในแต่ละงาน
• ลด Lead Time — งานเสร็จเร็วขึ้นเมื่อมีการทำงานหลายอย่างพร้อมกันน้อยลง
• ค้นพบคอขวด — เมื่อคอลัมน์ถึงขีดจำกัด แสดงว่ามีปัญหา
• เพิ่มคุณภาพ — แต่ละรายการงานได้รับความสนใจมากขึ้น

งานวิจัยปี 2023 พบว่าทีมที่นำ WIP Limits ไปใช้มี Cycle Time ลดลง 40% และ Bug ลดลง 25%

ตัวอย่างเชิงตัวเลข

ถ้าทีม 5 คนจำกัดคอลัมน์ "In Progress" ไว้ที่ 5 งาน นักพัฒนาแต่ละคนจะมุ่งเน้นที่งานเดียวในเวลาใดก็ตาม ถ้านักพัฒนาคนใดติดขัด พวกเขาจะขอความช่วยเหลือแทนที่จะเริ่มงานใหม่

ระบบดึง (Pull System) ใน Kanban ส่งเสริมให้ทำงานให้เสร็จก่อนที่จะเริ่มงานใหม่ โดยเน้นที่ความสามารถและความต้องการจริงของทีม แนวทางนี้แตกต่างอย่างสิ้นเชิงจาก "ระบบผลัก" (Push System) ที่งานถูกผลักเข้าสู่ทีมโดยไม่คำนึงถึงความสามารถ

หลักการของระบบดึง:

• "หยุดเริ่ม เริ่มเสร็จ" (Stop Starting, Start Finishing) — ให้ความสำคัญกับการเสร็จมากกว่าการเริ่ม
• ทำงานตามความต้องการ — งานใหม่เข้ามาเมื่อมีที่ว่างเท่านั้น
• ลดของเสีย — งานที่ไม่จำเป็นน้อยลงและ Context Switching น้อยลง
• การไหลที่ราบรื่น — งานไหลอย่างต่อเนื่องผ่านระบบ

Kanban อาศัยตัวชี้วัดเชิงปริมาณเพื่อปรับปรุงกระบวนการ:

Lead Time

เวลาทั้งหมดตั้งแต่คำขอเข้าสู่ระบบจนกว่าจะเสร็จสิ้น Lead Time รวมเวลารอด้วย

Cycle Time

เวลาที่ใช้ในการทำงานตั้งแต่เริ่มจนถึงเสร็จ Cycle Time เป็นตัวชี้วัดสำคัญของประสิทธิภาพทีม

Throughput

จำนวนรายการงานที่ทีมทำเสร็จต่อหน่วยเวลา (สัปดาห์/เดือน)

Cumulative Flow Diagram (CFD)

CFD เป็นแผนภูมิที่แสดงจำนวนรายการงานในแต่ละขั้นตอนตลอดเวลา สามารถระบุแนวโน้ม คอขวด และปัญหาการไหลได้

เครื่องมือดิจิทัลยอดนิยมสำหรับการใช้ Kanban:

• Jira — เครื่องมือมืออาชีพที่ได้รับความนิยมมากที่สุด มีการสนับสนุน Kanban ขั้นสูง
• Trello — เรียบง่ายและใช้งานง่าย เหมาะสำหรับทีมขนาดเล็ก
• Asana — ผสมผสานการจัดการงานกับบอร์ด Kanban
• Azure DevOps — เหมาะสำหรับทีม DevOps
• Notion — ยืดหยุ่น เหมาะกับงานหลายประเภท

Kanban ต้องการการฝึกอบรมพิเศษหรือไม่?

ไม่ หนึ่งในข้อดีที่สำคัญของ Kanban คือสามารถเริ่มต้นจากกระบวนการที่มีอยู่และค่อยๆ เพิ่มแนวปฏิบัติ อย่างไรก็ตาม มีใบรับรอง เช่น KMP (Kanban Management Professional) ให้เลือก

Kanban เหมาะกับทีมขนาดใหญ่หรือไม่?

ใช่ Kanban เหมาะกับทีมทุกขนาดและองค์กรทั้งหมด "Kanban at Scale" ช่วยให้สามารถนำวิธีการไปใช้ในระดับองค์กร

Kanban Board กับ Scrum Board ต่างกันอย่างไร?

Kanban Board เป็นแบบต่อเนื่อง — งานไหลโดยไม่มีกำหนดเวลา Scrum Board รีเซ็ตในทุก Sprint นอกจากนี้ Kanban Board มี WIP Limits ที่ชัดเจน

จะกำหนด WIP Limits อย่างไร?

จุดเริ่มต้นที่นิยม: จำนวนสมาชิกทีม x 1.5 เช่น ทีม 4 คน เริ่มที่ WIP Limit 6 แล้วปรับตามประสบการณ์

สามารถใช้ Kanban โดยไม่มีเครื่องมือดิจิทัลได้หรือไม่?

ได้แน่นอน! บอร์ดจริงที่ใช้กระดาษโน้ตติดเป็นวิธีที่ยอดเยี่ยมในการเริ่มต้น บอร์ดจริงให้การมองเห็นทันทีและส่งเสริมปฏิสัมพันธ์แบบเห็นหน้า

• Scrum — กรอบงาน Agile ชั้นนำ
• Lean — ปรัชญาที่เป็นรากฐานของ Kanban
• Kaizen — การปรับปรุงอย่างต่อเนื่อง
• Cycle Time — เวลาในการทำงาน
• Lead Time — เวลาทั้งหมดจากคำขอถึงการส่งมอบ
• DevOps — การรวมการพัฒนาและการดำเนินงาน
• Jira — เครื่องมือจัดการโครงการ