在信息化項目剛起步階段，企業實施信息化項目時，一般都不會進行招標。這主要有多方面的原因。如在以前信息化項目很多都可能是由IT部門主導，而他們對于信息化項目的招標工作不是很清楚，所以，也就放棄了招標。近幾年，企業也意思到了這么做的弊端，所以，在信息化項目上，也開始引入了招標管理，以規范信息化項目的運作。

　　可惜的是，由于缺乏相關的經驗，招標書的書寫上，存在比較多的毛病。這篇文章，我將結合自己的經歷，談談在信息化項目的招標書書寫時，常見的一些毛病。

　　一、招標書上需求寫的不夠細致、深入。

　　信息化項目招標書上，企業的需求是一塊不容忽視的內容。但是，我遇到過一些用戶，在需求上，存在一些過大過粗的錯誤。如我以前接觸過一家客戶，其在寫銷售管理需求時，招標書上說要實現“銷售訂單價格分級確認審核”需求。這個需求現在大部分的信息化管理軟件都可以實現。

　　但是，具體如何實現呢？

　　如分級審核要分幾個級別審核，分三級呢，還是五級？在后來的軟件供應商演示的過程中，發現他們只能夠實現對于價格的三級確認，而按照用戶現在的需求，則需要實現至少五級的確認。最后從來演示的供應商中，發現只有四家供應商符合這個要求，而其他的十余家供應商否不符合這個需求。這說明什么呢？這說明我們用戶由于在招標說明書上沒有寫清楚需求，把很多的時間浪費在這些基本功能的刷選上。若我們能夠把這些基本需求再定義的詳細一點，那很多供應商可能都會自動選擇退出了。我們也就不會浪費這么多的時間。

　　如分級審核是執行統一的政策呢，還是有地域差異呢？如對于一些產品，可能會根據當地的經濟有不同的價格優惠。如對于西北地區，我們為了推廣市場，同時，出于當地的消費水平需要，企業可能會給與一些價格上的扶持。如對于這些市場上來說，業務員的價格折扣權利有8折扣。而對于其他市場來收，業務員的價格折扣權利只有9折。若統一的折扣政策，可能很多信息化管理系統都可以實現，但是，若是這種分區域的折扣政策，可以實現這個功能的信息化管理系統就要少得多了。那我們也可以過濾掉一些不符合我們要求的供應商了。

　　從以上兩個例子中，我們就可以看出，在招標書上，把需求寫的詳細、深入的重要性了。所以，在招標書書寫之前，要先進行需求調研、分析、研究。沒有準確的需求、沒有詳細的需求的招標書，對于招標工作來說，沒有多大實際的利益。而且，很容易被對方鉆空子。

　　在信息化項目剛起步階段，企業實施信息化項目時，一般都不會進行招標。這主要有多方面的原因。如在以前信息化項目很多都可能是由IT部門主導，而他們對于信息化項目的招標工作不是很清楚，所以，也就放棄了招標。近幾年，企業也意思到了這么做的弊端，所以，在信息化項目上，也開始引入了招標管理，以規范信息化項目的運作。

　　可惜的是，由于缺乏相關的經驗，招標書的書寫上，存在比較多的毛病。這篇文章，我將結合自己的經歷，談談在信息化項目的招標書書寫時，常見的一些毛病。

　　一、招標書上需求寫的不夠細致、深入。

　　信息化項目招標書上，企業的需求是一塊不容忽視的內容。但是，我遇到過一些用戶，在需求上，存在一些過大過粗的錯誤。如我以前接觸過一家客戶，其在寫銷售管理需求時，招標書上說要實現“銷售訂單價格分級確認審核”需求。這個需求現在大部分的信息化管理軟件都可以實現。

　　但是，具體如何實現呢？

　　如分級審核要分幾個級別審核，分三級呢，還是五級？在后來的軟件供應商演示的過程中，發現他們只能夠實現對于價格的三級確認，而按照用戶現在的需求，則需要實現至少五級的確認。最后從來演示的供應商中，發現只有四家供應商符合這個要求，而其他的十余家供應商否不符合這個需求。這說明什么呢？這說明我們用戶由于在招標說明書上沒有寫清楚需求，把很多的時間浪費在這些基本功能的刷選上。若我們能夠把這些基本需求再定義的詳細一點，那很多供應商可能都會自動選擇退出了。我們也就不會浪費這么多的時間。

