Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Đừng so ba loại phần mềm này bằng bảng tính năng. So bằng phạm vi lan của một thay đổi dữ liệu: sửa một con số thì bao nhiêu bộ phận phải biết.
Trong một buổi khảo sát ở doanh nghiệp thương mại quy mô vừa, anh giám đốc nghe hai mươi phút rồi đặt một câu rất thẳng: bên anh chạy phần mềm kế toán nhiều năm nay không vấn đề gì, đội sale đang dùng một công cụ khác để theo dõi khách hàng, vậy hệ thống em nói có gì khác, hay chỉ là gộp hai thứ đó lại cho gọn.
Nếu lúc đó bạn mở bảng phân hệ ra và đọc tên từng cái thì bạn thua ngay tại chỗ, bởi phần mềm kế toán của anh ấy cũng nhập được đơn hàng, cũng in được phiếu, cũng có một chỗ ghi tồn kho, và xét theo danh sách thì trông chẳng thiếu gì so với thứ bạn đang giới thiệu.
Câu trả lời không nằm ở danh sách. Câu hỏi đáng hỏi ngược lại là: khi kế toán sửa một con số trên sổ vào chín giờ sáng, tới trưa có ai khác trong công ty biết chuyện đó chưa, và biết bằng cách nào. Câu trả lời quen thuộc là: thì kế toán biết thôi, ai cần thì gọi hỏi.
Đó mới là ranh giới thật giữa ba loại phần mềm. Cách đo dùng được ngay khi cần phân loại nhanh là phạm vi lan của một thay đổi dữ liệu: bạn chọn một dữ liệu bất kỳ, giả định có người sửa nó vào đầu giờ sáng, rồi đếm xem trong ngày hôm đó bao nhiêu bộ phận phải biết chuyện vừa xảy ra, và hệ thống có tự làm cho họ biết hay phải có người cầm điện thoại lên gọi để thông báo.
Bảng tick tính năng trả lời câu hỏi hệ thống có chứa thành phần nào, còn phạm vi lan trả lời câu hỏi hệ thống có nối được các bộ phận với nhau hay không, mà đó mới là thứ doanh nghiệp thật sự đi mua.
Luận điểm ERP là một cơ sở dữ liệu duy nhất thì tôi đã nói riêng.
Một phần mềm kế toán được thiết kế để ghi nhận kết quả của hoạt động kinh doanh chứ không phải để điều khiển hoạt động đó, và mọi đặc điểm của nó đi ra từ đây.
Khi kế toán sửa một bút toán, đổi một số dư hay điều chỉnh một dòng công nợ, phạm vi lan dừng trong chính phòng kế toán, cộng thêm báo cáo gửi lên ban giám đốc cuối kỳ. Kho không nhận được gì, sale cũng không.
Chiều ngược lại còn quan trọng hơn. Nếu kho xuất nhầm hàng lúc mười giờ sáng thì phần mềm kế toán không biết, nó chỉ biết khi có người ngồi gõ lại con số đó vào, thường là vài ngày sau.
Nên nhớ rằng đây là đặc điểm thiết kế chứ không phải khuyết điểm, bởi với doanh nghiệp mà phần lớn việc phối hợp diễn ra gọn trong một hai phòng thì vòng khép kín này đủ dùng, và chuyện khi nào chưa cần tới ERP là một chủ đề riêng.
CRM lan rộng hơn phần mềm kế toán, nhưng lan theo một chiều rất khác, và dữ liệu chính của CRM là thông tin về khả năng bán được: khách hàng tiềm năng, cơ hội, giai đoạn cơ hội đang đứng, doanh thu và ngày đóng dự kiến.
Khi một nhân viên sale kéo cơ hội sang giai đoạn kế tiếp hoặc sửa ngày đóng dự kiến, báo cáo dự báo doanh thu mà giám đốc kinh doanh đang nhìn đổi ngay lập tức, và trưởng nhóm cũng thấy pipeline của nhóm mình đổi theo.
Tuy nhiên, hãy để ý cái không xảy ra. Kho không nhúc nhích, không phiếu nào được sinh ra, kế toán không ghi nhận gì. Phạm vi lan của CRM rộng về phía báo cáo nhưng nông về phía vận hành, bởi dữ liệu của nó nói về khả năng chứ không nói về nghĩa vụ.
Từ đó suy ra ranh giới. CRM kết thúc ở điểm chốt deal; sau điểm đó thứ chạy tiếp là đơn hàng, và cách một cơ hội biến thành đơn hàng là một dòng chảy riêng, thuộc bài khác. Còn giai đoạn sau khi khách đã mua, gồm bảo hành và khiếu nại, thì không thuộc CRM mà thuộc một phân hệ khác chuyên xử lý yêu cầu sau bán.
Hậu quả của việc bỏ qua ranh giới này rất cụ thể. Khách nghe hai chữ quản lý khách hàng thường hiểu là gồm cả chăm sóc sau bán, nên nếu bạn không tách ra ngay từ buổi khảo sát thì phân hệ helpdesk sẽ xuất hiện lúc nghiệm thu như một thứ đáng lẽ phải có.
Đặc biệt trên Odoo thì theo kiểm tra mã nguồn phiên bản Community 19, phân hệ helpdesk không nằm trong bản miễn phí, nghĩa là cái khách tưởng đã mua thực ra là một khoản chưa ai báo giá.
Nói cách khác, ranh giới của CRM không nằm ở chỗ khách hàng ngừng là khách hàng, mà nằm ở chỗ dữ liệu ngừng nói về khả năng bán được và bắt đầu nói về nghĩa vụ đã cam kết.
Sang tới ERP thì cách đo đó cho kết quả khác hẳn, và tôi lấy một ví dụ nhỏ tới mức nhiều người bỏ qua.
Trên Odoo, mỗi sản phẩm có một ô cấu hình chính sách lập hóa đơn với hai lựa chọn: xuất hóa đơn theo số lượng đã đặt, hoặc xuất theo số lượng đã giao. Người bấm vào ô đó thường là người triển khai, thao tác mất ba giây, và nó nằm trong màn hình sản phẩm chứ không gần phòng kế toán.
Bây giờ đếm xem ai chịu ảnh hưởng. Nếu chọn theo số lượng đã giao, kho ghi nhận giao năm cái vào buổi sáng thì kế toán chỉ xuất được hóa đơn cho đúng năm cái, giao tiếp bốn cái thì hóa đơn kế tiếp ra bốn, còn trước khi kho làm gì thì đơn mang trạng thái không có gì để xuất và nút tạo hóa đơn màu xanh quen thuộc biến mất khỏi màn hình.
Có một chi tiết dễ làm kế toán bối rối mà bạn nên biết trước để giải thích: đúng chỗ nút vừa biến mất, Odoo lại hiện lên một nút cũng mang chữ Create Invoice nhưng là một nút khác, và nút này bấm vào được chứ không hề bị làm mờ.
Chỉ có điều nó mở trình hướng dẫn tạm ứng chứ không lập hóa đơn cho các dòng hàng, nên thứ nhận về là một hóa đơn tạm ứng vỏn vẹn một dòng, còn trạng thái hóa đơn của đơn gốc thì vẫn nằm nguyên ở không có gì để xuất.
Nhân viên bán hàng nhìn trên đơn biết đã giao và đã xuất hóa đơn bao nhiêu, còn con số công nợ phải thu ban giám đốc xem cuối tháng cũng đổi theo. Một ô chọn, bốn nhóm người chịu ảnh hưởng, tất cả đều nắm thông tin không ai phải gọi điện cho ai.
Một phần mềm kế toán đứng riêng hay một CRM đứng riêng không tạo ra được phạm vi lan đó, bởi để lan được thì cả bốn nhóm người kia phải đang ghi vào cùng một chỗ.
Đồng thời, chính chỗ mạnh này là chỗ đắt: thay đổi đúng lan được thì thay đổi sai cũng lan được, và một cấu hình đặt nhầm ở màn hình sản phẩm sẽ hiện ra, trở thành tranh cãi giữa kho và kế toán sau vài tuần.
Hai kiểu đầu đều đi ra từ chuyện nhầm bài toán một phòng với bài toán chỗ nối, và bài về khi nào doanh nghiệp thực sự cần ERP đã đi hết chuyện đó.
Kiểu thứ ba tinh vi hơn hai kiểu kia, là mua đúng loại nhưng sai mô hình vận hành. Một chuỗi bán lẻ thu tiền ngay tại quầy không có công nợ để quản lý, nên luồng bán theo đơn rồi xuất hóa đơn không dành cho họ.
Và doanh nghiệp bán thẳng cho người tiêu dùng tại cửa hàng cũng gần như không có gì để làm CRM quản lý, bởi hành trình từ lúc khách quan tâm tới lúc trả tiền chỉ diễn ra vỏn vẹn trong vài phút.
Cách làm dưới đây chỉ cần một buổi và không cần dựng hệ thống nào: bạn chọn một chứng từ thật mà doanh nghiệp đang dùng hằng ngày, rồi đi ngược theo nó. Cách chạy thì đơn giản, còn ngưỡng để kết luận thì thuộc về bài khi nào doanh nghiệp thực sự cần ERP.
Trong buổi khảo sát, bạn chạy năm việc sau:
Nếu mọi thứ diễn ra trong một phòng và không ai phải gõ lại gì, thứ doanh nghiệp cần là một phần mềm chuyên biệt cho phòng đó, và bạn nên nói thẳng như vậy dù nó làm hụt doanh số bên bạn.
Ngược lại, nếu có một nhân sự mà cả công ty phải hỏi mới biết số thật, bài toán nằm ở chỗ nối, và lúc đó bạn mới có cơ sở để bàn tới hệ thống dùng chung dữ liệu.
Có mấy chỗ cần nói thẳng, nếu không bạn sẽ dùng cách đo trên rất máy móc.
Đầu tiên, ba cái tên này không phải ba nhóm sản phẩm tách bạch trên thị trường, bởi một hệ ERP luôn chứa bên trong nó một phân hệ quan hệ khách hàng và một phân hệ tài chính, còn nhiều sản phẩm bán dưới tên CRM đã mở rộng tới báo giá và hóa đơn từ lâu. Chữ ghi trên vỏ hộp không nói được gì.
Tiếp theo, câu nói ERP thay được phần mềm kế toán phải kiểm lại theo từng bản chứ không đúng sẵn, bởi riêng với Odoo thì phần kế toán trong bản cộng đồng dừng ở mức ghi nhận hóa đơn và công nợ, còn các phần chuyên sâu hơn nằm ở những module thuộc bản trả phí.
Cuối cùng là một ngoại lệ hay gặp, khi doanh nghiệp cố ý giữ phần mềm kế toán cũ và chỉ đối chiếu số liệu theo kỳ với hệ thống mới. Cách làm này không sai, và quyết định thuộc về kế toán trưởng chứ không thuộc về bạn; việc của bạn là buộc hai bên trả lời dứt khoát rằng với mỗi loại dữ liệu thì bản ghi nào là bản gốc và ai được quyền sửa.
Và ngay khi đo phạm vi lan cho từng loại dữ liệu, bạn sẽ thấy chúng không lan giống nhau: có loại đứng yên làm gốc cho hàng nghìn chứng từ khác, có loại sinh ra theo từng giao dịch rồi nằm im, và phân biệt được hai loại đó sẽ quyết định thứ tự bạn phải làm khi triển khai.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận