RFP hệ thống quản lý sản xuất 2026 – chênh 3 lần là do tiền đề

“Chúng tôi gửi cùng một nội dung cho 3 nhà cung cấp, vậy mà số tiền chênh nhau tới 3 lần. Biết tin vào bên nào bây giờ”. Khi nhận tư vấn về việc nâng cấp hệ thống tại các nhà máy Nhật Bản ở Thái Lan, đây gần như luôn là câu hỏi đầu tiên được đưa ra. Nhưng khi nghe kỹ câu chuyện, cái gọi là “cùng một nội dung” mà 3 nhà cung cấp nhận được, trong hầu hết trường hợp, hoàn toàn không giống nhau. Thứ khác nhau không phải giá, mà là tiền đề. Bài viết này theo dõi xem việc lập RFP (đề nghị mời thầu) cho hệ thống quản lý sản xuất làm khoảng chênh báo giá thu hẹp lại nhờ điều gì, qua một trường hợp mô hình tại nhà máy ở Ayutthaya.

Vì sao RFP cho hệ thống quản lý sản xuất luôn bị dời lại

Khi hỏi các nhà máy vừa bắt đầu cân nhắc thay mới hệ thống quản lý sản xuất rằng “công ty có định lập RFP không”, phần lớn câu trả lời nhận được là “chúng tôi không đủ sức làm tới mức đó”. Đào sâu vào lý do thì thường quy về ba điều.

Thứ nhất là không có người viết được. Số nhà máy tại Thái Lan bố trí được nhân sự chuyên trách CNTT không nhiều. Thực tế là trưởng phòng quản lý sản xuất hoặc người phụ trách kỹ thuật kiêm nhiệm việc làm việc với nhà cung cấp, nên công việc đưa yêu cầu vào văn bản bị đẩy về phía sau như một việc không gắn trực tiếp với sản xuất hằng ngày. Vì đó là việc không có hạn chót nên nó không bao giờ được khởi động.

Thứ hai là kỳ vọng rằng nhà cung cấp sẽ sắp xếp yêu cầu giúp. Trên thực tế, những nhà cung cấp có kinh nghiệm sẽ đi khảo sát hiện trường và trình bày yêu cầu dưới dạng đề xuất. Đây là một cách làm tử tế, nhưng xét về cấu trúc thì đó là trạng thái “yêu cầu của bên đặt hàng đang do bên nhận đơn hàng định nghĩa”. Bên đặt hàng không có căn cứ nào để kiểm chứng xem định nghĩa đó có đúng hay không. Hơn nữa, nếu mỗi bên tự đi khảo sát riêng thì mỗi bên sẽ mang về một bộ yêu cầu khác nhau.

Thứ ba là hình dung về tài liệu RFP quá nặng nề. Người ta tưởng tượng ra một tập đặc tả dày vài chục trang rồi từ bỏ ngay từ đầu vì nghĩ mình không viết nổi thứ đó. Nhưng RFP trong thực hành là tài liệu để thống nhất ba việc, gồm muốn đạt được điều gì, muốn báo giá bao gồm tới đâu, và sẽ chọn theo tiêu chí nào. Nó không phải bản thiết kế hệ thống. Bản chất nằm ở chỗ tất cả các bên có đang nhìn cùng một tờ giấy hay không, chứ không nằm ở độ dày.

Và cả ba lý do này đều không tính tới “chi phí của việc không viết RFP”. Kết quả của việc không viết sẽ lộ diện ngay khoảnh khắc báo giá gửi về, dưới hình dạng một mớ số tiền hỗn loạn. Về những lối đi điển hình khiến bản thân việc triển khai vấp ngã, chúng tôi đã sắp xếp trong bài vì sao việc triển khai hệ thống quản lý sản xuất thất bại, và phần lớn cửa vào của những thất bại đó nằm ngay ở giai đoạn lựa chọn nhà cung cấp.

Phân biệt RFP với RFI và tài liệu định nghĩa yêu cầu – dùng cái gì, khi nào, ai dùng

Khi nói tới RFP, không hiếm khi cuộc thảo luận cứ thế tiếp diễn trong lúc ranh giới với tài liệu định nghĩa yêu cầu vẫn còn mơ hồ. Hai thứ này chứa những nội dung giống nhau, nhưng thời điểm sử dụng và mục đích thì hoàn toàn khác.

Theo bài giải thích của Computer Management, RFP là tài liệu do bên đặt hàng lập ra trước khi lựa chọn nhà cung cấp và trình cho nhiều nhà cung cấp cùng lúc. Ngược lại, tài liệu định nghĩa yêu cầu là thứ được bên đặt hàng và nhà cung cấp cùng nhau xây dựng sau khi đã chốt nhà cung cấp. Sẽ dễ sắp xếp hơn nếu coi cái trước là “tài liệu để so sánh”, còn cái sau là “tài liệu để triển khai”.

Trước cả hai thứ đó còn có một bước nữa là RFI (đề nghị cung cấp thông tin). Đây là việc đề nghị nhà cung cấp đưa ra thông tin, nhằm biết trên thị trường đang có những sản phẩm nào và có thể chọn những phương thức hiện thực hóa nào. Với những nhà máy mấy năm mới cân nhắc thay mới hệ thống quản lý sản xuất một lần, thường thì bản thân tấm bản đồ các lựa chọn cũng chưa có, nên việc chèn thêm bước RFI rất đáng làm.

Sắp xếp quan hệ giữa ba tài liệu này thì được như sau.

Cũng trong bài giải thích đó, tác giả chỉ ra rằng việc trình cùng một nội dung RFP cho nhiều nhà cung cấp sẽ giúp việc so sánh các đề xuất diễn ra trôi chảy. Nghe thì như một điều hiển nhiên, nhưng trên thực tế của việc lấy báo giá song song, số trường hợp không giữ được cái “cùng một nội dung” này lại chiếm áp đảo. Gửi email tóm tắt cho công ty A, mời công ty B tới nhà máy rồi giải thích bằng miệng, còn công ty C thì đưa cho một tập tài liệu cũ do người tiền nhiệm soạn. Ngay tại thời điểm đó, 3 nhà cung cấp đang cố giải ba bài toán khác nhau.

Điều gì xảy ra khi lấy báo giá song song mà không có RFP – tiền đề do nhà cung cấp tự quyết

Nếu đề nghị báo giá song song mà không chuẩn bị RFP, nhà cung cấp sẽ tự bù đắp những thông tin còn thiếu để làm ra được con số. Không phải vì ác ý, mà vì không làm vậy thì không xuất ra được số tiền. Những hạng mục tiêu biểu được bù đắp ở đây là bốn thứ, gồm chuyển đổi dữ liệu, tùy chỉnh, đào tạo và số năm bảo trì.

Chuyển đổi dữ liệu là hạng mục khiến số tiền dịch chuyển rất mạnh tùy theo việc có đưa vào hay không. Dữ liệu chủ về mặt hàng, BOM, dữ liệu chủ về đối tác, dữ liệu thực tế trong quá khứ của hệ thống hiện hành sẽ được mang sang hệ thống mới tới đâu. Nếu phạm vi này không được nêu ra, sẽ có nhà cung cấp phán đoán rằng “chuyển đổi tính riêng”, và có nhà cung cấp khác phán đoán rằng “đương nhiên là bao gồm”. Cả hai đều không sai. Chỉ là căn cứ để phán đoán đã không được bên đặt hàng đưa ra.

