เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
- แอตทริบิวต์ที่แนะนำสำหรับการวิเคราะห์เชิงลึก
- กิจกรรมหลักที่ควรติดตามเพื่อค้นหากระบวนการ
- คำแนะนำในการดึงข้อมูลจากระบบต้นทาง
แอตทริบิวต์สำหรับการจัดการคำขอบริการ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
Service Request ID
ServiceRequestID
|
รหัสเฉพาะที่ใช้ระบุคำขอบริการแต่ละรายการ. | ||
|
คำอธิบาย
Service Request ID เป็นรหัสเฉพาะของคำขอบริการแต่ละรายการที่ผู้ใช้หรือระบบส่งเข้ามา รหัสนี้เชื่อมโยงเหตุการณ์ทั้งหมดที่เกิดขึ้นภายหลัง ตั้งแต่บันทึกคำขอครั้งแรกจนถึงปิดคำขอ ทำให้วิเคราะห์เส้นทางของคำขอแต่ละรายการได้ตั้งแต่ต้นจนจบ.
เหตุผลที่สำคัญ
นี่คือรหัสกรณีหลักที่เชื่อมกิจกรรมที่เกี่ยวข้องทั้งหมดเข้าด้วยกันเป็นกระบวนการเดียว ทำให้วิเคราะห์กระบวนการตั้งแต่ต้นจนจบได้.
แหล่งข้อมูล
นี่คือคีย์หลักของ business object ของ Service Request ซึ่งมักใช้ชื่อ ServiceReqNumber ในตาราง ServiceReq.
ตัวอย่าง
SR-0012345SR-0012346SR-0012347
|
|||
|
ชื่อกิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้น ณ จุดหนึ่งในวงจรคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้อธิบายขั้นตอนหรือการเปลี่ยนสถานะเฉพาะในกระบวนการคำขอบริการ เช่น 'ส่งคำขอบริการเพื่อขออนุมัติ' หรือ 'แก้ไขคำขอบริการแล้ว' การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นพื้นฐานสำคัญในการทำความเข้าใจขั้นตอนการทำงาน ค้นหาคอขวด และตรวจพบความเบี่ยงเบนจากขั้นตอนมาตรฐาน.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้กำหนดขั้นตอนในแผนผังกระบวนการ ทำให้เห็นและวิเคราะห์ขั้นตอนการทำงาน รวมถึงค้นหางานที่ต้องทำซ้ำ คอขวด และความเบี่ยงเบนได้.
แหล่งข้อมูล
โดยทั่วไปได้จากการเปลี่ยนสถานะ รายการบันทึกประจำวัน หรือคำอธิบายเหตุการณ์ในบันทึกการตรวจสอบของ Ivanti Service Manager.
ตัวอย่าง
สร้างคำขอบริการแล้วอนุมัติคำขอแล้วแก้ไขคำขอบริการแล้วปิดคำขอบริการแล้ว
|
|||
|
เวลาที่เกิดเหตุการณ์
EventTime
|
เวลาประทับที่ระบุว่าเกิดกิจกรรมหรือเหตุการณ์เมื่อใด. | ||
|
คำอธิบาย
เวลาที่เกิดเหตุการณ์ หรือที่เรียกว่าเวลาเริ่มต้น คือวันและเวลาที่แน่นอนซึ่งระบบบันทึกกิจกรรมไว้ เวลาประทับนี้จำเป็นต่อการเรียงลำดับเหตุการณ์ให้ถูกต้อง และเป็นพื้นฐานของการวิเคราะห์ process mining ที่อิงเวลา เช่น การคำนวณระยะเวลาดำเนินการ เวลารอ และระยะเวลาของกิจกรรม.
เหตุผลที่สำคัญ
เวลาประทับนี้จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลาและคำนวณตัวชี้วัดด้านระยะเวลาทั้งหมด ซึ่งเป็นข้อมูลสำคัญสำหรับวิเคราะห์ผลการดำเนินงาน.
แหล่งข้อมูล
ค้นหาได้จากบันทึกการตรวจสอบ รายการบันทึกประจำวัน เช่น Journal.CreatedDateTime หรือระเบียนการเปลี่ยนสถานะที่เชื่อมโยงกับ Service Request.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ใช้ดึงข้อมูลออกมา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลกระบวนการ สำหรับมุมมองนี้ ค่าจะเหมือนกันทั้งหมด โดยระบุว่าข้อมูลมาจาก Ivanti Service Manager ซึ่งสำคัญเมื่อรวมข้อมูลจากหลายระบบ เพื่อให้ตรวจสอบที่มาและบริบทของข้อมูลได้ชัดเจน.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้ให้บริบทสำคัญเกี่ยวกับที่มาของข้อมูล ช่วยให้ระบุผลการวิเคราะห์กับระบบต้นทางที่ถูกต้อง โดยเฉพาะในสภาพแวดล้อมที่ใช้หลายระบบ.
แหล่งข้อมูล
โดยทั่วไปจะกำหนดค่าแบบคงที่ระหว่างการดึงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล.
ตัวอย่าง
Ivanti Service Manager
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่รีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุวันและเวลาที่ดึงข้อมูลจาก Ivanti Service Manager ครั้งล่าสุด ช่วยให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด ครอบคลุมช่วงเวลาใด และคาดว่าจะอัปเดตครั้งต่อไปเมื่อใด.
เหตุผลที่สำคัญ
แจ้งให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ซึ่งสำคัญต่อการตัดสินใจโดยอิงข้อมูลผลการดำเนินงานของกระบวนการล่าสุดที่มี.
แหล่งข้อมูล
ระบบสร้างค่านี้และบันทึกลงในชุดข้อมูลขณะดึงข้อมูล.
ตัวอย่าง
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
กำหนดเวลา SLA
SLADeadline
|
เวลาที่คาดว่าจะแก้ไขคำขอบริการเสร็จ. | ||
|
คำอธิบาย
กำหนดเวลา SLA คือวันที่และเวลาที่คำนวณไว้ ซึ่งต้องแก้ไขคำขอบริการให้เสร็จเพื่อให้เป็นไปตามข้อตกลงระดับการให้บริการ โดยทั่วไปจะกำหนดเป้าหมายจากปัจจัยต่างๆ เช่น ระดับความสำคัญและประเภทของคำขอ การเปรียบเทียบเวลาแก้ไขจริงกับกำหนดเวลานี้ใช้วัดการปฏิบัติตาม SLA.
เหตุผลที่สำคัญ
เป็นเกณฑ์สำหรับเปรียบเทียบผลการดำเนินงานจริง ช่วยคำนวณอัตราการปฏิบัติตาม SLA และระบุคำขอที่เสี่ยงไม่ทันกำหนด.
แหล่งข้อมูล
มักเป็นฟิลด์ที่คำนวณใน Ivanti และจัดเก็บไว้ในฟิลด์ที่เกี่ยวข้องกับ Service Level Agreement หรือ Offering เช่น “ResolutionTargetDateTime”.
ตัวอย่าง
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
เจ้าหน้าที่ที่ได้รับมอบหมาย
AssignedAgent
|
ผู้ใช้หรือเจ้าหน้าที่ที่ได้รับมอบหมายให้ดูแลคำขอบริการ. | ||
|
คำอธิบาย
เจ้าหน้าที่ที่ได้รับมอบหมายคือผู้รับผิดชอบดำเนินการกับคำขอบริการโดยตรง แอตทริบิวต์นี้ช่วยให้วิเคราะห์รายบุคคลได้ ซึ่งเป็นประโยชน์ต่อการบริหารผลการปฏิบัติงาน การปรับสมดุลภาระงาน และการระบุโอกาสในการฝึกอบรม การติดตามการเปลี่ยนผู้รับผิดชอบช่วยคำนวณ KPI เช่น “จำนวนครั้งเฉลี่ยที่เปลี่ยนผู้รับผิดชอบต่อคำขอ” และทำความเข้าใจจุดที่กระบวนการไม่มีประสิทธิภาพ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ภาระงาน ผลการปฏิบัติงาน และรูปแบบการเปลี่ยนผู้รับผิดชอบรายบุคคล ซึ่งอาจบ่งชี้ปัญหาด้านการฝึกอบรม ทักษะ หรือการส่งต่องานตั้งแต่แรก.
แหล่งข้อมูล
โดยทั่วไปจะอยู่ในฟิลด์อย่าง “Owner” ของออบเจ็กต์ Service Request ค่านี้อาจเปลี่ยนทุกครั้งที่มีการมอบหมายใหม่ จึงควรติดตามไว้ในบันทึกเหตุการณ์.
ตัวอย่าง
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
ทีมที่ได้รับมอบหมาย
AssignedTeam
|
ทีมสนับสนุนหรือกลุ่มที่ได้รับมอบหมายให้ดูแลคำขอบริการในขณะนั้น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุทีมที่รับผิดชอบดำเนินการกับคำขอบริการในแต่ละช่วงเวลา การวิเคราะห์การส่งต่องานระหว่างทีม เวลาที่ใช้กับแต่ละทีม และจำนวนคำขอที่แต่ละทีมดูแล ช่วยให้เข้าใจการกระจายภาระงาน ระบุคอขวด และประเมินผลการทำงานของทีมได้ อีกทั้งยังใช้ประกอบแดชบอร์ดเกี่ยวกับการปฏิบัติตาม SLA และภาระงานของเจ้าหน้าที่.
เหตุผลที่สำคัญ
ใช้ติดตามผู้รับผิดชอบและการส่งต่องาน ช่วยวิเคราะห์ความล่าช้าระหว่างทีม ความสมดุลของภาระงาน และทีมที่เป็นคอขวดในกระบวนการ.
แหล่งข้อมูล
ข้อมูลนี้มักจัดเก็บในฟิลด์อย่าง “OwnerTeam” ของออบเจ็กต์ Service Request หรือในระเบียนการมอบหมายที่เกี่ยวข้อง.
ตัวอย่าง
ศูนย์บริการด้านไอทีฝ่ายปฏิบัติการเครือข่ายฝ่ายสนับสนุนทรัพยากรบุคคลฝ่ายบริหารอาคารสถานที่
|
|||
|
ประเภทคำขอบริการ
ServiceRequestType
|
การจัดประเภทหรือหมวดหมู่ของคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ใช้จัดหมวดหมู่คำขอบริการ เช่น “คำขอฮาร์ดแวร์” “ติดตั้งซอฟต์แวร์” หรือ “รีเซ็ตรหัสผ่าน” เป็นมิติสำคัญในการวิเคราะห์ ช่วยให้ทีมเปรียบเทียบประสิทธิภาพของกระบวนการ ระยะเวลาดำเนินการ และการปฏิบัติตาม SLA ของบริการแต่ละประเภทได้ เมื่อเข้าใจความแตกต่างเหล่านี้ ทีมจะปรับปรุงกระบวนการและจัดสรรทรัพยากรได้เหมาะสมยิ่งขึ้น.
เหตุผลที่สำคัญ
การแยกวิเคราะห์กระบวนการตามประเภทคำขอช่วยให้ตรวจสอบได้ตรงจุด และเห็นว่าคำขอประเภทใดมีแนวโน้มล่าช้า ต้องทำงานซ้ำ หรือไม่เป็นไปตาม SLA มากกว่า.
แหล่งข้อมูล
มักเป็นฟิลด์ในออบเจ็กต์ Service Request ซึ่งอาจใช้ชื่อว่า “Service” หรือ “Category” โปรดดูเอกสารประกอบ Ivanti Service Manager เพื่อค้นหาชื่อฟิลด์ที่แน่นอน เช่น “SvcReqTmplLink_Category”.
ตัวอย่าง
คำขอฮาร์ดแวร์ใหม่สิทธิ์เข้าถึงซอฟต์แวร์แก้ไขบัญชีผู้ใช้สอบถามข้อมูล
|
|||
|
ระดับความสำคัญ
Priority
|
ระดับความสำคัญที่กำหนดให้กับคำขอบริการ. | ||
|
คำอธิบาย
ระดับความสำคัญแสดงความเร่งด่วนของคำขอบริการ โดยทั่วไปแบ่งเป็น “ต่ำ” “ปานกลาง” “สูง” และ “วิกฤต” แอตทริบิวต์นี้ช่วยประเมินว่ากระบวนการเร่งจัดการคำขอที่มีความสำคัญสูงได้ผลหรือไม่ การวิเคราะห์มักเปรียบเทียบระยะเวลาดำเนินการและการปฏิบัติตาม SLA ในแต่ละระดับ เพื่อให้มั่นใจว่าการจัดลำดับความสำคัญเป็นไปตามที่ตั้งใจไว้.
เหตุผลที่สำคัญ
จำเป็นต่อการประเมินว่ากลยุทธ์การจัดลำดับความสำคัญได้ผลหรือไม่ และช่วยให้มั่นใจว่าคำขอที่มีความสำคัญสูงได้รับการแก้ไขเร็วกว่าคำขอที่มีความสำคัญต่ำ.
แหล่งข้อมูล
ฟิลด์มาตรฐานในออบเจ็กต์ Service Request ซึ่งมักใช้ชื่อว่า “Priority”.
ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
|
|||
|
เวลาที่แก้ไขเสร็จ
ResolutionDateTime
|
วันที่และเวลาที่แก้ไขคำขอบริการเสร็จอย่างเป็นทางการ. | ||
|
คำอธิบาย
แอตทริบิวต์ระดับเคสนี้ระบุเวลาสุดท้ายที่ส่งมอบบริการหรือแก้ไขปัญหาเสร็จ ก่อนปิดคำขออย่างเป็นทางการ เวลานี้เป็นจุดสิ้นสุดหลักที่ใช้คำนวณระยะเวลาดำเนินการตั้งแต่ต้นจนจบของคำขอบริการ และเป็นข้อมูลสำคัญในการวัดประสิทธิภาพโดยรวมของกระบวนการและการปฏิบัติตาม SLA.
เหตุผลที่สำคัญ
กำหนดจุดสิ้นสุดสำหรับคำนวณระยะเวลาดำเนินการหลักของกระบวนการ ซึ่งเป็นตัวชี้วัดสำคัญของประสิทธิภาพการส่งมอบบริการ.
แหล่งข้อมูล
ฟิลด์เวลาที่ระบุไว้ในออบเจ็กต์ Service Request ซึ่งมักใช้ชื่อว่า “ResolvedDateTime” หรือชื่อใกล้เคียง.
ตัวอย่าง
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
เวลาสิ้นสุดกิจกรรม
EventEndTime
|
เวลาที่ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาสิ้นสุดเหตุการณ์ระบุว่ากิจกรรมเสร็จสมบูรณ์แล้ว ระยะเวลาตั้งแต่เวลาเหตุการณ์ (เวลาเริ่มต้น) จนถึงเวลาสิ้นสุดเหตุการณ์ คือเวลาที่ใช้ดำเนินกิจกรรมนั้น ข้อมูลนี้ช่วยให้ทราบว่าขั้นตอนใดใช้เวลามากที่สุด และช่วยระบุจุดที่ไม่มีประสิทธิภาพกับโอกาสในการปรับปรุงกระบวนการ.
เหตุผลที่สำคัญ
ข้อมูลนี้ใช้คำนวณระยะเวลาของแต่ละกิจกรรม ซึ่งจำเป็นต่อการระบุคอขวดในกระบวนการและงานที่ใช้เวลานาน.
แหล่งข้อมูล
อาจไม่มีฟิลด์นี้แยกไว้โดยเฉพาะ โดยทั่วไปจะใช้เวลาเริ่มต้นของกิจกรรมถัดไปในลำดับของเคสเดียวกันแทน.
ตัวอย่าง
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
สถานะ SLA
SLAStatus
|
ระบุว่าแก้ไขคำขอบริการเสร็จภายในกำหนดเวลาตาม SLA หรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณจากข้อมูลนี้กำหนดสถานะของคำขอบริการแต่ละรายการเป็น “เป็นไปตามกำหนด” หรือ “เกินกำหนด” โดยพิจารณาจากเวลาแก้ไขเทียบกับกำหนดเวลาตาม SLA ข้อมูลนี้เป็นพื้นฐานของแดชบอร์ด “ผลการปฏิบัติตาม SLA” และ KPI “อัตราการปฏิบัติตามข้อตกลงระดับการให้บริการ” โดยเปรียบเทียบ ResolutionDateTime กับ SLADeadline ของแต่ละเคส.
เหตุผลที่สำคัญ
ใช้วัดผลการดำเนินงานเทียบกับข้อตกลงการให้บริการโดยตรง ซึ่งสำคัญต่อการประเมินคุณภาพบริการและรักษาความไว้วางใจของผู้ใช้.
แหล่งข้อมูล
คำนวณโดยเปรียบเทียบ “ResolutionDateTime” กับ “SLADeadline” หาก ResolutionDateTime <= SLADeadline สถานะจะเป็น “เป็นไปตามกำหนด” มิฉะนั้นจะเป็น “เกินกำหนด”.
ตัวอย่าง
เป็นไปตามกำหนดเกินกำหนด
|
|||
|
สถานะคำขอบริการ
ServiceRequestStatus
|
สถานะของคำขอบริการ ณ เวลาที่เกิดเหตุการณ์. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกสถานะของคำขอบริการ เช่น “บันทึกแล้ว” “กำลังดำเนินการ” “รอดำเนินการ” “แก้ไขแล้ว” หรือ “ปิดแล้ว” การเปลี่ยนสถานะมักใช้กำหนดกิจกรรมในบันทึกกระบวนการ การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะช่วยระบุคอขวดได้ เช่น คำขอที่ค้างอยู่ในสถานะ “รอดำเนินการ” นานเกินไป.
เหตุผลที่สำคัญ
แสดงสถานะของคำขอในแต่ละช่วงเวลา ซึ่งจำเป็นต่อการคำนวณเวลาที่ใช้ในแต่ละสถานะและระบุจุดที่กระบวนการหยุดชะงัก.
แหล่งข้อมูล
ฟิลด์มาตรฐานในออบเจ็กต์ Service Request ซึ่งมักใช้ชื่อว่า “Status”.
ตัวอย่าง
บันทึกแล้วกำลังดำเนินการรอข้อมูลจากลูกค้าดำเนินการตามคำขอแล้วปิดแล้ว
|
|||
|
จำนวนครั้งที่เปิดคำขออีกครั้ง
ReopenCount
|
จำนวนครั้งที่เปิดคำขอบริการที่แก้ไขแล้วกลับมาดำเนินการอีกครั้ง. | ||
|
คำอธิบาย
แอตทริบิวต์นี้นับจำนวนครั้งที่เปลี่ยนสถานะคำขอบริการจาก “แก้ไขแล้ว” หรือ “ปิดแล้ว” กลับเป็น “กำลังดำเนินการ” หากเปิดคำขออีกครั้งหลายครั้ง อาจบ่งชี้ว่าการแก้ไขครั้งแรกไม่มีคุณภาพ แก้ปัญหาไม่ครบ หรือปัญหาเกิดซ้ำ ข้อมูลนี้ใช้คำนวณ KPI “อัตราการทำงานซ้ำของคำขอบริการ” ได้โดยตรง.
เหตุผลที่สำคัญ
ใช้วัดการทำงานซ้ำโดยตรงและเป็นตัวชี้วัดสำคัญของคุณภาพการแก้ไข หากมีจำนวนครั้งสูง แสดงว่าการแก้ไขครั้งแรกอาจไม่ได้ผล.
แหล่งข้อมูล
โดยทั่วไปเป็นฟิลด์ตัวนับในออบเจ็กต์ Service Request ซึ่งกฎทางธุรกิจจะเพิ่มค่าเมื่อสถานะเปลี่ยนตามเงื่อนไข ฟิลด์นี้อาจใช้ชื่อว่า “ReopenCounter”.
ตัวอย่าง
0123
|
|||
|
จำนวนครั้งที่มอบหมายงาน
AssignmentCount
|
จำนวนครั้งทั้งหมดที่มีการมอบหมายหรือเปลี่ยนผู้รับผิดชอบคำขอบริการ. | ||
|
คำอธิบาย
เมตริกที่คำนวณนี้นับจำนวนกิจกรรมที่เกี่ยวข้องกับการมอบหมายงาน เช่น “มอบหมายให้ทีม” หรือ “มอบหมายให้เจ้าหน้าที่” ของคำขอบริการแต่ละรายการ การเปลี่ยนผู้รับผิดชอบหลายครั้ง ซึ่งมักเรียกว่า “ส่งตั๋วไปมา” บ่งชี้ว่าการกำหนดเส้นทางไม่มีประสิทธิภาพ แก้ไขปัญหาไม่ได้ตั้งแต่การติดต่อครั้งแรก หรือทีมมีหน้าที่รับผิดชอบไม่ชัดเจน แอตทริบิวต์นี้จำเป็นต่อการคำนวณ KPI “จำนวนครั้งเฉลี่ยที่เปลี่ยนผู้รับผิดชอบต่อคำขอ”.
เหตุผลที่สำคัญ
ใช้วัดการส่งต่องานและปัญหาการกำหนดเส้นทางที่ไม่มีประสิทธิภาพ หากมีจำนวนครั้งสูง มักบ่งชี้ว่าใช้เวลาแก้ไขนานและผู้ใช้ไม่พอใจ.
แหล่งข้อมูล
คำนวณระหว่างเตรียมข้อมูล โดยนับจำนวนครั้งที่เกิดกิจกรรมเกี่ยวกับการมอบหมายงานของ ServiceRequestID แต่ละรายการ.
ตัวอย่าง
12345
|
|||
|
ช่องทาง
Channel
|
วิธีหรือช่องทางที่ใช้ยื่นคำขอบริการ. | ||
|
คำอธิบาย
ช่องทางระบุวิธีสร้างคำขอบริการ เช่น ผ่านพอร์ทัลบริการตนเอง อีเมล โทรศัพท์ หรือสร้างโดยระบบอื่นโดยอัตโนมัติ การวิเคราะห์จำนวนคำขอและเวลาแก้ไขแยกตามช่องทางช่วยให้เห็นว่าช่องทางใดมีประสิทธิภาพ และช่องทางใดควรปรับปรุงกระบวนการหรือให้ความรู้แก่ผู้ใช้เพิ่มเติม.
เหตุผลที่สำคัญ
ช่วยให้เข้าใจพฤติกรรมผู้ใช้และประสิทธิภาพของแต่ละช่องทาง ซึ่งนำไปใช้ประกอบการตัดสินใจเรื่องแนวทางการให้บริการและโอกาสในการทำงานอัตโนมัติ.
แหล่งข้อมูล
ข้อมูลนี้มักจัดเก็บในฟิลด์ประเภท “Source” หรือ “CreatedBy” ของออบเจ็กต์ Service Request.
ตัวอย่าง
บริการตนเองอีเมลโทรศัพท์ป้อนข้อมูลโดยตรง
|
|||
|
ชื่อผู้ให้บริการภายนอก
VendorName
|
ชื่อผู้ให้บริการภายนอกที่มีส่วนช่วยแก้ไขคำขอ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้ให้บริการภายนอกที่เข้ามาช่วยหรือดำเนินการคำขอบริการให้เสร็จ เป็นข้อมูลสำคัญสำหรับแดชบอร์ด “ระยะเวลาการทำงานของผู้ให้บริการภายนอก” เพราะใช้วัดและเปรียบเทียบผลการดำเนินงานของผู้ให้บริการแต่ละราย การติดตามข้อมูลนี้ช่วยบริหารความสัมพันธ์กับผู้ให้บริการและระบุคอขวดที่เกิดจากการพึ่งพาบุคคลภายนอก.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลการดำเนินงานของผู้ให้บริการภายนอกและผลกระทบต่อเวลาแก้ไขคำขอบริการโดยรวม เพื่อสนับสนุนการบริหารผู้ให้บริการ.
แหล่งข้อมูล
ข้อมูลนี้อาจอยู่ในฟิลด์ของออบเจ็กต์งานที่เชื่อมโยงกับคำขอบริการ หรืออยู่ในฟิลด์เฉพาะของ Service Request หากมีการมอบหมายผู้ให้บริการ.
ตัวอย่าง
Dell SupportOracle ConsultingMicrosoft Premiernull
|
|||
|
แผนกของผู้ยื่นคำขอ
RequestorDepartment
|
แผนกธุรกิจของผู้ใช้ที่ยื่นคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแผนกของพนักงานหรือระบบที่เริ่มคำขอบริการ เช่น “ฝ่ายขาย” “ฝ่ายการเงิน” หรือ “ฝ่ายทรัพยากรบุคคล” ช่วยวิเคราะห์คุณภาพและความต้องการใช้บริการในส่วนต่างๆ ขององค์กร เช่น ตรวจสอบว่าแผนกใดใช้เวลาแก้ไขนานกว่า หรือยื่นคำขอจำนวนมากกว่าแผนกอื่น.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์การใช้บริการและคุณภาพบริการแยกตามหน่วยธุรกิจ เพื่อระบุปัญหาหรือแนวโน้มเฉพาะของแต่ละแผนก.
แหล่งข้อมูล
โดยทั่วไปดึงข้อมูลนี้จากโปรไฟล์ผู้ใช้ที่ยื่นคำขอ ซึ่งเชื่อมโยงกับ Service Request ฟิลด์อาจชื่อ “Department” ในออบเจ็กต์ Profile.Employee.
ตัวอย่าง
ฝ่ายการเงินฝ่ายขายฝ่ายการตลาดฝ่ายเทคโนโลยีสารสนเทศ
|
|||
|
มีการทำงานซ้ำหรือไม่
IsRework
|
ตัวบ่งชี้แบบบูลีนที่ระบุว่าคำขอบริการมีการทำงานซ้ำหรือไม่. | ||
|
คำอธิบาย
ตั้งค่าตัวบ่งชี้ที่คำนวณนี้เป็น true เมื่อพบสัญญาณว่ามีการทำงานซ้ำ เช่น เปิดคำขออีกครั้งหลังแก้ไขแล้ว หรือมีกิจกรรมบางอย่างเกิดซ้ำเป็นวงจร ช่วยให้คำนวณ KPI “อัตราการทำงานซ้ำของคำขอบริการ” ได้ง่ายขึ้น และกรองรายการกระบวนการที่ไม่มีประสิทธิภาพในแดชบอร์ด เช่น “การส่งต่องานและการมอบหมายงานซ้ำ”.
เหตุผลที่สำคัญ
ช่วยระบุและนับจำนวนคำขอที่ต้องใช้ความพยายามเพิ่มเติมโดยไม่ได้วางแผนไว้ได้ง่ายขึ้น ทำให้เห็นปัญหาด้านคุณภาพและประสิทธิภาพ.
แหล่งข้อมูล
คำนวณจากข้อมูล โดยอาจใช้เงื่อนไขว่าแอตทริบิวต์ “ReopenCount” มากกว่าศูนย์ หรือตรวจจับลำดับกิจกรรมเฉพาะ เช่น มีเหตุการณ์ “มอบหมายให้เจ้าหน้าที่” หลายครั้ง.
ตัวอย่าง
truefalse
|
|||
|
หมวดหมู่การแก้ไข
ResolutionCategory
|
การจัดประเภทวิธีแก้ไขคำขอบริการ. | ||
|
คำอธิบาย
หมวดหมู่การแก้ไขช่วยจัดประเภทวิธีที่ใช้แก้ไขคำขอบริการ โดยมักแบ่งเป็นลำดับชั้น เช่น หมวดหมู่และหมวดหมู่ย่อย เพื่อช่วยวิเคราะห์สาเหตุที่แท้จริงและรายงานแนวโน้ม ตัวอย่างเช่น ข้อมูลนี้อาจแสดงปัญหาที่เกิดซ้ำหรือวิธีดำเนินการตามคำขอที่พบบ่อย ซึ่งนำไปใช้ปรับปรุงบริการหรือจัดทำบทความฐานความรู้ได้.
เหตุผลที่สำคัญ
ช่วยให้เห็นลักษณะของการแก้ไขปัญหา ระบุปัญหาที่พบบ่อย โอกาสในการปรับปรุงบริการ และงานที่อาจทำให้เป็นอัตโนมัติได้.
แหล่งข้อมูล
มักจัดเก็บในฟิลด์การจัดหมวดหมู่ที่กรอกเมื่อแก้ไขเสร็จ เช่น “ResolutionCategory” หรือฟิลด์รหัสปิดงานที่กำหนดเอง.
ตัวอย่าง
ต้องฝึกอบรมผู้ใช้ติดตั้งซอฟต์แวร์แล้วซ่อมฮาร์ดแวร์แล้วให้สิทธิ์เข้าถึงแล้ว
|
|||
กิจกรรมในการจัดการคำขอบริการ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขคำขอบริการแล้ว
|
ถือว่าคำขอบริการได้รับการแก้ไขแล้ว และส่งมอบวิธีแก้ไขให้ผู้ใช้ กิจกรรมสำคัญนี้บันทึกจากการเปลี่ยนสถานะเป็น 'Resolved' ซึ่งมักทำให้นาฬิกา SLA หยุดทำงาน. | ||
|
เหตุผลที่สำคัญ
นี่คือจุดสิ้นสุดสำคัญสำหรับวัดเวลาปิดคำขอและการปฏิบัติตาม SLA ระยะเวลาตั้งแต่สร้างคำขอจนถึงกิจกรรมนี้เป็น KPI หลักสำหรับประเมินผลการดำเนินงานของกระบวนการ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ 'Status' ในระเบียน Service Request เป็น 'Resolved' พร้อมเวลาประทับที่เกี่ยวข้อง.
บันทึก
ตรวจพบการอัปเดตฟิลด์ 'Status' เป็น 'Resolved' จากประวัติการตรวจสอบ.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิดคำขอบริการแล้ว
|
ปิดคำขอบริการอย่างเป็นทางการและไม่สามารถดำเนินการเพิ่มเติมได้ โดยมักเกิดขึ้นโดยอัตโนมัติหลังจากอยู่ในสถานะ 'Resolved' ตามระยะเวลาที่กำหนด ถือเป็นจุดสิ้นสุดของวงจรคำขอ. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดที่ชัดเจนของกระบวนการ ระยะเวลาระหว่าง 'Resolved' กับ 'Closed' อาจช่วยให้เห็นความล่าช้าในการยืนยันผลหรือการทำงานอัตโนมัติของระบบ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ 'Status' ในระเบียน Service Request เป็น 'Closed' พร้อมเวลาประทับที่เกี่ยวข้อง.
บันทึก
ตรวจพบการอัปเดตฟิลด์ 'Status' เป็น 'Closed' จากประวัติการตรวจสอบ.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอให้เจ้าหน้าที่
|
เจ้าหน้าที่คนหนึ่งรับผิดชอบคำขอบริการ โดยทั่วไปอนุมานจากการกรอกหรืออัปเดตฟิลด์ 'Owner' ซึ่งระบุเจ้าหน้าที่ผู้รับผิดชอบเป็นครั้งแรก. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของเวลารอหรือเวลาที่คำขออยู่ในคิวช่วงแรก การวัดระยะเวลาก่อนถึงจุดนี้ช่วยค้นหาปัญหาการจัดสรรทรัพยากร และสนับสนุนแดชบอร์ด Agent Workload.
แหล่งข้อมูล
อนุมานจากการกรอกหรือเปลี่ยนฟิลด์ 'Owner' ในระเบียน Service Request ตามที่ปรากฏในประวัติการตรวจสอบ.
บันทึก
เวลาประทับแรกที่มีการกรอกชื่อเจ้าหน้าที่ในฟิลด์ 'Owner' หลังสร้างคำขอหรือมอบหมายให้ทีม.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอให้ทีม
|
มอบหมายคำขอบริการให้ทีมสนับสนุนที่รับผิดชอบ โดยตรวจดูว่ามีการกรอกหรือเปลี่ยนฟิลด์ 'OwnerTeam' ในระเบียน Service Request หรือไม่. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้สำคัญต่อการวิเคราะห์ผลการดำเนินงานและปริมาณงานของแต่ละทีม รวมถึงเวลาส่งต่องานระหว่างทีม และช่วยระบุทีมที่เป็นคอขวดในกระบวนการ.
แหล่งข้อมูล
ติดตามจากการเปลี่ยนแปลงฟิลด์ 'OwnerTeam' ในประวัติการตรวจสอบหรือบันทึกประจำวันของ Service Request.
บันทึก
เหตุการณ์อัปเดตฟิลด์ 'OwnerTeam' ซึ่งโดยทั่วไปจะบันทึกไว้ในประวัติการตรวจสอบ.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้างคำขอบริการแล้ว
|
กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรคำขอบริการ เมื่อมีการส่งคำขอใหม่อย่างเป็นทางการและบันทึกลงใน Ivanti ระบบจะบันทึกเหตุการณ์นี้เมื่อสร้างระเบียนใหม่ใน business object ของ Service Request และกำหนด Service Request ID ที่ไม่ซ้ำกัน. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ การวิเคราะห์เวลาตั้งแต่จุดนี้จนถึงการแก้ไขคำขอเป็นพื้นฐานสำคัญในการวัดระยะเวลาดำเนินการโดยรวมและประสิทธิภาพของกระบวนการ.
แหล่งข้อมูล
ข้อมูลนี้มาจากเวลาที่สร้างระเบียน Service Request เช่น ฟิลด์ CreatedDateTime ใน business object ของ ServiceReq.
บันทึก
เหตุการณ์สร้างระเบียนในตาราง ServiceReq ซึ่งระบุได้จากเวลาที่สร้าง.
ประเภทเหตุการณ์
explicit
|
|||
|
ขอข้อมูลเพิ่มเติมจากผู้ใช้
|
เจ้าหน้าที่ที่ได้รับมอบหมายต้องการข้อมูลเพิ่มเติมจากผู้ส่งคำขอเพื่อดำเนินการต่อ ระบบบันทึกเหตุการณ์นี้เมื่อเปลี่ยนสถานะคำขอเป็น 'Waiting for Customer' หรือสถานะลักษณะเดียวกัน. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ชี้ให้เห็นความล่าช้าที่เกิดจากข้อมูลเริ่มต้นไม่ครบ การติดตามความถี่และระยะเวลาของกิจกรรมนี้เป็นสิ่งสำคัญต่อการวิเคราะห์ผลกระทบจากการขอข้อมูลและค้นหาจุดที่ควรปรับปรุงกระบวนการ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะในระเบียน Service Request เป็นสถานะ เช่น 'Waiting for Customer' หรือ 'Pending'.
บันทึก
ตรวจพบการเปลี่ยนฟิลด์ 'Status' เป็นสถานะที่กำหนดไว้สำหรับการรอข้อมูลจากผู้ใช้.
ประเภทเหตุการณ์
inferred
|
|||
|
ดำเนินการตามคำขอบริการเสร็จแล้ว
|
เจ้าหน้าที่หรือระบบดำเนินงานทั้งหมดที่จำเป็นต่อการให้บริการตามคำขอเสร็จแล้ว ระบบบันทึกเหตุการณ์นี้เมื่อสถานะเปลี่ยนเป็น 'Fulfilled' ซึ่งมักเกิดก่อนสถานะสุดท้าย 'Resolved'. | ||
|
เหตุผลที่สำคัญ
หมุดหมายนี้แสดงว่างานด้านเทคนิคหรือขั้นตอนการดำเนินงานเสร็จสิ้น เป็นจุดสำคัญสำหรับวัดเวลาที่ใช้จัดการคำขอจริงก่อนยืนยันผลและปิดคำขอ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ 'Status' ในระเบียน Service Request เป็น 'Fulfilled'.
บันทึก
ตรวจพบการเปลี่ยนฟิลด์ 'Status' เป็น 'Fulfilled' จากประวัติของระเบียน.
ประเภทเหตุการณ์
inferred
|
|||
|
เปลี่ยนระดับความสำคัญ
|
มีการปรับระดับความสำคัญของคำขอบริการหลังจากสร้างคำขอครั้งแรก เหตุการณ์นี้ดึงจากบันทึกการตรวจสอบหรือประวัติที่ติดตามการเปลี่ยนแปลงระดับฟิลด์. | ||
|
เหตุผลที่สำคัญ
การติดตามการเปลี่ยนระดับความสำคัญเป็นสิ่งสำคัญต่อภาพรวมประสิทธิผลการจัดลำดับความสำคัญ ช่วยตรวจสอบว่าการยกระดับคำขอได้รับการจัดการอย่างเหมาะสมหรือไม่ และการจัดลำดับความสำคัญครั้งแรกถูกต้องหรือไม่.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกไว้อย่างชัดเจนในประวัติการตรวจสอบของระเบียน Service Request ซึ่งบันทึกการเปลี่ยนแปลงฟิลด์ 'Priority'.
บันทึก
เหตุการณ์อัปเดตฟิลด์ 'Priority' ที่บันทึกไว้ในประวัติการตรวจสอบของระบบ.
ประเภทเหตุการณ์
explicit
|
|||
|
เปิดคำขอบริการอีกครั้ง
|
เปิดคำขอบริการที่เคยแก้ไขแล้วกลับมาดำเนินการอีกครั้ง เนื่องจากปัญหายังคงอยู่หรือผู้ใช้ไม่พอใจกับวิธีแก้ไข ระบบบันทึกเหตุการณ์นี้เมื่อสถานะเปลี่ยนจาก 'Resolved' กลับไปเป็นสถานะที่ดำเนินการได้ เช่น 'Active' หรือ 'Assigned'. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้บ่งชี้โดยตรงว่ามีงานที่ต้องทำซ้ำและการแก้ไขครั้งแรกไม่มีคุณภาพ การวิเคราะห์เหตุการณ์เปิดคำขออีกครั้งช่วยค้นหาจุดอ่อนของกระบวนการและปรับปรุง KPI อัตราการทำงานซ้ำของคำขอบริการ.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบเมื่อฟิลด์ 'Status' เปลี่ยนจาก 'Resolved' หรือ 'Closed' เป็นสถานะที่ดำเนินการได้.
บันทึก
การเปลี่ยนสถานะจากสถานะสิ้นสุด ('Resolved', 'Closed') เป็นสถานะเปิด ('Active', 'Assigned').
ประเภทเหตุการณ์
inferred
|
|||
|
ผู้ใช้ให้ข้อมูลแล้ว
|
ผู้ส่งคำขอให้ข้อมูลที่จำเป็นแล้ว เจ้าหน้าที่จึงทำงานต่อได้ ระบบบันทึกเหตุการณ์นี้เมื่อคำขอเปลี่ยนจากสถานะ 'Waiting for Customer' กลับไปเป็นสถานะที่ดำเนินการได้. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้ปิดวงจรการขอข้อมูล เวลาตั้งแต่ขอข้อมูลจนได้รับข้อมูลเป็นส่วนสำคัญของความล่าช้าและวงจรการทำงานซ้ำในกระบวนการ.
แหล่งข้อมูล
อนุมานเมื่อฟิลด์ 'Status' ของ Service Request เปลี่ยนจากสถานะ 'Waiting for Customer' เป็นสถานะที่ดำเนินการได้ เช่น 'Active' หรือ 'In Progress'.
บันทึก
ตรวจพบการเปลี่ยนสถานะจากสถานะรอข้อมูลจากผู้ใช้เป็นสถานะที่ดำเนินการได้.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกเลิกคำขอบริการ
|
ผู้ใช้หรือเจ้าหน้าที่ยกเลิกคำขอบริการก่อนแก้ไขปัญหาเสร็จ นี่คือสถานะสิ้นสุดอีกแบบหนึ่ง ซึ่งบันทึกจากการเปลี่ยนสถานะเป็น 'Cancelled' หรือ 'Withdrawn'. | ||
|
เหตุผลที่สำคัญ
กรณีนี้เป็นการสิ้นสุดกระบวนการที่ไม่เป็นไปตามปกติ การวิเคราะห์สาเหตุที่ยกเลิกคำขออาจเผยให้เห็นปัญหาในขั้นตอนการส่งคำขอหรือความต้องการของผู้ใช้ที่เปลี่ยนไป.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ 'Status' ในระเบียน Service Request เป็น 'Cancelled'.
บันทึก
ตรวจพบการอัปเดตฟิลด์ 'Status' เป็น 'Cancelled' จากประวัติการตรวจสอบ.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งคำขอเพื่อขออนุมัติ
|
ส่งคำขอบริการเพื่อขออนุมัติที่จำเป็นก่อนดำเนินการให้บริการ โดยทั่วไปอนุมานได้จากการเปลี่ยนสถานะคำขอเป็น 'Submitted' หรือ 'Pending Approval' ซึ่งมักทำให้เวิร์กโฟลว์การอนุมัติเริ่มทำงาน. | ||
|
เหตุผลที่สำคัญ
การติดตามกิจกรรมนี้ช่วยค้นหาความล่าช้าในขั้นตอนอนุมัติ การรอนานในขั้นตอนนี้อาจเป็นคอขวดสำคัญที่กระทบเวลาปิดคำขอและความพึงพอใจของผู้ใช้.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะของระเบียน Service Request เช่น เป็น 'Submitted' หรือ 'Waiting for Approval' นอกจากนี้ยังดึงข้อมูลจาก business object ของ FRS_Approval หรือ FRS_ApprovalVoteTracking ได้.
บันทึก
การเปลี่ยนฟิลด์ 'Status' ในระเบียน Service Request เป็นสถานะรออนุมัติ.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งงานให้ผู้ให้บริการภายนอก
|
ส่งต่อการดำเนินการตามคำขอบริการให้ผู้ให้บริการภายนอกหรือบุคคลที่สาม โดยทั่วไปบันทึกจากการเปลี่ยนสถานะเป็น 'Waiting for 3rd Party' หรือสถานะลักษณะเดียวกัน. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้จำเป็นต่อการวัดประสิทธิภาพของผู้ให้บริการและผลกระทบต่อรอบเวลาดำเนินการโดยรวม ช่วยวิเคราะห์ความล่าช้าที่เกี่ยวข้องกับผู้ให้บริการ และใช้กับแดชบอร์ดระยะเวลากิจกรรมของผู้ให้บริการภายนอก.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะในระเบียน Service Request เป็นสถานะ เช่น 'Waiting for 3rd Party' หรือ 'Pending Vendor'.
บันทึก
ตรวจพบการเปลี่ยนฟิลด์ 'Status' เป็นสถานะที่กำหนดไว้สำหรับการรอผู้ให้บริการ.
ประเภทเหตุการณ์
inferred
|
|||
|
อนุมัติคำขอแล้ว
|
คำขอบริการได้รับการอนุมัติครบถ้วนและพร้อมดำเนินการ ระบบบันทึกเหตุการณ์นี้เมื่อเวิร์กโฟลว์การอนุมัติเสร็จสมบูรณ์และสถานะคำขอเปลี่ยนไป. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นหมุดหมายสำคัญที่แสดงว่าขั้นตอนอนุมัติสิ้นสุดและเริ่มดำเนินการให้บริการ จึงใช้วัดประสิทธิภาพของขั้นตอนอนุมัติได้.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะจาก 'Waiting for Approval' เป็น 'Approved' หรือ 'Fulfilled' หรืออาจเป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนใน business object ของ FRS_Approval.
บันทึก
การเปลี่ยนฟิลด์ 'Status' ในระเบียน Service Request จากสถานะรออนุมัติเป็นสถานะที่ดำเนินการต่อได้.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตข้อมูลฉบับละเอียดนี้เพื่อดึงศักยภาพของกระบวนการจัดการคำขอบริการออกมาให้เต็มที่ เริ่มปรับปรุงการปฏิบัติการของคุณได้วันนี้.
เริ่มปรับปรุงการจัดการคำขอบริการของคุณวันนี้
ลดความล่าช้าในการดำเนินการ ลดความไม่พอใจของผู้ใช้ และทำอัตราการทำงานอัตโนมัติให้ได้ 70%.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.