一則典型的項目開發的真實案例剖析，包攬了項目開發中所遇到的諸多問題，總結出開發的實戰經驗，以此作為借鑒。
好開頭未必好兆頭
經過幾個月的反復比較、挑選、論證，飛揚公司決定實施國外的一家大型軟件公司提供的ERP管理軟件。實施方是國內相當有實力的高成咨詢公司。作為這家大型機械設備制造企業的CIO，陳先生終于可以松一口氣了。領導的大力支持，同行業相對便宜的價格，國外ERP軟件，實力強勁的實施公司，以及企業員工的計算機水平相對較高，所有這些看起來，ERP實施是開了個好頭。
很快，高成公司根據合同派來了由顧問李先生為首的項目實施小組，項目開始實施。為了配合項目實施，飛揚公司也成立了ERP項目小組，除了電腦部的原有的實施人員外，還從業務部門抽調了熟悉財務、分銷、制造的幾名業務人員。雙方的項目人員配合得相對還算不錯，調研，需求分析，關鍵用戶培訓，一步一步按照項目計劃在進行中。看到這么順利的進展，陳先生不禁喜上心頭，跟項目小組放言：年底前爭取上線。
系統開發前的針鋒相對
不久，項目進行到方案設計階段。公司老總在ERP實施前為實施定了調：現有的業務流程不能大改，只能逐步優化。飛揚公司業務相對復雜，有待改進和規范的業務流程不少，估計開發量不少，因此顧問在同業務部門討論解決方案前采取了如下應對策略：培訓客戶盡快熟悉系統功能，勸說客戶采用系統已有的相似功能，減少一些無謂的開發，系統沒有的功能則考慮開發。
當項目小組同業務部門開始方案進行討論時，許多業務部門提出了開發需求。李先生極力反對對系統做大量開發，他認為該軟件是在數萬家企業使用的，它的管理思想是非常先進和合理的，而且大量開發不但會有開發的風險，延長了實施周期，還會對系統升級帶來諸多不便。業務部門堅持開發的理由是：1，企業現有的流程支持公司快速發展，目前使用的流程是經過實踐檢驗了的，只是需要更進一步完善；2，ERP的流程或許先進，但不可能因為實施ERP而大改，太大的調整將導致上下銜接不順，連正常的運轉都難以維系，上ERP是找死。處在中間的陳先生犯難了：開發吧，時間長、風險大；不開發吧，業務部門的需求在老總看來是理所當然的，而且如果現在開發了以后可以不開發，陳先生在權衡后選擇了開發。這樣，實施小組和業務部門討論、協商、爭論了個把月，一大堆的開發擺在李先生面前。令李先生為難的是，如果拒絕，實施方案沒有業務部門的簽字，飛揚公司將拒付實施費。在開發和項目停頓的兩難中，李先生無奈的選擇了前者。在承諾給予開發后，業務部門才陸續在實施方案上簽字確認。
開發中的人員更替
在初步估算幾百個工作日的開發量，李先生深知開發任務的艱巨，于是從公司將高級技術顧問劉先生以及另外兩個技術顧問調入項目組，而在此時，飛揚公司的幾名開發人員才剛剛從其他系統脫身介入ERP開發。按照李先生所擬定的實施計劃安排，留給劉先生的開發時間是不多的， 劉先生經過幾天的分析，擬定了開發了一個開發計劃，沒想到剛提交給李先生遭到否決：“不行，開發的日期必須縮短！否則項目怎么上線啊”，但劉先生有他的苦衷，因為他比誰都明白自己所面臨的難處：如此巨大開發量及緊張的開發時間安排，同時，他還要負責進行培訓，對飛揚公司的幾名開發人員進行知識轉移，以及其它技術顧問的開發跟進。
在修改了開發計劃后，劉先生投入了緊張的設計、開發過程中，并將一些簡單的開發交給了飛揚公司的開發人員。然而，飛揚公司的開發人員以前都未接觸該ERP軟件的開發，同時還需要維護公司其他系統，人也三心二意，因此起步格外吃力，經常向劉先生請教開發的問題。這些問題在劉先生看來，不但簡單而且如果有心的話應該很容易上手，因此不勝其煩，加上開發的困擾，對請教問題逐漸變得不耐煩，甚至有一次對飛揚公司的開發人員吼到：“這么簡單的問題都不會，你們真是豬腦袋!”，雙方開發人員關系開始緊張起來。
事情發展下去越來越糟，飛揚公司將劉先生告到了高成公司上層，李先生不得不警告了劉先生，要求他必須保持耐心。不久，鑒于劉先生在項目中被客戶投訴，高成公司在例行的加薪中沒有給劉先生加薪，這些令劉先生怒不可遏，本來開發挺累的，累了還不值，公司沒有重視他的價值，于是萌生了跳槽的想法。在后來的開發中，他沒有象開始那么積極和負責了，整個項目的開發開始陷入了不正常中。
項目在雙方開發人員的三心二意中繼續，本來確定的上線日期卻因為開發的未完成和項目方案的反復調整而一拖在拖。眼看如果再不上線，整個項目將嚴重滯后，李先生不得不強行上線，留下一堆尚未開發完善的程序等待測試。此時，劉先生收到了一家獵頭公司發來的邀請，于是向公司提出辭職，盡管公司竭力勸阻和利誘，但去向已定的劉先生沒有動心，堅決辭職。高成公司不得不從其它項目抽調技術人員來接劉先生的手。項目上線后，業務部門在使用中，相關的開發程序逐漸暴露出了問題，不是這個報表運行出錯，是明天那個功能計算有誤，整個項目小組陷入救火當中，盡管開發人員對前期由劉先生開發的程序進行了修修補補，但問題還是層出不窮，陳先生不時接到業務部門的抱怨和不滿，整個企業迷漫了對ERP失敗的看法，原來美好的愿望在現實中被擊的粉碎。
項目開發徹底癱瘓
面對如此尷尬局面，不得已，陳先生將電腦部開發所有的開發力量集中于ERP項目，并要求開發人員加班加點，指望能夠扭轉頹勢。但是，電腦部的一些開發人員變的不滿，本來開發待遇低，做相同的工作拿的比研發部門少的多，現在又加班，又沒什么激勵措施，干多干少一個樣，有的人開始消極怠工，一張報表做個十天八天，稍有難度的開發推給顧問。不久，高成公司的顧問逐步撤出項目，雙方開始了郵件打仗，你推給我，我推給你，一個問題解決需要很長時間。
隨著時間的推移，飛揚公司開發人員逐步變得熟練起來，開發的程序慢慢變得完善。但沒過多久，隨著業務部門對系統的熟悉，一些新的需求被提了出來，面對這些需求，除了繼續開發還能有什么辦法嗎？電腦部的一些開發人員變的更加不滿，開發后又改來改去，感覺工作沒什么意義，有的人開始考慮跳槽，提出了辭職。在這個節骨眼上提出辭職，陳先生當然不會批準，只有拖延，整個項目開發再次陷入停頓。
故事剖析
通過對上面的項目實施開發情況分析，哪些是可以借鑒的經驗呢？
首先，作為一個項目來說，保持相對穩定的開發隊伍是非常關鍵的。如果人員頻繁的流動，沒有相應的獎懲措施，那么無法調動積極性，也無法進行持續的開發；
其次，作為實施相對成熟的ERP系統，開發可以帶來相對方便的功能，但如果是沒有足夠的開發和實施力量，那么軟件被改的面目全非，正常的功能不能使用，而且開發的新功能不完善，出現問題頻頻，嚴重影響使用；
再次，企業需要知道開發什么，如何開發。作為實施ERP來說，改善企業的管理是一個逐步的過程，需要一定的積累，如果由于使用的不便等原因而對系統改這改那，很容易犯了拆東墻補西墻的錯誤，導致軟件開發了客戶卻不能用不愿用的尷尬局面。
那么，如何判斷開發需求呢？以下有幾個原則需要注意：
系統中不能提供功能需要開發：例如系統不提供生產線員工的生產統計，而只能粗放的管到生產線，這時，系統需要進行開發。
涉及到流程的可以緩改：某些無關痛癢的流程的完善，如某些單據的審核流程可以緩改，或用手工的方式去控制。
涉及到報表開發，需要分情況處理：報表的改動是多的，幾乎70%的定制開發工作量都在報表的修改上，許多用戶很多情況下不了解系統中提供什么樣的報表或者是不習慣系統中的報表提出開發。這時，判斷是否需要開發的依據是：影響業務流程報表需要及時開發，如：供應商入庫報表、銷售統計報表等，這些報表能夠連貫企業的流程，是業務管理所必須的。而有些報表則屬于錦上添花，不影響業務流程，這時需要根據開發力量和時間安排合適的時間開發。
對于界面的調整，可以緩改或者不改：常見問題是用戶對系統的界面不滿意，例如錄入的金額沒有千位符，想改，錄入框沒有按錄入順序排列，想改成按順序等等
