Phần mềm theo yêu cầu trong 1 ngày: Điều gì thực sự được hoàn thiện?

“Phần mềm theo yêu cầu trong một ngày? Nghe có vẻ không thể.”

Đó là phản ứng hợp lý của nhiều lãnh đạo doanh nghiệp. Một phần mềm quản trị thường liên quan đến quy trình, dữ liệu, người dùng, phân quyền, báo cáo và nhiều tình huống vận hành đặc thù. Nếu phải xây toàn bộ công nghệ từ đầu, một ngày rõ ràng là không đủ.

Nhưng “phần mềm theo yêu cầu trong một ngày” không có nghĩa là viết mới toàn bộ hệ thống ERP, hoàn tất mọi tích hợp và chuyển đổi toàn bộ doanh nghiệp chỉ sau vài giờ. Thứ được thực hiện trong ngày là cấu hình và hoàn thiện một bài toán quản trị cụ thể trên nền tảng đã có sẵn, để doanh nghiệp có thể nhìn thấy, thao tác và đánh giá cách giải pháp vận hành trong thực tế.

Không xây lại nền móng, mà cấu hình trên một nền tảng sẵn có

Hãy hình dung việc triển khai phần mềm giống như xây dựng một không gian làm việc. Nếu phải sản xuất từng viên gạch, dựng lại hệ thống điện và thiết kế toàn bộ kết cấu từ đầu, quá trình chắc chắn kéo dài. Nhưng nếu nền móng và các cấu phần chính đã sẵn sàng, đội ngũ có thể tập trung vào việc bố trí không gian theo đúng cách doanh nghiệp sử dụng.

Faceworks tiếp cận bài toán theo hướng thứ hai. Nền tảng đã có các thành phần phục vụ quản trị như tổ chức dữ liệu, quy trình xử lý, phân quyền, dashboard và khả năng kết hợp AI. Trong ngày trải nghiệm, công việc trọng tâm không phải phát triển lại những lớp công nghệ nền đó, mà là cấu hình chúng theo một nhu cầu cụ thể.

Ví dụ, một doanh nghiệp có thể chọn bài toán quản lý đề nghị mua hàng. Thay vì chỉ nghe mô tả chung về phần mềm, doanh nghiệp cùng đội ngũ Faceworks xác định:

• Nhân sự nào được tạo đề nghị mua hàng;
• Thông tin nào bắt buộc phải nhập;
• Đề nghị được chuyển qua các cấp duyệt nào;
• Trường hợp nào cần trả lại, bổ sung hoặc từ chối;
• Ai được xem dữ liệu theo phòng ban, đơn vị hoặc phạm vi trách nhiệm;
• Lãnh đạo cần theo dõi những chỉ số nào trên dashboard.

Từ phạm vi đó, một phiên bản sát với quy trình dự kiến có thể được cấu hình để người dùng trực tiếp tạo hồ sơ, chuyển duyệt, kiểm tra trạng thái và quan sát báo cáo. Đây là khác biệt giữa việc xem một bản trình diễn chung và trải nghiệm một bài toán mang ngữ cảnh của chính doanh nghiệp.

Trong một ngày, doanh nghiệp thực sự nhận được gì?

Kết quả phù hợp của một ngày trải nghiệm không nên được đánh giá bằng số lượng màn hình hay danh sách tính năng. Giá trị quan trọng hơn là doanh nghiệp có một mô hình đủ rõ để trả lời câu hỏi: Cách tiếp cận này có giải quyết đúng vấn đề quản trị của chúng ta hay không?

Tùy vào độ rõ của yêu cầu, phạm vi dữ liệu và mức độ phức tạp, một ngày làm việc có thể hướng tới các đầu ra sau:

1. Một quy trình được mô hình hóa: Các bước xử lý, vai trò tham gia, điều kiện chuyển bước và trạng thái hồ sơ được thể hiện rõ ràng.
2. Biểu mẫu dữ liệu phù hợp: Những trường thông tin cần quản lý được cấu hình theo nghiệp vụ thay vì sử dụng một biểu mẫu chung cho mọi doanh nghiệp.
3. Phân quyền ở mức thử nghiệm: Người tham gia có thể kiểm tra ai được tạo, xem, cập nhật hoặc phê duyệt dữ liệu.
4. Góc nhìn quản trị ban đầu: Một số báo cáo hoặc dashboard có thể được thiết lập từ dữ liệu mẫu để minh họa cách lãnh đạo theo dõi hoạt động.
5. Danh sách điểm cần làm rõ: Những ngoại lệ, nhu cầu tích hợp, yêu cầu dữ liệu và quy tắc chưa thống nhất được ghi nhận cho bước tiếp theo.

