ว่าด้วยเรื่อง 3M

muri mura mudaวันนี้จะขอมาพูดเกี่ยวกับเรื่องของ 3M ที่ไม่ใช่ฟิล์มติดรถยนต์ ที่ที่ขอค้างไว้ตั้งแต่คราวก่อนว่า การที่ต้องมี multi-skilled team นั้นมีเพื่อมาแก้ปัญหาจากตัว M ทั้งสามนี้

ตัว M ทั้งสามตัวนั้นมาจาก คำภาษาญี่ปุ่น สามคำ ที่พอมาเขียนแบบใช้ตัวอักษรภาษาอังกฤษ (Romanji) แล้วขึ้นต้นด้วยตัว M เหมือนกัน เลยเรียกรวม ๆ ว่า 3M โดยคำทั้งสามคือ Muri, Mura, และ Muda ซึ่งทั้งสามสิ่งนี้เป็นส่ิงที่ในกระบวนการพัฒนาแบบลีน จะคอยจับจ้องและมุ่งกำจัดพวกมันให้ได้มากที่สุด เพราะเป็นตัวถ่วงให้ไม่สามารถส่งมอบคุณค่าให้กับลูกค้าอย่างรวดเร็วได้ มาว่ากันเลย

1. Muri – overburden – การทำงานหนักเกินไป

เครื่องจักรนั้นยังต้องมีการพักเพื่อซ่อมบำรุง คนเราก็เช่นกัน การทำงานที่หนักเกินไป หามรุ่งหามค่ำ ทำงานเต็มเวลา แล้วยังต้องมีโอทีอีก ไม่ใช่เรื่องที่ดี ในบริษัทที่ทำงานกันหนักเกินไปนั้น จะพบว่า ในช่วยแรกจะได้ผลกำไรดีเพราะ เมื่อชั่วโมงการทำงานมาก ก็จะได้ผลงานออกมามาก ก็ได้กำไรมาก แต่ทว่า เมื่อเวลาผ่านไป คนกลับเหนื่อยล้า ทำให้ไม่สามารถโฟกัสกับงานได้ ก็จะเกิดความผิดพลาดขึ้น กลายเป็น ยิ่งทำก็ยิ่งต้องเสียเวลากลับไป แก้ไขสิ่งที่ทำผิดพลาดไว้ ซ้ำแล้วซ้ำอีก ลองนึกถึงเวลาที่เราทำงานโอทีดึก ๆ แต่ก็ไม่สามารถหาสาเหตุของปัญหาได้ แต่พอ รุ่งเช้า กลับมาดูกลับคิดออก ได้ง่าย ๆ นี่เป็นตัวอย่างหนึ่งของปัญหานี้ นอกจากนี้การที่มุ่งแต่ทำผลงานมากจนเกินไป ใช่ช่วงแรกจะได้ผลงานมาก แต่เมื่อเวลาผ่านไป ความที่ขาดโอกาสในการศึกษาหาความรู้ใหม่ ๆ ตลอดจนการติดตามและเพิ่มประสิทธิภาพของระบบงาน เช่น การทำ Process Improvement หรือ การ update framework ต่าง ๆ หรือ upgrade tools ที่ใช้ในการพัมนา สุดท้ายแล้ว ผลกำไรที่ได้ก็จะหมดไปกับการเสียโอกาส ในการแข่งขันเหล่านี้ ใน XP (eXtreme Programming) จะให้คำแนะนำไว้ว่า เมื่อสิ้นวัน เราควรจะรู้สึก “เหนือย แต่ไม่ล้า – Tired but not exhausted”

2. Mura – unevenness – ความไม่สม่ำเสมอ

