ถอด 5 บทเรียนการทำ “Change Management” จากประสบการณ์การทำโปรเจกต์ Digital Transformation

จากประสบการณ์ของเราในการทำโครงการ Digital Transformation ให้หลายองค์กร สิ่งหนึ่งที่เห็นชัดมากคือ

👉 เทคโนโลยี แทบไม่เคยเป็นปัญหาหลัก
👉แต่ “การบริหารการเปลี่ยนแปลง” เกือบจะเป็นจุดล้มเสมอ

TYPE

Thoughts

มาลองดู 5 บทเรียนสำคัญที่เราได้เรียนรู้กันครับ

1️⃣ คนไม่ได้ต่อต้านการเปลี่ยนแปลง แต่ต่อต้านความไม่ชัดเจน

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

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

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

📍การไม่เข้าใจทิศทางของโปรเจกต์ หากขาดการสื่อสารที่ชัดเจน และเป็นขั้นตอน ก็อาจทำให้เกิดความไม่เข้าใจ และเกิดมุมมองที่ไม่สอดคล้องกับการดำเนินโปรเจกต์ 

1️⃣ คนไม่ได้ต่อต้านการเปลี่ยนแปลง แต่ต่อต้านความไม่ชัดเจน

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

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

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

📍การไม่เข้าใจทิศทางของโปรเจกต์ หากขาดการสื่อสารที่ชัดเจน และเป็นขั้นตอน ก็อาจทำให้เกิดความไม่เข้าใจ และเกิดมุมมองที่ไม่สอดคล้องกับการดำเนินโปรเจกต์ 

1️⃣ คนไม่ได้ต่อต้านการเปลี่ยนแปลง แต่ต่อต้านความไม่ชัดเจน

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

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

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

📍การไม่เข้าใจทิศทางของโปรเจกต์ หากขาดการสื่อสารที่ชัดเจน และเป็นขั้นตอน ก็อาจทำให้เกิดความไม่เข้าใจ และเกิดมุมมองที่ไม่สอดคล้องกับการดำเนินโปรเจกต์ 

2️⃣ ผู้บริหารระดับกลางคือผู้ขับเคลื่อนความสำเร็จที่แท้จริง

แม้ว่าผู้บริหารระดับสูงจะอนุมัติโปรเจกต์แล้วก็ตาม แต่บทบาทของ “Project Manager” มักจะตกเป็นของผู้บริหารระดับกลาง (หรือ Mid-Level Management) ที่ต้องพยายามขับเคลื่อนโปรเจกต์ 

แต่คำว่า “ขับเคลื่อน”​ ไม่ใช่เรื่องง่าย…สิ่งที่ Project Manager จะต้องเข้าใจมีหลายมิติด้วยกัน ได้แก่

  • ความเข้าใจด้านเทคโนโลยีและระบบใหม่ๆ ที่จะนำมาซึ่งความเปลี่ยนแปลง

  • กระบวนการหรือ Process ที่เกี่ยวข้องกับการเปลี่ยนแปลง จะเปลี่ยนเป็นอย่างไร และควรจะเป็นอย่างนั้นหรือไม่

  • คนที่เกี่ยวข้อง กลยุทธ์ในการชักนำให้คนเข้าใจในการทำโปรเจกต์ การพยายามช่วยหาคำตอบและตอบสนองต่อความต้องการของคนหลากหลายฝ่าย ฯ

  • ข้อมูลที่ต้องเตรียม ต้องแปลง ต้องจัดในเท็มเพลต ฯ​ 

  • การบริหารจัดการโปรเจกต์ เช่น แผน ความเสี่ยง การตรวจรับผลงาน เป็นต้น

หากไม่เคยทำมาก่อน ถึงว่าเป็นความท้าทายที่จะส่งผลต่อความสำเร็จของโปรเจกต์มากทีเดียว

2️⃣ ผู้บริหารระดับกลางคือผู้ขับเคลื่อนความสำเร็จที่แท้จริง

