Business rule kiểu "thừa vải thiếu cúc": khi nghiệp vụ không có trong sách nào

Hi lại là Hoàng đây!

Bữa trước trong group có một chị làm phần mềm kể lại chuyện hồi mới vô nghề, mở đầu bằng đúng một câu: "ôi mỗi ông một kiểu ạ". Rồi chị kể tiếp:

"vẫn nhớ bài toán thời đầu làm phần mềm đc một chị HR cho xem công thức và tính bảng lương ví dụ của một nhà máy may — thừa vải thừa chỉ thừa cúc / thiếu vải thiếu chỉ thiếu cúc — 6 cái đấy cộng trừ lại rồi tính theo số sản phẩm mỗi ngày…"

Mình đọc xong ngồi cười một mình, vì cái cảm giác đó thì BA nào đi làm vài dự án cũng gặp: nghe stakeholder mô tả nghiệp vụ, thấy quen quen, gật gù, trong đầu đã kịp map nó vô một module chuẩn nào đó rồi. Tới lúc ngồi dựng thật mới ngã ngửa ra là rule đó không nhét vừa cái gì hết.

Phần lớn business rule làm mình mệt nhất trong nghề không nằm trong sách nào, không có trong chuẩn quốc tế nào, cũng chẳng có framework nào phủ. Nó sinh ra từ thói quen của một ngành, một nhà máy, thậm chí một phân xưởng, và được nói ra bằng ngôn ngữ của nghề đó chứ không phải ngôn ngữ phần mềm. Cái mình cần học không phải là thuộc thêm một bộ framework, mà là nhận ra sớm rằng mình đang nghe một rule đặc thù, rồi hỏi cho tới nơi trước khi hứa.

Cái công thức "thừa vải thiếu cúc" thật ra là gì

Nghe qua thì kỳ, nhưng ngồi ngẫm chút là thấy nó cực kỳ hợp lý.

Công nhân may ăn lương theo sản phẩm, làm được bao nhiêu áo thì tính bấy nhiêu tiền. Nhưng nhà máy còn một nỗi lo thứ hai: nguyên phụ liệu. Vải, chỉ, cúc được phát ra theo định mức tính sẵn cho từng mã hàng — mỗi áo tốn bao nhiêu mét vải, bao nhiêu mét chỉ, mấy cái cúc. Cuối ca đối chiếu lại: phát ra bao nhiêu, ra được bao nhiêu sản phẩm, còn dư lại bao nhiêu. Dư thì công nhân đó tiết kiệm được vật tư, thiếu thì có cái gì đó đã rơi, đã hỏng, đã cắt sai. Sáu con số thừa/thiếu của ba loại vật liệu cộng trừ lại rồi cấn vô lương.

Nói cách khác, nhà máy đang vừa trả công vừa kiểm soát hao hụt vật tư bằng chính bảng lương. Không phải làm hai hệ thống, một cái tính lương một cái quản kho — họ gộp luôn, vì gộp thì người công nhân mới có động lực giữ vật tư.

Mình lấy một ví dụ số cho dễ hình dung (số này mình bịa ra để minh hoạ thôi, đừng đem đi báo giá):

• Công đoạn may thân áo sơ mi, đơn giá 4.500 đ/áo, một ngày ra 120 áo => 540.000 đ tiền sản phẩm.
• Định mức vải 1,15 m/áo => phát ra 138 m. Cuối ca đo lại thực dùng 136,2 m, thừa 1,8 m, quy ra 28.000 đ/m => cộng 50.400 đ.
• Định mức 9 cúc/áo => phát 1.080 cúc, đếm lại thiếu 14 cái (rơi, gãy khi đóng) => trừ 14 × 350 = 4.900 đ.
• Chỉ thừa một cuộn nhỏ => cộng 7.000 đ.

Lương ngày hôm đó = 540.000 + 50.400 − 4.900 + 7.000 = 592.500 đ.

Nhìn con số ra rồi thì thấy rõ: cái này không phải "tính lương". Đây là tính lương lồng với quyết toán vật tư, mà mỗi công ty lồng một kiểu khác nhau — đúng như câu "mỗi ông một kiểu ạ".

Vì sao rule kiểu này không nằm trong sách nào

Rule đặc thù khó không phải vì nó phức tạp về mặt toán, mà vì ba thứ cộng lại.

Thứ nhất là nó nhiều chiều. Cái công thức trên không phải một phép nhân, nó là loại vật tư × thừa hay thiếu × số sản phẩm × ca làm × mã hàng. Chỉ cần nhà máy đó có 5 loại vật tư thay vì 3, hoặc phân biệt ca ngày ca đêm, là bảng tính phình lên ngay.

Thứ hai là nó thay đổi theo mùa hàng. Mã hàng mới, chất liệu mới thì định mức khác, đơn giá công đoạn khác, có khi cách tính thừa thiếu cũng khác vì vải co giãn thì không đo được như vải thường. Rule mà bạn nghe hôm nay là rule của mùa hàng hiện tại.

