Gió thổi mây bay – phong khởi vân động

Lần đăng status về chuyện tiêu chí chọn lựa gần nhất của mình trên Facebook đó là: “Ngon, bổ, rẻ, bền, đẹp.” và comment của người bạn là “Rẻ kill all” cũng là một trong những điểm đáng lưu tâm trong thế giới thực. Kill All có thể là đòn tổng lực nhưng không mấy hiệu quả cho các bài thi về lý thuyết nhỉ. [Lưu ý phần note này nhé, đừng lấy kinh nghiệm chinh chiến ra đấu với lý thuyết và môi trường lý tưởng nhé]

1. Câu chuyện thầu bè trong phần nội dung trong CISA

Phần trước bạn đã biết rằng mỗi năm các phòng ban/đơn vị sẽ có thời điểm là chuyện trình các dự án để được duyệt kinh phí, và sau khi được duyệt sẽ tiếp theo đến phần quan trọng nhất đó là đi chợ (mua sắm) và chọn lựa giữa những nhà thầu cùng với sản phẩm/dịch vụ được cung cấp. Phần này được bắt đầu từ việc ‘trình các dự án’ (business case) và được duyệt, phần sau của thầu bè chính là việc chi tiết các business case này trở thành các yêu cầu cụ thể.

Trước khi vào trọng tâm, bạn hãy đảo sơ lược qua phần business-case một xíu nhé. Business-case là cách gọi nôm na cho một (nhóm) dự án cùng với kết quả (delivery value) cụ thể (có thể cho từng giai đoạn) – mà nói chung cái value đó thường rất là hoành tá tràng và đủ thứ nhiêu khê thế nên mới cần có người làm công việc BA (Business Analyst); công việc của BA sẽ phân tách ra thành các business requirements và diễn dịch lại trở thành các yêu cầu dành cho CNTT (IT) sau đó các yêu cầu này lại được diễn dịch thành các Cases. [Đó là lý do vì sao có chữ test-cases, cũng như các yêu cầu thì có cả kỹ thuật (technical) và phi kỹ thuật (non-technical)].

Hình trích từ một cuốn sách: The Bridging the communication Gap by Toby Henderson

Ghi chú: tùy theo tính chức và độ phức lớn, phức tạp mà có vai trò của BA hoặc tư vấn nhé. Ở một số nơi áp dụng theo Agile thì vai trò của BA sẽ do Product Owner đảm nhiệm, cũng như họ sẽ là người kể chuyện (Story, Epics). Nhức đầu với Agile. Notes: cái hình 2.1 trên là trích từ testing dựa theo cách tiếp cận Agile nhé.

Khi hiểu rõ được các yêu cầu của Business rồi, công việc tiếp theo sẽ cần bảo mật của rất nhiều bên, đó là tiêu chí chấm điểm và thang điểm cho các hạng mục được yêu cầu. Tiêu chí này được xây dựng như là một phần của nội dung chọn lựa đối tác đi cùng cũng như để minh bạch hóa. Thông thường phần chọn lựa thầu tổng quát sẽ có một số điểm chung như sau:

• Mô tả phạm vi và mục đích của thầu – ví dụ như: cung cấp giải pháp XYZ gì đó cho doanh nghiệp [thường thì họ sẽ lấy các đề xuất được chọn lựa và thay đổi tên cho nó nghe hấp dẫn hơn]
• Thời gian thực hiện – tùy theo business case vẽ ra, có bao nhiêu phases và thuộc thể loại dài hạn hay ngắn hạn.
• Kết quả mong đợi của tổ chức.
• Chi phí được duyệt [thường bảo mật]
• Một lô một lốc các đk khác chẳng hạn như yêu cầu về tài chính, yêu cầu về nhân sự, kinh nghiệm …

Ghi chú: ở một số các công ty lớn và thuộc dạng Enterprise (to to) những tiêu chí về tài chính được ưu tiên dữ lắm, các vấn đề về kinh nghiệm cũng được quan tâm nhưng ở mức thấp hơn tiêu chí tài chính [thực tế là họ sợ bị ai đó mua lại và ko theo tiếp dự án].

Ghi chú: khi vấn đề năng lực và kinh nghiệm được đề cập cũng có một số tình huống cần lưu ý, khi chào thầu thì giới thiệu có anh ABC có profile khủng, công ty chọn thầu vì anh ABC ấy nhưng khi thực hiện thì anh ABC đó chả thấy đâu. [Lưu ý tình trạng mược Profile, bùa chú phần năng lực như không có người đúng như trong cam kết, có người thì không đủ chuyên môn để làm …]

