เปลี่ยนกระบวนการควบคุมในวิศวกรรมซอฟต์แวร์พร้อมขั้นตอน

⚡ สรุปอย่างชาญฉลาด

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

📚 ความหมาย: การควบคุมการเปลี่ยนแปลงเป็นการกำหนดกระบวนการอย่างเป็นทางการในการขอ การประเมิน การอนุมัติ การดำเนินการ และการปิดการเปลี่ยนแปลงภายในสภาพแวดล้อมด้านไอที
📋 เอกสารสำคัญ: เอกสารบันทึกการเปลี่ยนแปลงและแบบฟอร์มขอเปลี่ยนแปลงจะบันทึกข้อมูลเกี่ยวกับลำดับความสำคัญ ผู้รับผิดชอบ ค่าใช้จ่าย ประโยชน์ ผลกระทบ และสถานะการอนุมัติ
💼 ห้าขั้นตอนหลัก: การระบุ การประเมิน การวิเคราะห์ การอนุมัติ และการดำเนินการ คือขั้นตอนมาตรฐานของการควบคุมการเปลี่ยนแปลง
🏗️ แผงควบคุมการเปลี่ยนแปลง: CCB จะประเมินความเสี่ยง ความซับซ้อน และผลกระทบของการเปลี่ยนแปลงที่เกินกว่าเกณฑ์ที่ตกลงกันไว้ก่อนที่จะอนุมัติ
🔁 การจัดการ vs. การควบคุม: การจัดการการเปลี่ยนแปลง (Change Management) กำหนดกลยุทธ์สำหรับการปรับใช้การเปลี่ยนแปลง ในขณะที่การควบคุมการเปลี่ยนแปลง (Change Control) กำกับดูแลคำขอแต่ละรายการ
✅ ผลกระทบทางธุรกิจ: การควบคุมการเปลี่ยนแปลงอย่างมีระเบียบวินัยช่วยลดการหยุดชะงัก ปกป้องขอบเขตงาน และรักษาร่องรอยการตรวจสอบและการปฏิบัติตามกฎระเบียบให้คงอยู่

อ่านเพิ่มเติม

การควบคุมการเปลี่ยนแปลงคืออะไร?

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

ทำไมต้องเปลี่ยนการควบคุม?

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

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

คำถามทั่วไปที่มักถูกถามในการวิเคราะห์คำขอควบคุมการเปลี่ยนแปลง ได้แก่:

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

ปัจจัยต่างๆ ของกระบวนการควบคุมการเปลี่ยนแปลง

มีหลายปัจจัยที่กระบวนการควบคุมการเปลี่ยนแปลงควรพิจารณา

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

กระบวนการควบคุมการเปลี่ยนแปลง

ก่อนที่จะเจาะลึกเข้าไปในกระบวนการควบคุมการเปลี่ยนแปลง เราควรทำความคุ้นเคยกับเอกสารที่ใช้ในการควบคุมการเปลี่ยนแปลงเสียก่อน เอกสารสองฉบับมีความสำคัญอย่างยิ่งต่อการควบคุมการเปลี่ยนแปลง ได้แก่:

เปลี่ยนเข้าสู่ระบบบันทึกการเปลี่ยนแปลงจะแสดงรายละเอียดของคำขอเปลี่ยนแปลงแต่ละรายการ ได้แก่ หมายเลขโครงการ รหัส PCR (คำขอเปลี่ยนแปลงโครงการ) ลำดับความสำคัญ เจ้าของ วันที่เป้าหมาย สถานะ วันที่สถานะ ผู้ยื่นคำขอ และวันที่ยื่นคำขอ

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

แผนภาพกระบวนการเปลี่ยนแปลง

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

ขั้นตอนในกระบวนการควบคุมการเปลี่ยนแปลง

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

หมายเหตุ: การอนุมัติการควบคุมการเปลี่ยนแปลงอาจได้รับโดย ผู้จัดการโครงการ หัวหน้าฝ่ายไอที หรือหัวหน้าฝ่ายพัฒนา หรือผู้มีส่วนได้ส่วนเสียที่ได้รับมอบหมาย

การจัดการการเปลี่ยนแปลง กับ การควบคุมการเปลี่ยนแปลง

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

การบริหารการเปลี่ยนแปลง

การเปลี่ยนแปลงการควบคุม

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

ครอบคลุมถึงการเสนอ การบันทึก การวิเคราะห์ และการอนุมัติการเปลี่ยนแปลงเพื่อปรับปรุงประสิทธิภาพโดยรวมของระบบหรือผลิตภัณฑ์

คำถามที่พบบ่อย

เครื่องมือ ITSM ที่ขับเคลื่อนด้วย AI จะทำการวิเคราะห์ผลกระทบ การประเมินความเสี่ยง การกำหนดเส้นทางตั๋ว และการตรวจจับการเปลี่ยนแปลงที่ซ้ำซ้อนโดยอัตโนมัติ โมเดลการเรียนรู้ของเครื่องจะเรียนรู้จากเหตุการณ์ในอดีตและแจ้งเตือนการเปลี่ยนแปลงที่มีความเสี่ยงต่อคณะกรรมการที่ปรึกษาการเปลี่ยนแปลงก่อนการใช้งานจริง

Copilot และ GPT สามารถร่างแบบฟอร์มคำขอเปลี่ยนแปลง สร้างแผนการย้อนกลับ และสรุปประวัติการคอมมิตเป็นรายงานผลกระทบที่อ่านง่ายได้ นักวิเคราะห์ธุรกิจยังคงตรวจสอบร่างแต่ละฉบับเทียบกับแม่แบบ CCB ก่อนส่ง

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

บริการตอนนี้ Jira Service Managementบีเอ็มซี เฮลิกซ์ Freshserviceและ Ivanti Neurons ITSM ต่างก็มีเวิร์กโฟลว์การควบคุมการเปลี่ยนแปลงที่สอดคล้องกับ ITIL โดยจะบันทึกคำขอ ดำเนินการอนุมัติ บันทึกแผนการย้อนกลับ และผสานรวมกับไปป์ไลน์ CI/CD

ITIL กำหนดประเภทของการเปลี่ยนแปลงไว้ 3 ประเภท ได้แก่ การเปลี่ยนแปลงมาตรฐาน ซึ่งได้รับการอนุมัติล่วงหน้าและมีความเสี่ยงต่ำ การเปลี่ยนแปลงปกติ ซึ่งต้องได้รับการตรวจสอบจากคณะกรรมการที่ปรึกษาด้านการเปลี่ยนแปลง (CAB) และการเปลี่ยนแปลงฉุกเฉิน ซึ่งไม่ต้องผ่านการตรวจสอบอย่างเต็มรูปแบบเพื่อแก้ไขเหตุการณ์เร่งด่วน แต่ยังคงต้องจัดทำเอกสารหลังการดำเนินการ

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

ทีม Agile จัดการกับการเปลี่ยนแปลงผ่านการปรับปรุง Backlog การวางแผน Sprint และการทบทวน Definition of Ready การอนุมัติอย่างเป็นทางการจาก CCB จะสงวนไว้สำหรับการเปลี่ยนแปลงที่ส่งผลกระทบต่อขอบเขต งบประมาณ หรือเงื่อนไขtracts หรือระบบที่มีการควบคุมอยู่นอกขอบเขตของสปรินต์

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