Theo quy định của Luật Đấu thầu số 43/2013/QH13, Nghị định số 63/2014/NĐ-CP về đấu thầu, Nghị định số 37/2015/NĐ-CP về hợp đồng trong hoạt động xây dựng… đã loại bỏ loại hợp đồng theo tỷ lệ %. Như vậy, khi ký hợp đồng tư vấn, Chủ đầu tư và Tư vấn không thể dùng tỷ lệ nội suy theo Quyết định số 957/QĐ-BXD để xác định chi phí tư vấn, ký hợp đồng và sau này thanh quyết toán hợp đồng tư vấn thì điều chỉnh lại theo giá trị dự toán được phê duyệt nữa. Nắm bắt được nội dung này, các kỹ sư GXD đã phát triển trong phần mềm Dự toán GXD 10 tính năng hỗ trợ lập dự toán chi phí tư vấn theo phương pháp man-months (tháng người). Không chỉ là phần mềm, các giảng viên – kỹ sư GXD còn biên soạn tài liệu hướng dẫn sử dụng và các bài tập minh họa bằng số liệu cụ thể. Điều này đem lại sự thuận lợi cho các Chủ đầu tư và Tư vấn khi chọn sử dụng phần mềm Dự toán GXD 10. Năm 2011 tôi đã làm luận văn thạc sĩ KT&QLXD về đề tài liên quan đến xác định chi phí tư vấn theo man-months. Kết hợp thời gian qua đã lập hoặc thẩm tra – tiếp xúc với nhiều dự toán man-months nên sẽ có ít nhiều kinh nghiệm hướng dẫn, chia sẻ các bạn tính đúng, tính đủ dự toán chi phí Tư vấn… Nay lập chủ đề này để hướng dẫn cho các bạn đồng nghiệp đang sử dụng phần mềm Dự toán GXD 10 cách lập dự toánchi phí Tư vấn man months – hướng dẫn chuyên môn và cách làm đem lại hiệu quả hơn nhiều lần kinh phí bạn đầu tư cho phần mềm. Vì thế đang dùng phần mềm nào không có tính năng này và đang Bí không biết làm thế nào bạn hãy mạnh dạn đổi phần mềm đi cho công việc được thuận lợi. Bởi các ví dụ và tài liệu sẽ sử dụng giáo cụ minh họa là Dự toán GXD 10. Đang gặp khó khăn về lập dự toán chi phí tư vấn thì chủ đề này sẽ đem lại lợi ích cho bạn hơn nhiều lần giá trị đầu tư phần mềm  ❖ Trong nhiều trường hợp Developer sẽ là người nhận ủy thác công việc và được yêu cầu phải đưa ra Es... ❖ Trong nhiều trường hợp Developer sẽ là người nhận ủy thác công việc và được yêu cầu phải đưa ra Estimate (ở công ty mình thì dev leader sẽ là người thực hiện EST). ❖ Khi thực hiện Estimate hẳn các bạn đã quá quen với cụm từ Man-month, Man-day rồi (với đứa comtor với vào nghề như tuôi thì tuôi chả biết nó là cái gì sấc - à mà giờ tuôi cũng hiểu được đại khái rồi nha). ❖ Tiện đây mình sẽ share về cách phân bổ Estimate của các developer trong cách viết Estimate document để giao cho khách hàng. ①Ngày công của Developer và đơn vị Man-month: - Thuật ngữ ngày công hay còn gọi là công số bên mình sẽ dùng từ Effort/工数. - Trong tài liệu Estimate cần tính toán số nhân công để đưa ra Budget/dự toán cần thiết. Nhân công nghĩa là số lượng công việc tính trên 1 người, được tính bằng đơn vị Man-month hoặc Man-day. - Formula/Công thức: Man-day X chi phí ngày công. - Đối với các dự án Outsource, chi phí được trả theo giờ (Billable Hour). Tức là thù lao/Wage sẽ được trả ứng với số giờ lao động, chứ không phải ứng với sản phẩm hoàn thành. - Có rất nhiều cách tính toán Man-month, Man-day. Giá 1 Man-month sẽ phụ thuộc vào kinh nghiệm cũng như kỹ thuật. Chi phí Man-month ở các nước như Mỹ, Tây Ây sẽ khá cao, nhưng ở Châu Á thì thấp hơn. Ở Nhật Bản, 1 Man-month sẽ tầm 50 man yên (96 triệu VNĐ) đến 150 man yên (288 triệu VNĐ) ②Tính toán số tiền dự toán/Budget/予算: - Khi đưa ra số tiền dự toán, trước tiên cần tìm số nhân công từ quy mô của dự án. Budget = số nhân công X giá của man-month/man-day - Tuy nhiên, sẽ có trường hợp cần cộng thêm các chi phí khác như nhân công quản lý (cost for PM), chi phí làm document, chi phí cho communicator,.... rồi mới ra được Budget. ③Hợp đồng khoán sản phẩm/請負契約 - Có nhiều trường hợp developer sẽ nhận dự án với cách tính toán nhân công như phía trên, nhưng cũng có trường hợp làm theo hợp đồng khoán/thầu sản phẩm, phía khách hàng sẽ quyết định giá của sản phẩm. Ví dụ: Khách đưa ra budget khoảng 500 man yên và bảo mày làm cho tao 1 cái Web chạy batch tính toán doanh thu theo ngày, theo tháng và theo năm... thì trường hợp này khách sẽ quyết định số nhân công dự tính. ⇒Trong trường hợp dự án làm theo dạng hợp đồng khoán sản phẩm thì bên team phát triển cũng cần estimate/confirm lại để xem có phát sinh sự chênh lệch, sai khác/差異 giữa budget team dự đoán và số tiền khách đưa ra. (cái này mà ko xem xét/検討 kỹ thì có mà lỗ sấp mặt) ④Pre-condition/Điều kiện tiền đề của việc Estimate - Khi thực hiện est không chỉ viết dự toán mà còn cân nhắc cả quyết định về điều kiện tiền đề để tránh những phiền toái, vấn đề về sau. Quyết định điều kiện tiền đề được thống nhất giữa khách và team develop. ⑤Phạm vi Estimate và ngoài phạm vi estimate - Cần tạo một check-list liệt kê những phần Function và cả Non-function mà team sẽ đối ứng. Nếu khách yêu cầu làm thêm những chức năng hoặc khách yêu cầu thay đổi/chỉnh sửa mà khác biệt nhiều so với nội dung yêu cầu ban đầu thì sẽ tính đó là ngoài phạm vi estimate và charge fee (nếu cần). ⑥Kỳ hạn của dự án - Thông thường nếu thời gian hoàn thành và giao nộp sản phẩm ngắn thì số tiền dự án cao, còn nếu thời gian dài thì có thể thương lượng để giảm giá xuống. ⑦Phân bổ tỉ lệ chi phí dự toán phần mềm - Ví dụ bảng phân bổ tỉ lệ chi phí dự toán ở công ty mình:
- Tùy thuộc vào đặc điểm dự án và các điều kiện tiền đề mà tỉ lệ có thể khác nhau. Ví dụ dự án mình đang phụ trách thì phần Requirement specification và Design là bên khách làm nên chỉ có rate là 0 nhưng bù lại rate bên Comtor sẽ rất là cao. - Dự án theo kiểu upgrage thì Deploy cũng có rate = 0% Nên tùy mỗi dự án khác nhau sẽ có rate khác nhau chứ không có cai nào là tiêu chuẩn cả. ⑧ Cách viết estimate document Cách viết estimate document có thể chia làm 2 loại lớn. Cách viết nêu các mục theo công đoạn Estimate document sẽ được chia thành các mục theo từng công đoạn. Viết số nhân công cho từng công đoạn rồi nhân với giá tiền là đã có thể tạo thành estimate document. Những mục như dưới đây thường được sử dụng trong nhiều trường hợp.
Dưới đây là ví dụ: Cách viết khi hệ thống sử dụng phương thức khoán Trong trường hợp các công đoạn chi tiết được viết ở 1 văn bản khác thì estimate document có thể viết bằng cách coi chi phí dự toán là chi phí thiết lập hệ thống và được khoán trả 1 lần. |