Vì sao lãnh đạo nên bắt đầu bằng một bài toán nhỏ nhưng thật?

Nhiều dự án phần mềm bắt đầu bằng danh sách yêu cầu rất dài. Các phòng ban tập hợp hàng chục mong muốn, nhà cung cấp trình bày hàng trăm tính năng, nhưng câu hỏi quan trọng nhất lại chưa được trả lời: hệ thống sẽ thay đổi cách doanh nghiệp vận hành như thế nào?

Một bài toán nhỏ nhưng thật giúp đưa cuộc trao đổi trở về với hoạt động quản trị cụ thể. Thay vì hỏi phần mềm “có quản lý mua hàng không”, doanh nghiệp có thể kiểm tra một đề nghị mua hàng phát sinh từ phòng ban sẽ đi qua hệ thống như thế nào, ai chịu trách nhiệm ở từng bước và lãnh đạo nhìn thấy điều gì khi hồ sơ bị chậm.

Cách làm này mang lại ba lợi ích thực tế:

• Giảm khoảng cách giữa mô tả và trải nghiệm: Người dùng không phải hình dung giải pháp qua slide hoặc tài liệu tính năng.
• Phát hiện sớm điểm chưa thống nhất: Khi quy trình được đưa lên hệ thống, các ngoại lệ và khác biệt giữa các phòng ban thường trở nên rõ hơn.
• Tạo cơ sở cho quyết định đầu tư: Lãnh đạo có thể đánh giá giải pháp dựa trên khả năng xử lý một tình huống thật, thay vì chỉ dựa trên cam kết chung.

Một ngày trải nghiệm có thể diễn ra như thế nào?

Không có lịch trình duy nhất cho mọi doanh nghiệp. Tuy nhiên, để buổi làm việc tạo ra kết quả cụ thể, quá trình thường cần đi qua bốn phần rõ ràng.

1. Chốt vấn đề cần giải quyết

Hai bên thống nhất một phạm vi đủ nhỏ để có thể xử lý sâu trong ngày. Đó có thể là quy trình phê duyệt chi phí, theo dõi cơ hội bán hàng, quản lý yêu cầu nội bộ, quản lý công việc dự án hoặc một phần của quy trình mua hàng.

Ở bước này, điều quan trọng không phải mô tả mọi mong muốn, mà là xác định vấn đề hiện tại: dữ liệu đang phân tán ở đâu, bước nào thường chậm, ai cần được thông báo và lãnh đạo đang thiếu thông tin gì.

2. Mô hình hóa dữ liệu, quy trình và quyền hạn

Đội ngũ thực hiện chuyển yêu cầu nghiệp vụ thành cấu trúc trên hệ thống: biểu mẫu, danh mục, trạng thái, luồng phê duyệt, vai trò sử dụng và chỉ số theo dõi. Đại diện doanh nghiệp cần tham gia để xác nhận các quy tắc thay vì chỉ bàn giao tài liệu rồi chờ kết quả.

3. Cấu hình và chạy thử bằng tình huống mẫu

Một số tình huống tiêu biểu được đưa vào hệ thống. Chẳng hạn: hồ sơ đúng quy định, hồ sơ thiếu thông tin, hồ sơ vượt hạn mức hoặc hồ sơ bị trả lại. Việc chạy thử giúp kiểm tra luồng xử lý trong bối cảnh gần với hoạt động thật.

4. Đánh giá và xác định bước tiếp theo

Cuối ngày, doanh nghiệp xem lại điều đã cấu hình, những nội dung phù hợp, những điểm cần chỉnh và các hạng mục nằm ngoài phạm vi trải nghiệm. Nếu tiếp tục, hai bên mới xây dựng kế hoạch triển khai dựa trên phạm vi, dữ liệu, tích hợp và nhóm người dùng thực tế.

Ví dụ: từ bảng tính theo dõi yêu cầu đến quy trình có trách nhiệm rõ ràng

Giả sử một doanh nghiệp đang tiếp nhận yêu cầu nội bộ qua tin nhắn, email và bảng tính. Người gửi khó biết yêu cầu đang ở đâu. Bộ phận xử lý phải tổng hợp thủ công. Lãnh đạo chỉ biết có vấn đề khi công việc đã chậm.

