> การปรับปรุงกระบวนการอย่างต่อเนื่อง > การจัดการคำขอบริการ > BMC Helix ITSM > เทมเพลตข้อมูล

เทมเพลตข้อมูลการจัดการคำขอบริการ

BMC Helix ITSM

แอตทริบิวต์การจัดการคำขอบริการ(20) กิจกรรมในการจัดการคำขอบริการ(14) คู่มือการดึงข้อมูล(3)

เทมเพลตข้อมูลการจัดการคำขอบริการ

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

แอตทริบิวต์ที่แนะนำให้เก็บ
กิจกรรมสำคัญที่ควรติดตาม
คำแนะนำการดึงข้อมูลจาก BMC Helix ITSM

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

แอตทริบิวต์การจัดการคำขอบริการ

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

5 จำเป็น 6 แนะนำ 9 ไม่บังคับ

	ชื่อ	คำอธิบาย
	Service Request ID ServiceRequestId	รหัสเฉพาะของคำขอรับบริการแต่ละรายการ ใช้เป็นคีย์หลักสำหรับติดตามคำขอตลอดวงจร.
คำอธิบาย Service Request ID เป็นรหัสเฉพาะที่ใช้ระบุคำขอรับบริการแต่ละรายการที่ผู้ใช้หรือระบบส่งเข้ามา รหัสนี้เชื่อมโยงเหตุการณ์ทั้งหมดเข้าด้วยกัน ตั้งแต่การบันทึกคำขอครั้งแรกจนถึงการปิดคำขอ ทำให้วิเคราะห์เส้นทางของคำขอแต่ละรายการได้ตั้งแต่ต้นจนจบ. ใน process mining รหัสนี้จำเป็นต่อการสร้างลำดับกิจกรรมของแต่ละเคสขึ้นใหม่ เครื่องมือจะใช้รหัสนี้จัดกลุ่มเหตุการณ์ที่เกี่ยวข้อง เช่น 'ส่งคำขอแล้ว' 'มอบหมายคำขอแล้ว' และ 'ปิดคำขอรับบริการแล้ว' ให้อยู่ในกระบวนการเดียวกัน ซึ่งเป็นพื้นฐานของการวิเคราะห์กระบวนการทั้งหมด. เหตุผลที่สำคัญ นี่คือรหัสประจำเคสหลัก หากไม่มีรหัสนี้ก็จะติดตามเส้นทางของคำขอรับบริการตั้งแต่ต้นจนจบไม่ได้ และไม่สามารถค้นพบหรือวิเคราะห์กระบวนการได้. แหล่งข้อมูล โดยทั่วไปคือฟิลด์ 'InstanceId' หรือ 'Request Number' ในแบบฟอร์ม 'SRM:Request' ของ BMC Helix ITSM. ตัวอย่าง SR000010572931SR000010572932SR000010572933
	กิจกรรม ActivityName	ชื่อเหตุการณ์หรืองานที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในวงจรคำขอรับบริการ.
คำอธิบาย แอตทริบิวต์นี้อธิบายขั้นตอนหรือการเปลี่ยนสถานะในกระบวนการคำขอรับบริการ เช่น 'กำลังตรวจสอบคำขอ' 'กำลังดำเนินการตามคำขอ' หรือ 'แก้ไขคำขอรับบริการแล้ว' แต่ละกิจกรรมแทนเหตุการณ์หนึ่งรายการในเส้นทางของคำขอ. การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining ช่วยค้นพบแผนผังกระบวนการ ระบุคอขวด และวิเคราะห์รูปแบบกระบวนการ การทำความเข้าใจว่ามีกิจกรรมใดเกิดขึ้น ตามลำดับใด และบ่อยเพียงใด เป็นสิ่งสำคัญต่อการปรับปรุงกระบวนการ. เหตุผลที่สำคัญ กิจกรรมเป็นองค์ประกอบพื้นฐานของแผนผังกระบวนการ เมื่อติดตามกิจกรรมเหล่านี้ คุณจะเห็นภาพและวิเคราะห์การไหลของกระบวนการได้ว่าการทำงานเกิดขึ้นจริงอย่างไร. แหล่งข้อมูล โดยทั่วไปได้จากการเปลี่ยนแปลงในฟิลด์ 'Status' และ 'Status Reason' ของแบบฟอร์ม 'SRM:Request' หรือจากบันทึกของแอปพลิเคชันที่เกี่ยวข้องกับการดำเนินงาน เช่น Incident หรือ Work Order. ตัวอย่าง คำขอกำลังรออนุมัติกำลังดำเนินการตามคำขอแก้ไขคำขอรับบริการแล้วปิดคำขอรับบริการแล้ว
	เวลาเริ่มต้น EventStartTime	เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์หนึ่งเริ่มต้นเมื่อใด.
คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่กิจกรรมเริ่มต้นอย่างแม่นยำ เหตุการณ์ทุกอย่างในบันทึก ตั้งแต่การส่งคำขอครั้งแรกจนถึงการปิดคำขอ ต้องมีเวลาเริ่มต้นเพื่อระบุลำดับเวลาของกระบวนการ. เวลานี้จำเป็นต่อการวิเคราะห์ process mining ที่อิงเวลา ใช้คำนวณระยะเวลาของวงจรและกิจกรรม เวลารอระหว่างขั้นตอน และตรวจสอบการปฏิบัติตาม SLA อีกทั้งช่วยค้นหาคอขวดและวิเคราะห์ประสิทธิภาพของกระบวนการในแต่ละช่วงเวลา. เหตุผลที่สำคัญ เวลาเริ่มต้นช่วยเรียงเหตุการณ์ตามลำดับเวลา ซึ่งจำเป็นต่อการคำนวณระยะเวลาของกระบวนการ ระบุความล่าช้า และทำความเข้าใจลำดับเหตุการณ์ของกระบวนการ. แหล่งข้อมูล ตรงกับฟิลด์เวลาใน audit log หรือตารางประวัติสถานะที่เชื่อมโยงกับแบบฟอร์ม 'SRM:Request' เช่น 'Submit Date' สำหรับเหตุการณ์แรก. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ระบบต้นทาง SourceSystem	ระบุระบบที่ดึงข้อมูลมา.
คำอธิบาย แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลกระบวนการ สำหรับมุมมองนี้จะกำหนดค่าเป็น 'BMC Helix ITSM' เพื่อแสดงว่าเหตุการณ์ทั้งหมดที่เกี่ยวข้องกับคำขอรับบริการมาจากระบบนี้. ในสภาพแวดล้อมที่เชื่อมต่อหลายระบบ ฟิลด์นี้สำคัญต่อการทำความเข้าใจที่มาของข้อมูลและการแบ่งข้อมูลตามแหล่งที่มา ช่วยให้ตรวจสอบที่มาได้ชัดเจน โดยเฉพาะเมื่อนำข้อมูลจากแพลตฟอร์มต่างๆ มารวมกัน. เหตุผลที่สำคัญ ฟิลด์นี้ให้ข้อมูลบริบทเกี่ยวกับแหล่งที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การตรวจสอบย้อนกลับ และการแก้ปัญหาในสภาพแวดล้อมที่มีหลายระบบ. แหล่งข้อมูล ค่านี้กำหนดไว้ระหว่างการดึงและแปลงข้อมูล ไม่ใช่ฟิลด์ที่มีอยู่ใน BMC Helix ITSM โดยตรง. ตัวอย่าง BMC Helix ITSM
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาที่ดึงข้อมูลของกระบวนการนี้จากระบบต้นทางมาอัปเดตล่าสุด.
คำอธิบาย แอตทริบิวต์นี้ระบุวันที่และเวลาที่ดึงข้อมูลจาก BMC Helix ITSM ล่าสุด ช่วยให้ผู้ใช้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลใหม่เพียงใด และครอบคลุมช่วงเวลาไหน. นี่คือเมทาดาทาสำคัญสำหรับแดชบอร์ดหรือการวิเคราะห์ process mining ช่วยให้ผู้ใช้ทราบว่าข้อมูลเชิงลึกอิงจากข้อมูลที่ใกล้เคียงเวลาจริงหรือเป็นข้อมูลย้อนหลัง ซึ่งมีผลต่อความน่าเชื่อถือและความเกี่ยวข้องของข้อสรุป. เหตุผลที่สำคัญ ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ซึ่งจำเป็นต่อการตัดสินใจโดยอาศัยข้อมูลประสิทธิภาพกระบวนการล่าสุดที่มี. แหล่งข้อมูล ระบบสร้างและเพิ่มเวลานี้ระหว่างการดึงและโหลดข้อมูล. ตัวอย่าง 2024-05-21T08:00:00Z
	เจ้าหน้าที่ที่ได้รับมอบหมาย AssignedAgent	ผู้ใช้ที่รับผิดชอบดำเนินการตามคำขอรับบริการในขณะนั้น.
