Lộ trình CNTT nên bắt đầu từ dự án nào?

Trước hết, hãy yêu cầu mỗi bộ phận mô tả việc đang gặp khó khăn, thay vì chỉ nêu tên phần mềm muốn mua. “Cần một báo cáo mới” chưa cho biết người quản lý thiếu thông tin nào và quyết định gì đang bị chậm. “Phải hỏi từng kho mới biết còn hàng để nhận đơn” giúp các bên hiểu vấn đề cần giải quyết rõ hơn.

Trong ví dụ mở chi nhánh, cần kiểm tra vì sao tồn kho chưa đáng tin cậy. Có thể nhân viên ghi nhận xuất hàng muộn, mỗi nơi dùng một mã cho cùng sản phẩm hoặc dữ liệu chưa được kết nối. Những nguyên nhân này dẫn đến phần việc khác nhau. Nếu nguyên nhân là thao tác chưa thống nhất, mua thêm công cụ báo cáo chưa chắc giải quyết được; doanh nghiệp có thể phải sửa cách ghi nhận trước.

Tiếp đó, nêu kết quả muốn đạt bằng ngôn ngữ công việc. Chẳng hạn, người nhận đơn cần biết lượng hàng có thể bán mà không gọi lại từng kho. Nhóm có thể xem thời gian xác nhận hàng, số trường hợp phải đối chiếu bằng tay hoặc số đơn phải điều chỉnh vì thông tin tồn không đúng. Đây là những chỉ dấu để tìm hiểu và thống nhất, không phải mức cải thiện được hứa trước.

Bằng chứng ban đầu có thể là một số tình huống phát sinh, báo cáo đang dùng và trao đổi với người trực tiếp xử lý. Chưa có số liệu đầy đủ thì ghi rõ điều cần kiểm tra, không tự đặt một tỷ lệ tiết kiệm để làm đề xuất hấp dẫn hơn. Một bước khảo sát ngắn có mục tiêu rõ đôi khi là việc nên làm trước cả khi chọn giải pháp.

Cũng cần xác định người chịu trách nhiệm về kết quả sau triển khai. Đội kỹ thuật có thể bàn giao chức năng xem tồn, nhưng người phụ trách kho và bán hàng phải cùng thống nhất cách cập nhật, đối chiếu và sử dụng thông tin đó. Nếu chưa có người nhận trách nhiệm, một dự án được cấp ngân sách vẫn có thể không tạo ra thay đổi trong công việc.

Các đề xuất nên được trình bày theo cùng một cách: đang gặp vấn đề gì, ai bị ảnh hưởng, có bằng chứng nào, mong đợi kết quả gì và nếu chưa làm thì hậu quả ra sao. Sau đó mới xem phạm vi dự kiến, phần việc phải chuẩn bị và người cần tham gia. Cách này giúp so sánh nhu cầu thực tế giữa các phòng ban, thay vì ưu tiên bản đề xuất được viết thuyết phục nhất.

Với từng đề xuất, hãy tách mức độ ảnh hưởng khỏi mức độ cấp bách. Một báo cáo có thể hữu ích cho nhiều người nhưng chưa nhất thiết phải làm trước một vấn đề đang khiến đơn hàng bị gián đoạn. Ngược lại, một yêu cầu được gọi là “gấp” cần có lý do cụ thể: mốc mở chi nhánh đã chốt, công việc đang bị cản trở hay hệ thống sắp hết hỗ trợ. Những thông tin như hết hỗ trợ phải được xác nhận với đúng sản phẩm và phiên bản.

Chi phí cần tính cả phần sau khi mua hoặc phát triển. Ai làm sạch dữ liệu, hướng dẫn nhân viên, trả phí sử dụng và xử lý khi có lỗi? Nếu chỉ so giá xây dựng ban đầu, một phương án rẻ hơn có thể đòi hỏi đội nội bộ làm nhiều việc hơn. Khi chưa có đủ thông tin, hãy ghi giả định và khoảng cần khảo sát thay vì đưa ra một con số có vẻ chính xác.

Nguồn lực cũng không chỉ là số lập trình viên. Hai dự án khác nhau có thể cùng cần một trưởng kho để mô tả nghiệp vụ và kiểm tra kết quả. Nếu người đó đang chuẩn bị mở chi nhánh, chạy đồng thời có thể làm cả hai dự án chậm. Lịch ưu tiên phải tính thời gian của người nghiệp vụ, người phê duyệt và người tiếp quản, bên cạnh ngân sách.

Có thể dùng điểm số để hỗ trợ so sánh, nhưng phải giải thích tiêu chí và lý do chấm. Hai đề xuất bằng điểm vẫn có thể cần thứ tự khác nhau vì một việc đang chờ dữ liệu hoặc cùng dùng một người phụ trách. Điểm số là tài liệu để thảo luận; người có thẩm quyền vẫn cần quyết định dựa trên ảnh hưởng, rủi ro và điều kiện thực tế.

Sau khi so sánh, cần tìm các việc phụ thuộc nhau: việc sau có bắt đầu được nếu việc trước chưa xong không? Trong ví dụ tồn kho, báo cáo nhiều chi nhánh cần cùng cách hiểu về mã sản phẩm và số lượng có thể bán. Nếu mỗi nơi ghi một kiểu, đưa dữ liệu lên cùng một màn hình chưa làm cho số liệu trở nên đáng tin cậy.

