Home / Knowledge : การบริหารและการจัดการ

การจัดการความเปลี่ยนแปลงด้านเทคโนโลยีสารสนเทศ 2

IT Change Management Image generated by me, Adobe Ps & Ai, as of Nov.20, 2023
การจัดการความเปลี่ยนแปลงด้านเทคโนโลยีสารสนเทศ 2^01,02.

First revision: Nov.17, 2023
Last change: Feb.09, 2024.
สืบค้น รวบรวม เรียบเรียง และปริวรรตโดย อภิรักษ์ กาญจนคงคา.

หน้าที่ 17

2. แนวทาง (การจัดการการเปลี่ยนแปลง) ที่มีหลายระยะซึ่งใช้งานได้จริง (A practical multi-phase approach)

"หากไม่คิดว่าจำเป็นต้องเปลี่ยนแปลงแล้วไซร้ การอยู่รอดก็ไม่จำเป็น"

ดับเบิลยู. เอ็ดเวิร์ดส์ เดมิ่ง (W. Edwards Deming)

2.1 ความท้าทายในการจัดการการเปลี่ยนแปลง (The change management challenge).
นอกเหนือจากการจัดการด้านเหตุการณ์ (Incident management) การจัดการการเปลี่ยนแปลงถือเป็นกระบวนการจัดการบริการไอที (ISTM) ที่เป็นที่รู้จักและนำไปใช้อย่างกว้างขวางที่สุด.

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

มีสองแนวทางทั่วไปในการใช้การจัดการการเปลี่ยนแปลง:
       • ใช้โปรแกรมการเปลี่ยนแปลงขั้นพื้นฐานที่จะตรวจสอบการเปลี่ยนแปลงทั้งหมดก่อนที่จะเผยแพร่.
       • ใช้กระบวนการเปลี่ยนแปลงที่สมบูรณ์เต็มที่ตามที่แสดงในกรอบแนวทางปฏิบัติที่ดีที่สุด.

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

แบบจำลองนี้จะแทรกจุดตรวจสอบ (CAB review) การจัดการการเปลี่ยนแปลงระหว่างการออกแบบ/การสร้าง (Build change) และการเปิดตัวสู่การใช้งานจริง (Release and depoly) (ดูรูปที่ 2.1) เมื่องานเสร็จสิ้นและพร้อมสำหรับการเปิดตัวและการปรับใช้ การจัดการการเปลี่ยนแปลงจะทำหน้าที่เป็นการตรวจสอบครั้งสุดท้ายอย่างง่าย ๆ เพื่อหลีกเลี่ยงผลกระทบทางเทคนิคที่ไม่ได้ตั้งใจ.

รูปที่ 2.1 จุดตรวจสอบการจัดการการเปลี่ยนแปลงขั้นพื้นฐาน

หน้าที่ 18

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

ในทางตรงกันข้าม มุมมองเชิงปฏิวัติของ W. Edwards Deming เมื่อกว่า 40 ปีที่แล้วคือคุณภาพควรได้รับการออกแบบทางวิศวกรรมเข้าสู่ระบบ/กระบวนการ แทนที่จะตรวจสอบหลังจากสร้างผลิตภัณฑ์แล้ว.

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

ตารางที่ 2.1 เริ่มจากจุดเล็ก ๆ (Starting small)

	จุดแข็ง (Strengths)	จุดอ่อน (Weaknesses)
	# ผลลัพธ์เกิดขึ้นทันที. (Immediate results.)	# เป็นเพียงปฏิกิริยาเท่านั้น. (Reactive only.)
	# เปิดเผยการเปลี่ยนแปลง เพื่อการตรวจสอบที่กว้างขึ้น. (Expose changes to wider review.)	# ความสามารถมีจำกัดในการปรับปรุงการเปลี่ยนแปลงระหว่างการพัฒนา. (Limited ability to improve change during development.)
	# การเปลี่ยนแปลงเล็กน้อยในขั้นตอนการทำงาน. (Minor change to workflow.)	# การเปลี่ยนแปลงจะไม่เกี่ยวข้องกัน จนกว่าจะมีการออกแบบและสร้างการเปลี่ยนแปลงแล้ว. (Change is not involved until after changes are designed and built.)
	# ง่ายในการนำไปปฏิบัติ. (Easy to implement.)	# มุ่งเน้นที่ระบบไอทีภายในและการดำเนินงาน.(IT internal/operations focus.)

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

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

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

