Khi doanh nghiệp bắt đầu số hóa, cách dễ nhất thường là mua từng thứ mình đang cần. Cần quản lý khách hàng thì mua CRM, cần giao việc thì mở thêm module công việc, cần KPI thì mua thêm KPI, cần phê duyệt thì tìm tiếp một module khác.
Cách này có một ưu điểm rất rõ: triển khai nhanh và không phải đầu tư lớn ngay từ đầu. Mỗi nhu cầu phát sinh lại có một công cụ giải quyết, nên trong giai đoạn đầu doanh nghiệp thường cảm thấy khá tiện.
Nhưng sau một thời gian, tôi thấy một vấn đề bắt đầu xuất hiện ở khá nhiều hệ thống dạng này: doanh nghiệp có ngày càng nhiều chức năng, nhưng chưa chắc đã có một hệ thống vận hành thực sự liền mạch.
Đây là khác biệt khá lớn giữa việc mua nhiều module và xây một phần mềm dựa trên chính quy trình của doanh nghiệp.
Có nhiều module chưa chắc đã có một hệ thống
Một số nền tảng SaaS tổ chức sản phẩm thành nhiều module riêng: CRM, công việc, KPI, nhân sự, phê duyệt, tài liệu và nhiều chức năng khác. Nhìn danh sách tính năng thì rất đầy đủ, nhưng khi đi vào sử dụng thực tế, các phần này đôi khi vẫn mang tính độc lập khá cao.
Lấy quản lý công việc làm ví dụ. Một module task có thể làm rất tốt chuyện giao việc, deadline, người phụ trách và trạng thái hoàn thành. Nhưng với doanh nghiệp bán hàng dự án, thứ người quản lý cần theo dõi thường không phải một task đứng riêng lẻ.
Công việc đó đang thuộc dự án nào? Dự án thuộc khách hàng nào? Sales nào đang phụ trách? Kỹ thuật đang xử lý phần gì? Báo giá hiện tại là revision nào? Sau khi công việc này hoàn thành thì dự án phải chuyển sang bước nào tiếp theo?
Nếu các phần này không được thiết kế ngay từ đầu để liên kết với nhau, doanh nghiệp vẫn có thể sở hữu rất nhiều module nhưng rất khó nhìn toàn bộ quá trình từ đầu tới cuối.
Đây cũng là cách tôi phân biệt giữa một tập hợp phần mềm và một phần mềm điều hành doanh nghiệp.
Một hệ thống điều hành tốt không nhất thiết phải có nhiều chức năng nhất. Quan trọng hơn là dữ liệu và các bước công việc có nối được với nhau theo đúng cách doanh nghiệp đang vận hành hay không.
Quá nhiều chức năng đôi khi lại làm người dùng khó làm việc hơn
Một sản phẩm được bán cho rất nhiều doanh nghiệp buộc phải đáp ứng rất nhiều nhu cầu khác nhau. Vì vậy giao diện thường phải chứa nhiều menu, nhiều nút, nhiều trường dữ liệu và nhiều lựa chọn để người dùng có thể tự cấu hình.
Điều này không có gì sai về mặt sản phẩm. Nhưng với một doanh nghiệp cụ thể, có thể 70 chức năng được cung cấp mà nhân viên chỉ thực sự cần 15 chức năng trong công việc hàng ngày.
Phần còn lại trở thành thứ người dùng phải học để biết rằng mình... không cần dùng.
Đây là vấn đề tôi đặc biệt để ý khi thiết kế CRM. Một nhân viên mở một dự án lên không nên mất thời gian suy nghĩ xem mình phải bấm nút nào trong hàng loạt lựa chọn. Nếu quy trình đã rõ thì giao diện cũng nên giúp họ hiểu được dự án đang ở bước nào, thông tin quan trọng nằm ở đâu và bước tiếp theo cần làm gì.
Vì vậy khi SYP xây phần mềm CRM theo yêu cầu, mục tiêu không phải là đưa càng nhiều chức năng lên màn hình càng tốt. Ngược lại, chúng tôi cố gắng bỏ bớt những thứ không cần thiết để hệ thống càng gần với công việc thực tế càng tốt.
Một CRM dành cho doanh nghiệp bán hàng dự án chẳng hạn có thể rất phức tạp ở phía sau, nhưng người sử dụng không nhất thiết phải cảm nhận được sự phức tạp đó. Sales chỉ cần nhìn vào và hiểu mình đang ở đâu trong luồng công việc.
Theo tôi, đây mới là giao diện tốt: logic bên trong có thể sâu, nhưng trải nghiệm bên ngoài phải đơn giản.
Có một khoảng cách khá lớn giữa người bán phần mềm và người thực sự xây phần mềm
Một điểm khác tôi từng gặp khi sử dụng và tìm hiểu các nền tảng lớn là khoảng cách giữa người dùng cuối và đội phát triển sản phẩm.
Một phần mềm có thể được phát triển bởi một công ty, sau đó phân phối qua đối tác, rồi tới đội sales, đội triển khai và đội support. Người doanh nghiệp trực tiếp trao đổi nhiều khi nằm khá xa những người thực sự thiết kế logic của hệ thống.
Khi câu hỏi chỉ là “chức năng này nằm ở đâu?” thì mô hình đó hoạt động rất tốt. Nhân viên hỗ trợ chỉ cần hướng dẫn đúng tài liệu.
Nhưng câu hỏi của doanh nghiệp đôi khi lại là:
Công ty tôi hiện đang làm theo quy trình này, vậy nên thiết kế hệ thống như thế nào để vừa kiểm soát được nhân viên vừa không làm quy trình quá cứng?
Đây không còn là câu hỏi hướng dẫn sử dụng.
Nó là câu hỏi về thiết kế hệ thống.
Nếu người tư vấn chỉ biết sản phẩm ở mức sử dụng, câu trả lời rất dễ quay về kiểu “phần mềm hiện hỗ trợ chức năng A, B, C” hoặc hướng dẫn doanh nghiệp điều chỉnh quy trình để vừa với sản phẩm.
Với SYP thì khoảng cách này ngắn hơn nhiều vì chính đội ngũ tư vấn cũng tham gia vào việc phân tích và phát triển hệ thống. Khi khách hàng nói một luồng công việc có vấn đề, chúng tôi có thể nhìn trực tiếp vào logic phía sau để xem nên thay đổi ở giao diện, workflow, phân quyền hay cấu trúc dữ liệu.
Đặc biệt với những CRM bán hàng dự án có logic khá sâu, điều này theo tôi quan trọng hơn rất nhiều so với việc phần mềm có thêm vài chục tính năng.
Tập trung không phải là có thật nhiều module trong một tài khoản
Khái niệm “all-in-one” nghe rất hấp dẫn. Một nhà cung cấp có thể có CRM, công việc, KPI, nhân sự, tài liệu và hàng loạt module khác dưới cùng một thương hiệu.
Nhưng với tôi, tập trung không phải là nhìn thấy nhiều icon trong cùng một menu.
Tập trung nghĩa là khi mở một dự án, tôi có thể hiểu được toàn bộ ngữ cảnh của dự án đó mà không phải đi tìm thông tin ở nhiều nơi.
Khách hàng là ai, những contact nào liên quan, lịch sử làm việc trước đây ra sao, ai đang phụ trách, công việc nào đang mở, kỹ thuật đang xử lý vấn đề gì, báo giá nào đã gửi, file nào thuộc dự án và bước tiếp theo là gì.
Nếu những thứ này được thiết kế quanh cùng một đối tượng và cùng một luồng nghiệp vụ thì người dùng có cảm giác đang làm việc trong một hệ thống.
Ngược lại, nếu mỗi phần là một module gần như độc lập, người dùng vẫn phải chuyển qua nhiều khu vực, đôi khi nhiều ứng dụng hoặc nhiều tài khoản khác nhau để ghép lại toàn bộ câu chuyện.
SYP đi theo hướng tập trung này: ít hơn nhưng liên kết sâu hơn. Không cố biến phần mềm thành một siêu ứng dụng chứa mọi thứ trên đời, mà đưa những thứ thật sự liên quan tới quy trình của doanh nghiệp về cùng một hệ thống.
Chi phí SaaS không chỉ nằm ở con số nhìn thấy lúc đăng ký
Một điểm khác doanh nghiệp nên tính trước khi chọn mô hình module là cấu trúc chi phí.
Giá ban đầu của SaaS thường khá dễ tiếp cận. Nhưng khi công ty tăng số nhân viên, chi phí có thể tăng theo số user. Khi muốn mở thêm module, dùng chức năng nâng cao hoặc nâng giới hạn, doanh nghiệp có thể phải chuyển sang gói cao hơn.
Mỗi khoản riêng lẻ thường không quá lớn. Nhưng khi cộng lại trong nhiều năm thì câu chuyện có thể khác.
Custom software của SYP đi theo mô hình khác. Phạm vi dự án được thống nhất từ đầu và giá được tính theo hệ thống cần xây, không phải cứ tuyển thêm một nhân viên là phần mềm lại tăng một license hàng tháng.
Sau khi hệ thống production, SYP hiện áp dụng 6 tháng bảo hành. Ngoài việc xử lý lỗi, đây cũng là khoảng thời gian hai bên có thể trao đổi những điều chỉnh nhỏ nằm trong phạm vi đã thống nhất, đặc biệt là giao diện hoặc những điểm trong luồng sử dụng mà chỉ khi nhân viên dùng thực tế mới nhận ra cần tối ưu thêm.
Điều này khá quan trọng vì có những thao tác nhìn trên thiết kế thấy hợp lý nhưng sau một tháng sử dụng mỗi ngày mới thấy thừa một bước hoặc đặt nút chưa đúng chỗ.
Phần mềm riêng vì vậy không nên được hiểu là “làm xong rồi đóng lại”, mà là một hệ thống được đưa vào sử dụng và tiếp tục tinh chỉnh để phù hợp hơn với vận hành thực tế.
Với phần mềm dùng chung, doanh nghiệp không quyết định được sản phẩm sẽ thay đổi như thế nào
SaaS là một sản phẩm phục vụ rất nhiều khách hàng nên việc cập nhật phải được quyết định dựa trên toàn bộ sản phẩm.
Nhà cung cấp có thể thay giao diện, thay cách tổ chức chức năng, nâng cấp workflow hoặc ngừng một tính năng cũ để chuyển sang cách mới. Những thay đổi đó có thể rất tốt đối với phần đông người dùng, nhưng một doanh nghiệp riêng lẻ gần như không có quyền nói rằng:
Hệ thống của công ty tôi đang chạy ổn, phần này tôi không muốn thay đổi.
Đó là bản chất của việc thuê một sản phẩm dùng chung.
Custom software khác ở chỗ hệ thống được xây cho chính doanh nghiệp đó. Nếu một chức năng đang chạy ổn thì không có lý do gì phải thay đổi chỉ vì một nhóm khách hàng khác muốn sản phẩm đi theo hướng mới.
Doanh nghiệp có quyền quyết định khi nào nâng cấp, nâng cấp cái gì và việc thay đổi đó có thực sự mang lại giá trị hay không.
Theo tôi đây là một quyền khá quan trọng nhưng thường ít được nhắc tới: quyền quyết định phần mềm của công ty mình sẽ phát triển theo hướng nào.
Và cuối cùng là câu hỏi: dữ liệu của doanh nghiệp đang nằm ở đâu?
Đây là chuyện tôi nghĩ đặc biệt đáng quan tâm với CRM.
Danh sách khách hàng, contact, pipeline, báo giá và lịch sử các dự án đều là dữ liệu thuộc về doanh nghiệp. Với SaaS, dữ liệu đó vẫn là dữ liệu của khách hàng, nhưng database và hạ tầng phía dưới thường nằm trên hệ thống do nhà cung cấp quản lý.
Điều đó không có nghĩa SaaS không an toàn. Những nhà cung cấp lớn có thể có năng lực bảo mật rất tốt.
Nhưng quyền kiểm soát cuối cùng đối với hạ tầng không nằm hoàn toàn trong tay doanh nghiệp.
Với phần mềm riêng, doanh nghiệp có thêm lựa chọn. Database có thể đặt trên VPS riêng, cloud riêng hoặc server ngay tại công ty. Domain và các tài khoản hạ tầng cũng có thể đứng tên doanh nghiệp, còn SYP chỉ chịu trách nhiệm triển khai và hỗ trợ kỹ thuật.
Với doanh nghiệp nhỏ, server cũng không nhất thiết phải là một hệ thống đắt tiền. Nếu tải chỉ vài chục người dùng, một máy phù hợp có sẵn tại công ty trong nhiều trường hợp đã có thể sử dụng, miễn được cấu hình, backup và bảo mật đúng cách.
Điểm tôi quan tâm không phải là “cloud tốt hơn hay server nội bộ tốt hơn”.
Câu hỏi quan trọng hơn là:
Nếu ngày mai doanh nghiệp muốn đổi đơn vị phát triển, toàn bộ hệ thống và dữ liệu có thực sự nằm trong quyền kiểm soát của mình hay không?
Vậy nên mua thêm module hay xây một hệ thống riêng?
Nếu từng nghiệp vụ khá tiêu chuẩn và ít phụ thuộc vào nhau, mua module là phương án rất hợp lý. Không có lý do gì phải tự xây một chức năng đã có sản phẩm ngoài thị trường làm rất tốt.
Nhưng khi các nghiệp vụ bắt đầu chạy thành một chuỗi và dữ liệu của bước trước quyết định bước sau — đặc biệt trong bán hàng dự án, kỹ thuật hoặc những doanh nghiệp có quy trình riêng đã hình thành qua nhiều năm — việc tiếp tục mua thêm module chưa chắc giải quyết được vấn đề.
Có thể doanh nghiệp sẽ có thêm chức năng, nhưng chưa chắc có thêm sự rõ ràng.
Lúc đó tôi nghĩ nên đổi câu hỏi.
Thay vì hỏi:
“Còn thiếu module nào để mua thêm?”
hãy thử hỏi:
“Nếu xây lại từ chính cách công ty đang vận hành, hệ thống nên được tổ chức như thế nào?”
Hai cách tiếp cận dẫn tới hai loại phần mềm rất khác nhau.
Một bên là tập hợp những sản phẩm được thiết kế để phục vụ nhiều doanh nghiệp.
Một bên là một hệ thống được thiết kế để phục vụ chính doanh nghiệp của mình.
Và nếu quy trình vận hành đã trở thành một phần quan trọng trong cách công ty cạnh tranh, tôi nghĩ phương án thứ hai ngày càng đáng để đưa lên bàn tính.