Tùy chỉnh cũng vậy. Có xử lý BOM nhiều tầng hay không, có cần quản lý theo lô hay không, có phải kết nối với hệ thống kế toán hiện hành hay không. Nếu không được nêu ra, nhà cung cấp sẽ báo giá trong phạm vi chức năng tiêu chuẩn của chính họ. Mà phạm vi chức năng tiêu chuẩn thì khác nhau tùy sản phẩm, nên cùng một câu “nằm trong phạm vi tiêu chuẩn” lại mang nghĩa những số tiền hoàn toàn khác nhau.

Đào tạo và bảo trì cũng hay bị bỏ sót. Sau khi triển khai sẽ đào tạo cho người vận hành trong bao nhiêu ngày, hợp đồng bảo trì sẽ được tính bao nhiêu năm vào báo giá. Những khoản này có khi được ghi nhận là chi phí ban đầu, có khi lại được tách thành khung chi phí vận hành riêng.

Kết quả là một trạng thái không thể so sánh được số tiền. Nhà cung cấp rẻ có thể chỉ đơn giản là bao gồm phạm vi hẹp hơn, còn nhà cung cấp đắt có thể chỉ là đã báo giá một cách chỉn chu. Nếu ở trạng thái này mà quyết định chỉ dựa trên giá, thì tới sát ngày vận hành sẽ nghe câu “chi phí chuyển đổi dữ liệu không bao gồm trong báo giá”, và một khoản báo giá bổ sung sẽ phát sinh. Về bản thân các trục so sánh giữa các sản phẩm, chúng tôi đã sắp xếp trong bài so sánh hệ thống quản lý sản xuất 2026, nhưng dù trục so sánh có đồng nhất, nếu tiền đề của báo giá không đồng nhất thì vẫn không rút ra được kết luận.

Trường hợp mô hình – nâng cấp hệ thống quản lý sản xuất tại nhà máy Ayutthaya

Từ đây chúng ta sẽ xem xét bằng một trường hợp mô hình cụ thể. Nội dung dưới đây là trường hợp mô hình dựa trên tính toán riêng của chúng tôi, không phải số liệu của một doanh nghiệp có thật. Thay vì bản thân các con số, mời bạn nhìn vào cấu trúc, tức là khoảng chênh sinh ra ở đâu và cần thống nhất điều gì thì khoảng chênh mới thu hẹp lại.

Tiền đề như sau. Một nhà máy lắp ráp linh kiện ô tô của Nhật Bản tại tỉnh Ayutthaya, Thái Lan, với 300 nhân viên. Hệ thống quản lý sản xuất dạng cài đặt tại chỗ được đưa vào cách đây 10 năm đã cũ đi, thời hạn hỗ trợ cũng tới gần, nên nhà máy bắt đầu cân nhắc thay mới. Không có nhân sự chuyên trách CNTT, và trưởng phòng quản lý sản xuất kiêm nhiệm việc làm việc với nhà cung cấp cùng các công việc khác. Đây là một cấu hình cực kỳ phổ biến tại các nhà máy Nhật Bản ở Thái Lan.

Hành động đầu tiên mà nhà máy này thực hiện là liên hệ 3 nhà cung cấp, gồm bên vẫn có quan hệ làm ăn và bên đã trao đổi danh thiếp tại một triển lãm của doanh nghiệp Nhật Bản, để đề nghị báo giá. Tài liệu dùng cho lời đề nghị chỉ gồm phần giải thích bằng miệng khi mời các bên tới nhà máy, cùng một tập tài liệu tóm tắt 2 trang do nội bộ tự soạn. Trong tài liệu có sơ đồ màn hình của hệ thống hiện hành, và các khó khăn được liệt kê thành gạch đầu dòng, gồm việc nhập số liệu thực tế bị trùng hai lần, tồn kho không khớp, và việc tổng hợp cuối tháng mất nhiều thời gian.

Trong cách đề nghị này không có sự cẩu thả rõ ràng nào. Các khó khăn đã được chia sẻ, hiện trường cũng đã được cho xem. Thậm chí còn thuộc loại chỉn chu. Vậy mà, như chúng ta sẽ thấy ngay sau đây, những gì gửi về lại là 3 tờ báo giá không thể so sánh với nhau.

Đợt báo giá đầu tiên (không có RFP) – số tiền của 3 nhà cung cấp và tiền đề của từng bên

Số tiền báo giá mà 3 nhà cung cấp gửi về, cùng phạm vi được bao gồm trong từng báo giá, là như sau. Số tiền tính bằng THB.

Số tiền cao nhất là 3,450,000 của công ty C, gấp 3.0 lần số tiền thấp nhất là 1,150,000 của công ty A. Cùng một nhà máy, cùng những khó khăn như nhau, mà báo giá chênh nhau 3 lần.

Phản ứng đầu tiên của người phụ trách khi nhìn 3 tờ giấy này thường là “hay công ty A rẻ quá mức, hoặc công ty C đang thổi giá”. Nhưng nếu đọc ngang theo cột phạm vi được bao gồm, sẽ thấy không phải bên nào trong hai bên đó cả. Công ty A diễn giải nội dung được đề nghị theo cách hẹp nhất, chỉ báo giá cho việc đưa nguyên các chức năng hiện có lên nền tảng mới. Công ty C diễn giải rộng nhất, bao gồm cả chuyển đổi, đào tạo, bảo trì, và thêm cả phần hỗ trợ BOM nhiều tầng. Công ty B nằm ở giữa.

Nói cách khác, 3 nhà cung cấp đang báo giá cho ba công việc khác nhau. Trong lúc tưởng rằng mình đang so sánh giá, thực chất bên đặt hàng đang so sánh độ rộng của cách diễn giải.

Một điểm cần lưu ý ở đây là báo giá của công ty A không hề thiếu trung thực. Trên tờ báo giá của công ty A có ghi rõ dòng chữ “chuyển đổi dữ liệu, đào tạo, bảo trì báo giá riêng”. Nó được viết ra để ai đọc cũng hiểu. Chỉ có điều, con số ở cột số tiền lại được trình bày ở dạng có thể xếp cạnh các công ty khác, nên ngay khoảnh khắc bảng so sánh được lập ra, dòng ghi chú kia biến mất khỏi tầm nhìn. Bảng so sánh báo giá trong hầu hết trường hợp không có cột nào để diễn đạt sự khác biệt về phạm vi.

Bốn khác biệt về tiền đề đã tạo ra khoảng chênh báo giá

Khi phân rã báo giá của 3 nhà cung cấp, những tiền đề tạo ra khoảng chênh có thể sắp xếp thành bốn thứ. Các mức giá thị trường dưới đây là con số tham chiếu theo tính toán riêng của chúng tôi.