คำอธิบาย แอตทริบิวต์นี้ระบุเจ้าหน้าที่ IT หรือเจ้าหน้าที่สนับสนุนที่รับผิดชอบคำขอ ณ ช่วงเวลาหนึ่ง หากค่านี้เปลี่ยนระหว่างวงจรของคำขอ แสดงว่ามีการส่งต่องานหรือมอบหมายงานใหม่. แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ผลงานและภาระงานของเจ้าหน้าที่ ช่วยติดตามจำนวนคำขอที่เจ้าหน้าที่แต่ละคนดูแล เวลาแก้ไขเฉลี่ย และความถี่ในการมอบหมายงานใหม่ ข้อมูลนี้ช่วยจัดการทรัพยากรและระบุโอกาสในการฝึกอบรม. เหตุผลที่สำคัญ การติดตามเจ้าหน้าที่ที่ได้รับมอบหมายจำเป็นต่อการวิเคราะห์การส่งต่องาน วัดผลการทำงานรายบุคคล และทำความเข้าใจการกระจายภาระงานในทีมสนับสนุน. แหล่งข้อมูล ตรงกับฟิลด์ 'Assignee' หรือ 'Assigned To' ในระเบียนการดำเนินงาน เช่น Work Order หรือ Incident ที่เชื่อมโยงกับคำขอรับบริการ. ตัวอย่าง Bob SmithAlice JohnsonCharlie Brown
	ทีมที่ได้รับมอบหมาย AssignedTeam	กลุ่มสนับสนุนหรือทีมที่รับผิดชอบคำขอรับบริการในขณะนั้น.
คำอธิบาย แอตทริบิวต์นี้ระบุกลุ่มงานที่รับผิดชอบคำขอ เช่น 'ฝ่ายช่วยเหลือ', 'ทีมเครือข่าย' หรือ 'ผู้ดูแลฐานข้อมูล' เมื่อค่าในฟิลด์นี้เปลี่ยน แสดงว่ามีการโอนความรับผิดชอบระหว่างทีม การวิเคราะห์ตามทีมที่ได้รับมอบหมายช่วยให้เห็นคอขวดในแต่ละทีม วิเคราะห์การส่งต่องานระหว่างทีม และประเมินประสิทธิภาพของกลุ่มสนับสนุนต่างๆ ข้อมูลนี้สำคัญต่อแดชบอร์ดการทำงานซ้ำและการมอบหมายคำขอ และประสิทธิภาพการคัดแยกคำขอ โดยช่วยให้เห็นรูปแบบการส่งต่องานภายในองค์กร. เหตุผลที่สำคัญ ช่วยวิเคราะห์การไหลของกระบวนการระหว่างกลุ่มงานต่างๆ เพื่อระบุจุดที่การส่งต่องานไม่มีประสิทธิภาพและวัดผลการทำงานของแต่ละทีม. แหล่งข้อมูล ตรงกับฟิลด์ 'Assigned Group' ในระเบียนการดำเนินการตามคำขอ เช่น ใบสั่งงานหรือเหตุขัดข้อง ที่เชื่อมโยงกับคำขอบริการ. ตัวอย่าง ศูนย์บริการทีมสนับสนุนโครงสร้างพื้นฐานทีมสนับสนุนแอปพลิเคชันระดับ 2
	ประเภทบริการ ServiceType	หมวดหมู่หรือประเภทของบริการที่ผู้ใช้ร้องขอ.
คำอธิบาย ประเภทบริการใช้จัดหมวดหมู่ลักษณะของคำขอ เช่น 'ขอซอฟต์แวร์ใหม่' 'รีเซ็ตรหัสผ่าน' หรือ 'เตรียมความพร้อมพนักงานใหม่' เป็นมิติพื้นฐานสำหรับกรองและแบ่งกลุ่มข้อมูลกระบวนการ. ในการวิเคราะห์กระบวนการ แอตทริบิวต์นี้ใช้เปรียบเทียบประสิทธิภาพของคำขอแต่ละประเภท ช่วยตอบคำถาม เช่น 'บริการประเภทใดใช้เวลาแก้ไขนานที่สุด' หรือ 'บริการประเภทใดมีการทำงานซ้ำมากที่สุด' ข้อมูลนี้สำคัญต่อแดชบอร์ดเวลาแก้ไขและการปฏิบัติตาม SLA. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มคำขอรับบริการเพื่อเปรียบเทียบการไหลของกระบวนการ ระบุปัญหาเฉพาะประเภท และกำหนดแนวทางปรับปรุงได้ตรงจุด. แหล่งข้อมูล ข้อมูลนี้มักอยู่ในฟิลด์ 'Title' หรือฟิลด์จัดหมวดหมู่ในแบบฟอร์ม 'SRM:Request' โดยอ้างอิงจากบริการที่เลือกในแค็ตตาล็อก. ตัวอย่าง ขอฮาร์ดแวร์ใหม่ขอสิทธิ์เข้าถึงซอฟต์แวร์ตั้งค่าการเข้าถึง VPN
	ระดับความสำคัญ Priority	ระดับความสำคัญที่กำหนดให้กับคำขอรับบริการ เพื่อแสดงผลกระทบต่อธุรกิจและความเร่งด่วน.
คำอธิบาย ระดับความสำคัญกำหนดลำดับและความเร็วในการดำเนินการตามคำขอ ค่าที่ใช้กันทั่วไป ได้แก่ 'วิกฤต' 'สูง' 'ปานกลาง' และ 'ต่ำ' โดยมักพิจารณาจากผลกระทบของคำขอต่อธุรกิจร่วมกับความเร่งด่วน. การวิเคราะห์ตามระดับความสำคัญช่วยประเมินว่าคำขอที่มีความสำคัญสูงได้รับการดำเนินการเร็วกว่าคำขอที่มีความสำคัญต่ำหรือไม่ เป็นมิติสำคัญในแดชบอร์ดเวลาแก้ไขและการปฏิบัติตาม SLA เพื่อช่วยจัดสรรทรัพยากรให้เหมาะกับความต้องการทางธุรกิจที่สำคัญที่สุด. เหตุผลที่สำคัญ ช่วยประเมินว่ากระบวนการจัดลำดับงานได้เหมาะสมหรือไม่ และให้บริการตามระดับที่คาดหวังสำหรับคำขอที่มีผลกระทบต่อธุรกิจแตกต่างกันได้หรือไม่. แหล่งข้อมูล คือฟิลด์ 'Priority' ในแบบฟอร์ม 'SRM:Request'. ตัวอย่าง วิกฤตสูงปานกลางต่ำ
	เวลาสิ้นสุด EventEndTime	เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์หนึ่งเสร็จสิ้นเมื่อใด.
