Với doanh nghiệp EPC/MEP, chuẩn bị một hồ sơ thầu không đơn giản là nhận BOQ rồi điền đơn giá. Một tender thường bắt đầu từ lúc Sales hoặc BD nhận cơ hội, sau đó kỹ thuật và QS phải xác định scope, xây BOQ, kiểm tra vật tư, supplier và nhiều phương án khác nhau trước khi cấp quản lý xem lại margin, rủi ro và quyết định có phát hành hồ sơ hay không. Trong suốt quá trình đó, yêu cầu từ khách có thể tiếp tục thay đổi, BOQ phải revise nhiều lần và thời gian chuẩn bị đôi khi chỉ được tính bằng vài ngày. Khi tất cả vẫn chạy qua Excel, Drive, email và chat, càng nhiều người tham gia thì doanh nghiệp càng khó biết đâu là bộ dữ liệu đang đúng ở thời điểm hiện tại.
Đó là lý do bài toán tự động hóa Tender không nên bắt đầu bằng câu hỏi “có thể thay Excel bằng phần mềm nào?”. Excel vẫn rất mạnh cho tính toán và xử lý dữ liệu. Vấn đề thật sự nằm ở chỗ doanh nghiệp đang dùng Excel như một công cụ tính toán hay đang vô tình dùng hàng chục file Excel để thay cho cả một hệ thống vận hành. Khi BOQ, version, approval, supplier, lịch sử thay đổi và kết quả tender đều nằm rải rác, rủi ro không còn là một file khó tìm mà là việc doanh nghiệp không có một nguồn dữ liệu đủ rõ để kiểm soát toàn bộ quy trình.
Tự động hóa bóc tách BOQ trước hết là giảm những việc phải làm lại
Khi nghe tới “tự động hóa bóc tách BOQ”, nhiều người hình dung một hệ thống có thể tự đọc bản vẽ hoặc hồ sơ mời thầu rồi tạo ra toàn bộ khối lượng. Đây có thể là một hướng phát triển trong tương lai, nhưng không phải nơi duy nhất tạo ra giá trị. Trong thực tế, một phần đáng kể thời gian của đội Tender lại bị tiêu tốn bởi những việc đơn giản hơn rất nhiều: tìm item đã dùng ở dự án trước, copy một BOQ cũ, sửa unit, kiểm tra supplier, dựng lại cấu trúc system và category hoặc đối chiếu xem file hiện tại có đang dùng đúng dữ liệu mới nhất hay không.
Nếu doanh nghiệp đã làm hàng trăm tender, phần lớn kiến thức cần thiết thực ra đã tồn tại ở đâu đó trong những BOQ cũ. Vấn đề là dữ liệu đó đang nằm dưới dạng file, nên rất khó tái sử dụng một cách có kiểm soát. Một kỹ sư nhiều kinh nghiệm có thể biết phải mở dự án nào để tìm một item tương tự, nhưng người mới lại không có cùng kiến thức đó. Khi người phụ trách nghỉ việc hoặc đội Tender tăng nhanh, doanh nghiệp gần như quay lại điểm xuất phát và tiếp tục copy từ những file mà không ai chắc còn đúng hay không.
EPCore Tender xử lý vấn đề này bằng cách đưa BOQ về cấu trúc dữ liệu gồm system, category và item, đồng thời quản lý những thành phần nền như unit và supplier trong master data. Khi dữ liệu đã được chuẩn hóa, doanh nghiệp có thể xây thư viện BOQ dùng lại cho các tender sau thay vì mỗi dự án lại tạo ra một bộ dữ liệu hoàn toàn mới. Template có thể giữ lại những cấu trúc thường xuyên lặp lại, còn đội kỹ thuật vẫn điều chỉnh khối lượng và phạm vi theo tình hình thực tế của từng tender. Tự động hóa ở đây không thay kỹ sư quyết định chuyên môn; nó giúp những kiến thức đã được tạo ra không phải nhập lại từ đầu ở mỗi dự án.
Một BOQ tốt không chỉ cần đúng số, mà còn phải biết nó thuộc phương án nào
Một điểm khó khác của Tender EPC/MEP là cùng một hồ sơ có thể tồn tại nhiều phương án song song. Doanh nghiệp có thể cần một phương án tối ưu giá để cạnh tranh, một phương án cân bằng giữa giá và yêu cầu kỹ thuật, hoặc một option sử dụng thương hiệu cao hơn để khách hàng lựa chọn. Nếu mỗi phương án được quản lý bằng một file Excel riêng, sau vài vòng thay đổi sẽ rất khó biết những file đó còn đang dựa trên cùng một scope hay đã bắt đầu lệch nhau.
Điều quản lý cần biết lúc này không chỉ là tổng giá của từng option. Quan trọng hơn là phải thấy sự khác biệt nằm ở đâu, item nào thay đổi, supplier nào được sử dụng, option nào đã được đội kỹ thuật xác nhận và option nào đang được chuẩn bị để phát hành. Nếu ba phương án nằm trong ba workbook độc lập, việc so sánh nhanh giữa các BOQ thường phải quay lại cách làm thủ công, trong khi mỗi lần chỉnh sửa lại tạo thêm nguy cơ hai phương án không còn cùng một cơ sở dữ liệu.
EPCore Tender tổ chức nhiều BOQ option trong cùng một version hồ sơ. Cấu trúc này giúp phương án A, B hoặc C vẫn thuộc cùng một Tender và cùng một thời điểm dữ liệu, thay vì trở thành những file rời rạc không còn mối liên hệ rõ ràng. Các amount quan trọng được tính ở backend, nhờ đó doanh nghiệp cũng giảm phụ thuộc vào những công thức Excel có thể vô tình bị sửa hoặc tham chiếu sai. Khi BOQ bắt đầu ảnh hưởng trực tiếp tới giá trị hồ sơ hàng tỷ đồng, việc kiểm soát cách con số được tạo ra quan trọng không kém việc có thể tính ra con số đó.
Version control là phần doanh nghiệp thường chỉ thấy quan trọng sau khi đã gửi nhầm một hồ sơ
Trong quy trình sử dụng file, version thường được quản lý bằng tên. Người đầu tiên tạo v1, người tiếp theo tạo v2, sau đó xuất hiện final, final_new, final_ok và những tên tương tự. Cách này vẫn có thể hoạt động khi chỉ có một người làm và số lượng tender còn ít, nhưng nhanh chóng trở nên nguy hiểm khi nhiều bộ phận cùng chỉnh sửa và deadline bắt đầu sát hơn.
Một version hồ sơ thực tế không chỉ là bản sao mới hơn của file cũ. Nó còn phản ánh một trạng thái nghiệp vụ. Có version đang được chỉnh sửa, version đã được gửi nội bộ để duyệt, version bị reject vì margin hoặc rủi ro, và version đã được approve để sử dụng cho bidding. Nếu doanh nghiệp chỉ dùng tên file để biểu diễn tất cả những trạng thái này thì thông tin quan trọng nhất của quy trình đang nằm trong trí nhớ của người làm, chứ chưa nằm trong hệ thống.
Trong EPCore Tender, mỗi Tender có thể có nhiều version và mỗi version mang trạng thái riêng như draft, submitted, approved hoặc rejected. Khi hồ sơ cần sửa sau khi bị reject, hệ thống tạo version mới thay vì ghi đè lên version trước. Nhờ vậy doanh nghiệp có thể quay lại và hiểu v1 đã được submit lúc nào, vì sao bị từ chối, v2 đã thay đổi những gì và cuối cùng version nào được sử dụng để bước vào bidding. Cách quản lý này biến lịch sử thay đổi từ một chuỗi file khó hiểu thành một phần dữ liệu có thể truy vết.
Phê duyệt nội bộ chỉ có giá trị khi người duyệt biết mình đang duyệt đúng version
Trong nhiều doanh nghiệp, BOQ được chuẩn bị khá bài bản nhưng bước phê duyệt cuối cùng vẫn diễn ra qua chat hoặc email. Người làm Tender gửi một file cho quản lý, sau đó tiếp tục sửa vì phát hiện thêm vấn đề. Trong lúc đó quản lý mở file cũ, xem số liệu và trả lời “OK”. Cả hai phía đều đã làm đúng phần việc của mình, nhưng kết quả cuối cùng lại có thể là một hồ sơ chưa từng được duyệt thật sự.
Đây là lý do workflow không thể tách khỏi version. EPCore Tender mô hình hóa luồng từ draft sang submit, approve hoặc reject; nếu cần chỉnh sửa thì tạo version mới rồi tiếp tục vòng duyệt. Khi hồ sơ đã đạt trạng thái approved theo rule của doanh nghiệp, Tender mới được đưa sang bước bidding. Cơ chế này giúp câu “đã duyệt rồi” có một ý nghĩa rõ ràng hơn: ai đã duyệt, duyệt version nào và dữ liệu tại thời điểm duyệt là gì.
Khi nhiều người cùng thao tác, hệ thống còn cần ngăn trường hợp hai người đang xử lý trên hai trạng thái khác nhau. EPCore Tender sử dụng lock và optimistic concurrency cho những thao tác quan trọng để hạn chế việc dữ liệu bị ghi đè hoặc một thao tác approve được thực hiện trên phiên bản đã thay đổi. Đây là những chi tiết người dùng cuối ít nhìn thấy, nhưng lại là phần khiến một hệ thống điều hành quy trình Tender khác bản chất với việc đưa file lên một thư mục online. Hệ thống không chỉ lưu dữ liệu mà còn bảo vệ tính đúng đắn của quá trình dữ liệu được thay đổi.
Khi dữ liệu Tender được chuẩn hóa, dashboard mới bắt đầu có ý nghĩa
Doanh nghiệp thường muốn có dashboard ngay từ đầu, nhưng dashboard chỉ đáng tin khi dữ liệu phía dưới đủ sạch. Nếu trạng thái Tender được cập nhật bằng cảm tính, version không rõ ràng và kết quả won/lost không được ghi nhận nhất quán thì một biểu đồ đẹp cũng chỉ tổng hợp lại dữ liệu thiếu kiểm soát.
Khi pipeline đã được chuẩn hóa thành những trạng thái như draft, pending approval, approved, bidding, won, lost hoặc cancelled, doanh nghiệp bắt đầu có khả năng nhìn Tender ở góc độ vận hành thay vì chỉ nhìn từng hồ sơ riêng lẻ. Quản lý có thể biết hồ sơ đang bị kẹt nhiều nhất ở bước nào, thời gian từ lúc tạo draft tới khi được approve thường kéo dài bao lâu, một team đang xử lý bao nhiêu tender và tỷ lệ thắng thay đổi thế nào theo thời gian. Những chỉ số như cycle time, approval time hay win rate lúc này không còn phải tổng hợp thủ công từ nhiều file mà có thể được hình thành từ chính lịch sử workflow.
Giá trị lớn hơn nằm ở chỗ mỗi Tender won hoặc lost đều trở thành dữ liệu cho những tender sau. Nếu doanh nghiệp nhận ra những hồ sơ bị reject nội bộ thường xuất phát từ một nhóm lỗi giống nhau, quy trình có thể được điều chỉnh. Nếu một nhóm tender có cycle time quá dài, quản lý có thể tìm đúng bước đang gây tắc nghẽn. Khi dữ liệu đủ tốt, Tender Management không còn chỉ giúp đội QS làm hồ sơ nhanh hơn mà trở thành công cụ để doanh nghiệp cải thiện cách làm thầu theo thời gian.
Phần mềm generic thường gặp giới hạn vì Tender không chỉ là một danh sách Task
Một phần mềm quản lý công việc thông thường hoàn toàn có thể giúp tạo task, đặt deadline, upload file và comment. Những chức năng này vẫn hữu ích trong Tender, nhưng chúng không giải quyết được phần khó nhất nếu phần mềm không hiểu cấu trúc dữ liệu phía sau. Tender có Project, mỗi Project có Version, mỗi Version có nhiều BOQ option, từng option lại chứa system, category và item. Approval phải tác động lên đúng version và khi won còn phải xác định được winning version cùng winning option.
Nếu một hệ thống ngay từ đầu chỉ hiểu Tender là một task có file đính kèm, doanh nghiệp vẫn có thể cố tùy chỉnh thêm nhiều trường để sử dụng. Nhưng càng đi sâu, những workaround này càng khó kiểm soát vì cấu trúc nền không phản ánh đúng nghiệp vụ. Đây là lý do một đơn vị phát triển phần mềm phải hiểu được nghiệp vụ thực tế trước khi quyết định database, workflow hay giao diện cần được xây ra sao. Nếu data model đúng từ đầu, nhiều chức năng sau đó trở nên tự nhiên; nếu data model sai, càng thêm tính năng thì hệ thống càng phức tạp.
Tender Management là ví dụ khá rõ về giá trị của custom software. Doanh nghiệp không cần một phần mềm có thật nhiều nút, mà cần một hệ thống hiểu đúng sự khác biệt giữa Project, Version, BOQ Option, Approval và Bidding. Giao diện chỉ là lớp phía trên. Phần quyết định hệ thống có sử dụng được lâu dài hay không nằm ở cách những khái niệm nghiệp vụ đó được mô hình hóa thành dữ liệu và rule.
Tư duy này giống CRM theo yêu cầu, dù Tender Management không phải CRM
EPCore Tender không phải CRM và cũng không nên cố biến thành CRM. Nhưng cách xây một hệ thống Tender chuyên sâu có cùng tư duy: thay vì bắt đầu từ danh sách tính năng có sẵn, đội phát triển phải bắt đầu từ cách doanh nghiệp thật sự làm việc, dữ liệu nào tồn tại, dữ liệu nào liên quan với nhau và quyết định nào cần được kiểm soát bằng workflow.
Trong CRM, doanh nghiệp có thể cần mô hình hóa Contact, Deal, Project, báo giá và các bước phê duyệt riêng. Trong Tender Management, cấu trúc lại xoay quanh Tender Project, Version, BOQ Option, master data, approval và bidding. Hai hệ thống khác nhau về nghiệp vụ nhưng giống nhau ở một điểm: phần mềm chỉ tạo ra lợi thế khi nó được xây quanh logic thật của doanh nghiệp thay vì buộc doanh nghiệp phải thay đổi toàn bộ cách làm chỉ để phù hợp với một cấu trúc generic.
Đây cũng là lý do custom software thường phù hợp hơn khi quy trình đã trở thành một phần năng lực cạnh tranh của doanh nghiệp. Nếu doanh nghiệp làm Tender giống hệt mọi công ty khác và nhu cầu chỉ dừng ở lưu file, một công cụ generic có thể đã đủ. Nhưng khi cách xây BOQ, quản lý supplier, approval, option và bidding chứa nhiều kinh nghiệm riêng tích lũy qua nhiều năm, việc đưa những logic đó vào phần mềm chính là cách biến kinh nghiệm vận hành thành một tài sản có thể sử dụng lại.
Tự động hóa tốt không phải loại bỏ chuyên môn của người làm Tender
Một hệ thống Tender tốt không nên cố thay kỹ sư quyết định scope, thay QS đánh giá BOQ hay thay quản lý quyết định margin và rủi ro. Đây là những phần cần kinh nghiệm, hiểu dự án và chịu trách nhiệm của con người. Nếu phần mềm cố tự động hóa cả những quyết định chưa đủ dữ liệu để tự động hóa, hệ thống có thể tạo thêm rủi ro thay vì giảm rủi ro.
Phần nên được tự động hóa là những việc con người không cần phải làm lại: tìm lại dữ liệu đã tồn tại, dựng lại cấu trúc BOQ, kiểm tra version, chuyển hồ sơ tới đúng người duyệt, giữ lịch sử thay đổi, tính amount theo rule thống nhất và tổng hợp trạng thái cho quản lý. Khi những phần này được hệ thống xử lý, đội Tender có thêm thời gian cho các quyết định chuyên môn thật sự tạo ra khác biệt trong hồ sơ.
EPCore Tender được xây theo đúng hướng đó: master data và template tạo nền dữ liệu dùng chung; Tender được tạo ở draft; team xây BOQ và các option; version được submit để approve hoặc reject; hồ sơ cần sửa sẽ tạo version mới; version được duyệt mới đi tới bidding; cuối cùng kết quả won, lost hoặc cancelled được giữ lại cho analytics. Toàn bộ chuỗi này không biến người làm Tender thành người chỉ bấm nút. Nó giúp những quyết định của họ được thực hiện trên một nền dữ liệu rõ ràng hơn và để lại lịch sử đủ tốt cho doanh nghiệp sử dụng về sau.
Giá trị cuối cùng của tự động hóa Tender vì vậy không nằm ở việc thay Excel bằng một màn hình web. Nó nằm ở việc biến BOQ, version, approval, lịch sử và kinh nghiệm làm thầu từ những dữ liệu rời rạc thành một quy trình có thể kiểm soát, đo lường và tiếp tục cải thiện. Khi doanh nghiệp đạt tới mức đó, mỗi Tender mới không còn bắt đầu từ con số không mà được xây trên những gì tổ chức đã học được từ những Tender trước.