Việc lập ra bảng này thì bên đặt hàng cũng làm được. Chỉ cần xếp phần chi tiết của từng tờ báo giá cạnh nhau rồi đánh dấu vào những hạng mục có bao gồm. Tuy nhiên, khi thực sự bắt tay vào làm, người ta sẽ nhận ra rằng độ chi tiết trong phần bóc tách của các tờ báo giá không đồng đều. Có bên chỉ viết “trọn gói xây dựng hệ thống”, có bên lại chia theo từng công đoạn. Độ chi tiết đã khác nhau thì bản thân thao tác đánh dấu cũng không thực hiện được.

Điều quan trọng ở đây là ba trong bốn hạng mục này là những việc mà bên đặt hàng phải quyết. Chuyển đổi dữ liệu của bao nhiêu năm, có cần hỗ trợ BOM nhiều tầng hay không, ký bảo trì bao nhiêu năm. Đây không phải chuyện nhà cung cấp quyết, mà được quyết bởi yêu cầu nghiệp vụ và chủ trương ngân sách của phía nhà máy. Số ngày đào tạo cũng vậy, việc cần dạy cho bao nhiêu người vận hành và dạy tới chức năng nào là câu chuyện về cơ cấu nhân sự của nhà máy.

Nếu đề nghị báo giá mà không quyết những thứ đáng lẽ bên đặt hàng phải quyết, thì khoảng trống đó sẽ do nhà cung cấp lấp vào. Cách lấp lại phụ thuộc vào chiến lược kinh doanh của từng bên, nên không có lý gì để chúng đồng nhất. Con số chênh 3 lần không phải khoảng cách về năng lực giữa các nhà cung cấp, mà là biên độ diễn giải phát sinh đúng bằng số lượng tiền đề mà bên đặt hàng đã không nêu ra.

Nhân đây, ở giai đoạn này người ta rất dễ muốn nghĩ rằng “cộng thêm mức giá thị trường của các hạng mục còn thiếu vào số tiền của công ty A thì sẽ ra giá thực chất”, nhưng chúng tôi không khuyến nghị làm vậy. Mức thị trường chỉ là con số tham chiếu, còn thực tế khi công ty A nhận phạm vi đó thì con số sẽ là bao nhiêu, chỉ có hỏi công ty A mới biết. Hãy dừng lại ở mức nhận diện khác biệt tiền đề như một khác biệt, còn con số chính xác thì đi lấy bằng đợt báo giá lại. Đó mới là cách làm thực tế.

Lập RFP và sắp xếp yêu cầu theo Must/Want/Better

Hành động tiếp theo của nhà máy này là lập RFP. Đích đến không phải là làm ra một tài liệu hoành tráng, mà là tạo ra trạng thái để 3 nhà cung cấp báo giá cho cùng một phạm vi.

Trung tâm của công việc là việc xếp thứ tự ưu tiên cho các yêu cầu. GeNEE, đơn vị cung cấp hướng dẫn lập RFP, giới thiệu phương pháp xếp thứ tự ưu tiên cho các yêu cầu theo ba bậc là Must (bắt buộc), Want (mong muốn) và Better (có thì tốt). Hiệu quả của ba bậc này không đơn thuần là làm cho mọi thứ trông gọn gàng dễ nhìn. Nó nằm ở chỗ phía nhà cung cấp có thể tự phán đoán được rằng nên đưa tới đâu vào báo giá.

Trên thực tế, trong trường hợp của nhà máy này, phần hỗ trợ BOM nhiều tầng, thứ tạo ra khoảng chênh lớn nhất ở đợt báo giá đầu tiên, đã được đặt vào Must. Lý do là sau khi kiểm tra hiện trường, nhà máy xác nhận rằng thực tế đang sản xuất những sản phẩm có cụm lắp ráp con, và phán đoán rằng hệ thống nào không đáp ứng được điều này thì bị loại khỏi danh sách lựa chọn. Chuyển đổi dữ liệu cũng là Must, đào tạo 3 ngày là Must, bảo trì 1 năm là Must.

Mặt khác, cũng có những thứ được đặt vào Want. Nhập số liệu thực tế từ điện thoại thông minh, bảng điều khiển dành cho ban lãnh đạo, khả năng hỗ trợ nhiều cơ sở để tính tới việc nhân rộng sang các nhà máy khác. Tất cả đều là những chức năng có thì mừng, nhưng không có thì bài toán lần này vẫn được giải. Việc đặt vào Want giúp nhà cung cấp có thể trình bày tách bạch giữa “có đáp ứng được hay không” và “chi phí bổ sung nếu đáp ứng”.

Vào Better thì đặt những hạng mục như việc tự động thu thập dữ liệu thiết bị trong tương lai, hay dự báo nhu cầu bằng AI. Vị trí của chúng là không cần đưa vào báo giá lần này, nhưng bên đặt hàng muốn biết sản phẩm có mang định hướng đó hay không.

Khi giữ được ba bậc này, hình dạng của bản đề xuất từ nhà cung cấp sẽ thay đổi. Không đáp ứng được Must thì rút lui, Want thì trình bày ở khung riêng, Better thì trả lời bằng lộ trình sản phẩm. Vì quy tắc phán đoán đã được chia sẻ nên độ chi tiết của các đề xuất trở nên đồng đều.

Kết quả báo giá lại – khoảng chênh từ 3.0 lần xuống 12.8%

Sau khi trình RFP và thống nhất phạm vi gồm chuyển đổi dữ liệu, hỗ trợ BOM nhiều tầng (Must), đào tạo 3 ngày (Must) và bảo trì 1 năm (Must), nhà máy đề nghị chính 3 nhà cung cấp đó báo giá lại. Kết quả như sau.

Khoảng chênh giữa số tiền cao nhất là 2,460,000 của công ty C và số tiền thấp nhất là 2,180,000 của công ty A là 280,000 THB. Tỷ lệ chênh so với mức thấp nhất là 12.8%. Từ mức 3.0 lần của đợt đầu, nó đã thu hẹp về phạm vi có thể so sánh được.

Có hai điểm cần lưu ý khi đọc kết quả này.

Một là không hề rẻ đi. Số tiền của công ty A đã tăng từ 1,150,000 của đợt đầu lên 2,180,000. Đây không phải tăng giá, mà là kết quả của việc bổ sung phần phạm vi vốn không có trong đợt đầu. Hiệu quả của RFP không nằm ở việc kéo giá xuống, mà ở việc làm cho số tiền thực sự cần thiết trở nên nhìn thấy được. Nếu đã đặt hàng luôn theo số tiền đợt đầu của công ty A, thì ở đâu đó trên đường tới lúc vận hành, một khoản báo giá bổ sung sẽ phát sinh, và tổng số tiền phải trả cuối cùng sẽ hiện ra dưới dạng vượt ngân sách.

Hai là chính khoảng chênh 12.8% mới có ý nghĩa. Phần chênh còn lại sau khi đã báo giá cho cùng một phạm vi phản ánh khác biệt thực sự về năng lực và điều kiện, gồm khác biệt về phương thức triển khai, khác biệt về mô hình bản quyền của gói phần mềm, khác biệt về đơn giá kỹ sư tại Thái Lan. Tới giai đoạn này thì giá mới bắt đầu dùng được như một căn cứ phán đoán. Khoảng chênh 3.0 lần không phải căn cứ để so sánh, nhưng khoảng chênh 12.8% là khoảng chênh có thể đặt lên bàn cân cùng với bộ máy hỗ trợ và thành tích thực tế.