Thứ ba, và đây là cái nguy hiểm nhất: người nói ra rule đó coi nó là chuyện hiển nhiên. Với chị HR ở nhà máy, chuyện cấn vật tư vô lương là chuyện đương nhiên như chuyện đi làm phải chấm công, nên chị sẽ không tự kể. Bạn hỏi "chị tính lương thế nào" thì chị trả lời "tính theo sản phẩm" — đúng, mà thiếu mất một nửa bài toán. Nó chỉ lòi ra khi bạn xin xem file thật.

Ba dấu hiệu bạn đang nghe một rule đặc thù

Cái này theo mình là phần đáng nhớ nhất của bài, vì nếu nhận ra sớm thì mọi thứ phía sau dễ hết.

Dấu hiệu đầu tiên là người ta mô tả nghiệp vụ bằng danh từ của nghề chứ không phải danh từ của hệ thống. Họ nói "cúc", "chỉ", "cữ", "mã hàng", "chuyền", "quyết toán mã" chứ không nói "cấu hình", "trạng thái", "phê duyệt". Khi trong câu chuyện toàn từ chuyên môn của ngành mà bạn không map được sang khái niệm phần mềm nào, đó là tín hiệu rất sớm và rất rõ.

Dấu hiệu thứ hai là hỏi "quy định này ghi ở đâu" thì không ai chỉ ra được văn bản nào. Câu trả lời thường là "trước giờ làm vậy", "chị Ba bên kho làm vậy đó em", hoặc "hồi trước sếp quy định". Rule sống trong đầu người và trong thói quen chứ không sống trong tài liệu. Kèm theo đó, hỏi ba người thì ra ba con số hơi khác nhau — người nói trừ 350 một cúc, người nói trừ theo giá nhập, người nói tháng rồi sếp cho bỏ qua.

Dấu hiệu thứ ba, kinh điển nhất: có một file Excel mà ai đó giữ riêng. Không nằm trên hệ thống, không có ai khác sửa, thường là một chị làm lâu năm giữ, mở ra thì đầy công thức lồng nhau và vài ô tô màu vàng "để nhớ". Cái file đó chính là đặc tả thật của nghiệp vụ, còn cái người ta kể cho bạn nghe chỉ là bản tóm tắt.

Gặp đủ ba dấu hiệu này thì mình dừng, không kết luận gì hết trong buổi họp đó.

Những câu mình hay hỏi trước khi hứa "hệ thống làm được"

Chỗ này mình liệt kê ra cho gọn, vì nó là bộ câu hỏi mình sài đi sài lại:

• "Xin chị file thật đang tính tay được không ạ?" — hỏi câu này trước tiên, đừng ngồi nghe mô tả. Một file thật bằng ba buổi phỏng vấn.
• "Con số cuối cùng ai là người chốt?" — để biết ai mới là chủ của rule. Người kể cho bạn nghe chưa chắc là người quyết.
• "Lần gần nhất có trường hợp bất thường là khi nào, xử sao?" — hỏi ngoại lệ bằng chuyện đã xảy ra, đừng hỏi "có ngoại lệ nào không" vì câu đó luôn nhận về "không có gì đâu em".
• "Rule này áp cho cả công ty hay chỉ phân xưởng này?" — cực kỳ hay bị bỏ sót. Nhiều rule chỉ đúng cho một chuyền, một chi nhánh.
• "Nếu số ra sai thì ai chịu trách nhiệm giải thích với công nhân?" — nghe hơi lạ nhưng câu này lộ ra mức độ nhạy cảm của rule, và lộ ra luôn ai sẽ là người test kỹ nhất cho bạn.

Năm câu này không giúp bạn hiểu hết nghiệp vụ, nhưng nó giúp bạn biết mình chưa hiểu tới đâu — đủ để đừng gật đầu quá sớm.

Ép rule đặc thù vô module chuẩn thì chuyện gì xảy ra

Phản xạ tự nhiên của cả BA lẫn dev là tìm chỗ nhét. Đã có module Payroll rồi thì thôi cấu hình thêm mấy khoản phụ cấp, khấu trừ là xong chứ gì.

Vấn đề là module lương chuẩn được thiết kế cho các khoản có cấu trúc đơn giản: một khoản, một công thức, một kỳ. Còn cái rule trên thì mỗi dòng lương phụ thuộc vô một bảng đối chiếu vật tư của đúng ca đó, đúng mã hàng đó. Ép vô thì thường ra một trong hai kết cục: hoặc bạn tạo ra mấy chục khoản phụ cấp/khấu trừ ảo và nhập tay số vô đó mỗi ngày — tức là hệ thống chỉ đóng vai máy đánh chữ; hoặc dev nhét logic vô mấy trường tự do, sáu tháng sau nhà máy đổi mùa hàng là không ai dám sửa vì không hiểu số ở đâu ra.

