ย้ายข้อมูลเดิมโดยไม่ต้องยุ่งยาก

การย้ายข้อมูลเดิมเป็นเรื่องยาก

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

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

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

การย้ายข้อมูลโดยทั่วไป

1. ทำให้การย้ายถิ่นเป็นโครงการที่แยกจากกัน

ในรายการตรวจสอบการปรับใช้ซอฟต์แวร์ การโยกย้ายข้อมูลไม่ใช่รายการ "ส่งออกและนำเข้า" ที่จัดการโดยเครื่องมือการย้ายข้อมูล "กดปุ่มเดียว" อันชาญฉลาดที่มีการแมปที่กำหนดไว้ล่วงหน้าสำหรับระบบเป้าหมาย

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

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

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

2. ประมาณการตามความเป็นจริง

อย่าประมาทความซับซ้อนของการย้ายข้อมูล งานที่ต้องใช้เวลานานจำนวนมากมาพร้อมกับกระบวนการนี้ ซึ่งอาจมองไม่เห็นในตอนเริ่มต้นของโครงการ

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

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

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

การใช้เครื่องมือที่ชาญฉลาด เช่น Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas และอื่นๆ สามารถลดเวลานี้ได้ โดยเฉพาะอย่างยิ่งในขั้นตอนการสร้าง

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

การประมาณค่าแรงโดยรวมที่ง่ายที่สุดคือหนึ่งวันสำหรับทุกๆ ฟิลด์ที่ย้ายจากระบบเดิม

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

การประมาณการโดยละเอียดเป็นศิลปะของมันเอง

3. ตรวจสอบคุณภาพข้อมูล

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

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

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

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

4. ดึงดูดนักธุรกิจ

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

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

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

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

“อ้อ ฉันเข้าใจแล้ว เราต้องเปลี่ยนนิดหน่อย” กลายเป็นวลีทั่วไป

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

5. มุ่งสู่โซลูชันการโยกย้ายอัตโนมัติ

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

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

ดังนั้น แม้ว่าการโยกย้ายจะเป็นกิจกรรมที่เกิดขึ้นครั้งเดียวโดยธรรมชาติ การมีการดำเนินการโดยเจ้าหน้าที่อาจทำให้การดำเนินการของคุณช้าลงอย่างมาก

การย้ายข้อมูล Salesforce

ต่อไป เราจะครอบคลุมเคล็ดลับห้าประการสำหรับการย้าย Salesforce ที่ประสบความสำเร็จ โปรดทราบว่าคำแนะนำเหล่านี้มักจะใช้ได้กับโซลูชันระบบคลาวด์อื่นๆ เช่นกัน

6. เตรียมพร้อมสำหรับการโหลดที่ยาวนาน

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

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

แต่ไม่ใช่ในคลาวด์ ในระบบคลาวด์ เราถูกจำกัดอย่างมากจากปัจจัยหลายประการ

• เวลาแฝงของเครือข่าย – ข้อมูลถูกถ่ายโอนผ่านอินเทอร์เน็ต
• เลเยอร์แอปพลิเคชันของ Salesforce – ข้อมูลจะถูกย้ายผ่านเลเยอร์หลายชั้นของ API แบบหนา จนกว่าจะลงสู่ฐานข้อมูล Oracle
• โค้ดที่กำหนดเองใน Salesforce – การตรวจสอบความถูกต้อง ทริกเกอร์ เวิร์กโฟลว์ กฎการตรวจจับการทำซ้ำ และอื่นๆ ซึ่งส่วนใหญ่จะปิดใช้งานการโหลดแบบขนานหรือจำนวนมาก

เป็นผลให้ประสิทธิภาพการโหลดสามารถเป็นพันบัญชีต่อชั่วโมง

อาจน้อยกว่าหรือมากก็ได้ ขึ้นอยู่กับสิ่งต่างๆ เช่น จำนวนช่อง การตรวจสอบความถูกต้อง และทริกเกอร์ แต่ช้ากว่าการโหลดฐานข้อมูลโดยตรงหลายเกรด

ต้องพิจารณาการลดประสิทธิภาพการทำงาน ซึ่งขึ้นอยู่กับปริมาณของข้อมูลใน Salesforce ด้วย