แม้ว่าผู้บริหารระดับสูงจะอนุมัติโปรเจกต์แล้วก็ตาม แต่บทบาทของ “Project Manager” มักจะตกเป็นของผู้บริหารระดับกลาง (หรือ Mid-Level Management) ที่ต้องพยายามขับเคลื่อนโปรเจกต์ 

แต่คำว่า “ขับเคลื่อน”​ ไม่ใช่เรื่องง่าย…สิ่งที่ Project Manager จะต้องเข้าใจมีหลายมิติด้วยกัน ได้แก่

  • ความเข้าใจด้านเทคโนโลยีและระบบใหม่ๆ ที่จะนำมาซึ่งความเปลี่ยนแปลง

  • กระบวนการหรือ Process ที่เกี่ยวข้องกับการเปลี่ยนแปลง จะเปลี่ยนเป็นอย่างไร และควรจะเป็นอย่างนั้นหรือไม่

  • คนที่เกี่ยวข้อง กลยุทธ์ในการชักนำให้คนเข้าใจในการทำโปรเจกต์ การพยายามช่วยหาคำตอบและตอบสนองต่อความต้องการของคนหลากหลายฝ่าย ฯ

  • ข้อมูลที่ต้องเตรียม ต้องแปลง ต้องจัดในเท็มเพลต ฯ​ 

  • การบริหารจัดการโปรเจกต์ เช่น แผน ความเสี่ยง การตรวจรับผลงาน เป็นต้น

หากไม่เคยทำมาก่อน ถึงว่าเป็นความท้าทายที่จะส่งผลต่อความสำเร็จของโปรเจกต์มากทีเดียว

2️⃣ ผู้บริหารระดับกลางคือผู้ขับเคลื่อนความสำเร็จที่แท้จริง

แม้ว่าผู้บริหารระดับสูงจะอนุมัติโปรเจกต์แล้วก็ตาม แต่บทบาทของ “Project Manager” มักจะตกเป็นของผู้บริหารระดับกลาง (หรือ Mid-Level Management) ที่ต้องพยายามขับเคลื่อนโปรเจกต์ 

แต่คำว่า “ขับเคลื่อน”​ ไม่ใช่เรื่องง่าย…สิ่งที่ Project Manager จะต้องเข้าใจมีหลายมิติด้วยกัน ได้แก่

  • ความเข้าใจด้านเทคโนโลยีและระบบใหม่ๆ ที่จะนำมาซึ่งความเปลี่ยนแปลง

  • กระบวนการหรือ Process ที่เกี่ยวข้องกับการเปลี่ยนแปลง จะเปลี่ยนเป็นอย่างไร และควรจะเป็นอย่างนั้นหรือไม่

  • คนที่เกี่ยวข้อง กลยุทธ์ในการชักนำให้คนเข้าใจในการทำโปรเจกต์ การพยายามช่วยหาคำตอบและตอบสนองต่อความต้องการของคนหลากหลายฝ่าย ฯ

  • ข้อมูลที่ต้องเตรียม ต้องแปลง ต้องจัดในเท็มเพลต ฯ​ 

  • การบริหารจัดการโปรเจกต์ เช่น แผน ความเสี่ยง การตรวจรับผลงาน เป็นต้น

หากไม่เคยทำมาก่อน ถึงว่าเป็นความท้าทายที่จะส่งผลต่อความสำเร็จของโปรเจกต์มากทีเดียว

3️⃣ Go-live ไม่ใช่เส้นชัย

แรงต้านส่วนใหญ่มา หลัง go-live ตอนที่ต้องใช้งานจริง และพฤติกรรมเดิมเริ่มกลับมา

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

บางคนก็ทำตามสิ่งที่ Project Manager และผู้ให้บริการ (Vendor) พาให้ทำไปตามขั้นตอน แต่สุดท้ายพอต้องทำงานกับระบบใหม่จริงๆ และพบกับความไม่คุ้นเคย อาจจะทำให้รู้สึกไม่เคยชิน ไม่สะดวกสบาย และไม่อยากเสียเวลาไปสอบถามใคร จึงพบว่าคนกลุ่มนี้ มีแนวโน้มกลับไปใช้ทางลัด (Workaround) หรือวิธี Manual เดิมๆ กันเสียมาก 