คำอธิบาย เวลาสิ้นสุดระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด กิจกรรมหลายอย่างในระบบ ITSM เป็นเพียงการเปลี่ยนสถานะที่เกิดขึ้นทันที แต่บางกิจกรรมมีระยะเวลาที่วัดได้ การบันทึกเวลาสิ้นสุดช่วยคำนวณระยะเวลาของกิจกรรมเหล่านั้นได้อย่างแม่นยำ. ในการวิเคราะห์ จะใช้เวลาสิ้นสุดร่วมกับเวลาเริ่มต้นเพื่อคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการ ช่วยระบุว่างานใดใช้เวลามากที่สุด ไม่ใช่แค่เวลาระหว่างรอขั้นตอนถัดไป. เหตุผลที่สำคัญ ช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรม ซึ่งจำเป็นต่อการระบุขั้นตอนที่ไม่มีประสิทธิภาพและทำความเข้าใจว่าทรัพยากรใช้เวลาไปกับงานส่วนใด. แหล่งข้อมูล ค่านี้คำนวณได้ โดยเวลาสิ้นสุดของกิจกรรมหนึ่งมักตรงกับเวลาเริ่มต้นของกิจกรรมถัดไปในเคสเดียวกัน ส่วนกิจกรรมสุดท้ายจะใช้เวลาที่แก้ไขหรือปิดคำขอ. ตัวอย่าง 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	สถานะคำขอ RequestStatus	สถานะของคำขอรับบริการขณะที่เกิดเหตุการณ์ เช่น 'กำลังดำเนินการ' 'รอดำเนินการ' หรือ 'ปิดแล้ว'.
คำอธิบาย แอตทริบิวต์นี้บันทึกสถานะของคำขอรับบริการในแต่ละช่วงของวงจร สถานะช่วยให้เข้าใจบริบทของแต่ละกิจกรรม และมักเป็นแหล่งข้อมูลที่ใช้ระบุแอตทริบิวต์ 'กิจกรรม'. การวิเคราะห์ตามสถานะช่วยให้เข้าใจว่าคำขอใช้เวลาอยู่ในสถานะต่างๆ นานเพียงใด เช่น 'รอลูกค้า' หรือ 'รอการอนุมัติ' ซึ่งจำเป็นต่อการระบุคอขวดและความล่าช้าที่เกิดจากการพึ่งพาบุคคลภายนอกหรือคิวงานภายใน อีกทั้งยังช่วยในการใช้งานแดชบอร์ดระบุคอขวดโดยตรง. เหตุผลที่สำคัญ แสดงสถานะของคำขอ ณ ช่วงเวลาหนึ่ง ช่วยวิเคราะห์เวลาที่ใช้ในสถานะรอเทียบกับสถานะที่กำลังดำเนินงาน ซึ่งเป็นข้อมูลสำคัญในการระบุคอขวด. แหล่งข้อมูล คือฟิลด์ 'Status' ในแบบฟอร์ม 'SRM:Request' โดยดูค่าในอดีตได้จาก audit log. ตัวอย่าง วางแผนกำลังดำเนินการรอดำเนินการแก้ไขแล้วปิดแล้ว
	เกินกำหนด SLA หรือไม่ IsSlaBreached	ค่าบูลีนที่ระบุว่าดำเนินการคำขอบริการเสร็จหลังวันครบกำหนดตาม SLA หรือไม่.
คำอธิบาย ตั้งค่าที่คำนวณนี้เป็น true เมื่อเวลาที่แก้ไขคำขอบริการเสร็จช้ากว่า 'วันครบกำหนดตาม SLA' จึงแสดงผลการปฏิบัติตาม SLA ของแต่ละคำขอได้อย่างชัดเจนว่าเป็นไปตามกำหนดหรือไม่ แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ดภาพรวมการปฏิบัติตาม SLA และ KPI อัตราการปฏิบัติตาม SLA ช่วยรวมข้อมูลเพื่อคำนวณอัตราการปฏิบัติตามข้อกำหนดโดยรวม และกรองวิเคราะห์ลักษณะกระบวนการของคำขอที่เกินกำหนดเทียบกับคำขอที่ทำได้ตามกำหนด เพื่อค้นหาสาเหตุที่แท้จริงของการไม่เป็นไปตาม SLA. เหตุผลที่สำคัญ ช่วยให้วิเคราะห์ผลการดำเนินงานตาม SLA ได้ง่ายขึ้น โดยแปลงการเปรียบเทียบเวลาเป็นค่าบูลีนที่ชัดเจน ทำให้วัดและแสดงอัตราการปฏิบัติตามข้อกำหนดได้สะดวก. แหล่งข้อมูล ฟิลด์นี้คำนวณจากเงื่อนไข: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. ตัวอย่าง truefalse
	จำนวนครั้งที่ส่งต่องาน HandoffCount	จำนวนครั้งทั้งหมดที่มีการมอบหมายคำขอบริการให้เจ้าหน้าที่หรือทีมอื่น.
คำอธิบาย เมตริกนี้คำนวณจำนวนครั้งที่ค่า 'AssignedAgent' หรือ 'AssignedTeam' เปลี่ยนไปสำหรับคำขอบริการหนึ่งรายการ หากมีการส่งต่องานหลายครั้ง อาจบ่งชี้ว่ากระบวนการแยกส่วน แก้ไขไม่สำเร็จตั้งแต่การติดต่อครั้งแรก หรือมีการส่งคำขอไปยังทีมที่ไม่เหมาะสม แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานของ KPI จำนวนครั้งเฉลี่ยที่ส่งต่องานระหว่างเจ้าหน้าที่ต่อคำขอ และใช้ในแดชบอร์ดการทำงานซ้ำและการมอบหมายคำขอ การวิเคราะห์กรณีที่มีการส่งต่องานหลายครั้งช่วยให้เห็นโอกาสในการปรับปรุงการคัดแยก จัดอบรมให้เหมาะสม หรือปรับขั้นตอนการแก้ไขให้กระชับขึ้น เพื่อลดความล่าช้าและเพิ่มความพึงพอใจของลูกค้า. เหตุผลที่สำคัญ ใช้วัดการแยกส่วนของกระบวนการและภาระในการสื่อสาร หากมีการส่งต่องานหลายครั้ง มักสัมพันธ์กับระยะเวลาแก้ไขที่นานขึ้นและประสิทธิภาพกระบวนการที่ลดลง. แหล่งข้อมูล เมตริกนี้คำนวณโดยนับจำนวนค่าที่ไม่ซ้ำกันในแอตทริบิวต์ 'AssignedAgent' หรือ 'AssignedTeam' ของ Service Request ID แต่ละรายการ. ตัวอย่าง 0135
	ช่องทางการส่งคำขอ SubmissionChannel	วิธีหรือช่องทางที่ใช้ส่งคำขอบริการ.
คำอธิบาย แอตทริบิวต์นี้บันทึกวิธีเริ่มต้นคำขอบริการ เช่น ผ่านพอร์ทัลบริการตนเอง อีเมล โทรศัพท์ติดต่อฝ่ายบริการ หรือการแจ้งเตือนจากระบบอัตโนมัติ ช่องทางที่ต่างกันอาจทำให้รูปแบบกระบวนการและระยะเวลาแก้ไขแตกต่างกัน การวิเคราะห์กระบวนการตามช่องทางการส่งคำขอช่วยให้เห็นจุดที่ไม่มีประสิทธิภาพหรือแนวทางที่ได้ผลในแต่ละช่องทาง ตัวอย่างเช่น คำขอที่ส่งผ่านพอร์ทัลบริการตนเองอาจได้รับการแก้ไขเร็วกว่า เพราะข้อมูลเบื้องต้นครบถ้วนกว่า ส่วนคำขอทางอีเมลอาจต้องคัดแยกด้วยตนเองมากขึ้น. เหตุผลที่สำคัญ ช่วยให้เข้าใจว่าวิธีรับคำขอส่งผลต่อประสิทธิภาพกระบวนการ คุณภาพข้อมูล และระยะเวลาดำเนินการโดยรวมอย่างไร จึงปรับปรุงช่องทางที่ต้องการได้ตรงจุด. แหล่งข้อมูล โดยทั่วไปอนุมานข้อมูลนี้ได้จากฟิลด์อย่าง 'Client Type' หรือ 'Reported Source' ในแบบฟอร์ม 'SRM:Request' หรือจากใบงานที่เกี่ยวข้อง. ตัวอย่าง พอร์ทัลบริการตนเองอีเมลโทรศัพท์ระบบสร้างรายการ
	แผนกของผู้ขอ RequestorDepartment	แผนกหรือหน่วยงานธุรกิจของผู้ใช้ที่ส่งคำขอ.
คำอธิบาย แอตทริบิวต์นี้ระบุแผนกของผู้ที่ขอรับบริการ เช่น 'การเงิน', 'ทรัพยากรบุคคล' หรือ 'เทคโนโลยีสารสนเทศ' โดยทั่วไปข้อมูลนี้มาจากโปรไฟล์ผู้ใช้ในระบบ การแบ่งผลวิเคราะห์กระบวนการตามแผนกช่วยให้เห็นความต้องการและรูปแบบคำขอเฉพาะของแต่ละแผนก รวมถึงโอกาสในการจัดอบรมหรือปรับปรุงบริการให้ตรงจุด นอกจากนี้ยังช่วยตอบคำถาม เช่น 'แผนกการเงินต้องรอคำขอนานกว่าแผนกอื่นหรือไม่'. เหตุผลที่สำคัญ ช่วยวิเคราะห์การใช้บริการและประสิทธิภาพกระบวนการตามหน่วยงานธุรกิจ เพื่อให้เห็นปัญหาหรือแนวโน้มเฉพาะของแต่ละแผนก. แหล่งข้อมูล โดยปกติดึงข้อมูลนี้จากโปรไฟล์ของผู้ใช้ที่ระบุในฟิลด์ 'Requested For' ของแบบฟอร์ม 'SRM:Request'. ตัวอย่าง การเงินฝ่ายขายทรัพยากรบุคคลเทคโนโลยีสารสนเทศ
	มีการทำงานซ้ำหรือไม่ IsRework	ค่าบูลีนที่ระบุว่าคำขอบริการมีการทำงานซ้ำ เช่น ย้อนกลับไปยังขั้นตอนก่อนหน้าหรือไม่.