มีสาเหตุจากดัชนีใน RDBMS (Oracle) ที่ใช้ตรวจสอบคีย์นอก ฟิลด์เฉพาะ และการประเมินกฎการทำซ้ำ สูตรพื้นฐานจะชะลอตัวลงประมาณ 50 เปอร์เซ็นต์สำหรับทุกเกรด 10 ซึ่งเกิดจาก O(logN) ส่วนความซับซ้อนของเวลาในการจัดเรียงและการดำเนินการ B-tree

นอกจากนี้ Salesforce ยังมีข้อจำกัดการใช้ทรัพยากรมากมาย

หนึ่งในนั้นคือขีดจำกัด Bulk API ที่ตั้งค่าเป็น 5,000 ชุดในกรอบเวลาต่อเนื่อง 24 ชั่วโมง โดยมีระเบียนสูงสุด 10,000 รายการในแต่ละชุดงาน

ดังนั้น ค่าสูงสุดตามทฤษฎีคือ 50 ล้านระเบียนที่โหลดใน 24 ชั่วโมง

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

สิ่งนี้มีผลกระทบอย่างมากต่อแนวทางการย้ายข้อมูล

แม้แต่ชุดข้อมูลขนาดกลาง (จาก 100,000 ถึง 1 ล้านบัญชี) แนวทางบิ๊กแบงก็ไม่เป็นปัญหา ดังนั้นเราต้องแยกข้อมูลออกเป็นคลื่นการย้ายถิ่นที่มีขนาดเล็กลง

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

เราต้องพิจารณาข้อมูลที่มีอยู่นี้ในการแปลงและการตรวจสอบการย้ายข้อมูล

นอกจากนี้ การโหลดที่ยาวนานอาจหมายความว่าเราไม่สามารถทำการย้ายข้อมูลระหว่างที่ระบบหยุดทำงาน

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

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

และนั่นอาจไม่เพียงพอ ดังนั้น เราต้องโหลด ขณะออนไลน์ เมื่อผู้ใช้ทำงานกับระบบ

7. เคารพความต้องการในการโยกย้ายถิ่นฐานในการพัฒนาแอปพลิเคชัน

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

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

เคล็ดลับอีกประการหนึ่งคือการใช้ฟิลด์ Legacy ID หรือ Migration ID ในทุกอ็อบเจ็กต์ที่ย้ายข้อมูล มีสองเหตุผลสำหรับเรื่องนี้ ประการแรกชัดเจน: เพื่อป้องกันไม่ให้ ID จากระบบเก่าสำหรับการย้อนรอย; หลังจากที่ข้อมูลอยู่ในระบบใหม่แล้ว ผู้คนอาจยังต้องการค้นหาบัญชีของตนโดยใช้รหัสเก่า ซึ่งพบได้ในอีเมล เอกสาร และระบบติดตามจุดบกพร่อง นิสัยที่ไม่ดี? อาจจะ. แต่ผู้ใช้จะขอบคุณหากคุณรักษา ID เก่าไว้ เหตุผลที่สองเป็นเรื่องทางเทคนิค และมาจากข้อเท็จจริงที่ Salesforce ไม่ยอมรับ ID ที่ให้ไว้อย่างชัดเจนสำหรับเรกคอร์ดใหม่ (ต่างจาก Microsoft Dynamics) แต่สร้างขึ้นในระหว่างการโหลด ปัญหาเกิดขึ้นเมื่อเราต้องการโหลดวัตถุลูกเพราะเราต้องกำหนด ID ของวัตถุหลัก เนื่องจากเราจะทราบ ID เหล่านั้นหลังจากโหลดแล้วเท่านั้น นี่เป็นแบบฝึกหัดที่ไร้ประโยชน์

ลองใช้บัญชีและรายชื่อติดต่อของตน เช่น

1. สร้างข้อมูลสำหรับบัญชี
2. โหลดบัญชีเข้าสู่ Salesforce และรับ ID ที่สร้างขึ้น
3. รวมรหัสบัญชีใหม่ในข้อมูลการติดต่อ
4. สร้างข้อมูลสำหรับผู้ติดต่อ
5. โหลดผู้ติดต่อใน Salesforce

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

