為什麼在實施過程中有的專案就能做的非常好，有的專案應用效果就非常差？原因在**？下面本人就從下面幾個方面進行分析：
1、什麼是專案？
2、在erp軟體行業專案應該怎麼做？
3、為什麼有一些專案會失敗，失敗的原因在**？
4、怎樣最大程度避免專案失敗？
1、什麼是專案？
專案可以理解為是一種任務，個人理解專案一般包括三層含義，即：什麼時間或週期、呼叫哪些資源、完成什麼任務並達成什麼目標；
專案的概念並不是只在軟體實施過程中存在，其實現在各種各樣千差萬別的專案多種多樣，如：對a企業進行產品的銷售，這就是乙個專案。其特點是銷售人員通過一定時間面對客戶的中高層通過對功能的演示和講標，完成最終銷售的目標；乙個新產品的研發也可以視作為專案，其特點是是n個開發人員要通過n個月的研發完成乙個產品的最終成形；如北京五環路的貫通也乙個專案，其特點是多少個施工人員要通過多少天的奮戰，動用多少的機器以完成道路的通車為目標；再如唐山曹妃甸要進行招商引資，招商引資也這是乙個專案。專案的種類多種多樣，在此不再舉例。
2、在erp軟體行業專案應該怎麼做？
1）、嚴格制定專案的實施週期和計畫及方案；
在專案實施開始之前，一定要根據每個客戶不同的情況，制定出相應的實施計畫、實施方案並規劃出實施週期來，這一點是非常重要的。沒有實施計畫就無法預知專案何時完成，使人找不到目標感，對於乙個沒有目標的專案來說這將是非常可怕的事情。
2）、專案要獲得甲方高層的足夠重視；
所有專案無論大小都應該獲得甲方高層的足夠重視，成功的專案往往都是企業一把手直接抓的工程。一把手工程的好處為：領導講話具有權威性、下達指令後各部門執行力比較強、牴觸專案推進的部門少。因此一把手專案非常有利於專案的推進。
3）、嚴格的按照專案實施計畫進行實施，並監控專案是否按照計畫正在進行；
實施計畫制定後，雙方人員都要按照既定的目標去努力，如果發現實施過程中與計畫出現了偏差，需要馬上對實施計畫進行變更，並分析出現偏差的原因和改善方案，亡羊補牢精神是最可貴的。
4）、對於大型專案可以分成幾個階段，按階段進行實施；
對於大型和超大型的專案，往往實施週期會有一年或幾年。長時間的專案實施會使人找不到終點，因找不到終點而失去動力。而把專案分成幾個階段後，每個階段都會制定出階段性想要達到的目標，這樣給人的感覺是距離專案的目標非常接近，工作也就有了動力。
5）、與客戶商定明確的需求和範圍，確定專案驗收的目標；
實施範圍的確定是實施過程中的重中之重，實施範圍沒有界定或界定模糊，會造成客戶需求無窮無盡，需求不斷增加的後果就是專案無法按期交付，甚至專案暫停或退貨。為了避免這種情況最好的方法就是君子約定，在專案開始時就書面確認乙方做哪些內容，做哪些功能，達到什麼樣的效果後專案就可以驗收，這樣做對專案的雙方都是有利的。再者一定要吃透需求，書面確定需求的內容，目前在實施過程中因需求雙方理解存在偏差而導致專案返工的情況還是比較常見的，偏差太大的情況下往往會返工多次。
6）、建立有效的專案溝通的機制，保證甲乙雙方溝通順暢；
這種溝通尤其是在專案出現危機時尤為重要。
7）、建立健全的文件機制
目前實施的大專案都是多個人共同協作來實施的，每個人每天做了什麼內容，有哪些成果或針對專案進展有哪些規劃等，除了自己之外其他人都不清楚。這樣情況怎麼避免？最好的方法是編寫專案文件，每一步都要有操作文件來支撐，比如今天我對產品增加了某個功能、對哪些資料進行了完善、需要誰來協助哪些事情、對客戶的哪個方案進行了更新。這些文件都要記錄下文件的版本號是多少，是誰在哪個時間段更新的等，以方便專案組人員的協作；
8）、專案組成員穩定性的保障，尤其是雙方核心專案組成員的保障；
乙個專案要培養中乙個合格的核心人員，需要這個人員不僅要對企業業務流程十分精通，還要對軟體操作流程十分熟悉，並能夠處理軟體中常見的一些問題。而這樣的人員的培養需要幾個月甚至更長的時間。而如果在關鍵的時刻核心人員的離職會給專案的推進帶來毀滅性的災難。
9）、明確專案獎勵和懲罰制度；
怎樣避免人才的流失？怎樣讓員工對專案充滿激情？怎麼避免軟體實施過程中員工的不公平對待造成的情緒化（干多幹少都一樣）？怎樣最大程度的防止錯誤的發生？這些內容都要有一定的機制來保障和約束，那麼最有效的方法就是建立起專案獎懲制度。
10）、基礎資料編碼的規範化和擴充套件性規劃
要蓋一座高樓大廈就必須打好根基，對於erp系統來說基礎資料就是這座高樓大廈的根基，基礎資料的重要性可想而知。
11）、20/80原則
目前很多專案中20％的需求在實施和開發的時間佔到了整個專案總工作量的80％，對於這樣的需求要進行討論再討論，確定最優解決方案或遮蔽某些不重要不合理的需求。
12）、業務流程反覆測試和校驗
任何產品都是存在bug的，像微軟這樣的軟體帝國都不敢說他的產品沒有bug，所以必須在實施方案確定後按照實施方案來跑產品，尤其是核心流程的反覆測試和優化。
13）、專案資源的保障
資源主要來講還是人的保障，如果只購買了產品而沒有人來實施和開發，專案不可能做好。
14）、加強專案核心人員的培訓和培養；
客戶方核心專案成員一但培養出來後，他就可以支撐起客戶方業務的一片天，一些實施業務便可交由他來做。這樣無論對客戶方人員的成長及後續的維護都是有好處的。
15）、基層操作人員的培訓培訓再培訓
基層操作人員經常反饋的問題是產品不好用。為什麼不好用呢，無非是操作習慣的變更和操作方法的問題。所以培訓一定要貫穿專案實施的始終，改變操作員的習慣，認知我們的產品為企業帶來的好處，不能用侷限的眼光來看待產品。
3、為什麼有一些專案會失敗，失敗的原因在**？
當乙個專案失敗後，失敗原因這個皮球往往就會踢來踢去。銷售人員說實施人員水平低、在專案上不努力、要是更換乙個水平高的實施人員也不至於專案失敗；實施人員說銷售人員過度承諾、客戶需求無止境、產品bug多、開發團隊的支援跟不上等，要不是這些因素，專案也不會這樣子；開發人員說客戶需求不明確，造成開發出來的產品改來改去，多次返工。
問題到底在**？到底是哪個環節出了問題？是單純的某個人的責任嗎？或者是單純的某個部門的責任嗎？答案是：「不是」！
那麼問題到底出在了**？答案是：「甲乙雙方各打10大板，雙方都有責任！」
首先是客戶方的問題：a系統上線之前業務的梳理和優化時業務部門不參與，上線後瞎起鬨；b專案經理沒有實權，下達的指令業務部門不執行；c各業務部門經理不重視；d核心目標及需求不清楚；e資訊化基礎弱，底子薄，沒人來統籌管理；f新上軟體後改變了基層操作人員的操作習慣，面對新的軟體不願意接受，提高企業管理水平對他們來說都天方夜譚；g高層領導假重視和瞎指揮；h各部門的利益衝突；i團隊核心成員頻繁更換等；
其次是實施方的問題：a實施方團隊更換頻繁，我接觸過的專案有的最多換了10任專案經理；b專案沒有資源保證，實施人員今天3個人在現場實施，明天就有可能1個人單獨奮鬥了，拿1個人當3個人用；c銷售人員為了簽單和業績，承諾再難的需求我們也能實現；d為了保證按時上線，在業務理解不深，需求沒有吃透，理解了差不多的情況下就開始了實施過程；e同工不同酬，消極怠工；f專案經理控制不住客戶的需求，導致客戶的需求越來越多，產品很難交付；g產品bug問題
4、怎樣最大程度避免專案失敗？
要避免專案的失敗必須從失敗的案例中吸取教訓，要從客戶方和實施方兩個方面著手：
1、 客戶方在上軟體之前一定要先知道自己上軟體要做什麼？是為了充一下門面還是想達到乙個什麼樣的目標，實現什麼樣的功能？
2、 客戶方高層必須重視專案，客戶方專案經理在企業必須有權威或權力，能夠保證每一項下達的指令各個部門都能貫徹執行；
3、 客戶方有乙個穩定的專案團隊，並有1到2個精通業務和產品的核心成員；
4、 實施方在實施之前先評估專案情況，劃出乙個實施範圍的圈圈來，確定驗收標準；
5、 三分軟體七分實施，實施人員的水平對於專案的交付也有很大的關係，不一定要派出最好的顧問到客戶現場，一定要派出最合適的顧問到專案現場；
6、 按照計畫來實施專案，按章辦事，一步乙個腳印的來實施，不要想一口吃成個胖子；
7、 保持雙方專案經理的持續有效的溝通，出現問題即時反饋並處理；
8、 實施方人員的保證，堅決不能出現因為實施或開發人員不在現場而導致的暫停狀態；
如果在實施過程中客戶方和實施公司雙方都能夠達到上面所說的幾點，不敢說專案一定會成功，但專案一定不會失敗！
ERP專案管理經驗分享
本人進入軟體行業已經有5個年頭了，主導實施和參與過的大大小小的專案有20餘個。其中有些專案做的非常好，提公升了客戶企業的管理水平，也規範了企業的業務操作水平，優化了企業的流程，客戶非常認同我們實施的價值 也有的專案實施效果一般，客戶在應用軟體前後沒有明顯的效果，唯一的成果就是計算機代替了人來彙總一些...
專案管理經驗分享
我的專案經驗分為專案啟動前，專案開發中，專案維護中三個階段總結。一 專案啟動前 1 需求分析 根據需求給定的需求說明書，去仔細分析理解每乙個需求任務，評估功能需求的可做性 技術可行性，評估功能的實現和耗費的資源 人力和時間 的可支援性。例如 在tulipb b02 專案開發過程中，在使用者遠端許可權...
專案管理經驗借鑑
要馬兒好，又要馬兒不吃草 這句話不知是誰 發明 的 發明這句話的人，想來是專案管理的高手。為什麼？因為專案管理的精義，就是 又要馬兒好，又要馬兒不吃草。乙個成功的專案，通常有三個要素 這三個彼此互斥的要素，就像乙個等邊三角形的三邊一樣，缺了一邊，或任何一邊比其它兩面邊短，我們就不能再稱這個三角形為等...