Phần mềm trước hay dữ liệu trước?

Phần mềm trước hay dữ liệu trước?

Vì sao càng phát triển hệ thống thì dữ liệu càng "toang"?

Trong quá trình số hóa - chuyển đổi số, doanh nghiệp nào cũng muốn hướng đến số hóa quy trình - ghi nhận dữ liệu (data-driven). Nhưng thực tế chỉ dừng lại ở việc tạo các tiện tích hoặc chức năng trên phần mềm (feature-driven). Nên dù doanh nghiệp đã ghi nhận được rất nhiều dữ liệu nhưng chất lượng không đủ để dùng cho các mục đích phân tích chuyên sâu.

Một ví dụ để thấy 2 kiểu xây dựng Phần mềm quản lý quan hệ khách hàng (CRM)

  • Kiểu 1: Chị A cần phần mềm có đủ tính năng cho nhân viên làm việc (Feature-driven)
  • Kiểu 2: Anh B cần hệ thống để ghi nhận đúng - đủ dữ liệu thông tin Khách hàng, phục vụ phân tích - quản trị hiệu quả. (Data-driven)

Chị A sẽ tiếp cận từ quy trình làm việc thực tế của nhân viên bán hàng để phát triển các chức năng phục vụ cho nhân viên ghi chú thông tin, tìm kiếm và cập nhật thông tin. Hệ thống cần thiết kế dựa trên quy trình làm việc có sẵn và phục vụ cho công việc hàng ngày của nhân viên là chính.

Còn Anh B sẽ yêu cầu ghi nhận thông tin khách hàng bao gồm những gì (Tên, SĐT...), ghi nhận trạng thái bán hàng (KH mới, Đang tư vấn, Đã đồng ý giá, Đã thành công..), ghi nhận doanh thu theo nhân viên, tính toán tỷ lệ chuyển đổi,...vv. Phục vụ đồng thời cho quy trình làm việc của nhân viên và đôi khi cần điều chỉnh quy trình để thống nhất với chức năng hệ thống phục vụ mục đích đo lường, theo dõi, đánh giá hiệu quả bán hàng qua các báo cáo số liệu ghi nhận được.

Từ sự khác nhau ở mục đích sử dụng, 2 kiểu đặt yêu cầu này hình thành 2 bộ tiêu chí nghiệm thu dự án phần mềm hoàn toàn khác nhau, nghiệm thu chức năng và nghiệm thu dữ liệu. Có thể dễ nhận thấy rằng kiểu 1 thường không kiểm tra chi tiết về cấu trúc dữ liệu, mối liên hệ giữa chúng, mối liên hệ giữa dữ liệu CRM này hiện tại với dữ liệu các hệ thống khác (Hệ thống kế toán, Quản trị vận hành..) ...vv.

Sau vài năm dùng hệ thống, tích lũy được nhiều dữ liệu từ nhiều hệ thống rồi nhưng dữ liệu rời rạc và logic ghi nhận không rõ ràng. Việc này dẫn đến tình trạng không thể tổng hợp được toàn bộ thông tin và thông tin không nhất quán giữa các hệ thống. Ví dụ: thông tin Khách hàng có trên CRM nhưng không biết được các đơn hàng của khách hàng đó trên hệ thống kế toán. Khi doanh nghiệp phát sinh nhu cầu đánh giá hiệu quả hoạt động cần đến dữ liệu thì họ phải làm rất nhiều bước kiểm tra thủ công để đảm bảo mức độ chính xác của dữ liệu đủ lớn để có thể sử dụng. Những công đoạn kiểm tra thủ công này tốn rất nhiều thời gian và nhân lực nhưng thường kết quả cũng không đủ chính xác để doanh nghiệp tự tin dựa vào đó để đưa ra quyết định. Lúc này các doanh nghiệp sẽ rất đau đầu khi không biết phải bắt đầu sửa hệ thống từ đâu (hệ thống nào sinh ra dữ liệu sai, và bao lâu nữa họ mới có được những số liệu chính xác để phân tích)

Kết luận:

Vì vậy, để hạn chế những vấn đề đau đầu đó, doanh nghiệp khi bắt đầu xây dựng hệ thống không chỉ phải quan tâm đầy đủ các tính năng cho các hoạt động của công ty mà còn cần bắt đầu thiết kế cấu trúc dữ liệu rõ ràng để có thể dùng được và phát triển được trong tương lai.