Và trên thực hành, chúng tôi khuyến nghị đừng quyết biên độ 12.8% này chỉ bằng giá. Bởi vì khoảng chênh 280,000 THB, so với khác biệt về chất lượng ứng phó phát sinh trong suốt quá trình vận hành dài hạn, hoàn toàn không phải là lớn.

Công sức và tiến độ để lập RFP

“Đã hiểu là lập RFP thì mọi thứ sẽ đồng nhất, nhưng nó mất bao lâu” là cửa ải tiếp theo. Thời gian thực tế đã bỏ ra trong trường hợp mô hình này được ước lượng như sau.

GeNEE sắp xếp việc lập RFP thành 5 bước, và đưa ra mốc tham chiếu rằng bản thân việc soạn nội dung RFP (từ phân tích hiện trạng tới khi hoàn thành tài liệu) mất từ 1 tới 1.5 tháng, còn toàn bộ quá trình tính cả việc trình cho nhà cung cấp và nhận về bản đề xuất thì khoảng 1.5 tới 2.5 tháng. Con số 7 tuần của trường hợp mô hình này nằm gọn trong khoảng tham chiếu của toàn bộ quá trình, tính tới cả phần trình nhà cung cấp và xử lý hỏi đáp. Có thể coi đây là một tiến độ tiêu chuẩn, không đặc biệt nhanh cũng không đặc biệt chậm.

Nhìn vào nội dung từng công đoạn sẽ thấy chỗ tốn thời gian nhất là “rà soát các vấn đề hiện tại” ở ngay đầu. Việc được thực hiện ở đây là đi nghe những khó khăn với hệ thống hiện hành từ người phụ trách của không chỉ phòng quản lý sản xuất mà cả mua hàng, đảm bảo chất lượng, sản xuất và kế toán. Vì người phụ trách kiêm nhiệm phải tranh thủ giữa các công việc khác, nên phần lớn khoảng thời gian 2 tuần đó là thời gian chờ.

Ngược lại, phần “soạn tài liệu”, tức việc viết thực sự, chỉ mất 1.5 tuần. Nếu chất liệu để viết đã đủ thì bản thân việc văn bản hóa không phải công việc quá nặng. Nguyên nhân khiến người ta cảm thấy không viết nổi RFP, phần lớn không nằm ở khả năng viết, mà nằm ở chỗ chất liệu chưa được gom đủ.

Hai tuần cuối cho “trình nhà cung cấp và xử lý hỏi đáp” cũng không thể lược bỏ. Sau khi giao RFP, nhà cung cấp chắc chắn sẽ gửi câu hỏi. Việc chia sẻ cùng một nội dung trả lời cho tất cả các bên chính là công đoạn hoàn thiện cuối cùng để thống nhất phạm vi. Nếu chỉ truyền thông tin bổ sung cho một bên, thì ngay tại đó tiền đề lại lệch đi.

Cảm nhận 7 tuần là dài hay ngắn còn tùy vị trí của từng người, nhưng nếu tính tới thời gian dành cho việc điều chỉnh các khoản báo giá bổ sung và việc sửa chữa những hiểu lầm sau khi vận hành, vốn sẽ phát sinh khi tiến hành mà không có nền tảng so sánh, thì cách nhìn thực tế là coi đây là khoảng thời gian được trả trước.

Ba phần cần có trong một RFP

Về cách dựng nội dung RFP, GeNEE đưa ra cấu trúc ba phần, gồm tổng quan, nội dung đề nghị đề xuất, và cách thức tiến hành lựa chọn. Khung này dùng được nguyên vẹn cho các dự án hệ thống quản lý sản xuất.

Phần thứ nhất là tổng quan. Viết về việc công ty mình đang làm gì, và vì sao lần này lại thay mới hệ thống. Vị trí nhà máy, sản phẩm sản xuất, số nhân viên, phương thức sản xuất (đặt hàng riêng hay sản xuất theo dự báo, sản xuất theo lô hay theo dây chuyền), và cấu hình cùng vấn đề của hệ thống hiện hành. Nếu phần này mỏng, nhà cung cấp sẽ phải tưởng tượng ra thực trạng của nhà máy. Với các dự án tại cơ sở Thái Lan, nếu viết luôn cả quan hệ với trụ sở chính tại Nhật Bản, việc có kết nối với hệ thống kế toán hay không, và khả năng sử dụng tiếng Nhật của nhân viên bản địa, thì độ chính xác của đề xuất sẽ tăng lên.

Phần thứ hai là nội dung đề nghị đề xuất. Đây là phần thân của RFP, viết về yêu cầu chức năng, yêu cầu phi chức năng, cơ cấu nhân sự, tiến độ, và cách nghĩ về ngân sách. Việc sắp xếp Must/Want/Better phát huy tác dụng ở đây. Ngoài ra, việc nêu rõ phạm vi muốn được bao gồm trong báo giá là điều mang tính quyết định. Đối tượng và khoảng thời gian của chuyển đổi dữ liệu, số ngày và số người của đào tạo, số năm của hợp đồng bảo trì. Chỉ cần viết ba điểm này, phần lớn khoảng chênh đã xảy ra ở đợt báo giá đầu tiên sẽ biến mất.

Phần thứ ba là cách thức tiến hành lựa chọn. Hạn nộp đề xuất là khi nào, thuyết trình vào lúc nào, thông báo kết quả khi nào. Và đánh giá dựa trên tiêu chí gì. Có người thấy ngại khi phải công khai tiêu chí đánh giá từ trước, nhưng công khai thì chất lượng đề xuất sẽ cao hơn. Vì nhà cung cấp làm đề xuất trong thời gian hạn chế, nên khi biết cần dồn sức vào đâu thì họ có thể tập trung nguồn lực vào đó.

Trong ba phần này, phần dễ thiếu nhất trong RFP của các nhà máy Nhật Bản là phần thứ ba. Chuyện chức năng thì viết được, còn chuyện chọn thế nào thì bị bỏ trống, để rồi sau khi nhận đề xuất mới bắt đầu lập bảng đánh giá. Với thứ tự này, tiêu chí đánh giá sẽ bị kéo theo những bản đề xuất đang có trong tay.

Sắp xếp yêu cầu chức năng theo Must/Want/Better

Việc sắp xếp Must/Want/Better xét về khái niệm thì đơn giản, nhưng khi làm thật thì chắc chắn sẽ tắc. Nguyên nhân của việc tắc là ai ở hiện trường cũng coi nguyện vọng của mình là Must.

Thứ hữu hiệu để vượt qua bức tường này là quyết trước một câu hỏi phán định. Trong thực hành, chúng tôi phán định bằng đúng một điểm là “nếu không có chức năng này thì nghiệp vụ có chạy được không”. Không chạy được thì là Must, chạy được nhưng tốn thêm công thì là Want, có thì tương lai sẽ hữu ích thì là Better. Vì việc có chạy được hay không là vấn đề của sự thật, nên các bộ phận ở vị trí khác nhau cũng dễ đồng thuận hơn.