Giả sử như sau các tiêu chí có rồi và các đơn vị nhận thầu đã gửi các hồ sơ, thông tin theo đúng các yêu cầu thì câu chuyện vẫn còn tiếp diễn đó là:

• Bên kỹ thuật sẽ căn cứ trên các tiêu chí đã được đưa ra để chấm điểm cho từng hạng mục. Thang điểm này đã được thống nhất là chiếm một số lượng % nào đó trong hồ sơ thầu, ví dụ như là 60%
• Bên mua hàng hay các bên khác cũng sẽ nhận được thông tin bảo mật và sẽ thực hiện việc chấm tương tự [tiêu chí cũng có rồi] và cũng sẽ có thang điểm phù hợp.
• Các tiêu chí quan trọng: Kỹ thuật, chi phí thực hiện, các vấn đề khác [pháp lý, điểm cộng ưu tiên …] sẽ được tổng hợp và mở ra khi [công khai], ừ thì theo lý thuyết là thế, và xem điểm đơn vị nào phù hợp nhất.
• Có thể sẽ có bước thương lượng, làm rõ nhưng sẽ chốt kết quả sớm thôi. Ai trúng được thầu là vui hay buồn thì hạ hồi phân giản.

Phần trên là những phần tóm lược khá đơn giản, những bạn đã tham gia thầu/bè làm hồ sơ rồi thì mấy cái này có gì mới đâu. Nhưng phần chính mình đề cập không phải phần này đâu [phí mất thời gian lướt qua nội dung này hen], phần mình đề cập chủ yếu là mấy cái notes và phần tiếp theo đây.

2.Các câu hỏi then chốt cho hoạt động thầu bè.

2.1 Ai sẽ là chuột đây?

Đời vốn không như là mơ, nên khi từ business cases đưa ra giải pháp ngoài chuyện đã có sẵn giải pháp rồi thì vẫn còn một số điểm cần phải mạo hiểm nhất là dự án quan trọng. Một trong những câu hỏi quen thuộc nhất là: “Có thằng nào làm chưa?” hoặc là “Giải pháp tương tự đã ứng dụng thành công là cái nào”. Đây là câu hỏi khó chịu nhất, nhưng dù sao cũng đúng, ai cũng muốn an toàn, có ai muốn mình làm chuột thí nghiệm đâu. Nếu đã có người thành công thì khả năng thầu đó đã được chỉ định nhất là trong các lĩnh vực hẹp. Ví dụ: ở VN thì PCI-DSS do Control Case bao sân, đây là lĩnh vực hẹp, họ lại có kinh nghiệm triển khai thành công cho nhiều bên, tại sao không chọn.

Nếu đó là một dự án hoàn toàn mới, cũng như chưa có ai từng làm vậy thì …bài toán khó gấp 4-5 lần và một khi quyết định chọn đối tác sai thì hậu quả cũng đi theo. Thế nên: khi đã làm chuột, mạo hiểm trở thành người đi đầu thì phải xác định liều và bài toán chi phí sẽ được cân nhắc rất kỹ. Nếu cả 2 bên theo xu hướng Win-Win thì ổn; thực tế thì khác biệt về văn hóa, kinh nghiệm sẽ là một vấn đề kinh khủng lắm. [Note: nếu đã quyết định làm chuột thì cũng phải có giá của nó chứ, xác định rủi ro và chấp nhận rủi ro (take-risk) để theo đuổi cơ hội cũng không quá đâu, miễn là nó hiệu quả]

2.2 Kinh nghiệm là thế nào?

Kinh nghiệm đầy mình là một lợi thế, tuy nhiên, kinh nghiệm đó sẽ sáng chói hơn nếu như được thể hiện ở đúng lĩnh vực, đúng thể loại doanh nghiệp và cũng như phạm vi thực hiện. Bên nhà thầu nếu chỉ thực hiện cho các doanh nghiệp vừa và nhỏ (SMB) sẽ gặp nhiều khó khăn cho các doanh nghiệp Enterprise và nó cũng sẽ khác biệt nhiều khi làm với nhà nước.

