開發不慎ERP上線擱淺(轉)

開發不慎ERP上線擱淺
一則典型的專案開發的真實案例剖析，包攬了專案開發中所遇到的諸多問題，總結出開發的實戰經驗，以此作為借鑑。

好開頭未必好兆頭

經過幾個月的反覆比較、挑選、論證，飛揚公司決定實施國外的一家大型軟體公司提供的ERP管理軟體。實施方是國內相當有實力的高成諮詢公司。作為這家大型機械裝置製造企業的CIO，陳先生終於可以鬆一口氣了。領導的大力支援，同行業相對便宜的價格，國外著名ERP軟體，實力強勁的實施公司，以及企業員工的計算機水平相對較高，所有這些看起來，ERP實施是開了個好頭。

很快，高成公司根據合同派來了由資深顧問李先生為首的專案實施小組，專案開始實施。為了配合專案實施，飛揚公司也成立了ERP專案小組，除了電腦部的原有的實施人員外，還從業務部門抽調了熟悉財務、分銷、製造的幾名業務人員。雙方的專案人員配合得相對還算不錯，調研，需求分析，關鍵使用者培訓，一步一步按照專案計劃在進行中。看到這麼順利的進展，陳先生不禁喜上心頭，跟專案小組放言：年底前爭取上線。

系統開發前的針鋒相對
不久，專案進行到方案設計階段。公司老總在ERP實施前就為實施定了調：現有的業務流程不能大改，只能逐步優化。飛揚公司業務相對複雜，有待改進和規範的業務流程不少，估計開發量不少，因此顧問在同業務部門討論解決方案前採取瞭如下應對策略：培訓客戶儘快熟悉系統功能，勸說客戶採用系統已有的相似功能，減少一些無謂的開發，系統沒有的功能則考慮開發。

當專案小組同業務部門開始就方案進行討論時，許多業務部門提出了開發需求。李先生極力反對對系統做大量開發，他認為該軟體是在數萬家企業使用的，它的管理思想是非常先進和合理的，而且大量開發不但會有開發的風險，延長了實施週期，還會對系統升級帶來諸多不便。業務部門堅持開發的理由是：1，企業現有的流程支援公司快速發展，目前使用的流程是經過實踐檢驗了的，只是需要更進一步完善；2，ERP的流程或許先進，但不可能因為實施ERP而大改，太大的調整將導致上下銜接不順，就連正常的運轉都難以維繫，上ERP就是找死。處在中間的陳先生犯難了：開發吧，時間長、風險大；不開發吧，業務部門的需求在老總看來是理所當然的，而且如果現在開發了以後就可以不開發，陳先生在權衡後選擇了開發。就這樣，實施小組和業務部門討論、協商、爭論了個把月，一大堆的開發擺在李先生面前。令李先生為難的是，如果拒絕，實施方案沒有業務部門的簽字，飛揚公司將拒付實施費。在開發和專案停頓的兩難中，李先生無奈的選擇了前者。在承諾給予開發後，業務部門才陸續在實施方案上簽字確認。

開發中的人員更替
在初步估算幾百個工作日的開發量，李先生深知開發任務的艱鉅，於是從公司將高階技術顧問劉先生以及另外兩個技術顧問調入專案組，而在此時，飛揚公司的幾名開發人員才剛剛從其他系統脫身介入ERP開發。按照李先生所擬定的實施計劃安排，留給劉先生的開發時間是不多的， 劉先生經過幾天的分析，擬定了開發了一個開發計劃，沒想到剛提交給李先生就遭到否決：“不行，開發的日期必須縮短！否則專案怎麼上線啊”，但劉先生有他的苦衷，因為他比誰都明白自己所面臨的難處：如此巨大開發量及緊張的開發時間安排，同時，他還要負責進行培訓，對飛揚公司的幾名開發人員進行知識轉移，以及其它技術顧問的開發跟進。

在修改了開發計劃後，劉先生投入了緊張的設計、開發過程中，並將一些簡單的開發交給了飛揚公司的開發人員。然而，飛揚公司的開發人員以前都未接觸該ERP軟體的開發，同時還需要維護公司其他系統，人也三心二意，因此起步格外吃力，經常向劉先生請教開發的問題。這些問題在劉先生看來，不但簡單而且如果有心的話應該很容易上手，因此不勝其煩，加上開發的困擾，對請教問題逐漸變得不耐煩，甚至有一次對飛揚公司的開發人員吼到：“這麼簡單的問題都不會，你們真是豬腦袋!”，雙方開發人員關係開始緊張起來。