หน้าที่ 19

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

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

เมื่อถึงจุดนี้องค์กรต่าง ๆ จะต้องตัดสินใจเรื่องที่ยากลำบาก สิ่งสำคัญคือต้องตระหนักว่าการเพิ่มความเข้มงวดมากขึ้นให้กับโครงการเปลี่ยนแปลงที่ไม่เป็นที่นิยมนั้นไม่ได้ช่วยปรับปรุงให้ดีขึ้น สิ่งที่ตรงกันข้ามมักเกิดขึ้น การเพิ่มข้อจำกัดและข้อกำหนดมักทำให้พนักงานเกิดความไม่พอใจและการต่อต้าน อีกทางหนึ่ง บางองค์กรละทิ้งการจัดการการเปลี่ยนแปลงอย่างเป็นทางการ หรือปล่อยให้คณะกรรมการที่ปรึกษาการเปลี่ยนแปลง (CAB-Change Advisory Board) กลายเป็นมากกว่าคณะกรรมการตรายาง ทั้งสองวิธีมีผลกระทบเช่นเดียวกับการเพิ่มความเข้มงวดมากขึ้น.

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

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

ที่มา: pinterest.com, วันที่เข้าถึง: 6 กุมภาพันธ์ 2567.

2.3 การตรวจสอบคุณภาพเทียบกับวิศวกรรมคุณภาพ (Quality inspection versus Quality engineering).
เราอาจคุ้นเคยกับผลงานของ W. Edwards Deming เป็นอย่างดี, สถาปนิกด้านคุณภาพและระบบซึ่งทำงานร่วมกับผู้ผลิตรถยนต์ของญี่ปุ่นในช่วงทศวรรษ 1950 และ 60 (ค.ศ.) หรือราว พ.ศ.2493-2503 ได้สร้างพื้นฐานสำหรับวิศวกรรมคุณภาพสมัยใหม่.

ใน Out of the Crisis (2000) เดมิงแนะนำปัญหาที่กว้างขึ้นเกี่ยวกับวิธีการตรวจสอบครั้งสุดท้าย:

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

หน้าที่ 20

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

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

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

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

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

2.4 เริ่มต้นครั้งใหญ่ (Starting big).
ในทางกลับกัน การพยายามใช้กระบวนการที่สมบูรณ์เต็มที่โดยตรง ตามที่อธิบายไว้ในกรอบงานแนวปฏิบัติที่ดีที่สุด โดยใช้กรอบงานเป็น 'ตำราอาหาร' หรือแหล่งที่มาของสูตรอาหาร ไม่เพียงแต่ท้าทายสำหรับองค์กรส่วนใหญ่เท่านั้น แต่ยังเป็นแนวทางที่ผิดด้วย.

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

หน้าที่ 21

ตารางที่ 2.2 เริ่มครั้งใหญ่ (Starting bigl)

	จุดแข็ง (Strengths)	จุดอ่อน (Weaknesses)
	ครอบคลุม. (Comprehensive.)	ก้าวกระโดดครั้งใหญ่สำหรับวัฒนธรรม. (Big for culture.)
	การเปลี่ยนแปลงที่ได้รับจากการจัดการในกระแสงาน. (Changes managed in the workstrem.)	ต้องใช้ทรัพยากรจำนวนมากในการดำเนินการ และโดยปกติแล้วจะเป็นการประยุกต์ใช้การจัดการการเปลี่ยนแปลงองค์กร. (Requires significant resources to implement - and usually the application of organizational change management.)
	การเปลี่ยนแปลงที่เกี่ยวข้องในระยะแรกสุด มีอิทธิพลต่อทิศทางของการเปลี่ยนแปลง. (Change involved at earliest stage; influences direction of change.)	การเปลี่ยนแปลงที่สำคัญต่อขั้นตอนการทำงานและโครงสร้าง/วัฒนธรรมองค์กร. (Major change to workflow and organizational structure/culture.)
	มุ่งเน้นผลลัพธ์ทางธุรกิจ. (Business-outcome focused.)	ความเสี่ยงในการสูญเสียการสนับสนุนด้านการจัดการ.(Risk of losing management support.)

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

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

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