Sắp xếp theo trường hợp nhà máy Ayutthaya thì được phân loại như sau.

Một mẹo nữa là đừng để Must nhiều quá. Nếu đưa hết mọi thứ vào Must thì hoặc là chỉ còn đúng một nhà cung cấp đáp ứng được, hoặc là tất cả các bên đều chất thêm những khoản tùy chỉnh đắt đỏ. Must là điều kiện mang nghĩa “bỏ cái này ra thì không đặt hàng”, nên chỉ đặt vào đó những hạng mục thực sự chi phối quyết định đặt hàng.

Ngược lại, việc viết Want thật kỹ lại có giá trị rất lớn. Nếu Want được thỏa mãn bằng chức năng tiêu chuẩn của nhà cung cấp thì có thể hiện thực hóa mà không tốn thêm chi phí. Nếu không viết Want ra, sẽ có những chức năng vốn đã nằm sẵn trong gói tiêu chuẩn nhưng cuối cùng không được dùng tới. Chính những nguyện vọng có khả năng đạt được với giá rẻ mới là thứ đáng viết ra.

Và bảng sắp xếp này còn được dùng tiếp cả sau khi đã phát hành RFP. Bởi khi đánh giá các đề xuất, ta có thể xếp việc từng bên đáp ứng Must ra sao và xử lý Want thế nào lên cùng một trục. Bản thân bảng sắp xếp chính là bộ khung của bảng đánh giá về sau.

Yêu cầu phi chức năng phải viết bằng con số – tính từ không so sánh được

So với việc sắp xếp yêu cầu chức năng, yêu cầu phi chức năng thường bị làm sơ sài hơn hẳn. Và phần lớn sự cố sau khi vận hành lại sinh ra từ sự mơ hồ của chính những yêu cầu phi chức năng này.

GeNEE cũng chỉ ra rằng yêu cầu phi chức năng cần được viết cụ thể bằng con số và tiêu chuẩn. Lý do rất rõ ràng, vì tính từ thì không so sánh được. Với một RFP viết rằng “phản hồi phải nhanh”, nhà cung cấp A có thể hình dung 1 giây, còn nhà cung cấp B có thể hình dung 5 giây. Theo tiêu chuẩn của chính họ thì cả hai đều là “nhanh”.

Những yêu cầu phi chức năng cần định lượng trong hệ thống quản lý sản xuất đại khái thuộc các lĩnh vực sau.

Về hiệu năng, đó là số người dùng kết nối đồng thời, số lượng giao dịch cần xử lý vào giờ cao điểm, thời gian phản hồi của màn hình, và thời gian có thể chấp nhận được cho tới khi hoàn tất xử lý chốt sổ hằng tháng. Cách chắc chắn nhất là viết dựa trên số đo thực tế của hệ thống hiện hành. Nếu khó đo được, hãy đi hỏi hiện trường xem chờ quá bao lâu thì công việc bị dừng lại, rồi lấy đó làm mốc.

Về khả dụng, đó là khung giờ vận hành (nhà máy ở Thái Lan nhiều nơi chạy 2 ca hoặc 3 ca, nên đừng bê nguyên tiêu chuẩn của Nhật Bản sang), tần suất dừng theo kế hoạch có thể chấp nhận, và mục tiêu thời gian khôi phục khi có sự cố. Về bảo toàn dữ liệu, đó là tần suất sao lưu và thời gian lưu trữ, cùng việc khi sự cố xảy ra thì khôi phục được về tới mốc nào.

Và thứ hay bị thiếu là điều kiện phản hồi của bảo trì. Thời gian từ khi nhận thông báo sự cố tới lúc có phản hồi đầu tiên, khung giờ tiếp nhận, và ngôn ngữ hỗ trợ. Tại cơ sở Thái Lan, việc chỉ định ngôn ngữ hỗ trợ có ý nghĩa cực kỳ quan trọng trong thực hành. Việc có tổ chức được mô hình hỗ trợ mà nhân viên bản địa liên hệ bằng tiếng Thái, còn quản lý người Nhật xác nhận tình hình bằng tiếng Nhật hay không sẽ làm thay đổi gánh nặng vận hành sau khi hệ thống chạy.

Cũng cần lưu ý rằng viết yêu cầu phi chức năng càng khắt khe thì số tiền càng tăng. Nếu đòi vận hành liên tục và phản hồi tức thì thì chi phí cho bộ máy đó sẽ được cộng vào. Mục đích của việc viết bằng con số không phải để nâng yêu cầu lên cao, mà để nêu rõ mức cần thiết và đưa tất cả các bên lên cùng một sàn đấu. Nếu muốn xác nhận bản thân cấu trúc chi phí phát triển, bài chi phí phát triển hệ thống nghiệp vụ và kết nối ERP cũng là tài liệu tham khảo hữu ích.

Những điểm riêng của cơ sở tại Thái Lan và ASEAN

Có những điểm không xuất hiện trong các bài hướng dẫn RFP tại Nhật Bản, nhưng lại rất riêng của cơ sở Thái Lan. Chúng tôi nêu ra những điểm phát huy tác dụng trong thực hành.

Tình trạng chuẩn hóa dữ liệu hiện có. newsclip.be chỉ ra rằng khi triển khai hệ thống quản lý sản xuất tại Thái Lan, có rất nhiều trường hợp hệ thống mã của thông tin khách hàng, thông tin sản phẩm và thông tin nguyên vật liệu, vốn được từng bộ phận tự quản lý riêng bằng Excel và các công cụ tương tự, lại khác nhau giữa các bộ phận. Đây là điểm nhất định phải xác nhận ở giai đoạn “rà soát các vấn đề hiện tại” của RFP. Nếu viết RFP mà không nắm được tình trạng hệ thống mã chưa đồng nhất giữa các bộ phận, thì phạm vi chuyển đổi dữ liệu sẽ bị đánh giá thấp hơn thực tế. Việc trường hợp mô hình xử lý chi phí chuyển đổi dữ liệu như một hạng mục độc lập cũng vì khác biệt tiền đề này gắn thẳng vào giá.

Phạm vi ngôn ngữ và tài liệu. Hãy chỉ định riêng từng thứ, gồm ngôn ngữ hiển thị trên màn hình, ngôn ngữ của tài liệu hướng dẫn, và ngôn ngữ của buổi đào tạo. Cần kết hợp cho khớp với thực tế, chẳng hạn màn hình là tiếng Thái và tiếng Anh, tài liệu là tiếng Nhật và tiếng Anh, còn đào tạo là tiếng Thái. Nếu gộp lại thành một câu “hỗ trợ đa ngôn ngữ” thì phạm vi được bao gồm sẽ khác nhau tùy nhà cung cấp.

Yêu cầu kết nối với trụ sở chính. Việc có cần kết nối với hệ thống kế toán của trụ sở chính tại Nhật Bản hay với ERP chuẩn của tập đoàn hay không là điều cần chốt ngay từ giai đoạn đầu. Nếu yêu cầu kết nối được bổ sung về sau, có nguy cơ phải làm lại từ chính khâu chọn gói phần mềm.