การทำงานแบบลีนนั้น จะมุ่งเป้าการทำงานแบบ เต่าเอาชนะกระต่าย คือเน้นที่การสร้างความสม่ำเสมอในการทำงาน ลีนพบว่า การที่มีบางคนในทีม มีงานมาก ในขณะที่อีกคนไม่มีงาน หรือมีงานน้อยเกินไป จะทำให้ประสิทธิภาพการทำงานลดลง หรือ ไม่ก็ ช่วงต้น โปรเจ็ค งานเบา แต่พอจะปิดเฟส งานก็หนักมาก พูดง่าย ๆ คือ ความไม่สม่ำเสมอ จะทำให้เกิด การทำงานหนักเกินไป นั่นเอง ตัวอย่างของปัญหานี้คือ เมื่อเราสร้างทีมที่เป็น cross functional แล้ว แต่ยังคงรูปแบบการทำงานคล้าย waterfall อยู่ สมมติอาจเป็นว่า มี developer และ tester โดยที่ developer จะทำงานของตัวเองก่อน คือ การสร้างโค้ด ในเวลานั้น tester จะต้องนั่งคอย เพราะ ยังไม่มีอะไรให้ test แต่พอ developer บอกว่า เสร็จแล้วนะ งานก็ตกไปอยู่กับ tester ส่วน developer ก็ต้องนั่งว่าง ๆ ถ้าจะทำให้ซับซ้อนขึ้นอีก ก็คือ ในขณะที่ developer ทำงานอยู่ tester ก็เขียน test cases ไปพลาง เพราะไม่อยากเสียเวลานั่งคอยเฉยๆ แต่เพราะในตอนนั้นโปรแกรมยังไม่ถูกออกจนเรียบร้อย ทำให้ test cases ที่ออกมา ไม่ตรงกับสิ่งที่เขียนในโค้ดเสียทีเดียว พอถึงเวลา test ก็กลายเป็น บั๊ก ในขณะเดียวกัน ในเวลาที่ tester กำลัง test อยู่นั้น developer ก็ไม่อยากนั่งเสียเวลาคอย จึงหางาน ใหม่มาทำ เมื่อเกิดบั๊ก ก็ต้องสลับไปมา ระหว่าง งานใหม่ และ งานเก่า เกิดเป็นความสูญเปล่าขึ้นมา ดังที่จะกล่าวในข้อถัดไป

3. Muda – Waste – ความสูญเปล่า

หลายตำรามักจะให้น้ำหนักในการอธิบายเรื่องความสูญเปล่า มากจนกระทั่งคนที่ศึกษาเรื่องลีนใหม่ ๆ มักจะเข้าใจว่า ลีนคือการค้นหาและกำจัดความสูญเปล่า ซึ่งไม่ถูกเสียทีเดียว เพราะ ความสูญเปล่า นั้นความจริงส่วนใหญ่เป็นผลจาก การมี Mura และ Muri ถ้าหาก จะขจัดความสูญเปล่า(Muda) ให้เด็ดขาด จะต้องขจัดที่ตัวต้นเหตุซึ่งคือ Mura และ Muri ก่อน ขออธิบายความสูญเปล่าทั้ง 7 ไว้ตรงนี้สำหรับคนที่ยังไม่คุ้นชินกับมันนะครับ

3.1 Transportation – การขนส่ง

ในการจัดทีมแบบดั้งเดิมจะเห็นว่า กว่า ข้อมูลจากลูกค้าจะถูกส่งมายัง คนทำงานตัวจริง อย่าง developer และ tester นั้น มักจะมีคนขั้นกลางหลายคน ตัวอย่างเช่น System Analyst หรือ Technical Designer หรือไม่ก็ Architect คนเหล่านี้ ถ้าดีหน่อย พอได้มีโอกาสคุยกับลูกค้าตัวจริงแล้ว ก็มาส่งต่อด้วยช่องทางที่ดีอย่างการพูดคุยตัวต่อตัว แต่ส่วนใหญ่แล้วกลับใช้วิธีที่แย่ที่สุดอย่างเขียนเป็นเอกสาร ทำให้กว่า ความต้องการของลูกค้าจะถูกส่งต่อมายังคนทำงาน ก็ใช้เวลานาน ซ้ำยังไม่ครบถ้วนอีกด้วย

3.2 Inventory – สินค้า(ข้อมูล)คงคลัง

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

3.3 Motion – การเคลื่อนไหว(ที่ไม่จำเป็น)

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

3.4 Waiting – การรอคอย

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

3.5 Over-processing – กระบวนการ

