ปัญหาที่อไจล์พยายามแก้มีมาตั้งนานแล้ว

Chokchai Phatharamalai
odds.team
Published in
2 min readJul 3, 2023
Photo by Petrebels on Unsplash

ลองนึกภาพว่าคุณเป็นเจ้าของร้านขายของชำแห่งหนึ่ง คุณจะมีปัญหากับสองความต้องการที่ขัดแย้งกันตลอดเวลา 1) อยากจะรักษายอดขาย 2) อยากจะลดขนาดคลัง

รักษายอดขาย

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

เพราะสำหรับนักขาย lead คือเงิน ถ้าคุณเจอว่าคุณทำเงินตกพื้น คุณจะก้มไปเก็บไหม สำหรับนักขาย การมีโอกาสขายวิ่งเข้ามาก็สำคัญเหมือนมีเงินวิ่งเข้ามา เค้าจะทำทุกอย่างเพื่อรักษามันไว้ เพื่อเปลี่ยนโอกาสนั้นเป็นเงิน เพื่อปิดการขายให้ได้ และเพื่อให้ได้สิ่งนั้น คุณในฐานะเจ้าของร้าน อยากมีคลังขนาดใหญ่ไม่จำกัด เพื่อสนับสนุนการขาย

ลดขนาดคลัง

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

ทำไมต้องมีคลัง

เพราะการผลิตมันเสกไม่ได้ ถ้าเราสั่งของแล้วกระพริบตาเดียวของก็เติมเต็ม shelf ได้ดังใจเลย เราคงอยู่โดยไม่ต้องมีคลังได้ แต่เพราะกระบวนการผลิตมีข้อจำกัด (constraint) ทั้งเรื่องเวลาที่ใช้ตั้งแต่ได้รับ order มา, ผลิต, จนส่งมอบสินค้าสำเร็จ (lead time) และจำนวนน้อยที่สุดที่จะสั่งได้ (minimum batch size) เพราะสำหรับโรงงานส่วนใหญ่ เค้ารับ order 2–3 ชิ้นไม่ได้ มันไม่คุ้มทุน

ในทฤษฎีของไหล (flow theory) เวลาที่กระบวนการมีขั้นตอนหนึ่งที่มีข้อจำกัดแบบนี้ มันจะให้ flow สะดุด

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

แล้วอไจล์เกี่ยวอะไร?

หลาย ๆ ทฤษฎีของอไจล์จะพยายามให้เราเอากระบวนการในองค์กรตั้งแต่ concept to cash มากาง แล้วดูว่า queue ตรงไหนมากไป น้อยไป การ optimize ทั้งสายนี้แหละที่ทำให้องค์กรมี business agility จากการ reduce waste พวกเทคนิค visualize flow, value stream mapping เพื่อทำ global optimization แทน local optimization ตอบโจทย์แถว ๆ นี้

อีกด้านคือพยายามเติมเต็มฝันที่ทำให้กระบวนการผลิตเหมือนเสกได้ คือ ลดขนาด batch size ให้เล็กลง และทำให้ lead time ของการผลิตเร็วขึ้น พวกการ track lead time หรือทำงานเป็นรอบ ๆ แบบ iterative ตอบโจทย์แถว ๆ นี้

นอกจากนี้ หนังสือ Lean Software Development ของ Mary กับ Tom Poppendieck ก็สอนให้เรามองความรู้ที่อยู่ในหัวของทุกคนที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์เป็นสินค้าที่อยู่ในคลังเช่นกัน เพราะ มันเสื่อมคุณค่าทุกวินาทีเพราะถูกลืมเลือนไปเรื่อย ๆ ไม่ต่างกัน

สิ่งที่แตกต่างคือเวลาสินค้าล้นคลัง มันมองเห็นได้ชัดกว่าเวลาที่ข้อมูลล้นสมอง เวลาที่เห็นสินค้าบูดเสียหรือต้องทิ้งเพราะหมออายุมันกระตุ้นอารมณ์และการเรียนรู้ได้ลึกซึ้งกว่าเวลาที่รายละเอียดของข้อมูลถูกลืมเลือน และ เวลาที่สินค้าถูกเอาไปกองรอส่งให้ลูกค้ามันเห็นความเสี่ยงและความซับซ้อนในการขนส่งชัดกว่าที่ซอฟต์แวร์ที่เสร็จแล้วถูกเอาไปกองรอ release ขึ้น production เลยมีเทคนิคมากมายที่พยายาม ใช่อุปมาอุปไมยทำให้ของพวกนี้กลายเป็น token ที่จับต้องได้ขึ้นมา เช่นเปลี่ยนเป็น index card หรือกระดาษ post it เพื่อให้เห็นของกอง ๆ แล้วเราจะได้มองเห็นปัญหาได้อย่างเป็นธรรมชาติมากขึ้น

เรื่องตลกร้ายคือตั้งแต่ช่วง lock down มา เราก็ขนพวก token เหล่านี้กลับไปใส่ในซอต์แวร์ ผมเห็นแล้วอดทั้งขำทั้งเศร้าปนกันไปไม่ได้

สรุป

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

--

--