คำอธิบาย ค่านี้ระบุคำขอบริการที่วนกลับหรือมีการทำงานซ้ำในกระบวนการ ตัวอย่างเช่น คำขอที่เปลี่ยนจาก 'กำลังดำเนินการตามคำขอ' กลับไปเป็น 'กำลังตรวจสอบคำขอ' ถือว่ามีการทำงานซ้ำ ทั้งนี้ขึ้นอยู่กับกติกาของกระบวนการธุรกิจ แอตทริบิวต์นี้ใช้กับแดชบอร์ดวิเคราะห์การทำงานซ้ำและการมอบหมายคำขอ และ KPI อัตราการทำงานซ้ำของคำขอโดยตรง ช่วยวัดความถี่ของการทำงานซ้ำและวิเคราะห์สาเหตุที่พบบ่อย เช่น การประเมินเบื้องต้นไม่ถูกต้องหรือข้อมูลไม่ครบ ซึ่งทำให้กระบวนการไม่มีประสิทธิภาพ. เหตุผลที่สำคัญ ช่วยวัดความไม่มีประสิทธิภาพของกระบวนการ โดยระบุกรณีที่เบี่ยงเบนจากเส้นทางปกติ เพื่อค้นหาสาเหตุของการวนกลับและการทำงานซ้ำ. แหล่งข้อมูล แอตทริบิวต์นี้คำนวณจากลำดับกิจกรรมในบันทึกเหตุการณ์ โดยต้องกำหนดตรรกะเพื่อตรวจจับการย้อนกลับไปยังขั้นตอนก่อนหน้าในกระบวนการ. ตัวอย่าง truefalse
	มีการยกระดับหรือไม่ IsEscalated	ค่าบูลีนที่ระบุว่ามีการยกระดับคำขอบริการหรือไม่.
คำอธิบาย ตั้งค่านี้เป็น true เมื่อมีการยกระดับคำขอบริการตามสายงานหรือลำดับชั้น โดยทั่วไปจะยกระดับเมื่อคำขอไม่คืบหน้าตามที่คาด เสี่ยงเกินกำหนด SLA หรือต้องขออนุมัติหรือการดำเนินการจากผู้มีอำนาจสูงกว่า แอตทริบิวต์นี้สำคัญต่อแดชบอร์ดวิเคราะห์ประสิทธิภาพการยกระดับคำขอ ใช้กรองและวิเคราะห์เส้นทางของคำขอที่มีการยกระดับ เพื่อดูว่าอะไรเป็นสาเหตุ ใช้เวลาแก้ไขนานเท่าใดหลังยกระดับ และกระบวนการยกระดับได้ผลเพียงใด. เหตุผลที่สำคัญ ช่วยแยกและวิเคราะห์คำขอที่ต้องยกระดับ เพื่อค้นหาจุดอ่อนของกระบวนการปกติหรือปัจจัยที่ทำให้เกิดปัญหาซับซ้อน. แหล่งข้อมูล โดยทั่วไปไม่มีฟิลด์เดียวที่ระบุข้อมูลนี้โดยตรง แต่คำนวณได้จากการตรวจหากิจกรรมที่เกี่ยวข้องกับการยกระดับในบันทึกการตรวจสอบ หรือการเปลี่ยนแปลงลำดับความสำคัญหรือผู้รับผิดชอบตามขั้นตอนการยกระดับ. ตัวอย่าง truefalse
	รหัสการปิดคำขอ CloseCode	รหัสที่ระบุผลลัพธ์หรือเหตุผลสุดท้ายที่ปิดคำขอบริการ.
คำอธิบาย รหัสการปิดคำขอเป็นวิธีมาตรฐานในการจัดประเภทผลการดำเนินการคำขอบริการ ตัวอย่างเช่น 'ฝ่ายบริการแก้ไขแล้ว', 'ผู้ใช้ยกเลิก' หรือ 'คำขอซ้ำ' การวิเคราะห์รหัสการปิดคำขอช่วยให้เข้าใจผลลัพธ์ที่เกิดขึ้นบ่อย หากมีคำขอถูกยกเลิกจำนวนมาก อาจแสดงว่ากระบวนการใช้เวลานาน หรือหากมีคำขอซ้ำจำนวนมาก อาจเป็นปัญหาที่ระบบหรือการสื่อสาร ข้อมูลนี้ใช้กับแดชบอร์ดความถูกต้องของหมวดหมู่การแก้ไข. เหตุผลที่สำคัญ ให้ข้อมูลผลลัพธ์ของคำขอในรูปแบบที่มีโครงสร้าง จึงวิเคราะห์ประสิทธิผลของการแก้ไข รวมถึงสาเหตุที่ดำเนินการไม่เสร็จหรือถูกยกเลิกได้. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้อยู่ในฟิลด์ 'Resolution' หรือ 'Closure Code' ของใบงานที่เชื่อมโยงกับคำขอบริการ. ตัวอย่าง ดำเนินการสำเร็จผู้ใช้ยกเลิกไม่ต้องการแล้วแก้ไขโดยระบบอัตโนมัติ
	วันครบกำหนดตาม SLA SlaTargetDate	วันและเวลาที่คาดว่าจะดำเนินการคำขอบริการให้เสร็จตามข้อตกลงระดับการให้บริการ (SLA).
คำอธิบาย วันครบกำหนดตาม SLA คือเวลาที่คำนวณไว้เพื่อระบุเส้นตายในการดำเนินการคำขอบริการให้เสร็จ โดยคำนวณตามเงื่อนไขของข้อตกลงการให้บริการ ซึ่งมักพิจารณาปัจจัยต่างๆ เช่น ลำดับความสำคัญและประเภทของคำขอ แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ดภาพรวมการปฏิบัติตาม SLA ใช้เป็นเกณฑ์เปรียบเทียบกับเวลาแก้ไขจริง เมื่อนำ 'EventEndTime' ของกิจกรรมแก้ไขขั้นสุดท้ายมาเทียบกับวันครบกำหนดนี้ ก็จะทราบได้ว่าดำเนินการตามข้อตกลงการให้บริการได้ทันเวลาหรือไม่. เหตุผลที่สำคัญ เป็นเกณฑ์หลักในการวัดผลการให้บริการเทียบกับข้อตกลง จึงจำเป็นต่อการติดตามและรายงานการปฏิบัติตาม SLA. แหล่งข้อมูล โมดูล Service Level Management (SLM) คำนวณและจัดเก็บวันที่นี้ไว้ โดยดูได้จากแบบฟอร์ม SLM ที่เชื่อมโยงกับคำขอบริการ. ตัวอย่าง 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	หมวดหมู่การแก้ไข ResolutionCategory	การจัดประเภทวิธีแก้ไขที่ใช้ดำเนินการตามคำขอ.
คำอธิบาย แอตทริบิวต์นี้จัดประเภทวิธีแก้ไขคำขออย่างเป็นระบบ เช่น 'แก้ไขซอฟต์แวร์', 'อบรมผู้ใช้' หรือ 'แก้ไขข้อมูล' โดยให้รายละเอียดลักษณะการแก้ไขมากกว่ารหัสการปิดคำขอทั่วไป ข้อมูลนี้จำเป็นต่อแดชบอร์ดความถูกต้องของหมวดหมู่การแก้ไข ซึ่งใช้เปรียบเทียบกับประเภทบริการเริ่มต้นเพื่อตรวจสอบความสอดคล้อง การวิเคราะห์หมวดหมู่การแก้ไขช่วยให้เห็นแนวโน้มของปัญหาและวางแผนจัดการปัญหาเชิงรุก เช่น หากมีคำขอจำนวนมากที่แก้ไขด้วยการอบรมผู้ใช้. เหตุผลที่สำคัญ ช่วยให้เห็นลักษณะของวิธีแก้ไข ระบุแนวโน้มของปัญหาที่เกิดซ้ำ และหาโอกาสจัดการปัญหาเชิงรุกหรือจัดอบรมผู้ใช้. แหล่งข้อมูล ข้อมูลนี้อยู่ในฟิลด์การจัดหมวดหมู่ด้านการปฏิบัติการและผลิตภัณฑ์ของใบงาน โดยมักใช้ชื่อ 'Resolution Category'. ตัวอย่าง การจัดการบัญชีผู้ใช้อุปกรณ์ขัดข้องอัปเกรดซอฟต์แวร์ได้รับข้อมูลแล้ว

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการจัดการคำขอบริการ

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

