Nếu bạn là dev và vừa nhận dự án từ một xưởng sản xuất hay một nhà bán hàng, chắc hẳn bạn đã gặp tình huống này. Khách nói một đằng, cần một nẻo. Bạn làm theo bản yêu cầu đầu tiên, rồi đến lúc bàn giao mới thấy mọi thứ lệch đi. Chúng tôi đã đi qua không ít dự án như vậy. Phần lớn vấn đề nằm ở chỗ chưa hiểu nghiệp vụ phía sau. Bài này tổng hợp top 7 kinh nghiệm thực tế về thương mại và sản xuất mà đội ngũ chúng tôi rút ra trong quá trình triển khai, kèm tiêu chí chọn và những hạn chế bạn nên cân nhắc.
Vì sao dân công nghệ cần hiểu thương mại và sản xuất
Phần lớn website, ứng dụng hay phần mềm đầu tiên của doanh nghiệp vừa và nhỏ xuất phát từ nhu cầu rất thực tế. Chủ xưởng muốn nhận đơn nhanh hơn. Chủ shop muốn báo giá chính xác hơn. Và ai cũng muốn biết hôm nay còn bao nhiêu hàng trong kho.
Vấn đề là dev thường không quen với cách người ta nhận đơn, lập báo giá hay theo dõi tồn kho. Khi hai bên dùng hai bộ từ vựng khác nhau, sản phẩm làm ra rất dễ lệch. Hiểu nghiệp vụ giúp bạn làm đúng ngay từ vòng đầu, tránh phải sửa đi sửa lại nhiều lần. Đó cũng là lý do chúng tôi luôn dành thời gian đầu dự án để nghe khách kể về công việc hằng ngày của họ.
Dưới đây là bảy kinh nghiệm chúng tôi đúc kết. Mỗi mục đều có phần tiêu chí và phạm vi phù hợp để bạn tự đối chiếu với dự án của mình.
Bài toán đơn hàng và tồn kho quyết định phần mềm
Trước khi bàn đến công nghệ, hãy hỏi xưởng một câu đơn giản: mỗi ngày có bao nhiêu đơn, và đang quản lý bao nhiêu mã hàng (SKU)? Hai con số này cho bạn biết nên nâng cấp một bảng tính hay phải xây dựng một hệ thống quản lý thật sự.
Xưởng vừa và nhỏ thường vẫn dùng Excel. Với vài chục đơn mỗi ngày, Excel có thể vẫn ổn. Nhưng khi tồn kho nằm rải rác ở nhiều kho, mỗi người nhập một kiểu, lỗi nhập tay sẽ tăng rất nhanh. Chúng tôi từng gặp một lần đếm sai, kéo theo cả tuần giao hàng bị trễ, và cả xưởng phải ngồi đối chiếu lại từ đầu. Từ đó chúng tôi luôn hỏi kỹ về quy mô trước khi đề xuất giải pháp.
- Tiêu chí: số đơn trung bình mỗi ngày và số SKU đang quản lý.
- Phù hợp với: xưởng sản xuất vừa và nhỏ còn quản lý bằng bảng tính.
- Lưu ý: chưa có con số chuẩn cho mọi quy mô, nên khảo sát trực tiếp tại xưởng.
Luồng sản xuất phải được vẽ ra trước khi code
Đây là bước nhiều dự án bỏ qua. Bạn nên ngồi với người phụ trách và ghi lại từng công đoạn, từ lúc nhận đơn, lên kế hoạch, cấp nguyên liệu, sản xuất, kiểm tra cho đến xuất hàng. Mỗi công đoạn cần ghi rõ ai làm, dùng giấy tờ gì và kết quả đi đâu.
Sơ đồ trên giấy thường rất gọn gàng. Thực tế tại xưởng thì khác. Có công đoạn phải làm lại, có người làm tắt, có việc chỉ nằm trong đầu một người. Vì vậy hãy đi xem tận nơi thay vì chỉ đọc tài liệu. Một buổi quan sát ca làm việc thường cho bạn nhiều thông tin hơn cả chục cuộc họp.
Khi đã có sơ đồ thực tế, bạn mới biết chỗ nào cần số hóa trước. Nếu không, phần mềm làm ra sẽ buộc người dùng đi theo một quy trình mà chính họ chưa bao giờ làm, và rất nhanh sau đó họ sẽ quay lại dùng giấy bút.
Website bán hàng B2B không giống B2C
Nhiều người làm web theo khuôn của cửa hàng bán lẻ, với giỏ hàng, nút thanh toán nhanh và vài bước là xong. Với khách hàng doanh nghiệp, cách vận hành hoàn toàn khác.
Khách B2B thường muốn xem catalogue đầy đủ, yêu cầu báo giá theo lô và đặt số lượng lớn. Họ cần tài khoản riêng, theo dõi công nợ, và đôi khi có bảng giá khác nhau cho từng đại lý. Giỏ hàng kiểu bán lẻ lúc này lại gây khó chịu, vì người mua muốn gửi yêu cầu chứ không muốn thanh toán ngay.
Một trang catalogue rõ ràng, kèm form báo giá dễ dùng, thường là điểm khởi đầu hợp lý cho nhiều xưởng. Tuy vậy, không có công thức chung cho mọi ngành. Hàng cơ khí, thực phẩm hay dệt may đều có cách đặt hàng và quy cách đóng gói riêng, nên bạn cần điều chỉnh theo từng trường hợp. Nếu muốn tham khảo cách làm cụ thể cho nhóm khách này, bạn có thể xem thêm cách xây dựng hiện diện số cho xưởng sản xuất.
Chọn công cụ theo quy mô, không theo độ hot
Một công cụ đang được bàn tán rầm rộ chưa chắc đã hợp với doanh nghiệp của bạn. Ba câu hỏi nên đặt ra đầu tiên là: bao nhiêu người sẽ dùng, ngân sách hàng năm là bao nhiêu, và ai sẽ bảo trì nó về sau.
Phần mềm miễn phí rất hấp dẫn với doanh nghiệp mới bắt đầu chuyển đổi số. Tuy nhiên, chúng thường giới hạn tính năng, số tài khoản và cả hỗ trợ kỹ thuật. Khi công ty mở rộng, chi phí chuyển sang nền tảng khác đôi khi cao hơn cả việc trả phí ngay từ đầu. Đừng vội kết luận công cụ nào tốt nhất, hãy xem nó có đồng hành cùng doanh nghiệp được bao lâu.
Dữ liệu sạch quan trọng hơn giao diện đẹp
Có một dự án đến giờ đội ngũ chúng tôi vẫn nhớ. Giao diện rất đẹp, biểu đồ rất sinh động, nhưng báo cáo tồn kho sai liên tục. Nguyên nhân khá đơn giản: mã sản phẩm bị trùng. Cùng một mặt hàng được nhập thành ba mã khác nhau tùy người nhập liệu. Nhìn dashboard thì ấn tượng, nhưng con số thì không thể tin được.
Vì vậy, trước khi làm bất kỳ dashboard nào, hãy chuẩn hóa dữ liệu. Quy định rõ cách đặt mã, đơn vị tính và ai được phép tạo sản phẩm mới. Việc này nghe nhàm chán, nhưng nếu bỏ qua, mọi báo cáo phía sau đều mất giá trị.
- Tiêu chí: dữ liệu gốc phải thống nhất trước khi đưa vào hệ thống mới.
- Phù hợp với: mọi doanh nghiệp đang số hóa dữ liệu lần đầu.
- Lưu ý: làm sạch dữ liệu cũ thường tốn thời gian hơn dự kiến, nên lên kế hoạch sớm.
Những thuật ngữ thương mại dev nên biết
Bạn không cần trở thành chuyên gia thương mại, nhưng một vài thuật ngữ sẽ xuất hiện thường xuyên. Khi làm website xuất nhập khẩu, bạn sẽ gặp Incoterms, bộ quy tắc quy định bên nào chịu chi phí và rủi ro vận chuyển ở từng chặng. Khi ký hợp đồng bảo trì phần mềm, bạn sẽ gặp SLA, tức cam kết về thời gian phản hồi và thời gian khắc phục sự cố.
Hiểu sơ các khái niệm này giúp bạn không bị bất ngờ khi đọc hợp đồng và biết nên hỏi khách những câu gì. Tuy nhiên, khi áp dụng vào điều khoản cụ thể, hãy tham khảo ý kiến người có chuyên môn. Đừng tự suy diễn ý nghĩa pháp lý của một điều khoản.
Chốt phạm vi và nghiệm thu bằng văn bản
Dự án đổ bể thường không phải vì code kém, mà vì hai bên hiểu khác nhau về phạm vi. Khách nghĩ tính năng đó đã nằm trong gói, còn dev nghĩ đó là phát sinh. Đến cuối dự án, cả hai đều thấy mình bị thiệt.
Hãy ghi rõ từng tính năng, mốc thời gian, cách tính chi phí phát sinh và tiêu chí nghiệm thu. Mỗi lần thay đổi yêu cầu nên có xác nhận bằng văn bản, dù chỉ là email. Việc này không làm mất lòng khách, ngược lại còn cho thấy bạn làm việc chuyên nghiệp.
- Tiêu chí: mọi hạng mục đều có mô tả, mốc thời gian và người xác nhận.
- Phù hợp với: freelancer và đội dev nhỏ nhận dự án từ doanh nghiệp.
- Lưu ý: văn bản nội bộ không thay thế tư vấn pháp lý khi có tranh chấp.
Gợi ý cách bắt đầu tại doanh nghiệp đang làm thương mại
Đừng cố số hóa cả công ty trong một lần. Hãy chọn quy trình gây đau đầu nhất, thường là khâu xử lý đơn hoặc kiểm kho, rồi làm trước khâu đó. Khi một mảng đã chạy ổn, mọi người sẽ tin tưởng hơn để mở rộng sang phần còn lại.
Trước khi thay đổi, hãy đo thời gian xử lý hiện tại, ví dụ một đơn hàng mất bao lâu từ lúc nhận đến lúc xuất. Sau khi hệ thống mới ổn định, đo lại để thấy khác biệt. Có số liệu thật trong tay, cả bạn lẫn khách hàng đều dễ thống nhất hơn nhiều.
Khi đã có kết quả tốt, hãy mở rộng dần sang các khâu khác. Nếu muốn tìm hiểu thêm về giải pháp phần mềm quản lý bảo trì thiết bị, đó cũng là một hướng đi đáng cân nhắc cho xưởng đang lớn dần. Bạn cũng có thể đối chiếu thêm với hướng dẫn sử dụng WordPress và công nghệ web từ A đến Z nếu cần nền tảng web đơn giản cho phần giới thiệu sản phẩm.
Câu hỏi thường gặp
Dev không chuyên thương mại có làm được phần mềm cho xưởng không?
Được, nhưng bạn cần dành thời gian ngồi cùng người trong xưởng. Hãy hỏi nhiều, ghi lại quy trình và kiểm chứng ngay tại chỗ thay vì chỉ dựa vào tài liệu có sẵn. Theo kinh nghiệm của đội ngũ chúng tôi, nhiều dev làm tốt hơn mong đợi khi chịu đi xem thực tế.
Nên bắt đầu số hóa từ khâu nào trong sản xuất?
Thường là khâu nhận đơn và kiểm tồn kho, vì đây là nơi sai sót xảy ra nhiều và ảnh hưởng trực tiếp đến khách. Hãy chọn khâu đang gây đau đầu nhất của doanh nghiệp bạn.
Website B2B cần những trang nào tối thiểu?
Thông thường cần trang giới thiệu, catalogue sản phẩm, trang yêu cầu báo giá và thông tin liên hệ. Nếu có đại lý, nên thêm khu vực đăng nhập để xem bảng giá riêng. Nếu đang cân nhắc giao việc cho bên ngoài, bạn có thể đọc thêm năm điều cần biết khi thuê đội dev ngoài.
Làm sao biết phần mềm miễn phí đã đủ dùng chưa?
Hãy liệt kê những việc bắt buộc phải làm mỗi ngày, rồi kiểm tra xem bản miễn phí có đáp ứng hết không. Nếu phải lách bằng cách làm thủ công song song, có lẽ đã đến lúc cân nhắc trả phí.
Khi nào nên thuê đội dev ngoài thay vì tự làm?
Khi công việc vượt quá năng lực nội bộ hoặc cần tiến độ gấp. Nếu chưa có người bảo trì lâu dài, cũng nên cân nhắc kỹ trước khi quyết định, vì phần mềm cần được chăm sóc sau khi bàn giao. Đội ngũ chúng tôi thường khuyên khách hàng chuẩn bị sẵn người đầu mối nội bộ trước khi ký hợp đồng.