ความจริง กระบวนการทุกชนิดที่ไม่ก่อให้เกิดคุณค่าแก่ลูกค้าตัวจริง ถือเป็นข้อนี้ทั้งหมด สิ่งที่เราคิดว่าเป็นงาน อย่างเช่น การทำ status report การลง timesheet การประชุมประจำสัปดาห์ ฯลฯ ทั้งหมดนี้ตกในข้อนี้ทั้งหมด

3.6 Over-production – การผลิตมากเกินไป

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

3.7 Defects – ความผิดพลาด

จากประสบการณ์ของผม บั๊กต่าง ๆ นั้น ส่วนใหญ่แล้ว โปรแกรมทำงานถูกต้องตาม assumption ที่ developer ตั้งไว้ แต่ไม่ตรงกับ assumption ที่ tester หรือ ลูกค้า ตั้ง เมื่อไม่ตรงกันก็เกิดเป็น บั๊ก และ ก่อให้เกิดความไม่เข้าใจกัน ระหว่าง คนเหล่านี้ในที่สุด

เมื่อมาถึงจุดนี้ผมว่าหลายคนคงพอจะมองเห็นแล้วว่า ถ้าหากทีมเป็น multi-skilled แล้ว ปัญหาทุกอย่างหายไป ถ้ายังไม่เห็นลองมาตามดูกันนะครับ

ติ๊ต่างว่า ทุกคนมีความสามารถใกล้เคียงกัน ทำงานแทนกันได้ เราก็จะไม่มี SA, Architect, Developer, Tester เราจะมีแต่ team member เท่านั้น และทุกคนสามารถทำงานชิ้นไหนก็ได้

Muri จะไม่เกิด เพราะ ถ้า นายเอ มีงานมาก ก็เพียงแค่แบ่งงานส่วนหนึ่ง ให้นายบีไปทำ ทั้งสองก็จะทำงาน ใกล้เคียงกันแล้ว

Mura จะไม่มี เพราะ ทุกคนจะแบ่งงาน กันอย่างเท่าเทียม ค่อย ๆ ทำฟีเจอร์ส่งให้ลูกค้า ทีละ ฟีเจอร์ ไปเรื่อย ๆ จนครบ

Muda แต่ละข้อจะเกิดขึ้นน้อยมาก เพราะ

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

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

มีการเคลื่อนไหวจำกัด เพราะ ทุกคนทำเองได้จึงไม่มีความจำเป็นต้องทำงานที่ไม่จำเป็น อย่างเอกสาร หรือ status report มากจนเกินไป

เมื่อทุกคนทำได้เหมือนกัน ก็ไม่จำเป็นที่คนหนึ่งคนใดต้องค่อยคนอื่น เพราะ ถ้าต้องการสิ่งใดก็ลงมือทำเองได้เลย

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

การผลิตมากเกินไป และ ความผิดพลาด จะลดลง ด้วย เพราะความมีอิสระของแต่ละคน และการให้อำนาจ(empowerment) นอกจากนี้ การที่ทุกคนมีความสามารถและอำนาจใกล้เคียงกัน จะทำให้เกิดการสื่อสารและการ debate กันอย่างเท่าเทียมเกิดเป็นการแสวงหาคำตอบที่ดียิ่งขึ้นแก่ปัญหาที่เกิดขึ้นเฉพาะหน้าในแต่ละวัน

ที่เล่ามายาวยืดมาถึงตรงนี้ คงขอจบลงที่การเน้นย้ำว่า Muri กับ Mura เป็น เหตุ Muda เป็นผล การตรวจสอบคุณภาพการทำงานของเรานั้นไม่จำเป็นที่เราจะต้องมานั่งหาว่า เรามี Muda ข้อไหนบ้าง เพราะถ้าหากว่าเราเพียงแต่ คอยสอดส่อง ว่า มีใครทำงานหนักกว่า คนอื่นหรือไม่ หรือมีช่วงเวลาใดที่มีงานมาก หรือช่วงใดมีน้อย แล้ว ปรับเรียบภาระตรงนั้นเสีย Muda จะหายไปโดย อัตโนมัติ

Advertisements

2 thoughts on “ว่าด้วยเรื่อง 3M

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s