事情發展下去越來越糟，飛揚公司將劉先生告到了高成公司上層，李先生不得不警告了劉先生，要求他必須保持耐心。不久，鑑於劉先生在專案中被客戶投訴，高成公司在例行的加薪中沒有給劉先生加薪，這些令劉先生怒不可遏，本來開發就挺累的，累了還不值，公司沒有重視他的價值，於是萌生了跳槽的想法。在後來的開發中，他沒有象開始那麼積極和負責了，整個專案的開發開始陷入了不正常中。

專案就在雙方開發人員的三心二意中繼續，本來確定的上線日期卻因為開發的未完成和專案方案的反覆調整而一拖在拖。眼看如果再不上線，整個專案將嚴重滯後，李先生不得不強行上線，留下一堆尚未開發完善的程式等待測試。此時，劉先生收到了一家獵頭公司發來的邀請，於是向公司提出辭職，儘管公司竭力勸阻和利誘，但去向已定的劉先生沒有動心，堅決辭職。高成公司不得不從其它專案抽調技術人員來接劉先生的手。專案上線後，業務部門在使用中，相關的開發程式逐漸暴露出了問題，不是今天這個報表執行出錯，就是明天那個功能計算有誤，整個專案小組陷入救火當中，儘管開發人員對前期由劉先生開發的程式進行了修修補補，但問題還是層出不窮，陳先生不時接到業務部門的抱怨和不滿，整個企業迷漫了對ERP失敗的看法，原來美好的願望在現實中被擊的粉碎。

專案開發徹底癱瘓
面對如此尷尬局面，不得已，陳先生將電腦部開發所有的開發力量集中於ERP專案，並要求開發人員加班加點，指望能夠扭轉頹勢。但是，電腦部的一些開發人員變的不滿，本來開發待遇就低，做相同的工作拿的比研發部門少的多，現在又加班，又沒什麼激勵措施，幹多幹少一個樣，有的人開始消極怠工，一張報表做個十天八天，稍有難度的開發就推給顧問。不久，高成公司的顧問逐步撤出專案，雙方開始了郵件打仗，你推給我，我推給你，一個問題解決需要很長時間。

隨著時間的推移，飛揚公司開發人員逐步變得熟練起來，開發的程式慢慢變得完善。但沒過多久，隨著業務部門對系統的熟悉，一些新的需求被提了出來，面對這些需求，除了繼續開發還能有什麼辦法嗎？電腦部的一些開發人員變的更加不滿，開發後又改來改去，感覺工作沒什麼意義，有的人開始考慮跳槽，提出了辭職。在這個節骨眼上提出辭職，陳先生當然不會批准，只有拖延，整個專案開發再次陷入停頓。

故事剖析
通過對上面的專案實施開發情況分析，哪些是可以借鑑的經驗呢？

首先，作為一個專案來說，保持相對穩定的開發隊伍是非常關鍵的。如果人員頻繁的流動，沒有相應的獎懲措施，那麼無法調動積極性，也就無法進行持續的開發；

其次，作為實施相對成熟的ERP系統，開發可以帶來相對方便的功能，但如果是沒有足夠的開發和實施力量，那麼軟體被改的面目全非，正常的功能不能使用，而且開發的新功能不完善，出現問題頻頻，嚴重影響使用；

再次，企業需要知道開發什麼，如何開發。作為實施ERP來說，改善企業的管理是一個逐步的過程，需要一定的積累，如果由於使用的不便等原因而對系統改這改那，很容易犯了拆東牆補西牆的錯誤，導致軟體開發了客戶卻不能用不願用的尷尬局面。

那麼，如何判斷開發需求呢？以下有幾個原則需要注意：

系統中不能提供功能需要開發：例如系統不提供生產線員工的生產統計，而只能粗放的管到生產線，這時，系統就需要進行開發。

涉及到流程的可以緩改：某些無關痛癢的流程的完善，如某些單據的稽核流程可以緩改，或用手工的方式去控制。

涉及到報表開發，需要分情況處理：報表的改動是最多的，幾乎70%的定製開發工作量都在報表的修改上，許多使用者很多情況下不了解系統中提供什麼樣的報表或者是不習慣系統中的報表就提出開發。這時，判斷是否需要開發的依據是：影響業務流程報表就需要及時開發，如：供應商入庫報表、銷售統計報表等，這些報表能夠連貫企業的流程，是業務管理所必須的。而有些報表則屬於錦上添花，不影響業務流程，這時就需要根據開發力量和時間安排合適的時間開發。

對於介面的調整，可以緩改或者不改：常見問題就是使用者對系統的介面不滿意，例如錄入的金額沒有千位符，想改，錄入框沒有按錄入順序排列，想改成按順序等等。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-20805/，如需轉載，請註明出處，否則將追究法律責任。