Mona Media
Top 7 sai lầm thường gặp về chuyển đổi số là những cái bẫy đội ngũ chúng tôi chứng kiến lặp đi lặp lại qua nhiều dự án tư vấn và triển khai. Có lỗi khiến doanh nghiệp nhỏ mất tiền oan, mất cả năm trời, rồi phải quay lại vạch xuất phát. Danh sách này không phải sưu tầm cho vui. Đây là những gì chúng tôi thấy tận mắt.
Chúng tôi làm giải pháp số cho doanh nghiệp nhỏ và vừa nhiều năm nay. Số dự án phải “cứu” giữa đường nhiều hơn số dự án chạy trơn tru ngay từ đầu. Lý do hiếm khi nằm ở phần mềm dở. Nó nằm ở thứ tự làm việc. Và ở vài quyết định tưởng nhỏ nhưng hậu quả kéo dài.
Bài này dành cho chủ doanh nghiệp và người phụ trách vận hành đang chuẩn bị làm lại hệ thống. Bạn đọc để soi lại kế hoạch của mình, không phải để làm theo răm rắp. Chỗ nào chưa chắc chắn, chúng tôi sẽ nói rõ là chưa chắc.
Vì sao sai lầm chuyển đổi số hiếm khi nằm ở công nghệ
Khi một dự án chuyển đổi số đổ vỡ, phản ứng đầu tiên của chủ doanh nghiệp thường là đổi nhà cung cấp. Họ nghĩ phần mềm cũ chưa đủ tốt. Lần sau họ mua phần mềm đắt hơn, nhiều tính năng hơn. Kết quả vẫn vậy.
Vấn đề nằm ở chỗ khác. Phần lớn thất bại đến từ việc chọn sai thứ tự ưu tiên. Quy trình chưa rõ mà đã mua công cụ. Người chịu trách nhiệm chưa có mà đã họp bàn. Chỉ số đo lường chưa chốt mà đã bấm nút chạy. Công nghệ chỉ là phương tiện. Nó khuếch đại cái đang có, kể cả cái sai.
Một ví dụ dễ thấy. Doanh nghiệp bán hàng online có bốn nhân viên xử lý đơn theo cách riêng mỗi người. Họ mua phần mềm quản lý đơn hàng để “chuyên nghiệp hóa”. Phần mềm chạy tốt. Nhưng vì bốn người ghi chú đơn theo bốn kiểu khác nhau, dữ liệu nhập vào lộn xộn. Báo cáo xuất ra không dùng được. Sau ba tháng, cả nhóm quay lại dùng file Excel. Tiền phần mềm coi như mất.
Ba tiêu chí để chúng tôi chọn ra 7 sai lầm dưới đây. Một là lặp lại nhiều nhất ở doanh nghiệp nhỏ và vừa. Hai là hậu quả kéo dài, không sửa một sớm một chiều. Ba là có thể tránh được nếu biết trước vài điều cơ bản.
Sai lầm #1: Đặt công nghệ lên trước quy trình
Biểu hiện quen thuộc nhất là mua phần mềm trước, vẽ lại luồng công việc sau. Hoặc tệ hơn, không vẽ gì cả. Nhân viên được giao tài khoản đăng nhập rồi tự mò.
Kết quả thế nào? Mỗi người dùng một nửa tính năng. Người nhập liệu ở phần mềm mới, người duyệt vẫn ký giấy. Dữ liệu nằm hai nơi. Sếp hỏi số liệu, không ai dám chắc con số nào đúng. Hệ thống mới thành gánh nặng thêm, chứ không phải bớt việc.
Nguyên lý ở đây khá đơn giản. Phần mềm được thiết kế theo một quy trình chuẩn nào đó. Nếu quy trình của bạn khác, bạn phải uốn nắn một trong hai. Uốn phần mềm thì tốn tiền tùy chỉnh. Uốn con người thì tốn thời gian và dễ thất bại. Uốn trước khi mua luôn rẻ hơn cả hai.
Chúng tôi thường khuyên làm một việc nhỏ trước khi ký hợp đồng. Vẽ luồng công việc hiện tại ra giấy, từ lúc khách đặt đến lúc thu tiền. Đánh dấu chỗ nào đang chậm, chỗ nào hay sai. Bản vẽ này chỉ mất một buổi, nhưng nó là bản đối chiếu tốt nhất khi chọn phần mềm.
Một cái bẫy trong chính bước vẽ này là vẽ quy trình “lý tưởng”. Tức là vẽ cái mình muốn, không phải cái đang diễn ra. Bạn nên vẽ thật. Có chỗ nhân viên kẹp giấy nhớ vào hồ sơ vì phần mềm cũ không có ô ghi chú. Chi tiết đó quan trọng hơn bạn tưởng.
Kinh nghiệm của chúng tôi là chọn một quy trình nhỏ nhất, có tần suất cao nhất để làm thí điểm. Ví dụ quy trình xác nhận đơn hàng, chứ không phải toàn bộ khâu bán hàng. Chạy thử hai tuần. Nếu nhân viên tự nguyện dùng tiếp, bạn biết mình chọn đúng. Nếu phải nhắc mỗi ngày, dừng lại xem xét.
Lời khuyên này có hạn chế thật. Với doanh nghiệp cực nhỏ, dưới năm người, làm quy trình trước đôi khi làm chậm tiến độ không cần thiết. Ở quy mô đó, cả nhóm ngồi chung một phòng, quy trình truyền miệng vẫn chạy được. Bạn cứ chọn công cụ dễ dùng, dùng ngay, rồi chuẩn hóa dần. Khi chọn công cụ, cũng nên xem qua vài điều cần biết trước khi làm lại hệ thống, vì cái sai ở bước này thường chỉ lộ ra sau vài tháng vận hành.
Sai lầm #2: Chọn nền tảng theo quảng cáo thay vì theo nhu cầu
Đây là lỗi tốn tiền nhiều nhất, vì hậu quả trải dài nhiều năm. Doanh nghiệp xem quảng cáo, nghe hội thảo, thấy demo đẹp, rồi chốt. Không ai hỏi câu quan trọng nhất: ba năm nữa tôi có lấy được dữ liệu ra không?
Trước khi so sánh, cần nói rõ mấy khái niệm cho người ngoài nghề. Website tự xây là đội của bạn hoặc đơn vị thuê làm riêng cho bạn, mã nguồn thuộc về bạn. CMS đóng là phần mềm có sẵn nhưng cài trên hạ tầng của bạn. SaaS thuê bao là trả tiền hàng tháng để dùng trên hệ thống của nhà cung cấp. Nền tảng all-in-one là một gói ôm hết, từ bán hàng đến email, nhưng dữ liệu nằm trong hệ sinh thái của họ.
Cách chúng tôi thường đặt vấn đề với khách là nhìn vào tổng chi phí sở hữu trong ba năm, không phải giá niêm yết tháng đầu. Một gói thuê bao có thể rẻ bằng một phần ba gói tự xây ở năm đầu. Nhưng đến năm thứ ba, khi số người dùng tăng và phát sinh nhu cầu tùy chỉnh, nó có thể vượt xa. Đừng quên các chi phí ẩn như đào tạo, tích hợp và phí tăng theo số tài khoản.
Một điểm nữa ít ai để ý là khả năng xuất dữ liệu. Bạn nên hỏi thẳng: xuất được định dạng gì, mất bao lâu, có tính phí không. Có nền tảng cho xuất file chuẩn. Có nền tảng chỉ cho xuất PDF, nghĩa là đọc được nhưng không nhập lại vào hệ thống khác được. Sự khác biệt này chỉ lộ ra khi bạn muốn đổi nhà cung cấp, và lúc đó thì đã muộn.
Mức độ phụ thuộc nhà cung cấp cũng là tiêu chí đáng cân. Hỏi một câu đơn giản: nếu mai họ tăng giá gấp đôi, tôi có đường lùi không. Nếu câu trả lời là “không rõ”, bạn đang ở thế yếu. Với doanh nghiệp chưa có nhân sự IT riêng, rủi ro này cao hơn hẳn. Bạn có thể tham khảo các mức độ sở hữu website khác nhau để hiểu rõ hơn, trước khi quyết định thuê hay tự xây.
Sai lầm #3: Không có người chịu trách nhiệm cuối cùng
Dự án có năm người bàn nhưng không ai quyết. Cuộc họp nào cũng kết thúc bằng câu “để em hỏi lại sếp”. Ba tuần sau vẫn chưa chọn được phiên bản nào.
Triệu chứng này dễ nhận ra nếu bạn để ý. Biên bản họp toàn câu hỏi, ít câu chốt. Danh sách việc cần làm dài ra nhưng không có mục nào đánh dấu xong. Nhà cung cấp gửi ba phương án, không ai phản hồi trong hai tuần.
Vì sao đây là nguyên nhân trì hoãn phổ biến hơn cả thiếu ngân sách? Vì thiếu tiền thì biết ngay, còn thiếu người quyết thì âm thầm. Ngân sách thiếu có thể xoay. Thời gian trôi qua thì không lấy lại được. Mỗi tháng chậm là một tháng đối thủ chạy trước.
Chúng tôi thường đề nghị một cơ chế đơn giản. Chọn một người làm chủ dự án, có quyền quyết trong phạm vi ngân sách đã duyệt. Người này không nhất thiết phải là sếp. Quan trọng là họ có quyền chốt phương án A hay B mà không phải xin ý kiến từng lần.
Một mẹo nhỏ nhưng hiệu quả: ghi rõ người quyết vào biên bản họp đầu tiên. “Anh Nam chịu trách nhiệm chốt phương án nền tảng trước ngày 15.” Có tên, có hạn, có phạm vi. Không có ba thứ đó thì trách nhiệm chỉ là danh nghĩa.
Tình huống này hay gặp ở doanh nghiệp gia đình hoặc ban lãnh đạo đồng quyền. Ở mô hình đó, ai cũng có tiếng nói, nên không ai muốn là người quyết sai. Cách xử lý là tách quyết định lớn và quyết định nhỏ. Việc lớn cả nhà bàn. Việc nhỏ giao một người, và cả nhà cam kết không xen vào.
Hạn chế thật là mô hình “một người quyết” không phù hợp với tổ chức có nhiều mảng kinh doanh độc lập. Ví dụ một công ty vừa làm bán lẻ vừa làm xây dựng, hai mảng cần hai hệ thống khác nhau. Lúc đó nên có người quyết riêng cho từng mảng, chỉ gặp nhau ở cấp ngân sách.
Sai lầm #4: Đo lường sai chỉ số ngay từ đầu
Báo cáo cuối kỳ ghi “lượt truy cập tăng 40%”. Sếp hỏi vậy doanh thu tăng không. Không ai trả lời được. Đây là kiểu báo cáo phổ biến nhất và vô dụng nhất.
Nguyên nhân nằm ở chỗ chốt chỉ số quá muộn. Khi dự án đã chạy, người ta mới ngồi tìm xem nên đo cái gì. Lúc đó dữ liệu cũ không có, không so sánh được. Thành ra báo cáo chỉ còn mấy con số dễ lấy như lượt truy cập, số người theo dõi, số bài đăng.
Cách làm của chúng tôi là chốt chỉ số trước khi triển khai, nhóm theo mục tiêu. Mỗi nhóm chỉ cần vài số cụ thể. Nhóm bán hàng thì nhìn số đơn mỗi tuần, giá trị trung bình mỗi đơn, và tỷ lệ đơn hoàn thành trên tổng đơn tạo ra. Nhóm vận hành thì để ý thời gian xử lý một đơn từ lúc nhận đến lúc giao, cùng số lần phải làm lại do sai sót. Nhóm khách hàng thì theo dõi tỷ lệ khách quay lại mua lần hai.
Danh sách này nên chốt thành văn bản trước khi ký hợp đồng. Mỗi chỉ số cần ghi rõ ba thứ. Lấy từ đâu. Đo bằng cách nào. Ai chịu trách nhiệm cập nhật. Không có ba thông tin đó thì chỉ số chỉ để trang trí.
Có một điều chúng tôi phải nói thẳng vì chưa chắc chắn. Một số ngành khó gắn trực tiếp chuyển đổi số với doanh thu trong sáu tháng đầu. Ví dụ ngành dịch vụ chuyên môn, chu kỳ quyết định của khách dài, có khi cả năm. Với những ngành này, nên đặt chỉ số trung gian rõ ràng. Ví dụ số cuộc hẹn tư vấn đặt được mỗi tháng, hoặc thời gian phản hồi khách trung bình. Có trung gian rồi mới nối được tới doanh thu sau này.
Đừng đo quá nhiều chỉ số. Ba đến năm số là đủ cho một giai đoạn. Nhiều hơn thì không ai xem, và bạn sẽ mất thời gian thu thập. Khi cần đọc báo cáo kỹ thuật từ đơn vị SEO, có những khái niệm cơ bản nên nắm trước. Bạn có thể xem qua kiến thức SEO nền tảng để không bị lạc khi đọc số liệu.
Sai lầm #5: Coi chuyển đổi số là dự án một lần rồi đóng lại
Giai đoạn một hoàn thành. Hệ thống chạy. Mọi người mừng. Rồi ai về việc nấy, không ai đụng tới nữa. Hai năm sau, hệ thống lạc hậu, dữ liệu bẩn, nhân viên mới không ai biết dùng.
Đây là lỗi gần như doanh nghiệp nào cũng mắc, chỉ là ở giai đoạn hai đến ba năm sau triển khai. Lúc đó, cảm giác “xong rồi” rất mạnh. Ngân sách chuyển sang việc khác. Đội dự án giải tán. Không ai còn nhớ cấu hình ban đầu.
Thực tế vận hành khác hẳn. Hệ thống cần vòng lặp cải tiến theo quý, không phải kế hoạch một năm đóng băng. Mỗi quý nhìn lại ba câu: chỉ số nào đang xấu đi, quy trình nào đang bị vòng vo, nhân viên đang phàn nàn điều gì. Ba câu này đủ để ra vài việc nhỏ cho quý sau.
Chúng tôi hay so sánh với việc bảo dưỡng xe. Bạn không mua xe rồi để đó hai năm không thay dầu. Hệ thống số cũng vậy. Không cần đại tu mỗi quý. Nhưng cần một buổi rà soát, một danh sách việc nhỏ, và một người theo.
Cách nhẹ nhất là giữ một buổi mỗi quý, có mặt người vận hành và người kỹ thuật. Một buổi, hai giờ, bốn lần một năm. Chi phí thấp hơn nhiều so với việc để hai năm rồi phải làm lại.
Buổi rà soát này cũng là lúc bạn nhìn lại các xu hướng tối ưu hiện diện số đang thay đổi, đặc biệt với website bán hàng nhỏ. Các xu hướng tối ưu hiện diện số cho website bán hàng nhỏ là loại thông tin nên cập nhật mỗi năm một lần, không cần nhiều hơn.
Sai lầm #6: Bỏ quên dữ liệu và quyền sở hữu dữ liệu
Đây là sai lầm mà hậu quả chỉ lộ ra khi bạn muốn đổi nhà cung cấp. Lúc đó bạn mới phát hiện dữ liệu khách hàng ba năm không xuất được ra định dạng dùng được. Hoặc xuất được nhưng tốn phí. Hoặc tệ hơn, không xuất được vì điều khoản hợp đồng không cho.
Có bốn câu hỏi bạn nên hỏi nhà cung cấp trước khi ký. Hỏi bằng văn bản, ghi vào hợp đồng, đừng chỉ nghe trả lời miệng. Dữ liệu lưu ở đâu, máy chủ trong nước hay ngoài nước. Xuất được không, bằng công cụ gì, có mất phí không. Xuất ra định dạng gì, có phải định dạng chuẩn như CSV hay Excel không. Nếu yêu cầu xuất, mất bao lâu thì có, và trong thời gian chờ hệ thống có chạy bình thường không.
Bốn câu này nghe đơn giản nhưng ít ai hỏi. Chúng tôi từng chứng kiến một doanh nghiệp muốn đổi đơn vị làm website, phát hiện toàn bộ dữ liệu sản phẩm và đơn hàng nằm trong hệ thống của đơn vị cũ. Họ chỉ được xuất dưới dạng PDF. Nghĩa là đọc được nhưng không nhập lại vào hệ thống mới được. Họ phải ngồi gõ lại hàng nghìn sản phẩm.
Một điểm đáng lưu ý nữa là chuyện sao lưu định kỳ. Nhiều nền tảng thuê bao có sao lưu tự động, nhưng không phải bản sao nào cũng khôi phục được về đúng thời điểm bạn muốn. Chúng tôi khuyên bạn hỏi rõ chu kỳ sao lưu và thử một lần khôi phục giả định. Việc này nghe nhỏ nhưng khi có sự cố thì nó là khác biệt giữa mất một ngày và mất cả tháng dữ liệu.
Khi bàn về hạ tầng và nền tảng cần chọn cho giai đoạn này, nên xem qua các đơn vị triển khai website và hệ thống cho doanh nghiệp. Dù bạn chọn hướng nào, kiến thức thiết kế website cơ bản vẫn rất cần để đọc hợp đồng cho đúng. Nhớ kiểm tra phần sở hữu dữ liệu trước khi ký, không phải sau.
Lời khuyên này cũng có hạn chế. Không phải doanh nghiệp nào cũng cần hệ thống riêng. Thuê bao dùng ngay vẫn hợp lý ở giai đoạn đầu. Khi doanh nghiệp còn nhỏ, chưa có dữ liệu lớn, việc ràng buộc với một nền tảng thuê bao để đổi lấy tốc độ triển khai là quyết định đúng. Chỉ cần biết trước là mình đang chấp nhận đánh đổi, và đặt mốc xem lại khi nào.
Sai lầm #7: Đào tạo hình thức, bỏ rơi người dùng cuối
Buổi training hai giờ, không có tài liệu, không có người hỗ trợ sau một tháng. Đây là cách kết thúc buồn của rất nhiều dự án chạy tốt về mặt kỹ thuật.
Biểu hiện rất dễ thấy. Tuần đầu mọi người hào hứng. Tuần thứ hai bắt đầu có người hỏi lại. Tuần thứ tư ai cũng quay về cách làm cũ. Sau hai tháng, hệ thống mới chỉ còn một hai người dùng, số còn lại quay lại Excel.
Vấn đề nằm ở chỗ đào tạo được thiết kế cho người đã quen công cụ số. Trong khi thực tế, người dùng cuối có nhiều mức độ khác nhau. Chia nhóm theo tần suất dùng hiệu quả hơn chia theo phòng ban. Nhóm dùng hàng ngày cần hướng dẫn sâu, nhóm dùng tuần một lần cần hướng dẫn vừa, nhóm chỉ xem báo cáo cần biết cách đọc số.
Cách làm chúng tôi thấy hiệu quả nhất là “người đỡ đầu” nội bộ. Chọn một người trong mỗi nhóm, cho họ học trước và sâu hơn. Khi đồng nghiệp có câu hỏi, họ hỏi người này trước, không hỏi nhà cung cấp. Cách này giải quyết được hai việc. Một là câu trả lời nhanh hơn. Hai là người đỡ đầu hiểu quy trình thật, nên hướng dẫn sát hơn.
Ngoài ra, tài liệu nên viết cho đúng một việc cụ thể. Đừng viết cuốn hướng dẫn dài 40 trang. Viết năm đến bảy tờ một trang, mỗi tờ cho một tác vụ hay làm nhất. Ví dụ “cách tạo đơn hàng”, “cách kiểm tra hàng tồn”, “cách xuất báo cáo tuần”. Tài liệu ngắn thì người ta đọc.
Tình huống này hay gặp ở doanh nghiệp có nhân sự lớn tuổi hoặc ít quen công cụ số. Với nhóm này, tốc độ học chậm hơn nhưng mức độ thành thạo lại bền hơn nếu được hướng dẫn đúng cách. Đừng gộp họ vào buổi training chung với nhóm trẻ. Học riêng, thực hành chậm, có người kèm.
Có một hạn chế thật mà nhiều người không muốn nghe. Đào tạo nhiều không cứu được công cụ quá khó dùng. Vấn đề gốc vẫn là chọn sai ở bước hai. Nếu phần mềm bắt người dùng qua sáu màn hình để làm một việc, không buổi đào tạo nào sửa được. Cách tốt nhất là nhận ra sớm và đổi công cụ, chứ đừng đổ tiền vào đào tạo thêm.
Checklist ngắn trước khi ký hợp đồng chuyển đổi số
Phần này để bạn dùng ngay, không cần nhớ hết bài. Năm câu hỏi tự kiểm, vài giấy tờ nên có, và một cảnh báo hay gặp.
Năm câu hỏi tự kiểm trước khi ký. Ai chịu trách nhiệm cuối cùng, tên cụ thể, không phải “ban lãnh đạo”. Đo bằng chỉ số nào, lấy từ đâu, ai cập nhật. Dữ liệu thuộc về ai, xuất được định dạng gì. Ai đào tạo, đào tạo cho nhóm nào, trong bao lâu. Bao lâu rà soát lại một lần, ai chủ trì buổi rà soát.
Giấy tờ nên có trong hồ sơ dự án gồm bản mô tả phạm vi (làm gì, không làm gì), tiêu chí nghiệm thu cụ thể, và điều khoản xuất dữ liệu khi kết thúc hợp tác. Ba thứ này nghe hành chính nhưng tiết kiệm rất nhiều tranh cãi sau này.
Một cảnh báo hay gặp là hợp đồng không ghi điều khoản bàn giao. Chúng tôi từng thấy hai bên mất nhiều tuần chỉ để thống nhất ai giữ tên miền. Tên miền là tài sản của doanh nghiệp, nên đứng tên doanh nghiệp ngay từ đầu. Việc nhỏ, hậu quả lớn.
Câu hỏi thường gặp về chuyển đổi số
Sai lầm chuyển đổi số thường do công nghệ hay do con người?
Phần lớn do con người và quy trình. Công nghệ hiếm khi là nút thắt thật. Nó chỉ khuếch đại cái đang có. Quy trình rõ thì công nghệ giúp chạy nhanh hơn. Quy trình lộn xộn thì công nghệ làm lộn xộn nhanh hơn.
Doanh nghiệp nhỏ có cần chuyển đổi số bài bản không?
Tùy quy mô. Dưới năm người, cứ dùng công cụ có sẵn cho nhanh, chọn loại dễ xuất dữ liệu. Từ mười người trở lên, hoặc có từ hai phòng ban, nên làm bài bản. Đến mức đó, quy trình truyền miệng bắt đầu đứt gãy.
Nên bắt đầu chuyển đổi số từ phòng ban nào?
Bắt đầu từ nơi có nỗi đau rõ nhất và tần suất lặp lại cao nhất. Ví dụ khâu xác nhận đơn hàng nếu ngày nào cũng sai sót. Trong kinh nghiệm của đội ngũ chúng tôi, khởi đầu từ một khâu nhỏ giúp kết quả đến sớm hơn nhiều so với việc nhảy thẳng vào cả phòng ban lớn. Đừng bắt đầu từ phòng ban to nhất, vì rủi ro cao và khó thấy kết quả sớm.
Bảy sai lầm trên có một điểm chung. Chúng đều là quyết định sai về thứ tự và sự chuẩn bị, không phải sai về lựa chọn công cụ. Phần mềm có thể đổi được. Thời gian và niềm tin của đội ngũ thì khó lấy lại hơn nhiều.
Nếu bạn đang chuẩn bị làm lại hệ thống, hãy bắt đầu bằng một buổi vẽ quy trình thật, một người chịu trách nhiệm có tên, và một bản chốt chỉ số. Ba việc nhỏ này, làm trước khi ký hợp đồng, sẽ giúp bạn tránh phần lớn các cái bẫy chúng tôi vừa kể.