1. สร้างข้อมูลสำหรับบัญชี รวมถึงรหัสเดิม
2. สร้างข้อมูลสำหรับผู้ติดต่อ รวมถึง ID ดั้งเดิมของบัญชี
3. โหลดบัญชีลงใน Salesforce
4. โหลดผู้ติดต่อใน Salesforce โดยใช้ Account Legacy ID เป็นข้อมูลอ้างอิงหลัก

ข้อดีของที่นี้คือ เราได้แยกรุ่นและขั้นตอนการโหลดออก ซึ่งช่วยให้เกิดการขนานกันได้ดีขึ้น ลดเวลาหยุดทำงาน และอื่นๆ

8. ระวังคุณสมบัติเฉพาะของ Salesforce

เช่นเดียวกับระบบอื่นๆ Salesforce มีส่วนที่ยุ่งยากมากมายซึ่งเราควรทราบเพื่อหลีกเลี่ยงความประหลาดใจอันไม่พึงประสงค์ในระหว่างการย้ายข้อมูล ต่อไปนี้คือตัวอย่างบางส่วน:

• การเปลี่ยนแปลงบางอย่างเกี่ยวกับผู้ใช้ที่ใช้งานอยู่จะสร้างการแจ้งเตือนทางอีเมลไปยังอีเมลของผู้ใช้โดยอัตโนมัติ ดังนั้น หากเราต้องการเล่นกับข้อมูลผู้ใช้ เราจำเป็นต้องปิดการใช้งานผู้ใช้ก่อนและเปิดใช้งานหลังจากการเปลี่ยนแปลงเสร็จสิ้น ในสภาพแวดล้อมการทดสอบ เราแย่งชิงอีเมลผู้ใช้เพื่อไม่ให้มีการแจ้งเตือนเลย เนื่องจากผู้ใช้ที่ใช้งานอยู่ใช้ใบอนุญาตที่มีราคาแพง เราจึงไม่สามารถให้ผู้ใช้ทั้งหมดใช้งานได้ในสภาพแวดล้อมการทดสอบทั้งหมด เราต้องจัดการกลุ่มย่อยของผู้ใช้ที่ใช้งานอยู่ ตัวอย่างเช่น เพื่อเปิดใช้งานเฉพาะผู้ที่อยู่ในสภาพแวดล้อมการฝึกอบรม
• ผู้ใช้ที่ไม่ใช้งานสำหรับอ็อบเจ็กต์มาตรฐานบางอย่าง เช่น บัญชีหรือกรณีและปัญหา สามารถกำหนดได้หลังจากให้สิทธิ์ระบบแล้ว "อัปเดตเรกคอร์ดด้วยเจ้าของที่ไม่ใช้งาน" แต่สามารถกำหนดให้กับผู้ติดต่อและอ็อบเจ็กต์ที่กำหนดเองทั้งหมดได้ ตัวอย่างเช่น
• เมื่อปิดใช้งานผู้ติดต่อ ฟิลด์การเลือกไม่รับทั้งหมดจะถูกเปิดอย่างเงียบ ๆ
• เมื่อโหลดออบเจ็กต์สมาชิกทีมบัญชีที่ซ้ำกันหรืออ็อบเจ็กต์การแชร์บัญชี เรกคอร์ดที่มีอยู่จะถูกเขียนทับโดยไม่โต้ตอบ อย่างไรก็ตาม เมื่อโหลดคู่ค้าโอกาสทางการขายที่ซ้ำกัน เรกคอร์ดจะถูกเพิ่มอย่างง่าย ๆ ซึ่งส่งผลให้เกิดการซ้ำซ้อน
• ฟิลด์ระบบ เช่น Created Date , Created By ID , Last Modified Date , Last Modified By ID สามารถเขียนได้อย่างชัดเจนหลังจากให้สิทธิ์ระบบใหม่ “Set Audit Fields on Record Creation”
• การเปลี่ยนแปลงค่าประวัติเขตข้อมูลไม่สามารถย้ายได้เลย
• ไม่สามารถระบุเจ้าของบทความองค์ความรู้ในระหว่างการโหลด แต่สามารถอัปเดตได้ในภายหลัง
• ส่วนที่ยุ่งยากคือการจัดเก็บเนื้อหา (เอกสาร ไฟล์แนบ) ลงใน Salesforce มีหลายวิธีที่จะทำ (โดยใช้สิ่งที่แนบมา ไฟล์ สิ่งที่แนบมาของฟีด เอกสาร) และแต่ละวิธีก็มีข้อดีและข้อเสีย รวมถึงการจำกัดขนาดไฟล์ที่แตกต่างกัน
• ฟิลด์รายการเลือกจะบังคับให้ผู้ใช้เลือกค่าใดค่าหนึ่งที่อนุญาต เช่น ประเภทของบัญชี แต่เมื่อโหลดข้อมูลโดยใช้ Salesforce API (หรือเครื่องมือใดๆ ที่สร้างจากข้อมูลดังกล่าว เช่น Apex Data Loader หรือตัวเชื่อมต่อ Informatica Salesforce) ค่า ใดๆ ก็ตาม จะถูกส่งต่อ

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