2.5 ค้นหาจุดสมดุลที่เหมาะสม (Find the right balance).
ผู้เขียนได้อธิบายแนวทางทั่วไปสองประการในการจัดการการเปลี่ยนแปลง ในทางปฏิบัติ นี่เป็นเพียงปลายทั้งสองด้านของสเปกตรัม ทุกองค์กรมีเอกลักษณ์เฉพาะตัว และความคิดริเริ่มในการจัดการการเปลี่ยนแปลงแต่ละอย่างก็แตกต่างกัน.

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

หน้าที่ 22

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

ในบทที่ 3 และ 4 ข้าพเจ้าจะอธิบายแนวทางที่สมดุล โดยเริ่มจากระยะพื้นฐาน ตามด้วยระยะที่สองที่เพิ่มความสามารถในการเปลี่ยนแปลง ข้าพเจ้ารวมระยะที่สามไว้ในบทที่ 5 ซึ่งออกแบบมาเพื่อเพิ่มประสิทธิภาพโปรแกรมการเจริญเติบโต.

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

ความท้าทายส่วนใหญ่ในการค้นหาสมดุลที่เหมาะสมคือการปรับแนวทางปฏิบัติที่ดีที่สุดให้เหมาะกับองค์กรของเรามากที่สุด (ดูบทที่ 6 สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการปรับใช้และปรับใช้แนวทางปฏิบัติที่ดีที่สุด).

THE WAY OF TEA, ที่มา: pinterest.com อ้างถึง behance.net, วันที่เข้าถึง: 9 กุมภาพันธ์ 2567.

2.6 ข้อกังวลด้านวัฒนธรรม (Cultural Concerns).
ทุกองค์กรมีวัฒนธรรม. แต่ละอย่างมีเอกลักษณ์และได้รับอิทธิพลจากธรรมชาติและความท้าทายของธุรกิจ ทัศนคติของพนักงาน และพฤติกรรมที่เป็นที่ยอมรับโดยทั่วไป.

เมื่อเราเข้าใจวิธีที่องค์กรจัดการ (หรือไม่จัดการ) การเปลี่ยนแปลง เราจะได้เรียนรู้มากมายเกี่ยวกับการไหลหรือกระแส (flows) ของข้อมูล. คอยดูว่าใครกำลังสื่อสารข้อมูลอะไรกับใคร สิ่งนี้จะทำให้เรามีข้อมูลเชิงลึกอย่างมากเกี่ยวกับวิธีการจัดการกับการเปลี่ยนแปลงประเภทต่าง ๆ .

พึงรับรู้หรือตระหนักว่าเมื่อเราแนะนำการจัดการการเปลี่ยนแปลง เราอาจท้าทายคุณค่าทางวัฒนธรรมขั้นพื้นฐานบางประการ ซึ่งหนึ่งในนั้นอาจเป็นได้ว่าพนักงานไอทีได้รับมอบอำนาจให้จัดการการเปลี่ยนแปลงของตนเองในอดีต ซึ่งอยู่ในระบบไอทีในตัวเอง.

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

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

ในงานหลักของพวกเขา ABC of ICT: An Introduction (Wilkinson and Schilt, 2008), Paul Wilkinson และ Jan Schilt กล่าวไว้ดังนี้:

หน้าที่ 23

