Scroll ลง เพื่อดูบทความ
เบื้องหลังเชิง Technical ของระบบรายงานผลเลือกตั้งร่วมกับ Workpoint News
โดย PanJ
การเลือกตั้งเมื่อวันที่ 24 มีนาคม ที่ผ่านมาหลาย ๆ คนน่าจะเคยได้ดูการรายงานผลแบบ Real-time ของ Workpoint News ที่เว็บ https://vote.workpointnews.com ซึ่งจัดทำโดยทีม Cleverse ของเรา บทความนี้ จะมาเล่าถึ ...
ไขปริศนา ความท้าทายต่าง ๆ ในการก้าวไปสู่ตำแหน่ง CTO
โดย PanJ
ในสายอาชีพ programmer/developer ตำแหน่งที่คนส่วนใหญ่คิดว่าสูงที่สุดแล้วน่าจะหนีไม่พ้น Chief Technology Officer หรือ CTO ซึ่งมีชื่อเรียกภาษาไทยเก๋ ๆ ว่าประธานเจ้าหน้าที่บริหารฝ่ายเทคโนโลยี เอาจริง ๆ แล ...
Solving BigData with BigQuery (3/3) — ใช้จริง
โดย SARIN
บทความนี้จะมีเนื้อหาเกี่ยวกับ Google BigQuery: Serverless Data Warehouse จาก Google ครับ บทความนี้เป็นเนื้อหาพาร์ทสุดท้ายจาก ซีรีส์แนะนำ Google BigQuery ของ Cleverse โดยบทความนี้จะเน้นไปที่แนวทางต่างๆ ...
Solving BigData with BigQuery (2/3) — ลองเล่น
โดย SARIN
คุณมีปัญหากับการวิเคราะห์ข้อมูลขนาดใหญ่ใช่ไหม? — ลองมาใช้ BigQuery ดูสิ 0) เกริ่นนำ หากคุณเป็นคนที่ทำงานในสายงาน Data Science หรือใกล้เคียง คุณอาจจะเคยได้ยินคนพูดถึง BigQuery มาบ้าง สรุปแบบสั้นๆเลยคือ ...
Solving BigData with BigQuery (1/3) — บทนำ
โดย SARIN
หลายๆคนอาจจะมองว่าการจัดการ Big Data เป็นเรื่องลำบาก — ตั้งแต่การวางแผนติดตั้งระบบ การนำข้อมูลเข้า จนถึงการ Query ข้อมูลแต่ละครั้งซึ่งทำได้ยากและใช้เวลานาน แถมพอใช้งานจริงก็ต้องคอยดูแลอีก วันนี้บล็อกน ...
ของโคตรดี! เมื่อแทนที่ GraphQL Backend ด้วย Graphcool!
โดย ชิน
สำหรับท่านที่ไม่เคยใช้ GraphQL มาก่อน น่าจะเคยใช้ชีวิตร่วมกับ REST มาก่อน ซึ่งตัว REST จะมีความต่างที่ชัดเจนจาก GraphQL คือ REST เราต้องกำหนด endpoint เต็มไปหมด ถ้า model เปลี่ยนไปเรื่อยๆต้องมาแก้ทีละ ...
ENGINEERING
DESIGN
CULTURE
Cleverse, a venture builder, with people who have fun building the future. If you also consider building the future a fun and meaningful purpose — let’s find a way we can work together.
121/75 RS TOWER 24th Floor
Ratchadaphisek Road
Dindaeng Bangkok 10400
Thailand
09.Nov.2018
โดย Nut

LEAN แนวคิดทำน้อยแต่ได้ผลมาก