Vị trí của cơ sở hỗ trợ. Có kỹ sư ở trong Thái Lan hay sẽ hỗ trợ từ xa từ Singapore hoặc Nhật Bản. Khi cần hỗ trợ tại chỗ thì chi phí công tác có nằm trong báo giá hay không. Nếu không hỏi rõ ngay trong RFP, những điều này sẽ chỉ lộ ra sau khi hệ thống đã chạy. Về cách nhìn nhận bản thân bộ máy của nhà cung cấp, mời bạn tham khảo thêm bài cách chọn công ty phát triển hệ thống tại Thái Lan.

Yêu cầu về thuế và pháp lý. Việc có xuất được các biểu mẫu đáp ứng chế độ kế toán và yêu cầu thuế của Thái Lan hay không, có bắt kịp được xu hướng hóa đơn điện tử hay không cũng là lĩnh vực cần viết vào như yêu cầu chức năng. Nếu mang nguyên một gói phần mềm được làm theo tiêu chuẩn Nhật Bản sang, phần này thường trở thành hạng mục phát triển bổ sung phát sinh về sau.

Ngoài RFP, còn phải nhìn gì khi so sánh báo giá

Sau khi RFP đã giúp so sánh được số tiền, thì phán đoán cuối cùng dựa vào cái gì. Nếu ở đây lại quay về chỉ nhìn giá thì ý nghĩa của việc lập RFP mất đi một nửa.

ASPIC nêu ba điểm khi so sánh các hệ thống quản lý sản xuất, gồm phạm vi nghiệp vụ được hỗ trợ, việc có hỗ trợ doanh nghiệp quy mô nhỏ hay không, và mức độ đầy đủ của chức năng lập lịch sản xuất. Phạm vi nghiệp vụ được hỗ trợ thì chính các yêu cầu Must trong RFP đã trở thành trục so sánh, còn việc hỗ trợ doanh nghiệp quy mô nhỏ và sự cần thiết của chức năng lập lịch cũng là những điểm mà trọng số thay đổi tùy quy mô và phương thức vận hành của từng công ty. Ngoài ra, trong thực hành lấy báo giá song song, ba điểm sau cũng là căn cứ phán đoán ngang hàng với giá.

Khả năng mở rộng thì cách thực tế là nhìn vào câu trả lời của nhà cung cấp đối với phần Want và Better. Với những chức năng không đưa vào báo giá lần này, có bổ sung được không, và nếu bổ sung thì sẽ theo hình thức nào. Chỉ cần đổi thiết lập trong chức năng tiêu chuẩn là xong, hay phải phát triển thêm. Tư tưởng thiết kế của sản phẩm bộc lộ trong cách trả lời này.

Hỗ trợ khách hàng thì hãy xác nhận bằng những câu hỏi cụ thể về vận hành, chứ không bằng phần giải thích về bộ máy. Khi người phụ trách thay đổi thì việc bàn giao ra sao, đầu mối tiếp nhận là một cá nhân hay một nhóm, đã từng hỗ trợ nhà máy cùng quy mô nào chưa. Ở Thái Lan việc kỹ sư chuyển việc là chuyện phổ biến, nên cần nhìn mô hình phụ thuộc vào cá nhân như một rủi ro.

Chi phí thì hãy so sánh tổng số tiền trong nhiều năm chứ không chỉ chi phí ban đầu. Bản quyền là mua đứt hay tính theo năm, chi phí dịch chuyển ra sao khi số người dùng tăng giảm, phí bảo trì từ năm thứ mấy sẽ là bao nhiêu. Chuyện bản đề xuất có chi phí ban đầu rẻ nhất lại trở thành đắt nhất về dài hạn không hề hiếm.

Và còn một góc nhìn nữa chỉ có được sau khi đã phát hành RFP. Đó là chất lượng của phần hỏi đáp. Nhà cung cấp đọc kỹ RFP rồi đặt những câu hỏi trúng đích là bên đang cố gắng hiểu dự án. Nhà cung cấp không gửi câu hỏi nào thì hoặc là chưa đọc, hoặc là đang vận hành trên tiền đề sẽ nộp nguyên bản đề xuất tiêu chuẩn của họ. Bản thân nội dung câu hỏi cũng là căn cứ để đánh giá.

Năm kiểu thất bại thường gặp khi lập RFP

Trong thực hành lập RFP, những kiểu thất bại sau đây rất hay gặp. Chúng tôi sắp xếp lại theo bối cảnh dự án hệ thống quản lý sản xuất.

Bắt đầu viết khi mục đích vẫn còn mơ hồ. “Vì hệ thống đã cũ” không phải mục đích, mà là nguyên nhân khởi phát. Muốn giảm chênh lệch tồn kho, muốn rút ngắn thời gian chốt sổ tháng, hay muốn xóa bỏ việc nhập số liệu thực tế hai lần. Nếu mục đích chưa được xác định, ta sẽ không có tiêu chí phán định Must/Want/Better, và yêu cầu sẽ trở thành một danh sách liệt kê nguyện vọng của hiện trường.

Nhồi nhét quá nhiều yêu cầu. Nếu đưa hết mọi nguyện vọng thu thập từ các bộ phận vào mục Must, thì hoặc là không còn nhà cung cấp nào đáp ứng nổi, hoặc là số tiền báo giá nhảy vọt. RFP không phải kho chứa nguyện vọng, mà là tài liệu thể hiện thứ tự ưu tiên. Việc của RFP bao gồm cả phán đoán loại bỏ.

Dùng cách diễn đạt mơ hồ. “Màn hình dễ dùng”, “vận hành ổn định”, “khả năng mở rộng linh hoạt”. Tất cả đều là những từ mà mỗi bên có thể diễn giải theo hướng có lợi cho mình. Như đã nói ở trên, yêu cầu phi chức năng phải viết bằng con số và tiêu chuẩn. Yêu cầu chức năng cũng vậy, hãy hạ xuống độ chi tiết kiểu “ghi nhận xuất nhập theo đơn vị lô và tra cứu được tồn kho tại thời điểm chỉ định”, chứ không dừng ở “quản lý được tồn kho”.

Không nêu ngân sách và thời hạn. Người ta dễ nghĩ rằng giấu ngân sách đi thì sẽ moi được điều kiện tốt hơn, nhưng thực tế lại ngược lại. Không biết mức ngân sách thì nhà cung cấp chỉ còn cách đưa ra bản đề xuất tiêu chuẩn của mình, và sẽ không có những sáng kiến điều chỉnh cấu hình cho vừa ngân sách. Trình bày theo khoảng cũng được, nhưng có nêu ra thì tính thực dụng của đề xuất sẽ cao hơn.

Phát hành mà chưa có đồng thuận nội bộ. Đây là trường hợp RFP được viết chỉ bởi người phụ trách hệ thống thông tin rồi gửi cho nhà cung cấp mà chưa qua rà soát của hiện trường và ban lãnh đạo. Khi đề xuất gửi về mà nhận được nhận xét kiểu “chức năng đó công đoạn của chúng tôi không dùng được”, thì việc lựa chọn phải làm lại từ đầu. Việc trường hợp mô hình dành 1.5 tuần cho “soạn tài liệu và rà soát nội bộ” chính là để không bỏ qua công đoạn này.

