เทมเพลตข้อมูลสำหรับการจัดการปัญหา
เทมเพลตข้อมูลสำหรับการจัดการปัญหา
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการปัญหา หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- โครงสร้างทั่วไปที่ใช้ได้กับระบบจัดการปัญหาทุกประเภท.
- ฟิลด์ข้อมูลและขั้นตอนกระบวนการที่แนะนำสำหรับการวิเคราะห์อย่างละเอียด.
- ข้อมูลตั้งต้นที่ช่วยให้คุณเริ่มใช้ process mining ได้อย่างมีประสิทธิภาพ.
แอตทริบิวต์การจัดการปัญหา
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อของเหตุการณ์ งาน หรือการเปลี่ยนสถานะที่เกิดขึ้นในวงจรการจัดการปัญหา. | ||
| คำอธิบาย ชื่อกิจกรรมอธิบายขั้นตอนหนึ่งในกระบวนการจัดการปัญหา เช่น 'สร้างระเบียนปัญหา', 'ระบุสาเหตุที่แท้จริง' หรือ 'นำวิธีแก้ไขถาวรไปใช้' ระบบบันทึกกิจกรรมตามลำดับเวลาเพื่อแสดงให้เห็นว่าจัดการปัญหาอย่างไร. ใน process mining แอตทริบิวต์นี้สำคัญต่อการสร้างแผนผังกระบวนการ ซึ่งแสดงลำดับงานที่เกิดขึ้นจริง การวิเคราะห์ลำดับ ความถี่ และเส้นทางของกิจกรรมช่วยให้เห็นความเบี่ยงเบน คอขวด และจุดที่ทำงานไม่มีประสิทธิภาพในกระบวนการแก้ไขปัญหา. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนในกระบวนการ จึงช่วยให้เห็นภาพและวิเคราะห์ลำดับงาน รวมถึงเส้นทางที่พบบ่อยและความเบี่ยงเบน. แหล่งข้อมูล ชื่อกิจกรรมมักได้มาจากบันทึกการเปลี่ยนสถานะ ประวัติการตรวจสอบ หรือตารางเหตุการณ์ที่เชื่อมโยงกับระเบียนปัญหาหลัก. ตัวอย่าง เริ่มตรวจสอบเปลี่ยนลำดับความสำคัญจัดเตรียมวิธีแก้ปัญหาชั่วคราวปิดรายการปัญหา | |||
| รหัสระเบียนปัญหา ProblemRecordId | รหัสเฉพาะของระเบียนปัญหา ซึ่งใช้แทนกรณีหนึ่งของกระบวนการจัดการปัญหา. | ||
| คำอธิบาย รหัสระเบียนปัญหาเป็นคีย์หลักที่ใช้ติดตามวงจรชีวิตของปัญหาตั้งแต่สร้างจนแก้ไขเสร็จ ปัญหาแต่ละรายการอาจเชื่อมโยงกับเหตุขัดข้องหลายรายการ และจะมีรหัสเฉพาะเพื่อแยกจากปัญหาอื่น. ใน process mining แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานที่ใช้ระบุเคส เพื่อให้ระบบจัดกลุ่มกิจกรรมที่เกี่ยวข้องทั้งหมดไว้ในกระบวนการเดียวกัน การวิเคราะห์ลำดับงาน การระบุคอขวด และการคำนวณระยะเวลาของเคส ล้วนต้องอาศัยการระบุระเบียนปัญหาแต่ละรายการให้ถูกต้อง. เหตุผลที่สำคัญ นี่คือ Case ID ที่ใช้จัดกลุ่มเหตุการณ์ที่เกี่ยวข้องทั้งหมด ทำให้ติดตามการตรวจสอบปัญหาได้ตั้งแต่ต้นจนจบ. แหล่งข้อมูล โดยทั่วไปจะพบรหัสนี้ในตารางปัญหาหรือตารางใบงานหลักของระบบ IT Service Management (ITSM). ตัวอย่าง PRB0040332PROB-1298778103PM-5501 | |||
| เวลาเกิดเหตุการณ์ EventTime | วันที่และเวลาที่แน่นอนซึ่งกิจกรรมเกิดขึ้น. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์หรือ timestamp แสดงลำดับเวลาของแต่ละกิจกรรมในวงจรชีวิตของปัญหา ข้อมูลนี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณระยะเวลาระหว่างขั้นตอนต่างๆ. ใน process mining ระบบใช้แอตทริบิวต์นี้เพื่อเรียงกิจกรรม ค้นหาโมเดลกระบวนการ และวิเคราะห์ข้อมูลด้านเวลา ใช้เป็นพื้นฐานในการคำนวณ KPI สำคัญ เช่น 'เวลาเฉลี่ยในการตรวจสอบสาเหตุที่แท้จริง' และระบุความล่าช้าระหว่างขั้นตอน เช่น ช่วงเวลาตั้งแต่ระบุสาเหตุที่แท้จริงจนถึงเริ่มคำขอเปลี่ยนแปลง. เหตุผลที่สำคัญ timestamp ของแต่ละกิจกรรมจำเป็นต่อการเรียงเหตุการณ์และคำนวณตัวชี้วัดด้านเวลา เช่น ระยะเวลารอบงานและระยะเวลาที่เกิดคอขวด. แหล่งข้อมูล โดยปกติจะพบ timestamp นี้ในตารางบันทึกเหตุการณ์หรือประวัติการตรวจสอบ พร้อมกับชื่อกิจกรรมและรหัสเคส. ตัวอย่าง 2023-04-15T10:22:05Z2023-11-20T14:05:30Z2024-01-08T09:00:11Z | |||
| ระบบต้นทาง SourceSystem | ชื่อแอปพลิเคชันหรือระบบที่ดึงข้อมูลมา. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลการจัดการปัญหา เช่น ServiceNow, Jira หรือเครื่องมือ ITSM ที่พัฒนาขึ้นเอง มีความสำคัญเป็นพิเศษเมื่อรวมข้อมูลจากหลายระบบเพื่อวิเคราะห์ภาพรวม. ในการทำ process mining คุณสามารถใช้ระบบต้นทางเป็นตัวกรองเพื่อเปรียบเทียบผลการดำเนินงานและความแตกต่างของกระบวนการระหว่างหน่วยธุรกิจหรือแพลตฟอร์มต่างๆ นอกจากนี้ยังช่วยตรวจสอบความถูกต้องและแก้ไขปัญหาข้อมูล โดยระบุบริบทว่าได้ข้อมูลมาจากที่ใด. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบความถูกต้องและเปรียบเทียบกระบวนการระหว่างระบบหรือหน่วยงานต่างๆ. แหล่งข้อมูล โดยทั่วไปจะเพิ่มค่าแบบคงที่นี้ระหว่างการดึงข้อมูล เพื่อระบุระเบียนจากระบบต้นทางแต่ละระบบ. ตัวอย่าง ServiceNowJira Service ManagementBMC Helix ITSMFreshservice | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | timestamp ที่ระบุเวลาล่าสุดที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทาง. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลครั้งล่าสุด ช่วยให้เห็นว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด และทำให้ผู้เกี่ยวข้องทราบว่าการวิเคราะห์ครอบคลุมช่วงเวลาใด. ข้อมูลนี้ช่วยให้เข้าใจบริบทของแดชบอร์ดและรายงาน ผู้ใช้จะทราบได้ว่ากำลังดูข้อมูลล่าสุดหรือข้อมูล ณ เวลาใดเวลาหนึ่ง ซึ่งมีผลต่อการตีความตัวชี้วัด เช่น 'งานปัญหาค้างสะสมตามอายุ'. เหตุผลที่สำคัญ ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด จึงตีความผลวิเคราะห์และแดชบอร์ดได้ถูกต้องตามเวลาที่รีเฟรชข้อมูลล่าสุด. แหล่งข้อมูล โดยปกติ เครื่องมือหรือสคริปต์ ETL จะสร้างและจัดเก็บ timestamp นี้ระหว่างนำเข้าข้อมูล. ตัวอย่าง 2023-10-01T06:00:00Z2024-02-20T08:00:00Z2024-03-15T05:30:00Z | |||
| กลุ่มสนับสนุน SupportGroup | ทีมเทคนิคหรือแผนกที่รับผิดชอบตรวจสอบและแก้ไขปัญหาในช่วงเวลานั้น. | ||
| คำอธิบาย กลุ่มสนับสนุนระบุทีมที่ได้รับมอบหมายให้จัดการปัญหา เมื่อดำเนินการไป ปัญหาอาจถูกส่งต่อระหว่างกลุ่มต่างๆ เช่น จากทีมสนับสนุนระดับ 2 ไปยังทีมวิศวกรรมเครือข่ายเฉพาะทาง. แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ผลการดำเนินงานของทีมและการส่งต่องานระหว่างทีม process mining ช่วยให้เห็นความล่าช้าจากการมอบหมายงานใหม่ วัดระยะเวลาที่แต่ละกลุ่มใช้จัดการปัญหา และระบุทีมที่แก้ปัญหาบางประเภทได้มีประสิทธิภาพที่สุด ข้อมูลนี้ใช้ประกอบแดชบอร์ด เช่น 'การวิเคราะห์การส่งต่องานระหว่างกลุ่มสนับสนุน'. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์ผลการดำเนินงานของทีม ระบุคอขวดจากการส่งต่องาน และทำความเข้าใจการกระจายภาระงานระหว่างทีม. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บไว้ในประวัติการมอบหมายของระเบียนปัญหา หรือตารางรายละเอียดหลักในระบบ ITSM. ตัวอย่าง การปฏิบัติการเครือข่ายการดูแลระบบฐานข้อมูลทีมสนับสนุนแอปพลิเคชันระดับ 3ทีมรักษาความปลอดภัย | |||
| จำนวนครั้งที่มอบหมายใหม่ ReassignmentCount | จำนวนครั้งที่ระเบียนปัญหาถูกมอบหมายใหม่ระหว่างกลุ่มสนับสนุนหรือบุคคลต่างๆ. | ||
| คำอธิบาย ตัวชี้วัดนี้นับจำนวนครั้งที่มีการโอนความรับผิดชอบของปัญหา หากมีการมอบหมายใหม่บ่อยครั้ง มักบ่งชี้ว่ากระบวนการไม่มีประสิทธิภาพ เช่น ส่งงานไปผิดทีมตั้งแต่แรก หรือหน้าที่ของแต่ละทีมไม่ชัดเจน. ใน process mining ตัวชี้วัดนี้ช่วยบอกจุดติดขัดของกระบวนการ และใช้ระบุกรณีที่ปัญหาถูกส่งกลับไปมาระหว่างทีม การวิเคราะห์เคสที่มีการมอบหมายใหม่หลายครั้งอาจเผยให้เห็นช่องว่างด้านความรู้หรือข้อบกพร่องของกระบวนการ ซึ่งทำให้เกิดความล่าช้าและเสียแรงงานโดยเปล่าประโยชน์. เหตุผลที่สำคัญ ช่วยวัดความไม่มีประสิทธิภาพของกระบวนการจากการส่งต่องานที่มากเกินไป ซึ่งมักบ่งชี้ถึงการส่งงานผิดทีม ช่องว่างด้านความรู้ หรือความรับผิดชอบที่ไม่ชัดเจน. แหล่งข้อมูล มักเป็นฟิลด์ตัวนับในระเบียนปัญหาที่เพิ่มขึ้นทุกครั้งที่เปลี่ยนผู้รับมอบหมาย หรือคำนวณจากบันทึกเหตุการณ์ได้. ตัวอย่าง 0135 | |||
| จำนวนเหตุขัดข้องที่เกี่ยวข้อง RelatedIncidentCount | จำนวนระเบียนเหตุขัดข้องแต่ละรายการที่เชื่อมโยงกับปัญหานี้. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงผลกระทบของปัญหาเป็นจำนวนเหตุขัดข้องที่ส่งผลต่อผู้ใช้ โดยทั่วไป ปัญหาที่มีเหตุขัดข้องเกี่ยวข้องจำนวนมากจะส่งผลกระทบต่อธุรกิจมากกว่า. ตัวชี้วัดนี้ช่วยจัดลำดับความสำคัญและวิเคราะห์ผลกระทบ ใน process mining คุณสามารถใช้เปรียบเทียบจำนวนเหตุขัดข้องกับเวลาที่ใช้ตรวจสอบหรือลำดับความสำคัญในการแก้ไข ช่วยให้องค์กรเข้าใจขนาดของปัญหา และแสดงให้เห็นว่าการแก้ไขเพียงครั้งเดียวช่วยป้องกันเหตุขัดข้องได้กี่รายการ เพื่อประกอบการจัดสรรทรัพยากรสำหรับการจัดการปัญหา. เหตุผลที่สำคัญ แสดงผลกระทบทางธุรกิจของปัญหาเป็นตัวเลข ช่วยจัดลำดับความสำคัญของการตรวจสอบและวัดประสิทธิผลของการแก้ไข. แหล่งข้อมูล ค่านี้มักเป็นฟิลด์ที่คำนวณในระเบียนปัญหา โดยนับจำนวนระเบียนเหตุขัดข้องที่เชื่อมโยงกัน. ตัวอย่าง 5281501 | |||
| บริการที่ได้รับผลกระทบ AffectedService | บริการทางธุรกิจ แอปพลิเคชัน หรือรายการกำหนดค่า (CI) หลักที่ได้รับผลกระทบจากปัญหา. | ||
| คำอธิบาย แอตทริบิวต์นี้เชื่อมโยงปัญหากับองค์ประกอบหรือบริการเฉพาะในโครงสร้างพื้นฐาน IT เช่น 'บริการอีเมล' หรือ 'แพลตฟอร์มบริหารความสัมพันธ์ลูกค้า' จึงช่วยให้เข้าใจผลกระทบทางธุรกิจของปัญหาทางเทคนิค. ในการวิเคราะห์ process mining บริการที่ได้รับผลกระทบช่วยให้มองกระบวนการจากมุมธุรกิจ และตอบคำถามได้ เช่น 'บริการใดมีปัญหาเกิดขึ้นมากที่สุด' หรือ 'โดยเฉลี่ยแล้วใช้เวลาแก้ปัญหาที่กระทบต่อระบบการเงินสำคัญนานเท่าใด' บริบทนี้จำเป็นต่อการจัดลำดับความสำคัญของการปรับปรุงตามผลกระทบทางธุรกิจ. เหตุผลที่สำคัญ ช่วยให้เห็นบริบททางธุรกิจโดยเชื่อมโยงปัญหาทางเทคนิคกับบริการที่ได้รับผลกระทบ และจัดลำดับความสำคัญตามความสำคัญต่อธุรกิจได้. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้เชื่อมโยงมาจากฐานข้อมูลการจัดการการกำหนดค่า (CMDB) และจัดเก็บในฟิลด์ 'รายการกำหนดค่า' หรือ 'บริการ' ของระเบียนปัญหา. ตัวอย่าง บริการอีเมลและการทำงานร่วมกันระบบการเงิน SAP ERPVPN ขององค์กรเว็บไซต์หลักของลูกค้า | |||
| ผิด SLA SlaBreached | แฟล็กที่ระบุว่าการแก้ไขปัญหาเกินวันครบกำหนดตาม SLA ที่กำหนดไว้หรือไม่. | ||
| คำอธิบาย แอตทริบิวต์แบบบูลีนนี้บอกได้โดยตรงว่าเป็นไปตามข้อตกลงระดับการให้บริการหรือไม่ โดยทั่วไปจะตั้งค่าเป็น true หาก timestamp ที่แก้ไขปัญหาเสร็จช้ากว่าวันครบกำหนดตาม SLA. แฟล็กนี้แสดงผลลัพธ์โดยตรง จึงมีประโยชน์มากสำหรับการจัดทำแดชบอร์ดและรายงานภาพรวม ใน process mining สามารถใช้ตรวจสอบความสอดคล้องหรือกรองเคสที่ผิด SLA ทั้งหมดได้ การเปรียบเทียบแผนผังกระบวนการของปัญหาที่ผิด SLA กับปัญหาที่ไม่ผิด SLA อาจเผยให้เห็นรูปแบบ คอขวด หรือกิจกรรมเฉพาะที่มักทำให้ไม่เป็นไปตาม SLA. เหตุผลที่สำคัญ แสดงผลลัพธ์การปฏิบัติตาม SLA ว่าสำเร็จหรือไม่อย่างชัดเจน ช่วยกรองและวิเคราะห์เส้นทางกระบวนการที่นำไปสู่การผิด SLA ได้ง่าย. แหล่งข้อมูล มักเป็นฟิลด์ที่ได้จากการคำนวณ โดยเปรียบเทียบ timestamp ที่แก้ไขปัญหาเสร็จกับวันครบกำหนดตาม SLA. ตัวอย่าง truefalse | |||
| ลำดับความสำคัญ Priority | ระดับความสำคัญที่กำหนดให้ปัญหา ซึ่งใช้กำหนดความเร่งด่วนในการตรวจสอบและแก้ไข. | ||
| คำอธิบาย ลำดับความสำคัญเป็นแอตทริบิวต์หลักที่ใช้จัดประเภทปัญหาตามผลกระทบต่อธุรกิจและความเร่งด่วน ช่วยให้ทีมจัดการปัญหาสำคัญที่สุดก่อน โดยมักกำหนดระดับมาตรฐาน เช่น วิกฤต สูง ปานกลาง และต่ำ. ในการวิเคราะห์กระบวนการ คุณสามารถใช้ลำดับความสำคัญเป็นมิติสำหรับกรองและเปรียบเทียบข้อมูล นักวิเคราะห์สามารถเปรียบเทียบลำดับงานของปัญหาที่มีความสำคัญสูงกับปัญหาที่มีความสำคัญต่ำ เพื่อดูว่ามีวิธีจัดการต่างกันหรือมีประสิทธิภาพต่างกันหรือไม่ นอกจากนี้ยังจำเป็นต่อการวิเคราะห์การปฏิบัติตาม SLA เพราะ SLA มักกำหนดตามระดับความสำคัญ. เหตุผลที่สำคัญ ช่วยแบ่งข้อมูลเพื่อเปรียบเทียบการจัดการปัญหาสำคัญกับปัญหาทั่วไป และจำเป็นต่อการวัดการปฏิบัติตาม SLA. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในตารางระเบียนปัญหาหลักของแพลตฟอร์ม ITSM ส่วนใหญ่. ตัวอย่าง 1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ | |||
| วันครบกำหนดตาม SLA SlaDueDate | วันที่และเวลาเป้าหมายที่คาดว่าจะแก้ไขระเบียนปัญหาเสร็จตามข้อตกลงระดับการให้บริการ. | ||
| คำอธิบาย วันครบกำหนดตาม SLA กำหนดเป้าหมายอย่างเป็นทางการสำหรับการแก้ไขปัญหา โดยปกติกำหนดตามลำดับความสำคัญของปัญหาและเงื่อนไขในข้อตกลงระดับการให้บริการ (SLA). แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'ภาพรวมการปฏิบัติตาม SLA' องค์กรสามารถคำนวณอัตราการทำตาม SLA โดยเปรียบเทียบเวลาที่ใช้แก้ไขจริงกับวันครบกำหนดตาม SLA ส่วน process mining ช่วยแยกวิเคราะห์เพิ่มเติมเพื่อระบุขั้นตอนหรือทีมที่ทำให้เกิดการผิด SLA มากที่สุด. เหตุผลที่สำคัญ กำหนดเป้าหมายการแก้ไข และเป็นข้อมูลพื้นฐานสำหรับการวัดและรายงานการปฏิบัติตาม SLA. แหล่งข้อมูล โดยทั่วไปจะคำนวณและจัดเก็บวันที่นี้ในระเบียนปัญหา โดยอิงจากเวลาที่สร้างและลำดับความสำคัญของปัญหา. ตัวอย่าง 2023-05-20T17:00:00Z2024-01-10T09:30:00Z2024-03-01T12:00:00Z | |||
| หมวดหมู่สาเหตุที่แท้จริง RootCauseCategory | การจัดประเภทขั้นสุดท้ายของสาเหตุพื้นฐานที่ทำให้เกิดปัญหา. | ||
| คำอธิบาย เมื่อการตรวจสอบเสร็จสิ้น จะใช้หมวดหมู่สาเหตุที่แท้จริงจัดประเภทสาเหตุหลักของปัญหา เช่น 'ข้อบกพร่องของซอฟต์แวร์', 'ฮาร์ดแวร์ขัดข้อง' หรือ 'ข้อผิดพลาดในการกำหนดค่า' การจัดประเภทนี้มีความสำคัญต่อการปรับปรุงในระยะยาว. แอตทริบิวต์นี้เป็นหัวใจของแดชบอร์ด 'ผลการตรวจสอบสาเหตุที่แท้จริง' องค์กรสามารถวิเคราะห์ความถี่ของแต่ละหมวดหมู่ เพื่อระบุปัญหาเชิงระบบที่เกิดซ้ำและจัดลำดับความสำคัญของการแก้ไขระยะยาว ช่วยให้องค์กรเปลี่ยนจากการแก้ปัญหาเฉพาะหน้าไปสู่การป้องกันล่วงหน้า. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์เชิงกลยุทธ์ ช่วยระบุปัญหาเชิงระบบและแนวโน้มของสาเหตุที่ทำให้เกิดปัญหาทั่วทั้งองค์กร. แหล่งข้อมูล โดยปกติจะบันทึกข้อมูลนี้ในฟิลด์เฉพาะของระเบียนปัญหา ซึ่งมักกรอกก่อนหรือระหว่างขั้นตอนปิดงาน. ตัวอย่าง ข้อผิดพลาดในการกำหนดค่าข้อบกพร่องของซอฟต์แวร์ฮาร์ดแวร์ขัดข้องปัญหาด้านการฝึกอบรมผู้ใช้ | |||
| จัดเตรียมวิธีแก้ปัญหาชั่วคราว WorkaroundProvided | แฟล็กที่ระบุว่ามีการค้นพบและแจ้งวิธีแก้ปัญหาชั่วคราวแล้วหรือไม่. | ||
| คำอธิบาย แอตทริบิวต์นี้ติดตามว่ามีวิธีแก้ไขชั่วคราวเพื่อบรรเทาผลกระทบของปัญหาหรือไม่ ระหว่างที่กำลังพัฒนาวิธีแก้ไขถาวร นี่คือหมุดหมายสำคัญในวงจรการจัดการปัญหา. แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'ประสิทธิผลและความรวดเร็วในการใช้วิธีแก้ปัญหาชั่วคราว' process mining ช่วยคำนวณเวลาเฉลี่ยที่ใช้ในการจัดหาวิธีแก้ปัญหาชั่วคราว และวิเคราะห์ต่อได้ว่าการจัดหาวิธีดังกล่าวสัมพันธ์กับจำนวนเหตุขัดข้องใหม่ที่ลดลงหรือไม่ ข้อมูลนี้ช่วยวัดความสามารถของทีมในการทำให้บริการกลับมาใช้งานได้อย่างรวดเร็ว แม้ยังไม่ได้แก้สาเหตุที่แท้จริง. เหตุผลที่สำคัญ ระบุว่าคืนบริการให้ใช้งานได้ชั่วคราวแล้วหรือไม่ ช่วยวิเคราะห์ว่าทีมบรรเทาผลกระทบทางธุรกิจได้รวดเร็วเพียงใด. แหล่งข้อมูล อาจใช้แฟล็กแบบบูลีน ('WorkaroundPublished') หรือพิจารณาจากการมีข้อความในฟิลด์รายละเอียดวิธีแก้ปัญหาชั่วคราว. ตัวอย่าง truefalse | |||
| ผู้ใช้ที่ได้รับมอบหมาย AssignedUser | ผู้ใช้หรือผู้ประสานงานที่ได้รับมอบหมายให้ดูแลระเบียนปัญหาในขณะนั้น. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุบุคคลที่รับผิดชอบปัญหาในแต่ละช่วงเวลา กลุ่มสนับสนุนระบุทีม ส่วนผู้ใช้ที่ได้รับมอบหมายจะระบุเจ้าหน้าที่ วิศวกร หรือผู้ประสานงานที่ดูแลการตรวจสอบ. การวิเคราะห์ตามผู้ใช้ที่ได้รับมอบหมายช่วยให้เข้าใจภาระงาน ผลการดำเนินงาน และความต้องการด้านการฝึกอบรมของแต่ละคน นอกจากนี้ยังช่วยให้เห็นว่ามีใครกลายเป็นคอขวดหรือมีการกระจายงานภายในทีมไม่ทั่วถึงหรือไม่ มุมมองนี้ช่วยเสริมการวิเคราะห์กลุ่มสนับสนุน. เหตุผลที่สำคัญ ช่วยวิเคราะห์ภาระงานและผลการดำเนินงานรายบุคคล เพื่อระบุผู้ที่ทำผลงานได้ดีหรือผู้ที่อาจต้องการความช่วยเหลือหรือการฝึกอบรมเพิ่มเติม. แหล่งข้อมูล โดยทั่วไปจะพบฟิลด์นี้ในตารางระเบียนปัญหาหลัก โดยอาจใช้ชื่อว่า 'ผู้รับมอบหมาย', 'มอบหมายให้' หรือ 'ผู้ประสานงาน'. ตัวอย่าง Alice JohnsonajohnsonBob Smithbsmith | |||
| รหัสคำขอเปลี่ยนแปลงที่เกี่ยวข้อง RelatedChangeRequestId | รหัสคำขอเปลี่ยนแปลงที่เริ่มขึ้นเพื่อนำวิธีแก้ไขปัญหาแบบถาวรไปใช้. | ||
| คำอธิบาย แอตทริบิวต์นี้เชื่อมโยงกระบวนการจัดการปัญหากับกระบวนการจัดการการเปลี่ยนแปลงโดยตรง ใช้เมื่อจำเป็นต้องเปลี่ยนโค้ด เปลี่ยนฮาร์ดแวร์ หรือปรับเปลี่ยนอย่างอื่นเพื่อแก้สาเหตุที่แท้จริงของปัญหา. การวิเคราะห์ลิงก์นี้ช่วยให้เข้าใจ 'ความล่าช้าในการส่งต่องานไปจัดการการเปลี่ยนแปลง' process mining สามารถวัดเวลาตั้งแต่ระบุสาเหตุที่แท้จริงจนถึงสร้างคำขอเปลี่ยนแปลง และตั้งแต่ดำเนินการเปลี่ยนแปลงจนถึงปิดปัญหาได้ในที่สุด ข้อมูลนี้ช่วยระบุจุดที่ทำงานไม่มีประสิทธิภาพระหว่างสองกระบวนการ. เหตุผลที่สำคัญ เชื่อมโยงปัญหากับวิธีแก้ไขในกระบวนการจัดการการเปลี่ยนแปลง ช่วยวิเคราะห์ความล่าช้าในการส่งต่องานและติดตามวงจรการแก้ไขตั้งแต่ต้นจนจบ. แหล่งข้อมูล โดยทั่วไปจะเป็นฟิลด์อ้างอิงในระเบียนปัญหาที่เชื่อมไปยังระเบียนที่เกี่ยวข้องในระบบหรือโมดูลจัดการการเปลี่ยนแปลง. ตัวอย่าง CHG0030219CR-8812CHANGE-401 | |||
| สถานะปัญหา ProblemStatus | สถานะปัจจุบันของระเบียนปัญหาในวงจรชีวิต เช่น เปิด อยู่ระหว่างตรวจสอบ หรือปิดแล้ว. | ||
| คำอธิบาย สถานะปัญหาระบุขั้นตอนปัจจุบันของปัญหาในเวิร์กโฟลว์ แสดงให้เห็นว่าปัญหาอยู่ในขั้นใด ตั้งแต่บันทึกครั้งแรกจนถึงการแก้ไขขั้นสุดท้าย. ชื่อกิจกรรมบันทึกเหตุการณ์ที่เปลี่ยนสถานะ ส่วนสถานะปัญหาใช้วิเคราะห์งานค้างในปัจจุบัน คุณสามารถสร้างแดชบอร์ดเพื่อแสดงจำนวนปัญหาที่ยังเปิดอยู่ในแต่ละสถานะ ช่วยจัดการภาระงานและระบุระเบียนที่ค้างอยู่ในขั้นตอนใดขั้นตอนหนึ่งนานเกินไป. เหตุผลที่สำคัญ แสดงขั้นตอนปัจจุบันของปัญหา ซึ่งจำเป็นต่อการวิเคราะห์งานค้างและระบุปัญหาที่หยุดค้างอยู่ในขั้นตอนใดขั้นตอนหนึ่ง. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในตารางระเบียนปัญหาหลัก ซึ่งจะอัปเดตเมื่อปัญหาดำเนินไปตามวงจรชีวิต. ตัวอย่าง เปิดการวิเคราะห์หาสาเหตุที่แท้จริงรอการเปลี่ยนแปลงแก้ไขแล้วปิดแล้ว | |||
กิจกรรมในการจัดการปัญหา
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| จัดเตรียมวิธีแก้ปัญหาชั่วคราว | เหตุการณ์นี้หมายถึงมีการบันทึกและเผยแพร่แนวทางแก้ไขชั่วคราวแล้ว ช่วยลดผลกระทบต่อผู้ใช้ปลายทางระหว่างพัฒนาการแก้ไขถาวร. | ||
| เหตุผลที่สำคัญ เวลาที่ใช้ในการแจ้งวิธีแก้ปัญหาชั่วคราวเป็น KPI สำคัญสำหรับวัดความสามารถของทีมในการคืนบริการให้กลับมาใช้งานได้อย่างรวดเร็ว กิจกรรมนี้ช่วยวิเคราะห์ความเร็วและประสิทธิผลของแนวทางแก้ไขชั่วคราว. แหล่งข้อมูล บันทึกได้จากเวลาครั้งแรกที่มีการกรอกข้อความในช่อง “Workaround” การบันทึกการดำเนินการ “Communicate Workaround” หรือการตั้งค่าสถานะ “Workaround Available”. บันทึก ตรวจจับครั้งแรกที่มีการกรอกข้อมูลในช่องวิธีแก้ปัญหาชั่วคราว หรือเหตุการณ์เผยแพร่ที่เกี่ยวข้อง. ประเภทเหตุการณ์ explicit | |||
| นำการแก้ไขถาวรไปใช้แล้ว | เหตุการณ์นี้แสดงว่ามีการนำแนวทางแก้ไขทางเทคนิคแบบถาวร ซึ่งมักจัดการผ่านคำขอเปลี่ยนแปลง ไปใช้สำเร็จแล้ว ถือเป็นการสิ้นสุดงานแก้ไขปัญหา. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดของขั้นตอนนำแนวทางแก้ไขไปใช้ ระยะเวลาตั้งแต่เริ่มคำขอเปลี่ยนแปลงจนถึงจุดนี้ใช้วัดประสิทธิภาพของกระบวนการจัดการการเปลี่ยนแปลงในการแก้ปัญหา. แหล่งข้อมูล โดยทั่วไปอนุมานจากสถานะของรายการปัญหาที่เปลี่ยนเป็น “Resolved” หรือ “Solution Implemented” ซึ่งมักเกิดขึ้นเมื่อปิดคำขอเปลี่ยนแปลงที่เชื่อมโยงไว้. บันทึก อนุมานจากการเปลี่ยนสถานะปัญหาเป็น “Resolved” หรือจากเวลาที่รายการเปลี่ยนแปลงที่เกี่ยวข้องเสร็จสมบูรณ์. ประเภทเหตุการณ์ inferred | |||
| ปิดรายการปัญหา | กิจกรรมสุดท้ายในวงจรนี้ แสดงว่าปิดรายการปัญหาในระบบเรียบร้อยแล้วและไม่ต้องดำเนินการต่อ ถือว่าเคสเสร็จสมบูรณ์และจัดเก็บเข้าคลังแล้ว. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดหลักของกระบวนการส่วนใหญ่ และจำเป็นต่อการคำนวณระยะเวลารวมตั้งแต่ต้นจนจบของกระบวนการจัดการปัญหา. แหล่งข้อมูล แทบทุกครั้งจะบันทึกเป็นเหตุการณ์โดยตรงจากการเปลี่ยนสถานะเป็น “Closed” ในบันทึกประวัติของรายการ. บันทึก ใช้เวลาที่สถานะของรายการเปลี่ยนเป็น “Closed”. ประเภทเหตุการณ์ explicit | |||
| ระบุสาเหตุที่แท้จริง | กิจกรรมนี้เป็นหมุดหมายที่แสดงว่าวินิจฉัยและบันทึกสาเหตุเบื้องหลังของปัญหาได้สำเร็จ ถือเป็นการสิ้นสุดขั้นตอนการตรวจสอบ. | ||
| เหตุผลที่สำคัญ หมุดหมายนี้สำคัญต่อการวัดประสิทธิภาพในการวินิจฉัย ระยะเวลาตั้งแต่เริ่มตรวจสอบจนถึงระบุสาเหตุที่แท้จริงเป็นตัวชี้วัดผลการดำเนินงานสำคัญของการวิเคราะห์ปัญหา. แหล่งข้อมูล มักอนุมานจากการเปลี่ยนสถานะเป็น “Root Cause Identified” หรือบันทึกเมื่อมีการกรอกข้อมูลในช่อง “Root Cause” เป็นครั้งแรก. บันทึก บันทึกเวลาที่สถานะเปลี่ยน หรือเวลาที่มีการปรับปรุงช่องข้อความ “Root Cause” ครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| เริ่มคำขอเปลี่ยนแปลง | เหตุการณ์นี้บันทึกการสร้างหรือเชื่อมโยงคำขอเปลี่ยนแปลงอย่างเป็นทางการกับรายการปัญหา เป็นจุดส่งต่องานจากกระบวนการจัดการปัญหาไปยังกระบวนการจัดการการเปลี่ยนแปลง เพื่อนำการแก้ไขถาวรไปใช้. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการวิเคราะห์ความล่าช้าระหว่างการวินิจฉัยปัญหากับการเริ่มแก้ไข และช่วยระบุคอขวดตรงจุดเชื่อมระหว่างการจัดการปัญหากับการจัดการการเปลี่ยนแปลง. แหล่งข้อมูล โดยทั่วไปจะเป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในประวัติความสัมพันธ์หรือลิงก์ของรายการ ซึ่งแสดงการเชื่อมโยงกับรายการเปลี่ยนแปลง. บันทึก ระบุเหตุการณ์ที่มีการเชื่อมโยงรายการเปลี่ยนแปลงกับรายการปัญหา. ประเภทเหตุการณ์ explicit | |||
| เริ่มตรวจสอบ | เหตุการณ์นี้บันทึกการเปลี่ยนสถานะของรายการปัญหาจากสถานะใหม่หรือรอดำเนินการไปเป็นสถานะกำลังตรวจสอบ แสดงว่านักวิเคราะห์เริ่มวินิจฉัยปัญหาอย่างเป็นทางการแล้ว. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยวัดเวลาตอบสนองเบื้องต้นและความเร็วในการจัดการงานค้าง ระยะเวลาตั้งแต่สร้างรายการจนถึงเริ่มตรวจสอบเป็นตัวชี้วัดสำคัญที่แสดงความรวดเร็วในการตอบสนองของทีม. แหล่งข้อมูล มักอนุมานจากการเปลี่ยนสถานะในประวัติรายการ เช่น จาก “New” เป็น “In Progress” หรือ “Under Investigation”. บันทึก บันทึกเวลาที่สถานะเปลี่ยนเป็นสถานะกำลังตรวจสอบครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| สร้างรายการปัญหา | กิจกรรมนี้คือการสร้างรายการปัญหาครั้งแรก เป็นจุดเริ่มต้นอย่างเป็นทางการของกระบวนการจัดการปัญหา และเป็นเวลาฐานสำหรับการวิเคราะห์ขั้นตอนถัดไปทั้งหมด. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นหลักของกระบวนการแต่ละกรณี การวิเคราะห์เวลาตั้งแต่เหตุการณ์นี้ไปจนถึงเหตุการณ์อื่นมีความสำคัญต่อการทำความเข้าใจระยะเวลารวมของกระบวนการและความล่าช้าในช่วงต้น. แหล่งข้อมูล โดยทั่วไปจะบันทึกจากเวลาที่สร้างรายการปัญหาหลักหรือรายการในตารางทิกเก็ต ซึ่งแทบทุกครั้งจะมีช่องข้อมูลนี้ในข้อมูลต้นทาง. บันทึก ใช้เวลาจากช่อง “Created On” หรือช่องเวลาที่มีความหมายเดียวกันในตารางปัญหาหลัก. ประเภทเหตุการณ์ explicit | |||
| ตรวจพบการผิด SLA | เหตุการณ์นี้หมายถึงเวลาที่ใช้จนถึงการแก้ไขปัญหาหรือถึงเป้าหมายการตอบสนองเกินกำหนดตามข้อตกลงระดับการให้บริการ (SLA) ที่ตั้งไว้ ระบบสร้างหรือคำนวณเหตุการณ์นี้. | ||
| เหตุผลที่สำคัญ การติดตามกรณีผิด SLA เป็นพื้นฐานสำคัญของการจัดการผลการดำเนินงานและการรายงานการปฏิบัติตามข้อกำหนด โดยแสดงกรณีที่ไม่เป็นไปตามข้อตกลงระดับการให้บริการโดยตรง. แหล่งข้อมูล อาจบันทึกเป็นแฟล็กหรือเหตุการณ์เฉพาะในระบบ หรือคำนวณโดยเปรียบเทียบเวลาที่แก้ไขปัญหากับวันครบกำหนดตาม SLA. บันทึก คำนวณโดยเปรียบเทียบเวลาที่แก้ไขปัญหาหรือตอบสนองกับเวลาเป้าหมายตาม SLA หรือบันทึกเหตุการณ์ผิด SLA ที่ระบบสร้างขึ้น. ประเภทเหตุการณ์ calculated | |||
| ทบทวนหลังนำการแก้ไขไปใช้เสร็จแล้ว | เหตุการณ์นี้บันทึกการทบทวนหลังนำการแก้ไขไปใช้ (PIR) เสร็จสิ้น การทบทวนอย่างเป็นทางการนี้วิเคราะห์วิธีจัดการปัญหา เพื่อระบุบทเรียนที่ได้รับและแนวทางปรับปรุงกระบวนการ. | ||
| เหตุผลที่สำคัญ การติดตามการทำ PIR ให้เสร็จมีความสำคัญต่อการปฏิบัติตามข้อกำหนดของกระบวนการและการปรับปรุงอย่างต่อเนื่อง ช่วยให้บันทึกและนำข้อมูลเชิงลึกจากปัญหาสำคัญไปใช้ได้. แหล่งข้อมูล มักบันทึกจากการทำงานย่อยที่เกี่ยวข้องกับ PIR เสร็จสิ้น การเปลี่ยนสถานะเป็น “Review Complete” หรือการกรอกวันที่ทำ PIR เสร็จในช่องข้อมูล. บันทึก ระบุว่างานที่เกี่ยวข้องกับ PIR เสร็จสิ้น หรือมีการปรับปรุงสถานะที่กำหนด. ประเภทเหตุการณ์ explicit | |||
| เปลี่ยนลำดับความสำคัญ | กิจกรรมนี้บันทึกการปรับปรุงลำดับความสำคัญ ผลกระทบ หรือความเร่งด่วนของรายการปัญหาหลังสร้างรายการครั้งแรก แสดงถึงการประเมินความสำคัญของปัญหาต่อธุรกิจอีกครั้ง. | ||
| เหตุผลที่สำคัญ การวิเคราะห์การเปลี่ยนลำดับความสำคัญช่วยระบุปัญหาที่ถูกยกระดับหรือลดระดับความสำคัญบ่อยครั้ง ซึ่งอาจส่งผลต่อการจัดสรรทรัพยากรและการปฏิบัติตาม SLA. แหล่งข้อมูล โดยทั่วไปจะบันทึกไว้ในบันทึกการตรวจสอบหรือตารางประวัติการเปลี่ยนแปลงที่ติดตามการแก้ไขช่อง “Priority”. บันทึก ติดตามการปรับปรุงช่อง “Priority” ทั้งหมดในประวัติการเปลี่ยนแปลงของรายการ. ประเภทเหตุการณ์ explicit | |||
| เปิดรายการปัญหาอีกครั้ง | กิจกรรมนี้เกิดขึ้นเมื่อรายการปัญหาที่แก้ไขหรือปิดไปแล้วกลับมาอยู่ในสถานะดำเนินการ โดยทั่วไปหมายความว่าการแก้ไขที่นำไปใช้ไม่ได้ผล หรือปัญหาเกิดขึ้นอีก. | ||
| เหตุผลที่สำคัญ อัตราการเปิดรายการซ้ำที่สูงเป็นตัวชี้วัดสำคัญว่าคุณภาพการแก้ปัญหายังไม่ดี การติดตามกิจกรรมนี้มีความสำคัญต่อการวัดอัตราการแก้ปัญหาได้ตั้งแต่ครั้งแรกและระบุแนวทางแก้ไขที่ไม่ได้ผล. แหล่งข้อมูล บันทึกเหตุการณ์นี้โดยติดตามประวัติสถานะของรายการ เพื่อดูการเปลี่ยนจากสถานะปิดหรือแก้ไขแล้วกลับไปเป็นสถานะเปิดหรือกำลังดำเนินการ. บันทึก ระบุการเปลี่ยนสถานะจาก “Resolved” หรือ “Closed” กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น “Open”. ประเภทเหตุการณ์ explicit | |||
| มอบหมายให้กลุ่มสนับสนุน | กิจกรรมนี้หมายถึงการมอบหมายหรือมอบหมายใหม่ให้รายการปัญหาไปยังกลุ่มสนับสนุนหรือทีมที่ระบุ บันทึกการโอนความเป็นเจ้าของและความรับผิดชอบในการตรวจสอบปัญหา. | ||
| เหตุผลที่สำคัญ การติดตามการมอบหมายมีความสำคัญต่อการวิเคราะห์ความล่าช้าในการส่งต่องาน ระบุคอขวดระหว่างทีม และทำความเข้าใจผลการดำเนินงานของแต่ละกลุ่ม หากมีการมอบหมายใหม่หลายครั้ง มักเป็นสัญญาณว่ากระบวนการไม่มีประสิทธิภาพ. แหล่งข้อมูล โดยปกติจะพบข้อมูลนี้ในบันทึกการตรวจสอบหรือตารางประวัติที่ติดตามการเปลี่ยนแปลงช่อง “Assignment Group” หรือ “Support Team” ในรายการปัญหา. บันทึก ระบุการเปลี่ยนแปลงทั้งหมดของช่องกลุ่มผู้รับผิดชอบในบันทึกประวัติของรายการ. ประเภทเหตุการณ์ explicit | |||
| ยกเลิกรายการปัญหา | กิจกรรมนี้หมายถึงการยุติระเบียนปัญหาก่อนที่จะหาทางแก้ไขได้ อาจเกิดขึ้นเมื่อสร้างระเบียนผิดพลาด เป็นรายการซ้ำ หรือไม่เกี่ยวข้องอีกต่อไป. | ||
| เหตุผลที่สำคัญ การวิเคราะห์รายการที่ยกเลิกช่วยให้เข้าใจคุณภาพของระเบียนปัญหาที่รับเข้ามา หากอัตราการยกเลิกสูง อาจต้องปรับปรุงการฝึกอบรมหรือเกณฑ์การคัดกรอง. แหล่งข้อมูล บันทึกเหตุการณ์นี้จากการเปลี่ยนสถานะเป็น 'ยกเลิก', 'ปฏิเสธ' หรือ 'ถอนคำขอ' ในประวัติของระเบียน. บันทึก ระบุเวลาที่สถานะเปลี่ยนเป็นสถานะยกเลิกขั้นสุดท้าย. ประเภทเหตุการณ์ explicit | |||
| ยืนยันผลการแก้ไขแล้ว | กิจกรรมนี้หมายถึงการยืนยันว่าการแก้ไขที่นำไปใช้จัดการปัญหาที่ต้นเหตุได้ผล และบริการกลับสู่ภาวะปกติ เป็นขั้นตอนตรวจสอบขั้นสุดท้ายก่อนปิดรายการ. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เป็นการตรวจสอบคุณภาพของการแก้ไข การวิเคราะห์เวลาที่ใช้ในการตรวจสอบยืนยันช่วยให้เห็นความล่าช้าในการยืนยันผลสำเร็จของการแก้ไข. แหล่งข้อมูล อาจบันทึกเป็นสถานะโดยตรง เช่น “Verification” หรืออนุมานจากการเปลี่ยนไปเป็นสถานะ “Resolved” หรือ “Solved”. บันทึก บันทึกเวลาที่สถานะเปลี่ยนเป็นสถานะซึ่งแสดงว่ามีการยืนยันผลการแก้ไขแล้ว. ประเภทเหตุการณ์ inferred | |||
| รอนำการเปลี่ยนแปลงไปใช้ | กิจกรรมนี้หมายถึงสถานะที่พักรายการปัญหาไว้เพื่อรอให้คำขอเปลี่ยนแปลงที่เกี่ยวข้องเสร็จสิ้น ทีมจัดการปัญหากำลังรอทีมจัดการการเปลี่ยนแปลงนำการแก้ไขไปใช้. | ||
| เหตุผลที่สำคัญ การแยกช่วงเวลารอนี้ออกมาช่วยวัดเวลาที่ใช้ในกระบวนการจัดการการเปลี่ยนแปลงเทียบกับกระบวนการจัดการปัญหาได้อย่างถูกต้อง และช่วยให้ระบุความรับผิดชอบได้ชัดเจนขึ้น. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะของรายการปัญหาเป็น “Pending Change” หรือ “Fix in Progress”. บันทึก บันทึกเวลาที่สถานะของรายการปัญหาเปลี่ยนเป็นสถานะรอการเปลี่ยนแปลง. ประเภทเหตุการณ์ inferred | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เลือกคู่มือสำหรับระบบที่คุณใช้เพื่อดูคำแนะนำที่ตรงกับระบบ หรือใช้เทมเพลตทั่วไปนี้เพื่อเริ่มวิเคราะห์กระบวนการจัดการปัญหาได้เลย.
ยกระดับการจัดการปัญหา เริ่มได้เลย
ใช้ข้อมูลเพื่อค้นหาจุดที่ไม่มีประสิทธิภาพและแก้ปัญหาได้เร็วขึ้น.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.