Scroll down
แนวคิดที่ช่วยให้งานเสร็จไว มีประสิทธิภาพ ลดสิ่งที่ไม่จำเป็น เค้นกำไร
ผมทำงานเป็น Software Engineer ก็อยากจะเพิ่มประสิทธิภาพให้งาน ทำไงให้ไว
ลดต้นทุน ทำงานน้อยๆ ได้ผลมากๆ กำไรมาก ตัดสิ่งที่ไม่จำเป็นตอนไหนดี ก็เลยสนใจในเรื่องกระบวนการทำงาน จนได้มาศึกษาจากคนรอบตัว และ อ่านหนังสือ พอดีที่ Cleverse มี knowledge sharing กัน แล้วผมเล่าเรื่องนี้เลยนำมาเขียนอีกรอบ ก็มีการนำไปใช้ในหลากหลายกรณีอย่างเช่นบทความลิงค์นี้ LEAN แนวคิดที่ช่วยให้ STARTUP ปรับตัวไว

LEAN คือ แนวคิดที่ช่วยให้ทำงานเสร็จไว

และมีประสิทธิภาพโดยกำจัดสิ่งที่สูญเปล่า

1. คุณค่า กับ ความสูญเปล่า

สิ่งที่สูญเปล่า (Muda) มีอยู่ทุกที่ เราต้องแยกให้ออกว่า สิ่งไหนสร้างคุณค่าในระยะยาว สิ่งไหนเป็นความสูญเปล่าที่ควรจะลดหรือกำจัด

สิ่งใดก็ตามที่ไม่ส่งผลให้เกิดการเรียนรู้ การพัฒนาในระยะยาว นั่นคือความสูญเปล่า

KEYWORD: MUDA = WASTE = ความสูญเปล่า

ประเภทของความสูญเปล่า (Muda) ในแนวคิดของ LEAN มีอยู่หลายอย่างเหมือนกัน

source: https://www.whatissixsigma.net/seven-types-of-waste/seven-types-of-waste/

7 Muda + 1

  • Overproduction ผลิตเกิน
  • Inventory มีสินค้าคงคลัง
  • Transportation ต้องมีการขนย้าย
  • Motion เคลื่อนไหวไม่ถูกสุขลักษณะ
  • Processing มีขั้นตอนซับซ้อน
  • Delay ต้องรอ
  • Defect ของเสีย
  • Underutilized People ใช้คนไม่ถูกกับงาน

Muda Examples

ตัวอย่าง Muda ในแต่ละสถานการณ์ เพื่อเป็นแนวทางให้สามารถประยุกต์กับการทำงานได้หลายรูปแบบ

Muda ในโรงงาน

  • ยอดสั่ง 1000 ชิ้น ผลิตออกมา 1200 ชิ้น
  • ส่วนที่เกินอีก 200 ชิ้น ก็มีต้นทุนเหมือนกัน (Over Production)
  • ต้องขนย้าย (Transportation) ดูแลจัดเก็บ (Inventory)
  • เก็บไว้นานๆ ก็อาจจะเสียได้ (Defect)
  • ทำงานที่มากเกินไป ส่งผลไม่ดีต่อคนทำงาน (Motion)
  • ทำให้การขนส่งล่าช้า (Delay) เพิ่มขั้นตอนในการดูแล (Over Processing)
  • ต้องแบ่งคนไปดูแล ทั้งๆที่ควรจะไปทำอย่างอื่น (Underutilized People)

แค่ผลิตของเกิน เผื่อๆไว้ เหมือนจะดี ลองคิดดีๆว่า

จะส่งผลยังไงในทางบัญชี ?

Muda ในที่ทำงาน

  • ต้องเอื้อมหยิบจับอะไร บ่อยๆ นั่งไม่ถูกสุขลักษณะ (Motion)
  • อากาศไม่ถ่ายเท คนป่วยบ่อย ติดทั้งออฟฟิศ งานช้า (Motion)
  • ต้องเดินไปเดินมา เพราะของในที่ทำงานกระจัดกระจาย (Processing)
  • ซื้อของมาเผื่อไว้ แต่ไม่ได้ใช้ (Inventory) สุดท้ายเสีย (Defect)
  • ต้องรองานจากอีกคนนึงอยู่เสมอ (Delay)
  • ใช้คนที่ไม่ถนัดไปทำบางงาน ซึ่งอาจได้ผลไม่ดี (Underutilized People)
  • ทำงานให้สมบูรณ์แบบเลย เผื่อไว้เยอะๆ แต่ลูกค้าไม่ใช้ (Over production)
  • เดินทางไกลๆ ต้องเทียวไปเทียวมาบ่อยๆ (Transportation)

