Dynamics 365 實施常見問題及避免

2021-10-08 10:58:57 字數 1898 閱讀 1276

專案管理中,解決問題的方法沒有對錯,只有是否適合自己,以下經驗僅僅是個人的觀點,分享出來是為了跟同行進行交流,給初學者在專案實施過程中一些參考案例及思路。

經歷過erp的實施後發現,大部分的專案實施都很辛苦,尤其上線前後,顧問們都加班加點的幹活,但是上線後仍然發現有很多問題,我見過和聽過的問題主要有以下幾類。

1. 效能問題

2. 主資料問題

3. 業務流程問題

4. 操作問題

5. 功能bug

或多或少問題都可以歸結到上述幾類中,效能問題: 這一類在各個專案中經常遇到,前面也有專題從技術角度去進行了闡述,這裡不再多敘。操作問題:可以通過培訓來解決。這篇文章針對其他幾類進行一些**。

主資料問題:這部分的問題相對比較嚴重,很多erp的專著中也會提到,主資料是erp的重中之重,其實很好理解,主資料有問題就會導致業務出問題,所以主資料的重要性人人都知道,但實際專案中還是有各種各樣的問題。首先從甲方的角度,甲方應該要非常重視主資料,指派專人進行主資料整理,不能因為說資料量大嫌麻煩而不認真準備。從乙方的角度,應給與甲方足夠的指導,要幫助甲方理解主資料需要的字段,甚至提供模板,幫助甲方梳理主資料的建立,更新,停用等流程,確保主資料在系統中的正確性和安全性。對敏感的主資料,尤其是對業務造成影響的,比如客戶組,**商組,物料組等不能讓使用者輕易就可以對這些字段進行修改。建議二次開發主資料檢查功能,只有檢查合格的資料才可以使用後續的業務。

業務流程問題:這部分問題居多,有調研時沒有調研到的問題;有新需求變動;有流程規劃不合理;有流程變更引起的連鎖反應導致功能不一致;有只考慮正向操作不考慮取消或退貨的操作;總之,功能不完善的都歸屬這一類。這一類建議每個專案必須有個總設計師。只有各模組的負責人,出問題後各自為陣的做法在小專案中是可行的,大專案中就會出現各種問題,尤其是新增或修改功能導致其他功能不可用,導致使用者對系統的不信任。修改到最後,專案容易導致失控。越臨近專案尾聲(由於時間原因,顧問都會追求快速解決問題,不能夠周全的考慮問題), 越容易出現意想不到的問題。

功能bug:這一類屬於業務流程和資料都沒問題,但是結果不是預期結果。這類問題的測試往往是測試場景考慮不全,測試不夠充分。所有的定製在設計好功能之後,就要考慮測試場景,對所有可能有影響的場景都要測試。資料的測試建議都是3 以上。 如果是介面,要測試三個以上檔案匯入,三個以上web service呼叫同時進行。普通功能的測試行應在3行以上。為什麼是3以上,我也沒仔細思考原因,實踐中發現1~2條資料發現不了問題,三條以上就能出現問題。類似的實戰案例遇到過多次,僅僅是經驗分享,沒有理論依據。

文章最後,我想說,專案的成功有很多因素,我們可能很難找到一套確保專案成功的秘訣,但是把可能導致失敗的因素多加注意和避免我認為是能夠增加專案成功的概率。

除了以上避免外,個人還有幾點經驗,這些經驗看起來好像大家都知道,但是實際執行起來確很難。

1. 專案計畫:建議除了正常計畫外,需要做個雙周滾動計畫,計畫傳送到所有干係人。專案經理不僅僅是計畫的制定者,監督者,更重要的是要確保計畫執行所需的資源保障。

2. 過程管控:只看結果不看過程的做法,實踐證明是比較失敗的。 因為,等到結果不行的時候,時間往往已經浪費掉了,要在規定時間完成專案就必須對過程進行管控,按計畫進行專案追蹤。

3. 專家判斷及專案監理:pmp的理論中,遇到問題有乙個通用的辦法,就是專家建議。小專案可以不需要專家及專案監理。10人以上的專案,建議聘請專家第三方專案監理對專案方案進行諮詢以及交付物的檢查。專家可以是兼職的,也可以是甲方內部的關鍵人物,乙方的高階顧問但是並不一定在本專案上。第三方專案監理應脫離乙方和甲方,能夠公正的對待專案。檢查也應該是事先制定標準,不應事後找問題,監理方應是資深顧問能夠發現問題,並提出很好解決方案,協助專案走向正規。比如fdd的編寫,要給出模板。**編寫,要給出開發規範,詳細列舉最佳實踐要求。檢查標準可以不斷完善。

4. 測試: erp的測試一定要確保熟悉功能的人來測試,不能找不熟悉的人去測。甲方的關鍵使用者最好在測試前就培訓就緒,乙方在提交給甲方測試之前必須確保功能在測試環境是經過驗證的。

Dynamics 365 多選字段

update tablebase set field 1,對應選項值多個逗號隔開,1 獲取多選框所有選項 public dictionarygetmoreoptionset string entityname,string fieldname,iorganizationservice service...

Dynamics 365 技術入門建議

1.主要是因為目前市場上6.0的使用者仍然很多,作為技術人員遇到老使用者需要支援,如果只會10.0 的開發是不夠的,如果學會了6.0 再學10.0就容易很多。2.6.0 的安裝相對簡單,所佔空間也比較小,對電腦要求也要低於10.0。3.除錯簡單,方便初學者學習。4.顧問資源多,遇到問題能夠請教的人也...

Dynamics 365 刪除CRM快取

刪除crm快取 專案公升級到dynamics 365以後,過了些時間,有的賬號反饋使用很慢,甚至同乙個地方同一臺電腦用不同的賬號特別是進行資料修改的時候會發現有明顯的速度差別,why?有問題就有解決問題的方法,大神們日夜分析,發現卡頓的主要原因是執行部分sql後會卡頓,等待然後再執行,這樣導致的總體...