Một điểm khác cần lưu ý khi đối chiếu kinh nghiệm đó là “Ai” mới là người thực sự làm dự án đó. Không hiếm các trường hợp những đơn vị nhỏ kiệt xuất do không đủ điều kiện tài chính nên đành phải ở phía sau các công ty to đùng. Thế nên, thực tế một chút là: nếu biết và chốt được các đơn vị kiệt xuất phía sau thì cân nhắc trường hợp hỗ trợ, chi phí sẽ ổn hơn rất nhiều.

Ghi chú: kinh nghiệm thì phải bao gồm cả các dự án khó nhằn, chứ dự án nào cũng thành công tốt đẹp vầ sau đó đắp chiếu thì …cũng nên xem xét lại cái kinh nghiệm ấy. Mấy bài xác minh kinh nghiệm này thì dễ lắm, cũng không quá khó đâu, thường là người thực hiện dự án sẽ nhớ rất rõ những gì mình đã trải qua và khi họ thuật lại sẽ có một sự lôi cuốn nhẹ nhàng nhưng có mùi mồ hôi và máu đấy [đùa đấy, máu đâu ra, cùng lắm bị hăm dọa thôi].

2.3 Tham chiếu và nghiệm thu.

Chọn nhà thầu mà, đôi khi phải tham chiếu việc họ triển khai và cách hành xử sau khi thực hiện xong dự án. Đây cũng là hoạt động chủ yếu để xác định các đơn vị, cá nhân kiệt xuất để tranh thủ lôi kéo (he..he..) cũng như xác định, đối chiếu khả năng thành công của tổ chức, doanh nghiệp mình. Tham chiếu là một hình thức đảm bảo cho các chọn lựa, bên nào PR tốt thì sẽ có lợi thế thôi.

Một bài học xương máu khi nghiệm thu đó là nghiệm thu từng phần, xong phần nào nghiệm thu phần đó và kết quả sau khi nghiệm thu xong hết tất cả là…hệ thống không hoạt động ka..ka…Bài học này được tổng kết lại là: Nghiệm thu tổng thể, ký review từng phần. Câu trong ISACA thường được nhắc tớ là: Giá trị tổng thể luôn lớn hơn tổng của từng phần. [Định nghĩa về chứ System có đề cập đến nhưng không hiểu ý nghĩa nên dễ ăn đòn thôi].

Những vấn đề tham chiếu sau nghiệm thu là một trong những yếu tố cần thiết để hạn chế việc bỏ của chạy lấy người, nhất là các dự án cần 2-3 hoặc lâu hơn để triển khai. Chuyện chỉ đơn giản là một số nơi khi nghiệm thu đến giai đoạn gần cuối, chốt được hơn 80% giá trị tổng hợp đồng, phần còn lại họ sẵn sàng bỏ ngang. [vì phí sức và mệt quá –> chuyện đó ai xử lý nhỉ ?]

2.4 Ràng buộc nhân sự + bảo hiểm + …

Kinh nghiệm: “PM đối tác tìm thú vui mới, bác tổng bên ta cũng nhức đầu”; với các dự án dài hơi thì chuyện này như cơm bữa, và đặc biệt là các key-member (của cả 2 bên luôn á) đi theo tiếng gọi của gì đó [sau thời gian vật lộn với dự án, họ cảm thấy rằng đã lên level – ừ lên thật mà – và nhu cầu tăng nhưng chưa thể đáp ứng + tiếng gọi/chào mời hấp dẫn thì …vấn vương lắm nhưng đành thôi …]

Bảo hiểm là một hình thức để giảm thiểu, có thể không ràng buộc nhân sự nhưng yêu cầu các bên cung cấp người có trình độ tương đương –> mua các dịch vụ giám sát độc lập, trọng tài hoặc nhà cung cấp giải pháp để yêu cầu can thiệp khi dự án ở giai đoạn lùi không được, tiến cũng chả xong và sức nóng hơn cả núi lửa …

Các hình thức bảo hiểm có thể kể tới: nhân sự tương đương; nhà cung cấp phạt đơn vị thầu các dự án khác [hăm dọa về uy tín]; phạt hợp đồng …

Định tiếp mà thôi, thấy nó dài rồi nên dừng vậy.

2019/07/23

PS: trong phần này có nêu ra một vài kinh nghiệm được chia sẻ của người bạn vật lộn với dự án ERP từ năm 2009; những đòn đau không phải vì độ khó mà vì nghiệp vụ. Một thời cafe góc phố lề đường…cho tới giờ người bạn đó trở thành chuyên gia cao cấp PowerBI tại VN. [chả liên can gì tới cái ERP của Oracle].