Trong ngày trải nghiệm, phạm vi có thể được giới hạn ở một loại yêu cầu. Hệ thống được cấu hình để người dùng tạo yêu cầu theo biểu mẫu thống nhất, tự xác định bộ phận phụ trách theo nhóm nội dung, ghi nhận thời điểm tiếp nhận, cập nhật trạng thái và tổng hợp số lượng yêu cầu đang chờ xử lý.

Khi chạy thử, doanh nghiệp có thể nhanh chóng nhận ra những câu hỏi quản trị trước đây chưa được làm rõ: yêu cầu nào cần phê duyệt, khi nào được xem là hoàn thành, ai có quyền mở lại hồ sơ và trường hợp quá hạn sẽ được xử lý ra sao.

Kết quả của một ngày trong trường hợp này không phải là tuyên bố rằng toàn bộ hệ thống vận hành đã hoàn tất. Giá trị nằm ở việc doanh nghiệp nhìn thấy mô hình quản lý mới, kiểm tra được các giả định và xác định chính xác hơn những gì cần triển khai.

Doanh nghiệp cần chuẩn bị gì để một ngày không bị lãng phí?

Tốc độ cấu hình phụ thuộc nhiều vào mức độ rõ ràng của bài toán. Công nghệ có thể giúp rút ngắn thao tác, nhưng không thể tự thay doanh nghiệp quyết định quy tắc quản trị. Trước buổi trải nghiệm, doanh nghiệp nên chuẩn bị:

• Một vấn đề ưu tiên: Chọn một quy trình có tác động rõ, không gom toàn bộ ERP vào một ngày.
• Người hiểu nghiệp vụ: Có đại diện đủ khả năng xác nhận các bước xử lý và tình huống ngoại lệ.
• Biểu mẫu hoặc dữ liệu mẫu: Có thể sử dụng biểu mẫu hiện tại và một lượng dữ liệu minh họa phù hợp, tránh cung cấp dữ liệu nhạy cảm khi chưa thống nhất cơ chế xử lý.
• Quy tắc phân quyền cơ bản: Xác định ai tạo, ai xem, ai xử lý và ai phê duyệt.
• Tiêu chí đánh giá: Nêu rõ điều gì cần được chứng minh sau buổi trải nghiệm.

Nếu yêu cầu còn mơ hồ, một phần thời gian sẽ phải dành cho việc phân tích và thống nhất nghiệp vụ. Điều đó vẫn có giá trị, bởi nhiều doanh nghiệp cần làm rõ quy trình trước khi số hóa. Tuy nhiên, đầu ra cấu hình trong ngày sẽ phụ thuộc vào thời gian còn lại và độ phức tạp của bài toán.

Từ trải nghiệm một ngày đến một hệ thống quản trị thực tế

Một mô hình thử nghiệm chỉ thực sự hữu ích khi nó tạo nền tảng cho quyết định tiếp theo. Sau ngày trải nghiệm, lãnh đạo nên đánh giá giải pháp trên bốn phương diện.

1. Mức độ phù hợp với quy trình: Hệ thống có phản ánh được cách doanh nghiệp muốn vận hành hay buộc doanh nghiệp đi theo một khuôn cứng?
2. Khả năng kiểm soát dữ liệu: Thông tin có cấu trúc rõ, dễ tìm và có thể phân quyền theo trách nhiệm không?
3. Khả năng mở rộng: Bài toán ban đầu có thể kết nối với các quy trình liên quan khi doanh nghiệp triển khai tiếp không?
4. Nguồn lực triển khai: Doanh nghiệp cần chuẩn bị ai, dữ liệu nào và kế hoạch thay đổi thói quen làm việc ra sao?

Nếu kết quả phù hợp, bước tiếp theo có thể là hoàn thiện quy trình thử nghiệm, mở rộng sang nhóm người dùng thực tế, chuẩn hóa dữ liệu và xác định các nhu cầu tích hợp. Nếu chưa phù hợp, doanh nghiệp vẫn có thêm thông tin để điều chỉnh yêu cầu hoặc xem lại cách thiết kế quy trình trước khi đầu tư lớn hơn.

Kết quả cấu hình trong một ngày phụ thuộc vào phạm vi yêu cầu, mức độ sẵn sàng của dữ liệu, quy trình và người tham gia. Các nội dung triển khai toàn diện sẽ được đánh giá và lập kế hoạch riêng.