↓ Chuyển đến nội dung chính
Bảng fit-gap analysis với các cột phân loại trên màn hình
  1. Bài viết/

Fit-gap analysis ERP: làm thế nào để mỗi gap ra quyết định

·
Đặng Đức Quân
Tác giả
Đặng Đức Quân
Chuyện nghề BA trong lĩnh vực sản xuất. Viết cho mình, và cho cả những ai đang muốn dấn thân vào con đường này.

Cập nhật lần cuối:

Có lần mình làm một hệ thống chia lệnh sản xuất tự động, hệ thống đã tự tính hết rồi, vậy mà khách vẫn muốn giữ file Excel cũ, tự nhập tự điền như trước, vì quen và vì tiện lưu trữ. Nói thẳng thì việc đó không còn cần nữa, nhưng gốc của nó không phải lười đổi thói quen, họ sợ hệ thống tính nhầm, một nỗi lo rất tự nhiên.

Từ vụ đó mình hiểu ra một điều về fit-gap, nhiều yêu cầu sửa cho giống cách cũ thật ra là nỗi lo chưa được giải tỏa chứ không phải gap, fit-gap chỉ có ích khi mỗi dòng trong danh sách đi tới một quyết định kèm tên người quyết, còn dòng nào sinh ra từ nỗi lo thì phải xử lý nỗi lo trước.

fit-gap trong một đoạn
#

Fit-gap analysis là việc so quy trình to-be của khách với tính năng chuẩn của sản phẩm để phân từng yêu cầu vào ba nhóm, fit là sản phẩm đáp ứng đúng, dùng luôn, gap là không đáp ứng, phải xử lý, còn partial fit là đáp ứng một phần, cần cấu hình thêm hoặc đổi quy trình nhỏ. Nó thường làm sau khi có quy trình to-be và trước khi chốt thiết kế hay cấu hình, là cầu nối giữa khách muốn gì và sản phẩm làm được gì.

BABOK Guide v3 không có mục riêng tên fit-gap, theo mình gần nhất là nhóm task Strategy Analysis (phân tích hiện trạng, xác định trạng thái tương lai, chọn change strategy) và task 8.3 Assess Solution Limitations khi đánh giá một sản phẩm có sẵn.

quy trình làm
#

Fit-gap thường kéo dài nhiều buổi, đi theo năm bước. Đầu tiên là lập danh sách yêu cầu theo quy trình, từ to-be liệt kê từng yêu cầu cụ thể kiểu khi đơn mua vượt mức X thì cần giám đốc duyệt. Sau đó demo chuẩn sản phẩm, cho khách xem sản phẩm chạy quy trình đó thế nào từng bước một. Rồi phân từng yêu cầu thành fit, gap hay partial fit, với mỗi gap thì đưa phương án xử lý kèm đánh đổi, cuối cùng là để người quyết định chọn và ghi lại quyết định đó.

mẫu bảng fit-gap
#

Một bảng gọn nên có các cột ID, quy trình, yêu cầu, mức fit, phương án đề xuất, công sức (S/M/L), rủi ro, người quyết, trạng thái. Mức fit ghi fit, gap hay partial fit, phương án ghi cách xử lý, công sức ghi tương đối nhỏ vừa lớn, không cần con số chính xác, chỉ để mọi người có cảm giác về chi phí. Cột người quyết là quan trọng nhất mà người mới hay bỏ, gap nào cũng phải có một người chịu trách nhiệm chốt, không thì nó nằm đó mãi.

năm cách xử lý gap, từ rẻ tới đắt
#

Rẻ nhất là đổi quy trình, chấp nhận làm theo cách chuẩn của sản phẩm, có điều cần khách đồng ý bỏ thói quen cũ. Tiếp theo là cấu hình, dùng cấu hình có sẵn để đáp ứng mà không cần code, lựa chọn tốt nhất cho partial fit. Thứ ba là báo cáo hoặc workaround, dùng báo cáo, xuất Excel, hay một quy trình phụ bên ngoài để bù chỗ thiếu. Thứ tư là tùy biến nhỏ, thêm một field hay một luồng riêng. Đắt nhất là tùy biến lớn, phát triển một module gần như mới, kèm theo gánh nặng mỗi lần nâng cấp.

khi nào nói không với tùy biến
#

Tùy biến không phải lúc nào cũng xấu, nhưng hay bị lạm dụng, theo mình nó chỉ nên làm khi gap đụng tới tuân thủ pháp lý hoặc là lợi thế cạnh tranh thật của doanh nghiệp, còn vì quen làm thế này thì chưa đủ lý do. Tùy biến nào cũng có cái giá ngầm, mỗi lần nâng cấp sản phẩm phần tùy biến phải kiểm lại, có khi phải sửa, càng nhiều tùy biến càng khó nâng cấp, người quyết cần hiểu rõ cái giá này trước khi gật đầu.