6 แนะนำ 8 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	กำลังดำเนินการตามคำขอ	เจ้าหน้าที่หรือทีมที่ได้รับมอบหมายเริ่มดำเนินงานตามคำขอรับบริการแล้ว แสดงว่าคำขอออกจากคิวและเข้าสู่สถานะที่กำลังทำงาน.
เหตุผลที่สำคัญ เป็นจุดเริ่มต้นของงานดำเนินการที่สร้างคุณค่า การวิเคราะห์เวลาที่ใช้ในช่วงนี้ช่วยให้เข้าใจผลิตภาพของทรัพยากรและความซับซ้อนของงาน. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็น 'กำลังดำเนินการ'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'กำลังดำเนินการ'. ประเภทเหตุการณ์ inferred
	แก้ไขคำขอรับบริการแล้ว	ดำเนินการตามคำขอรับบริการเสร็จแล้ว และแจ้งผลการแก้ไขให้ผู้ส่งคำขอทราบ คำขอจะรอการยืนยันขั้นสุดท้าย หรือปิดโดยอัตโนมัติเมื่อครบระยะเวลาที่กำหนด.
เหตุผลที่สำคัญ หมุดหมายสำคัญที่แสดงว่าสิ้นสุดวงจรการให้บริการ ใช้เป็นจุดสิ้นสุดหลักในการวัดเวลาแก้ไขและการปฏิบัติตาม SLA. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็น 'แก้ไขแล้ว' หรือ 'เสร็จสมบูรณ์'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'แก้ไขแล้ว' หรือ 'เสร็จสมบูรณ์'. ประเภทเหตุการณ์ inferred
	ปิดคำขอรับบริการแล้ว	ปิดคำขอรับบริการอย่างเป็นทางการและเปลี่ยนเป็นสถานะเก็บถาวรที่อ่านได้อย่างเดียว โดยจะเกิดขึ้นหลังแก้ไขเสร็จและพ้นช่วงเวลารอการยืนยันแล้ว.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดของกระบวนการอย่างชัดเจน ระยะเวลาระหว่าง 'แก้ไขแล้ว' กับ 'ปิดแล้ว' อาจช่วยให้เห็นจุดที่ไม่มีประสิทธิภาพในขั้นตอนปิดคำขอ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะสุดท้ายในแบบฟอร์ม SRM:Request เป็น 'ปิดแล้ว'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'ปิดแล้ว'. ประเภทเหตุการณ์ inferred
	มอบหมายคำขอแล้ว	มอบหมายคำขอรับบริการให้เจ้าหน้าที่หรือทีมที่รับผิดชอบดำเนินงานแล้ว ซึ่งเป็นจุดสิ้นสุดของขั้นตอนคัดแยก.
เหตุผลที่สำคัญ หมุดหมายนี้สำคัญต่อการวัดเวลาคัดแยกและวิเคราะห์ภาระงานของเจ้าหน้าที่ การมอบหมายงานซ้ำบ่อยครั้งอาจบ่งชี้ถึงปัญหาในการจัดเส้นทางงานหรือทักษะที่ยังขาดอยู่. แหล่งข้อมูล บันทึกเหตุการณ์นี้ได้โดยตรงจาก audit log ของฟิลด์ 'Assigned Group' หรือ 'Assignee' ใน SRM:Request หรือแบบฟอร์มแอปพลิเคชันที่เกี่ยวข้องกับการดำเนินงาน เช่น WOI:WorkOrder. บันทึก เวลาจาก audit log ที่แสดงว่ามีการกำหนดค่าในฟิลด์ 'Assignee' ซึ่งเดิมไม่มีค่าเป็นครั้งแรก. ประเภทเหตุการณ์ explicit
	ยกเลิกคำขอรับบริการ	ผู้ส่งคำขอหรือ service desk ถอนคำขอรับบริการก่อนดำเนินการเสร็จ สถานะนี้เป็นสถานะสิ้นสุดของคำขอ.
เหตุผลที่สำคัญ การติดตามคำขอที่ถูกยกเลิกช่วยให้เห็นรูปแบบต่างๆ เช่น ผู้ใช้ส่งคำขอผิดประเภทหรือไม่ต้องการบริการนั้นแล้ว ซึ่งนำไปใช้ปรับปรุงแค็ตตาล็อกบริการได้. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็น 'ยกเลิกแล้ว'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'ยกเลิกแล้ว'. ประเภทเหตุการณ์ inferred
	ส่งคำขอรับบริการแล้ว	กิจกรรมนี้บันทึกการสร้างและส่งคำขอรับบริการใหม่โดยผู้ใช้ ระบบจะบันทึกเมื่อมีรายการใหม่ในแบบฟอร์ม SRM:Request พร้อมสถานะเริ่มต้น ซึ่งโดยทั่วไปคือ 'ส่งแล้ว'.
เหตุผลที่สำคัญ นี่คือจุดเริ่มต้นของคำขอรับบริการแต่ละรายการ ซึ่งจำเป็นต่อการวัดระยะเวลาตลอดวงจรและวิเคราะห์ปริมาณคำขอที่เข้ามา. แหล่งข้อมูล อนุมานจากเวลาที่สร้างรายการและสถานะเริ่มต้น เช่น 'ส่งแล้ว' ในแบบฟอร์ม SRM:Request. บันทึก ระบุเวลาที่สร้าง Service Request ID ใหม่ในแบบฟอร์ม SRM:Request เมื่อสถานะเป็น 'ส่งแล้ว'. ประเภทเหตุการณ์ inferred
	กำลังตรวจสอบคำขอ	ทีม service desk กำลังตรวจสอบและคัดแยกคำขอเบื้องต้น เพื่อพิจารณาประเภท ความสำคัญ และทีมที่จะรับผิดชอบดำเนินการ โดยทั่วไปจะแสดงเป็นการเปลี่ยนสถานะในระเบียนคำขอ.
เหตุผลที่สำคัญ การติดตามกิจกรรมนี้ช่วยวัดประสิทธิภาพการคัดแยก และระบุความล่าช้าระหว่างการส่งคำขอกับการมอบหมายงาน ซึ่งจำเป็นต่อ KPI 'เวลาเฉลี่ยในการคัดแยก'. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็นค่าอย่าง 'กำลังตรวจสอบ' หรือ 'วางแผน'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'กำลังตรวจสอบ'. ประเภทเหตุการณ์ inferred
	ขอข้อมูลเพิ่มเติมจากผู้ใช้	เจ้าหน้าที่ผู้ดำเนินการต้องการข้อมูลเพิ่มเติมจากผู้ส่งคำขอเพื่อทำงานต่อ โดยทั่วไปคำขอจะเปลี่ยนเป็นสถานะ 'รอดำเนินการ'.
เหตุผลที่สำคัญ กิจกรรมนี้จำเป็นต่อการคำนวณ 'เวลารอข้อมูลจากภายนอก' และช่วยระบุว่าคำขอหยุดชะงักเพราะข้อมูลไม่ครบถ้วนบ่อยเพียงใด. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็น 'รอดำเนินการ' พร้อมเหตุผล เช่น 'รอลูกค้า' หรือ 'รอข้อมูล'. บันทึก เวลาที่สถานะเปลี่ยนเป็น 'รอดำเนินการ' พร้อมเหตุผลของสถานะที่ระบุ. ประเภทเหตุการณ์ inferred
	คำขอกำลังรออนุมัติ	ส่งคำขอรับบริการให้ผู้อนุมัติหรือกลุ่มผู้อนุมัติที่กำหนดแล้ว และกำลังรอการตัดสินใจก่อนเริ่มดำเนินการ ขั้นตอนนี้มักพบในคำขอที่เกี่ยวข้องกับค่าใช้จ่ายหรือสิทธิ์การเข้าถึง.
เหตุผลที่สำคัญ กิจกรรมนี้ช่วยแยกความล่าช้าที่เกี่ยวกับการอนุมัติออกมา เพื่อวิเคราะห์ระยะเวลาของรอบการอนุมัติและหาคอขวดในลำดับการอนุมัติ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็นค่าอย่าง 'รออนุมัติ'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'รออนุมัติ'. ประเภทเหตุการณ์ inferred
	ดำเนินการแก้ไขเสร็จแล้ว	เจ้าหน้าที่ดำเนินงานด้านเทคนิคที่จำเป็นต่อคำขอรับบริการเสร็จแล้ว ขณะนี้คำขอพร้อมให้ผู้ใช้ยืนยันก่อนปิดงานอย่างเป็นทางการ.
