ทำไมการทำ Transformation ถึงล้มเหลวถึง 70%
โปรแกรมการทำ Transformation ส่วนใหญ่มักล้มเหลว และไม่สามารถบรรลุเป้าหมายที่ตั้งไว้ได้
ผมเคยนำการเปลี่ยนแปลงด้าน AI และ ERP ที่ Novartis และผมได้เห็นความจริงอย่างหนึ่ง นั่นคือ เทคโนโลยีไม่ใช่ส่วนที่ยากที่สุด บ่อยครั้งที่ซอฟต์แวร์ทำงานได้ดีไม่มีปัญหา แต่ผู้คนต่างหากที่เลือกที่จะไม่ใช้งานมัน
เมื่อโครงการล้มเหลว ผู้นำมักจะโทษเรื่องข้อมูลหรือขอบเขตของงาน (scope) แต่นั่นเป็นเพียงแค่อาการเท่านั้น สาเหตุที่แท้จริงคือ "การยอมรับใช้งาน" (adoption) บริษัทส่วนใหญ่มองว่าการยอมรับใช้งานเป็นเพียงกิจกรรมการฝึกอบรมในช่วงท้าย แต่จริงๆ แล้วมันควรจะเป็นกฎเกณฑ์ในการออกแบบตั้งแต่เริ่มต้น
เครื่องมือจะไม่มีมูลค่าเลยหากผู้คนหลีกเลี่ยงที่จะใช้ ผมเคยเห็นซอฟต์แวร์ที่สมบูรณ์แบบแต่มีอัตราการใช้งานเพียง 30% เพราะผู้คนยังคงเลือกใช้ Spreadsheet แบบเดิมๆ ต่อไป
คุณไม่ได้ผลตอบแทนจากการลงทุน (ROI) จากซอฟต์แวร์ที่คุณซื้อมา แต่คุณจะได้ ROI จากซอฟต์แวร์ที่ผู้คน "ใช้งานจริง" ต่างหาก
ผู้คนต่อต้านการเปลี่ยนแปลงเพราะพวกเขารู้สึกว่ามันเป็นการแลกเปลี่ยนที่ไม่คุ้มค่า พวกเขามองเห็นแต่ความเสี่ยงและการถูกตรวจสอบที่มากขึ้น โดยที่ไม่มีผลประโยชน์ส่วนตัวใดๆ เลย
เพื่อแก้ไขปัญหานี้ คุณต้องสร้าง "ความปลอดภัยทางจิตวิทยา" (psychological safety) ผู้คนต้องรู้สึกปลอดภัยที่จะพูดว่า "ฉันไม่เข้าใจสิ่งนี้" หรือ "กระบวนการนี้มันมีปัญหา" หากปราศจากความปลอดภัย ผู้คนจะปกปิดความสับสน ซึ่งความสับสนที่ถูกซ่อนไว้จะนำไปสู่การหาทางเลี่ยงงานแบบเงียบๆ (silent workarounds) และการหาทางเลี่ยงเหล่านั้นก็นำไปสู่ความล้มเหลวในที่สุด
ปฏิบัติตามแผนนี้เพื่อชัยชนะ:
- กำหนดชัยชนะให้ชัดเจน: ก่อนที่คุณจะสร้างอะไรก็ตาม ให้เขียนระบุว่าบทบาทหน้าที่เฉพาะเจาะจงนั้นจะเปลี่ยนไปในทางที่ดีขึ้นอย่างไร หากคุณไม่สามารถแสดงให้เห็นถึงชัยชนะสำหรับคนคนนั้นได้ แสดงว่าคุณยังไม่มีแผนการที่แท้จริง คุณมีเพียงแค่แผนการเปิดตัว (rollout) เท่านั้น
- ใช้กลุ่มคนขี้สงสัย: อย่าคุยแค่กับกลุ่มคนที่สนับสนุนคุณเท่านั้น แต่จงดึงคนที่ขี้สงสัยที่สุดเข้ามาอยู่ในห้องออกแบบด้วย พวกเขาจะช่วยค้นพบปัญหาที่แท้จริงได้ตั้งแต่เนิ่นๆ และเมื่อคนขี้สงสัยยอมรับในแผนการได้ คนอื่นๆ ก็จะทำตามเอง
- นำด้วยความซื่อสัตย์: ขอให้ผู้นำยอมรับความผิดพลาด ความจริงใจเพียงครั้งเดียวจากหัวหน้าสามารถสร้างความเชื่อมั่นได้มากกว่าการทำแบบสำรวจหลายครั้งเสียอีก
- ให้รางวัลกับความซื่อสัตย์: กล่าวขอบคุณผู้คนที่รายงานขั้นตอนที่มีปัญหา เพราะพวกเขากำลังช่วยคุณทำหน้าที่ควบคุมคุณภาพ (quality control) อยู่
- วัดผลในสิ่งที่ถูกต้อง: อย่าติดตามแค่เรื่องงบประมาณและกำหนดการ แต่ให้ติดตามว่ามีคนใช้เครื่องมือกี่คน และพวกเขาต้องหาทางเลี่ยงงานบ่อยแค่ไหน
- แก้ไขและประกาศให้ทราบ: เมื่อคุณแก้ไขปัญหาได้แล้ว ให้บอกทุกคน เพื่อแสดงให้เห็นว่าการกล้าพูดออกมาสามารถเปลี่ยนแปลงระบบได้จริง
จงปฏิบัติต่อความเชื่อมั่นเหมือนเป็นโครงสร้างพื้นฐาน คุณต้องออกแบบและจัดสรรงบประมาณให้กับมัน เช่นเดียวกับที่คุณทำกับ tech stack ของคุณ
เลิกตรวจสอบแค่สถาปัตยกรรม (architecture) ของคุณ แล้วเริ่มถามทีมงานของคุณว่า: "อะไรที่จะทำให้สิ่งนี้ดีขึ้นสำหรับคุณ และมีอะไรที่คุณไม่กล้าบอกผมบ้าง?"
กลุ่ม 30% ที่ประสบความสำเร็จ คือกลุ่มคนที่รู้จักรับฟัง
Source: https://dev.to/cedricbignet/why-70-of-transformations-fail-and-the-people-first-fix-1ff
Optional learning community: https://t.me/GyaanSetuAi