Một thứ tự có thể cân nhắc là xác nhận nguồn tồn đang dùng và thống nhất mã, sửa cách ghi nhận tại một nơi, rồi mới tổng hợp cho nhiều chi nhánh. Mỗi bước phải có kết quả kiểm tra được: mã đã được xác nhận, người sử dụng cập nhật theo cùng quy tắc, báo cáo khớp với dữ liệu đã đối chiếu. Đây là ví dụ minh họa, không phải trình tự mặc định cho mọi doanh nghiệp.

Trong tình huống này, thử dự báo bằng AI có thể chưa phải việc cần mở rộng ngay nếu lịch sử bán hàng còn thiếu hoặc mã hàng chưa nhất quán. Trước khi xếp sáng kiến AI vào giai đoạn triển khai, cần biết dữ liệu có phù hợp với mục đích đó không. Bài Dữ liệu doanh nghiệp đã sẵn sàng cho AI chưa? giúp bạn xem xét phần chuẩn bị dữ liệu trước khi đầu tư vào mô hình.

Tuy nhiên, không phải mọi việc đều phải chờ toàn bộ dự án trước hoàn tất. Một nhóm có thể khảo sát cách kết nối trong khi bộ phận khác đang thống nhất mã hàng, nếu phạm vi và người tham gia cho phép. Cần phân biệt việc có thể chuẩn bị song song với việc chỉ được đưa vào sử dụng khi điều kiện đã đạt. Nếu bỏ qua sự khác nhau này, lộ trình dễ bị xếp quá chậm hoặc chồng chéo quá mức.

Nếu còn một điểm kỹ thuật có thể làm thay đổi cả phương án, nên xác định bước kiểm tra trước khi duyệt phát triển rộng. Chẳng hạn, nhóm cần biết phần mềm kho hiện tại có cho lấy dữ liệu với quyền được phép hay không. Bài PoC hay MVP: Cần thử điều gì trước? giải thích cách chọn phạm vi thử để trả lời điều chưa chắc, thay vì xây nhiều chức năng rồi mới phát hiện một điều kiện quan trọng không đáp ứng được.

Có trường hợp cần đổi thứ tự theo thực tế kinh doanh. Nếu chi nhánh mới phải mở trước khi giải pháp tổng thể sẵn sàng, doanh nghiệp cần chọn phạm vi tối thiểu có thể sử dụng và cách đối chiếu tạm được chấp nhận. Phần làm tạm phải có người phụ trách và điều kiện kết thúc, nếu không doanh nghiệp có thể duy trì hai cách làm lâu hơn dự định.

Phần làm ngay cần cụ thể hơn phần làm sau: phạm vi được duyệt, người chịu trách nhiệm, nguồn lực có thể bố trí và điều kiện xác nhận kết quả. Phần xa hơn có thể ghi theo hướng cải thiện và điều kiện để bắt đầu, chưa nhất thiết gắn ngày hoàn thành. Một ý tưởng được ghi trên lộ trình không tự trở thành dự án đã được duyệt.

Trong ví dụ, việc gần nhất có thể là kiểm tra cách ghi nhận tồn tại một chi nhánh và thống nhất quy tắc sửa. Báo cáo toàn doanh nghiệp chỉ chuyển sang bước thực hiện khi nguồn dữ liệu đã đủ tin cậy và có người tham gia xác nhận. Thử AI được giữ để xem lại sau khi đã đánh giá dữ liệu và nhu cầu. Nhìn vào đó, các bộ phận biết việc nào đang được làm và vì sao việc khác chưa bắt đầu.

Khi phân bổ người và ngân sách, cần tính cả công việc duy trì hệ thống đang chạy. Nếu toàn bộ đội nội bộ cùng tham gia dự án mới, ai xử lý sự cố, cập nhật hoặc hỗ trợ người dùng hiện tại? Phần nguồn lực này phải được tính vào khả năng thực hiện, không chỉ được bổ sung khi có vấn đề rồi rút người khỏi kế hoạch.

Lộ trình cần được xem lại khi có kết quả thử, thông tin mới về dữ liệu hoặc thay đổi trong kế hoạch kinh doanh. Doanh nghiệp nên có người được giao tổng hợp và người có quyền thay đổi thứ tự. Khi hoãn một đề xuất, hãy ghi lý do, việc cần làm để có thể quay lại và thông báo cho bộ phận liên quan; nếu chỉ dời ngày, mọi người vẫn có thể chờ một lời hứa không còn phù hợp.

Kết quả của giai đoạn đã triển khai cũng phải được đưa vào lần xem xét tiếp theo. Nếu chức năng xem tồn đã hoạt động nhưng nhân viên vẫn gọi lại từng kho, cần tìm nguyên nhân trước khi mở rộng. Bài Làm sao biết phần mềm đang mang lại hiệu quả? giúp bạn đối chiếu việc phần mềm đã được bàn giao với thay đổi thực tế trong công việc.

Khi trao đổi với Fenix, doanh nghiệp có thể bắt đầu bằng các đề xuất đang có, những tình huống gây khó khăn và giới hạn về người, ngân sách hoặc thời gian. Hai bên sẽ có cơ sở làm rõ vấn đề, điều kiện cần kiểm tra và thứ tự nên triển khai, trước khi chốt danh sách công nghệ hoặc một lịch đầu tư dài hạn.

Trao đổi nhu cầu với Fenix