เหตุผลที่สำคัญ กิจกรรมนี้แยกการทำงานด้านเทคนิคที่เสร็จแล้วออกจากการปิดคำขออย่างเป็นทางการ ช่วยให้เห็นความล่าช้าระหว่างงานเสร็จกับการยืนยันจากผู้ใช้. แหล่งข้อมูล อนุมานได้จากการเปลี่ยนสถานะของทิกเก็ตงานเบื้องหลัง เช่น สถานะ Work Order เปลี่ยนเป็น 'เสร็จสมบูรณ์' ก่อนที่ SRM:Request หลักจะเปลี่ยนเป็น 'แก้ไขแล้ว'. บันทึก เวลาที่ทิกเก็ตงานเบื้องหลัง เช่น Work Order หรือ Incident ซึ่งเชื่อมโยงกับ SRM:Request ถูกระบุว่าเสร็จสมบูรณ์. ประเภทเหตุการณ์ inferred
	ดำเนินการคำขอต่อ	นำคำขอรับบริการออกจากสถานะรอดำเนินการหรือรอ ซึ่งมักเกิดหลังผู้ใช้ส่งข้อมูลที่ต้องการแล้ว เจ้าหน้าที่จึงกลับมาดำเนินการตามคำขอต่อ.
เหตุผลที่สำคัญ เป็นจุดสิ้นสุดของช่วงเวลารอ ช่วยวัดเวลารอข้อมูลจากภายนอกและผลกระทบต่อการปฏิบัติตาม SLA ได้อย่างแม่นยำ. แหล่งข้อมูล อนุมานเมื่อสถานะของ SRM:Request เปลี่ยนจาก 'รอดำเนินการ' กลับเป็น 'กำลังดำเนินการ'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนจาก 'รอดำเนินการ' เป็น 'กำลังดำเนินการ'. ประเภทเหตุการณ์ inferred
	ปฏิเสธคำขอ	คำขอรับบริการถูกปฏิเสธในขั้นตอนการอนุมัติ สถานะนี้เป็นสถานะสิ้นสุดและหยุดกระบวนการก่อนเริ่มดำเนินการตามคำขอ.
เหตุผลที่สำคัญ การวิเคราะห์คำขอที่ถูกปฏิเสธช่วยให้เห็นปัญหาเกี่ยวกับเหตุผลของคำขอ เกณฑ์คุณสมบัติ หรือนโยบายการอนุมัติ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request เป็น 'ถูกปฏิเสธ'. บันทึก เวลาของเหตุการณ์อัปเดตที่ฟิลด์ 'Status' ใน SRM:Request เปลี่ยนเป็น 'ถูกปฏิเสธ'. ประเภทเหตุการณ์ inferred
	ผู้ใช้ยืนยันการแก้ไขแล้ว	ผู้ส่งคำขอยืนยันด้วยตนเองว่าได้รับบริการเป็นที่พอใจและแก้ไขคำขอเรียบร้อยแล้ว ซึ่งมักทำให้คำขอถูกปิดในขั้นตอนสุดท้าย.
เหตุผลที่สำคัญ เป็นตัวชี้วัดความพึงพอใจของลูกค้าที่ชัดเจนและปิดการให้บริการอย่างเป็นทางการ อีกทั้งแยกการแก้ไขตามกระบวนการออกจากการยอมรับของลูกค้า. แหล่งข้อมูล อาจบันทึกเหตุการณ์นี้ไว้ในบันทึกงานหรือหมายเหตุของกิจกรรมใน SRM:Request เมื่อผู้ใช้ยืนยันผ่านพอร์ทัลหรืออีเมล แต่ไม่ได้มีสถานะแยกสำหรับเหตุการณ์นี้เสมอไป. บันทึก ตรวจสอบบันทึกงาน (SRM:WorkInfo) เพื่อหารายการที่ระบุว่าผู้ใช้ยืนยันหรือทำแบบสำรวจเสร็จแล้ว. ประเภทเหตุการณ์ explicit
	อนุมัติคำขอแล้ว	ผู้มีอำนาจอนุมัติคำขอรับบริการแล้ว จึงดำเนินการตามคำขอต่อได้ โดยทั่วไปเหตุการณ์นี้จะเกิดหลังจากสถานะ 'รออนุมัติ'.
เหตุผลที่สำคัญ เป็นจุดสิ้นสุดของกระบวนการย่อยด้านการอนุมัติ และเป็นหมุดหมายสำคัญในการติดตามระยะเวลาการอนุมัติและผลกระทบต่อเวลาแก้ไขโดยรวม. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในแบบฟอร์ม SRM:Request จาก 'รออนุมัติ' เป็นสถานะถัดไป เช่น 'วางแผน' หรือ 'กำลังดำเนินการ' ส่วนผลการอนุมัติจะบันทึกไว้ในแบบฟอร์มการอนุมัติที่เกี่ยวข้อง. บันทึก เวลาที่สถานะเปลี่ยนจาก 'รออนุมัติ' หลังได้รับการอนุมัติ. ประเภทเหตุการณ์ inferred

แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก BMC Helix ITSM

ขั้นตอน

เข้าใช้งาน Smart Reporting: เข้าสู่ระบบสภาพแวดล้อม BMC Helix ITSM ของคุณ ไปที่ส่วนรายงานแล้วเปิด Smart Reporting ชื่อเมนูอาจแสดงเป็น 'Reports' หรือ 'Smart Reporting' ขึ้นอยู่กับเวอร์ชันที่คุณใช้
สร้างรายงานใหม่: เมื่ออยู่ใน Smart Reporting ให้เลือกสร้างรายงานใหม่ แล้วเลือกประเภท 'Report'
เลือกแหล่งข้อมูลและมุมมอง: ระบบจะแจ้งให้เลือกแหล่งข้อมูล ให้เลือกแหล่งข้อมูล AR System หลักของคุณ จากนั้นค้นหาและเลือกมุมมอง Service Request ซึ่งโดยทั่วไปอ้างอิงจากฟอร์ม SRM:Request
เพิ่มฟอร์มที่เกี่ยวข้อง (การเชื่อมตาราง): หากต้องการเก็บข้อมูลตลอดวงจรของคำขอ ให้เชื่อมฟอร์มหลัก SRM:Request กับฟอร์มที่เกี่ยวข้อง โดยใช้แท็บ 'Data' แล้วเชื่อมฟอร์มต่อไปนี้:
- SRM:WorkInfo (โดยใช้ SR ID+ = Request Number) เพื่อดึงรายละเอียดกิจกรรมการดำเนินการและบันทึกงาน
- AP:Signature (โดยใช้ Request = SRInstanceID) เพื่อดึงเหตุการณ์การอนุมัติและปฏิเสธ คุณอาจต้องสร้างการเชื่อมตารางแบบกำหนดเอง
กำหนดคอลัมน์รายงาน: ลากฟิลด์ที่ต้องการจากฟอร์มที่เชื่อมไว้ไปยังส่วน 'Columns' โดยรวมฟิลด์ Request Number, Submit Date, สถานะ, คำอธิบาย, Priority, Assigned To และ Assigned Group จาก SRM:Request รวมถึงฟิลด์ที่เกี่ยวข้องจากฟอร์มอื่น
สร้างฟิลด์คำนวณสำหรับกิจกรรม: วิธีนี้ต้องสร้างฟิลด์คำนวณหลายรายการเพื่อแทนเวลาของแต่ละกิจกรรม ไปที่แท็บ 'Data' แล้วสร้างฟิลด์คำนวณใหม่สำหรับแต่ละกิจกรรม ตัวอย่างเช่น:
- เวลาที่ส่งคำขอ: ใช้ฟิลด์ Submit Date โดยตรง
- เวลาที่อนุมัติ: ใช้ Signature Date จากฟอร์ม AP:Signature
- เวลาเริ่มดำเนินงาน: ใช้ค่า MIN(Submit Date) จาก SRM:WorkInfo โดยจัดกลุ่มตาม Request Number
จัดโครงสร้างรายงานเพื่อรวมข้อมูล: Smart Reporting ไม่มีปุ่ม 'UNION ALL' แบบ SQL หากต้องการรวมข้อมูล ให้สร้างรายงานเดียวแล้วใช้ฟังก์ชันขั้นสูงหรือคิวรีย่อยเพื่อปรับรูปแบบข้อมูล วิธีที่นิยมคือสร้างคอลัมน์คำนวณหลายคอลัมน์ โดยแต่ละคอลัมน์แทนเวลาของกิจกรรมหนึ่งรายการ จากนั้นจัดรูปแบบข้อมูลที่ส่งออกให้แต่ละกิจกรรมอยู่คนละแถว
ใช้ตัวกรอง: เพิ่มตัวกรองเพื่อจำกัดขอบเขตข้อมูลและช่วยให้รายงานทำงานได้เร็วขึ้น อย่างน้อยให้กรอง Submit Date จากฟอร์ม SRM:Request เพื่อเลือกช่วงวันที่ที่ต้องการ หากใช้ระบบแบบหลายผู้เช่า ให้เพิ่มตัวกรอง 'Company' ด้วย
เรียกใช้และตรวจสอบข้อมูลตัวอย่าง: เรียกใช้รายงานเพื่อตรวจสอบว่าดึงข้อมูลได้ถูกต้อง ตรวจสอบการเชื่อมตาราง คอลัมน์ที่มีข้อมูล และเวลาที่ฟิลด์คำนวณส่งกลับ
ส่งออกรายงาน: เมื่อตรวจสอบรายงานแล้ว ให้ส่งออกข้อมูลเป็น CSV หรือ Microsoft Excel ซึ่งนำไปเตรียมสำหรับนำเข้าเครื่องมือ process mining ได้สะดวก
ปรับรูปแบบข้อมูลขั้นสุดท้าย: หลังส่งออก ให้เปลี่ยนข้อมูลจากรูปแบบกว้าง ซึ่งมีหนึ่งแถวต่อคำขอบริการและมีหลายคอลัมน์เวลา เป็นรูปแบบยาว ซึ่งมีหนึ่งแถวต่อกิจกรรม ใช้สคริปต์ เช่น Python หรือ PowerShell หรือเครื่องมืออย่าง Excel Power Query เพื่อแปลงคอลัมน์เวลาให้เป็นสองคอลัมน์ ได้แก่ ActivityName และ EventStartTime ขั้นตอนนี้จำเป็นต่อการสร้างโครงสร้างบันทึกเหตุการณ์ตามที่ต้องการ.