การประชุมใหญ่ครั้งถัดไปที่เราเข้าร่วม ให้ดูที่โปรแกรมและชื่อหัวข้อในคาบนั้นด้วย 95% จะมุ่งเน้นไปที่กรอบการทำงาน วิธีการ แนวทาง หรือกระบวนการเฉพาะบางอย่าง น้อยคนนักที่จะมุ่งเน้นไปที่การจัดการกับทัศนคติ พฤติกรรม และวัฒนธรรม บอกคุณถึงวิธีการฝังวิธีแก้ปัญหาในองค์กร การต่อต้านแบบใดที่เราจะต้องเผชิญ และวิธีเอาชนะสิ่งนี้ สิ่งนี้ทำให้หลายองค์กรยังใหม่กับการนำกรอบการทำงานมาใช้โดยความเชื่อที่ดูอ่อนด้อยว่าพวกเขาสามารถ 'นำไปปฏิบัติ' ได้.

ABC ที่พวกเขาอธิบายคือทัศนคติ พฤติกรรม และวัฒนธรรม โดยรวมแล้วสิ่งเหล่านี้เป็นตัวแทนของ “ด้านผู้คนหรือพนักงาน” ของการนำกระบวนการมาใช้. เมื่อเปรียบเทียบแล้ว กระบวนการต่าง ๆ เองก็ตรงไปตรงมา.

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

ทัศนคติที่เกี่ยวข้องกับการจัดการการเปลี่ยนแปลงนั้น สามารถสัมผัสกับความเชื่อและคุณค่าทางวัฒนธรรมที่ยึดถืออย่างลึกซึ้ง เช่น:

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

เราควรใช้เวลาทำความเข้าใจว่าโปรแกรมการจัดการการเปลี่ยนแปลงใหม่นี้จะเข้ากับวัฒนธรรมองค์กรได้อย่างไร มีความตั้งใจอย่างมากเกี่ยวกับการจัดการการเปลี่ยนแปลงทางวัฒนธรรมควบคู่ไปกับกระบวนการใหม่.

การคัดค้านทางวัฒนธรรมมักเกิดขึ้นในขณะที่ดำเนินการจัดการการเปลี่ยนแปลง ซึ่งรวมถึง:

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

มนุษย์เป็นสิ่งมีชีวิตที่ซับซ้อนซึ่งพฤติกรรมถูกขับเคลื่อนโดยความต้องการและแรงจูงใจที่หยั่งรากลึก บางสิ่งที่เรียบง่ายอย่างการใช้กระบวนการเปลี่ยนแปลงขั้นพื้นฐานสามารถกระตุ้นให้เกิดการตอบสนองแบบ Maslovian ที่น่าประหลาดใจซึ่งอาจเอาชนะได้ยาก.

หน้าที่ 24

เมื่อความพยายาม "เฉพาะกระบวนการ" ประสบปัญหาหรือล้มเหลว เนื่องจากความพยายามเหล่านี้ทำบ่อยเกินไป คำตอบแรกมักจะเป็นการตำหนิกรอบงาน.

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

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

2.7 ทำให้มันเรียบง่าย (Keep it simple)
ความเรียบง่ายเป็นหนึ่งในหลักการชี้นำของการจัดการการเปลี่ยนแปลงที่ประสบความสำเร็จ โดยเฉพาะอย่างยิ่งในระยะแรก ๆ รวมเฉพาะองค์ประกอบที่จำเป็นซึ่งสามารถเข้าใจคุณค่าได้ทันที.

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

2.8 คำศัพท์เกี่ยวกับเครื่องมือ (A word about tools)
เครื่องมือ ITSM เชิงพาณิชย์หลายอย่างมีการสนับสนุนการจัดการการเปลี่ยนแปลง. การเลือกเครื่องมืออยู่นอกเหนือขอบเขตของข้อมูลที่ได้เผยแพร่ในบล็อกนี้ด้วยเหตุผลเฉพาะ ไม่สามารถเลือกหรือกำหนดค่าเครื่องมือที่เหมาะสมได้ เว้นแต่เราจะเข้าใจการจัดการการเปลี่ยนแปลง รวมถึงความต้องการและความท้าทายเฉพาะขององค์กรของเรา.

ข้าพเจ้าไม่รู้ว่าใครเป็นคนแรกที่พูด แต่วลีที่ว่า 'คนเขลาที่มีเครื่องมือก็ยังเป็นคนเขลา' ค่อนข้างจะสรุปมุมมองของข้าพเจ้าได้.

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

