Tuần trước tôi ngồi với một chị quản lý vận hành của một công ty thương mại nhỏ. Chị khoe vừa mua một gói phần mềm quản lý bán hàng, đã trả tiền cả năm. Hỏi lại thì ra chị chưa từng ngồi xem nhân viên của mình đang ghi đơn hàng thế nào. Ba tuần sau, phần mềm vẫn nằm đó, còn nhân viên vẫn nhắn Zalo cho nhau rồi chép tay vào sổ. Tiền mất, niềm tin vào "số hoá" cũng mất theo. Cảnh này lặp lại rất nhiều, và gần như lần nào cũng vì cùng một lý do: làm sai thứ tự.
Chuyển đổi số không khó ở công nghệ. Nó khó ở việc chọn đúng việc để làm trước. Bài này là một bản đồ thực hành gồm năm bước, xếp theo thứ tự ưu tiên, dành cho người được giao phụ trách số hoá mà không có nền tảng kỹ thuật. Bạn không cần biết lập trình. Bạn cần biết quan sát, đặt câu hỏi và kiên nhẫn đi từng bước.
Vì sao sai thứ tự lại khiến dự án đổ vỡ
Khi được giao một dự án số hoá, phản xạ tự nhiên của hầu hết chúng ta là nghĩ tới công cụ trước. Mua phần mềm đi, cài lên là xong. Nhưng công cụ chỉ là chiếc xe. Nếu chưa biết mình đi đâu, đường nào đang tắc, thì xe tốt cũng không giúp gì, thậm chí còn chạy nhanh hơn về phía sai.
Thứ tự sai tạo ra ba hệ quả thường thấy. Thứ nhất, bạn mang một quy trình đang lộn xộn lên phần mềm, và phần mềm chỉ làm cho sự lộn xộn đó nhanh hơn, khó sửa hơn. Thứ hai, dữ liệu cũ chưa được dọn, nên báo cáo trên hệ thống mới ra số không ai tin, và niềm tin sụp trước khi hệ thống kịp chứng minh giá trị. Thứ ba, bạn không có điểm đo nào trước khi bắt đầu, nên không biết mình đã tốt lên hay chỉ đang bận hơn.
Lưu ý: Một dự án số hoá thành công thường bắt đầu bằng những việc rất ít liên quan tới công nghệ: ngồi xem người ta làm việc, vẽ lại quy trình, gom giấy tờ về một chỗ.
Năm bước dưới đây không phải công thức cứng. Nhưng thứ tự thì nên giữ. Đi ngược lại, bạn sẽ trả giá bằng thời gian và bằng uy tín của chính mình trong mắt đội ngũ.
Bước 1 và 2: nhìn đúng hiện trạng, rồi chọn đúng một nỗi đau
Bước 1: đánh giá hiện trạng trước khi động vào bất cứ thứ gì
Đánh giá hiện trạng không phải là lập một bảng kiểm dài ba trang. Nó là việc trả lời được vài câu hỏi rất cụ thể: công việc đang chảy qua những tay ai, mỗi người đang dùng công cụ gì để ghi lại, và chỗ nào thông tin bị mất hoặc phải nhập lại hai lần.
Cách làm đơn giản nhất là ngồi cạnh một nhân viên trong một buổi làm việc bình thường và ghi chép. Không phỏng vấn trong phòng họp, không hỏi "em thấy quy trình có ổn không". Cứ ngồi đó, xem họ mở những gì, chuyển qua lại giữa những cửa sổ nào, gọi điện hỏi ai. Ghi lại thời điểm họ phải dừng lại vì thiếu thông tin. Đó chính là những điểm đau thật.
Song song, hãy kiểm kê dữ liệu đang nằm ở đâu. Bao nhiêu phần nằm trong sổ giấy, bao nhiêu trong bảng tính cá nhân, bao nhiêu trong tin nhắn, bao nhiêu trong phần mềm cũ. Việc kiểm kê này nghe nhàm chán nhưng nó là nền cho bước 3, và bỏ qua nó là lý do phổ biến khiến dữ liệu sau này không ghép được với nhau.
Lỗi thường gặp ở bước này: đánh giá bằng cảm nhận của người quản lý thay vì quan sát thực tế. Người quản lý thường mô tả quy trình như nó được viết trong tài liệu, còn quy trình thật thì khác. Một lỗi khác là cố đánh giá toàn bộ công ty cùng lúc, dẫn tới một bức tranh lớn nhưng không chỗ nào đủ chi tiết để hành động.
Bước 2: chọn đúng một quy trình đau nhất
Sau bước 1, bạn sẽ có một danh sách dài những chỗ chưa ổn. Bản năng muốn sửa hết. Đừng. Chọn một, đúng một quy trình để làm điểm khởi đầu.
Tiêu chí chọn khá thực dụng. Chọn quy trình gây đau rõ rệt cho cả người làm và người quản lý: hay sai, hay trễ, hay phải làm lại, hoặc khiến khách hàng phàn nàn. Chọn quy trình có phạm vi hẹp, ít phòng ban dính vào, để bạn có thể đi hết một vòng mà không phải xin phép quá nhiều nơi. Và chọn quy trình mà kết quả tốt lên sẽ nhìn thấy được, để bạn có cái khoe với đội ngũ và với ban lãnh đạo.
Ví dụ dễ hình dung: quy trình xử lý đơn hàng từ lúc khách đặt tới lúc xuất kho, hoặc quy trình tiếp nhận và phản hồi yêu cầu bảo hành. Những quy trình này thường có điểm bắt đầu và kết thúc rõ, dễ đo.
Lỗi thường gặp: chọn quy trình "quan trọng nhất" thay vì "đau nhất nhưng vừa sức". Quy trình quan trọng nhất thường chạm vào nhiều phòng ban và nhiều người có quyền lợi, nên rất dễ sa lầy. Lỗi thứ hai là chọn theo cảm hứng của sếp chứ không theo dữ liệu quan sát được ở bước 1.
Một điều cần nói thẳng: bước 1 và 2 tốn thời gian, và trong lúc làm bạn sẽ có cảm giác mình chưa "làm gì cả". Đó là bình thường. Đây là phần đặt móng, và móng thì không ai nhìn thấy.
Bước 3: chuẩn hoá dữ liệu trước khi nghĩ đến công cụ
Đây là bước bị bỏ qua nhiều nhất, và cũng là bước quyết định dự án của bạn sống hay chết. Chuẩn hoá dữ liệu nghĩa là làm cho thông tin về cùng một thứ được ghi giống nhau ở mọi nơi, trước khi đưa lên bất kỳ hệ thống nào.
Hãy tưởng tượng bạn có mười cách viết tên khách hàng khác nhau trong sổ, trong bảng tính và trong tin nhắn. Khi đưa lên phần mềm, hệ thống sẽ coi đó là mười khách hàng. Báo cáo doanh thu theo khách sẽ sai. Nhân viên sẽ mất niềm tin vào hệ thống mới ngay tuần đầu.
Việc cần làm ở bước này khá cụ thể:
- Thống nhất một bộ quy tắc ghi dữ liệu tối thiểu: tên gọi, mã, đơn vị tính, định dạng ngày tháng, cách đánh số chứng từ.
- Gom dữ liệu cũ về một chỗ, loại bỏ bản trùng, đánh dấu những bản thiếu thông tin thay vì xoá vội.
- Viết ra một tờ giấy một trang mô tả quy trình đã chọn, bằng ngôn ngữ của người làm, không dùng từ kỹ thuật.
- Chỉ định một người chịu trách nhiệm về chất lượng dữ liệu của quy trình đó. Không phải cả nhóm, mà một người.
Có một sự thật hơi khó chịu: chuẩn hoá dữ liệu là phần tốn công nhất và ít được khen nhất. Nó không có màn hình đẹp để trình diễn. Nhưng nếu bỏ qua, mọi thứ xây lên sau đó đều lung lay. Chi phí phải trả không phải tiền, mà là thời gian của chính bạn và sự kiên nhẫn của đội ngũ.
Lỗi thường gặp: chuẩn hoá nửa vời, chỉ làm cho dữ liệu mới mà bỏ mặc dữ liệu cũ. Khi cần so sánh với quá khứ, bạn sẽ không có gì để so. Một lỗi khác là đặt ra quy tắc quá chi tiết, tới mức nhân viên phải nhớ mười điều kiện cho một ô nhập liệu, và rồi họ lách cho xong.
Bước 4: chọn công cụ vừa ngân sách, không chọn theo quảng cáo
Đến đây bạn mới được phép nghĩ tới phần mềm. Và tiêu chí đầu tiên không phải là công cụ nào mạnh nhất, mà là công cụ nào vừa với ngân sách và vừa với cách đội ngũ của bạn đang làm việc.
Trước khi xem bất kỳ bản chào giá nào, hãy viết ra ba thứ. Một là danh sách những việc tối thiểu công cụ phải làm được cho quy trình bạn đã chọn. Hai là ngân sách trần cho cả năm, gồm cả chi phí triển khai, đào tạo và duy trì. Ba là mức độ thoải mái về công nghệ của người sẽ dùng hằng ngày.
Khi đánh giá, hãy tự hỏi vài câu ít ai hỏi. Nếu sáu tháng nữa tôi muốn dừng, tôi lấy dữ liệu ra được không, hay bị khoá trong hệ thống? Chi phí có tăng vọt khi thêm người dùng không? Có cần thuê người bên ngoài để vận hành không? Những câu này quan trọng hơn danh sách tính năng dài dằng dặc trong tờ rơi quảng cáo.
Cũng nên nhớ rằng công cụ đắt hơn không đồng nghĩa với phù hợp hơn. Với một quy trình hẹp và đội ngũ nhỏ, một công cụ khiêm tốn được dùng thật thường có giá trị hơn một nền tảng đồ sộ mà chỉ dùng được một phần. Ngân sách tiết kiệm được nên để dành cho đào tạo và cho việc dọn dữ liệu, hai thứ thường bị cắt trước tiên và cũng là hai thứ quyết định thành bại.
Lỗi thường gặp: chọn theo bản demo đẹp, được trình bày bởi người bán hàng chứ không phải người dùng thật. Lỗi thứ hai là mua nhiều công cụ cùng lúc cho nhiều quy trình, khiến đội ngũ phải học ba thứ mới trong cùng một tháng và bỏ cuộc giữa chừng. Lỗi thứ ba là không tính chi phí ẩn: thời gian chuyển dữ liệu, thời gian làm quen, và những ngày năng suất giảm trong giai đoạn chuyển đổi.
Bước 5: đo lường rồi mới mở rộng ra phòng ban khác
Quy trình mới đã chạy. Bây giờ là lúc trả lời câu hỏi mà ban lãnh đạo sẽ hỏi: nó có tốt hơn không. Câu trả lời phải dựa trên con số bạn đã ghi lại từ trước khi bắt đầu, chứ không phải cảm giác hào hứng của tuần đầu.
Chọn vài chỉ số đơn giản và đo được bằng tay nếu cần: thời gian trung bình để hoàn thành một vòng quy trình, số lần phải làm lại, số lỗi phát hiện muộn, hoặc số câu hỏi mà khách hàng phải gọi lại để hỏi tình trạng. Đừng cố đo mười thứ. Ba chỉ số được theo dõi đều đặn có giá trị hơn mười chỉ số ghi một lần rồi bỏ.
Hãy so sánh trước và sau trong cùng một khung thời gian đủ dài để không bị nhiễu bởi mùa cao điểm hay một tuần nghỉ lễ. Nếu kết quả tốt, ghi lại cụ thể tốt ở đâu, cho ai. Nếu kết quả chưa tốt, xem lại xem vấn đề nằm ở công cụ, ở dữ liệu, hay ở chỗ đội ngũ chưa được hướng dẫn đủ. Cả ba khả năng đều bình thường, và đều sửa được.
Chỉ khi quy trình đầu tiên đã chạy ổn định và có số liệu chứng minh, bạn mới nên nghĩ tới việc nhân ra phòng ban khác. Lúc đó bạn có sẵn một câu chuyện thật, một quy trình mẫu, và những người đã từng làm được để kèm người mới. Mở rộng bằng uy tín thì dễ hơn nhiều so với mở rộng bằng mệnh lệnh.
Lỗi thường gặp: mở rộng quá sớm vì sốt ruột hoặc vì muốn báo cáo thành tích. Một lỗi khác là chỉ đo những chỉ số dễ thấy như số người dùng đăng nhập, mà không đo thứ có ý nghĩa với công việc. Và lỗi cuối cùng, khá phổ biến: không ghi lại bài học từ lần đầu, nên lần mở rộng sau lặp lại đúng những sai lầm cũ.
Lời mời đồng hành cùng DoanhSo
Nếu bạn đọc đến đây và thấy lộ trình này hợp lý nhưng vẫn chưa biết bắt đầu từ đâu với tình huống cụ thể của mình, đó là chỗ DoanhSo có thể đi cùng. Chúng tôi làm việc với các doanh nghiệp vừa và nhỏ, những nơi ngân sách có hạn và không có đội kỹ thuật riêng, theo đúng tinh thần của bản đồ này: đánh giá hiện trạng trước, chọn một quy trình để làm, dọn dữ liệu cho sạch, rồi mới tính tới công cụ.
Chúng tôi không hứa một con số thần kỳ về thời gian. Mỗi doanh nghiệp có điểm xuất phát khác nhau, và những chỗ rối nhất thường lộ ra sau khi bắt tay vào làm. Điều chúng tôi cam kết là đi cùng bạn qua từng bước, bằng ngôn ngữ bạn hiểu, với chi phí được tính toán để không vượt quá khả năng của một doanh nghiệp nhỏ.
Bạn có thể bắt đầu bằng việc ngồi lại một buổi để vẽ ra hiện trạng của mình. Không cần chuẩn bị gì nhiều. Chỉ cần mang theo câu hỏi đang khiến bạn trăn trở nhất về quy trình đang vận hành, và sự kiên nhẫn để đi đúng thứ tự.
