Khi doanh nghiệp quyết định làm CRM theo yêu cầu, câu hỏi thường xuất hiện đầu tiên là mất bao lâu, cần chuẩn bị những gì và quá trình triển khai thực tế sẽ diễn ra như thế nào. Nhiều người hình dung khá đơn giản: doanh nghiệp đưa danh sách tính năng, công ty phần mềm báo giá, sau đó đội phát triển bắt đầu code và vài tháng sau bàn giao hệ thống. Nhưng nếu làm theo cách đó, rủi ro lớn nhất là phần mềm hoàn thành đúng danh sách yêu cầu nhưng lại không thực sự phù hợp với cách doanh nghiệp đang làm việc.
Một dự án CRM theo yêu cầu tốt thường bắt đầu trước cả lúc viết dòng code đầu tiên. Đội triển khai phải hiểu sales đang tìm khách như thế nào, một cơ hội bán hàng đi từ đâu tới đâu, dữ liệu nào cần giữ lại, quản lý cần nhìn thấy gì và nhân viên đang gặp khó khăn ở bước nào. Sau đó mới xác định phần mềm cần được xây như thế nào để hỗ trợ quy trình đó. Với một dự án SME có phạm vi tương đối rõ, toàn bộ quá trình này thường có thể triển khai trong khoảng vài tháng, nhưng điều quan trọng hơn tốc độ là từng bước phải được làm đúng thứ tự.
Bước 1: Khảo sát cách doanh nghiệp đang bán hàng và vận hành thực tế
Buổi khảo sát không nên bắt đầu bằng câu hỏi “anh cần CRM có những module gì?”. Nếu người dùng chưa từng xây phần mềm, họ rất khó biết chính xác hệ thống nên có những module nào, và ngay cả khi đã sử dụng CRM trước đây thì danh sách chức năng họ nghĩ tới chưa chắc phản ánh đúng vấn đề cần giải quyết. Cách hợp lý hơn là bắt đầu từ công việc thật: khách hàng đến từ đâu, ai tiếp nhận, sales tạo cơ hội như thế nào, một Deal thường đi qua những giai đoạn nào, lúc nào cần kỹ thuật tham gia, báo giá được làm và duyệt ra sao, khi chốt được đơn thì chuyển cho bộ phận nào.
Một cách rất hiệu quả là lấy một vài trường hợp thật rồi đi từ đầu tới cuối. Chẳng hạn chọn một Deal vừa thắng, một Deal đang theo và một Deal đã thất bại, sau đó cùng xem từng bước đã diễn ra thế nào. Qua đó có thể phát hiện những điều rất khó nhìn thấy nếu chỉ hỏi bằng một bảng câu hỏi: có bước trên quy trình nhưng thực tế nhân viên thường bỏ qua, có thông tin quản lý tưởng sales đang lưu nhưng thực ra chỉ nằm trong trí nhớ cá nhân, hoặc có những thao tác lặp lại hằng ngày khiến nhân viên mất rất nhiều thời gian.
Khảo sát cũng là lúc xác định vấn đề nào thực sự đáng đưa vào CRM. Có doanh nghiệp đang đau vì sales quên follow-up, có nơi khó bàn giao khách hàng khi nhân viên nghỉ, có nơi lại mất nhiều thời gian cho báo giá và phê duyệt. CRM không nên cố giải quyết mọi thứ doanh nghiệp đang làm ngay trong phiên bản đầu tiên. Mục tiêu của bước này là hiểu đủ rõ để trả lời được một câu đơn giản: sau khi CRM được triển khai, những công việc nào phải trở nên nhanh hơn, rõ hơn hoặc dễ kiểm soát hơn so với hiện tại?
Bước 2: Chốt phạm vi trước khi bắt đầu phát triển
Sau khi hiểu quy trình, lúc này mới nên nói tới chức năng. Đội triển khai có thể xác định CRM cần quản lý những dữ liệu nào như khách hàng, người liên hệ, cơ hội bán hàng, dự án, công việc, báo giá hay sản phẩm, đồng thời làm rõ mối quan hệ giữa chúng. Với doanh nghiệp bán hàng đơn giản, cấu trúc có thể khá gọn. Với doanh nghiệp bán hàng dự án, một Project có thể liên quan nhiều khách hàng, nhiều Contact và nhiều cơ hội bán hàng khác nhau nên cách tổ chức sẽ khác ngay từ đầu.
Đây cũng là lúc cần chốt quyền sử dụng. Sales có được xem toàn bộ khách hàng của công ty hay chỉ dữ liệu mình phụ trách? Trưởng nhóm được xem những gì? Ai được sửa báo giá sau khi đã duyệt? Ai được export dữ liệu? Những câu hỏi này nghe có vẻ nhỏ nhưng nếu không thống nhất sớm, đến lúc hệ thống gần hoàn thành mới xử lý thì rất dễ ảnh hưởng tới nhiều phần đã xây trước đó.
Quan trọng nhất ở bước này là kiểm soát phạm vi. Khi bắt đầu thảo luận CRM, doanh nghiệp thường nghĩ thêm rất nhiều ý tưởng: KPI, công nợ, kho, ứng dụng mobile, tích hợp kế toán, chữ ký điện tử, AI, automation và nhiều chức năng khác. Phần lớn đều có ích, nhưng không có nghĩa phải làm hết ngay trong giai đoạn đầu. Một dự án tốt nên tách rõ phần lõi cần có để CRM vận hành và những phần có thể bổ sung sau, nhờ đó doanh nghiệp kiểm soát được cả ngân sách lẫn thời gian triển khai.
Ở SYP, đây cũng là lý do phạm vi thường được chia theo nhóm chức năng thay vì đưa ra một con số rồi gom tất cả nhu cầu vào cùng một gói. Doanh nghiệp có thể biết phần nào thực sự cần đầu tư ngay, phần nào chưa tạo nhiều giá trị ở thời điểm hiện tại và hoàn toàn có thể để sang giai đoạn tiếp theo.
Bước 3: Thiết kế cách người dùng sẽ thao tác trước khi làm toàn bộ hệ thống
Một quy trình có thể nghe rất hợp lý khi mô tả bằng lời nhưng lại trở nên bất tiện khi đưa lên giao diện. Vì vậy sau khi logic đã tương đối rõ, cần hình dung cụ thể người dùng sẽ thao tác như thế nào. Khi sales mở một khách hàng thì thông tin quan trọng nào cần xuất hiện trước? Tạo một Deal mới cần bao nhiêu bước? Báo giá được gửi đi phê duyệt ở đâu? Quản lý muốn xem tình hình đội sales thì mở màn hình nào?
Đây không chỉ là chuyện làm giao diện đẹp. Một CRM có thể rất hiện đại nhưng nếu nhân viên phải mở bốn màn hình chỉ để cập nhật một việc đơn giản thì sau vài tuần họ sẽ bắt đầu ngại sử dụng. Ngược lại, nếu những thứ thường dùng được đặt đúng chỗ và phần mềm phản ánh gần với cách nhân viên vốn đang suy nghĩ về công việc, thời gian học hệ thống sẽ ngắn hơn rất nhiều.
Giai đoạn này cũng là lúc nên đưa những người trực tiếp sử dụng vào xem. Quản lý có thể thiết kế một quy trình rất hợp lý trên giấy, nhưng người sales làm việc mỗi ngày thường nhìn ra ngay những điểm không thực tế. Một câu như “bình thường tụi em không có thông tin này ở bước này” có thể giúp tránh việc xây cả một luồng sai. Phát hiện vấn đề trước khi phát triển luôn rẻ và nhanh hơn nhiều so với sửa khi hệ thống đã hoàn thiện.
Bước 4: Phát triển từng phần và kiểm tra ngay trong quá trình làm
Khi phạm vi và cách sử dụng đã rõ, đội phát triển mới bắt đầu xây hệ thống. Tuy nhiên không nên làm toàn bộ CRM trong im lặng rồi tới cuối dự án mới đưa khách hàng xem lần đầu. Với một hệ thống có nhiều nghiệp vụ riêng, cách làm đó rất rủi ro vì chỉ cần một giả định ban đầu bị hiểu sai, hàng loạt chức năng phía sau có thể phải sửa theo.
Cách an toàn hơn là phát triển theo từng nhóm chức năng có liên quan. Có thể hoàn thành phần tài khoản và phân quyền trước, sau đó tới khách hàng và Contact, rồi Deal, Task, báo giá, dashboard và những nghiệp vụ riêng của doanh nghiệp. Khi một nhóm quan trọng hoàn thành, hai bên có thể xem lại và xác nhận cách hoạt động trước khi tiếp tục đi sâu hơn.
Việc demo trong quá trình phát triển không có nghĩa mỗi vài ngày lại thay đổi toàn bộ yêu cầu. Phạm vi chính vẫn phải được giữ ổn định để dự án không bị kéo dài vô hạn. Giá trị của việc kiểm tra thường xuyên nằm ở chỗ phát hiện những sai lệch nhỏ về cách hiểu: một dữ liệu nên nằm ở Contact thay vì Deal, một trạng thái cần đổi tên cho đúng ngôn ngữ nội bộ, hay một bước phê duyệt đang được đặt sai vị trí. Những chỉnh sửa nhỏ ở đúng thời điểm thường giúp hệ thống cuối cùng tự nhiên hơn rất nhiều khi đưa vào sử dụng.
Bước 5: Chạy bằng dữ liệu thật trước khi chính thức đưa vào sử dụng
Một CRM chạy mượt với vài dòng dữ liệu mẫu chưa nói lên nhiều điều. Khi đưa khách hàng thật, Deal thật, báo giá thật và nhiều người dùng thật vào hệ thống, rất nhiều tình huống mới bắt đầu xuất hiện. Có Contact trùng tên, có khách hàng thuộc nhiều dự án, có Deal không đi theo luồng thông thường, có báo giá phải sửa nhiều lần và cũng có trường hợp người dùng vô tình thao tác sai thứ tự.
Vì vậy trước khi Go-live, nên có giai đoạn chạy thử với một nhóm người sử dụng thực tế. Đây là lúc kiểm tra không chỉ phần mềm có lỗi hay không mà còn xem cách vận hành đã hợp lý chưa. Sales có tìm được thông tin đủ nhanh không, quản lý có nhìn được dữ liệu mình cần không, quyền truy cập có bị quá rộng hoặc quá hẹp không, và có bước nào khiến nhân viên phải nhập lại cùng một thông tin nhiều lần hay không.
Song song đó là việc chuẩn bị dữ liệu cũ, tài khoản người dùng, môi trường chạy chính thức và kế hoạch backup. Nếu doanh nghiệp có dữ liệu từ hệ thống trước thì cần xác định cái gì thực sự cần chuyển sang, thay vì bê toàn bộ dữ liệu cũ vào CRM mới chỉ vì sợ bỏ sót. Dữ liệu đầu vào càng sạch thì hệ thống mới càng dễ sử dụng sau này.
Đào tạo cũng nên đi theo công việc thật thay vì chỉ giới thiệu từng nút. Một sales nên được hướng dẫn theo câu chuyện “tôi vừa có khách hàng mới thì làm gì tiếp theo?”, trưởng nhóm cần biết “tôi muốn kiểm tra những Deal sắp quá hạn thì xem ở đâu?”, còn người duyệt báo giá cần hiểu chính xác việc nào đang chờ mình xử lý. Khi đào tạo bám vào tình huống hằng ngày, người dùng thường tiếp nhận hệ thống nhanh hơn nhiều so với việc học một danh sách chức năng.
Bước 6: Go-live rồi mới bắt đầu thấy CRM vận hành trong đời thật
Go-live là thời điểm CRM chuyển từ một dự án phần mềm thành một công cụ làm việc hằng ngày. Đây cũng là lúc những chi tiết nhỏ mà cả đội triển khai lẫn khách hàng chưa nhìn thấy trong giai đoạn test bắt đầu lộ ra. Có thể một nút đang đặt không thuận tay, một màn hình thiếu một thông tin mà sales cần nhìn liên tục, một thông báo đang xuất hiện quá nhiều hoặc một thao tác tưởng ít dùng nhưng thực tế lại xảy ra mỗi ngày.
Những điều này không nhất thiết có nghĩa phần mềm được thiết kế sai. Có những vấn đề chỉ có thể nhìn thấy khi nhân viên sử dụng thật trong vài tuần. Chính vì vậy quá trình triển khai CRM không nên kết thúc ngay khi hệ thống được đưa lên production. Cần có một giai đoạn theo dõi, sửa lỗi và tinh chỉnh những điểm nhỏ để phần mềm ngày càng sát với cách doanh nghiệp thực sự vận hành.
Với các dự án của SYP, sau khi hệ thống được đưa vào sử dụng chính thức sẽ có 6 tháng bảo hành. Ngoài việc xử lý lỗi, những điều chỉnh nhỏ liên quan tới luồng sử dụng hoặc UI/UX trong phạm vi đã thống nhất cũng có thể tiếp tục được trao đổi trong giai đoạn này. Mục tiêu không phải chỉ bàn giao một hệ thống chạy được, mà là đưa CRM tới trạng thái đủ ổn định để doanh nghiệp có thể sử dụng lâu dài mà không cần liên tục phụ thuộc vào đội phát triển.
Một dự án CRM tốt không bắt đầu từ code
Nhìn lại toàn bộ quá trình, phần viết code thực tế chỉ là một phần của dự án. Nếu khảo sát sai, phạm vi không rõ hoặc cách tổ chức dữ liệu không phù hợp thì đội phát triển có giỏi đến đâu vẫn có thể tạo ra một CRM không được người dùng đón nhận. Ngược lại, khi bài toán đã được hiểu rõ, phạm vi đủ gọn và người dùng được tham gia từ sớm, quá trình phát triển thường đơn giản và ít phải làm lại hơn rất nhiều.
Đó cũng là lý do khi tìm đơn vị triển khai CRM theo yêu cầu, doanh nghiệp không nên chỉ hỏi họ sử dụng công nghệ gì hoặc mất bao nhiêu ngày để code. Những câu hỏi quan trọng hơn là họ sẽ khảo sát quy trình bằng cách nào, cách nào để xác nhận hai bên đang hiểu giống nhau, khi nào người dùng được xem hệ thống, dữ liệu thật được kiểm tra ra sao và sau Go-live ai sẽ xử lý những vấn đề phát sinh.
Một CRM theo yêu cầu tốt không phải là quá trình biến một danh sách tính năng thành phần mềm. Nó là quá trình biến cách doanh nghiệp đang vận hành thành một hệ thống rõ ràng hơn, kiểm soát tốt hơn nhưng vẫn đủ tự nhiên để nhân viên muốn sử dụng mỗi ngày.