ทุกวันนี้แทบทุกธุรกิจมี Software ใช้งานอยู่หลายระบบ ทีม Marketing มีเครื่องมือสำหรับ Campaign และ Analytics ทีม Sales มี CRM ส่วน Customer Service อาจทำงานผ่าน LINE, Facebook หรือช่องทางสนทนาอื่น ขณะที่ฝ่ายบัญชีมีระบบเอกสารและการชำระเงิน และฝ่าย Operation ก็อาจใช้ Spreadsheet, Inventory หรือระบบภายในของตัวเอง เมื่อมองจากภายนอกจึงดูเหมือนว่าธุรกิจมีเครื่องมือพร้อมสำหรับการทำงานแทบทุกด้านแล้ว
แต่เมื่อเข้าไปดู Workflow ที่เกิดขึ้นจริง กลับพบปัญหาที่เกิดขึ้นซ้ำ ๆ นั่นคือ ยิ่งมี Software มากขึ้น ไม่ได้หมายความว่าข้อมูลจะเชื่อมกันมากขึ้นเสมอไป หลายครั้งสิ่งที่เกิดขึ้นกลับตรงกันข้าม ข้อมูลถูกกระจายออกไปอยู่หลายระบบ และคนในองค์กรต้องกลายเป็นตัวกลางที่คอยเปิดหลายหน้าจอ ดาวน์โหลดไฟล์ Copy ข้อมูล ส่งต่อข้อมูล และตรวจสอบว่าข้อมูลในแต่ละระบบยังตรงกันอยู่หรือไม่
นี่เป็นหนึ่งในปัญหาที่ผมเจอมาหลายครั้งจากการทำงานด้าน CRM, Digital Marketing, Customer Data และ Business Operations และเป็นอีกเหตุผลหนึ่งที่ทำให้แนวคิดของ HostDrift ค่อย ๆ พัฒนาไปในทิศทางของ Connected Business Systems
ปัญหาไม่ได้อยู่ที่ไม่มีระบบ แต่แต่ละระบบทำงานแยกกัน
เวลาเกิดปัญหาใหม่ในธุรกิจ เรามักแก้ด้วยการเพิ่ม Software อีกหนึ่งตัว หากมี Lead มากขึ้นก็หา CRM ถ้าต้องการดูพฤติกรรมของผู้ใช้งานบน Website ก็เพิ่ม Analytics ถ้าต้องการส่ง Campaign อย่างเป็นระบบก็เพิ่ม Marketing Automation และเมื่อเริ่มมีเรื่อง Privacy เข้ามาเกี่ยวข้องก็อาจเพิ่ม Consent Management Platform ส่วนงานขายก็อาจมี Quotation, Invoice หรือระบบเอกสารเพิ่มเติมอีกชุดหนึ่ง
การเพิ่มเครื่องมือเหล่านี้ไม่ได้ผิด เพราะ Software แต่ละตัวสามารถแก้ปัญหาเฉพาะด้านได้ดี แต่สิ่งที่เกิดขึ้นเมื่อเวลาผ่านไปคือข้อมูลเริ่มอยู่กันคนละที่ และแต่ละระบบอาจมองลูกค้าคนเดียวกันด้วย Identity ที่ไม่เหมือนกัน
ตัวอย่างเช่น ลูกค้าคนหนึ่งอาจเป็น Anonymous Visitor เมื่ออยู่บน Website แต่เมื่อกรอก Form เขาอาจถูกระบุด้วย Email Address ใน Marketing Platform เมื่อทักผ่าน LINE OA เขาจะกลายเป็น LINE User ID และเมื่อทีม Sales บันทึกข้อมูลลง CRM เขาก็กลายเป็น Customer Record อีกหนึ่งรายการ ส่วนในระบบ Quotation อาจถูกเก็บด้วยชื่อบริษัท เบอร์โทรศัพท์ หรือ Tax ID ทั้งหมดนี้ดูเหมือนเป็นข้อมูลหลายชุด แต่ในความเป็นจริงอาจเป็น คนคนเดียวกัน
ถ้าระบบเหล่านี้ไม่สามารถเชื่อม Identity เข้าหากันได้ แต่ละทีมก็จะเห็นลูกค้าคนเดียวกันคนละมุม นี่จึงเป็นเหตุผลว่าทำไมแนวคิดอย่าง Customer 360° ฟังดูไม่ซับซ้อนในทางทฤษฎี แต่เมื่อทำจริงกลับเกี่ยวข้องทั้ง Data Structure, Identity Resolution และ Workflow ระหว่างหลายระบบ
Integration ไม่ได้หมายถึงแค่การมี API
เมื่อพูดถึงการเชื่อมระบบ หลายคนมักนึกถึง API ก่อน แต่สำหรับผม Integration ที่ดีไม่ควรเริ่มจากคำถามว่า “ระบบนี้มี API ไหม?” คำถามที่ควรมาก่อนคือ “ข้อมูลอะไรจำเป็นต้องเดินทางจากจุดหนึ่งไปยังอีกจุดหนึ่ง และข้อมูลนั้นจะถูกนำไปใช้ทำอะไรต่อ?”
ลองดู Workflow ง่าย ๆ อย่างการที่ลูกค้ากรอก Form บน Website หลังจากกด Submit แล้วข้อมูลควรไปที่ไหน ควรเข้า CRM โดยอัตโนมัติหรือไม่ ระบบควรสร้าง Lead ใหม่ทันที หรือควรตรวจสอบก่อนว่าบุคคลนี้มี Customer Profile อยู่แล้ว ทีม Sales จำเป็นต้องได้รับ Task สำหรับ Follow-up หรือไม่ และหาก Form มีการเก็บ Consent สถานะนั้นควรถูกส่งไปพร้อมกับข้อมูลลูกค้าด้วยหรือเปล่า
ถ้าในเวลาต่อมาลูกค้าคนนี้ซื้อสินค้าหรือบริการสำเร็จ Marketing ก็ควรรู้ด้วยว่า Lead เดิมได้กลายเป็น Customer แล้ว เพื่อไม่ให้ยังส่ง Communication แบบเดียวกับ Prospect ต่อไป คำถามเหล่านี้จึงไม่ใช่เรื่อง API เพียงอย่างเดียว แต่เป็นเรื่องของ Business Workflow ส่วน API, Webhook หรือ Queue เป็นเพียง Technology ที่ช่วยให้ Workflow ที่ออกแบบไว้สามารถทำงานได้จริง
เมื่อธุรกิจมีข้อมูลหลายชุด ความจริงก็อาจมีหลายเวอร์ชัน
อีกปัญหาหนึ่งที่พบได้บ่อยคือองค์กรมีข้อมูลจำนวนมาก แต่กลับไม่แน่ใจว่าข้อมูลชุดไหนเป็นข้อมูลล่าสุด เช่น Sales แก้เบอร์โทรศัพท์ของลูกค้าใน CRM แล้ว แต่ Marketing Platform ยังใช้เบอร์เดิม หรือลูกค้าเปลี่ยน Email แล้ว Newsletter Platform ยังเก็บ Email เก่าอยู่ รวมถึงกรณีที่ลูกค้าถอน Consent ไปแล้ว แต่ระบบอื่นที่เกี่ยวข้องไม่เคยได้รับสถานะใหม่
ในบางกรณี ลูกค้าคนเดียวกันอาจมี Record ซ้ำหลายรายการเพียงเพราะเข้ามาจากคนละ Channel เมื่อปัญหาเหล่านี้เกิดขึ้นพร้อมกัน สิ่งที่ได้รับผลกระทบไม่ได้มีเพียง Data Quality แต่รวมไปถึง Customer Experience ด้วย ลูกค้าอาจได้รับข้อความซ้ำ ได้ Campaign ที่ไม่เกี่ยวข้อง หรือถูกติดต่อจากหลายทีมโดยที่แต่ละทีมไม่รู้ว่าอีกทีมได้พูดคุยกับลูกค้าไปแล้ว
กรณีที่เกี่ยวข้องกับ Privacy ยิ่งมีความสำคัญมากขึ้น เพราะหาก Consent เปลี่ยนในระบบหนึ่ง แต่ระบบอื่นยังใช้สถานะเดิม ก็อาจเกิดการนำข้อมูลไปใช้โดยที่ Context ไม่ตรงกัน ดังนั้นเป้าหมายของการเชื่อมข้อมูลจึงไม่ใช่เพียงการนำข้อมูลทั้งหมดมาเก็บไว้ที่เดียว แต่คือการทำให้แต่ละระบบสามารถทำงานโดยอาศัย Context ที่สอดคล้องกัน
ทุกอย่างจำเป็นต้องอยู่ในระบบเดียวหรือไม่?
ผมไม่ได้คิดว่าคำตอบคือการทำให้ Software ตัวเดียวทำทุกอย่าง เพราะระบบแต่ละประเภทถูกสร้างขึ้นมาเพื่อแก้ปัญหาคนละแบบ CRM ควรทำหน้าที่ด้าน Customer Relationship, Sales Pipeline และ Workflow ของทีมให้ดี ขณะที่ CDP ควรเน้น Customer Profile, Behavioral Events และ Data Signals ส่วน Consent Platform ควรรับผิดชอบเรื่อง Permission, Preference และ Privacy
ในอีกด้านหนึ่ง Quotation ควรเน้น Document Workflow และสถานะของเอกสาร ขณะที่ Inventory ก็ควรดูแล Stock, Asset, Location และข้อมูลด้าน Operation การพยายามนำความสามารถทั้งหมดมารวมอยู่ในระบบเดียวอาจทำให้ Software มีขนาดใหญ่และซับซ้อนจนยากต่อการใช้งานและพัฒนาต่อ
สิ่งที่สำคัญกว่าคือการออกแบบให้ชัดว่า แต่ละระบบควรรู้อะไร ข้อมูลใดควรถูกแชร์ ระบบใดเป็นเจ้าของข้อมูลต้นฉบับ และเมื่อข้อมูลเปลี่ยน ระบบใดจำเป็นต้องรับรู้การเปลี่ยนแปลงนั้น แนวคิดนี้เป็นสิ่งที่ผมเริ่มนำมาใช้มากขึ้นกับ HostDrift โดยให้แต่ละ Platform ยังคงมีหน้าที่ของตัวเองอย่างชัดเจน แต่สามารถส่งต่อข้อมูลและ Context ที่จำเป็นระหว่างกันได้
Single Source of Truth ไม่ได้หมายความว่าต้องมี Database เดียว
คำว่า Single Source of Truth ถูกใช้บ่อยในงาน Data และบางครั้งอาจทำให้เข้าใจว่าธุรกิจต้องนำข้อมูลทุกอย่างไปรวมไว้ใน Database เดียว แต่ในทางปฏิบัติหลายระบบสามารถเป็น Source หลักของข้อมูลคนละประเภทได้
CRM อาจเป็น Source หลักของ Lead Status ขณะที่ CDP เป็น Source ของ Behavioral Events ส่วน Consent Platform เป็น Source ของ Consent State ระบบ Quotation เป็น Source ของ Document Status และ Inventory เป็น Source ของ Stock Quantity สิ่งสำคัญไม่ใช่ว่าข้อมูลเหล่านั้นต้องอยู่ที่เดียวกัน แต่คือระบบอื่นต้องรู้ว่า เมื่อจำเป็นต้องใช้ข้อมูลประเภทหนึ่ง ควรเชื่อข้อมูลจาก Source ใด
ตัวอย่างเช่น หากลูกค้าถอน Consent แล้ว CRM และ CDP ไม่ควรสร้าง Consent State ของตัวเองขึ้นมาอีกชุดหนึ่งจนเกิดข้อมูลขัดแย้ง แต่ควรอ้างอิงสถานะล่าสุดจากระบบที่รับผิดชอบ Consent โดยตรง แนวทางแบบนี้ช่วยลดปัญหาที่แต่ละระบบมี “ความจริงคนละชุด” และทำให้การ Sync ข้อมูลมีโครงสร้างที่ชัดเจนมากขึ้น
เมื่อระบบไม่เชื่อมกัน คนจะกลายเป็น Integration Layer
สิ่งหนึ่งที่ผมพบว่าน่าสนใจจากการทำงานจริงคือ เมื่อ Software ไม่สามารถเชื่อมต่อกันได้ คนมักกลายเป็นคนทำ Integration แทนระบบโดยไม่รู้ตัว ตัวอย่างที่พบได้ทั่วไปคือการ Export Excel จากระบบหนึ่ง แล้วเปิดอีกระบบเพื่อ Copy ข้อมูล ตรวจสอบความถูกต้อง ส่งไฟล์ผ่าน Email หรือ LINE แล้วให้อีกทีม Upload ข้อมูลเข้าไปในอีกระบบหนึ่ง
ถ้ามองในเชิง Technical กระบวนการนี้ก็คือ Data Pipeline รูปแบบหนึ่ง เพียงแต่เป็น Pipeline ที่ใช้คนเป็น Middleware ซึ่งนอกจากจะใช้เวลาแล้ว ยังเพิ่มโอกาสเกิด Human Error และทำให้ข้อมูลไม่ได้ถูก Update แบบต่อเนื่อง
แน่นอนว่าหลาย Workflow ยังจำเป็นต้องมี Human Review และไม่ใช่ทุกขั้นตอนควรถูก Automate แต่ถ้างานเดิมเกิดขึ้นทุกวัน ใช้กฎเดิม และไม่ได้ต้องใช้การตัดสินใจที่ซับซ้อน นั่นคือจุดที่ระบบสามารถเข้ามาช่วยลดงาน Manual ได้ สำหรับผม Automation จึงไม่ใช่การเอาคนออกจาก Workflow แต่คือการเอางานซ้ำ ๆ ที่ไม่จำเป็นต้องใช้ Judgment ของคนออกไป เพื่อให้คนสามารถใช้เวลากับงานที่ต้องใช้ Context การคิด และการสื่อสารได้มากขึ้น
Connected Systems ควรเริ่มจาก Workflow ไม่ใช่ Technology
ตอนเริ่มทำ Integration ผมเองก็เคยมองเรื่องนี้จากฝั่ง Technology มากเกินไป เช่น ระบบไหนมี API ระบบไหนรองรับ Webhook หรือ Database ไหนสามารถ Sync กันได้ แต่เมื่อพัฒนาระบบมากขึ้น ผมเริ่มเห็นว่า Technology ควรเป็นขั้นตอนหลังจากเข้าใจ Workflow แล้ว
ก่อนเชื่อมสองระบบเข้าด้วยกัน เราควรรู้ก่อนว่าข้อมูลอะไรต้องถูกส่ง ส่งเมื่อไร Event ใดเป็นตัวเริ่มต้น หากส่งไม่สำเร็จระบบควรทำอย่างไร ระบบใดเป็นเจ้าของ Record หลัก ใครมีสิทธิ์เห็นข้อมูล และข้อมูลนั้นสามารถนำไปใช้ภายใต้ Consent แบบใด เมื่อคำถามเหล่านี้ชัด การเลือก Technology ก็ง่ายขึ้นมาก
บาง Workflow อาจเหมาะกับ API บางกรณีเหมาะกับ Webhook หรือ Queue และบางกระบวนการอาจไม่จำเป็นต้องทำแบบ Real-time เลยด้วยซ้ำ สิ่งสำคัญคือ Technology ควรถูกเลือกให้เหมาะกับ Workflow ไม่ใช่บังคับให้ Workflow ต้องปรับตาม Technology ที่มีอยู่
ทำไม HostDrift จึงเริ่มเชื่อมแต่ละ Platform เข้าหากัน
เมื่อมองย้อนกลับไป CRM, CDP, Consent, Quotation และ Inventory เริ่มต้นจากปัญหาคนละด้าน แต่เมื่อพัฒนาต่อเนื่อง ความสัมพันธ์ระหว่างระบบเหล่านี้กลับชัดขึ้นเรื่อย ๆ Customer ที่อยู่ใน CRM ก็คือ Customer Profile คนเดียวกับที่อยู่ใน CDP ข้อมูลที่ CDP นำไปใช้ควรสัมพันธ์กับ Consent และ Sales Workflow ที่อยู่ใน CRM ก็อาจนำไปสู่การสร้าง Quotation ในภายหลัง ขณะที่เมื่อเกิดการขายสินค้า ก็อาจมีผลต่อ Inventory ต่อไป
สิ่งที่ผมพยายามสร้างจึงไม่ใช่การรวมทุก Platform ให้กลายเป็น Software ขนาดใหญ่ที่ทำทุกอย่าง แต่เป็นการทำให้ แต่ละระบบยังคงชัดเจนในหน้าที่ของตัวเอง พร้อมกับสามารถส่งต่อ Context ที่จำเป็นให้กันได้
เพราะสุดท้ายแล้ว ปัญหาของธุรกิจหลายแห่งอาจไม่ได้เกิดจากการมี Software น้อยเกินไป แต่อาจเกิดจากการมี Software หลายตัวที่ต่างคนต่างทำงาน และเมื่อข้อมูลไม่สามารถเดินทางตาม Workflow ได้อย่างต่อเนื่อง คนก็ต้องกลับมาเป็นผู้เชื่อมระบบด้วยตัวเองอีกครั้ง
สำหรับผม Connected Business Systems จึงไม่ได้หมายถึงการสร้าง Platform ที่ใหญ่ที่สุด แต่หมายถึงการทำให้ ข้อมูลที่ถูกต้องสามารถเดินทางไปถึงคนและระบบที่ต้องใช้มัน ในเวลาที่เหมาะสม และนี่เป็นอีกหนึ่งแนวคิดที่ผมกำลังนำมาทดลองและพัฒนาต่อกับ HostDrift