Muda ใน Software

  • เขียนโค้ดแล้วไม่ได้ใช้ (Over Production) ต้อง maintain ด้วย (Inventory)
  • เขียนทิ้งไว้นานๆ ไม่ค่อยได้ดู ก็น่าจะมี Bug (Defect)
  • เขียนโปรแกรมซับซ้อนหายาก (Over Processing)
  • ต้องรออีกคนทำ part นึงให้เสร็จก่อน ถึงจะทำต่อได้ (Delay)
  • ทำงานซ้ำๆ มีความเครียดเกินขึ้น (Motion)
  • ต้องเดินไปเดินมา เพื่อคุยกันแทนที่จะนั่งด้วยกัน สำหรับงานเดียวกัน (Motion)
  • การส่งมอบงานให้ลูกค้า โดยที่ต้องมาทำ manual อยู่เสมอ (Transportation)
  • ใช้คนที่ไม่ถนัดไปทำงาน ที่ไม่ชอบเลยจริงๆ (Underutilized People)

จากบทความที่ผมอ่านมานี้ ก็เปลี่ยนจาก Transportation → Task Switching
http://www.somkiat.cc/7-wastes-in-software-development/

Muda ในการสอบเข้า

  • อ่านบทที่ตัวเองรู้อยู่แล้ว
  • ทำโจทย์ที่เป็นจุดอ่อนตัวเองไม่ได้สักที
  • อ่านหนังสือไม่ตรงกับที่จะสอบ เช่น จะสอบ วิศวะ แต่อ่านสังคม
  • อดหลับอดนอนอ่านหนังสือ สุดท้ายป่วย พอพักนานๆ ก็ลืม
  • ไม่วางแผนว่าจะสอบเข้าคณะนี้ ต้องใช้อะไรบ้าง
  • เล่นมากเกินไป แบ่งเวลาไม่ดี ติดซีรีย์ ติดเกม

2. ลดละเลิก Muda

หลังจากที่เรารู้อยู่แล้วว่าเราต้องสิ้นเปลืองทรัพยากรไปแค่ไหนกับการที่มี Muda เนี่ย เราก็ควรที่จะรู้วิธีที่จะลดมัน

Ex. ยอดสั่งของต้องทำวันนี้ 1000 ชิ้น ไม่ควรที่จะผลิต 1200 ชิ้น (Over Production) เพราะจะเหลือและเก็บเป็นสินค้าคงคลัง (Inventory)

วิธีแก้คือ ผลิตให้พอดีตามยอด 1000 ชิ้น (Just In Time — JIT) ไม่ขาดไม่เกิน

Ex. เราต้องทำงานซ้ำๆ แล้วผิดพลาดบ่อย ในโรงงานแถมยังทำช้าอีก ชิ้นส่วนซับซ้อน

วิธีแก้คือ ทำแขนกลหรือหุ่นยนต์ขึ้นมา ให้ทำงานแทนเรา (Automation — JIDOKA)

JIT & JIDOKA

  • ทำงานให้พอดีในเวลาที่พอดี ไม่ขาดไม่เกิน
  • ค่อยๆพัฒนาไปใช้ automation ช่วยลดงานที่ต้องใช้คน
  • หรืออาจจะสร้างระบบงานที่ลดขั้นตอนได้
  • สั่งงานแค่ไหน อย่าทำเผื่อมาก
  • ดูความต่อเนื่องในงาน
  • มีการแจ้งเตือนเวลาเกิดเรื่องผิดปกติ เช่น server down

สองคำนี้เป็นสองเสาหลัก ในการทำงานด้วยแนวคิดของ LEAN ซึ่งเริ่มต้นมาจาก Toyota Production System

Toyota Production System (TPS)

TPS นับว่าเป็นจุดกำเนิดของ LEAN เลยก็ว่าได้

