Nền tảng dữ liệu khách hàng (CDP) được định nghĩa là “phần mềm đóng gói” bởi Viện CDP, do đó, theo nghĩa đen, một công ty không thể xây dựng CDP của riêng mình. Tuy nhiên, bất chấp các định nghĩa, nhiều người mua CDP tiềm năng cân nhắc xây dựng thiết bị tương đương với CDP để sử dụng ngay từ đầu. Câu hỏi dường như đã xuất hiện thường xuyên hơn trong năm qua, có lẽ bởi vì các CDP hiện đã hiểu đủ rõ rằng bộ phận IT có thể phát triển các thông số kỹ thuật hợp lý cho những gì cần thiết. Vì vậy, cuộc tranh luận về xây dựng và mua phần mềm, từng dường như được giải quyết dứt khoát theo hướng có lợi cho việc mua, giờ đây đã trở lại trong chương trình nghị sự.
Xây dựng vs Mua?
Trên thực tế, cuộc tranh luận chưa bao giờ thực sự biến mất. Các khảo sát cho thấy một phần đáng kể các công ty luôn xây dựng CDP của riêng họ. Thật khó để diễn giải những dữ liệu như vậy vì chúng tôi thường không biết những người được hỏi định nghĩa CDP là gì. Rõ ràng là họ không tuân theo định nghĩa của Viện CDP, chứ chưa nói đến định nghĩa chi tiết hơn của Viện Danh sách kiểm tra RealCDPyêu cầu CDP chấp nhận tất cả các loại dữ liệu, giữ lại tất cả các chi tiết vô thời hạn, xây dựng các cấu hình thống nhất với một xem khách hàng duy nhất (SCV), cho phép truy cập thời gian thực bên ngoài vào các cấu hình và hỗ trợ trình kích hoạt sự kiện thời gian thực. Trong nhiều trường hợp, những người được hỏi dường như định nghĩa CDP là bất kỳ kho lưu trữ trung tâm nào cho dữ liệu khách hàng, bao gồm các hệ thống yếu hơn đáng kể so với định nghĩa của Viện yêu cầu.
Có nhiều mối đe dọa hơn là chia rẽ hợp pháp. Xây dựng một CDP thực sự là một thách thức kỹ thuật nghiêm trọng, trong khi xây dựng một cơ sở dữ liệu đơn giản thì không. Thật hợp lý khi cho rằng nhiều bộ phận IT coi CDP là một phần mở rộng nhỏ của kho dữ liệu hoặc hồ dữ liệu hiện có. Một số thậm chí tranh luận hiện tại của họ CRM đã làm những gì CDP phải làm. Bắt đầu từ những tiền đề đó, họ lập luận rằng tùy chọn xây dựng nhanh hơn, rẻ hơn và dễ dàng hơn so với việc mua, cài đặt, tích hợp và hỗ trợ một hệ thống lớn mới.
Người dùng CDP tiềm năng thường ít tự tin hơn IT rằng giải pháp nội bộ sẽ đáp ứng nhu cầu của họ. Ngay cả khi họ có cùng hiểu biết về CDP với bộ phận IT, họ cũng ít chắc chắn rằng nhóm IT sẽ cung cấp hệ thống đã hứa đúng thời hạn, một ngân sách và với tất cả các tính năng mong muốn. Người dùng doanh nghiệp cũng thường coi CDP đã mua là một cách để giảm sự phụ thuộc vào nhóm IT đối với hoạt động hàng ngày của hệ thống và để cải tiến trong tương lai. Đây là một trong những lời hứa ngầm về “phần mềm đóng gói” và là một trong những lý do khiến CDP ngay từ đầu đã trở nên phổ biến như vậy.
Thật tuyệt khi nghĩ rằng mọi quyết định xây dựng và mua phần mềm sẽ dựa trên sự so sánh khách quan, kỹ lưỡng giữa hai tùy chọn. Nhưng nhiều công ty có thành kiến văn hóa hoặc chính trị mạnh mẽ ủng hộ lựa chọn này hay lựa chọn khác. Trong những trường hợp đó, chi tiết của các yêu cầu CDP ít quan trọng hơn ấn tượng mà những người ra quyết định mạnh mẽ có về phạm vi của dự án. Đây là nơi các định nghĩa trở nên quan trọng. Các bộ phận IT coi CDP là một dự án đơn giản có khả năng nhất quyết yêu cầu họ tự xây dựng nó, trong khi các bộ phận đó có thể háo hức mua một hệ thống nếu họ coi việc xây dựng nó là một sự tiêu hao lớn nguồn lực của họ.
Phạm vi xây dựng CDP
Một cách để làm rõ phạm vi của CDP là xác định tập hợp đầy đủ các khả năng cần thiết để cung cấp một hệ thống chức năng. Danh sách này bắt đầu bằng việc thu thập dữ liệu từ các hệ thống nguồn và kết thúc bằng việc phân phối dữ liệu cho các hệ thống sử dụng dữ liệu đó. Mỗi khả năng là một ứng dụng chính liên quan đến một danh mục phần mềm hiện có. Vì vậy, một công ty đề xuất xây dựng CDP của riêng mình đang thực sự đề xuất tạo phiên bản riêng của nhiều hệ thống chính – một cam kết mà ít người thực sự chấp nhận nếu được cung cấp giải pháp thay thế đơn giản hơn là mua một gói kết hợp tất cả chúng.
Thủ tục thanh toán Cách chọn CDP phù hợp với bạn
Việc tính toán thay đổi đáng kể nếu một công ty đã có sẵn một số thành phần CDP. Một hồ dữ liệu hiện có sẽ bao gồm các khả năng thu thập dữ liệu, đường dẫn và cơ sở dữ liệu. Các hệ thống khách hàng hiện tại có thể có chất lượng dữ liệu, độ phân giải danh tínhvà các tính năng quản lý dữ liệu chính. Các nhóm phân tích kinh doanh và khoa học dữ liệu có thể đầu tư nhiều vào các công cụ phân tích, phân khúc và báo cáo. Và đáng kể điều phối hành trình khách hàng xương sống có thể đã sẵn sàng để chia sẻ dữ liệu và quy trình giữa các hệ thống.
Vì vậy, ngay cả một bộ phận IT hiểu đúng phạm vi công việc vẫn có thể kết luận nỗ lực gia tăng để xây dựng CDP ít hơn nỗ lực cài đặt, tích hợp và duy trì một hệ thống hoàn toàn riêng biệt. Điều này không nhất thiết phải đúng. CDP có thể sẽ yêu cầu thêm các nguồn dữ liệu và quy trình mới vào các ứng dụng hiện có, vì vậy nỗ lực gia tăng bằng cách sử dụng các công cụ hiện có có thể là đáng kể. Điều này cần phân tích chi tiết để xác định. Không có phân tích đó, việc mua một CDP sao chép nhiều chức năng hiện có có vẻ trùng lặp và lãng phí.
Kiểm kê các tính năng CDP để Xây dựng so với Mua
Cho đến nay, chúng tôi mới chỉ xem xét chi phí phát triển của việc xây dựng so với mua CDP. Tuy nhiên, chi phí phát triển chỉ là một yếu tố trong việc đưa ra lựa chọn và không thực sự quan trọng nhất. Một bản Audit toàn diện hơn sẽ bao gồm:
Có một số tính năng bị thiếu trong các hệ thống đóng gói hiện có sẽ mang lại lợi thế cạnh tranh đáng kể nếu nó được cung cấp bởi một hệ thống do công ty xây dựng không? Nếu vậy, đó sẽ là một lý do mạnh mẽ để xây dựng (giả sử nhóm IT có thể cung cấp tính năng đặc biệt). Mặt khác của câu hỏi này là liệu một hệ thống đóng gói hiện tại có cung cấp tất cả các chức năng cần thiết cho các yêu cầu CDP hiện tại hay không. Nếu không, bạn có thể cần xây dựng CDP của riêng mình để có được các tính năng cần thiết không tạo thêm lợi thế cạnh tranh.
Bộ phận IT thường lập luận rằng họ có thể thêm các tính năng mới khi có nhu cầu mới, giúp công ty có nhiều quyền kiểm soát hơn đối với tương lai của mình hơn là dựa vào nhà cung cấp phần mềm đóng gói để thêm chúng. Đây là một lập luận hấp dẫn nhưng phải được cân bằng với câu hỏi bộ phận IT sẽ thực sự thực hiện các thay đổi nhanh như thế nào, do các yêu cầu khác đối với nguồn lực hạn chế của nó. Cân bằng điều này với xác suất mạnh mẽ rằng một hệ thống đóng gói sẽ được cải tiến thường xuyên hơn một sản phẩm nội bộ và có thể thêm các tính năng mới trước khi công ty nhận ra rằng họ cần chúng.
Hầu hết phân tích xây dựng so với mua so sánh chi phí phát triển một hệ thống mới với chi phí mua một gói mới. Tuy nhiên, toàn bộ chi phí tài chính cũng bao gồm việc bảo trì và cập nhật liên tục hệ thống do gia đình xây dựng cũng như chi phí để tích hợp và vận hành nhân viên của gói. Ngoài ra, hãy nhớ rằng CDP có thể đảm nhận một số nhiệm vụ hiện đang được xử lý bởi các hệ thống hiện có hoặc theo cách thủ công, giúp giảm đáng kể thời gian và chi phí của nhân viên. (Mẹo chuyên nghiệp: riêng những khoản tiết kiệm đó có thể biện minh cho chi phí của một CDP đóng gói.) Hãy chắc chắn bao gồm tất cả những điều này trong tính toán của bạn.
Dự án CDP có phải là cách sử dụng tốt nhất các nguồn lực phát triển của công ty không? Ngay cả khi ngân sách là vô hạn, thì vẫn có một số lượng hạn chế những người hiểu rõ về hệ thống của công ty để thiết kế một CDP phù hợp cũng như những người quản lý và người dùng doanh nghiệp để giúp họ. Một lập luận phản bác là các hệ thống được đóng gói tốt hơn có thể xuất hiện trong tương lai, có lẽ từ một trong những nhà cung cấp phần mềm hiện tại của bạn, vì vậy, có thể hợp lý khi xây dựng một giải pháp nội bộ dự phòng cho đến khi điều đó xảy ra. Nhưng hãy cẩn thận với logic này. Các điểm dừng tạm thời có một cách trở nên cố định vĩnh viễn theo thời gian.
Luôn có một rủi ro đáng kể là một dự án nội bộ sẽ mất nhiều thời gian hơn, tốn nhiều chi phí hơn và mang lại kết quả thấp hơn những gì đã hứa. Ngoài các chi phí trực tiếp, sự chậm trễ như vậy có nghĩa là phải chờ đợi lâu hơn trước khi công ty thu được lợi ích từ CDP của mình hoặc giải quyết các vấn đề mà công ty phải khắc phục. Điều này không có nghĩa là việc mua hàng không có rủi ro. Luôn có những lo ngại rằng hệ thống đã mua sẽ không hoạt động như đã hứa hoặc sẽ không thể mở rộng theo nhu cầu trong tương lai. Giảm thiểu những rủi ro này là một trong những lý do mà các công ty cần tạo ra các yêu cầu chi tiết và kiểm tra kỹ lưỡng bất kỳ hệ thống đã mua nào trước khi ký hợp đồng.
Suy nghĩ cuối cùng
Không có công ty nào thực sự xây dựng hệ thống của riêng mình từ đầu. Bạn sẽ không xây dựng chip, máy chủ hoặc hệ điều hành của riêng mình và gần như chắc chắn bạn sẽ sử dụng cơ sở dữ liệu nguồn mở hoặc thương mại. Nhiều thành phần khác có thể đã có sẵn hoặc được mua cho dự án. Các thành phần đã mua giúp giảm chi phí và rủi ro của dự án xây dựng tại nhà, mặc dù mỗi thành phần đều tăng thêm chi phí tích hợp và license. Tương tự như vậy, không có hệ thống đóng gói nào thực sự hoàn chỉnh. Có khả năng sẽ có một số trình kết nối tùy chỉnh để tích hợp với các hệ thống hiện có và luôn cần hỗ trợ IT cho quá trình cài đặt và tích hợp.
Vì vậy, mặc dù chắc chắn có sự khác biệt lớn giữa việc xây dựng và mua CDP của bạn, nhưng bạn cũng nên nhận ra rằng có một số điểm chồng chéo giữa hai cách tiếp cận. Để có cơ hội thành công cao nhất, hãy thay thế “xây dựng so với mua” bằng “xây dựng cái gì và mua cái gì” và đặt mục tiêu của bạn là tìm ra sự kết hợp tối ưu giữa các thành phần được xây dựng và mua.
Nguồn : cdp.com (post by Automation bot)
