看完這個案例，我的第一反應是：這又是一個準備不充分的專案。和許多企業在資訊化過程中走過的彎路一樣，A企業的選型過程顯得倉促而不完善，看起來這樣可以節約一些時間，但具體實施的情況表明：該做的準備工作，一個都不能少。

　　A企業的案例可以引申兩個話題，首先是充分的準備工作應該是什麼樣的？其次是在當前的現狀下，A企業如何順利地完成專案？

　　需求與解決方案不匹配

　　a企業在實施過程中所出現的問題集中體現在a企業的需求和b企業的解決方案不匹配，具體體現在以下方面：

　　◆ 新系統和a企業的遺留系統在整合方面的不匹配。
　　◆ CAPP和a企業的需求出現了較大的不匹配。

　　因此，如何使專案的推進很順利，從根本上取決於a企業所能接受的需求變化範圍。需求的不匹配是幾個基本的事實，很難透過什麼行動來回避。因此，說到底，專案能否順利推進取決於a企業自身的態度。

　　重新調研和規劃

　　a企業應該補做的一個工作就是重新做一次細緻的需求調研和規劃工作，透過這個工作可以明確a企業期望透過PDM、CAPP等系統的實施究竟解決什麼問題。這個工作應該是深入而細緻的，基本上能把系統實施的底線搞清楚，同時做到不遺漏。

　　透過這樣的分析，可以摸清楚a企業對系統的需求究竟是什麼。比如，落在上述矩陣右上角的部分，代表對a企業而言非常重要的那些系統功能與需求，代表著a企業對新系統的基本期望。一般來說，企業往往希望這些功能能夠得到不折不扣的實現。在選型過程中，在這些方面的匹配程度往往會作為最重要的評價標準。

　具體到a企業，因為選型已經在一定程度上成為定局，那麼，在看到b公司軟體功能有一定差距的現實情況下，a企業應該首先尋找上述矩陣中右上角的那些功能，儘量要求b公司在這些方面，透過二次開發等手段儘量實現需求。如果實在差得太多，中止與b企業的合作是一個明智的選擇。

　　a企業只是將風險延遲

　　儘管在案例中，我們可以看到，到目前為止，a企業與b企業在該專案中似乎還很和諧，但表面上的和諧並不意味著合作的順利，這只是將風險延遲而已。既然是風險，遲早是要爆發的，只不過，破壞程度會更大而已。專案管理領域有一個經典的諺語：不要試圖拯救一個正在下沉的船，說的就是這個意思，如果不能在現有的框架內解決問題，那就跳出這個框架，儘管這樣可能意味著a企業要遭受一定的波折。

　　有意思的是，就這個案例，我們可以進一步追問一下，a企業為什麼會在選型過程中出現一定問題的呢？我覺得，僅僅用準備不充分是不能回答這個問題的。

　　案例似乎在告訴我們，a企業資訊化的相關人員（高層領導、業務人員、IT人員）在溝通上並不充分。在資訊化的不同階段，每一種角色應該做什麼工作似乎並不清楚，也就是說出現案例中的這種現象：a企業沒有說了算的領導在場，幹活的技術人員在提出質疑後，聽取了軟體方所謂的“合同裡只要求標準版，而標準版裡確實不提供這兩個模組”的解釋後也就作罷。最後只能感嘆，“那麼多錢原來大部分還是給設計部門上CAD和PDM，工藝上CAPP，成為兩個系統……”

　　我覺得，a企業的相關負責人應該仔細思考這樣一個問題，如何建立一個穩定的架構來推進資訊化工作。而案例中的這個現象也似乎在告訴我們後續的結局：技術人員會發現越來越多的不匹配和不和諧的現象，直到專案出現重大危機時，領導才會出面，然而，已經失去解決問題的最佳時機。[@more@]

資訊化專案實施前面的準備工作（轉）

相關文章