File:Lean manufactory house.png
source: https://commons.wikimedia.org/wiki/File:Lean_manufactory_house.png

ประวัติของ LEAN

Toyota Production System เกิดมาประมาณ 50 ปี แล้ว MIT เอาไปวิจัยสุดท้ายตั้งชื่อใหม่ว่า LEAN

แต่จริงๆ พวกนี้ ไม่ได้มีแค่ TOYOTA มีทั้ง Japanese Production System (JPS), Japanese Management System (JMS)

ถ้าพูดแนวเรื่อง LEAN คนที่ทำบริษัทญี่ปุ่นจะเข้าใจเรื่องพวกนี้ แต่บางทีก็อาจจะมีมุมมองและการตีความที่ต่างกันไป

3. LEAN มีหลายความหมาย

เป็นแนวคิด แล้วแต่คนตีความเวลานำไปใช้ ความเข้าใจในหลายแง่มุมจะทำให้ประยุกต์ใช้ได้ดีขึ้น ซึ่งเราก็ควรจะมองความหมายต่างๆ และภาพคร่าวๆก่อน

หัวใจของ LEAN ?

การออกจาก comfortzone คือการเรียนรู้ ค่อยเป็นค่อยไป

source: https://pixabay.com/en/chicks-animal-fluffy-poultry-573377/
source: https://pixabay.com/en/hahn-chickens-poultry-cockscomb-3607866/

จริงๆแล้ว LEAN เป็นกระบวนการวิทยาศาสตร์

กระบวนการวิทยาศาสตร์

สมมติฐาน → วางแผน → ทดลอง → วัดผล → ปรับปรุงการทดลอง

วางแผน = PLAN

ทดลอง = DO

วัดผล = CHECK

ปรับปรุง = ACT

Deming Cycle (PDCA)

วงจรในการพัฒนาคุณภาพ ปรับปรุงกระบวนการทำงาน อย่างต่อเนื่อง
เริ่มต้นจากวางแผน ไปจนถึงการปรับปรุง แบ่งเป็นรอบๆไป

PDCA ก็เหมือน อิทธิบาท 4 เมื่อคนเรามีความชอบ (ฉันทะ) ก็จะวางแผน (Plan)

จากนั้นก็ ลงมือทำ (วิริยะ, Do)

ไม่ว่าจะมอง LEAN ในมุมของ การออกจาก Comfortzone, การเรียนรู้ค่อยเป็นค่อยไป,
กระบวนการวิทยาศาสตร์ และ วงจรการพัฒนาคุณภาพ ทุกอย่างล้วนเหมือนกัน
คือ พัฒนาและปรับปรุงอย่างต่อเนื่อง (Continuous Improvement) หรือจะเรียกว่า KAIZEN

4. LEAN เป็นแนวคิด ส่วน KAIZEN เป็นวิถีปฏิบัติ

เพราะในโลกนี้ไม่มีอะไรสมบูรณ์แบบ เราจึงต้องพัฒนาต่อเนื่อง (KAIZEN)

Nothing is perfect → Continuous Improvement

KAIZEN (5Why)

  • เมื่อเกิดปัญหาขึ้น ให้ถามทำไม ไปเลย 5 ครั้ง จริงๆแล้วกี่ครั้งก็ได้ จนกว่าจะเจอต้นตอของปัญหา
  • ในแต่ละปัญหาที่เกิดขึ้นจะมีปัญหาในแต่ละชั้นอยู่ การถามทำไม เราจะมองปัญหา
    และแก้ออกได้ทีละชั้น จนสุดท้ายไปเจอที่ Root Cause
  • ส่วนใหญ่คนไทยอาจจะไม่ชอบคำถาม ทำไม ทำไม อาจจะเปลี่ยนเป็น
    อะไรคือสาเหตุของปัญหานี้หรอ ? ก็จะดู Soft ลง

KAIZEN (Gemba)

ไปดูมาให้เห็นกับตา อย่ามามโน

