...ลูกค้าบางคน เล่นง่ายครับ เวลาให้ Requirement บอกสั้นๆ ว่า “ต้องการระบบลำเลียงทีมีประสิทธิภาพ ไม่เสียบ่อย และ ต้นทุนต่ำ” พูดอย่างนี้ ต้องเชิญเทวดามาทำครับ เพราะ ใครๆ ก็อยากได้ แต่ ทำยาก คนที่ ไปรับ Requirement ถ้ากลับมาด้วย Requirement แบบนี้ เห็นทีต้องส่งกลับไปอีกรอบ เพราะ ความต้องการที่ได้มามันกว้างเกินไป

เกริ่นหัวข้อ ก็แทบไม่ต้องเขียนแล้วครับ

เพราะความหมายมันบอกอยู่ในตัว...แต่ก็อย่างว่าครับ ความหมายมันง่าย แต่ตอนทำเนี่ยยาก

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

“เรื่องเหล่านี้” ก็คืองานวิศวกรรมที่ทำอยู่นี่แหล่ะครับ (ลองอ่านบท เกริ่นนำ จะรู้ว่ามี สี่งานหลัก) <p style="margin: 0cm 0cm 10pt" class="MsoNormal">ระบบ AEI ที่ว่านี่ ผมอยากภูมิใจเสนอเลยครับ เพราะ จริงๆ แล้วมันก็คือ ระบบการทำงานพื้นฐาน ของ การ “สร้าง และ ทำลาย” คำเต็ม มาจาก “ Advanced Engineering Infrastructure”  ซึ่งตอนแรก เรียกว่า AEIOU ด้วยซ้ำ (มาจาก Advanced Engineering Infrastructure of Ultimatum) แต่ดูแล้วลิเก ไปหน่อย เลยลดเหลือ AEI อย่างที่เห็น</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">ใน AEI จะมีการพูดถึง การนำมาซึ่ง “Requirement” ว่า จะต้อง “ครอบคลุม ความต้องการทั้งหมดของลูกค้า และ เพียงพอที่จะนำมาใช้ออกแบบได้“</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">ลูกค้าบางคน เล่นง่ายครับ เวลาให้ Requirement บอกสั้นๆ ว่า “ต้องการระบบลำเลียงทีมีประสิทธิภาพ ไม่เสียบ่อย และ ต้นทุนต่ำ”  พูดอย่างนี้ ต้องเชิญเทวดามาทำครับ เพราะ ใครๆ ก็อยากได้ แต่ ทำยาก คนที่ ไปรับ Requirement ถ้ากลับมาด้วย Requirement แบบนี้ เห็นทีต้องส่งกลับไปอีกรอบ เพราะ ความต้องการที่ได้มามันกว้างเกินไป</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">คิดให้ง่ายๆอย่างงี้ครับ ว่า Requirement ก็คือจุดส่งงาน รายการต่างๆ ก็เป็น Check list ของเรานั่นแหล่ะครับ</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">ถ้าเขียน Requirement ออกมาแล้วเอามาทำ เป็น Check list ส่งงานไม่ได้ก็ไม่ใช่ Requirement ที่ดี</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">….</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">ถ้าเราเป็นลูกค้า เราอยากได้อะไรบ้าง…</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">อันแรก ก็ ต้องตอบโจทย์เราไห้ได้ก่อนครับ เช่น เราต้องการ เครื่องจักรอัตโนมัติ ที่ออกแบบมาใช้หยิบจับชิ้นงานในสายการผลิตแทนคนงาน ก็ต้อง ระบุไปให้ชัดเลยว่า อยากได้อะไร</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">ลองพิจารณาตัวอย่าง สองอันดังนี้</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">ตัวอย่างแรก “ออกแบบระบบจับชิ้นงาน ทดแทนคนงานที่มีอยู่ปัจจุบัน”</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">แล้วมาดูตัวอย่างสอง เป็น “เครื่องจักรที่ใช้หยิบจับชิ้นงาน จาก จุด A ไป จุด B ทำงานได้ตลอดเวลา 24 ชั่วโมง มีความเร็วในการหยิบชิ้นงานอย่างน้อย 15 ชิ้น ต่อ นาที และนำไปวางไว้ที่จุด B ได้อย่างถูกต้อง คลาดเคลื่อนได้ไม่เกิน 2 mm โดยที่ชิ้นงานไม่เสียหายระหว่างการ ขนย้าย”</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">อันที่สองนี่ชัดเจนกว่าเยอะครับ และ สามารถนำมาเขียนเป็น Check list ตอนส่งงานได้สบาย</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">เรื่องต่อไปที่ลูกค้า อาจจะเพิ่มนอกจากสิ่งที่อยากได้หลักแล้ว ก็คงจะเป็น เงื่อนไข หรือ ข้อกำหนด ของงานนี้ เช่น จะต้องไม่รบกวนสายการผลิตเดิม ระหว่างการติดตั้ง จะต้อง ใช้ผลิตภัณฑ์ที่เป็นสลากเขียว หรือ อะไรประเภทนี้เป็นต้น</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">เรียกได้ว่าเป็น Option ที่ลูกค้าต้องการ ซึ่งเราต้องเก็บมาให้หมดด้วยครับ</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal">สสารไม่สูญหายไปจากโลกครับ ถ้าวันนี้เก็บ Requirement ไม่หมด ลูกค้าก็เอามาเพิ่มให้วันหน้า อยู่ดี</p><p style="margin: 0cm 0cm 10pt" class="MsoNormal"> to be continued…..</p><div style="border-right: medium none; padding-right: 0cm; border-top: medium none; padding-left: 0cm; padding-bottom: 1pt; border-left: medium none; padding-top: 0cm; border-bottom: windowtext 1pt solid"></div> เกร็ดสำหรับตอนนี้องค์ประกอบของ Requirement ที่ดี1.       ระบุสิ่งที่ต้องการของตัวงาน ใน Term ของวิศวกรรม (วัดผลได้ และ มีเครื่องมือ หรือ วิธีที่ใช้วัด)2.       ความต้องการอื่นๆ ระหว่างการทำงาน เช่น รูปแบบการทำงาน ความปลอดภัย หรือ ข้อจำกัดต่างๆ   <p> </p>