MSITBlog

2 minutes reading time (392 words)

ได้ทำ ... ทำได้ ... ทำเป็น

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

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

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

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

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

หรือถ้าเราเอาตามลักษณะการนำมาปฏิบัติ ก็เช่น การวางแผนที่ใช้ประจํา การวางแผนที่ใช้เฉพาะครั้ง (Ad hoc)  

หรือถ้าเราเอาระยะเวลาเป็นตัวตั้ง ก็เช่น การวางแผนระยะยาว การวางแผนระยะปานกลาง การวางแผนระยะสั้น

หรือถ้าเราเอาตามลักษณะคุณค่าการใช้งาน ก็เช่น การวางแผนเพิ่มยอดขาย การวางแผนปรับปรุงคุณภาพ

จากที่กล่าวมานี้ แม้ว่ากรรมวิธี หรือ ขั้นตอนในการวางแผนจะไม่แตกต่างกันสักเท่าใดนัก แต่เรื่องราวและปัจจัยที่เรานำเอาเข้ามาพิจารณาก็จะแตกต่างกันไปตามกรอบที่ใช้เราใช้มอง

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

สมัยก่อนเวลาผมเข้าไปนั่งในห้องประชุมที่เขาทำการวางแผนกัน ผมก็จะเห็นคนอยู่สามกลุ่ม คือ กลุ่ม "ได้ทำ" กลุ่ม "ทำได้" และ กลุ่ม "ทำเป็น"

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

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

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

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

สมัยก่อน ผมต้องสอบสัมภาษณ์วิศวกรซึ่งต้องรับเข้ามาเพื่อพัฒนางานทางด้านระบบเครื่องมือที่ใช้ทดสอบงานโดยอัตโนมัติ (Automatic Test System, ATS) ดังนั้นวิศวกรที่ต้องการ จะต้องออกแบบฮาร์ดแวร์ได้และเขียนโปรแกรมควบคุมเป็น เพราะงานแต่ละงานย่อมแตกต่างกันออกไป บางงานต้องการควบคุมและสั่งการเร็ว เราก็จะใช้ฮาร์ดแวร์แบบหนึ่ง บางงานเราต้องการเรื่องการประมวลผลข้อมูลเร็ว เราก็ต้องใช้อีกฮาร์ดแวร์อีกแบบหนึ่ง

ในส่วนของฮาร์ดแวร์นั้น ผมไม่ค่อยจะซีเรียสสักเท่าใด เพราะเราออกแบบบอร์ดพวกนี้เอาไว้แล้ว จึงมีบล็อกไดอะแกรม มีวงจร มีภาพวาด พร้อม ตอนสัมภาษณ์ก็ให้เขาอธิบายให้ฟัง ใครที่อธิบายพอมีหลักการ เข้าใจได้ ก็ OK แล้ว ผมว่าเรื่องพวกนี้มันตายตัวครับ ใครที่เรียนมา ก็พอตอบได้ จะสอนเพิ่มเติมก็ไม่ยากอะไร

เรื่องของเรื่องมันไปอยู่ในส่วนของการเขียนโปรแกรมมากกว่า ประเด็นมันอยู่ที่เราจะแยกพวก เขียนโปรแกรมได้กับ เขียนโปรแกรมเป็นออกจากกันได้อย่างไร

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

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

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

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

ทีนี้ถ้าเอาพวก เขียนโปรแกรมได้มาเขียนโปรแกรมควบคุมแล้ว ผมมักจะเจอคำพูดว่า หน่วยความจำที่ใช้เก็บโปรแกรมเอาไว้ภายในตัว (Internal Program Memory) ไม่พอบ่อยมาก ทั้งนี้ก็เพราะไม่ได้วางแผนการเขียนโปรแกรมเอาไว้ก่อน หรือ บางทีโปรแกรมก็ทำงานช้าไปจนไม่สามารถควบคุมระบบได้ ครั้นให้ทำการ Optimize โปรแกรมเพื่อให้ทำงานได้เร็วขึ้น ก็ทำไม่เป็น ... งานก็เกิดความล่าช้า ลูกค้าก็ไม่ Happy 

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

ดังนั้น การเลือกคนที่ "เขียนโปรแกรมได้" กับ "เขียนโปรแกรมเป็น" จึงมีความสำคัญมากสำหรับงานที่ผมทำ เพราะเวลาที่ใช้ในการพัฒนาเมื่อผ่านไปแล้ว มันย้อนกลับคืนไม่ได้ ... อีกอย่างเส้นตายที่กำหนดไว้ (แผนการผลิต) มันมักจะขยับเข้ามาให้เร็วขึ้น มันไม่ค่อยยืดออกไปนะครับ  

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

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

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

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

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

 

เรื่องเล่าสู่กันฟัง
เราลืมฟังก์ชันของเราไปหรือเปล่า

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Thursday, 19 July 2018