Vì sao cần Technical Due Diligence?
Một sản phẩm có giao diện đẹp và vận hành ổn định bên ngoài vẫn có thể ẩn chứa rủi ro lớn bên trong: mã nguồn rối rắm không ai dám sửa, phụ thuộc vào 1-2 nhân sự hiếm, hoặc lỗ hổng bảo mật chưa từng được kiểm tra. Với các bên định rót vốn hoặc mua lại, những rủi ro này ảnh hưởng trực tiếp đến định giá và chi phí vận hành sau giao dịch.
Technical Due Diligence đánh giá những gì?
- Chất lượng mã nguồn: mức độ tài liệu hóa, khả năng bảo trì, số lượng "nợ kỹ thuật" tồn đọng
- Kiến trúc hệ thống: khả năng chịu tải và mở rộng khi tăng trưởng người dùng
- Bảo mật: lỗ hổng đã biết, cách quản lý dữ liệu người dùng và tuân thủ quy định
- Phụ thuộc nhân sự/công nghệ: hệ thống có phụ thuộc vào 1-2 người hiểu toàn bộ logic, hoặc công nghệ đã lỗi thời không
- Chi phí vận hành thực tế: chi phí hạ tầng, license và bảo trì dự kiến sau giao dịch
Quy trình đánh giá thường diễn ra thế nào?
- Ký NDA và nhận quyền truy cập read-only vào mã nguồn/hạ tầng
- Audit mã nguồn, kiến trúc và bảo mật theo checklist tiêu chuẩn
- Phỏng vấn đội kỹ thuật hiện tại để đánh giá mức độ phụ thuộc nhân sự
- Bàn giao báo cáo rủi ro kỹ thuật kèm khuyến nghị điều chỉnh định giá/điều khoản (nếu có)
Ai nên thực hiện việc đánh giá này?
Nên là một bên độc lập, không có xung đột lợi ích với cả hai phía giao dịch — không phải đội kỹ thuật của bên bán, và cũng không nên là đội sẽ tiếp quản vận hành sau này nếu muốn đánh giá thực sự khách quan.