การกำหนดค่า

สิ่งที่ต้องมี: คุณต้องมีบัญชีผู้ใช้ที่มีสิทธิ์รายงานใน BMC Helix ITSM โดยเฉพาะสิทธิ์สร้างและเรียกใช้รายงานใน Smart Reporting นอกจากนี้ยังต้องมีสิทธิ์อ่านข้อมูลจากฟอร์ม SRM:Request, SRM:WorkInfo และ AP:Signature.
ฟอร์มหลัก: รายงานสร้างจากการ join ฟอร์มหลักต่อไปนี้:
- SRM:Request: ฟอร์มหลักที่มีรายละเอียดคำขอบริการ.
- SRM:WorkInfo: มีรายการบันทึกงาน ซึ่งใช้ระบุกิจกรรมการดำเนินการ.
- AP:Signature: มีบันทึกการอนุมัติ ซึ่งจำเป็นต่อการติดตามกิจกรรมเกี่ยวกับการอนุมัติ.
การกรองช่วงวันที่: กรองช่วงวันที่จากฟิลด์ SRM:Request.Submit Date ทุกครั้ง แนะนำให้ใช้ข้อมูลย้อนหลัง 3 ถึง 6 เดือน เพื่อให้ได้ตัวอย่างที่เป็นตัวแทนและรายงานยังทำงานได้ดี.
ตัวกรองสำคัญ: นอกจากช่วงวันที่แล้ว ให้กรองตาม Company เพื่อแยกข้อมูลของหน่วยธุรกิจที่ต้องการ คุณอาจกรองประเภทคำขอหรือสถานะที่ไม่เกี่ยวข้องกับการวิเคราะห์ออกด้วย เช่น 'Draft'.
ข้อควรพิจารณาด้านประสิทธิภาพ: รายงานที่ join หลายฟอร์มและใช้ช่วงวันที่กว้างอาจสร้างช้า หากมีข้อมูลจำนวนมาก แนะนำให้ตั้งเวลารายงานไว้นอกช่วงเวลาที่มีการใช้งานสูง หากหมดเวลา ให้แบ่งการดึงข้อมูลเป็นช่วงย่อยรายเดือน.

ตัวอย่างคำค้น sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

ขั้นตอน

สิ่งที่ต้องมี: เตรียมโปรแกรมเชื่อมต่อฐานข้อมูล เช่น DBeaver, SQL Server Management Studio หรือ Oracle SQL Developer และข้อมูลเข้าสู่ระบบแบบอ่านอย่างเดียวสำหรับฐานข้อมูล BMC Helix AR System.
เชื่อมต่อฐานข้อมูล: ใช้โปรแกรมเชื่อมต่อฐานข้อมูลเพื่อเชื่อมต่อกับเซิร์ฟเวอร์ฐานข้อมูล AR System.
เตรียม Query: คัดลอก SQL query ฉบับเต็มจากส่วน 'Query' ในเอกสารนี้ไปยังตัวแก้ไข query ของโปรแกรมเชื่อมต่อฐานข้อมูล.
กำหนดพารามิเตอร์: ค้นหาค่าตัวแทนใน query แล้วแทน :start_date และ :end_date ด้วยช่วงวันที่ที่ต้องการดึงข้อมูล เช่น '2023-01-01' และ '2023-12-31' หากต้องการกรองตามบริษัท ให้แทน :company_name ด้วยชื่อบริษัทนั้น.
เรียกใช้ Query: เรียกใช้ SQL query ที่แก้ไขแล้ว ระยะเวลาอาจใช้หลายนาที ขึ้นอยู่กับช่วงวันที่และขนาดระบบ.
ตรวจสอบผลลัพธ์: เมื่อ query ทำงานเสร็จ ระบบจะแสดงชุดผลลัพธ์ที่มีบันทึกเหตุการณ์ ตรวจสอบคร่าวๆ ว่าข้อมูลครบถ้วนและมีคอลัมน์กับกิจกรรมตามที่ต้องการ.
จัดการการประทับเวลา: ตรวจสอบว่าคอลัมน์เวลาทั้งหมด โดยเฉพาะ EventStartTime, EventEndTime และ LastDataUpdate ใช้รูปแบบเดียวกัน เช่น 'YYYY-MM-DD HH:MI:SS' หากฐานข้อมูลแสดงผลเป็นรูปแบบอื่น ให้ปรับฟังก์ชัน TO_CHAR หรือ CONVERT ใน query ให้เหมาะสม.
ส่งออกข้อมูล: ใช้ฟังก์ชันส่งออกของโปรแกรมเชื่อมต่อฐานข้อมูลเพื่อบันทึกชุดผลลัพธ์ทั้งหมดเป็นไฟล์ CSV เลือกการเข้ารหัส UTF-8 เพื่อให้ใช้งานร่วมกับระบบอื่นได้.
เตรียมไฟล์สำหรับอัปโหลด: ตั้งชื่อไฟล์ให้สื่อความหมาย เช่น servicerequest_eventlog.csv จากนั้นอัปโหลดไฟล์นี้ไปยังแพลตฟอร์ม ProcessMind ได้.

การกำหนดค่า

ข้อมูลเข้าสู่ระบบฐานข้อมูล: ต้องใช้บัญชีผู้ใช้แบบอ่านอย่างเดียวสำหรับฐานข้อมูล AR System เพื่อป้องกันการแก้ไขข้อมูลโดยไม่ตั้งใจและให้เป็นไปตามแนวทางความปลอดภัยที่ดี.
การกรองช่วงวันที่: Query มีค่าตัวแทน :start_date และ :end_date ควรกำหนดช่วงวันที่ให้ชัดเจนและเหมาะสม โดยทั่วไปใช้ข้อมูลย้อนหลัง 3 ถึง 12 เดือน เพื่อควบคุมประสิทธิภาพของ query และปริมาณข้อมูล ระบบจะกรองตาม Submit_Date ของคำขอบริการ.
ตัวกรองบริษัท: มีค่าตัวแทน :company_name สำหรับกรองคำขอตามบริษัทที่ดำเนินงาน หากต้องการดึงข้อมูลทุกบริษัท ให้ลบบรรทัด AND req.Company = :company_name หรือกำหนดเป็น wildcard หากระบบรองรับ.
ค่าสถานะ: Query ใช้ค่าจำนวนเต็มมาตรฐานของสถานะใน BMC Helix ITSM เช่น Submitted = 0, In Review = 1 เป็นต้น ระบบของคุณอาจมีสถานะที่กำหนดเองหรือใช้ค่าจำนวนเต็มต่างกัน ให้ตรวจสอบค่าจากฟอร์ม SYS:Status หรือ developer studio แล้วปรับส่วน WHERE ใน query หากจำเป็น.
ประสิทธิภาพ: การ query ฐานข้อมูลโดยตรงจากตารางขนาดใหญ่ เช่น SRM_Request และบันทึกการตรวจสอบ อาจใช้ทรัพยากรมาก ควรกำหนดเวลาการดึงข้อมูลไว้นอกช่วงเวลาที่มีการใช้งานสูง เพื่อลดผลกระทบต่อประสิทธิภาพของระบบ.

