第三個誤區：把全部希望都寄託在外包廠商那邊。
不少企業在把某項任務外包給其他軟體廠商或者開發公司以後，就會放手不管。就只會在那邊等著讓他們把成品送過來。其實，這是非常危險的。因為外 包公司由於種種限制，其並不能夠了解你們企業的全部操作方式。如果就讓軟體公司在那邊閉門造車，則最後出現的東西很難保障符合企業的需要。所以我認為，如 果企業把某個資訊化專案外包，不能夠把全部希望都寄託給外包廠商。而是應該自己把好每道任務的關口。
具體來說，筆者建議案如下的方式操作。
首先，應該要求外包廠商把確認好的需求與解決方案通過書面的方式跟我們cio進行再次確認。因為口頭確認的內容，很容易引起誤解。而且時間久 了，也很容易遺忘。再說，乙個外包專案也不是短時間內可以完成的。如果外包廠商跟企業之間有一些實質性的書面文件，則對於外包廠商的開發人員來說，也有了 乙個對照的依據。同時，即使以後出現分歧的話，也有乙個書面文件的佐證。所以，筆者建議cio，不要怕麻煩。當把企業的需求交待給外包廠商的話，還要讓對 方出具乙份書面的需求文件，並配上解決方案。這有利於雙方消除分歧。
其次，不要到外包專案完工再進行驗收。而是每完成一項功能或者乙個模組之後，就進行驗收。這主要是因為，雖然通過前期的交流，再通過書面文件的 確認，但是仍然無法百分之百的消除彼此的分歧。如果等到產品完成驗收的時候，才發現雙方存在意見的分歧，那麼對於雙方的損失都很大的。對於外包廠商來說， 他們必須對軟體或者解決方案進行修改。由於已經是成品的東西，修改起來就會更加麻煩。而對於企業來說，則就面臨著時間上的損失，時間成本會增加。故如果在 成品完成階段才進行驗收的話，對於雙方都是不利的。筆者如果把乙個專案外包給其他合作夥伴的話，則會對整個過程進行追蹤。如筆者會讓對方在每個週末把本週 完成的任務跟我說。然手把這個月完成的成果先交給我。然後筆者進行測試。若發現問題的話，馬上跟對方聯絡，讓對方進行修改。如此的話，效果會比較好。一方 面筆者可以在程式開發的時候就發現一些不滿意的地方或者對方誤解的地方，提出來讓對方修改。如此的話，到了成品交付的時候，成品的缺陷會少許多。另一方 面，通過對方每週一報，可以讓筆者了解專案的進度。如果專案沒有按進度進行的話，筆者就會馬上督促對方。 這有利於專案在規定時間內完成。
最好，需要讓對方提供專案文件。如前不久筆者委託一家軟體公司，幫助我們完善一些erp系統中的功能。事先筆者就要求他們，必須把erp系統中 修改的內容，以書面的文件記錄下來。如要實現某個功能，在erp系統中修改了哪些地方;在資料庫中是否增加了內容;你們是如何進行測試的;對其他作業的影 響等等。每完成乙個功能的開發，就需要把這份文件交付給我們。也就是說，他們的工作成果，不僅僅是成品而已;還有中間所產生的文件。因為筆者必須要了解這 中間發生了什麼事情，功能是如何實現的。這對於筆者日後維護erp系統是非常重要的。而且當出現問題的時候，筆者還可以藉此判斷這是否是對方的二次開發所 造成的。
所以，筆者建議各位cio，如果你們要把某個專案外包的話，則最後的成果既然重要，但是也不能夠小瞧中間的過程。若不對中間的每一道過程進行把 關的話，則很難保障最後成果的質量。最重要的是，如果對方不提供中間實現過程的文件，那麼對於cio日後維護來說，會有很大的難度。總之，不能夠把全部希 望都寄託在外包廠商那邊，cio要跟蹤整個外包過程。
切莫病急亂投醫 企業選擇資訊化外包指南 1
it商業新聞網 隨著企業資訊化的發展，資訊化外包，包括軟體與服務的外包，越來越普遍。在企業資訊化相關技術能力不足的情況下，把一些資訊化方面的工作外包給專家來做，是乙個省心省力的明智選擇。不過由於企業缺乏這方面的經驗，在需要外包的時候，往往會 病急亂投醫 導外包效果並不是很好。筆者現在結合自己外包的經...