เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
- แอตทริบิวต์ที่แนะนำสำหรับการวิเคราะห์อย่างละเอียด
- กิจกรรมสำคัญที่ควรติดตามเพื่อค้นพบกระบวนการ
- แนวทางดึงข้อมูลจาก Jira Service Management
แอตทริบิวต์สำหรับการจัดการคำขอบริการ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้นในวงจรของคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุการดำเนินการหรือการเปลี่ยนสถานะที่เกิดขึ้นกับคำขอบริการ ณ เวลาหนึ่ง ตัวอย่างเช่น 'สร้างคำขอแล้ว' 'มอบหมายคำขอแล้ว' 'นำวิธีแก้ไขไปใช้แล้ว' และ 'ปิดคำขอแล้ว' การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining ช่วยให้เห็นแผนผังกระบวนการ ระบุคอขวด และตรวจจับความเบี่ยงเบนจากเวิร์กโฟลว์มาตรฐาน ซึ่งจำเป็นต่อการทำความเข้าใจประสิทธิภาพและการปฏิบัติตามข้อกำหนดของกระบวนการ.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้กำหนดขั้นตอนในกระบวนการ ช่วยให้เห็นแผนผังกระบวนการและวิเคราะห์รูปแบบกับความเบี่ยงเบนของเวิร์กโฟลว์ได้.
แหล่งข้อมูล
โดยทั่วไปได้มาจากประวัติการเปลี่ยนสถานะของรายการใน Jira โดยแต่ละรายการใน changelog ของช่องสถานะจะนับเป็นกิจกรรมหนึ่งรายการ.
ตัวอย่าง
คัดแยกคำขอแล้วขอข้อมูลเพิ่มเติมดำเนินการแก้ไขแล้วปิดคำขอบริการแล้ว
|
|||
|
รหัสคำขอบริการ
ServiceRequestId
|
รหัสเฉพาะของคำขอบริการแต่ละรายการ ใช้เป็นคีย์หลักสำหรับเหตุการณ์ทั้งหมดที่เกี่ยวข้อง. | ||
|
คำอธิบาย
รหัสคำขอบริการ ซึ่งใน Jira มักเรียกว่า Issue Key ใช้ระบุคำขอบริการแต่ละรายการที่ผู้ใช้หรือระบบส่งเข้ามาได้อย่างไม่ซ้ำกัน รหัสนี้เชื่อมโยงเหตุการณ์ทั้งหมดเข้าด้วยกัน ตั้งแต่การบันทึกคำขอครั้งแรกจนถึงการปิดคำขอ ทำให้วิเคราะห์เส้นทางของคำขอได้ตั้งแต่ต้นจนจบ ใน process mining รหัสนี้จำเป็นต่อการเชื่อมโยงเคส ช่วยให้กิจกรรม การเปลี่ยนสถานะ และเวลาประทับแต่ละรายการเชื่อมกับคำขอที่ถูกต้อง และรวมเป็นกระบวนการเดียวกันเพื่อใช้วิเคราะห์.
เหตุผลที่สำคัญ
รหัสนี้เป็นตัวระบุเคสหลักที่เชื่อมกิจกรรมที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการเดียวตั้งแต่ต้นจนจบ จึงสามารถวิเคราะห์กระบวนการได้.
แหล่งข้อมูล
นี่คือช่อง 'key' ของรายการใน Jira Service Management.
ตัวอย่าง
SR-2023-001IT-45892HELP-105
|
|||
|
เวลาเริ่มต้น
EventTime
|
วันที่และเวลาที่แน่นอนของกิจกรรมหรือเหตุการณ์หนึ่งๆ. | ||
|
คำอธิบาย
เวลาเริ่มต้นหรือเวลาประทับของเหตุการณ์จะบันทึกเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ ซึ่งเป็นข้อมูลสำคัญสำหรับการวิเคราะห์ process mining เพราะช่วยระบุช่วงเวลาที่เหตุการณ์ต่างๆ เกิดขึ้นในกระบวนการ ระบบใช้เวลาประทับนี้เรียงลำดับเหตุการณ์ คำนวณระยะเวลาระหว่างกิจกรรมและเวลารอบของแต่ละเคส รวมถึงวัดผลกระบวนการเทียบกับเป้าหมายด้านเวลา เช่น SLA หากไม่มีเวลาประทับที่ถูกต้อง ก็จะไม่สามารถทำความเข้าใจลำดับการทำงาน ระบุความล่าช้า หรือวัดประสิทธิภาพได้.
เหตุผลที่สำคัญ
เวลาประทับนี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลาและเวลารอบของกระบวนการ รวมถึงระบุคอขวด.
แหล่งข้อมูล
นี่คือเวลาประทับที่บันทึกไว้กับการเปลี่ยนสถานะแต่ละครั้งใน changelog ของรายการ Jira ส่วนเวลาที่สร้างรายการอยู่ในช่อง 'created'.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ใช้ดึงข้อมูลคำขอบริการออกมา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูล ซึ่งในกรณีนี้คือ Jira Service Management แม้จะดูไม่สำคัญเมื่อวิเคราะห์ข้อมูลจากแหล่งเดียว แต่จะมีความสำคัญมากเมื่อนำข้อมูลกระบวนการจากหลายระบบมารวมกัน การวิเคราะห์ใช้ข้อมูลนี้เพื่อติดตามที่มาของข้อมูลและตรวจสอบคุณภาพ อีกทั้งยังช่วยกรองและเปรียบเทียบกระบวนการที่เกี่ยวข้องกับซอฟต์แวร์หลายระบบได้.
เหตุผลที่สำคัญ
ระบุแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลข้อมูลและการรวมข้อมูลกระบวนการจากระบบต่างๆ ในองค์กร.
แหล่งข้อมูล
โดยทั่วไปจะเป็นค่าคงที่ที่เพิ่มระหว่างการดึงและแปลงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล.
ตัวอย่าง
Jira Service ManagementJiraSM
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่ามีการรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลจาก Jira Service Management ล่าสุด ช่วยให้ทราบว่าข้อมูลที่ใช้วิเคราะห์ รวมถึงข้อมูลในแดชบอร์ดและ KPI เป็นข้อมูลใหม่เพียงใด การทราบว่าข้อมูลเป็นปัจจุบันแค่ไหนเป็นสิ่งสำคัญต่อการตัดสินใจอย่างมีข้อมูล เวลาประทับนี้ช่วยให้ผู้ใช้ทราบว่ากำลังดูข้อมูลล่าสุดหรือข้อมูล ณ ช่วงเวลาก่อนหน้า ซึ่งมีผลต่อความเกี่ยวข้องของข้อค้นพบ.
เหตุผลที่สำคัญ
ระบุความใหม่ของข้อมูล เพื่อให้มั่นใจว่าการวิเคราะห์อ้างอิงข้อมูลล่าสุด.
แหล่งข้อมูล
นี่คือช่องเมทาดาทาที่เครื่องมือหรือสคริปต์ดึงข้อมูลสร้างและบันทึกเมื่อทำงานเสร็จ.
ตัวอย่าง
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
ประเภทคำขอ
RequestType
|
การจัดประเภทคำขอบริการ เช่น 'คำขอสิทธิ์เข้าถึง' หรือ 'ปัญหาเกี่ยวกับฮาร์ดแวร์'. | ||
|
คำอธิบาย
ประเภทคำขอใช้จัดหมวดหมู่คำขอบริการตามลักษณะของงาน ซึ่งเป็นมิติพื้นฐานในการวิเคราะห์ เพราะคำขอแต่ละประเภทมักมีขั้นตอนแก้ไข SLA และความต้องการด้านทรัพยากรต่างกัน เมื่อแบ่งผลการวิเคราะห์กระบวนการตามประเภทคำขอ องค์กรจะปรับปรุงเวิร์กโฟลว์ให้เหมาะกับงานแต่ละประเภทได้ เช่น คอขวดของคำขอ 'รีเซ็ตรหัสผ่าน' ย่อมต่างจากคำขอ 'จัดเตรียมเซิร์ฟเวอร์ใหม่' แอตทริบิวต์นี้ยังช่วยสร้างแดชบอร์ดที่ตรงกับการใช้งาน เช่น 'คุณภาพการแก้ไขตามหมวดหมู่'.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้จำเป็นต่อการเปรียบเทียบกระบวนการ ภาระงาน และผลการดำเนินงานระหว่างคำขอบริการแต่ละประเภท.
แหล่งข้อมูล
โดยทั่วไปตรงกับช่อง 'issuetype' ใน Jira หรือช่อง 'Request Type' ที่กำหนดเองใน Jira Service Management.
ตัวอย่าง
ขอเปิดบัญชีใหม่ขอความช่วยเหลือด้านไอทีเริ่มงานให้พนักงานใหม่
|
|||
|
ผู้รับผิดชอบ
Assignee
|
ผู้ใช้หรือเจ้าหน้าที่ที่ได้รับมอบหมายให้ดำเนินการกับคำขอบริการในขณะนั้น. | ||
|
คำอธิบาย
ผู้รับผิดชอบคือบุคคลที่ต้องดำเนินการขั้นถัดไปหรือแก้ไขคำขอบริการ แอตทริบิวต์นี้อาจเปลี่ยนแปลงหลายครั้งตลอดวงจรของคำขอ เมื่อมีการส่งต่องานระหว่างเจ้าหน้าที่หรือทีม แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ภาระงาน การวัดผลการทำงาน และการจัดการทรัพยากร คุณสามารถกรองกระบวนการตามเจ้าหน้าที่ เปรียบเทียบเวลาแก้ไขของแต่ละคน และระบุความจำเป็นในการฝึกอบรมหรือภาระงานที่ไม่สมดุลซึ่งอาจทำให้เกิดคอขวดได้.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ภาระงานของเจ้าหน้าที่ วัดผลการทำงานรายบุคคล และทำความเข้าใจการจัดสรรทรัพยากร.
แหล่งข้อมูล
ตรงกับช่อง 'assignee' ในรายการ Jira.
ตัวอย่าง
Alice JohnsonBob Williamsยังไม่ได้มอบหมาย
|
|||
|
ลำดับความสำคัญของคำขอ
RequestPriority
|
ระดับความสำคัญของคำขอบริการ เช่น ต่ำ ปานกลาง สูง หรือวิกฤต. | ||
|
คำอธิบาย
ลำดับความสำคัญของคำขอแสดงระดับความเร่งด่วนและผลกระทบต่อธุรกิจ การจัดประเภทนี้ใช้กำหนดลำดับการจัดการคำขอ และมักเป็นตัวกำหนดเวลาเป้าหมายในการแก้ไขกับ SLA ในการวิเคราะห์กระบวนการ ลำดับความสำคัญเป็นมิติสำคัญสำหรับแบ่งกลุ่มข้อมูล ช่วยเปรียบเทียบเวลารอบและการปฏิบัติตาม SLA ในแต่ละระดับ เพื่อดูว่าคำขอที่มีความสำคัญสูงได้รับการจัดการเร็วขึ้นและเป็นไปตามเป้าหมายหรือไม่ อีกทั้งยังช่วยตรวจสอบว่าระบบจัดลำดับความสำคัญทำงานได้ผลเพียงใด.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มการวิเคราะห์เพื่อให้แน่ใจว่าคำขอที่มีความสำคัญสูงได้รับการจัดการเร็วขึ้นและเป็นไปตามระดับการให้บริการที่เข้มงวดกว่า.
แหล่งข้อมูล
ตรงกับช่อง 'priority' ในรายการ Jira.
ตัวอย่าง
สูงสุดสูงปานกลางต่ำ
|
|||
|
วันครบกำหนด SLA
SlaDueDate
|
วันที่และเวลาเป้าหมายที่ควรแก้ไขคำขอบริการให้เสร็จตาม SLA. | ||
|
คำอธิบาย
วันครบกำหนด SLA คือเวลาประทับที่คำนวณขึ้นเพื่อระบุเส้นตายในการแก้ไขคำขอ โดยพิจารณาจากลำดับความสำคัญ ประเภทคำขอ และนโยบาย Service Level Agreement (SLA) ที่ตั้งค่าไว้ใน Jira Service Management แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานของแดชบอร์ด 'ผลการดำเนินงาน SLA ของคำขอบริการ' และ KPI 'อัตราการปฏิบัติตาม SLA' เมื่อนำเวลาแก้ไขจริงมาเปรียบเทียบกับวันครบกำหนด ระบบจะระบุได้ว่าคำขอเสร็จตามเวลา ล่าช้า หรือมีความเสี่ยงที่จะผิด SLA.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์วัดผลการดำเนินงานโดยตรง ช่วยคำนวณการปฏิบัติตาม SLA และจัดลำดับความสำคัญของงาน.
แหล่งข้อมูล
Jira Service Management จัดการข้อมูล SLA และเปิดให้เข้าถึงผ่าน API โดยข้อมูลมักจัดเก็บในช่องที่กำหนดเองและอัปเดตแบบไดนามิก.
ตัวอย่าง
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
|
|||
|
สถานะคำขอ
RequestStatus
|
สถานะปัจจุบันของคำขอบริการในวงจรการดำเนินงาน. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงสถานะปัจจุบันของคำขอบริการ เช่น 'Open' 'In Progress' 'Waiting for Customer' หรือ 'Resolved' จึงช่วยให้เห็นว่าคำขออยู่ในขั้นตอนไหน ณ เวลานั้น บันทึกกิจกรรมแสดงลำดับเหตุการณ์ที่ผ่านมา ส่วนสถานะปัจจุบันช่วยวิเคราะห์งานที่กำลังดำเนินการและระบุรายการที่หยุดชะงักได้ เช่น คำขอที่อยู่ในสถานะ 'Waiting for Vendor' นานผิดปกติ ซึ่งอาจชี้ให้เห็นถึงการพึ่งพาบุคคลภายนอกหรือความล่าช้า.
เหตุผลที่สำคัญ
แสดงสถานะปัจจุบันของแต่ละเคส ช่วยวิเคราะห์งานที่กำลังดำเนินการและระบุคำขอที่หยุดชะงักหรือค้างมานาน.
แหล่งข้อมูล
นี่คือช่อง 'status' ในรายการ Jira.
ตัวอย่าง
เปิดกำลังดำเนินการรอลูกค้าแก้ไขแล้ว
|
|||
|
ช่องทาง
Channel
|
วิธีที่ใช้ส่งคำขอบริการ เช่น อีเมล พอร์ทัล หรือ API. | ||
|
คำอธิบาย
แอตทริบิวต์ช่องทางระบุว่าคำขอบริการเข้าสู่ระบบด้วยวิธีใด ช่องทางที่ใช้บ่อยใน Jira Service Management ได้แก่ พอร์ทัลลูกค้า อีเมล หรือการสร้างรายการโดยเจ้าหน้าที่โดยตรง การวิเคราะห์กระบวนการตามช่องทางช่วยให้เข้าใจพฤติกรรมผู้ใช้และปรับปรุงการให้บริการ คุณอาจพบว่าคำขอจากบางช่องทางใช้เวลาแก้ไขนานกว่า หรือต้องขอข้อมูลเพิ่มเติม ซึ่งอาจบ่งชี้ว่าควรปรับแบบฟอร์มในพอร์ทัลหรือปรับกฎแยกวิเคราะห์อีเมล ข้อมูลนี้ใช้ประกอบแดชบอร์ด 'แนวโน้มปริมาณคำขอบริการ' ได้.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ว่าช่องทางส่งคำขอมีผลต่อเวลาแก้ไข ความชัดเจนของคำขอ หรือประสิทธิภาพโดยรวมของกระบวนการหรือไม่.
แหล่งข้อมูล
ข้อมูลนี้ดูได้จากช่อง 'Request channel type' ใน Jira Service Management แต่อาจต้องใช้สิทธิ์เข้าถึง API เฉพาะ หรือจัดเก็บไว้ในช่องที่กำหนดเอง.
ตัวอย่าง
พอร์ทัลอีเมลapi
|
|||
|
ทีมที่ได้รับมอบหมาย
AssignedTeam
|
ทีมที่รับผิดชอบจัดการคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุทีมที่ได้รับมอบหมายให้จัดการคำขอ ซึ่งมักเป็นกลุ่มระดับใหญ่กว่าผู้รับผิดชอบรายบุคคล จึงใช้วิเคราะห์ผลการดำเนินงานระดับทีมได้ เช่น เปรียบเทียบทีมสนับสนุนระดับแรกกับทีมปฏิบัติการเครือข่าย มิตินี้สำคัญต่อแดชบอร์ด เช่น 'ภาระงานเจ้าหน้าที่และตัวชี้วัดการแก้ไข' โดยช่วยรวมตัวชี้วัดผลการดำเนินงานในระดับทีม เพื่อให้เปรียบเทียบได้อย่างเป็นธรรมและเข้าใจว่าทีมต่างๆ มีส่วนช่วยในกระบวนการให้บริการโดยรวมอย่างไร.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลการดำเนินงานและปรับสมดุลภาระงานในระดับทีมหรือแผนก แทนที่จะดูเฉพาะเจ้าหน้าที่รายบุคคล.
แหล่งข้อมูล
อาจเป็นช่องที่กำหนดเองใน Jira เช่น 'Team' หรืออนุมานจากข้อมูลโปรไฟล์ผู้ใช้ของผู้รับผิดชอบ.
ตัวอย่าง
ฝ่ายสนับสนุนไอที ระดับ 1ทีมโครงสร้างพื้นฐานฝ่ายสนับสนุนแอปพลิเคชัน
|
|||
|
ผลการแก้ไข
Resolution
|
ผลลัพธ์หรือข้อสรุปสุดท้ายของคำขอบริการที่แก้ไขแล้ว. | ||
|
คำอธิบาย
ช่องผลการแก้ไขระบุเหตุผลที่ปิดคำขอบริการ ค่าที่พบบ่อย ได้แก่ 'Done' 'Won't Do' 'Duplicate' หรือ 'Cannot Reproduce' ซึ่งให้รายละเอียดการปิดงานมากกว่าสถานะ 'Resolved' หรือ 'Closed' เพียงอย่างเดียว การวิเคราะห์ผลการแก้ไขช่วยให้เข้าใจคุณภาพและลักษณะของผลลัพธ์ เช่น หากมีคำขอที่ปิดเป็น 'Duplicate' จำนวนมาก อาจสะท้อนปัญหาในขั้นตอนส่งคำขอ ส่วนการติดตามผลการแก้ไขที่ทำให้ต้องเปิดคำขออีกครั้งจะช่วยระบุวิธีแก้ไขที่ยังไม่ได้ผล.
เหตุผลที่สำคัญ
ให้ข้อมูลประกอบเกี่ยวกับผลลัพธ์ของคำขอ ช่วยวิเคราะห์คุณภาพการแก้ไขและหาแนวโน้มของเหตุผลที่ปิดคำขอ.
แหล่งข้อมูล
ตรงกับช่อง 'resolution' ในรายการ Jira ซึ่งโดยทั่วไปจะกำหนดเมื่อรายการเปลี่ยนไปอยู่ในหมวดสถานะ 'done'.
ตัวอย่าง
เสร็จแล้วไม่ดำเนินการรายการซ้ำแก้ไขแล้ว
|
|||
|
ผู้แจ้ง
Reporter
|
ผู้ใช้ที่สร้างหรือแจ้งคำขอบริการในตอนแรก. | ||
|
คำอธิบาย
ผู้แจ้งคือบุคคลที่ส่งคำขอบริการเข้ามา ซึ่งมักเป็นผู้ใช้ปลายทางหรือลูกค้า แอตทริบิวต์นี้ระบุผู้มีส่วนเกี่ยวข้องที่เริ่มต้นกระบวนการ คุณสามารถใช้ข้อมูลผู้แจ้งเพื่อทำความเข้าใจรูปแบบคำขอจากผู้ใช้ แผนก หรือกลุ่มลูกค้าต่างๆ เช่น แผนกใดส่งคำขอมากที่สุด หรือมีผู้ใช้รายใดพบปัญหาเดิมซ้ำๆ หรือไม่ ข้อมูลนี้ช่วยให้จัดการปัญหาเชิงรุกและปรับปรุงการฝึกอบรมผู้ใช้ได้.
เหตุผลที่สำคัญ
ระบุผู้เริ่มส่งคำขอ ช่วยวิเคราะห์จำนวนและประเภทคำขอตามผู้ใช้ แผนก หรือลูกค้า.
แหล่งข้อมูล
ตรงกับช่อง 'reporter' ในรายการ Jira.
ตัวอย่าง
Charles DarwinMarie CurieIsaac Newton
|
|||
|
มีการเปิดคำขออีกครั้งหรือไม่
IsReopened
|
ค่าสถานะแบบบูลีนที่ระบุว่ามีการเปิดคำขอบริการอีกครั้งหลังจากแก้ไขแล้วหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณนี้มีค่าเป็นจริงหรือเท็จ โดยกำหนดเป็นจริงเมื่อเวิร์กโฟลว์ของคำขอมีเหตุการณ์ 'เปิดคำขออีกครั้ง' ระบบคำนวณจากการวิเคราะห์ลำดับกิจกรรมของแต่ละเคส ค่านี้จำเป็นต่อการคำนวณ KPI 'อัตราการเปิดคำขอบริการอีกครั้ง' และแสดงข้อมูลในแดชบอร์ด 'ปริมาณคำขอบริการที่เปิดอีกครั้ง' หากอัตราการเปิดซ้ำสูง อาจบ่งชี้ว่าการแก้ไขครั้งแรกยังไม่มีคุณภาพ ทำให้ต้องทำงานซ้ำและลูกค้าพึงพอใจน้อยลง การวิเคราะห์ประเภทคำขอหรือผลการแก้ไขที่เกี่ยวข้องกับค่านี้ช่วยระบุจุดที่ควรปรับปรุงได้.
เหตุผลที่สำคัญ
วัดการทำงานซ้ำและคุณภาพการแก้ไขตั้งแต่ครั้งแรกโดยตรง ซึ่งเป็นตัวชี้วัดสำคัญของประสิทธิผลกระบวนการและความพึงพอใจของลูกค้า.
แหล่งข้อมูล
คำนวณระหว่างการแปลงข้อมูล โดยตรวจสอบว่าลำดับกิจกรรมของเคสมีการเปลี่ยนสถานะเป็น 'Reopened' หลังจากเปลี่ยนเป็น 'Resolved' หรือไม่.
ตัวอย่าง
truefalse
|
|||
|
สถานะ SLA
SlaState
|
ระบุว่าคำขอบริการเป็นไปตาม SLA ผิด SLA หรือยังอยู่ภายในเวลาที่กำหนดหรือไม่. | ||
|
คำอธิบาย
สถานะ SLA เป็นแอตทริบิวต์ที่คำนวณขึ้นเพื่อจัดประเภทคำขอบริการแต่ละรายการตามผลการดำเนินงานเทียบกับกำหนดเวลา SLA ค่าที่เป็นไปได้ ได้แก่ 'เป็นไปตามกำหนด' 'ผิด SLA' หรือ 'กำลังดำเนินการ' โดยพิจารณาจากเวลาที่แก้ไขคำขอเทียบกับ 'SlaDueDate' แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ด 'ผลการดำเนินงาน SLA ของคำขอบริการ' และใช้คำนวณ KPI 'อัตราการปฏิบัติตาม SLA' ช่วยให้เห็นผลการปฏิบัติตามระดับการให้บริการได้อย่างรวดเร็ว ซึ่งสำคัญต่อการรายงาน การจัดการสัญญา และการรักษาคุณภาพบริการ.
เหตุผลที่สำคัญ
แสดงผลการดำเนินงานตาม SLA ได้อย่างชัดเจนและรวดเร็ว ซึ่งเป็นตัวชี้วัดสำคัญของคุณภาพบริการและการปฏิบัติตามสัญญา.
แหล่งข้อมูล
คำนวณระหว่างการแปลงข้อมูล หากเวลาแก้ไขอยู่ก่อน 'SlaDueDate' สถานะจะเป็น 'เป็นไปตามกำหนด' มิฉะนั้นจะเป็น 'ผิด SLA'.
ตัวอย่าง
เป็นไปตามกำหนดผิด SLAกำลังดำเนินการ
|
|||
|
องค์กร
Organization
|
องค์กรของลูกค้าหรือแผนกภายในที่ผู้แจ้งสังกัดอยู่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้จัดกลุ่มผู้แจ้งตามองค์กรหรือแผนก Jira Service Management มีฟีเจอร์ 'Organizations' ในตัว ซึ่งช่วยให้เจ้าหน้าที่จัดการคำขอจากลูกค้าหลายรายหรือทีมภายในได้ การวิเคราะห์ตามองค์กรช่วยให้เห็นบริบททางธุรกิจ เช่น ลูกค้าหรือแผนกใดใช้ทรัพยากรสนับสนุนมากที่สุด กลุ่มใดพบปัญหาเดิมซ้ำๆ และองค์กรทำได้ตาม SLA อย่างสม่ำเสมอหรือไม่ในแต่ละหน่วยธุรกิจ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ความต้องการใช้บริการและผลการดำเนินงานแยกตามลูกค้าหรือแผนกภายใน พร้อมให้ข้อมูลเชิงธุรกิจที่สำคัญ.
แหล่งข้อมูล
ข้อมูลนี้มาจากช่อง 'Organizations' ที่เชื่อมโยงกับคำขอบริการใน Jira Service Management.
ตัวอย่าง
Acme CorporationแผนกการเงินGlobal Tech Inc.
|
|||
กิจกรรมในการจัดการคำขอบริการ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขคำขอบริการแล้ว
|
ระบุเวลาที่ถือว่าดำเนินการตามคำขอเสร็จสิ้นอย่างเป็นทางการและบันทึกวิธีแก้ไขแล้ว Jira จะกรอกข้อมูลในช่อง 'Resolution Date' เมื่อรายการเข้าสู่สถานะในหมวด 'Done' เป็นครั้งแรก. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสิ้นสุดหลักของกระบวนการ ซึ่งสำคัญต่อการคำนวณระยะเวลาแก้ไขและการปฏิบัติตาม SLA และเป็นจุดสิ้นสุดของการทำงานที่กำลังดำเนินอยู่.
แหล่งข้อมูล
เหตุการณ์นี้ระบุเวลาไว้อย่างชัดเจน โดยใช้ค่าจากช่อง 'Resolution Date' ของรายการใน Jira ซึ่งกำหนดเมื่อรายการเปลี่ยนสถานะเข้าสู่หมวด 'Done' เป็นครั้งแรก.
บันทึก
ใช้ช่อง 'resolutiondate' จากรายการใน Jira ซึ่งระบบจะกรอกข้อมูลให้อัตโนมัติ.
ประเภทเหตุการณ์
explicit
|
|||
|
ปิดคำขอบริการแล้ว
|
หมายถึงการปิดคำขอบริการขั้นสุดท้ายในเชิงธุรการ ซึ่งมักเกิดขึ้นโดยอัตโนมัติหลังจากอยู่ในสถานะ 'Resolved' ตามระยะเวลาที่กำหนด นี่คือจุดสิ้นสุดวงจรของรายการใน Jira. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์สิ้นสุดที่ชัดเจนของกระบวนการ คุณสามารถวิเคราะห์ช่วงเวลาระหว่าง 'Resolved' กับ 'Closed' เพื่อดูภาระงานด้านธุรการหรือนโยบายปิดรายการอัตโนมัติ.
แหล่งข้อมูล
อนุมานจากประวัติของรายการ โดยใช้เวลาที่สถานะเปลี่ยนเป็น 'Closed' หรือสถานะสิ้นสุดอื่นที่เทียบเท่ากันเป็นเวลาอ้างอิง.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'Closed' เป็นครั้งสุดท้าย.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอแล้ว
|
กิจกรรมนี้เกิดขึ้นเมื่อมอบหมายคำขอบริการให้เจ้าหน้าที่หรือทีมที่รับผิดชอบแก้ไข Jira บันทึกการเปลี่ยนแปลงฟิลด์ 'Assignee' โดยตรง จึงระบุเวลาที่มอบหมายงานได้ชัดเจน. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้ใช้วัดเวลาตั้งแต่คัดแยกจนถึงมอบหมายงาน และการกระจายภาระงานของเจ้าหน้าที่ อีกทั้งยังเป็นจุดเปลี่ยนจากการรอคิวไปสู่การดำเนินงาน.
แหล่งข้อมูล
ดูจากประวัติรายการ โดยหาเหตุการณ์แรกที่กำหนดหรือเปลี่ยนฟิลด์ 'Assignee' จากสถานะที่ยังไม่มีผู้รับผิดชอบ.
บันทึก
ใช้เวลาที่มีการเปลี่ยนฟิลด์ 'Assignee' ครั้งแรกในประวัติรายการ.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้างคำขอบริการแล้ว
|
กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรคำขอบริการ เมื่อผู้ใช้ส่งคำขอผ่านพอร์ทัล อีเมล หรือช่องทางอื่น Jira บันทึกเหตุการณ์นี้โดยตรงเมื่อมีการสร้างรายการใหม่ประเภท 'Service Request' พร้อมบันทึกเวลาที่สร้าง. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ ซึ่งจำเป็นต่อการคำนวณเวลาตั้งแต่เริ่มจนจบโดยรวม และทำความเข้าใจปริมาณกับรูปแบบการเข้ามาของคำขอ.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกไว้อย่างชัดเจนในตารางประวัติของรายการ เวลาของกิจกรรมใช้ค่าจากฟิลด์ 'created' ในรายการ Jira.
บันทึก
ใช้เวลาที่สร้างรายการจากตาราง 'issues' หรือประวัติรายการ.
ประเภทเหตุการณ์
explicit
|
|||
|
เสนอแนวทางแก้ไขแล้ว
|
ในเวิร์กโฟลว์ของทีมบริการหลายแห่ง ขั้นตอนนี้แยกต่างหากเพื่อเสนอแนวทางแก้ไขให้ผู้ส่งคำขออนุมัติ อนุมานได้เมื่อสถานะรายการเปลี่ยนเป็น 'Pending Customer Acceptance' หรือ 'Awaiting Confirmation'. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้แยกเวลาที่ใช้รอความคิดเห็นจากลูกค้าหลังเสนอแนวทางแก้ไขแล้วออกจากเวลาทำงานภายใน.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนเป็นสถานะซึ่งแสดงว่ากำลังรอให้ลูกค้าตรวจสอบแนวทางแก้ไข.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'Pending Customer Acceptance' หรือสถานะที่มีความหมายเทียบเท่ากัน.
ประเภทเหตุการณ์
inferred
|
|||
|
ขอข้อมูลเพิ่มเติม
|
ระบุจุดที่เจ้าหน้าที่ต้องขอข้อมูลเพิ่มเติมจากผู้ส่งคำขอเพื่อดำเนินการแก้ไข โดยทั่วไปอนุมานจากการเปลี่ยนสถานะของรายการเป็น 'Waiting for customer' หรือ 'Pending Input'. | ||
|
เหตุผลที่สำคัญ
การขอข้อมูล 'Information Requested' บ่อยครั้งหรือใช้เวลานานอาจบ่งชี้ว่าข้อมูลที่ส่งมาตอนแรกไม่ชัดเจน หรือการสื่อสารไม่มีประสิทธิภาพ ซึ่งเป็นสาเหตุสำคัญของความล่าช้า.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนเป็น 'Waiting for customer' หรือสถานะที่มีความหมายเทียบเท่ากัน.
บันทึก
ระบุเวลาที่ฟิลด์ 'status' เปลี่ยนเป็นค่าที่แสดงว่ากระบวนการกำลังรอข้อมูลจากลูกค้า.
ประเภทเหตุการณ์
inferred
|
|||
|
คัดแยกคำขอแล้ว
|
หมายถึงการประเมินคำขอบริการเบื้องต้น เพื่อกำหนดระดับความสำคัญ หมวดหมู่ และผลกระทบ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะ เช่น จาก 'New' เป็น 'In Progress' หรือเปลี่ยนเป็นสถานะ 'Triaged' โดยเฉพาะ. | ||
|
เหตุผลที่สำคัญ
การวิเคราะห์เวลาที่ใช้คัดแยกช่วยประเมินประสิทธิภาพของการจัดการคำขอในช่วงแรก หากล่าช้าอาจส่งผลอย่างมากต่อเวลาแก้ไขโดยรวมและการปฏิบัติตาม SLA.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยระบุเวลาครั้งแรกที่สถานะเปลี่ยนจาก 'New' หรือ 'Open' ไปเป็นสถานะที่กำลังดำเนินการ เช่น 'In Progress'.
บันทึก
ระบุการเปลี่ยนสถานะครั้งแรกจาก 'New' หรือสถานะเริ่มต้นที่เทียบเท่ากัน โดยอิงตามเวิร์กโฟลว์ของโปรเจกต์.
ประเภทเหตุการณ์
inferred
|
|||
|
ดำเนินการแก้ไขแล้ว
|
หมายถึงเจ้าหน้าที่ดำเนินการตามที่จำเป็นหรือจัดทำแนวทางแก้ไขคำขอบริการ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะเป็น 'Pending Review' หรือ 'Resolved' โดยตรง. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้หมายถึงงานหลักในการแก้ไขเสร็จสิ้น เวลาก่อนถึงกิจกรรมนี้มักเป็นช่วงที่สร้างคุณค่าหลักของกระบวนการ.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนเป็น 'Resolved', 'Pending Acceptance' หรือสถานะก่อนปิดงานที่มีความหมายใกล้เคียงกัน.
บันทึก
ระบุเวลาที่ฟิลด์ 'status' เปลี่ยนเป็นค่าที่แสดงว่างานเสร็จแล้ว.
ประเภทเหตุการณ์
inferred
|
|||
|
ได้รับข้อมูลแล้ว
|
เกิดขึ้นเมื่อผู้ส่งคำขอตอบกลับพร้อมข้อมูลที่จำเป็น ทำให้เจ้าหน้าที่ดำเนินงานต่อได้ อนุมานได้เมื่อรายการเปลี่ยนออกจากสถานะ 'Waiting for customer' ซึ่งมักเกิดหลังผู้ส่งคำขอเพิ่มความคิดเห็น. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ปิดวงจรการขอและตอบกลับข้อมูลกับลูกค้า เวลาระหว่างการขอข้อมูลกับการได้รับข้อมูลเป็นส่วนสำคัญของเวลารอในกระบวนการ.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนจาก 'Waiting for customer' กลับเป็น 'In Progress'.
บันทึก
ระบุเวลาที่ฟิลด์ 'status' เปลี่ยนจากสถานะ 'waiting' กลับเป็นสถานะ 'active'.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิดคำขออีกครั้ง
|
กิจกรรมนี้บันทึกกรณีที่คำขอบริการซึ่งแก้ไขแล้วกลับมาอยู่ในสถานะที่กำลังดำเนินการ อนุมานได้จากการเปลี่ยนสถานะจาก 'Resolved' หรือ 'Closed' กลับเป็น 'Open' หรือ 'In Progress'. | ||
|
เหตุผลที่สำคัญ
การติดตามคำขอที่เปิดใหม่เป็นเรื่องสำคัญต่อการวัดคุณภาพการแก้ไขและอัตราการแก้ไขสำเร็จตั้งแต่ครั้งแรก หากมีการเปิดใหม่บ่อย แสดงว่าแนวทางแก้ไขไม่ได้ผลหรือปัญหาเกิดซ้ำ.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยระบุการเปลี่ยนสถานะจากหมวด 'Resolved' หรือ 'Closed' ไปเป็นหมวด 'Open' หรือ 'In Progress'.
บันทึก
ตรวจหาการเปลี่ยนสถานะจากหมวด 'Done' ไปเป็นหมวด 'To Do' หรือ 'In Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
ยืนยันการแก้ไขแล้ว
|
เกิดขึ้นเมื่อผู้ส่งคำขอยอมรับแนวทางแก้ไขอย่างเป็นทางการ ซึ่งมักทำให้ระบบเปลี่ยนสถานะเป็น 'Resolved' โดยอัตโนมัติ โดยทั่วไปอนุมานเหตุการณ์นี้จากการเปลี่ยนสถานะดังกล่าว. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้ยืนยันว่าแนวทางแก้ไขได้ผล และเป็นจุดที่หยุดนับเวลา SLA ช่วยวัดเวลาที่ลูกค้าใช้ยืนยันการแก้ไข.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนจาก 'Pending Customer Acceptance' เป็น 'Resolved' หรือ 'Closed'.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนจาก 'Pending Customer Acceptance' เป็น 'Resolved' หรือ 'Closed'.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มประสานงานกับผู้ให้บริการ
|
กิจกรรมนี้หมายถึงคำขอบริการถูกส่งต่อไปยังผู้ให้บริการภายนอก หรือต้องรอให้บุคคลภายนอกดำเนินการ อนุมานได้จากการเปลี่ยนสถานะของรายการเป็น 'Waiting for vendor' หรือ 'With Third Party'. | ||
|
เหตุผลที่สำคัญ
การติดตามการประสานงานกับผู้ให้บริการเป็นเรื่องสำคัญ เพื่อระบุการพึ่งพาภายนอกและความล่าช้าที่ทีมบริการภายในควบคุมโดยตรงไม่ได้.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนเป็นสถานะ 'vendor' ที่กำหนดไว้.
บันทึก
ระบุเวลาที่ฟิลด์ 'status' เปลี่ยนเป็นค่าอย่าง 'Waiting for Vendor'.
ประเภทเหตุการณ์
inferred
|
|||
|
สิ้นสุดการประสานงานกับผู้ให้บริการ
|
หมายถึงเวลาที่ผู้ให้บริการภายนอกดำเนินการเสร็จและส่งคำขอบริการกลับมายังทีมภายใน อนุมานได้เมื่อรายการเปลี่ยนออกจากสถานะ 'Waiting for vendor'. | ||
|
เหตุผลที่สำคัญ
การวัดระยะเวลาที่ประสานงานกับผู้ให้บริการช่วยบริหารผลการดำเนินงานของผู้ให้บริการ และทำความเข้าใจว่าบุคคลภายนอกส่งผลต่อเวลาแก้ไขโดยรวมอย่างไร.
แหล่งข้อมูล
อนุมานจากประวัติรายการ โดยใช้เวลาที่สถานะเปลี่ยนจากสถานะ 'vendor' กลับเป็น 'In Progress'.
บันทึก
ระบุเวลาที่ฟิลด์ 'status' เปลี่ยนจากสถานะ 'vendor' กลับเป็นสถานะ 'active'.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เพื่อเริ่มต้นทำ process mining และค้นหาแนวทางปรับปรุงการจัดการคำขอบริการให้ดีขึ้น เริ่มปรับปรุงการปฏิบัติงานของคุณได้วันนี้.
เริ่มปรับปรุงการจัดการคำขอบริการใน Jira วันนี้
ทำระบบอัตโนมัติได้ 70% และยุติการดำเนินการที่ล่าช้า เพิ่มประสิทธิภาพได้ทันที!
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จในไม่กี่นาที.