ตัวอย่างคำค้น sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

ขั้นตอน

ข้อกำหนดเบื้องต้น: ตรวจสอบว่าระบบของคุณติดตั้ง Python 3.6 ขึ้นไปแล้ว ติดตั้งไลบรารี requests ซึ่งจำเป็นสำหรับเรียก HTTP API โดยรัน pip install requests ในเทอร์มินัลหรือพรอมต์คำสั่ง
เตรียมข้อมูลรับรอง API: สร้างหรือขอข้อมูลรับรองสำหรับบัญชีบริการเฉพาะใน BMC Helix ITSM บัญชีนี้ต้องมีสิทธิ์อ่านอย่างเดียวเป็นอย่างน้อยสำหรับฟอร์ม SRM:Request และฟอร์มบันทึกการตรวจสอบที่เกี่ยวข้อง ซึ่งมักใช้ชื่อ SRM:Request_AuditLog หรือชื่อใกล้เคียง จดชื่อผู้ใช้ รหัสผ่าน และ URL หลักของอินสแตนซ์ BMC Helix ของคุณไว้ (เช่น https://[your-company].bmc.com)
ตั้งค่าสคริปต์ Python: คัดลอกสคริปต์ Python ที่ให้มาไปไว้ในไฟล์ เช่น extract_servicerequests.py จากนั้นแก้ไขสคริปต์และใส่ค่าตัวแปรที่กำหนดไว้ด้านบน ได้แก่ BASE_URL, USERNAME, PASSWORD และ AUDIT_FORM_NAME ปรับพจนานุกรม STATUS_ACTIVITY_MAP ให้ตรงกับค่าของสถานะที่ใช้ในเวิร์กโฟลว์คำขอบริการขององค์กร
กำหนดช่วงเวลาที่ต้องการดึงข้อมูล: แก้ไขตัวแปร START_DATE และ END_DATE ในสคริปต์ เพื่อกำหนดช่วงเวลาที่จะดึงข้อมูลโดยอิงจากวันที่ส่งคำขอบริการ หากต้องการทดสอบเบื้องต้น ให้เลือกช่วงวันที่สั้นๆ เช่น 1 วัน
เรียกใช้สคริปต์: รันสคริปต์จากเทอร์มินัลด้วยคำสั่ง python extract_servicerequests.py สคริปต์จะยืนยันตัวตนกับ API ก่อนเพื่อรับโทเค็น
ดึงข้อมูลเบื้องต้น: สคริปต์จะค้นหาข้อมูลในฟอร์ม SRM:Request เพื่อดึงรายการคำขอบริการทั้งหมดที่สร้างขึ้นในช่วงวันที่ระบุ ขั้นตอนนี้จะรวบรวมรหัสเคสและคุณลักษณะคงที่ที่เกี่ยวข้อง เช่น ลำดับความสำคัญและประเภทบริการ
ดึงประวัติเหตุการณ์: สคริปต์จะวนตรวจสอบรหัสคำขอบริการแต่ละรายการที่ได้จากขั้นตอนก่อนหน้า แล้วเรียก API อีกครั้งสำหรับแต่ละรหัส เพื่อดึงประวัติการเปลี่ยนสถานะโดยละเอียดจากฟอร์มบันทึกการตรวจสอบที่กำหนดไว้
แปลงข้อมูลเป็นบันทึกเหตุการณ์: สำหรับแต่ละระเบียนจากบันทึกการตรวจสอบ สคริปต์จะแปลงการเปลี่ยนสถานะเป็นชื่อกิจกรรมมาตรฐานโดยใช้ STATUS_ACTIVITY_MAP และสร้างแถวสำหรับแต่ละกิจกรรมที่แปลงแล้ว โดยระบุรหัสคำขอบริการ ชื่อกิจกรรม และเวลาที่มีการเปลี่ยนแปลง
สร้างเหตุการณ์ส่งคำขอ: สคริปต์จะสร้างกิจกรรมเริ่มต้น 'ส่งคำขอบริการแล้ว' สำหรับคำขอแต่ละรายการ โดยใช้ค่า Submit Date จากฟอร์ม SRM:Request หลัก
ส่งออกเป็น CSV: หลังประมวลผลคำขอบริการและประวัติทั้งหมดแล้ว สคริปต์จะรวมแถวที่สร้างขึ้นเป็นรายการเดียวและเขียนข้อมูลลงในไฟล์ CSV ชื่อ servicerequest_event_log.csv ซึ่งจัดรูปแบบพร้อมอัปโหลดไปยังเครื่องมือ process mining.

การกำหนดค่า

API Endpoints: Script ใช้ API endpoint หลักสองรายการ โดยยืนยันตัวตนผ่าน api/jwt/login และ query ข้อมูลจาก arsys/v1/entry/SRM:Request เพื่อดึงรายการเคส และ arsys/v1/entry/[AUDIT_FORM_NAME] เพื่อดึงประวัติเหตุการณ์.
สิทธิ์ของบัญชีบริการ: ต้องมีบัญชีบริการเฉพาะที่อ่านข้อมูลจากฟอร์ม SRM:Request และฟอร์มบันทึกการตรวจสอบของระบบได้ การใช้บัญชีบริการจำเป็นต่อความปลอดภัยและการตรวจสอบย้อนหลัง.
การกรองช่วงวันที่: Script กรองคำขอบริการตาม Submit Date แนะนำให้ดึงข้อมูลเป็นชุดที่จัดการได้ เช่น ครั้งละ 3-6 เดือน เพื่อให้ทำงานได้อย่างเสถียร.
การจับคู่สถานะกับกิจกรรม: พจนานุกรม STATUS_ACTIVITY_MAP ใน script เป็นส่วนหลักของการแปลงข้อมูล ต้องกำหนดค่าให้ตรงกับสถานะที่องค์กรใช้และจับคู่กับชื่อกิจกรรมที่ต้องการ สถานะใดในเวิร์กโฟลว์ที่ไม่มีในแผนที่จะถูกละเว้น.
ฟอร์มบันทึกการตรวจสอบ: การดึงรายละเอียดกิจกรรมของ script ขึ้นอยู่กับว่ามีบันทึกการตรวจสอบที่ query ได้หรือไม่ คุณต้องระบุชื่อฟอร์มที่เก็บประวัติการเปลี่ยนสถานะของคำขอบริการในระบบ แล้วปรับตัวแปร AUDIT_FORM_NAME ให้ตรงกัน.
การแบ่งหน้า: Script จัดการการแบ่งหน้า API โดยอัตโนมัติเพื่อดึงข้อมูลทั้งหมด พารามิเตอร์ limit ใน API call กำหนดให้ดึงข้อมูลครั้งละ 1000 รายการ เพื่อรักษาสมดุลระหว่างประสิทธิภาพกับการใช้หน่วยความจำ.

ตัวอย่างคำค้น python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

if __name__ == class="hl-string">"__main__":
    main()

พร้อมเริ่มต้นหรือยัง?

ใช้เทมเพลตนี้เพื่อจัดระเบียบการรวบรวมข้อมูลและเริ่มต้นทำ process mining ได้อย่างมั่นใจ เริ่มปรับปรุงการจัดการคำขอบริการของคุณได้วันนี้!

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

เพิ่มประสิทธิภาพการจัดการคำขอบริการ เริ่มปรับปรุงได้วันนี้

ทำระบบอัตโนมัติให้ได้ 70% ลดความล่าช้าในการดำเนินการ และสร้างประสบการณ์ที่ดีให้ผู้ใช้.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มต้นได้ในไม่กี่นาที.

เทมเพลตข้อมูลการจัดการคำขอบริการ

เทมเพลตข้อมูลการจัดการคำขอบริการ

แอตทริบิวต์การจัดการคำขอบริการ

กิจกรรมในการจัดการคำขอบริการ

คู่มือการดึงข้อมูล

Smart Reporting ใน BMC Helix ITSM สำหรับคำขอบริการ

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น sql

ใช้ SQL Query โดยตรงกับตารางฐานข้อมูล AR System

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น sql

ดึงข้อมูลด้วย Python Script ผ่าน BMC Helix REST API

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น python

พร้อมเริ่มต้นหรือยัง?

เพิ่มประสิทธิภาพการจัดการคำขอบริการ เริ่มปรับปรุงได้วันนี้