Ranh giới giữa phần tự làm trong nội bộ và phần giao ra bên ngoài

Số nhà máy tự viết được toàn bộ RFP không nhiều. Nhưng nếu giao hết ra ngoài thì yêu cầu sẽ trở thành chuyện của người khác, và sau khi vận hành sẽ phát sinh câu “khác với những gì tôi được nghe”. Cần có một đường ranh giới.

Cách phân chia đang vận hành hiệu quả trên thực tế là mục đích và thứ tự ưu tiên thì giữ trong nội bộ, còn việc văn bản hóa và kiểm chứng tính hợp lý về mặt kỹ thuật thì giao ra bên ngoài.

Những thứ nên giữ trong nội bộ. Trước hết là mục đích, tức lần thay mới hệ thống này sẽ giải quyết điều gì. Đây là phán đoán của ban lãnh đạo và hiện trường, bên ngoài không quyết thay được. Tiếp theo là việc xếp thứ tự ưu tiên Must/Want/Better. Kiến thức nghiệp vụ làm căn cứ cho việc phán định chỉ có ở trong nội bộ. Thứ ba là khung ngân sách và quy trình phê duyệt. Việc tới khi nào cần ai duyệt chính là chuyện nội bộ của công ty.

Những thứ có thể giao ra bên ngoài. Một là công việc đưa các yêu cầu đã thu thập vào hình dạng tài liệu. Việc sắp xếp theo cấu trúc RFP rồi chỉ ra những hạng mục còn thiếu sẽ càng nhanh khi càng có kinh nghiệm nhìn nhiều dự án. Hai là việc đặt con số cho yêu cầu phi chức năng. Đặt thời gian phản hồi hay yêu cầu sao lưu ở mức nào là thực tế thì không có cảm nhận về mặt bằng thị trường sẽ không quyết được. Ba là hỗ trợ trả lời các câu hỏi từ nhà cung cấp. Trả lời sai một câu hỏi kỹ thuật thì báo giá về sau sẽ lệch.

Có hai điều kiện để đường ranh giới này vận hành được. Một là dù có giao ra bên ngoài thì phía nội bộ vẫn phải giữ được trạng thái đọc và hiểu được nội dung. Nếu chọn nhà cung cấp bằng một tài liệu mà mình không đọc nổi, thì các phán đoán sau khi vận hành cũng sẽ phụ thuộc vào bên ngoài. Hai là tách bạch giữa công ty hỗ trợ lập RFP và các nhà cung cấp tham gia dự thầu. Nếu cùng một công ty đảm nhận cả hai vai, RFP dễ mang hình dạng có lợi cho chính công ty đó, và ý nghĩa của việc lấy báo giá song song sẽ nhạt đi.

Nhân đây, ngay cả khi không đủ sức viết RFP từ đầu, lần đầu tiên hãy cứ bắt đầu từ một hình thức đơn giản. Gói gọn ba điểm gồm mục đích, yêu cầu Must, và phạm vi muốn được bao gồm trong báo giá vào một trang giấy, rồi đưa cùng một bản đó cho tất cả các nhà cung cấp. Chỉ vậy thôi cũng đã giảm mạnh sự phân tán về tiền đề. Thay vì nhắm tới một bản RFP hoàn hảo rồi chậm khởi động, việc phát hành sớm một trang giấy giúp thống nhất phạm vi mang lại lợi ích thực tế hơn.

Câu hỏi thường gặp

RFP cho hệ thống quản lý sản xuất cần khoảng bao nhiêu trang

Không có đáp án cố định cho số trang. Điều quan trọng không phải độ dài, mà là tài liệu có chứa đủ thông tin để tất cả các nhà cung cấp báo giá cho cùng một phạm vi hay không. Ở mức tối thiểu, nếu có tổng quan công ty và nhà máy, mục đích của việc thay mới hệ thống, các yêu cầu Must, phạm vi muốn được bao gồm trong báo giá (đối tượng chuyển đổi dữ liệu, số ngày đào tạo, số năm bảo trì), cùng tiến độ và tiêu chí đánh giá của việc lựa chọn, thì tài liệu đã vận hành được. GeNEE sắp xếp RFP thành ba phần gồm tổng quan, nội dung đề nghị đề xuất và cách thức tiến hành lựa chọn, nên nếu viết theo bộ khung này thì các hạng mục cần thiết sẽ được bao phủ. Thay vì tăng độ dài, hãy dùng thời gian để thay các cách diễn đạt mơ hồ bằng con số.

RFP và tài liệu định nghĩa yêu cầu khác nhau ở chỗ nào

Khác nhau ở thời điểm sử dụng và bên lập. Theo bài giải thích của Computer Management, RFP là tài liệu do bên đặt hàng lập trước khi lựa chọn nhà cung cấp và trình cho nhiều bên, còn tài liệu định nghĩa yêu cầu là thứ bên đặt hàng và nhà cung cấp cùng xây dựng sau khi đã chốt nhà cung cấp. Sẽ dễ sắp xếp hơn nếu coi RFP là tài liệu để so sánh, còn tài liệu định nghĩa yêu cầu là tài liệu để triển khai. Ở giai đoạn RFP không cần chốt đặc tả tới mức triển khai. Ngược lại, nếu chốt quá chặt thì sẽ không khai thác được những hiểu biết về phương thức hiện thực hóa mà nhà cung cấp đang nắm giữ.

Khi báo giá song song chênh lệch quá lớn thì phán đoán thế nào

Trước khi so sánh số tiền, hãy xếp phạm vi được bao gồm trong báo giá của từng bên lên cùng một bảng. Trong trường hợp mô hình, số tiền báo giá của 3 nhà cung cấp trải từ 1,150,000 tới 3,450,000, chênh nhau 3.0 lần, nhưng thứ tạo ra khoảng chênh là bốn khác biệt về tiền đề, gồm chuyển đổi dữ liệu, hỗ trợ BOM nhiều tầng, số ngày đào tạo và số năm bảo trì. Những báo giá không đồng nhất về phạm vi thì không thành một cuộc so sánh giá. Sau khi thống nhất tiền đề và đề nghị báo giá lại, khoảng chênh thu hẹp còn 12.8%, và tới lúc đó giá mới trở thành căn cứ phán đoán. Thứ tự đúng là xác nhận xem cái gì không được bao gồm, chứ không phải nghi ngờ bản đề xuất rẻ.

Lập RFP thì mất khoảng bao lâu

