คู่มือกำหนดขอบเขตระบบอัตโนมัติ

BPA เทียบกับ RPA: มุ่งผลลัพธ์หรือมุ่งคลิก

ใช้ BPA เพื่อประสานผลลัพธ์ทางธุรกิจตั้งแต่ต้นจนจบ และใช้ RPA ทำงานซ้ำบนหน้าจอเมื่อไม่มี API หรือการเชื่อมต่อโดยตรง

ทางเลือกนี้ไม่ใช่เรื่องยึดติดเทคโนโลยี กระบวนการธุรกิจหนึ่งอาจใช้บอต RPA ในบางขั้น ขณะที่ระบบกระบวนการยังคงดูแลกรณี ผู้รับผิดชอบ การตัดสินใจ ข้อยกเว้น และผลลัพธ์

เริ่มด้วยแผน Free ของ Jodoo สำหรับผู้ใช้สูงสุด 5 คน โดยไม่ต้องใช้บัตรเครดิต

  • เปรียบเทียบขอบเขตและความรับผิดชอบแบบเคียงข้างกัน
  • แบบทดสอบความเหมาะสมสำหรับสถานการณ์ที่พบบ่อย
  • สถาปัตยกรรมร่วมสำหรับบอตที่ทำงานภายในกระบวนการ
  • คำถามด้านความล้มเหลวและการกำกับดูแลก่อนเริ่มใช้งาน
การตัดสินใจด้านสถาปัตยกรรม
  1. 01ผลลัพธ์
  2. 02งาน
  3. 03หน้าจอระบบ
  4. 04การควบคุม
  5. 05ความล้มเหลว
  6. 06ความรับผิดชอบ
  7. 07ตัวชี้วัด
ทดสอบสถาปัตยกรรมอย่างรวดเร็ว

เลือกชั้นที่เปราะบางน้อยที่สุดและทำงานจนจบได้

ต้องจัดการกรณีและผลลัพธ์ที่มีผู้รับผิดชอบหรือไม่เลือก BPA
ต้องทำงานซ้ำบนหน้าจอที่มีรูปแบบคงที่หรือไม่ใช้ RPA เมื่อไม่มี API ที่ใช้งานได้จริง
ต้องแลกเปลี่ยนข้อมูลระหว่างระบบแบบมีการกำกับดูแลหรือไม่เลือก API หรือตัวเชื่อมต่อที่รองรับก่อน
ต้องใช้ทั้งสามแบบหรือไม่ให้ BPA เป็นเจ้าของกรณี แล้วคืนผลจากบอตและการเชื่อมต่อกลับมาที่ BPA
ความแตกต่างหลัก

BPA ประสานกรณี ส่วน RPA ทำงานบนหน้าจอระบบ

ทั้งสองแบบทำให้งานเป็นอัตโนมัติ แต่ดูแลคนละชั้นของรูปแบบการดำเนินงาน

ระบบอัตโนมัติสำหรับกระบวนการธุรกิจ

จัดการจุดเริ่มต้น กรณี ผู้เกี่ยวข้อง ขั้นตอนงาน การตัดสินใจ ระดับบริการ ข้อยกเว้น การสื่อสาร หลักฐาน และผลลัพธ์สุดท้ายข้ามหลายระบบ

ระบบอัตโนมัติด้วยหุ่นยนต์ซอฟต์แวร์

ใช้บอตซอฟต์แวร์ทำงานซ้ำบนหน้าจอ เช่น เปิดแอป อ่านช่องข้อมูล ป้อนข้อมูล ดาวน์โหลดไฟล์ หรือย้ายข้อมูล

เปรียบเทียบแบบเคียงข้างกัน

เปรียบเทียบขอบเขต ผู้รับผิดชอบ การเปลี่ยนแปลง และความล้มเหลวก่อนเลือก

โครงการระบบอัตโนมัติเดียวกันอาจต้องใช้ทั้งสองชั้น แต่ไม่ควรสับสนหน้าที่ของแต่ละชั้น

หน่วยของงาน

BPA จัดการกรณีหรือผลลัพธ์ทางธุรกิจ ส่วน RPA มักทำงานขอบเขตแคบหรือลำดับการโต้ตอบกับหน้าจอ