โดยปกติ มักจะพูดกันประมาณว่า ของจริง พื้นที่จริง ตัวเลขที่ได้มาไม่ได้มั่ว
แต่มีคนจริงๆ อยู่ข้างหลัง มีลูกค้าจริงๆอยู่ ต้องไปสัมผัส ต้องไปถามต้องไปคลุกคลี
ไม่ใช่แค่บอกว่าทำงานแล้วจะได้แบบนี้ แบบนี้นะ แต่ต้องลงไปดู
ไม่ว่าจะอยู่ระดับไหนก็ตาม
มีคำกล่าวว่า “ผู้จัดการโรงงานต้องล้างมือจากการเปื้อนน้ำมันวันละ 3 ครั้ง”
→ “อย่าอยู่แต่ในห้อง”

KAIZEN (สรุปแผ่นเดียว)

ไม่ว่าการประชุมจะใหญ่มากน้อยแค่ไหน ก็จะใช้แค่กระดาษแผ่นเดียว

Ex. ระดมปัญญาเพิ่ม yield

จาก 8 คนในแผนกเดียวกัน รวมเหลือ 1 แผ่นคนเดียว
Production engineer ดูคนละ part

จากนั้นก็ทุกสรุปมา ว่าเลือกวิธีไหน แล้วค่อยไปคุยกับฝ่ายอื่น เช่น Sale
ก็ยังทำสรุปแผ่นเดียวมาเรื่อยๆ

จุดเด่นคือเห็นแล้วเข้าใจ ไม่ใช่อ่านแล้วเข้าใจ (at a glance)
สำคัญที่ ไม่ได้ทำให้สมบูรณ์ในครั้งแรก ก็เขียนมาสักแผ่นก่อนแล้วค่อยแก้
KAIZEN แล้ว ต้อง KAIZEN ต่อได้อีก

KAIZEN (Standardization)

เมื่อเราพัฒนาปรับปรุงต่อเนื่องไปเรื่อยๆ เราทดลองกับวิธีใหม่ๆ

แล้วเราก็จัดทำมาตรฐานใหม่ เราจะอยู่ในระดับที่สูงขึ้นไปเรื่อยๆ

ตัวอย่างจากบริษัท Hitachi

พอดีผมได้จากลุงที่เคยทำงานกับบริษัท Hitachi เค้าบอกว่า ได้ให้ทางมหาวิทยาลัยต่างๆเพื่อให้ได้ศึกษาพัฒนาการ และเทคโนโลยี พอพูดถึง Kaizen เลยใช้ตัวอย่าง

เวลาผ่านไป ขนาดเล็กลง วัสดุใช้น้อยลง ต้นทุนต่ำลง

แต่มีอย่างเดียวที่เพิ่มขึ้นคือ ราคา แล้วจะไม่รวยได้ยังไง ?

Recap

  • ทำสิ่งที่จำเป็นในเวลาที่จำเป็น (Just in time → JIT)
  • แล้วค่อยๆพัฒนาไปเรื่อยๆ (Continuous Improvement)
  • เลือกสิ่งที่มี Impact หรือความเสี่ยงสูง มาจัดการก่อน
  • วางแผนไม่มากไปไม่น้อยไป

References

source: http://www.tpa.or.th/tpapublishing/book.php?bid=202&g=2&c=6
  •  มีตัวอย่างเกี่ยวกับ KAIZEN และแนวคิด
  • หลายเรื่องทำให้มองเห็นหลายแง่มุม
  • 5Why, Gemba
  • การเผชิญกับปัญหา ระดมปัญญา
  • พัฒนาปรับปรุงต่างๆ

Nut
Creative Hacker
คนธรรมดา ที่อยากทำ product ที่ไม่ธรรมดา
หลงใหลในเทคโนโลยี งานอดิเรกอ่านหนังสือ ฟังเพลง เล่นเกม
กีฬาที่ชอบคือ เทนนิส กับ หมากฮอส
Next Article
เราจะวัดความรัก(ของ user)ได้อย่างไร – Retention Rate พื้นฐาน
สมัครงาน