Và đây là chỗ mình muốn nói rõ: dùng lõi chuẩn cho phần chung, tách phần tính riêng ra ngoài không phải giải pháp chắp vá của công ty nhỏ. Cũng trong buổi nói chuyện hôm đó, một anh kể một công ty tài chính rất lớn, vốn hoá hàng chục tỷ đô, mà "vẫn chỉ dùng SAP để tính lương nhân viên văn phòng, còn sale tính excel". Lương sale có hoa hồng nhiều tầng, có điều chỉnh theo chính sách từng quý, nên họ để nguyên ngoài SAP. Người ta thừa tiền và thừa người để làm khác, nhưng người ta chọn không làm.

Mẫu lai mình hay đề xuất

Mô hình mình thấy chạy được lâu nhất gồm ba lớp.

Lõi chuẩn giữ những thứ ổn định và cần chia sẻ: hồ sơ nhân sự, chấm công, kỳ lương, hạch toán, phiếu lương phát ra. Phần tính đặc thù tách thành một khối riêng — một service, một bảng cấu hình công thức, hay đơn giản là một màn hình nhập bảng quyết toán vật tư theo ca — rồi trả về hệ thống chính đúng một con số hoặc vài dòng thu nhập/khấu trừ đã tính xong. Lớp thứ ba là Excel, giữ lại một cách có chủ ý cho các ca ngoại lệ, kèm quy định rõ ai nhập, ai duyệt, nhập vô hệ thống bằng đường nào.

Ranh giới giữa ba lớp mới là thứ bạn phải làm rõ trong tài liệu, chứ không phải bản thân công thức. Câu hỏi cần trả lời là: cái gì bắt buộc phải nằm trong hệ thống vì cần audit, cái gì được phép nằm ngoài, và số từ ngoài đi vô thì đi qua cửa nào.

Viết rule đó vô tài liệu như thế nào

Rule đặc thù mà viết bằng văn xuôi thì ba tháng sau đọc lại không ai hiểu. Mình luôn viết nó thành công thức, kèm một ví dụ số thật chạy từ đầu tới cuối như đoạn 592.500 đ ở trên — người dùng nghiệp vụ đọc ví dụ số sẽ phát hiện sai ngay, còn đọc mô tả thì họ gật hết.

Kèm theo công thức, mình ghi thêm ba thứ hay bị bỏ: nguồn của rule (ai nói, ngày nào, file nào), danh sách ngoại lệ đã biết tính tới thời điểm đó, và một câu ghi rõ phạm vi áp dụng — rule này đúng cho phân xưởng nào, mã hàng nào, từ ngày nào. Cái câu phạm vi đó nhìn thừa, nhưng tới lúc mở rộng sang nhà máy thứ hai thì nó cứu bạn.

Đừng quên phần dữ liệu đi kèm

Cái bẫy cuối, mình dính rồi nên nhắc kỹ: rule đặc thù gần như luôn kéo theo dữ liệu đặc thù. Công thức "thừa vải thiếu cúc" chỉ chạy được khi hệ thống có bảng định mức vật tư theo mã hàng, có bảng ca và phân công chuyền, có đơn giá từng công đoạn, có giá quy đổi từng loại vật tư. Bốn thứ đó nằm ở đâu? Ai cập nhật? Cập nhật khi nào — đầu mùa hàng hay bất kỳ lúc nào? Nếu giữa kỳ lương mà định mức đổi thì các ngày trước tính lại hay giữ nguyên?

Hỏi mấy câu này ngay trong buổi phỏng vấn nghiệp vụ, đừng để tới sprint dựng màn hình. Vì có công thức đúng mà thiếu nguồn dữ liệu thì hệ thống vẫn đứng im, mà lúc đó thì bạn đã hứa rồi.

Chốt lại

Khi nào thì lôi bài này ra sài: lúc bạn ngồi nghe một stakeholder mô tả cách họ tính một con số nào đó, thấy toàn từ chuyên môn của nghề họ, hỏi văn bản thì không có, mà mỗi người nói một con số hơi khác. Đó là lúc đừng hứa gì hết — xin file thật, hỏi ai chốt số, hỏi ngoại lệ gần nhất, hỏi phạm vi áp dụng, rồi mới bàn tới chuyện hệ thống làm được tới đâu.

Và nhớ giùm mình hai ý: rule đặc thù không phải chuyện lạ đời cần ép về chuẩn, nó là cách một ngành đã vận hành ổn định nhiều năm; còn chuyện tách phần tính riêng ra khỏi hệ thống chuẩn thì công ty vốn hoá hàng chục tỷ đô người ta cũng làm vậy thôi.

Dĩ nhiên mấy cái này còn tuỳ dự án — có nơi bắt buộc mọi thứ phải nằm trong hệ thống vì lý do audit, thì lại là câu chuyện khác. Hi vọng bài viết giúp bạn đỡ mất một phen hứa hẹn hớ như mình hồi trước. Cảm ơn bạn đã đọc tới đây, có gì chưa đúng hoặc bạn có case tương tự thì để lại comment cho mình với nhé :D