ผู้รับผิดชอบหลัก

BPA ต้องมีเจ้าของกระบวนการและรูปแบบผู้เกี่ยวข้อง ส่วน RPA ต้องมีเจ้าของบอต รวมถึงผู้ดูแลแอป ข้อมูลรับรอง และการทำงานของบอต

ความเสี่ยงจากการเปลี่ยนแปลง

BPA เปลี่ยนตามนโยบาย บทบาท ข้อมูล หรือผลลัพธ์ ส่วน RPA อาจหยุดทำงานเมื่อหน้าจอ ป้ายชื่อ เค้าโครง สิทธิ์ หรือจังหวะเวลาเปลี่ยน

การจัดการเมื่อเกิดความล้มเหลว

BPA ส่งกรณีที่มีข้อยกเว้นไปจัดการ ส่วน RPA รายงานว่ารอบทำงานล้มเหลว กระบวนการที่ครอบอยู่ต้องตัดสินใจว่าใครจะกู้คืนผลลัพธ์ทางธุรกิจ

แบบทดสอบความเหมาะสม

เลือก BPA, RPA, การเชื่อมต่อโดยตรง หรือใช้ร่วมกัน

ใช้วิธีที่เปราะบางน้อยที่สุด ซึ่งทำตามข้อกำหนดทางธุรกิจจนเสร็จและทำให้การกู้คืนมองเห็นได้

เลือก BPA

ใช้กับกรณีข้ามทีม การอนุมัติ การส่งมอบบริการ การจัดการข้อยกเว้น ประวัติตรวจสอบ งานตามบทบาท และแดชบอร์ดผลลัพธ์

เลือก RPA

ใช้กับงานบนหน้าจอที่มีกฎชัด ปริมาณมาก และรูปแบบคงที่ เมื่อระบบเป้าหมายไม่มี API หรือช่องทางเชื่อมต่อที่ใช้ได้จริง

เลือกการเชื่อมต่อโดยตรง

เลือก API เหตุการณ์ ฐานข้อมูล หรือตัวเชื่อมต่อที่รองรับก่อน หากทำงานกับระบบได้อย่างน่าเชื่อถือ มีการกำกับดูแล และคุ้มค่า

ใช้ร่วมกัน

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

สถาปัตยกรรมแบบใช้ร่วมกัน

ให้บอตอยู่ภายในขอบเขตการควบคุมของกระบวนการ

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

01

เตรียมพร้อม

ตรวจสอบกรณี ข้อมูลที่ต้องใช้ การอนุญาต ระบบเป้าหมาย และกฎป้องกันการทำซ้ำก่อนเริ่มบอต

02

ดำเนินการ

ให้บอตใช้สิทธิ์และบริบทเท่าที่จำเป็น บันทึกรหัสรอบทำงาน และเก็บผลลัพธ์กับหลักฐานในรูปแบบที่มีโครงสร้าง

03

กระทบยอด

อัปเดตกระบวนการหลังยืนยันผลในระบบเป้าหมายเท่านั้น ส่งกรณีข้อมูลไม่ตรง หมดเวลา สำเร็จบางส่วน หรือเสี่ยงทำซ้ำไปยังคิวกู้คืน

การกำกับดูแล

กำกับเวอร์ชันกระบวนการและสิ่งที่บอตพึ่งพาไปพร้อมกัน

หน้าจอที่เปลี่ยนอาจส่งผลรุนแรงเท่ากับเกณฑ์อนุมัติที่เปลี่ยน หากทำให้กระบวนการสำคัญหยุดลง

01

จัดทำรายการ

เชื่อมบอตแต่ละตัวกับขั้นตอนกระบวนการ แอป หน้าจอ ข้อมูลรับรอง ตารางเวลา ผู้รับผิดชอบ เป้าหมายบริการ และวิธีกู้คืน

02

ทดสอบ

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

03

เฝ้าติดตาม

ติดตามความสำเร็จของรอบ การลองใหม่ การกระทบยอดทางธุรกิจ การกู้คืนด้วยคน ผลต่อคิวงานค้าง และผลลัพธ์กระบวนการ

ทดสอบคุณค่า

