บอทระบบอัตโนมัติของคุณไม่ได้ล้มเหลว แต่ข้อมูลของคุณต่างหาก

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

TrueFocus Automation บริษัท RPA และระบบอัตโนมัติ AI ที่ตั้งอยู่ในดัลลาส ซึ่งเชี่ยวชาญด้านการประกันกรรมสิทธิ์และการดำเนินงานสินเชื่อที่อยู่อาศัย ได้เผชิญกับสิ่งนี้โดยตรง หลังจากสร้างบอตสำหรับระบบ title plant ที่เป็นกรรมสิทธิ์ของลูกค้า ระบบอัตโนมัติทำงานได้ดีจนกระทั่งไม่สามารถทำงานได้ กระบวนการดูเหมือนจะทำงานได้อย่างถูกต้อง ทีมของลูกค้าไม่ได้แสดงความกังวล จากนั้น ทีมปฏิบัติการใหม่เข้ามาและเริ่มถามว่าทำไมเอกสารบางฉบับถึงไม่ปรากฏในผลการค้นหา

คำตอบไม่ใช่ข้อบกพร่องในตัวบอต แต่เป็นการจัดทำดัชนีข้อมูลที่ไม่สม่ำเสมอมานานหลายทศวรรษ

ปัญหาที่ซ่อนอยู่ในระบบเดิม

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

ลูกค้ารายดังกล่าวได้ทำการจัดทำดัชนีบันทึก title plant ด้วยตนเองมาเป็นเวลาประมาณสามสิบปี ในช่วงเวลานั้น วิธีการบันทึกข้อมูลเหล่านั้นได้เปลี่ยนแปลงไป รูปแบบการตั้งชื่อเอกสารไม่สม่ำเสมอและมีการอ้างอิงถึง Deed ในรูปแบบต่างกัน เช่น DEED22W/1774 และบางรายการจัดทำดัชนีเป็น 22/1774, D22-1774, D22W-1774 เมื่อ TrueFocus สร้างบอตที่ค้นหาด้วยหมายเลขเอกสาร มันจะแสดงเฉพาะบันทึกที่จัดทำดัชนีในรูปแบบหนึ่ง และพลาดทุกอย่างที่ถูกบันทึกภายใต้สคีมาที่แตกต่างกันในปีก่อนๆ

Sridhar Loganathan ซีโอโอของ TrueFocus Automation อธิบายรูปแบบนี้ว่า: "ข้อมูลที่อยู่เบื้องหลังนั้นไม่สม่ำเสมอ ในช่วงสามสิบปีนั้น พวกเขาเปลี่ยนวิธีการจัดทำดัชนีเอกสาร เมื่อเราสร้างบอตที่ค้นหาโดยใช้หมายเลขเอกสาร มีเพียงเอกสารเหล่านั้นที่ปรากฏขึ้น ไม่ใช่เอกสารอื่นๆ"

บอตกำลังทำในสิ่งที่ถูกสร้างมาเพื่อทำ ข้อมูลที่อยู่เบื้องหลังนั้นไม่เคยสม่ำเสมอตั้งแต่ต้น

ความพร้อมของข้อมูลหมายความว่าอะไรจริงๆ ก่อนที่คุณจะทำระบบอัตโนมัติ

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

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

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

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

ปัญหาการมีส่วนร่วมของลูกค้าที่ทำให้สิ่งต่างๆ แย่ลง

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

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

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

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

กระบวนการค้นพบที่ซื่อสัตย์มีลักษณะอย่างไร

สำหรับบริษัทที่ประเมินผู้จำหน่ายระบบอัตโนมัติ ความเต็มใจที่จะนำปัญหาขึ้นมาก่อนเริ่มโปรเจกต์ มากกว่าหลังการส่งมอบ เป็นหนึ่งในสิ่งที่มีประโยชน์มากที่สุดที่ผู้จำหน่ายสามารถเสนอได้

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

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

Jimmy Lewis เป็นผู้ร่วมก่อตั้ง TrueFocus Automation ผู้เชี่ยวชาญด้าน RPA และระบบอัตโนมัติเวิร์กโฟลว์ที่ขับเคลื่อนด้วย AI สำหรับอุตสาหกรรมประกันกรรมสิทธิ์ สินเชื่อที่อยู่อาศัย และอสังหาริมทรัพย์ TrueFocus ได้พัฒนาบอตระบบอัตโนมัติมากกว่า 840 ตัวที่รองรับเวิร์กโฟลว์มากกว่า 2,500 รายการ และคืนชั่วโมงการผลิตมากกว่า 1.3 ล้านชั่วโมงให้กับลูกค้า

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