สิทธิ์เข้าถึงระบบธุรกิจ
รับชื่อระบบ บทบาท เหตุผล และวันหมดอายุ ผู้ตรวจสอบอนุมัติ ผู้ดูแลให้สิทธิ์ในระบบจริงและบันทึกผล การเปลี่ยนสถานะในแอปไม่ได้สร้างบัญชี
สร้างกระบวนการคำขอบริการ
กำหนดสิ่งที่พนักงานควรได้รับ แล้ววางแผนข้อมูล การอนุมัติ งานส่งมอบ และการยืนยันให้เกิดผล
สำรวจด้วยข้อมูลตัวอย่าง ปรับฟิลด์ มุมมอง และเวิร์กโฟลว์ให้ทีม
เขียนบริการที่ตั้งใจจะส่งมอบ
| การตัดสินใจ | นโยบายตัวอย่าง | ข้อผิดพลาดที่ควรหลีกเลี่ยง |
|---|---|---|
| ผลลัพธ์ | แล็ปท็อปและโต๊ะพร้อมให้พนักงานใช้ | อย่าถือว่าคำขอเสร็จเมื่อเพียงอนุมัติใบสั่งซื้อ |
| บริบทที่ต้องมี | เหตุผลทางธุรกิจ สถานที่ วันที่ และข้อกำหนดอุปกรณ์ | รับข้อเท็จจริงที่เปลี่ยนการตัดสินใจ ไม่ใช่ทุกฟิลด์สินทรัพย์ |
| การอนุมัติ | ผู้ตรวจสอบอุปกรณ์ที่กำหนด | การอนุมัติอนุญาตข้อผูกพัน แต่ไม่ได้พิสูจน์ว่าส่งมอบจริง |
| งานส่งมอบ | เตรียมแล็ปท็อป ส่งแท่นเชื่อมต่อ | แต่ละงานต้องมีเจ้าของและรายละเอียดเมื่อเสร็จ |
| การยืนยันรับมอบ | พนักงานยืนยันผลส่งมอบทั้งสองรายการ | งานที่ไม่เสร็จหรือถูกบล็อกทำให้ยืนยันขั้นสุดท้ายไม่ได้ |
สร้างกระบวนการรอบการตัดสินใจ
แยกคำขอออกจากปัญหาที่ไม่คาดคิด
“จัดแล็ปท็อปสำหรับเปลี่ยนบทบาท” เป็นบริการที่กำหนดไว้ ส่วน “แล็ปท็อปเดิมชาร์จไม่เข้า” เป็นปัญหาซัพพอร์ต ผู้เกี่ยวข้องอาจเหมือนกัน แต่ข้อมูล การตัดสินใจ และจุดจบต่างกัน
ระบุเจ้าของผลลัพธ์
กำหนดเจ้าของบริการที่แก้ความไม่ชัดเจนระหว่างทีม เจ้าของงานทำส่วนของตน ส่วนเจ้าของบริการรับผิดชอบคำขอและผลลัพธ์ทั้งหมด
ขออนุมัติเฉพาะเมื่อเปลี่ยนการตัดสินใจ
ค่าใช้จ่าย สิทธิ์ หรือข้อยกเว้นอาจต้องตรวจโดยคน แต่งานประจำความเสี่ยงต่ำอาจไม่ต้อง อย่าเพิ่มพิธีอนุมัติที่ล่าช้าโดยไม่สร้างการควบคุม
ทำให้ข้อมูลไม่ครบแก้ไขได้
ผู้ตรวจสอบต้องส่งกลับพร้อมระบุสิ่งที่ขาดและรับฉบับแก้ อย่าลบการตัดสินใจเดิมหรือเปลี่ยนการปฏิเสธเป็นการแก้ฟิลด์เงียบ ๆ
กำหนดว่าอะไรถือว่าส่งมอบแล้ว
ระบุงานบังคับและหลักฐานที่เจ้าของแต่ละคนบันทึก พนักงานต้องรู้ว่ากำลังยืนยันอะไร งานหนึ่งที่เสร็จห้ามซ่อนงานพึ่งพาที่ยังเปิด
คำขอต่างกันต้องจัดการต่างกัน
จอห้องประชุมเสีย
นี่คือปัญหาที่ไม่คาดคิด ไม่ใช่การซื้อจากแค็ตตาล็อก รับห้องและผลกระทบ มอบหมายผู้ดูแล บันทึกการวินิจฉัยกับการรอ และยืนยันว่าจอกลับมาใช้ได้
เริ่มใช้งานบริการหนึ่งรายการให้ครบก่อน
เริ่มจากบริการเดียวและเคสที่สมจริง
ใช้คำขอประจำ คำขอที่ต้องอนุมัติ การส่งมอบบางส่วน การส่งกลับ และการส่งมอบครบ ถามเจ้าของบริการว่าทุกเคสนำไปสู่ขั้นตอนถูกต้องหรือไม่
ตรวจงานค้างก่อนเพิ่มแดชบอร์ด
ดูข้อมูลที่ขาด งานไร้เจ้าของ ตัวบล็อก และการยืนยันล่าช้า สร้างมุมมองที่ช่วยแก้สถานะเหล่านี้ จำนวนเพียงอย่างเดียวไม่บอกว่าต้องทำอะไร
ขยายด้วยขอบเขตที่ตั้งใจ
เพิ่มบริการเมื่ออธิบายข้อมูลและการส่งมอบได้ เก็บคำขอลับ การตั้งค่าทางเทคนิค และเหตุขัดข้องเฉพาะไว้ในระบบและสิทธิ์ที่ออกแบบมา
การวางแผนกระบวนการคำขอบริการ
ใครควรเป็นเจ้าของการจัดการคำขอบริการ
กำหนดเจ้าของบริการที่เข้าใจผลลัพธ์และแก้การส่งต่องานข้ามทีม งานส่งมอบแต่ละชิ้นยังต้องมีผู้รับผิดชอบ การเป็นเจ้าของแดชบอร์ดไม่เท่ากับเป็นเจ้าของบริการ
ควรออกแบบนโยบายก่อนเลือกซอฟต์แวร์หรือไม่
กำหนดอย่างน้อยผลลัพธ์ ข้อมูล ผู้อนุมัติ เจ้าของงาน และเงื่อนไขยืนยันก่อน แล้วตรวจว่าแอปทำให้การตัดสินใจและข้อยกเว้นใช้งานได้
ควรทำอย่างไรกับคำขอที่ข้อมูลไม่ครบ
ส่งกลับพร้อมคำถามเฉพาะและเก็บประวัติ ระบุว่าใครต้องแก้และเมื่อใดจึงไปต่อ อย่าปฏิเสธเพียงเพื่อเอาออกจากคิว
ทีมเล็กควรเริ่มจากตัวชี้วัดใด
เริ่มจากการตัดสินใจ: คำขอใดไม่มีเจ้าของ งานใดถูกบล็อก หรือการส่งมอบใดรอยืนยัน เพิ่มตัวชี้วัดเวลาหลังนิยามจุดเริ่ม จุดจบ ปฏิทิน และกฎรอ
ตัวอย่างส่งมอบบริการกับเฮลป์เดสก์เป็นแอปที่ซิงค์กันหรือไม่
ไม่ เป็นตัวอย่างแยกสำหรับบริการที่กำหนดและปัญหาที่ไม่คาดคิด หากต้องส่งต่องานให้กำหนดความสัมพันธ์และเจ้าของอย่างชัดเจน
เลือกขั้นตอนถัดไปให้ทีม
เปลี่ยนนโยบายบริการที่เขียนไว้ให้เป็นกระบวนการทำงาน
ใช้คำขอและงานตัวอย่างทดสอบการส่งต่องานของทีมก่อนขยายบริการ