วัดกระบวนการที่เสร็จสมบูรณ์ ไม่ใช่จำนวนคลิกที่ลดลง

การใช้งานบอตและความเร็วของงานอาจสูงขึ้น ขณะที่กรณียังค้างในจุดอื่นหรือภาระกู้คืนเพิ่มขึ้น

ระยะเวลารวมจนได้ผลลัพธ์

วัดกรณีตั้งแต่จุดเริ่มต้นจนยืนยันว่าเสร็จ ครอบคลุมงานของคน ระบบ และบอต

อัตราสำเร็จโดยไม่ต้องแทรกแซง

ติดตามกรณีที่เสร็จโดยไม่ต้องซ่อมด้วยคน แก้ข้อมูลซ้ำ กระทบยอด หรือตรวจข้อยกเว้น

แรงงานในการกู้คืน

วัดเวลาที่ใช้สืบหาความล้มเหลว ซ่อมการอัปเดตบางส่วน รันงานใหม่ และสื่อสารความล่าช้า

ความทนทานต่อการเปลี่ยนแปลง

นับความล้มเหลวและงานบำรุงที่เกิดจากการเปลี่ยนแอป หน้าจอ นโยบาย ข้อมูลรับรอง ข้อมูล และกระบวนการ

คำถามด้านสถาปัตยกรรม

BPA, RPA และการเชื่อมต่อโดยตรงเหมาะกับจุดใด

BPA กับ RPA ต่างกันหลัก ๆ อย่างไร+

BPA ประสานผลลัพธ์ทางธุรกิจตั้งแต่ต้นจนจบผ่านระเบียน ผู้คน การตัดสินใจ ระบบ ข้อยกเว้น และตัวชี้วัด ส่วน RPA ทำงานซ้ำผ่านหน้าจอของแอป โดยมักเป็นหนึ่งขั้นในกระบวนการที่กว้างกว่า

ใช้ BPA และ RPA ร่วมกันได้หรือไม่+

ได้ แอป BPA เป็นเจ้าของกรณีและสั่งบอต RPA ทำงานในระบบเดิม บอตควรคืนผลลัพธ์ที่มีโครงสร้าง หลักฐาน และสถานะล้มเหลว เพื่อให้กระบวนการเดินหน้าหรือส่งไปกู้คืน

RPA ดีกว่าการเชื่อมต่อ API หรือไม่+

ใช้ API หรือตัวเชื่อมต่อที่รองรับเมื่อมีความน่าเชื่อถือ มีการกำกับดูแล และคุ้มค่า RPA มีประโยชน์เมื่อระบบจำเป็นไม่มีช่องทางเชื่อมต่อที่ใช้ได้จริง แต่การเปลี่ยนหน้าจอและการทำงานสำเร็จเพียงบางส่วนต้องมีการติดตามและกู้คืนอย่างรอบคอบ

Jodoo มี RPA ในตัวหรือไม่+

Jodoo ใช้สร้างแอปกระบวนการ ระเบียน แบบฟอร์ม Workflow กฎ แดชบอร์ด และการควบคุมงาน หากต้องใช้บอตบนหน้าจอ ให้เชื่อมบริการ RPA ที่เลือก และเก็บสถานะรอบบอตกับการกู้คืนไว้ในกระบวนการ Jodoo

ควรจัดการความล้มเหลวของบอตอย่างไร+

อย่าปล่อยไว้ในบันทึกทางเทคนิค ให้เชื่อมความล้มเหลวกับกรณีธุรกิจ เก็บการดำเนินการที่ลองทำและผลลัพธ์บางส่วน มอบหมายผู้รับผิดชอบการกู้คืน ป้องกันการรันซ้ำที่ไม่ปลอดภัย และยืนยันผลลัพธ์ทางธุรกิจภายหลัง

ใช้งานผลิตภัณฑ์จริง

ให้มองเห็นกรณีธุรกิจรอบทุกขั้นตอนอัตโนมัติ

สำรวจมุมมองข้อยกเว้น รอบทำงาน การตัดสินใจ และกรณี ซึ่งช่วยให้กระบวนการกู้คืนได้เมื่อการเชื่อมต่อหรือบอตทำงานไม่จบ

ดูชั้นควบคุมกระบวนการ