GeNEE đưa ra mốc tham chiếu về thời gian lập RFP, rằng bản thân việc soạn tài liệu mất từ 1 tới 1.5 tháng, còn toàn bộ quá trình tính cả việc trình nhà cung cấp và nhận về bản đề xuất thì khoảng 1.5 tới 2.5 tháng. Trong trường hợp mô hình, việc rà soát các vấn đề hiện tại mất 2 tuần, xếp thứ tự ưu tiên cho yêu cầu mất 1.5 tuần, soạn tài liệu và rà soát nội bộ mất 1.5 tuần, trình nhà cung cấp và xử lý hỏi đáp mất 2 tuần, tổng cộng 7 tuần. Chỗ tốn thời gian nhất là việc rà soát vấn đề ở ngay đầu, vì người phụ trách kiêm nhiệm phải tranh thủ giữa các công việc khác để đi nghe từng bộ phận, nên thời gian chờ dài hơn thời gian làm thật. Ngược lại, bản thân việc văn bản hóa sẽ không mất nhiều thời gian nếu chất liệu đã đủ.

Nên quyết tiêu chí phân chia Must/Want/Better như thế nào

Cách thực tế là phán định bằng đúng một điểm, “nếu không có chức năng này thì nghiệp vụ có chạy được không”. Không chạy được thì là Must, chạy được nhưng tốn thêm công thì là Want, có thì tương lai sẽ hữu ích thì là Better. Vì việc có chạy được hay không là vấn đề của sự thật, nên các bộ phận ở vị trí khác nhau cũng dễ đồng thuận. Một điểm cần lưu ý là đừng để Must nhiều quá. Must là điều kiện mang nghĩa “bỏ cái này ra thì không đặt hàng”, nên hãy thu hẹp về đúng những hạng mục chi phối quyết định đặt hàng. Mặt khác, Want thì đáng được viết kỹ, vì nếu được thỏa mãn bằng chức năng tiêu chuẩn của nhà cung cấp thì hiện thực hóa được mà không tốn thêm chi phí.

Tổng kết

Chúng tôi sắp xếp lại các điểm chính.

Việc giá chênh lệch lớn khi lấy báo giá song song cho hệ thống quản lý sản xuất không đến từ khác biệt về chức năng hay chất lượng. Nó đến từ việc mỗi nhà cung cấp diễn giải phạm vi tiền đề một khác. Nếu đề nghị báo giá chỉ bằng phần giải thích miệng và một tập tài liệu tóm tắt, thì cách bao gồm chuyển đổi dữ liệu, tùy chỉnh, đào tạo và số năm bảo trì sẽ phân tán giữa các bên, và những tờ báo giá không thể so sánh sẽ nằm cạnh nhau.

Trong tính toán của trường hợp mô hình, nhà máy lắp ráp linh kiện ô tô của Nhật Bản tại tỉnh Ayutthaya (300 nhân viên) đề nghị 3 nhà cung cấp báo giá, và số tiền đợt đầu là công ty A 1,150,000 THB, công ty B 2,300,000 THB, công ty C 3,450,000 THB, với mức cao nhất gấp 3.0 lần mức thấp nhất. Thứ tạo ra khoảng chênh là bốn khác biệt về tiền đề, gồm chi phí chuyển đổi dữ liệu 400,000, hỗ trợ BOM nhiều tầng 550,000, khác biệt về số ngày đào tạo với mức 60,000 cho mỗi ngày (công ty A 0 ngày, công ty B 2 ngày, công ty C 5 ngày), và việc gia hạn hợp đồng bảo trì thêm 1 năm 300,000. Sau khi lập RFP và thống nhất phạm vi gồm chuyển đổi dữ liệu, hỗ trợ BOM nhiều tầng, đào tạo 3 ngày và bảo trì 1 năm rồi đề nghị báo giá lại, số tiền mới là công ty A 2,180,000, công ty B 2,340,000, công ty C 2,460,000, và khoảng chênh giữa mức cao nhất với mức thấp nhất thu hẹp còn 280,000 THB, tương đương tỷ lệ 12.8%. Đây là tính toán riêng của chúng tôi chứ không phải số liệu của doanh nghiệp có thật, nên mời bạn nhìn vào cấu trúc, tức cần thống nhất điều gì thì khoảng chênh mới thu hẹp, thay vì nhìn vào bản thân các con số.

Điều không được đọc sai là RFP không phải công cụ để kéo giá xuống. Số tiền của công ty A đã tăng lên. Thứ mà RFP thay đổi là việc số tiền thực sự cần thiết trở nên nhìn thấy được, và phần chênh còn lại đã có thể so sánh như một khác biệt về năng lực.

RFP được dựng theo ba phần gồm tổng quan, nội dung đề nghị đề xuất và cách thức tiến hành lựa chọn. Yêu cầu chức năng thì xếp thứ tự ưu tiên theo Must/Want/Better, còn yêu cầu phi chức năng thì viết bằng con số và tiêu chuẩn thay vì tính từ. Với cơ sở tại Thái Lan, việc viết rõ tình trạng chuẩn hóa dữ liệu hiện có, phạm vi ngôn ngữ và tài liệu, yêu cầu kết nối với trụ sở chính, vị trí của cơ sở hỗ trợ, cùng các yêu cầu về thuế và pháp lý sẽ giúp giảm những bất ngờ sau khi vận hành.

Thời gian tham chiếu để lập là 7 tuần. Có thể bạn thấy dài, nhưng cách nhìn thực tế là coi đây là khoảng thời gian được trả trước, thay cho thời gian sẽ phải bỏ ra để điều chỉnh các khoản báo giá bổ sung và sửa chữa những hiểu lầm sau khi vận hành, vốn phát sinh khi tiến hành với những báo giá không đồng nhất.

Trước hết, hãy thử bắt đầu bằng việc gói gọn ba điểm gồm mục đích, yêu cầu Must và phạm vi muốn được bao gồm trong báo giá vào một trang giấy, rồi đưa cùng một bản cho tất cả các nhà cung cấp. Chỉ vậy thôi cũng đã làm thay đổi diện mạo của những tờ báo giá gửi về.

Ở giai đoạn còn thấy khó viết RFP từ đầu cũng không sao. TOMAS TECH đang triển khai và vận hành hệ thống quản lý sản xuất cho các nhà máy Nhật Bản tại Thái Lan, và cũng nhận trao đổi ngay từ giai đoạn rà soát các vấn đề hiện tại để sắp xếp thứ tự ưu tiên cho yêu cầu. Nếu bạn muốn cùng xác nhận xem cần quyết những gì trước khi bước vào lựa chọn nhà cung cấp, mời liên hệ với chúng tôi qua trang liên hệ.

Thông tin tham khảo

• GeNEE – Hướng dẫn cách viết RFP (đề nghị mời thầu) kèm mẫu và biểu mẫu (hướng dẫn lập RFP)
• Computer Management – RFP (đề nghị mời thầu) là gì, khác biệt với RFI và tài liệu định nghĩa yêu cầu cùng quy trình lập (bài giải thích về RFP)
• ASPIC – So sánh 17 hệ thống quản lý sản xuất, cách chọn theo quy mô, ngành nghề và phương thức sản xuất (bài so sánh hệ thống quản lý sản xuất)
• IO System Integration – So sánh 22 hệ thống quản lý sản xuất, bản mới nhất năm 2026 (tháng 1 năm 2026)
• newsclip.be – Bí quyết triển khai hệ thống quản lý sản xuất tại Thái Lan, phần 1 về công tác chuẩn bị để không thất bại (bài giải thích về triển khai hệ thống tại cơ sở Thái Lan)