หน้าที่ 25

ภาพที่ 2.2: องค์ประกอบของการจัดการการเปลี่ยนแปลงที่มีประสิทธิผล (Elements of effective change management)

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

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

รูปแบบความคิดทั่วไปอื่น ๆ ชี้ให้เห็นว่าหากเครื่องมือรวบรวมแนวทางปฏิบัติที่ดีที่สุด การใช้เครื่องมือ 'นอกกรอบ - Out of the box' จะเป็นกระบวนการมาตรฐาน น่าเศร้าที่แนวคิดในการใช้การจัดการการเปลี่ยนแปลงที่เป็นมาตรฐานหรือ "หนึ่งขนาดพอดีทุกคน - One-Size-Fits-All," ไม่มีอยู่จริง ไม่ว่าจะมาจากสิ่งพิมพ์อย่างเป็นทางการหรือโดยการติดตั้งเครื่องมือก็ตาม.

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

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

หน้าที่ 26

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

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

2.9 ความชัดเจนในบทบาทและความรับผิดชอบ (Clarity in roles and responsibilities)
การนำการจัดการการเปลี่ยนแปลงอย่างเป็นทางการมาใช้ย่อมจำเป็นต้องสร้างบทบาทใหม่และการเปลี่ยนแปลงบทบาทที่มีอยู่อย่างสม่ำเสมอ. เมื่อพัฒนาความเข้าใจอย่างมั่นคงเกี่ยวกับวิธีการจัดการการเปลี่ยนแปลงในปัจจุบันแล้ว เราควรมีภาพที่ชัดเจนของบทบาทที่มีอยู่ที่เกี่ยวข้องกับการจัดการการเปลี่ยนแปลง.

ในกรณีที่จำเป็นต้องปรับเปลี่ยนบทบาท จำเป็นต้องมีการสื่อสารที่ชัดเจนระหว่างผู้ที่ได้รับผลกระทบและผู้ที่เข้าใจบทบาทก่อนหน้านี้มากขึ้น นี่คือจุดที่แผนภูมิ RACI (รับผิดชอบ สำนึกในหน้าที่รับผิดชอบ ให้คำปรึกษา แจ้ง - responsibile, accountable, consulted, informed) มีประโยชน์.

วิธีสร้างแผนภูมิ RACI
แผนภูมิ RACI คือตารางแถวสำหรับแต่ละงาน/การมอบหมาย และชุดคอลัมน์ 1 คอลัมน์สำหรับผู้มีส่วนได้ส่วนเสียแต่ละราย ที่จุดตัดกันของงานและผู้มีส่วนได้ส่วนเสีย ให้มอบหมายบทบาทใดบทบาทหนึ่งที่ระบุไว้ในตาราง 2.3

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

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

จากนั้น จึงระบุว่าใครเป็นผู้รับผิดชอบในการทำงานหรือมอบหมายให้สำเร็จ.

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

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

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

หน้าที่ 27

ตารางที่ 2.3 บทบาทของ RACI

	ผู้รับผิดชอบ (Responsible)	บุคคลที่ดำเนินการตามกระบวนการหรือมอบหมายงาน (The person who carries out the process or task assignment.)
	ผู้รับผิดชอบ (Responsible)	รับผิดชอบในการทำให้งานเสร็จ (Responsible for getting the job done.)
	ผู้สำนึกในหน้าที่รับผิดชอบ (Accountable)	บุคคลนั้นจะต้องรับผิดชอบต่อกระบวนการหรืองานที่จะเสร็จสิ้นอย่างเหมาะสมในท้ายที่สุด (The person is ultimately accountable for the process or task being completed appropriately)
	ผู้สำนึกในหน้าที่รับผิดชอบ (Accountable)	ผู้รับผิดชอบจะต้องสำนึกในหน้าที่รับผิดชอบต่อบุคคลนี้ (Responsible people are accountable to this person.)
	ผู้ให้คำปรึกษา (Consulted)	ผู้ที่ไม่เกี่ยวข้องโดยตรงกับการปฏิบัติงาน แต่เป็นผู้ที่ให้คำปรึกษา (People who are not directly involved with carrying out the task but who consult.)
	ผู้ให้คำปรึกษา (Consulted)	อาจเป็นผู้มีส่วนได้ส่วนเสียหรือผู้เชี่ยวชาญเฉพาะเรื่อง (May be a stakeholder or subject matter expert.)
	แจ้ง (Informed)	ผู้ที่ได้รับผลลัพธ์จากกระบวนการหรืองานหรือผู้ที่จำเป็นต้องรับทราบข้อมูล (Those who receive output from the process or task or who have a need to stay informed.)