📍งานของทีมจัดการการเปลี่ยนแปลง หรือทีม “Change Management” จึงสำคัญมาก

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

3️⃣ Go-live ไม่ใช่เส้นชัย

แรงต้านส่วนใหญ่มา หลัง go-live ตอนที่ต้องใช้งานจริง และพฤติกรรมเดิมเริ่มกลับมา

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

บางคนก็ทำตามสิ่งที่ Project Manager และผู้ให้บริการ (Vendor) พาให้ทำไปตามขั้นตอน แต่สุดท้ายพอต้องทำงานกับระบบใหม่จริงๆ และพบกับความไม่คุ้นเคย อาจจะทำให้รู้สึกไม่เคยชิน ไม่สะดวกสบาย และไม่อยากเสียเวลาไปสอบถามใคร จึงพบว่าคนกลุ่มนี้ มีแนวโน้มกลับไปใช้ทางลัด (Workaround) หรือวิธี Manual เดิมๆ กันเสียมาก 

📍งานของทีมจัดการการเปลี่ยนแปลง หรือทีม “Change Management” จึงสำคัญมาก

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

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 ยืนยันว่าทดสอบผ่านแล้ว ค่อนข้างยากที่จะขอให้ผู้ให้บริการปรับแก้ระบบ และมีความเสี่ยงว่าผู้ใช้งานจะไม่ใช้ระบบ

4️⃣ “UAT” เป็นด่านสุดท้ายที่ห้ามปล่อยผ่าน

หลังจากที่ผู้ให้บริการ (Vendor) พัฒนาระบบต่างๆให้เราเสร็จแล้ว ก็มักจะเข้าสู่เฟสที่ต้องให้ทางผู้ใช้งานทดสอบใช้งานจริงไปด้วยกัน หรือที่เรียกว่า “User Acceptance Test” หรือ “UAT” (ซึ่งไม่ใช่การทดสอบโดยผู้พัฒนาเองนะครับ)

📍กิจกรรมนี้สำคัญมากต่อความสำเร็จของโปรเจกต์ โดยจุดที่เราควรจะใช้เวลาให้มากที่สุด คือ “การตั้งเคสหรือกรณีในการทดสอบ” 

โดยปกติแล้ว ทางผู้ให้บริการ (Vendor) จะต้องเป็นผู้ตั้งเคสในการทดสอบ แต่หลายๆ ครั้งก็พบว่ากรณีเหล่านี้ไม่ครอบคลุมทุกเงื่อนไขของการทำงานจริง หรือกรณีที่เป็น “Unhappy Case” ที่ผู้ใช้งานใช้งานผิดพลาด หรือไม่ตามเงื่อนไขของระบบ 

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

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) หากไม่มีการสรุปไว้ จะทำให้คนที่ไม่ได้เข้าประชุมไม่ทราบ และอาจต้องทำประชุมซ้ำๆ อีกหลายรอบ และหากไม่มีการระบุให้ชัดเจนว่าใครต้องทำอะไรต่อหลังจากเข้าประชุมแล้ว ก็จะทำให้การประชุมไม่มีความหมาย หรือไม่มีอะไรเกิดขึ้น 

5️⃣ ทุก “บันทึก” มีความหมาย

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

📍ประเภทของการ “บันทึก” ที่ต้องให้ความสำคัญตลอดช่วงเวลาของโปรเจกต์ เช่น

[1] เอกสารระบุความต้องการ (ที่แต่ละผู้ให้บริการ อาจจะใช้ชื่อเรียกไม่เหมือนกัน แต่โดยมาตรฐานควรจะเป็น “Business Requirement Definition”) โดยผู้ให้บริการ (Vendor) ที่ได้มาตรฐานจะมีการบันทึกความต้องการเหล่านี้ในเอกสารที่มีการเก็บเวอร์ชันที่ชัดเจน และก่อนที่ทำการพัฒนาระบบใดๆ จะต้องมีการเซ็นต์ยืนยันหรือ “Sign-off” จากทางลูกค้าเสมอ 

