ถอด 5 บทเรียนการทำ “Change Management” จากประสบการณ์การทำโปรเจกต์ Digital Transformation
จากประสบการณ์ของเราในการทำโครงการ Digital Transformation ให้หลายองค์กร สิ่งหนึ่งที่เห็นชัดมากคือ
👉 เทคโนโลยี แทบไม่เคยเป็นปัญหาหลัก
👉แต่ “การบริหารการเปลี่ยนแปลง” เกือบจะเป็นจุดล้มเสมอ
TYPE
Thoughts
มาลองดู 5 บทเรียนสำคัญที่เราได้เรียนรู้กันครับ
1️⃣ คนไม่ได้ต่อต้านการเปลี่ยนแปลง แต่ต่อต้านความไม่ชัดเจน
ในทุกโปรเจกต์ มักจะมีบางฝ่ายงานที่ถูกมองว่า ไม่ยอมเปลี่ยนง่ายๆ มีเงื่อนไข ตั้งแง่ และน่าจะเป็นอุปสรรคค่อการเปลี่ยนแปลง แต่จากที่เราเจอ ส่วนใหญ่ไม่ได้มาจากความตั้งใจของเขา แต่มาจากสิ่งที่ลึกว่านั้น เช่น
📍ความกังวลกับความเปลี่ยนแปลงใหม่ เพราะยังไม่ได้รับคำตอบที่ต้องการทั้งถาม และรู้สึกเหมือนกับว่ายังมีอีกหลายอย่างที่น่าจะต้องตรวจสอบ แต่วันนี้ยังไม่รู้เลยว่าจะต้องถามอะไรได้บ้าง โดยธรรมชาติ ก็จะต้องพยายามชะลอการตัดสินใจทุกอย่าง จนกว่าจะทำความเข้าใจได้
📍การมองเห็น Gap จากประสบการณ์ หากเป็นฝ่ายงานที่ทำงานกับเงื่อนไข/ข้อบังคับในสายงาน และรู้ว่าเงื่อนไข/ข้อบังคับนั้นเป็นเรื่องที่ต้องทำตามให้ได้อย่างไม่มีทางเลือก เมื่อพบว่าความเปลี่ยนแปลงที่กำลังจะเกิดขึ้นนั้น ไม่สามารถทำตามเงื่อนไข/ข้อบังคับได้ ก็จะต้องยกประเด็นขึ้นมา และอาจจะทำให้ดูเหมือนต่อต้าน
📍การไม่เข้าใจทิศทางของโปรเจกต์ หากขาดการสื่อสารที่ชัดเจน และเป็นขั้นตอน ก็อาจทำให้เกิดความไม่เข้าใจ และเกิดมุมมองที่ไม่สอดคล้องกับการดำเนินโปรเจกต์
2️⃣ ผู้บริหารระดับกลางคือผู้ขับเคลื่อนความสำเร็จที่แท้จริง
แม้ว่าผู้บริหารระดับสูงจะอนุมัติโปรเจกต์แล้วก็ตาม แต่บทบาทของ “Project Manager” มักจะตกเป็นของผู้บริหารระดับกลาง (หรือ Mid-Level Management) ที่ต้องพยายามขับเคลื่อนโปรเจกต์
แต่คำว่า “ขับเคลื่อน” ไม่ใช่เรื่องง่าย…สิ่งที่ Project Manager จะต้องเข้าใจมีหลายมิติด้วยกัน ได้แก่
ความเข้าใจด้านเทคโนโลยีและระบบใหม่ๆ ที่จะนำมาซึ่งความเปลี่ยนแปลง
กระบวนการหรือ Process ที่เกี่ยวข้องกับการเปลี่ยนแปลง จะเปลี่ยนเป็นอย่างไร และควรจะเป็นอย่างนั้นหรือไม่
คนที่เกี่ยวข้อง กลยุทธ์ในการชักนำให้คนเข้าใจในการทำโปรเจกต์ การพยายามช่วยหาคำตอบและตอบสนองต่อความต้องการของคนหลากหลายฝ่าย ฯ
ข้อมูลที่ต้องเตรียม ต้องแปลง ต้องจัดในเท็มเพลต ฯ
การบริหารจัดการโปรเจกต์ เช่น แผน ความเสี่ยง การตรวจรับผลงาน เป็นต้น
หากไม่เคยทำมาก่อน ถึงว่าเป็นความท้าทายที่จะส่งผลต่อความสำเร็จของโปรเจกต์มากทีเดียว
3️⃣ Go-live ไม่ใช่เส้นชัย
แรงต้านส่วนใหญ่มา หลัง go-live ตอนที่ต้องใช้งานจริง และพฤติกรรมเดิมเริ่มกลับมา
แน่นอนว่าตอนขึ้นโปรเจกต์กันใหม่ๆ ก็พอจะเห็นแรงต้านก็บ้าง แต่จะเห็นว่าเกิดผลลัพธ์ ผลสำเร็จที่ต้องการหรือไม่ ก็ต้องวัดกันหลังจากที่ Go-Live หรือประกาศเริ่มใช้ระบบใหม่กันไปแล้ว
บางคนก็ทำตามสิ่งที่ Project Manager และผู้ให้บริการ (Vendor) พาให้ทำไปตามขั้นตอน แต่สุดท้ายพอต้องทำงานกับระบบใหม่จริงๆ และพบกับความไม่คุ้นเคย อาจจะทำให้รู้สึกไม่เคยชิน ไม่สะดวกสบาย และไม่อยากเสียเวลาไปสอบถามใคร จึงพบว่าคนกลุ่มนี้ มีแนวโน้มกลับไปใช้ทางลัด (Workaround) หรือวิธี Manual เดิมๆ กันเสียมาก
📍งานของทีมจัดการการเปลี่ยนแปลง หรือทีม “Change Management” จึงสำคัญมาก
หากไม่มีใครคอยติดตามและวัดผลการใช้งานจริงเป็นระยะ ด้วยความถี่ที่เหมาะสม ก็อาจจะทำให้โปรเจกต์ที่ทำมาหลายเดือนไม่เกิดผลที่ตั้งใจ
4️⃣ “UAT” เป็นด่านสุดท้ายที่ห้ามปล่อยผ่าน
หลังจากที่ผู้ให้บริการ (Vendor) พัฒนาระบบต่างๆให้เราเสร็จแล้ว ก็มักจะเข้าสู่เฟสที่ต้องให้ทางผู้ใช้งานทดสอบใช้งานจริงไปด้วยกัน หรือที่เรียกว่า “User Acceptance Test” หรือ “UAT” (ซึ่งไม่ใช่การทดสอบโดยผู้พัฒนาเองนะครับ)
📍กิจกรรมนี้สำคัญมากต่อความสำเร็จของโปรเจกต์ โดยจุดที่เราควรจะใช้เวลาให้มากที่สุด คือ “การตั้งเคสหรือกรณีในการทดสอบ”
โดยปกติแล้ว ทางผู้ให้บริการ (Vendor) จะต้องเป็นผู้ตั้งเคสในการทดสอบ แต่หลายๆ ครั้งก็พบว่ากรณีเหล่านี้ไม่ครอบคลุมทุกเงื่อนไขของการทำงานจริง หรือกรณีที่เป็น “Unhappy Case” ที่ผู้ใช้งานใช้งานผิดพลาด หรือไม่ตามเงื่อนไขของระบบ
Project Manager จึงต้องใส่ใจในการระบุเคสเข้าไปให้มากที่สุดในเวลาที่มี เพราะนี่จะเป็นด่านสุดท้ายในการทดสอบ หากพ้นจากจุดนี้และเราทำการ Sign-off ยืนยันว่าทดสอบผ่านแล้ว ค่อนข้างยากที่จะขอให้ผู้ให้บริการปรับแก้ระบบ และมีความเสี่ยงว่าผู้ใช้งานจะไม่ใช้ระบบ
5️⃣ ทุก “บันทึก” มีความหมาย
หลายคนมองข้ามความสำคัญของการบันทึกข้อมูลสำคัญๆ ในระหว่างการทำโปรเจกต์ไป ทำให้ไม่รู้ว่าทำไมถึงมีฟังก์ชันนี้ ทำไมต้องใช้วิธีการแบบนี้ในการใช้งาน เป็นต้น
📍ประเภทของการ “บันทึก” ที่ต้องให้ความสำคัญตลอดช่วงเวลาของโปรเจกต์ เช่น
[1] เอกสารระบุความต้องการ (ที่แต่ละผู้ให้บริการ อาจจะใช้ชื่อเรียกไม่เหมือนกัน แต่โดยมาตรฐานควรจะเป็น “Business Requirement Definition”) โดยผู้ให้บริการ (Vendor) ที่ได้มาตรฐานจะมีการบันทึกความต้องการเหล่านี้ในเอกสารที่มีการเก็บเวอร์ชันที่ชัดเจน และก่อนที่ทำการพัฒนาระบบใดๆ จะต้องมีการเซ็นต์ยืนยันหรือ “Sign-off” จากทางลูกค้าเสมอ
👉🏻ความต้องการที่ไม่อยู่ในนี้ จะถือว่าเป็นความต้องการเพิ่มและจะต้องจ่ายเงินเพิ่มในภายหลัง เพราะฉะนั้นควรจะเก็บให้ครบถ้วนตั้งแต่จุดนี้
[2] อีเมล หากมีการตกลงอะไรกันนอกรอบประชุม ควรจะต้องส่งอีเมลให้ทุกคนที่ควรทราบตามหลังเสมอ เพื่อให้เกิดความเข้าใจที่ตรงกัน
[3] บันทึกประชุม (Minutes of Meeting หรือ “MoM”) เวลาเข้าประชุม มักจะมี 2 อย่างที่ได้ออกมาเสมอ ได้แก่ ข้อสรุป และสิ่งที่ต้องทำต่อ (Next Action) หากไม่มีการสรุปไว้ จะทำให้คนที่ไม่ได้เข้าประชุมไม่ทราบ และอาจต้องทำประชุมซ้ำๆ อีกหลายรอบ และหากไม่มีการระบุให้ชัดเจนว่าใครต้องทำอะไรต่อหลังจากเข้าประชุมแล้ว ก็จะทำให้การประชุมไม่มีความหมาย หรือไม่มีอะไรเกิดขึ้น
การได้ระบบที่ดี การขึ้นโปรเจกต์สำเร็จจึงไม่ใช่จุดจบของการทำ Transformation แต่เป็นเพียงจุดเริ่มต้นของการเปลี่ยนแปลง จะขยายผลให้ครอบคลุมทุกส่วนที่ตั้งใจได้หรือไม่นั้นก็ขึ้นอยู่กับความสามารถในการจัดการความเปลี่ยนแปลงหรือ “Change Management” ของเรานั่นเอง
ASAP Project เป็นที่ปรึกษาด้าน Digital Transformation ที่จะช่วยสร้างความเปลี่ยนแปลงให้กับธุรกิจด้วยเทคโนโลยี
#ChangeManagement #DigitalTransformation #DX #UAT #MoM #BRD