Mong muốn làm giống Excel cũ là nguồn của khá nhiều tùy biến không đáng làm, và gap nào đã chọn phương án rồi thì phải kiểm lại bằng kịch bản thật ở UAT cho dự án ERP.

khi khách muốn giữ Excel vì sợ hệ thống tính sai
#

Quay lại vụ chia lệnh sản xuất, việc đầu tiên mình làm là họp riêng với khách, giải thích kỹ công thức hệ thống đang tính, để họ thấy con số không phải từ trên trời rơi xuống. Họp xong mà họ vẫn chưa yên tâm thì mình đồng ý cho chạy song song Excel một thời gian để so kết quả, theo mình khoảng một đến hai tuần là đủ, số trên Excel khớp với số hệ thống suốt khoảng đó thì khách tự yên tâm, hệ thống ổn định rồi thì mình đề xuất bỏ Excel, vì giữ cả hai là làm trùng việc.

Còn nếu hai bên lệch số trong lúc chạy song song thì đừng vội kết luận ai sai, việc đầu tiên là xác định root cause, lệch ở đâu, do nhập tay trên Excel hay do nhập liệu trên hệ thống, xác định được gốc rồi mới đào nguyên nhân sâu hơn.

Anh em có thể phản biện rằng chạy song song là tốn công gấp đôi, sao không bắt bỏ Excel luôn cho nhanh. Đúng là tốn công thật, nhưng bỏ Excel khi khách chưa tin hệ thống thì niềm tin vẫn chưa có, còn một hai tuần chạy song song có mốc kết thúc rõ ràng và có số liệu để khách tự kiểm.

sai lầm hay gặp
#

Sai lầm lớn nhất là biến fit-gap thành danh sách tùy biến, ghi mọi gap rồi gap nào cũng sẽ tùy biến, thế là fit-gap mất luôn ý nghĩa là công cụ ra quyết định. Sai lầm thứ hai là không có người quyết, gap liệt kê xong rồi nằm im vì chẳng ai chịu chốt. Sai lầm thứ ba là đánh giá fit sai vì chưa hiểu sản phẩm đủ sâu, yêu cầu tưởng là gap hóa ra cấu hình được, chỉ là mình chưa biết, nên trước khi kết luận gap hãy hỏi người hiểu sản phẩm.

mỗi dòng một quyết định, một cái tên
#

Bảng fit-gap tốt là bảng mà dòng nào cũng có một quyết định và một cái tên, dùng chuẩn, cấu hình hay tùy biến, và ai chốt. Tuần này thử mở bảng của bạn ra đếm xem bao nhiêu dòng còn trống cột người quyết, gap không ai quyết sẽ thành nợ quyết định, còn nếu bạn đang cân nhắc làm cái nghề ngồi fit-gap mỗi tuần thì đọc Từ BA sang tư vấn ERP.

Anh em đã gặp khách nào xin giữ Excel cho chắc chưa, và anh em xử lý thế nào? Kể mình nghe qua Facebook hoặc LinkedIn nhé.

Bài viết liên quan

UAT cho dự án ERP: BA chuẩn bị kịch bản thế nào để không vỡ

·
Nhiều đợt UAT trong dự án ERP hỏng từ trước khi ai bấm nút đầu tiên, kịch bản viết theo màn hình, dữ liệu test toàn abc, chẳng ai thống nhất thế nào là đạt, tới tuần test thì key user bận, lỗi nào cũng bị ném vào một sheet chung, và buổi sign-off thành buổi cãi nhau. Nếu bạn là BA được giao chuẩn bị UAT, phần lớn việc của bạn nằm ở trước tuần test.

ERP đổi hướng giữa chừng: tiếp, dừng hay hybrid?

·
Tháng thứ 9 của dự án, requirement đã chốt, solution design đã duyệt, dev đang chạy full sprint, mọi thứ đi đúng lộ trình, rồi vendor publish roadmap, và trong danh sách tính năng mới có một feature standard làm y chang cái mà team đã bỏ mấy tháng thiết kế custom. Cả phòng im lặng, rồi ai đó hỏi, vậy giờ làm sao? Mình đã ngồi đúng khoảnh khắc đó hai lần. Lần đầu mình im, vì chưa biết nên nói gì, lần thứ hai mình mở miệng, không phải để trả lời mà để hỏi.

BPMN cho người mới: vẽ as-is/to-be từ ghi chú workshop

·
Giả sử bạn vừa bước ra khỏi buổi workshop hai tiếng với phòng mua hàng, cầm về tờ giấy chi chít chữ, ai gửi yêu cầu, ai duyệt, mức nào phải lên giám đốc, lúc nào thì chạy Excel ngoài, giờ phải vẽ lại thành một sơ đồ cho cả team nhìn chung một bức tranh, mở công cụ lên rồi đứng hình. Bài này đi từ đúng tờ giấy đó ra một sơ đồ BPMN dùng được, kèm mấy lỗi hay biến sơ đồ thành tranh treo tường.