9. อย่าใช้ Salesforce เป็นแพลตฟอร์มการย้ายข้อมูล

เป็นเรื่องที่น่าสนใจมากที่จะใช้ Salesforce เป็นแพลตฟอร์มสำหรับการสร้างโซลูชันการย้ายข้อมูล โดยเฉพาะอย่างยิ่งสำหรับนักพัฒนา Salesforce เป็นเทคโนโลยีเดียวกันสำหรับโซลูชันการย้ายข้อมูลสำหรับการปรับแต่งแอปพลิเคชัน Salesforce, GUI เดียวกัน, ภาษาการเขียนโปรแกรม Apex เดียวกัน, โครงสร้างพื้นฐานเดียวกัน Salesforce มีอ็อบเจ็กต์ที่สามารถทำหน้าที่เป็นตาราง และชนิดของภาษา SQL อย่าง Salesforce Object Query Language (SOQL) อย่างไรก็ตาม โปรดอย่าใช้มัน มันจะเป็นข้อบกพร่องทางสถาปัตยกรรมขั้นพื้นฐาน

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

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

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

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

10. กำกับดูแลข้อมูลเมตาของ Salesforce

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

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

ข้อมูลเมตาใดที่จะดาวน์โหลด:

• รายการของอ็อบเจ็กต์ที่มีเลเบลและชื่อทางเทคนิคและแอตทริบิวต์ เช่น creatable หรือ updatable
• รายการช่องที่มีแอตทริบิวต์ (ดีกว่าที่จะได้รับทั้งหมด)
• รายการค่าของรายการเบิกสำหรับฟิลด์รายการเบิกสินค้า เราจะต้องใช้พวกมันเพื่อจับคู่หรือตรวจสอบข้อมูลอินพุตสำหรับค่าที่ถูกต้อง
• รายการการตรวจสอบ เพื่อให้แน่ใจว่าการตรวจสอบความถูกต้องใหม่จะไม่สร้างปัญหาสำหรับข้อมูลที่ย้าย

จะดาวน์โหลดข้อมูลเมตาจาก Salesforce ได้อย่างไร ไม่มีวิธีข้อมูลเมตามาตรฐาน แต่มีหลายตัวเลือก:

• สร้าง Enterprise WSDL – ในเว็บแอปพลิเคชัน Salesforce ให้ไปที่ Setup / API และดาวน์โหลด Enterprise WSDL ที่พิมพ์อย่างเข้มงวด ซึ่งอธิบายอ็อบเจ็กต์และฟิลด์ทั้งหมดใน Salesforce (แต่ไม่ใช่ค่าของรายการที่เลือกหรือการตรวจสอบ)
• โทรหา Salesforce describeSObjects บริการเว็บ SObjects โดยตรงหรือโดยใช้ Java หรือ C# wrapper (ปรึกษา Salesforce API) ด้วยวิธีนี้ คุณจะได้สิ่งที่คุณต้องการ และนี่คือวิธีที่แนะนำในการส่งออกข้อมูลเมตา
• ใช้เครื่องมือทางเลือกที่มีอยู่มากมายบนอินเทอร์เน็ต

เตรียมพร้อมสำหรับการย้ายข้อมูลครั้งต่อไป

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

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

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