Hiện nay tôi thấy có nhiều phương pháp xác định thông số nào đó bằng cách sử dụng các hàm Excel lồng nhau, bên cạnh đó là hàm tự tạo VBA.
Theo ý kiến cá nhân thì lồng ghép hàm tuy hiệu quả (nhất là với người không thạo lập trình VBA), nhưng khá rắc rối, và dễ sai sót... Việc copy hay sử dụng ở các nơi khác trên bảng tính sẽ khó khăn.
Còn sử dụng VBA thì người dùng chủ động hơn, các bước tính toán trung gian đã được mã hóa. Việc khai thác, sử dụng hàm trở nên dễ dàng hơn vì tính chuyên biệt...
Xin ý kiến từ các thành viên GPE.
Công việc của em thường xuyên lặp lại, và em thường chọn lựa hàm UDF tự tạo, vì nó nhanh, dễ nhớ do mình đặt tên theo ý mình.
Nếu được phép chọn lựa lại bao nhiêu lần thì em mãi mãi ưu tiên dùng hàm UDF thôi.
Nhược điểm của UDF chỉ có một, là phải thạo lập trình VBA. Nhưng cái này có thể bù đắp bằng diễn đàn GPE của chúng ta. Nhờ anh chị tạo giúp hàm UDF...........gì đó. Nhờ một cách đoàng hoàng lịch sự thì sẽ có người giúp thôi.
Trước tiên, cần phân biệt giữa người tự viết hàm/công thức, và người nhờ kẻ khác viết giùm.
Đối với người không tự viết thì tôi nghĩ chả có gì khác nhau cả, ngoại trừ UDF thì file phải chứa Macro, không dễ dàng chuyển cho người khác. Nhưng đó chỉ là tôi nghĩ, ý chủ quan của tôi. Với đa số ở đây thì có lẽ UDF "xịn" hơn, "máu" hơn, và [theo họ] chạy nhanh hơn.
Đối với người tự viết thì tôi thích công thức hơn. Công thức phức tạo thì dùng cột phụ. Cực chẳng đã mới phải viết UDF. Lý do như đã nêu trên: file chứa Macro nhìn ái ngại lắm.
Đương nhiên, nếu cái công thức có cả đống mảng, lằng ngoằng lèo ngoèo thì UDF giản dị hơn. Điều kiện: UDF có chú thích kỹ lưỡng.
Ngay cả khi nói chuyện với các người chuyên gõ dữ liệu vào bảng tính (data entry), tôi cũng khuyên họ dùng cái Entry Form có sẵn của Excel thay vì UserForm.
Tôi xóa tạm 1 số bài nhắc nhở thành viên @viethung78 về việc viết hoa toàn bài viết, và đã cảnh cáo thành viên này. Nếu tái phạm tôi sẽ xử lý nặng hơn theo nội quy.
Đồng ý kiến với bạn VetMini.
Rất ít người có khả năng viết được các hàm tự tạo tốt như các chuyên gia Microsoft, nên các hàm tự tạo thường chạy chậm và làm nặng file hơn các hàm của excel, cực chẳng đã mới dùng hàm tự tạo, tốt nhất là dùng hàm excel, nếu công thức quá phức tạp hoặc nặng file thì dùng cột phụ, dùng VBA nên ưu tiên sử dụng Sub
Đồng ý kiến với bạn VetMini.
Rất ít người có khả năng viết được các hàm tự tạo tốt như các chuyên gia Microsoft, nên các hàm tự tạo thường chạy chậm và làm nặng file hơn các hàm của excel, cực chẳng đã mới dùng hàm tự tạo, tốt nhất là dùng hàm excel, nếu công thức quá phức tạp hoặc nặng file thì dùng cột phụ, dùng VBA nên ưu tiên sử dụng Sub
Em thấy việc dùng hàm lồng đối với người lâu lâu sử dụng thì tốt, còn đối với người làm công việc lặp lại liên tục thì sao anh ?
Em ví dụ một trường hợp
Viết Sai
Viết đúng
ACRYLIC PARC49/PARC48 MDF MUFSTD 4817
ACRYLIC PARC48/PARC49 MDF MUFSTD 4817
HPLVCJ LKPF8006G/LK431Z7 MDF MUFSTD 17MM
HPLVCJ LK431Z7/LKPF8006G MDF MUFSTD 17MM
HPLVCJ LK5007A/LK442Z6 MDF MUFSTD 17MM
HPLVCJ LK442Z6/LK5007A MDF MUFSTD 17MM
HPLVCJ LK700D/LK001Z6 MDF MUFSTD 17MM
HPLVCJ LK001Z6/LK700D MDF MUFSTD 17MM
Trường hợp này dùng hàm lồng thì như thế nào, và mỗi lần dùnghàm lồng cũng đủ mệt, mất thời gian.
Trong khi hàm UDF thì đơn giản nhanh........em thấy tóm lại là công việc lặp lại thường xuyên vẫn là UDF tốt hơn
Chỉ cần =hoanvi_LK( chuỗi dữ liệu) là xong
Function hoanvi_LK(Chuoi As String) As String
Dim tam
Dim j, k
tam = Split(Application.Trim(Chuoi))
For j = 0 To UBound(tam)
If InStr(tam(j), "/") Then
k = Split(tam(j), "/")
tam(j) = k(1) & "/" & k(0)
Exit For
End If
Next j
hoanvi_LK = Join(tam)
End Function
Em ví dụ 1 trường hợp khác cho công việc lặp lại
Mã
Tách màu 1
Tách màu 2
VEB VHT58/VHT58 MDF UFSTD 4817
VHT58
VHT58
VEB VHT59/VHT59 MDF UFSTD 4817
VHT59
VHT59
GC MEL 106S/106S PB-KH UFE1 4816
106S
106S
GC MEL 106S/106S PB-KH UFE1 4818
106S
106S
HPL LK058D/LK058D PB MUFSTD 4809
LK058D
LK058D
HPL LK058D/LK449Z6 PB MUFSTD 4809
LK058D
LK449Z6
ACRYLIC ARC80/BACKER01 WPB STD 4815
ARC80
BACKER01
Tách màu LK dùng công thức
=IFERROR(MID(C3,VALUE(FIND(" ",C3))+1,VALUE(FIND("/",C3)-(VALUE(FIND(" ",C3)+1)))),"")
'=IFERROR(TRIM(MID(C3,VALUE(FIND("/",C3))+1,VALUE(FIND(" ",C3,FIND(" ",C3,1)+1)-VALUE(FIND("/",C3))))),"")
Trường hợp dùng công thức này tách màu, chỉ sửa chữ C3 thôi cũng mất thời gian hơn so với code
Trong khi dùng code thì chỉ cần dùng, đơn giản, nhanh gọn
=TachMau(C3,1)
=TachMau(C3,2)
Function TachMau(str As String, lngMau As Byte)
Dim Tmp, I As Long
Tmp = Split(str)
For I = 0 To UBound(Tmp)
If InStr(Tmp(I), "/") Then
Tmp = Split(Tmp(I), "/")
TachMau = Tmp(lngMau - 1)
Exit Function
End If
Next
End Function
Bởi vậy em thấy là, người dùng có làm việc lặp lại thường xuyên không, hay lâu lâu mới xài một lần thì mới tìm ra câu trả lời chính xác.
Bài đã được tự động gộp:
Mà các anh sẵn cho em hỏi, trường hợp này nếu không dùng UDF mà viết lồng hàm bình thường thì viết như thế nào các anh.
Em cũng là người thích tìm hiểu nhiều cách giải quyết trong cùng một vấn đề
Tôi tự viết VBA để dùng cho rất nhiều thứ lặp đi lặp lại trong công việc hàng ngày nên tôi thấy dùng VBA tiện hơn và hầu hết tôi dùng Sub chứ không dùng UDF. Tất nhiên đơn giản như ba cái bảng lương hoặc các bảng biểu tương tự thì dùng công thức chứ chả dại gì mà viết code VBA.
Công việc lặp lại liên tục mà phải dùng hàm lồng rắc rối, hoặc phải viết cái UDF tổ bố (*1) thì rõ ràng là công việc có vấn đề.
Cần bổ sung kiến thức ở hai điều sau:
1. học lại cách sử dụng bảng tính trải rộng
2. học các công cụ của Excel về trình bày bảng tính và gom, lọc dữ liệu.
(*1) UDF vài dòng giản dị không kể. Bởi vì người chuyên nghiệp biết gom chúng vào thư viện.
(*2) Kinh nghiệm mấy năm ở GPE cho tôi biết người VN dùng bảng tính như chiếc đũa nhiệm mầu, gõ cái ra tất cả. Họ chuyên về giải quyết vấn đề phức tạp SAU KHI có vấn đề thay vì tư duy thiết kế thế nào để tránh sự phức tạp từ đầu.
Nói cách khác, người GPE giải quyết vấn đề rất giỏi nhưng tránh vấn đề thì họ không muốn bận tâm. Luôn luôn có cái cớ: "nhưng mà điều kiện làm việc là như vậy"
Mà các anh sẵn cho em hỏi, trường hợp này nếu không dùng UDF mà viết lồng hàm bình thường thì viết như thế nào các anh.
Em cũng là người thích tìm hiểu nhiều cách giải quyết trong cùng một vấn đề
...
"Nhiều cách" của quý vị nó cũng chủ quan.
Lý do tại sao phải hàm, phải công thức?
Trước mắt, gặp tôi thì làm việc theo thứ tự ưu tiên sau:
1. thủ công
2. công thức bảng tính
3. các công cụ "chiến đấu" hơn: Power Query, M, Power Pivot, ...
4. UDF
Đương nhiên, nếu tôi có sẵn một cái UDF trong thư viện làm được việc này thì là chuyện khác.
Vả lại, như tôi đã đề cập ở chú thích (* 2) trên, quý vị chỉ chú tâm vào giải quyết cái kết quả chứ không bao giờ tính giải quyết cái nguyên nhân.
Em thấy việc dùng hàm lồng đối với người lâu lâu sử dụng thì tốt, còn đối với người làm công việc lặp lại liên tục thì sao anh ?
Em ví dụ một trường hợp
Viết Sai
Viết đúng
ACRYLIC PARC49/PARC48 MDF MUFSTD 4817
ACRYLIC PARC48/PARC49 MDF MUFSTD 4817
HPLVCJ LKPF8006G/LK431Z7 MDF MUFSTD 17MM
HPLVCJ LK431Z7/LKPF8006G MDF MUFSTD 17MM
HPLVCJ LK5007A/LK442Z6 MDF MUFSTD 17MM
HPLVCJ LK442Z6/LK5007A MDF MUFSTD 17MM
HPLVCJ LK700D/LK001Z6 MDF MUFSTD 17MM
HPLVCJ LK001Z6/LK700D MDF MUFSTD 17MM
Trường hợp này dùng hàm lồng thì như thế nào, và mỗi lần dùnghàm lồng cũng đủ mệt, mất thời gian.
Trong khi hàm UDF thì đơn giản nhanh........em thấy tóm lại là công việc lặp lại thường xuyên vẫn là UDF tốt hơn
Chỉ cần =hoanvi_LK( chuỗi dữ liệu) là xong
Function hoanvi_LK(Chuoi As String) As String
Dim tam
Dim j, k
tam = Split(Application.Trim(Chuoi))
For j = 0 To UBound(tam)
If InStr(tam(j), "/") Then
k = Split(tam(j), "/")
tam(j) = k(1) & "/" & k(0)
Exit For
End If
Next j
hoanvi_LK = Join(tam)
End Function
Em ví dụ 1 trường hợp khác cho công việc lặp lại
Mã
Tách màu 1
Tách màu 2
VEB VHT58/VHT58 MDF UFSTD 4817
VHT58
VHT58
VEB VHT59/VHT59 MDF UFSTD 4817
VHT59
VHT59
GC MEL 106S/106S PB-KH UFE1 4816
106S
106S
GC MEL 106S/106S PB-KH UFE1 4818
106S
106S
HPL LK058D/LK058D PB MUFSTD 4809
LK058D
LK058D
HPL LK058D/LK449Z6 PB MUFSTD 4809
LK058D
LK449Z6
ACRYLIC ARC80/BACKER01 WPB STD 4815
ARC80
BACKER01
Tách màu LK dùng công thức
=IFERROR(MID(C3,VALUE(FIND(" ",C3))+1,VALUE(FIND("/",C3)-(VALUE(FIND(" ",C3)+1)))),"")
'=IFERROR(TRIM(MID(C3,VALUE(FIND("/",C3))+1,VALUE(FIND(" ",C3,FIND(" ",C3,1)+1)-VALUE(FIND("/",C3))))),"")
Trường hợp dùng công thức này tách màu, chỉ sửa chữ C3 thôi cũng mất thời gian hơn so với code
Trong khi dùng code thì chỉ cần dùng, đơn giản, nhanh gọn
=TachMau(C3,1)
=TachMau(C3,2)
Function TachMau(str As String, lngMau As Byte)
Dim Tmp, I As Long
Tmp = Split(str)
For I = 0 To UBound(Tmp)
If InStr(Tmp(I), "/") Then
Tmp = Split(Tmp(I), "/")
TachMau = Tmp(lngMau - 1)
Exit Function
End If
Next
End Function
Bởi vậy em thấy là, người dùng có làm việc lặp lại thường xuyên không, hay lâu lâu mới xài một lần thì mới tìm ra câu trả lời chính xác.
Bài đã được tự động gộp:
Mà các anh sẵn cho em hỏi, trường hợp này nếu không dùng UDF mà viết lồng hàm bình thường thì viết như thế nào các anh.
Em cũng là người thích tìm hiểu nhiều cách giải quyết trong cùng một vấn đề
Công thức excel hoán đổi vị trí khá dài, dùng hàm SUBSTITUTE ghép với 2 công thức lấy màu, tự làm sẽ được
Số lượng công thức ít, dùng hàm tự tạo cũng được nhưng dùng quá nhiều thường làm nặng file, ví vụ trên nếu muốn dùng VBA nên dùng Sub tốt hơn nhiều
Tôi thì chơi thủ công.
Nếu Flash Fill không thành công thì tôi thử Text-to-columns.
Công thức:
Bẳng tính mở rộng vốn làm việc, tính toán với con số. Dữ liệu text khởi đầu chỉ dùng để tham chiếu và sắp xếp, diễn giải.
Bảng tính hồi xưa cũng chuyên nghiệp tính. Ít khi cần phải nhập dữ liệu từ file khác hoặc dạng khác.
Vì vậy, các hàm thông dụng của Excel chỉ chủ yếu làm những việc này.
Qua đến cuối thập niên 2000, và đầu thập niên 2010, nhu cầu làm việc với dữ liệu "không phải số" gia tăng. Và nhu cầu liên kết, nhập dữ liệu khác cũng gia tăng. Microsoft ra các công cụ Power Query và Data Model (Power Pivot) để đáp ứng.
Dưới sự đe dọa của Google Sheets, MS ra các công thức mới cho 365 có thể giúp các trường hợp làm việc với text và array dễ dàng hơn.
Chú thích:
Tôi tránh nói nhiều về vấn đề của bài #7 là vì chúng thuộc về "lọc/chỉnh dữ liệu". Ở trình độ cao, nó không phải là công việc của bảng tính. Người chuyên nghiệp làm việc với dữ liệu tom góm có nhiều phương pháp giải quyết chúng; không nhất thiết phải dùng công thức bảng tính hay VBA gì cả.
...
Số lượng công thức ít, dùng hàm tự tạo cũng được nhưng dùng quá nhiều thường làm nặng file, ví vụ trên nếu muốn dùng VBA nên dùng Sub tốt hơn nhiều
Tôi thấy như sau:
1/ trên Sheet hàm trên Cells càng nhiều thì Excel chạy càng chậm
2/ đừng bao giờ nghĩ viết hàm tự tạo thay thế xong gõ trên Cells lại càng sai lầm
3/ nếu dùng VBA thì nên dùng Sub và hạn chế tối đa dùng hàm trên Cells trừ khi hết cách
4/ Nguyên tắc khi Excel Load ( Mở lên ) nó tính toán mọi cái có trong chính File đó mà hàm trên Cells chi phí thời gian quá nhiếu ... nhất là Hàm kiểu {=MySQLA(B1,B2,B3)} .... nếu ko tin cứ thử cái hàm kiểu đó trên này hiện có mà ai đó keo chạy siêu nhanh với số dòng 1048570 x 12 cột là biết
5/ nếu code két khá chút biết c++ or gì đó viết 1 thư viện hàm xong cần thì call từ VBA thì đó cũng là cách làm tăng tốc thêm chút
...
kẹt chút rảnh nói tiếp
Tôi có suy nghĩ giống bài #9.
1. Thứ tự ưu tiên khi giải quyết 1 vấn đề:
- Công thức đơn giản. Tôi sẽ không cố viết công thức khủng. Công thức phức tạp thì xé nhỏ ra cột phụ hoặc dùng name. Do đang xài 365 nên ưu tiên sử dụng hàm mới như Lambda, let, ...
- Dữ liệu nhiều mà xài công thức: Paste value chừa lại công thức ở vài dòng cuối
- Công cụ có sẵn: Advanced filter, Subtotal (không phải hàm subtotal), pivot table, Power query, Power pivot
- Sub VBA với nút nhấn (hạn chế dùng sự kiện). VBA là lựa chọn cuối cùng, và khi viết là phài viết cho tổng quát để khỏi sửa, ít sửa, và nếu sửa phải sửa dễ dàng.
2. Ưu tiên trước mọi ưu tiên:
Không để vấn đề xảy ra rồi phải giải quyết.
Lấy ví dụ như để xử lý bài #7: Nếu công việc cứ phải lặp lại thường xuyên và đau đầu vì nó, tại sao không tìm nguyên nhân sinh ra việc sai thứ tự màu, chấn chỉnh nó từ gốc, rồi ngồi rung đùi?
Lấy ví dụ như để xử lý bài #7: Nếu công việc cứ phải lặp lại thường xuyên và đau đầu vì nó, tại sao không tìm nguyên nhân sinh ra việc sai thứ tự màu, chấn chỉnh nó từ gốc, rồi ngồi rung đùi?
Cáo sai của bên em bắt nguồn từ sales, mà công việc chính của sales là bán được hàng, còn chuyện sai đúng đã có bộ phận khác lo.
Hồi trước có 1 đợt tuyển toàn sales giỏi Excel, lúc đó em cũng khỏe 1 thời gian…….nhưng kết quả là quá giỏi Excel mà không bán được hàng, cũng bị loại khỏi cuộc chơi……..
Và vòng xoáy cứ lặp lại, tuyển người mới, sale mới, bán được hàng nhưng ………người bán được hàng đa phần do giao tiếp chứ Excel rất cùi………
Mà người vừa giỏi Excel vừa giỏi giao tiếp bán được hàng.........thì không chịu làm với mức lương đó....
Và theo dòng chảy thời giản, kết quả là bộ phận khác phải dọn dẹp cho họ………xem cái sai của họ là điều hiển nhiên.
Thôi thì mình ở khâu cuối cùng, làm mấy cái VBA hoặc hàm tự tạo để xử lý cho sale xong, cho rùi.
Sale làm đúng thì mình khỏe, sales làm sai mình vẫn xử lý được…………không phải bất ngờ.
...
2. Ưu tiên trước mọi ưu tiên:
Không để vấn đề xảy ra rồi phải giải quyết.
Lấy ví dụ như để xử lý bài #7: Nếu công việc cứ phải lặp lại thường xuyên và đau đầu vì nó, tại sao không tìm nguyên nhân sinh ra việc sai thứ tự màu, chấn chỉnh nó từ gốc, rồi ngồi rung đùi?
Nhỏng nhẻo quen rồi. Bất cứ vấn đề gì đưa lên GPE đều có công thức/hàm giải.
Riết rồi thành thói quen ỷ lại, không muốn phấn đấu cải cách (phương pháp làm việc), hay cải tiến (kiến thức kỹ thuật).
Cải cách phương pháp làm việc: khả năng không đủ, và môi trường không khuyến khích.
Cải tiến kến thức kỹ thuật: hầu hết đều tự dối mình là xem cách người ta dùng công thức một thời gian rồi sẽ quen.
Vấn đề là: "một thời gian" là bao lâu? Tuổi thanh xuân nó không đợi người. Nếu đã biết "yêu cuồng sống vội" cho tình yêu thì tại sao không biết "học cuồng thực tập vội" cho tiền đồ sự nghiệp?
Đó là cái khác nhau giữa con người chủ động và con người thụ động.
Than thở cho lắm nhưng cái cần thiết phải gải quyết nhất là: tại sao họ lại làm sai? Khi nào thì biết họ làm sai và khi nào thì biết đúng?
Lý luận "không phải bất ngờ" là tự dối mình. Không đủ khả năng phân tích tình huống.
Nhắc lại câu cuối của bài #7: << Em cũng là người thích tìm hiểu nhiều cách giải quyết trong cùng một vấn đề >>
Bản tính bạn không thích làm việc tập thể. Không thích ngồi lại với các nhơn viên sêu ấy mà thảo luận với họ. Tự bạn phân biệt dân chuyên kỹ thuật và dân chuyên giao tiếp rồi đổ thừa.
Chú thích: dân chuyên nghề giao tiếp cũng tự có mặc cảm là dân kỹ thuật xem thường mình dốt kỹ thuật, chỉ giỏi miệng. Muốn thông cảm nhau, ít nhất một trong hai bên phải biết kiên nhẫn tìm cách phá bỏ cái hàng rào ấy. Nếu mình ở trong vị trí yếu hơn (bên sêu kiếm tiền) thì bắt buộc phải nhẫn nhịn, chịu khó chìu chuộng khi tiếp xúc.
Câu chuyện khi GPE.COM chưa ra đời:
Khi CQ (cơ quan) chuyển sang trả lương sản phẩm tập thể; Lúc đó hai anh em chúng tôi vừa phải xài công thức, vừa phải viết Sub & Hàm UDF. Với qui định là ngày 5 hàng tháng phải quyết toán lương cho hơn 800 CNV theo sản lượng từng ca của các phân xưỡng & phòng ban phụ trợ
Vậy mà hai chúng tôi làm được 1 việc: Người LĐ xuống ca hàng ngày là họ áng chừng hôm í sẽ nhận được bao nhiêu tiền về cho gia đình của họ.
Theo cá nhân tôi, thì khi làm việc với file có chứa VBA thì tôi không muốn ghi công thức lên sheet nữa, còn nếu file không chứa VBA tôi cố gắng xử lý tất cả bằng công thức của Excel, nói chung là thuần công thức.
Hồi đó bà con chưa bắt mạch được GPE. Chưa biết ỏng ẹo đòi hỏi đủ thứ.
Có ai biết chỉ cho tôi diễn đàn nào mà đại đa số là nhờ làm giùm? Làm xong thì thêm thắt "còn chút nữa"? Nhiều bài còn nóng nảy, khoảng 1 tiếng đồng hồ sau lên nhắc nhở "có ai giúp em với"? Thậm chí có bài dùng giọng điệu thách thức "ca khó"?
Hồi trước có 1 đợt tuyển toàn sales giỏi Excel, lúc đó em cũng khỏe 1 thời gian…….nhưng kết quả là quá giỏi Excel mà không bán được hàng, cũng bị loại khỏi cuộc chơi……..
Có một số câu muốn nói mà bài 15 nói rồi nên tôi không lập lại. Còn vài câu khác:
Tại sao tuyển người mới mà không duy trì được cái "khỏe 1 thời gian" đó? Người sale cũ đi, không để lại cái gì cho người mới vào làm hay sao? Rồi cứ giả sử nó nghỉ ngang không bàn giao đi; người mới vào thay vì để họ tự quậy lên tự tìm cách để làm, sao không chỉ cho họ để đến nỗi mất cái "khỏe" đi?
Một chuyện nữa, với hình minh họa thì đó là 1 cái sai có hệ thống, theo bạn giải thích thì cái sai đó truyền từ người cũ sang người mới, truyền từ file cũ sang file mới, từ năm cũ sang năm mới, ... (hễ đụng đến mã màu là làm ngược tất tần tật 1 cách có hệ thống, có tư duy!). Cách giải thích của bạn nó vô lý lắm.
...Tại sao tuyển người mới mà không duy trì được cái "khỏe 1 thời gian" đó? Người sale cũ đi, không để lại cái gì cho người mới vào làm hay sao? Rồi cứ giả sử nó nghỉ ngang không bàn giao đi; người mới vào thay vì để họ tự quậy lên tự tìm cách để làm, sao không chỉ cho họ để đến nỗi mất cái "khỏe" đi?
...
Công ty đó có thể đặt nặng vào chỉ tiêu thu nhập. Có thể họ có cái KPI (*1) về sales.
Khi tuyển một người giỏi, có thể người ấy nhận việc với nhiều điều kiện đòi hỏi riêng mình. Tôi đã từng thấy những người khi rời một công ty sang công ty khác là kéo luôn một đội ngũ lính 3-5 người.
Cái lợi là gặp đội giỏi thì thu nhập tốt. Thời buổi kinh tế khó khăn thì bán hàng giỏi có thể là lẽ sống của công ty.
Cái hại lâu dài là những người sêu giỏi thường đâu có quan niệm về chung thủy. Người giỏi sẽ được nơi khác chú ý mời đi. Và vì họ sẵn sàng đi như thế cho nên họ không bao giờ tính đến chuyện lâu dài.
(*1) Lỗi chung của những ban quản lý sử dụng KPI không đúng cách là:
KPI vốn dùng để báo động những khu vực cần để ý để tránh sự cố, vấn đề.
Người quản lý không kinh nghiệm thường dùng nó để đo hiệu quả làm việc.
...
Một chuyện nữa, với hình minh họa thì đó là 1 cái sai có hệ thống, theo bạn giải thích thì cái sai đó truyền từ người cũ sang người mới, truyền từ file cũ sang file mới, từ năm cũ sang năm mới, ... (hễ đụng đến mã màu là làm ngược tất tần tật 1 cách có hệ thống, có tư duy!). Cách giải thích của bạn nó vô lý lắm.
Thứ nhất: nếu sai có hệ thống thì chưa chắc đã do nó sai. Đôi khi cũng do khâu sau người ta thay đổi cách làm việc khiến hai khâu không còn ăn khớp như hoạch định ban đầu. (Toi chỉ nói: nhìn lại, khả năng này thấp nhưng không có nghĩa là hiếm)
Thứ hai: ở trên tôi có nhắc "khi nào biết đúng và khi nào biết sai?". Nếu tác giả bài #7 trả lời rằng "nhìn vào biết đúng sai" thì tôi cũng như mấy người sales kia "nó nói vậy thì cứ kệ tía nó".
Thứ ba: tôi nhìn cái bảng dữ liệu đưa ra thì tôi chỉ có thể đoán già đoán non rằng mã màu phải theo thứ tự abc mới đúng.
Là dân kỹ thuật với nhau, người hỏi còn không diễn tả đủ để cho người khác hiểu. Bảo dân sales họ nghe thì còn phya. Chắc chắn nếu tôi là mấy người sales trong công ty ấy thì tôi chỉ cười mỉm chi khi tác giả bài #7 đề nghị tôi thay đổi cách làm việc cho công việc họ đỡ cực.