ไม่ใช่เรื่องแปลกที่แผนภูมิ RACI พื้นฐานจะรวมอยู่ในนโยบายการเปลี่ยนแปลง แต่โดยทั่วไปจะอยู่ในระดับที่สูงมากเท่านั้น. ตัวอย่างเช่น ผู้จัดการส่วนให้บริการตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงที่ได้รับอนุมัติทั้งหมดได้รับการสื่อสารกับผู้มีส่วนได้ส่วนเสีย. เป็นการดีที่สุดที่จะไม่ใช้ชื่อที่ถูกต้อง (เพียงบทบาท) ในเอกสารนโยบาย.

จาก: Continuous Improvement Toolkit (citoolkit.com) via pinterest.com, access date: Feb.9, 2024.

2.10 แนวทางหลายเฟส (The multiphase approach)
ด้วยอันตรายของแนวทางที่เรียบง่ายเกินไป (ดูหัวข้อ 2.2) ในด้านหนึ่งและความท้าทายของแนวทางที่ซับซ้อนเกินไป (ดูหัวข้อ 2.4) อีกด้านหนึ่ง ข้าพเจ้าสนับสนุนสิ่งที่ฉันเรียกว่าแนวทาง 'หลายขั้นตอน-Multiphase' ที่ใช้งานได้จริงในบทต่อไปนี้.

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

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

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

ในบทต่อไป เราจะมาดูขั้นตอนแรกกัน (ระยะที่ 1)

2.11 บทที่ 2: แนวคิดหลัก
แนวคิดหลักในบทที่ 2 สามารถสรุปได้ดังนี้

การเริ่มต้นเปลี่ยนแปลงการจัดการ ไม่ว่าจะใหญ่หรือเล็กเกินไป ก็มีความท้าทาย.
คณะกรรมการที่ปรึกษาการเปลี่ยนแปลง (Change Advisory Board-CAB) ในฐานะผู้ตรวจสอบการควบคุมคุณภาพ มีคุณค่าจำกัด.
คุณภาพต้องได้รับการออกแบบเข้าสู่กระบวนการพัฒนา (ไม่ตรวจสอบหลังการพัฒนา).
ความสำเร็จขึ้นอยู่กับการเอาใจใส่อย่างมีสติต่อทัศนคติ พฤติกรรม และวัฒนธรรมของคนภายในองค์กร.
เริ่มจากเล็กๆ น้อยๆ และทำให้มันเรียบง่าย.
อย่าเป็น 'คนโง่ที่สาละวนกับเครื่องมือ' ขั้นแรก ทำความเข้าใจองค์กรของคุณและความต้องการในการจัดการการเปลี่ยนแปลงที่สำคัญ.
สร้างความชัดเจนในบทบาทและความรับผิดชอบ (ใช้แผนภูมิ RACI).
ใช้หลายขั้นตอนเพื่อให้โปรแกรมการเปลี่ยนแปลงประสบความสำเร็จ

ที่มา คำศัพท์ คำอธิบาย:
⁰¹. จาก. IT Changement: A Practitioner's Guide, Greg Sanker, TSO: A Williams Lea Company, International Best Practice, ISBN 9780117083653, 2017, Print in the United Kingdom.
⁰². จาก. Implementing ITIL Change and Release management, Larry Klosterboer, The ITIL Series, ISBN 978-0-13-815041-9, IBM Press, 1st Printing Dec. 2008, Indiana, United States.

back

info@huexonline.com

Visit : 4750640