การจัดการปัญหา

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

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

ขอบเขต

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

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

มูลค่าทางธุรกิจ

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

กิจกรรมกระบวนการ วิธีการ และเทคนิค

การจัดการปัญหาประกอบด้วยสองกระบวนการหลัก:

การตรวจจับปัญหา

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

การบันทึกปัญหา

ต้องบันทึกรายละเอียดที่เกี่ยวข้องทั้งหมดของปัญหาเพื่อให้มีบันทึกประวัติศาสตร์ที่สมบูรณ์ ต้องมีการประทับวันที่และเวลาเพื่อให้สามารถควบคุมและยกระดับได้อย่างเหมาะสม อ้างอิงข้ามจะต้องทำกับเหตุการณ์ที่เกิดขึ้น (s) ซึ่งริเริ่มปัญหา "บันทึก":

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

การจัดลำดับความสำคัญของปัญหา

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

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

การสอบสวนและวินิจฉัยปัญหา

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

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

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

  • จำนวนผู้ได้รับผลกระทบ
  • ระยะเวลาของการหยุดทำงานที่เกิดขึ้น
  • ต้นทุนของธุรกิจ

วิธีKepner และ Tregoeใช้เพื่อตรวจสอบปัญหาที่หยั่งรากลึก พวกเขากำหนดขั้นตอนต่อไปนี้:

  • การกำหนดปัญหา
  • อธิบายปัญหาในด้านตัวตน สถานที่ เวลา (ระยะเวลา) และขนาด (ผลกระทบ)
  • กำหนดสาเหตุที่เป็นไปได้
  • ทดสอบสาเหตุที่เป็นไปได้มากที่สุด
  • การตรวจสอบสาเหตุที่แท้จริง

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

  1. สร้างตารางที่แสดงสาเหตุและความถี่เป็นเปอร์เซ็นต์
  2. เรียงแถวตามลำดับความสำคัญของสาเหตุ (สาเหตุที่สำคัญที่สุดก่อน)
  3. เพิ่มคอลัมน์เปอร์เซ็นต์สะสมลงในตาราง
  4. สร้างแผนภูมิแท่งพร้อมสาเหตุ ตามลำดับเปอร์เซ็นต์ของยอดทั้งหมด
  5. ลากเส้นที่ 80% บนแกน Y แล้ววางเส้นที่จุดตัดกับแกน X จากแผนภูมิ คุณจะเห็นสาเหตุหลักของความล้มเหลวของเครือข่าย ควรกำหนดเป้าหมายเหล่านี้ก่อน
ความล้มเหลวของเครือข่าย
สาเหตุ เปอร์เซ็นต์ของทั้งหมด การคำนวณ %
ตัวควบคุมเครือข่าย 35 0+35% = 35%
ไฟล์เสียหาย 26 35% + 26% = 61%
ระบบปฏิบัติการเซิร์ฟเวอร์ 6 61%+6% = 67%

บันทึกข้อผิดพลาดที่ทราบ

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

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

ทบทวนปัญหาสำคัญ

แนวปฏิบัติที่ดีคือการทบทวนปัญหาที่สำคัญทั้งหมด แต่นั่นทำให้เกิดค่าใช้จ่าย การตรวจสอบควรตรวจสอบ:

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

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

ดูเพิ่มเติม

อ้างอิง

  • ผู้จัดการที่มีเหตุผลคนใหม่ - อธิบายการแก้ปัญหาและการตัดสินใจของ KT (PSDM)
  • ออฟฟอร์ด, พอล (2011). RPR: ปัญหาวิธีการวินิจฉัยสำหรับผู้เชี่ยวชาญด้าน เอสเซกซ์ ประเทศอังกฤษ: บริษัท แอดวานซ์ เซเว่น จำกัด ISBN 978-1-4478-4443-3.