👉🏻ความต้องการที่ไม่อยู่ในนี้ จะถือว่าเป็นความต้องการเพิ่มและจะต้องจ่ายเงินเพิ่มในภายหลัง เพราะฉะนั้นควรจะเก็บให้ครบถ้วนตั้งแต่จุดนี้

[2] อีเมล หากมีการตกลงอะไรกันนอกรอบประชุม ควรจะต้องส่งอีเมลให้ทุกคนที่ควรทราบตามหลังเสมอ เพื่อให้เกิดความเข้าใจที่ตรงกัน 

[3] บันทึกประชุม (Minutes of Meeting หรือ “MoM”) เวลาเข้าประชุม มักจะมี 2 อย่างที่ได้ออกมาเสมอ ได้แก่ ข้อสรุป และสิ่งที่ต้องทำต่อ (Next Action) หากไม่มีการสรุปไว้ จะทำให้คนที่ไม่ได้เข้าประชุมไม่ทราบ และอาจต้องทำประชุมซ้ำๆ อีกหลายรอบ และหากไม่มีการระบุให้ชัดเจนว่าใครต้องทำอะไรต่อหลังจากเข้าประชุมแล้ว ก็จะทำให้การประชุมไม่มีความหมาย หรือไม่มีอะไรเกิดขึ้น 

5️⃣ ทุก “บันทึก” มีความหมาย

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

📍ประเภทของการ “บันทึก” ที่ต้องให้ความสำคัญตลอดช่วงเวลาของโปรเจกต์ เช่น

[1] เอกสารระบุความต้องการ (ที่แต่ละผู้ให้บริการ อาจจะใช้ชื่อเรียกไม่เหมือนกัน แต่โดยมาตรฐานควรจะเป็น “Business Requirement Definition”) โดยผู้ให้บริการ (Vendor) ที่ได้มาตรฐานจะมีการบันทึกความต้องการเหล่านี้ในเอกสารที่มีการเก็บเวอร์ชันที่ชัดเจน และก่อนที่ทำการพัฒนาระบบใดๆ จะต้องมีการเซ็นต์ยืนยันหรือ “Sign-off” จากทางลูกค้าเสมอ 

👉🏻ความต้องการที่ไม่อยู่ในนี้ จะถือว่าเป็นความต้องการเพิ่มและจะต้องจ่ายเงินเพิ่มในภายหลัง เพราะฉะนั้นควรจะเก็บให้ครบถ้วนตั้งแต่จุดนี้

[2] อีเมล หากมีการตกลงอะไรกันนอกรอบประชุม ควรจะต้องส่งอีเมลให้ทุกคนที่ควรทราบตามหลังเสมอ เพื่อให้เกิดความเข้าใจที่ตรงกัน 

[3] บันทึกประชุม (Minutes of Meeting หรือ “MoM”) เวลาเข้าประชุม มักจะมี 2 อย่างที่ได้ออกมาเสมอ ได้แก่ ข้อสรุป และสิ่งที่ต้องทำต่อ (Next Action) หากไม่มีการสรุปไว้ จะทำให้คนที่ไม่ได้เข้าประชุมไม่ทราบ และอาจต้องทำประชุมซ้ำๆ อีกหลายรอบ และหากไม่มีการระบุให้ชัดเจนว่าใครต้องทำอะไรต่อหลังจากเข้าประชุมแล้ว ก็จะทำให้การประชุมไม่มีความหมาย หรือไม่มีอะไรเกิดขึ้น 

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

ASAP Project เป็นที่ปรึกษาด้าน Digital Transformation ที่จะช่วยสร้างความเปลี่ยนแปลงให้กับธุรกิจด้วยเทคโนโลยี

ติดตาม YouTube ของเราเพื่อดูรีวิวเพิ่มเติม

ติดตาม Facebook เพจของเรา

#ChangeManagement #DigitalTransformation #DX #UAT #MoM #BRD

NEXT >

Get your Strategic Plan Ready with DX Maturity Assessment

NEXT >

NEXT >

Feeling overwhelmed?
Let us help you find the right tools.

LET'S TALK

Feeling overwhelmed?
Let us help you find the right tools.

LET'S TALK

Feeling overwhelmed?
Let us help you find the right tools.

LET'S TALK