　　如分級審核是執行統一的政策呢，還是有地域差異呢？如對于一些產品，可能會根據當地的經濟有不同的價格優惠。如對于西北地區，我們為了推廣市場，同時，出于當地的消費水平需要，企業可能會給與一些價格上的扶持。如對于這些市場上來說，業務員的價格折扣權利有8折扣。而對于其他市場來收，業務員的價格折扣權利只有9折。若統一的折扣政策，可能很多信息化管理系統都可以實現，但是，若是這種分區域的折扣政策，可以實現這個功能的信息化管理系統就要少得多了。那我們也可以過濾掉一些不符合我們要求的供應商了。

　　從以上兩個例子中，我們就可以看出，在招標書上，把需求寫的詳細、深入的重要性了。所以，在招標書書寫之前，要先進行需求調研、分析、研究。沒有準確的需求、沒有詳細的需求的招標書，對于招標工作來說，沒有多大實際的利益。而且，很容易被對方鉆空子。

　　三、招標書對于項目范圍規定的不夠明確，模棱兩可。

　　我相信，很多企業的項目管理員，都有類似的苦惱。

　　一方面，企業員工的需求如同滾雪球一般，在慢慢的膨脹，越滾越大。一些新需求，如同雨后春筍一般，紛紛冒出來。員工系統使用的越深入，越發現軟件的不足與缺陷，使用起來也沒有想象中那么方便。

　　另一方面，信息化項目合作伙伴也在不斷的回避我們用戶增加的新需求，他們對不斷增加的新需求、不斷變更的需求實現方式叫苦不已，他們擔心，長久以往下去，他們會如同美國陷入伊拉克戰爭那樣，陷入泥潭而不可拔。

　　一方面，用戶不斷向信息化項目負責人施壓，另一方面，信息化合作伙伴又找種種理由（理由是成立的，不是借口）來進行推托，要么不斷的增加實施成本，這都讓信息化項目負責人在項目實施的過程中，兩頭不是人。

　　只有真正到了這緊張的時刻，CIO才會知道，原來招標書有這么的重要。要是在招標書上，能夠寫明詳細的需求，那么，也不會弄到現在這個進退兩難的地步了？在招標書上，對于項目范圍規定的不夠明確，對于需求定義的不夠詳細，是造成今天一切的罪魁禍首。

　　所以，在書寫招標書的時候，我們要明確定義出項目的范圍，整理清楚項目的具體需求，讓員工與項目合作伙伴，一看到招標書，就知道要實現什么什么功能，如此，可以減少三方之間的分歧；也可以減輕CIO肩膀上的壓力。

　　四、需求沒有跟管理制度結合，跟現實處理脫鉤。

　　若我們在招標說明書上寫需求的時候，沒有跟管理制度結合，那么，需求只是一種計算機上一些簡單的實現過程，但是，他沒有反應企業真實的需要。因為沒有跟管理制度結合的需求，就好像沒有血色的臉一樣，蒼白無力，經不起任何的推敲。

　　我見過一家企業寫的招標書，其招標書上寫的需求可謂是最詳細不過了，而且，還配有具體的流程圖。但是，其需求說明上，忽視了管理制度、忽視了例外。如他們在寫ERP收貨管理的時候，對于收貨管理有一個進貨數量的控制需求，他們要求，倉庫在收貨時，不能收超過采購單數量的貨物。若超過了，要么讓對方帶回去，要么暫時寄存在企業中，可以在下次采購單的時候，進行抵扣。但是，后來發現，在現實處理中，還不一定這么做。當經過采購經理批準的話，還是要按實入庫的。

　　那為何會有這種差異呢？原來，他們在寫招標書的時候，是按照企業的制度來的。但是，企業的制度跟現在的實際處理有一定的差異，可能是制度還沒來的更新。此時，若按這個有問題的管理制度寫招標書的話，就可能產生這個問題了。

　　所以，我們在寫招標書的時候，不要太迷信與企業的管理制度?，F在企業能夠百分之百的按照企業管理制度來辦事的企業還不是很多。所以，我們有了管理制度后，只能作為參考。我們作為信息化項目地掌舵人，要抱著高度負責的態度，要跟用戶一一進行確認，看看這些制度是否真的被落實下去，跟現實處理是否相同。我們要知道，在沒有系統的時候，制度跟現實即使脫節了，企業業務也可以正常進行；但是，上了信息化管理系統后，若系統處理跟現實處理脫節了，那企業可能就寸步難行了。而系統按照企業制度來設計，若企業制度跟現實處理不一致，那難免的，系統處理也會跟企業正常運作產生矛盾，到那時候，問題就大了，系統會影響企業的正常生產經營。

　　故在寫招標書的時候，不要把制度一成不變的往招標書上搬，而是還要跟用戶確認一下，這些制度的有效性到底如何。